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

[Benjamin Kaduk <[e-mail]>]

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

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