Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review

[Nico Williams <[e-mail]>]

On Sun, Aug 03, 2014 at 01:47:06AM -0400, Benjamin Kaduk wrote:
> On Fri, 1 Aug 2014, Nico Williams wrote:
> >We should agree as to data model for this, but not necessarily as to
> >encoding.  NFS uses XDR.
> 
> I think we're talking past each other.  AFS and NFS both use XDR;
> AFS is proposing to add a new fundamental data structure, in
> addition to the existing 'struct' and 'union' types.  This is a
> union type to which additional discriminant values (and
> corresponding data branches) may be added without causing existing
> implementations to fail to decode the binary data.  To do this
> requires that the encoded form for each branch of the union include
> a length field, for the length of the encoded form of the data
> branch.

Fair enough.

> >>---
> >
> >They aren't assertions in the send of a programming language "assert".
> >They are the client's assertions about local conditions, which the
> >client and only the client can know about.  The server's job is to
> >decide whether to accept those assertions considering all the context at
> >hand, including the compound authenticated principals.
> 
> I understand what they are.  All I am saying is that, while talking
> about "assertions" in this sense is normal for, e.g., SAML, it is
> not common in the GSS-API world.  This is an observation, not an
> actionable statement.

But this isn't GSS.  It's RPC, using GSS.  The term assertion here has
nothing to do with GSS.  What's being asserted has nothing to do with
GSS.

And incidentally, assertion in the SAML sense does fit what's happening
here.  Here the client makes assertions about the identity and/or
authorization attributes of a subject, "signs" them, and the server
decides what to do with them.

Other words can fit the bill, no doubt, but "assertion" seems best,
because it resembles the SAML usage, and because the English language
meaning of "assertion" fitst best.

> >>---
> >[...]
> 
> I don't think it's quite that cut-and-dried, as I can see cases
> where the client should be able to make non-critical requests, but
> also cases where the client should ask the server to fail the RPC if
> the request is not fulfillable.

Then you're proposing that criticality be described for the other cases
where it's provided, correct?  I agree.

> >>In 2.6.1.1, the following text is a little confusing:
> >>   Thus a server may refuse to
> >>   grant requested authority to a user acting alone (e.g., via an
> >>   unprivileged user-space program), or to a client acting alone (e.g.
> >>   when a client is acting on behalf of a user) but may grant requested
> >>   authority to a client acting on behalf of a user if the server
> >>   identifies the user and trusts the client.
> >>
> >>It makes more sense when one reads "client" to mean "in-kernel NFS
> >>client", but would probably be more clear if the "client is acting
> >
> >This is tricky.  What's a "client"?  The TCP client?  The physical
> >hardware running it and the NFS client stack?  The process running the
> >NFS client?  Does it matter if it's in-kernel or a FUSE process, or some
> >micro-kernel thing?  For me the only thing that matters is if it has
> >access to GSS credentials that the server will understand as being a
> >"client's" as opposed to a "user's".
> >
> >Wording this is hard, yes.
> >
> >>on behalf of a user" is reworded, possibly to "on behalf of a single
> >>user, using only that user's credentials).  It looks like the
> >
> >That's more verbose!  Yes, we need to distinguish "user with
> >credentials" from "user without credentials" (since identity assertions
> >are partly about the latter), but I think that should be clear anyways.
> 
> Hmm, I was talking about the distinction between "host with
> credentials" and "host without credentials".  Clearly there is still
> room for improvement :)

I'm not sure that we can have a "host without credentials" any more
since anonymous PKINIT (and equivalents for other mechanisms[*])
suffices for the purpose of protecting the client from the user.

And, obviously, in the case of a user-level, per-user inplementation of
NFSv4, there's no need for host credentials at all.

The server doesn't need to the client to use compound authentication --
that's for the client's protection.  But it may demand it in order to
grant more-than-normal privilege to the user.  Clearly anonymous client
credentials won't do in that case.  It's fair to expect that the clients
that should be authorized to have assertions honored must have
credentials!

[*] The key is that the user must not be able to determine the client's
    security contexts' session keys, even if the user is in full control
    of the wire.

> >>"client" vs. "kernel service" distinction is fuzzy throughout the
> >>rest of the section, too.  I would prefer if the word "client"
> >
> >We should absolutely not refer to "kernel" -- that's just an
> >implementation detail.  Instead we should refer to a "multi-user client"
> >or something of the sort.
> 
> I agree that we should not refer to "kernel"; this was intended as a
> comment about the use of the word "client" in this document and that
> it may not be appropriate in all the cases where it is currently
> used.

Sure, that may be.  I'll take a look.

Nico
--