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

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Chuck Lever" <[e-mail]>
> To: "Olga Kornievskaia" <[e-mail]>
> Cc: "NFSv4" <[e-mail]>
> Sent: Wednesday, April 3, 2019 7:47:48 PM
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt

>> On Apr 3, 2019, at 12:12 PM, Olga Kornievskaia <[e-mail]> wrote:
>> 
>> On Tue, Apr 2, 2019 at 11:15 AM Chuck Lever <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>>> On Apr 2, 2019, at 10:28 AM, Olga Kornievskaia <[e-mail]> wrote:
>>>> 
>>>> Hi Chuck,
>>>> 
>>>> First of all I apologizes for reading an out-dated version of the draft.
>>>> 
>>>> There are still several things I disagree with and some questions that I have:
>>>> 
>>>> 1. Encryption offload. I think it's unfair to list this as a benefit
>>>> of switching to TLS from tradition encryption methods. TLS adds a very
>>>> costly operation (public key encryption) which to reduce the impact on
>>>> performance needs to leverage things like offload engines. The same
>>>> link talks about how all modern CPUs have hardware support for
>>>> symmetric key ciphers like AES which speeds things up. In my opinion,
>>>> this list item should be removed.
>>> 
>>> TLS offload actually exists. GSS does not give us any practical
>>> path for offloading encryption and decryption. If an example of
>>> a commodity part that provides GSS offload can be identified,
>>> I'll consider removing this bullet.
>>> 
>>> 
>>>> -- what's a transient client?
>>> 
>>> An example is a guest's laptop.
>>> 
>>> 
>>>> 2. "Per-client deployment and administrative costs are not scalable"
>>>> (I'm assuming it means deploying keytabs). Yet the spec is talking
>>>> about the use of host certificates. If existing design is not scalable
>>>> so will the design with host certificates (or user certificates) as it
>>>> requires the same deployment. In my opinion, this bullet should be
>>>> removed (and so it the 3rd list item that talks about CPU cost of
>>>> encryption).
>>> 
>>> Certificates on RPC clients are optional. In deployment scenarios
>>> that don't provide client certificates, administrative cost is
>>> lower.
>> 
>> Sure, but then please add explicitly to the 4.2.2 (mutual
>> authentication) that this mode adds to the deployment cost making it
>> equivalent to the existing GSS model.
>> 
>>> I'll change the bullet to refer to "clients" instead of "host
>>> systems".
>>> 
>>> 
>>>> 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. 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.

IOW, don't require it, but keep it possible.

Tigran. 


> 
> 
>>> I'll change the section title.
>>> 
>>> 
>>>> 4. Section 5 is about TLS authentication and PKI identities. I find it
>>>> confusing the use of RPC client. RPC client has RPC identities from
>>>> the RPC RFC. Should we use TLS client here instead?
>>>> 
>>>> -- what is a TLS identifier? If it's defined in the TLS spec can we
>>>> either copy a definition or provide a reference for it?
>>> 
>>> I'm looking for a generic term that encapsulates certificate,
>>> PSK, or token binding to mean the identity of the peer host.
>>> Anyone know of a appropriate term to use for that?
>> 
>> Sorry more question about section 5 "TLS peer authentication".  Is the
>> purpose here to describe how a server would authenticate the client or
>> how the client authenticates the server (or both). I think the
>> intention to handle "both".
> 
> It is both. I'll correct the text throughout Section 5.
> 
> 
>> So if this section applies to both side
>> then the use "RPC client is uniquely identified by tuple" to me reads
>> to only apply to the RPC client. If this suppose to apply to both then
>> "TLS peer" maybe used? If this is suppose to be talking about just one
>> side authentication (whatever side that is), then why another side is
>> excluded (again I think it is both). Some of the bullets talk about
>> requirements for server authentication, but then there is wording that
>> server can deny
>> 
>> Also, for the "pre-shared" keys section can we add a reference to
>> RFC8446 section 2.2 otherwise there isn't much context here. Though I
>> feel that this draft was about making deployment easier so the cost of
>> pre-sharing the keys is like going backwards.
>> 
>> 
>>>> -- If an (RPC/NFS) server suppose to make decisions about executing an
>>>> RPC/NFS request based on the PKI identify shouldn't there be a talk
>>>> about how to map the PKI identify into the NFSv4 identify?
>>> 
>>> RPC over TLS is strictly about encryption at the RPC layer. It
>>> has nothing to do with the RPC user, and NFSv4 has no awareness
>>> that TLS is in use at the transport layer.
>>> 
>>> The server may determine whether to accept or reject a connection
>>> request based on the client's identity. That identity is not used
>>> to authorize individual RPC requests.
>> 
>>> 
>>> 
>>>> other comments in-line.
>>>> 
>>>> On Mon, Apr 1, 2019 at 6:58 PM Chuck Lever <[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Apr 1, 2019, at 4:31 PM, Olga Kornievskaia <[e-mail]> wrote:
>>>>>> 
>>>>>> On Mon, Apr 1, 2019 at 1:50 PM Chuck Lever <[e-mail]> wrote:
>>>>>>> 
>>>>>>> Olga, thanks for your comments.
>>>>>>> 
>>>>>>> 
>>>>>>>> On Apr 1, 2019, at 12:06 PM, Olga Kornievskaia <[e-mail]> 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.
>>>>>> 
>>>>>> Ok I guess I have issues with wording. That section talks about "host
>>>>>> and user authentication". What is "host" here? Is this the NFS server
>>>>>> or is this a client machine where a "user" might execute NFS
>>>>>> operations? I really hope that "host" means an NFS server and it's the
>>>>>> NFS server that will be authenticated via TLS (which means a
>>>>>> server-side certificate will be used).
>>>>> 
>>>>> I thought that "host authentication" had an unambiguous meaning.
>>>>> It means that the peer host is authenticated.
>>>>> 
>>>>> RPCSEC GSS performs host authentication using the service principals
>>>>> on both peers.
>>>>> 
>>>>> With TLS, AIUI, the client can always authenticate the server, because
>>>>> the server is required to have an identity (typically a certificate).
>>>>> The server can authenticate a connecting client if the client has an
>>>>> identity and presents it during the TLS handshake.
>>>>> 
>>>>> I can add "host authentication" and "user authentication" in the
>>>>> Terminology section if people feel that would be helpful. Or should
>>>>> I use "machine authentication" instead of "host authentication" ?
>>>> 
>>>> With the new organization of the draft I don't have those objections.
>>>> 
>>>>> 
>>>>> 
>>>>>> That leads to Option 1 wording.
>>>>>> It's not clear which side would used a self-signed certificate and why
>>>>>> we right away restricting/suggestion the type of the certificate. I
>>>>>> think it would be better to say: "To establish a secure TLS connection
>>>>>> at least a server-side PKI certificate is required and can provides
>>>>>> server authentication. Statement: "end-to-end encryption is provided
>>>>>> client certificate material" ... I don't think that's what end-to-end
>>>>>> encryption typically means. I would rather say. "Mutual authentication
>>>>>> is provided when client also presents a PKI certification during a TLS
>>>>>> handshake." (or something of that sorts).
>>>>>> 
>>>>>> My wording of the options:
>>>>>> TLS server-side authentication only with AUTH_SYS identity: To
>>>>>> establish a secure TLS connection a server-side PKI certificate is
>>>>>> required and provides server authentication (either self-signed or
>>>>>> CA-certified certificates can be used). After TLS connection is
>>>>>> established, the RPC client uses AUTH_SYS to identify users with the
>>>>>> guarantee that the UID and GID values cannot be observed or altered in
>>>>>> transit.
>>>>>> 
>>>>>> TLS mutual authentication with AUTH_SYS:  During TLS negotiation, the
>>>>>> client identifies itself to the server with a PKI certificate.  As
>>>>>> with encryption-only with AUTH_SYS, UID and GID values are well
>>>>>> protected.  In addition, the server can use the client's PKI identity
>>>>>> to perform additional authorization of this client's requests.
>>>>>> 
>>>>>> TLS server-side authentication only with RPCSEC GSS Kerberos identify:
>>>>>> To establish a secure TLS connection a server-side PKI certificate is
>>>>>> required and provides server authentication (either self-signed or
>>>>>> CA-certified certificates can be used). The RPC client uses Kerberos
>>>>>> to identify the client host and its users, but does not request GSS
>>>>>> integrity or privacy services as the connection is already secured.
>>>>>> 
>>>>>> TLS mutual authentication with AUTH_NONE:  Each user establishes her
>>>>>> own TLS context with the server, identified by a user PKI certficate.
>>>>>> There is no need for any additional information at the RPC layer, so
>>>>>> the RPC client can use the simplest authentication flavor for RPC
>>>>>> transactions.  This configuration is not typical for NFS deployments,
>>>>>> but it does enable strong certificate-based user authentication, which
>>>>>> is currently not afforded by GSS.
>>>>> 
>>>>> This appears to be based on an outdated version of this document.
>>>>> The latest version is here:
>>>>> 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpc-tls/
>>>>> 
>>>>> I hope Section 4.2 of the latest revision answers your questions.
>>>>> 
>>>>> 
>>>>>> If by "host" you don't mean the "server" and mean client's machine.
>>>>>> And for the server we are not implying that it's OK to use self-signed
>>>>>> certificates (which I really hoped we were not suggestion).
>>>>>> 
>>>>>> Then the options I propose should be:
>>>>>> 1. TLS server-side authentication + AUTH_SYS user identity: this is
>>>>>> the favorable option of no certificates on the client at all and only
>>>>>> server is authenticated.
>>>>>> 
>>>>>> 2. TLS mutual authentication with machine certificates + AUTH_SYS user
>>>>>> identity . This is where I think a suggestion to use a self-signed
>>>>>> certificate can be made (however see my view below that I don't this
>>>>>> client-side authentication gains us anything).
>>>>>> 
>>>>>> 3. TLS mutual authentication with user certificates + AUTH_SYS user identify
>>>>>> 
>>>>>> 4. TLS mutual authentication with machine certificate + Kerberos user identify
>>>>>> 
>>>>>> 5. TLS mutual authentication with user certificates + Kerberos user identify
>>>>>> 
>>>>>> 6. TLS mutual authentication with user certificates + AUTH_NONE
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> 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.
>>>>>> 
>>>>>> In my personal option, adding self-signed (user) authentication
>>>>>> provides no benefits as there no attack that it protects from. We are
>>>>>> not proposing to use the identity gotten from the client-side of the
>>>>>> TLS connection and map it to an nfs4 identity, are we (cue in the SPKM
>>>>>> troubles here).
>>>>> 
>>>>> IIRC we eventually decided not to support the use of user certs
>>>>> for RPC on TLS.
>>>> 
>>>> I don't think that's true as the Section 5.2 talks it.
>>> 
>>> Where? I see only discussion of the RPC client's identity.
>> 
>> Section 5.2 says "an RPC client is uniquely identified by the tuple
>> ... ie certificate". To me this reads, a client has a user
>> certificate.  But this section doesn't talk about the self-signed
>> certs.
> 
> I've reread the first paragraph of Section 5.2.1. I'm still
> not getting any sense that this implies a user certificate.
> 
> However I expect this text will change to accommodate
> replacing "RPC client" with a term that means both peers.
> Let's revisit with the next revision.
> 
> 
>>>> While there is
>>>> definitely a lot more information about what should go into the user
>>>> certificate and a concrete PKI identity : "an RPC client is uniquely
>>>> identified by the tuple (serial number of presented client
>>>> certificate;Issuer)" there is nothing about how to map this to the
>>>> NFSv4 identify.
>>> 
>>> That's because the NFSv4 protocol is not aware of the use of TLS.
>>> There is no connection between NFSv4 identities and TLS. If a user
>>> certificate is employed, it is used strictly for host authentication.
>>> 
>>> 
>>> --
>>> Chuck Lever
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4