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

[Benjamin Kaduk <[e-mail]>]

On Wed, 3 Sep 2014, Adamson, Andy wrote:

>
> On Sep 2, 2014, at 1:13 PM, Benjamin Kaduk <[e-mail]> wrote:
>
> Hi Ben
>
> Vacation. Thanks for the review. Comments inline...

Ah, understood.  Hope it was relaxing :)

>
> draft-08 section 2.6.1.1.  Multi-principal Authentication
>
>    RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of
>    the client host principal and a user principal.  This feature is
>    needed, for example, when a client wishes to use authority assertions
>    that the server may only grant if a user and a client are
>    authenticated together to the server.  Thus a server may refuse to
>    grant requested authority to a user acting alone (e.g., via an
>    unprivileged user-space program), or to a client acting alone (e.g.
>    when a client is acting on behalf of a user) but may grant requested
>    authority to a client acting on behalf of a user if the server
>    identifies the user and trusts the client.
>
>    It is assumed that an unprivileged user-space program would not have
>    access to client host credentials needed to establish a GSS-API
>    security context authenticating the client to the server, therefore
>    an unprivileged user-space program could not create an RPCSEC_GSSv3
>    RPCSEC_GSS_CREATE message that successfully binds a client and a user
>    security context.
>
> I believe the above last paragraph addresses this issue.  Do we need to
> make this section stronger, or perhaps clarify?
>
> Indeed, an attacker that has it’s own parent RPCSEC context ( e.g. a
> proveable client machine-credential context ) can have her way.
>
> This is nothing new as an attacker with such a context has ‘root’ for
> that machine in the RPCSEC world and can do a whole bunch of mischief :)

I'm not considering the same machine; I'm thinking about a different
machine.  Maybe I can be more clear with an explicit example using NFS,
instead of talking about rpcsec-gss in the abstract.

Alice is a mortal user on machine A, and machine A runs an NFS client.
Machine A has its secure host-specific credentials (nfs/A@REALM or
host/A@REALM or whatever), and Alice has credentials for alice@REALM.
Eve doesn't even have an account on machine A, but has root on machine B,
which also has host-specific credentials (host/B@REALM), and Eve can spy
on the NFS traffic between A and the NFS server (call it S).
A's NFS client has to do an RPCSEC_GSS_CREATE RPC to be able to act as
Alice.  My claim is that Eve can see the network traffic from that RPC
(just the request; the reply should not be needed), and use an evil NFS
client on her machine B, to make her own RPCSEC_GSS_CREATE request, that
contains the same rca_mp_auth field as the RPC from A, and with the result
of that RPC, Eve's NFS client has an rpcsec-gss context handle that lets
Eve read and write files as alice@REALM.


> That said, I suppose we could replace the nonce with the
> RPCSEC_GSS_CREATE reply verifier data and prevent such an attacker from
> acting on behalf of a user.

Hmm, if the verifier is signed using the outer context's GSS context, that
might be enough to produce the required binding.  I would need to think
about it more.

-Ben