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

["J. Bruce Fields" <[e-mail]>]

On Wed, Sep 03, 2014 at 01:32:46PM -0500, Nico Williams wrote:
> On Wed, Sep 3, 2014 at 12:47 PM, J. Bruce Fields <[e-mail]> wrote:
> > Sorry, I haven't been thinking about this, I'm probably confused, but I
> > think I was imagining an attack something like:
> >
> >         - I, a rogue client, sniff some random krb5 traffic from the
> >           user.
> >         - That traffic includes at least one (rpc header, mic of rpc
> >           header) pair.
> >         - I send a CREATE call using that rpc header as the nonce data.
> >
> > ?
> 
> It almost works, but remember, the server must have the security
> context to verify the MIC with, and that context will have to be tied
> to the same NFSv4 client ID (same session).

Argh, I'm totally confused.

Which context (inner or outer) is "the security context" in the above?

So the server will reject my attempt above because the inner context is
associated with a different clientid than the outer context?

I'm not even sure what it means for a gss context to be tied to a client
ID.

Maybe I'm just dense, but at a minimum I think this needs a much more
careful explanation.

> Oh, but maybe some servers have a global RPCSEC_GSS context handle?
> If so, that would be a problem.  In that case the server could pick
> the nonce.  Or the MIC could be taken over more content (e.g., also a
> MIC made with the client context).  Just in case, this would be a good
> change to make.

Fundamentally the (nonce, mic) pair here looks meaningless.  The network
is presumably already full of (data, mic(data)) pairs using this
context, what does it prove that you can supply me with one when you get
to choose the data?

--b.