Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

Olga, thanks for your comments.

> On Apr 1, 2019, at 12:06 PM, Olga Kornievskaia <aglo@umich.edu> wrote:
> 
> Comments about the draft-1 and section 4.3 Authentication.
> 
> 1. Why is there no option of no client authentication and simply using
> server-side authentication and using AUTH_SYS on top of it (and
> perhaps this is addressed by the 2nd editorial comment in the [] but
> the lack including this as an option bothered me). I think this is the
> most useful option to be considered.

I quite agree that it is the most useful. I don't see where we are
specifically excluding that option, however.

> I don't see how adding
> self-signed client certificates adds to the security of the system but
> instead this adds a costly PKI operation that would impact the time it
> takes to establish a secure connection.

Self-signed certificates allow a form of weak authentication by the
server. At least it can audit which client is connecting. The
discussion of self-signed certs can be removed if it's not something
we want to explicitly commend.

It can be made a little more robust by using DANE, maybe.

> 2. If there is an addition of certificated-based authentication (and
> specifically for option #4 of PKI-based crews + AUTH_NONE) shouldn't
> there be wording on what it means to do PKI-based authentication (the
> whole fun of interpreting X.509-based certification etc).

Feel free to propose text, or point us to an example discussion.

> 3. This is about the wording of option #3 and specifically ".. doesn't
> need to enable costly GSS integrity or privacy services". This to me
> reads that GSS integrity/privacy services is more costly that doing
> the same with TLS which I don't believe is a true statement.

It is a true statement in the sense that TLS may be offloaded from the
host. Otherwise, I agree: if encryption is done by the host CPU, there
is going to be little or no difference in computational cost.

> Shouldn't
> it be something like "it can forego using GSS integrity/privacy
> services because the transport layer already provides an encrypted
> connection" or something of the sorts that say we don't need to do
> integrity/privacy twice?

Sure, that's fair. I'll revise that text.

> 4. This is somewhat implementation specific question. If the draft is
> introducing an AUTH_TLS RPC security mechanism, I assume in linux we'd
> translate it to "sec=tls" option to be like other RPC AUTH mechanisms.
> But "sec=tls" doesn't quite work, it better fits with the "proto=tls"
> option group because "tls" by itself isn't enough. It'll always be
> combined with a traditional "sec=sys" or "sec=krb5". Then we are
> really introducing an option like "sec=tls+sys" or "sec=tls+krb5".

This is an implementation issue rather than a protocol issue, of
course, but I don't feel that sec= makes sense at this point. We
are not changing the way RPC users are authenticated, which is what
sec= controls.

> Then shouldn't we be introducing something like AUTH_TLS_SYS and
> AUTH_TLS_GSS?

No. The purpose of AUTH_TLS is simply to discover server support for
TLS. It is explicitly forbidden to be used after the TLS handshake.

> Or if we are really talking about "proto=tls" (or
> proto=dtls) do we even need AUTH_TLS and couldn't it be port-based
> decision to support it or not (but yes I read the RFC 2595 that
> discourages the use of "secure" ports as they could lead to user and
> administrator misconceptions). To reiterate, I feel that if AUTH_TLS
> is added but "sec=tls isn't used it would be confusing to users.

See earlier parts of this thread. I think we are purposely trying to
avoid introducing new ports and portmapper dependencies. A netid-
based solution is probably a non-starter.

I expect we will add a family of TLS mount and export options to
control transport-level security, separate from transport protocol
and user authentication mode.

> On Fri, Mar 29, 2019 at 10:18 AM Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>> 
>> 
>>> On Mar 28, 2019, at 8:35 PM, Tom Talpey <ttalpey@microsoft.com> wrote:
>>> 
>>>> -----Original Message-----
>>>> From: Chuck Lever <chuck.lever@oracle.com>
>>>> Sent: Thursday, March 28, 2019 3:43 PM
>>>> To: Tom Talpey <ttalpey@microsoft.com>
>>>> Cc: Lars Eggert <lars@eggert.org>; NFSv4 <nfsv4@ietf.org>
>>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
>>>> 
>>>> 
>>>>> On Mar 26, 2019, at 1:58 PM, Tom Talpey <ttalpey@microsoft.com> wrote:
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: nfsv4 <nfsv4-bounces@ietf.org> On Behalf Of Chuck Lever
>>>>>> Sent: Tuesday, March 26, 2019 1:52 PM
>>>>>> To: Lars Eggert <lars@eggert.org>
>>>>>> Cc: NFSv4 <nfsv4@ietf.org>
>>>>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
>>>> 01.txt
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Mar 26, 2019, at 12:35 PM, Lars Eggert <lars@eggert.org> wrote:
>>>>>>> 
>>>>>>> On 2019-3-26, at 17:33, Lars Eggert <lars@eggert.org> wrote:
>>>>>>>> Also note that STARTTLS is somewhat less secure than running TLS
>>>> directly.
>>>>>> See for example Section 6 of RFC3207:
>>>>>>>> 
>>>>>>>> A man-in-the-middle attack can be launched by deleting the "250
>>>>>>>> STARTTLS" response from the server.  This would cause the client not
>>>>>>>> to try to start a TLS session.  Another man-in-the-middle attack is
>>>>>>>> to allow the server to announce its STARTTLS capability, but to alter
>>>>>>>> the client's request to start TLS and the server's response.
>>>>>>>> 
>>>>>>>> ...
>>>>>>> 
>>>>>>> And RFC8314 recommends (for mail) that "implicit TLS" should be used
>>>>>> instead of STARTTLS.
>>>>>> 
>>>>>> Perhaps that is what we should require for RPC on TLS;
>>>>>> that is, "STARTTLS MUST NOT be used"?
>>>>> 
>>>>> It's a fine requirement, but there may need to be a justification for the MUST.
>>>>> 
>>>>> It's important to note that such a requirement means you'll need to allocate
>>>>> a new port number for such connections. This would apply to any upper
>>>>> layer using the new RPC flavor, which in turn might impact the portmapper.
>>>>> Note, it may also have implications on the proposed negotiation. If TLS is
>>>>> a "done deal", negotiating the auth flavor may be moot.
>>>> 
>>>> We could create a new netid for this purpose.
>>>> 
>>>> Advertise an RPC program with this new netid, and no STARTTLS would
>>>> be needed. The client simply connects and begins TLS negotiation.
>>> 
>>> But, the current draft proposes using a new AUTH_TLS exchange, which
>>> if successful allows the client to perform a STARTTLS. If you define a netid
>>> and/or port number, the client would simply start in TLS, prior to even
>>> sending its first RPC.
>>> 
>>> Would that not simply make the whole draft unnecessary?
>> 
>> No. The current revision places a number of restrictions on how TLS
>> is used, and that is needed in any case. But, the draft could define
>> new netids and reserve a new port number for making portmapper requests
>> using TLS.
>> 
>> Anyway, this is a strawman. I wanted to bring it up to ensure we are
>> happy with using STARTTLS.
>> 
>> 
>> --
>> Chuck Lever
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> nfsv4@ietf.org
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4

--
Chuck Lever