Subject: Re: [nfsv4] NFSv4 on TLS

From: Trond Myklebust <[email-masked]>
Date: Tue, 16 Oct 2018 15:53:32 -0400

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
standard security flavours on top of that channel (presumably after
negotiating down the irrelevant RPCSEC_GSS privacy and integrity mechanisms
and applying channel binding).

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Oct 2018 15:02:43 -0500

I'm not really in a position to speak of the level of demand for such a
proposal, but...

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

> 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

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 16 Oct 2018 17:03:59 -0400

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

> TLS exporter-based value that requires the use of TLS 1.3 or
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

---

From: "Black, David" <[email-masked]>
Date: Tue, 16 Oct 2018 21:10:48 +0000

> 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:[email-masked]] On Behalf Of Benjamin Kaduk
> Sent: Tuesday, October 16, 2018 4:03 PM
> To: Trond Myklebust
> Cc: [email-masked]; Rick Macklem; [email-masked]
> Subject: Re: [nfsv4] NFSv4 on TLS
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
>

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 16 Oct 2018 17:17:52 -0400

> practical for providing machine level authentication, not user level.
I should note, OTOH, that using TLS for machine authentication, and being
able to use certificate information in my /etc/exports file would be highly
useful!

---

From: Chuck Lever <[email-masked]>
Date: Tue, 16 Oct 2018 17:19:11 -0400

> On Oct 16, 2018, at 5:10 PM, Black, David <[email-masked]> wrote:
> 

A primary use case for separating machine and user authentication is when
user identity and machine identity are managed by distinct authorities.

For example, a cloud provider might be responsible for managing machine
identities, but a tenant of that cloud might be responsible for managing
UID information, or possibly a Kerberos KDC, for that tenant's users.

--
Chuck Lever

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 16 Oct 2018 17:40:54 -0500

> something that I can envision wanting to ever implement for a kernel NFS

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?

> practical for providing machine level authentication, not user level.

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

> that as far as I can tell should meet the requirements in the above

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

---

From: Trond Myklebust <[email-masked]>
Date: Wed, 17 Oct 2018 00:07:09 -0400

On Tue, 16 Oct 2018 at 18:41, Benjamin Kaduk <[email-masked]> wrote:

> > > > So here is a quick proposal: we add a new security type AUTH_TLS,
> which
> > > can
> > > > When the client has set up the TCP connection, and is ready to
> initiate
> > > the
> > > > auth_flavor of AUTH_TLS. If the server doesn't recognise that
> flavour,
> > > and

So that's the thing. While Linux is running on cell phones, which obviously
won't have more than 1 or 2 users, most of our NFS users tend to be running
server farms where each node can run processes on behalf of lots of
different users. A few 10s or 100s of users per node is not uncommon, with
upper bounds being on the order of 1000 or so. With server farms easily
reaching into the 10000 client range these days (because of virtualisation)
then that can run into quite a few connections per server. pNFS doesn't
really help, since all clients still need to talk to the metadata server,
and each pNFS data server will add to the number of connections that each
client needs to maintain...

So I'm asserting that the main scalability issue when using TLS with user
certificates would be on the server side due to the number of clients and
users per client, but the clients themselves would be affected too, since
they have to deal with scale out servers.

Does that make sense?

> > > > Is this a proposal that might be of interest to members of this
> group,
> > > and
> > > > > >It certainly is too limited now, but it is difficult to change.
> Even
> > > more
> > > > > of a
> > > > > >Further complicating matters is that in-kernel VFS's and POSIX
> API's
> > > are
> > > > > "user@domain" string as the authenticator. (There is a 400byte
> limit,
> > > but
> > > > > in the system. I do think a way to use TLS (or similar) to encrypt
> at
> > > the
> > > > > transport
> > > > > >Within NFSv4 proper, you could use name@domain, but there is
> really
> > > no
> > > > >       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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 17 Oct 2018 11:41:21 -0500

> they have to deal with scale out servers.

Yes, and thank you -- I just wanted to get a rough sense of the scale
involved, which I now have :)

-Ben