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

[Nico Williams <[e-mail]>]

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.

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

Nico
--