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

[Nico Williams <[e-mail]>]

On Sun, Aug 03, 2014 at 02:08:48AM -0400, Benjamin Kaduk wrote:
> On Fri, 1 Aug 2014, Nico Williams wrote:
> 
> >>Three levels of protection are provided for the RPC bodies, none,
> >>integrity, and privacy.  The choice of level for this attempt at
> >>this RPC, as well as a sequence number unique to this transmission,
> >>are encoded into the "credential", a part of the RPC request header;
> >>there is a GSS MIC over the header, so the header (and protection
> >>level and sequence number) are always protected.  The request
> >>payload's encoding depends on the level; for none, it is unchanged.
> >>[...]
> >
> >Though "none" always MICs the header.
> 
> Yes.

This is important, BTW, because the RPCSEC_GSS context handle is part of
the header that gets MICed, and this is/was part of the compoung binding
as I recall envisioning it.

> >>restricted to just a combination of host and user credentials,
> >>specifying which one is which.  I think this is the only
> >>well-understood scenario for compount authentication at the moment,
> >>and makes sense.
> >
> >What is the antecedent of "this" here?  Did you mean that conveying
> >local privilege information is not understood?
> 
> "this" is the scenario wherein host credentials and user credentials
> are combined for the compound authentication.  I make no statement
> on local privilege information, rather I claim that scenarios such
> as combining user A's credentials with uesr B's credentials is not
> well understood.

Well, a user with some set of privileges might nonetheless want to
assert a subset of them without client/host credentials.  There's
nothing wrong with that.  It's the case of asserting more privilege than
normal that [generally] requires a trusted agent to vouch for the
assertion.

Nico
--