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

[Benjamin Kaduk <[e-mail]>]

On Fri, 1 Aug 2014, Adamson, Andy wrote:

>
> On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk <[e-mail]> wrote:
>
>> On Wed, 30 Jul 2014, J. Bruce Fields wrote:
>>
>>
>>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows
>>> both parent and child's credentials.  That's easy for the parent since
>>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request
>>> sent as the parent.
>>>
>>> For the child the caller has to calculate the mic of a nonce using the
>>> child context, but as far as I can tell the choice of nonce is entirely
>>> up to the caller.
>>>
>>> Couldn't it then just choose as the nonce some data that it had
>>> previously seen a mic for?  If so, would it work to remove the nonce and
>>> instead calculate, say, a mic of the rpc header (as we do when
>>> calculating the verifier?).
>>
>> Certainly it would help to include (something with) the sequence 
>> number, as a proof of "liveness".  We may have to brainstorm a bit.
>
> I have always thought of Multi-principal authentication in terms of it’s 
> use in NFSv4.2 Inter server to server copy, where all of the 
> RPCSEC_GSS_CREATE messages MUST use rpc_gss_svc_privacy’…. Good catch 
> Bruce.
>
> So for this attack to occur the rgmp_nonce must be re-used by the same 
> rgmp_handle (same user-principal). Insisting on using a random number 
> generator to create nounce could be by-passed by a bad implementation...
>
> Bruces suggestion of using the new reply verifier data (rpc-header) 
> should do the trick. Any objections to this approach?
>
>>
>>> The reply is already authenticated as
>>> the parent, the problem again is authenticating as the child
>
> You must mean the Multi-principal “inner” handle.
>
> There is no “child’ as the child handle is the result of the successful 
> RPCSEC_GSS_CREATE call, and we are defining how success is determined.
>
>
>>> , so I think
>>> it should be calculating a mic using the child context (maybe over the
>>> header data again, as in section 2.3?).
>
> The child handle is varified on the target (server) by a successful 
> GSS_VerifyMIC using the user-principal GSS context and the nounce. This 
> exchange is the target
>>
>
>> In particular, the server could decline to validate the nonce-MIC at 
>> all, and grant access to anyone who claimed to be the user; we must 
>> trust that it does the verification properly.  (A proper verification 
>> confirms that the server does have a valid context handle for the inner 
>> context.)
>
> Correct, and that verification is noted in the sentence prior to the 
> quote above - this obviously could be clearer. I could separate the two 
> verifications into two paragraphs.
>
>   The target verifies the multi-principal authentication by verifying
>   the rgmp_nouce_mic.

I'm not sure we're all on the same page about the concerns about the 
"inner" RPCSEC context handle of the multi-principal authentication.

If I understand correctly, the child RPCSEC contex handle will use the 
same GSS context as the parent RPCSEC context handle (i.e., using the 
host's credentials, not the user's credentials).  This means that when 
creating the child RPCSEC context, there must be some proof that the RPC 
client controls the GSS context corresponding to the inner RPCSEC context 
handle, since the child RPCSEC context will perform operations acting as 
the user specified by the GSS context of the inner RPCSEC context.

My reading of the current draft is that the only attempt to do this is by 
presenting a random nonce and a GSS_GetMIC of that nonce, created using 
the GSS context of the inner RPCSEC context.  The server must verify that 
the MIC is a valid mic, but I do not see any other binding to this GSS 
context.  In particular, the nonce+MIC could be eavesdropped on the wire, 
and inserted into an attacker's RPCSEC_GSS_CREATE call, where the attacker 
provides its own parent RPCSEC context but does not actually have an inner 
context at all.  The attacker can reuse the valid nonce+MIC that it has 
intercepted, which will validate correctly on the server, and the server 
will issue a child RPCSEC context that acts as the user indicated by the 
GSS context of the inner RPCSEC context but uses the key material from the 
attacker's GSS context.

-Ben