Re: [nfsv4] NFSv4 on TLS

[Trond Myklebust <[e-mail]>]

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

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

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?


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