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

[Benjamin Kaduk <[e-mail]>]

On Fri, 1 Aug 2014, Nico Williams wrote:

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

I meant "my email is getting long", not "the draft is getting long", just 
so we're clear.

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

When I said "privileged", I mean "the thing maintaining the cache, which 
has its own credentials that are distinct from any other processes 
benefitting from the cache.

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

I think we're actually in agreement on what's going on here, just using 
different words to describe it.

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

Indeed, this is not the point I was trying to make.  More under separate 
cover.

-Ben