Re: [nfsv4] NFSv4 on TLS

[Benjamin Kaduk <[e-mail]>]

On Tue, Oct 16, 2018 at 05:03:59PM -0400, Trond Myklebust wrote:
> On Tue, 16 Oct 2018 at 16:02, Benjamin Kaduk <[e-mail]> wrote:
> 
> > 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.
> >
> 
> This is transport level security, so in order to have per-user certs, we'd
> presumably have to have a TCP connection per user? That is certainly not
> something that I can envision wanting to ever implement for a kernel NFS
> client.

There are some ugly tricks that could be played, but basically your
presumption is right.  If I may ask, though, how many concurrent NFS client
users do you think you need to support on a single NFS client machine?

> IOW: As far as this working group is concerned, I'd see TLS as mainly
> practical for providing machine level authentication, not user level.

I don't really expect anyone to disagree with that.

> I agree that there are issues addressed by RFC7525 that we may want to
> discuss.
> 
> 
> >
> > > 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.
> >
> >
> Is that discussion relevant to the NFSv4 working group though? NFSv4 only
> requires servers to support RPCSEC_GSSv2 (or RPCSEC_GSSv3 for NFSv4.2).
> Both those protocols have explicit channel binding RPC calls that return
> success/failure, and a separate service type (rpc_gss_svc_channel_prot)
> that as far as I can tell should meet the requirements in the above
> document. Am I wrong?

You are right -- I had forgotten that RPCSEC_GSSv2 uses a different binding
scheme, and in fact section 5 of RFC 5403 says you SHOULD NOT use native
GSS channel bindings.

Sorry about that.

-Ben

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