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

[Benjamin Kaduk <[e-mail]>]

I guess I'll split my replies amongst the existing thread instead of 
trying to reconsolidate everything.  Going in reverse order so as to try 
to avoid duplicating previous discussion...

On Fri, 1 Aug 2014, Nico Williams wrote:

> On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote:
>> The union construct in 2.6.1 with the default case being an opaque
>> is quite similar to the extensible union construct defined in
>> draft-keiser-afs3-xdr-union; the only difference is that the
>> encoding of the currently listed 'LABEL' and 'PRIVS' cases do not
>> include a length field.  It might be nice to have afs3 and nfsv4
>
> They don't need to.  They are struct types, and may (do) have lengths
> embedded.
>
>> agree on a consistent type for the extensible union primitive,
>> though I understand that this is unlikely to happen on the timescale
>> you desire for the rpcsec-gssv3 draft.
>
> 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.

I mention it because it is equivalent to having each data branch be an 
opaque, whose contents are the encoded form of the "actual" data, and here 
the default branch is just such an opaque.

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

>> ---
>> This draft makes no mention of the use of the 'critical' bit for
>> structured privilege assertions, but does imply that the critical
>> bit will apply to any future branches that are added to the
>> rgss3_assertion_u. This strikes me as odd; at the very least it
>> could say that the critical bit is ignored.  (That's my reading of
>> what the behavior is supposed to be, from section 2.6.1.3.)
>
> Criticality can always be decided by the client based on what the server
> accepts, I suppose, so we could probably remove either the critical bit
> or the echoing of accepted assertions in the reply.  I would rather
> remove the critical bit than the latter.

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.

>> ---
>> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample
>> code on page 7?  It is not otherwise mentioned in the draft, and the
>
> Dunno.  It was never marked so in my draft.  Andy?

(This is the comment in the saple code, in the definition of enum 
rpc_gss_proc_t.)

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

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

-Ben