[kitten] rpcsec-gssv3 multi-principal authentication

[Benjamin Kaduk <[e-mail]>]

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