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

[Olga Kornievskaia <[e-mail]>]

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 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.

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).

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. 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?

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".
Then shouldn't we be introducing something like AUTH_TLS_SYS and
AUTH_TLS_GSS? 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.

On Fri, Mar 29, 2019 at 10:18 AM Chuck Lever <[e-mail]> wrote:
>
>
>
> > On Mar 28, 2019, at 8:35 PM, Tom Talpey <[e-mail]> wrote:
> >
> >> -----Original Message-----
> >> From: Chuck Lever <[e-mail]>
> >> Sent: Thursday, March 28, 2019 3:43 PM
> >> To: Tom Talpey <[e-mail]>
> >> Cc: Lars Eggert <[e-mail]>; NFSv4 <[e-mail]>
> >> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> >>
> >>
> >>> On Mar 26, 2019, at 1:58 PM, Tom Talpey <[e-mail]> wrote:
> >>>
> >>>> -----Original Message-----
> >>>> From: nfsv4 <[e-mail]> On Behalf Of Chuck Lever
> >>>> Sent: Tuesday, March 26, 2019 1:52 PM
> >>>> To: Lars Eggert <[e-mail]>
> >>>> Cc: NFSv4 <[e-mail]>
> >>>> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-
> >> 01.txt
> >>>>
> >>>>
> >>>>
> >>>>> On Mar 26, 2019, at 12:35 PM, Lars Eggert <[e-mail]> wrote:
> >>>>>
> >>>>> On 2019-3-26, at 17:33, Lars Eggert <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4