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

[Chuck Lever <[e-mail]>]

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

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


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


> 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