Re: [nfsv4] NFSv4 on TLS

[Trond Myklebust <[e-mail]>]

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



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