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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 2 Sep 2014 13:13:06 -0400 (EDT)

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.

-Ben

On Wed, 20 Aug 2014, Benjamin Kaduk wrote:

> I'm starting a new thread for this, since I think it is the most important
> item revealed by my review, but it seems to have been lost amidst the
> other discussions.
>
> On Sun, 3 Aug 2014, Benjamin Kaduk wrote:
>
> > On Fri, 1 Aug 2014, Adamson, Andy wrote:
> >
> > >
> > > I have always thought of Multi-principal authentication in terms of it’s use
> > > in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_CREATE
> > > messages MUST use rpc_gss_svc_privacy’…. Good catch Bruce.
> > >
> > > So for this attack to occur the rgmp_nonce must be re-used by the same
> > > rgmp_handle (same user-principal). Insisting on using a random number
> > > generator to create nounce could be by-passed by a bad implementation...
> > >
> > > Bruces suggestion of using the new reply verifier data (rpc-header) should
> > > do the trick. Any objections to this approach?
>
> I don't think I correctly understand this proposal.  Can someone try to
> explain it in more detail, please?
>
> > If I understand correctly, the child RPCSEC contex handle will use the same
> > GSS context as the parent RPCSEC context handle (i.e., using the host's
> > credentials, not the user's credentials).  This means that when creating the
> > child RPCSEC context, there must be some proof that the RPC client controls
> > the GSS context corresponding to the inner RPCSEC context handle, since the
> > child RPCSEC context will perform operations acting as the user specified by
> > the GSS context of the inner RPCSEC context.
> >
> > My reading of the current draft is that the only attempt to do this is by
> > presenting a random nonce and a GSS_GetMIC of that nonce, created using the
> > GSS context of the inner RPCSEC context.  The server must verify that the MIC
> > is a valid mic, but I do not see any other binding to this GSS context.  In
> > particular, the nonce+MIC could be eavesdropped on the wire, and inserted into
> > an attacker's RPCSEC_GSS_CREATE call, where the attacker provides its own
> > parent RPCSEC context but does not actually have an inner context at all.  The
> > attacker can reuse the valid nonce+MIC that it has intercepted, which will
> > validate correctly on the server, and the server will issue a child RPCSEC
> > context that acts as the user indicated by the GSS context of the inner RPCSEC
> > context but uses the key material from the attacker's GSS context.
>
> Basically, my reading is that the triple of (opaque inner handle, nonce,
> mic) is a bearer token that is valid as long as the inner rpcsec context
> is valid, as specified in the -08.  The inner handle is only used to
> lookup the GSS security context to use to verify the MIC of the nonce, so
> if all three are passed together, there is no binding to anything else
> that I can see.
>
> An attacker who gets a copy of this bearer token could then use it to
> create its own child context from a parent context that the attacker
> controls, and perform actions as the user corresponding to the GSS
> security context of the inner context handle.
>
> -Ben

---

From: Nico Williams <[email-masked]>
Date: Tue, 2 Sep 2014 23:12:41 -0500

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

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

 - 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
       - verifier
          - MIC taken over the header (minus verifier) with the old outer
            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).

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.

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.

Nico
--

---

From: "Adamson, Andy" <[email-masked]>
Date: Wed, 3 Sep 2014 16:34:45 +0000

> performing multi-principal authentication.

Hi Ben 

Vacation. Thanks for the review. Comments inline...
>>> parent RPCSEC context

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

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.

—>Andy

>>> but does not actually have an inner context at all.  The

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 3 Sep 2014 13:47:41 -0400

> perhaps, but the client would have to pick that same nonce, so, not

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.

?

--b.

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 13:32:46 -0500

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

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.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 3 Sep 2014 15:28:55 -0400

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

> MIC made with the client context).  Just in case, this would be a good

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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Sep 2014 15:34:48 -0400 (EDT)

>    made with the user's context.  Both contexts having the same

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

>    context as the outer message in the establishment (see above) of this

Check.

>        - program, procedure, XID

This part is, I think, the problem.

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

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

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

> perhaps, but the client would have to pick that same nonce, so, not

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

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 14:39:29 -0500

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

Inner.  The one authenticating the user.

> 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

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

I agree.

> context, what does it prove that you can supply me with one when you get

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 3 Sep 2014 15:49:05 -0400

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

> we could add more to the message to be MICed (e.g., the client ID).

Sounds like there's work to do.

--b.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Sep 2014 16:51:51 -0400 (EDT)

> Vacation. Thanks for the review. Comments inline...

Ah, understood.  Hope it was relaxing :)

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 3 Sep 2014 16:54:17 -0400 (EDT)

> in ways I'm not sure I understand.

I agree; it doesn't feel like a good path forward (but I do believe it
would solve the problems we are worried about).

I agree.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 3 Sep 2014 16:17:30 -0500

>> Sounds like there's work to do.

I agree.  I wrote this eons ago and never got to implement.

Multi-principal authentication is critical for security on multi-user
clients.  We should get it right.

Nico
--

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 4 Sep 2014 11:57:43 +0000

> clients.  We should get it right.

Yes. But! If we add more structure to prevent aliasing - e.g. attach it to a client machine (or clientid) then it will prevent it’s use in NFSv4.2 Inter server to server copy where the user principal on one client machine is permitting another client (the destination server acting as a client) to act on it’s behalf.

I say we keep the current nonce and simply insist on privacy. This will prevent aliasing and yet allow ti’s only current use case.

—>Andy
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Sep 2014 10:33:46 -0500

> Yes. But! If we add more structure to prevent aliasing - e.g. attach it to a client machine (or clientid) then it will prevent it’s use in NFSv4.2 Inter server to server copy where the user princip…

Huh?   I don't see the connection.

> I say we keep the current nonce and simply insist on privacy. This will prevent aliasing and yet allow ti’s only current use case.

That's too risky.

---

From: "Adamson, Andy" <[email-masked]>
Date: Thu, 4 Sep 2014 16:37:51 +0000

On Sep 4, 2014, at 11:33 AM, Nico Williams <[email-masked]> wrote:

>> Yes. But! If we add more structure to prevent aliasing - e.g. attach it to a client machine (or clientid) then it will
                              ^^^
should be “could” not necessarily “will"

>> prevent it’s use in NFSv4.2 Inter server to server copy where the user principal on one client machine is permitting another client (the destination server acting as a client) to act on it’s behalf.
> 

Have you read the NFSv4.2 use of GSSv3 for inter server to server copy? The destination server (acting as an NFS client) needs to READ the file from the source server.  It needs to do so on behalf of the user-principal that starts the copy from the client. The destination server does not have a GSS context for the user-principal, as the user is logged onto the client, not the destination server.  The multi-principal nonce, MIC of nonce using the user-principal context is created on the client and sent with the user-principal context handle in a privacy protected structured privilege to the detination server which then uses it in a privacy protected multi-principal (plus structured privilege) assertion to the source server.

If the multi-principal nonce was replaced by data that tied the multi-principal use to a client machine, then in the above passing of the multi-principal data from the inter server to server client to the destination server (to allow the destination server to act on behalf of the user-principal) would not work.

In essence, NFSv4.2 inter server to server copy’s use of multi-principal assertion is aliasing.

>> I say we keep the current nonce and simply insist on privacy. This will prevent aliasing and yet allow ti’s only current use case.

Perhaps we allow a multi-principal aliasing mode.

—>Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 5 Sep 2014 16:02:45 -0400 (EDT)

On Mon, 4 Aug 2014, Nico Williams wrote:

> On Mon, Aug 04, 2014 at 12:00:16PM -0400, J. Bruce Fields wrote:
> > On Fri, Aug 01, 2014 at 05:15:36PM -0500, Nico Williams wrote:
> > > It was always my intention that traditional (read: multi-user
> > > shared-cache) NFS client implementations would just always use
> > > "multi-principal" contexts when doing any RPCs on a user's behalf.
> > >
> > > That is, addressing the "user can impersonate the server to the client"
> > > problem was always my first and foremost goal with this protocol, though
> > > I didn't always say so explicitly (since at the time the attack was not
> > > well-known, I didn't want to publicize it).
> >
> > Oh, that's really helpful to know.
>
> Yeah :(  I mentioned it several times at meetings.  The cat has been
> out of the bag for a long time as to the vulnerability for shared-cache
> clients, so we might as well state this motivation clearly.

I don't remember seeing new text clarifying the potential attack going by,
so I'll note that what we did for rxgk is in section 7 of
https://tools.ietf.org/html/draft-wilkinson-afs3-rxgk-afs-06

-Ben