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

[Nico Williams <[e-mail]>]

On Fri, Aug 01, 2014 at 08:28:25PM +0000, Adamson, Andy wrote:
> On Aug 1, 2014, at 1:54 AM, Nico Williams <[e-mail]> wrote:
> > On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote:
> >> Hmm, this seems to have gotten rather long.  
> 
> Well, it’s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!)

:)

> >> Multi-principal authentication
> >> 
> >> This draft proposes a multi-principal authentication scheme,
> >> restricted to just the case of a privileged client process on a
> > 
> > No, not only the case of a privileged client process.
> 
> Sure, but for the Multi-principal piece we do say the following which says that the use-case is privileged client process….

It was always my intention that traditional (read: multi-user
shared-cache) NFS client implementations would just always use
"multi-principal" contexts when doing any RPCs on a user's behalf.

That is, addressing the "user can impersonate the server to the client"
problem was always my first and foremost goal with this protocol, though
I didn't always say so explicitly (since at the time the attack was not
well-known, I didn't want to publicize it).

The conveyance of privilege (or under-privilege) is secondary, but
extremely useful.

(Was "multi-principal" my name for this?  No, I called them compound
authentication.  I prefer "compound".)

Local privilege or lack thereof is irrelevant to when compound
authentication is to be used.  The only relevant detail for that is: is
the client trusting the server's response in any way that could
compromise it or other users on the same client if the user on behalf of
which the RPC is being done could impersonate the server.  That's a
mouthful, sorry (shorter version: shared-cache).

>    RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of
>    the client host principal and a user principal.  This feature is
>    needed, for example, when a client wishes to use authority assertions
>    that the server may only grant if a user and a client are
>    authenticated together to the server.  Thus a server may refuse to
>    grant requested authority to a user acting alone (e.g., via an
>    unprivileged user-space program), 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6

That does not imply that compound contexts are only for privileged
processes.  Not at all.

> >> However, I don't think this is strong enough; I think this scheme
> >> requires the "privacy" level of protection.  Otherwise, an attacker
> >> could replay the nonce+MIC and obtain an RPCSEC_GSS context that
> >> will authenticate as the user from the "inner" context, without
> >> actually proving that it possesses the user's credentials.  In
> > 
> > The client's credentials are required to make progress.
> 
> So you do need to be a ‘privileged client process’ - in order to use
> the client’s machine credentials.

No.  The client (the kernel, whatever) does it on behalf of the user.

> >  That stops
> > replay attacks.  We need only bind things sufficiently to the new
> > RPCSEC_GSS security context handle and the client credentials.
> 
> An evil user that can get root on a client machine wouldn’t need to
> [...]

Stop right there!  We *always* assume local security when dealing with
security protocols :)  There's no need to state this assumption.  It's
bedrock.  Kerberos, PKI, EAP, SSH, ... -- all assume local security, and
can't do anything but assume local security.

Obviously the cache poisoning problem is/can be a local security problem,
but one we can address via a protocol like this.  But we still assume
local security in that protocol.

Nico
--