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

[Benjamin Kaduk <[e-mail]>]

On Fri, Apr 05, 2019 at 10:35:39AM -0400, Chuck Lever wrote:
> 
> 
> > On Apr 4, 2019, at 3:52 PM, Mkrtchyan, Tigran <[e-mail]> wrote:
> > 
> > Hi Chuck,
> > 
> > ----- Original Message -----
> >> From: "Chuck Lever" <[e-mail]>
> >> To: "Tigran Mkrtchyan" <[e-mail]>
> >> Cc: "NFSv4" <[e-mail]>
> >> Sent: Thursday, April 4, 2019 4:32:55 PM
> >> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> > 
> >> Hi Tigran-
> >> 
> >>> On Apr 3, 2019, at 5:31 PM, Mkrtchyan, Tigran <[e-mail]> wrote:
> >>> 
> >>>>>>> 3. Section 4.2.3 "Advanced forms of RPC authentication". I'm surprised
> >>>>>>> to see this here because of the wording in Section 1. Specifically it
> >>>>>>> says: "An alternative approach is to employ transport layer security
> >>>>>>> mechanism". Here alternative was to the GSS mechanism which was listed
> >>>>>>> as "hard to use". So nowhere was there a talk that TLS connection can
> >>>>>>> be used with a GSS mechanism. Is this section suppose to be about the
> >>>>>>> fact that RPCSEC GSS besides authentication also provides an encrypted
> >>>>>>> connection? Then I think the section title should be changed to
> >>>>>>> "RPCSEC GSS secure connection establishment"?   This section,blurs the
> >>>>>>> lines of RPC identify authentication via GSS identities and the TLS
> >>>>>>> authentication. In previous two section, it wasn't discussed what kind
> >>>>>>> of RPC authentication would happen on top of the TLS connection. I
> >>>>>>> think this whole section should be removed. Because it basically says
> >>>>>>> there is no need to use GSS privacy/integrity since underlying TLS
> >>>>>>> connection already provides that and since TLS is suppose to be
> >>>>>>> alternative to GSS so why combined it.
> >>>>>> 
> >>>>>> We have to discuss the use of channel binding somewhere, and
> >>>>>> we have to discuss the double host authentication because TLS
> >>>>>> has a host authentication step and so does GSS. I don't see any
> >>>>>> discussion of user authentication here.
> >>>>> 
> >>>>> I would have re-organized this to be something like:
> >>>>> 
> >>>>> 4.2 Establishing an end-to-end encrypted channel
> >>>>> same paragraph as before about providing a transparent end-to-end
> >>>>> encrypted channel for the RPC operations.
> >>>>> 4.2.1 TLS server-only authentication
> >>>>> (same as before)
> >>>>> 4.2.2 TLS mutual authentication
> >>>>> (same as before)
> >>>>> 4.3.3 Role of the RPCSEC GSS integrity and privacy services
> >>>>> Here talk about redundancy of using GSS services on top of TLS.
> >>>>> Channel binding would go here.
> >>>>> 
> >>>>> 4.3 RPC authentication on top of an encrypted channel
> >>>>> Here talk about how any of the existing methods (AUTH_SYS, GSS) can be
> >>>>> overplayed on top of the encrypted channel.
> >>>> 
> >>>> I'm not sure this warrants its own subsection. I'll look into
> >>>> explicitly stating that RPC user authentication is not altered
> >>>> by transport encryption earlier in Section 4.
> >>>> 
> >>>> Hopefully the new language will not forbid someday specifying
> >>>> user authentication via certificates. For now I would like to
> >>>> keep this document narrowly focused on providing transport
> >>>> encryption.
> >>> 
> >>> In GRID computing, dealing with end-user certificates is the main
> >>> reason why we try to move away from X509. Proxy certificates
> >>> with limited life time to pass around with, LDAP configs,
> >>> renewal, trusted CA distribution, CRLS, legal requirements to
> >>> present ID-card to get a certificate in the first place...
> >>> However, RPC is not only NFS. We have accelerator control systems,
> >>> that use AUTH_NONE with IP table rules.
> >> 
> >> Indeed, this is a use case that is interesting to me as well.
> >> In cases where a transient cloud service is spun up that has
> >> no local user identities, AUTH_NONE would be appropriate to
> >> use.
> >> 
> >> 
> >>> And, in general, many
> >>> server-to-server RPC based communication will benefit from
> >>> client+server mutual authentication. For example pNFS deployment,
> >>> where DSes talk to MDS and both want to be sure that the other
> >>> side is the right one.
> >> 
> >> This sounds like what Trond is most interested in.
> >> 
> > 
> > With a deployment dedicated CA it's an easy way to
> > control which hosts belongs to the instance. We do
> > it for our internal message communication.
> > 
> >> 
> >>> IOW, don't require it, but keep it possible.
> >> 
> >> I'm not sure exactly what you would like to see.
> >> 
> >> - The option to use user certificates for host authentication
> >> specified in this document.
> >> 
> >> - The option to use user certificates for host authentication
> >> left open for a future specification.
> >> 
> >> - The option to use user certificates for user authentication
> >> specified in this document.
> >> 
> >> - The option to use user certificates for user authentication
> >> left open for a future specification.
> >> 
> > 
> > 
> > Let's have a look and HTTP-over-TLS (rfc2818). No special requirement
> > for client authentication. The TLS spec (rfc8446) says:
> > 
> >   4.3.2.  Certificate Request
> > 
> >      A server which is authenticating with a certificate MAY optionally
> >     request a certificate from the client. 
> > 
> > The combination of it I read as: server configuration controls is client
> > certificate requested or not. Thus, leave it to TLS configuration.
> > 
> > But what should be part of your document is the handling of TLS session
> > termination. Something like (please make it rfc language compliant):
> 
> Makes sense. Questions below:
> 
> 
> >   Client can terminate the TLS session after sending a TLS closure alert.
> 
> What if a client closes the connection without terminating
> the TLS session?

Indeed, close_notify is basically unusable in the web world due to clients
just doing this.

> 
> >   After TLS session termination any other RPC requests over the same connection
> >   will fail with AUTH_ERROR.
> 
> What about UDP with DTLS?

(There's not a reliable way to do so.)

-Ben