Re: [nfsv4] NFSv4 on TLS

["Black, David" <[e-mail]>]

> Any such document would need to discuss the client authentication semantics
> for the TLS connection, whether a single per-host client cert is used vs.
> per-user certs, etc.  BCP 195/RFC 7525 would of course play a role, too.

+1 on RFC 7525 - very useful.

OTOH, I think per-user certs are not a good idea for NFS, because NFS already has a notion of user identity, channel binding has been difficult to deploy in practice, and there's value in separating user authentication (and identities) from machine/device authentication (and identities) in this context.

Starting with authentication separation, the baseline for this mechanism ought to be "AUTH_SYS-over-TLS" where the TLS per-host certs are for machine/device authentication and user "authentication" (well, for AUTH_SYS, it's more authorization than authentication) is initially handled via AUTH_SYS UIDs/GIDs over a TLS connection.  In this scenario, TLS secures the machine-to-machine connection enabling the AUTH_SYS UIDs/GIDs to be trusted by the server - Keeping that security property/goal in mind helps in figuring out what to do for TLS client authentication.

One possibility, TLS certs could be used as part of selecting a "domain" or "space" for AUTH_SYS UIDs/GIDs - one way to do that would be to run a separate NFS server instance per "domain" or "space" where the client uses the TLS Server Name indication to select the server that it wants to talk to.  Client validation of the server's TLS certificate then assures the client that it's talking to the intended AUTH_SYS "domain" or "space" and server TLS authentication of the client can establish whether or not the client is authorized to access that AUTH_SYS "domain" or "space".  That may involve TLS client certs, but this is machine-to-machine authorization (no humans) where that's definitely feasible.

Thanks, --David

> -----Original Message-----
> From: nfsv4 [mailto:[e-mail]] On Behalf Of Benjamin Kaduk
> Sent: Tuesday, October 16, 2018 4:03 PM
> To: Trond Myklebust
> Cc: [e-mail]; Rick Macklem; [e-mail]
> Subject: Re: [nfsv4] NFSv4 on TLS
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
> 
> I'm not really in a position to speak of the level of demand for such a
> proposal, but...
> 
> On Tue, Oct 16, 2018 at 03:53:32PM -0400, Trond Myklebust wrote:
> > So here is a quick proposal: we add a new security type AUTH_TLS, which
> can
> > act as the equivalent of a "STARTTLS command" to signal that we want to
> > initiate TLS security negotiation if the server supports it.
> >
> > When the client has set up the TCP connection, and is ready to initiate the
> > TLS negotiation, it pings the server with a NULL RPC request with an
> > auth_flavor of AUTH_TLS. If the server doesn't recognise that flavour, and
> > returns AUTH_ERROR (+AUTH_BADCRED?), then the client knows that the
> server
> > is unlikely to support stepping up to TLS on this connection.
> >
> > There should be no need for the credential to carry any form of
> > authentication payload, so just model it on AUTH_NONE, but have the
> server
> > return a payload of "STARTTLS" in the body of the verifier. That
> > differentiates it from AUTH_NONE, and allows the client to distinguish
> > servers that recognise AUTH_TLS, and servers that just ignore the
> > authentication header altogether in NULL RPC calls. If the payload matches,
> > then the client kicks off TLS negotiation before sending any further RPC
> > calls on this connection.
> >
> > If the client tries to use AUTH_TLS for anything other than a NULL RPC
> > ping, then a server would presumably be expected to return AUTH_ERROR
> with
> > AUTH_TOOWEAK.
> >
> > Once the TLS negotiation is complete, then the client and server will have
> > established a secure channel for communicating, and can then use the
> 
> Any such document would need to discuss the client authentication
> semantics
> for the TLS connection, whether a single per-host client cert is used vs.
> per-user certs, etc.  BCP 195/RFC 7525 would of course play a role, too.
> 
> > standard security flavours on top of that channel (presumably after
> > negotiating down the irrelevant RPCSEC_GSS privacy and integrity
> mechanisms
> > and applying channel binding).
> 
> Anyone considering GSSAPI channel binding should probably consider the
> issues that
> https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-03 tries
> to address, and also that the tls-unique-based binding value in RFC 5929 is
> rather overtaken by events.  There would probably be a need to define a
> new
> TLS exporter-based value that requires the use of TLS 1.3 or
> extended-master-secret.
> 
> -Ben
> 
> > Is this a proposal that might be of interest to members of this group, and
> > hence be worth documenting in an RFC?
> >
> > Cheers
> >   Trond
> >
> > On Tue, 28 Aug 2018 at 07:57, Rick Macklem <[e-mail]>
> wrote:
> >
> > > David Noveck wrote:
> > > [stuff snipped]
> > > >> AUTH_SYS with UIDs/GIDs is too limited.
> > > >
> > > >As far as I know, AUTH_SYS includes 32-bit UIDs/GIDs.   Those seemed
> > > ample when
> > > >AUTH_SYS was designed.
> > > >
> > > >It certainly is too limited now, but it is difficult to change. Even more
> > > of a
> > > >barrier than the existiing OTW formats, is the fact that most flle systems
> > > >used with NFS reserve 32 bits in the inode for each of owner and group.
> > > >Further complicating matters is that in-kernel VFS's and POSIX API's are
> > > >built around this very limited approach to user identity.
> > > >
> > > >> I have no objection to a mechanism like AUTH_SYS-over-TLS
> > > >
> > > >I don't know of any AUTH_SYS mechanism that uses anything other than
> > > >32-bit ids.
> > > >
> > > >> that uses name@domain to be consistent with the rest of NFSv4.
> > > I think he was referring to a new authentication flavour that had the
> > > "user@domain" string as the authenticator. (There is a 400byte limit, but
> > > that might be sufficient.) I might have called it AUTH_NAME or
> AUTH_OWNER.
> > >
> > > I'd guess that 99.9% of FreeBSD NFS usage is AUTH_SYS, although
> Kerberos is
> > > in the system. I do think a way to use TLS (or similar) to encrypt at the
> > > transport
> > > level would be a good thing and would get used more widely.
> > >
> > > Many of the FreeBSD sites (I won't guess the %) use AUTH_SYS but
> ignore the
> > > gid list and generate a gid list on the server from the uid. As such, I
> > > don't think
> > > putting gids/owner_group names in a new authentication mechanism is
> needed.
> > >
> > > For folks that have a 32bit uniform uid space, AUTH_SYS in transport
> > > encryption
> > > seems ok to me.
> > > For sites where the uid space isn't uniform or doesn't fit in 32bits, a
> > > "user@domaim"
> > > to uid/gid list mapping in the server can be done using this new one.
> > >
> > > >Within NFSv4 proper, you could use name@domain, but there is really
> no
> > > >point if you are using AUTH_SYS.    You are allowed to use numeric ids
> > > >as attributes and most people using AUTH_SYS choose to do so, to avoid
> > > >the overhead of a translation that provides no benefits.
> > > They could use this mapping with AUTH_OWNER when AUTH_SYS won't
> > > work for them.
> > >
> > > rick
> > > ps: I, for one, am not interested in implementing a new GSSAPI
> mechanism
> > > that
> > >       isn't in the open source Kerberos distros. As such, any complicated
> > > setup
> > >       involving writing of a lot of new code probably wouldn't make it in
> > > FreeBSD
> > >       for a long time. However, something that mostly uses the extant code
> > > for
> > >       supporting "https" should be doable.
> > > [more stuff snipped]
> > >
> > > _______________________________________________
> > > nfsv4 mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/nfsv4
> > >
> 
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4