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

[Tom Talpey <[e-mail]>]

> -----Original Message-----
> From: nfsv4 <[e-mail]> On Behalf Of Olga Kornievskaia
> Sent: Wednesday, April 3, 2019 12:13 PM
> To: Chuck Lever <[e-mail]>
> Cc: NFSv4 <[e-mail]>
> Subject: Re: [nfsv4] New Version Notification for draft-cel-nfsv4-rpc-tls-01.txt
> 
> 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.

Olga, I support this approach but would like to suggest it also explore the
inter-relation of existing RPC authentication methods with TLS. For example,
if per-user keys (obtained from the auth itself) are used to secure the TLS
channel, rather than the more usual machine-wide ones.

In addition there are implications on trunking and multiplexing of traffic,
and under what conditions traffic destined for a TLS channel can be redirected
and/or retried . For example, if GSS privacy is "downgraded" once a TLS channel
binding is established, then any trunked connections cannot be used until and
unless a similarly-protected TLS association is obtained on them as well. This
gets especially hairy in reconnection/retry scenarios.

Tom.

> > 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". 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-ietf-nfsv4-rpc-
> tls%2F&amp;data=02%7C01%7Cttalpey%40microsoft.com%7C03bbacc8265a4
> 10c140508d6b84f3cf2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7
> C636899047801793678&amp;sdata=rTIELxr2yBE8vluAoCHkmZJXqd%2FwHV%
> 2F2BHblUvSCz3g%3D&amp;reserved=0
> > >>
> > >> 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.
> 
> >
> >
> > > 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
> >
> >
> >
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fnfsv4&amp;data=02%7C01%7Cttalpey%40mi
> crosoft.com%7C03bbacc8265a410c140508d6b84f3cf2%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C636899047801793678&amp;sdata=7gZKwy
> NwPk7KqrbafSfzaFnP%2ByLVknRu0tqIprtpBZc%3D&amp;reserved=0