Re: [nfsv4] NFSv4 on TLS

[Benjamin Kaduk <[e-mail]>]

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