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

[Benjamin Kaduk <[e-mail]>]

On Mon, 4 Aug 2014, Nico Williams wrote:

> On Sun, Aug 03, 2014 at 01:47:06AM -0400, Benjamin Kaduk wrote:
>> On Fri, 1 Aug 2014, Nico Williams wrote:
>>>> ---
>>> [...]
>>
>> 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.

I think so?  I'm not sure I understand exactly what you're saying.
The main thing I'm saying is that we define a critical bit for all types 
of rgss3_assertion, but do not specify what to set it to for one branch of 
the rgss3_assertion_u union.  That looks like what you're saying, too.

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

Many krb5 realms do not have PKINIT enabled on the KDC.

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

Yes.

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

Yes.

-Ben