Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

[Trond Myklebust <[e-mail]>]

On Wed, 17 Apr 2019 at 16:37, Mkrtchyan, Tigran
<[e-mail]> wrote:
>
>
>
> ----- Original Message -----
> > From: "Trond Myklebust" <[e-mail]>
> > To: "Chuck Lever" <[e-mail]>
> > Cc: "NFSv4" <[e-mail]>
> > Sent: Tuesday, April 16, 2019 2:37:54 PM
> > Subject: Re: [nfsv4] Fwd: I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
>
> > A more general question that this raises is: Do we consider TLS as
> > part of the authentication mechanism, and if so, what is its role?
> > IOW: if the client does present a certificate when it sets up the TLS
> > channel, then should that suffice to prevent an attacker from setting
> > up a new TCP connection to the same server, and spoofing the identity
> > of that client without possessing the original client certificate?
> > If we do want that ability, then we should also look at consequences
> > for the NFSv4 state model and perhaps add a SP4_TLS mode to the state
> > protection negotiation in EXCHANGE_ID (as we already do for SSV).
>
> The same way as rfc1831 enforces unix security - up to service specific doc.
> Even RPCSEC_GSS doesn't require gss context per user. TLS session per user
> might be a challenging task.

Agreed, but I wasn't considering per user certificates. In the above
discussion I'm only talking about the client identifying itself, and
what consequences that may have.

In essence, the argument boils down to: I think we might be able to
use TLS as a substitute for SSV if the clients identify themselves via
a (per client) certificate.

Dave suggested that might require a new version of the EXCHANGE_ID op,
but I'm less sure. It seems to me that extending the type 'enum
state_protect_how4' by adding a value for SP4_TLS should allow us to
extend the existing EXCHANGE_ID type. Legacy servers would presumably
respond with a NFS4ERR_INVAL  or possibly NFS4ERR_BADXDR, since they
won't recognise that value for the state_protect4_a union, allowing
the client to negotiate down to a supported type.

> >
> > There is also the issue of trunking. Do we want to allow NFS clients
> > to use TLS authentication as a way to identify multi-homed servers?
>
> This is an interesting one. What about migration? Require 'Subject
> Alternative Name'?  Is this different from kerberos based trunking?
>

You presumably do not want to look exclusively at the alternative
names, since that would imply that the servers are presenting
different certificates, and identify as different services. I agree
though that you might be able to do the same with RPCSEC_GSS.

Cheers
  Trond