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

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

On Wed, Sep 03, 2014 at 02:39:29PM -0500, Nico Williams wrote:
> On Wed, Sep 3, 2014 at 2:28 PM, J. Bruce Fields <[e-mail]> wrote:
> > 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?
> 
> Inner.  The one authenticating the user.
> 
> > So the server will reject my attempt above because the inner context is
> > associated with a different clientid than the outer context?
> 
> Yes: because the inner security context is not known in ... this
> context (English sense of the word).
> 
> > I'm not even sure what it means for a gss context to be tied to a client
> > ID.
> 
> To a session, connection, ...  Maybe I assumed too much about that?
> I'd have to go look at Illumos source to see if maybe I was led astray
> by that.  It's been a while.

A gss context is created by an INIT_SEC_CONTEXT call before it's ever
used with any particular NFS client (do we even know it's necessarily
going to be used for NFS at that point?).

Then it may be used for some NFS RPC call, which may or may not be
associated with a client id.

So I guess you'd want the rules to be that a gss context is either tied
to a client id or not, that the first RPC call referring to some
clientid or sessionid ties the context to a client, at which point it's
forbidden from being associated to any other client, and that only
contexts tied to client id's can be used in CREATE calls?

This all seems a little ad-hoc.  And it mixes up the RPC and NFS layers
in ways I'm not sure I understand.

> > Maybe I'm just dense, but at a minimum I think this needs a much more
> > careful explanation.
> 
> I agree.
> 
> >> 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?
> 
> There should be a bit more structure to it to prevent aliasing, and
> the server could be the source of the nonce (adding a round-trip) or
> we could add more to the message to be MICed (e.g., the client ID).

Sounds like there's work to do.

--b.