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

[Chuck Lever <[e-mail]>]

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.


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

Enabling user certs at all seems like it could add significant
complexity to the document, and IIUC the use of user certs
might need some involvement with the protocol being carried
by RPC. That's why my preference would be to defer this
complexity to other specifications, if we can.

The next revision is evolving here:

https://github.com/chucklever/i-d-rpc-tls/tree/master

The Editor's Copy is the latest work, and there is a link
under that to generate an rpcdiff with the revision that was
submitted earlier this week to the datatracker.


--
Chuck Lever