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

[Benjamin Kaduk <[e-mail]>]

On Wed, 3 Sep 2014, Nico Williams wrote:

> On Tue, Sep 02, 2014 at 01:13:06PM -0400, Benjamin Kaduk 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.
>
> Sorry, let's look at this:
>
>  - As I had it the client sends an integrity-protected message that
>    contains a MIC of a nonce.  The outer message is protected by a GSS
>    security context authenticating the client host.  The inner MIC is
>    made with the user's context.  Both contexts having the same
>    acceptor.

Check.  The inner mic is an ordinary GSS_GetMic(), correct?

>  - The *new* RPCSEC_GSS security context uses the same GSS security
>    context as the outer message in the establishment (see above) of this
>    new context.

Check.

>  - When the client sends an RPC on behalf of a user, then, it sends
>    something like (simplifying):
>
>     - RPC header:
>        - program, procedure, XID
>        - credential
>           - *new* context ID

This part is, I think, the problem.

>        - verifier
>           - MIC taken over the header (minus verifier) with the old outer
>             context

(I don't think 'old' is needed here; it's just the outer GSS context.)

>     - payload (possibly wrapped)
>
> There's no bearer token here.  There's nothing in the credential or
> verifier that a man in the wire can use to replay against the server and
> get the same rights with a different payload (well, assuming we're
> providing at least integrity protection to the payload).

I don't think that there's a bearer token used to authenticate RPCs on
behalf of a user.

I think that the process of obtaining a new/child context ID involves a
bearer token that identifies the user which will be associated with the
child context.

The message to obtain the child context ID is integrity protected, but if
I have my own credentials to make my own parent context, and I can read
the contents of the RPCSEC_GSS_CREATE request, I can make my own
RPCSEC_GSS_CREATE request that contains the handle ID, nonce, and mic that
I observed over the wire.  So, I guess the question becomes, does the
server do anything to verify that the inner handle ID is associated with
the connection/peer that the server is currently talking to.

> The man in the wire would have to be able to manufacture a MIC and Wrap
> tokens without having the related security context's session keys.
>
> Could an attacker find a MIC made with a context authenticating the user
> (to the same acceptor) of a payload that looks like a nonce?  Yes,
> perhaps, but the client would have to pick that same nonce, so, not
> really.

If the attacker has their own (rpcsec) client, they can choose whatever
nonce they want.

-Ben

> OK, now let's see if the same is true for the current draft.  [reads]
>
> This section of the draft got rewritten, but my reading is that the gist
> is the same.