Re: [kitten] rpcsec-gssv3 multi-principal authentication

["Adamson, Andy" <[e-mail]>]

On Sep 2, 2014, at 1:13 PM, Benjamin Kaduk <[e-mail]> wrote:

> It would be nice if someone could confirm or contradict my conclusion that
> the triple of (opaque inner handle, nonce, mic) is a bearer token for
> performing multi-principal authentication.
> 
> -Ben

Hi Ben 

Vacation. Thanks for the review. Comments inline...
> 
> On Wed, 20 Aug 2014, Benjamin Kaduk wrote:
> 
>> I'm starting a new thread for this, since I think it is the most important
>> item revealed by my review, but it seems to have been lost amidst the
>> other discussions.
>> 
>> On Sun, 3 Aug 2014, Benjamin Kaduk wrote:
>> 
>>> On Fri, 1 Aug 2014, Adamson, Andy wrote:
>>> 
>>>> 
>>>> 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?
>> 
>> I don't think I correctly understand this proposal.  Can someone try to
>> explain it in more detail, please?
>> 
>>> 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

draft-08 section 2.6.1.1.  Multi-principal Authentication

   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), 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 is assumed that an unprivileged user-space program would not have
   access to client host credentials needed to establish a GSS-API
   security context authenticating the client to the server, therefore
   an unprivileged user-space program could not create an RPCSEC_GSSv3
   RPCSEC_GSS_CREATE message that successfully binds a client and a user
   security context.

I believe the above last paragraph addresses this issue.  Do we need to make this section stronger, or perhaps clarify?

Indeed, an attacker that has it’s own parent RPCSEC context ( e.g. a proveable client machine-credential context ) can have her way.

This is nothing new as an attacker with such a context has ‘root’ for that machine in the RPCSEC world and can do a whole bunch of mischief :)

That said, I suppose we could replace the nonce with the RPCSEC_GSS_CREATE reply verifier data and prevent such an attacker from acting on behalf of a user.

—>Andy


>>> 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.
>> 
>> Basically, my reading is that the triple of (opaque inner handle, nonce,
>> mic) is a bearer token that is valid as long as the inner rpcsec context
>> is valid, as specified in the -08.  The inner handle is only used to
>> lookup the GSS security context to use to verify the MIC of the nonce, so
>> if all three are passed together, there is no binding to anything else
>> that I can see.
>> 
>> An attacker who gets a copy of this bearer token could then use it to
>> create its own child context from a parent context that the attacker
>> controls, and perform actions as the user corresponding to the GSS
>> security context of the inner context handle.
>> 
>> -Ben