Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 1 Aug 2014 18:43:48 +0000

On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk <[email-masked]> wrote:

> On Wed, 30 Jul 2014, J. Bruce Fields wrote:
> 
>> On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote:
>>> Hello
>>> 
>>> I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, and he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten WG as well as to the NFSv4 WG to solicit reviews.  Please review the draft which adds two new RPCSEC GSS operations and is a normative reference to draft-ietf-nfsv4-minorversion2.
>>> 
>>> As we are working to finish draft-ietf-nfsv4-minorversion2 , please submit your reviews by Aug 31, 2014.
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3
>> 
>> I'm confused by multi-principal authentication:
> 
> Ah, good, it's not just me.
> Sorry I didn't catch this before sending my giant pile of comments.
> 
>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows
>> both parent and child's credentials.  That's easy for the parent since
>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request
>> sent as the parent.
>> 
>> For the child the caller has to calculate the mic of a nonce using the
>> child context, but as far as I can tell the choice of nonce is entirely
>> up to the caller.
>> 
>> Couldn't it then just choose as the nonce some data that it had
>> previously seen a mic for?  If so, would it work to remove the nonce and
>> instead calculate, say, a mic of the rpc header (as we do when
>> calculating the verifier?).
> 
> Certainly it would help to include (something with) the sequence number, as a proof of "liveness".  We may have to brainstorm a bit.

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'm not sure about the reply either:
>> 
>> 	On a successful reply, the rgss3_gss_mp_auth field in the
>> 	rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as
>> 	the rgmp_handle, the same rgmp_nounce as was sent in the call
>> 	data with the rgmp_nounce_mic created using the GSS-API security
>> 	context associate with the parent handle.  Verification of the
>> 	rbg_nounce_mic by the initiator demonstrates that the target
>> 	agrees to the multi-principal authentication.
>> 
>> "The target" here is ambiguous.  

Well, this is RPCSECGSS speak. There is only one target, and one initiator.  For NFS, the initiator is the client and the target is the server.

>> The reply is already authenticated as
>> the parent, the problem again is authenticating as the child

You must mean the Multi-principal “inner” handle.

There is no “child’ as the child handle is the result of the successful RPCSEC_GSS_CREATE call, and we are defining how success is determined.

>> , so I think
>> it should be calculating a mic using the child context (maybe over the
>> header data again, as in section 2.3?).

The child handle is varified on the target (server) by a successful GSS_VerifyMIC using the user-principal GSS context and the nounce. This exchange is the target 
> 
> In some sense at least, the server "owns" all the resources on it.  It could choose to hand out a user's data to the whole world if it felt like it, but we have to trust that it will not.  

Yes, true with any server at any level of security.

> In particular, the server could decline to validate the nonce-MIC at all, and grant access to anyone who claimed to be the user; we must trust that it does the verification properly.  (A proper verification confirms that the server does have a valid context handle for the inner context.)  

Correct, and that verification is noted in the sentence prior to the quote above - this obviously could be clearer. I could separate the two verifications into two paragraphs.

   The target verifies the multi-principal authentication by verifying
   the rgmp_nouce_mic.  

I can see that the following can be re-worded, and updated with a better nounce (just as Bruce suggested).

  On a successful reply, the rgss3_gss_mp_auth
   field in the rgss3_create_res reply uses the parent RPCSEC_GSSv3
   context as the rgmp_handle, the same rgmp_nounce as was sent in the
   call data with the rgmp_nounce_mic created using the GSS-API security
   context associate with the parent handle.  Verification of the
   rbg_nounce_mic by the initiator demonstrates that the target agrees
   to the multi-principal authentication.

> In that sense, this reply is just serving as a confirmation that the server accepts the multi-authentication claim, and a simple boolean would have the same effect, so long as it is authenticated.

Yes

> 
> Labels and MAC make this more interesting than the oversimplified picture I just painted, of course, and I agree that this exchange has room for improvement.
> 
>> (Also, note the draft uses at least "nonce", "nounc", and "nounce", a
>> spellcheck would help here.)

Yikes - a simple spell check is certainly not asking too much - I wlll fix this :)

—>Andy
> 
> Thank you for saying it :)
> 
> -Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 1 Aug 2014 18:46:13 +0000

On Jul 31, 2014, at 7:31 PM, J. Bruce Fields <[email-masked]> wrote:

> On Thu, Jul 31, 2014 at 07:10:18PM -0400, Benjamin Kaduk wrote:
>> Certainly it would help to include (something with) the sequence
>> number, as a proof of "liveness".  We may have to brainstorm a bit.
> 
> Maybe I'm forgetting some part of the motivation here:
> 
> 	http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-4.10.1.1
> 
> There might be something in the complete COPY protocol that makes this
> work.  Though I don't see it yet.

Yes, the use of privacy on the RPCSEC_GSS_CREATE calls due to the shared secrete being passed in the Structured Privilege assertions. 
> 
> At a minimum we could use some more explanation in this draft.

I agree we need to make Multi-principal authentication assertions secure all by itself - and not require privacy.

—>Andy
> --b.

---

From: "Adamson, Andy" <[email-masked]>
Date: Fri, 1 Aug 2014 20:28:25 +0000

On Aug 1, 2014, at 1:54 AM, Nico Williams <[email-masked]> wrote:

> On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote:
>> Hmm, this seems to have gotten rather long.  

Well, it’s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!)

>> The most important part
>> is near the top, just after the refresher on the RPCSEC_GSS
>> protocol.
> 
> I may reply in bite sizes :)
> 
>> [...]
>> Three levels of protection are provided for the RPC bodies, none,
>> integrity, and privacy.  The choice of level for this attempt at
>> this RPC, as well as a sequence number unique to this transmission,
>> are encoded into the "credential", a part of the RPC request header;
>> there is a GSS MIC over the header, so the header (and protection
>> level and sequence number) are always protected.  The request
>> payload's encoding depends on the level; for none, it is unchanged.
>> [...]
> 
> Though "none" always MICs the header.
> 
>> Multi-principal authentication
>> 
>> This draft proposes a multi-principal authentication scheme,
>> restricted to just the case of a privileged client process on a
> 
> No, not only the case of a privileged client process.

Sure, but for the Multi-principal piece we do say the following which says that the use-case is privileged client process….

   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), 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6

   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

Adamson & Williams      Expires December 29, 2014              [Page 10]
^L
Internet-Draft                    NFSv4                        June 2014

   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.

> 
> RPCSEC_GSSv3 wants to solve TWO problems:
> 
> - cache poisoning attacks on the client by the user
> - secure conveyance of privilege information for processes running with
>   more or even LESS privilege than the user normally would be accorded
> 
> Therefore we envision that RPCSEC_GSSv3 will *always* be used to
> establish security contexts on any ONC RPC client where the client can
> avail itself of a credential distinct from the user's.
> 
>> machine combining the (privileged) host's credentials with the
>> (unprivileged) user's credentials so as to take action on behalf of
>> the user.  This is a similar combination to that we are using for
>> RXGK_AFSCombineTokens (see draft-wilkinson-afs3-rxgk-afs),
> 
> Yes, it is similar to rxgk.
> 
>> restricted to just a combination of host and user credentials,
>> specifying which one is which.  I think this is the only
>> well-understood scenario for compount authentication at the moment,
>> and makes sense.
> 
> What is the antecedent of "this" here?  Did you mean that conveying
> local privilege information is not understood?
> 
>> The key material from the host's GSS context are used unchanged for
>> securing RPCs issued with the combined identity, but the opaque
>> RPCSEC_GSS context handle is changed to indicate that it represents
>> a "child" context which has the combined identity (and possibly
> 
> A new context results.
> 
>> other attributes as well, not relevant for multi-principal
>> authentication).  The creation of the child context involves sending
> 
> Yes.
> 
>> an authenticated RPC using the parent/host-credential context,
>> containing body data including a random nonce and the MIC of that
>> nonce using the "inner" context (i.e., the user's credentials).  The
>> reply contains the same nonce, but the MIC in the reply is performed
>> using the parent/host-credentials context.  The RPC to create the
>> child context is not permitted over a plaintext channel, and
>> requires either integrity protection, confidentiality+integrity
>> protection, or channel binding to a secure channel.
> 
> Eh?  No, confidentiality is neither needed nor called for for context
> establishment.
> 
>> However, I don't think this is strong enough; I think this scheme
>> requires the "privacy" level of protection.  Otherwise, an attacker
>> could replay the nonce+MIC and obtain an RPCSEC_GSS context that
>> will authenticate as the user from the "inner" context, without
>> actually proving that it possesses the user's credentials.  In
> 
> The client's credentials are required to make progress.

So you do need to be a ‘privileged client process’ - in order to use the client’s machine
credentials.

>  That stops
> replay attacks.  We need only bind things sufficiently to the new
> RPCSEC_GSS security context handle and the client credentials.

An evil user that can get root on a client machine wouldn’t need to bother with intercepting a nounce - it could simply create it’s own multi-principal RPCSEC_GSS_CREATE call because besides having access to the client host principal creds and gss_context, it also has access to all active user-principal contexts in the GSS context cache. So adding protection for the nounce is not required for the (currently only supported) case of client host principal and user-principal multi-principal authentication.

> 
> Sure, if you're not using integrity protection for the payloads then an
> attacker can hijack RPCs, but that was always true of RPCSEC_GSSv1.

> 
>> RXGK_AFSCombineTokens, we are not using (opaque) GSS credentials and
>> can explicitly combine the key material for a strong proof of
>> possession.  GSS credentials are opaque, and the GSS-API does not
>> really provide any primitives that seem applicable here. So, I would
>> recommend requiring privacy protection for this call.
> 
> I'll have to take a look (Andy produced the latest update and it's been
> a while since I've looked at RPCSEC_GSSv3), but IIRC it suffices to
> provide integrity protection.

This is the current wording:

   The client MUST use one of the following security services to protect
   the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message:

   o  rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [4])

   o  rpc_gss_svc_integrity

   o  rpc_gss_svc_privacy

> More tomorrow.

Thanks 

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

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Aug 2014 17:15:36 -0500

> Well, it’s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!)

:)

> Sure, but for the Multi-principal piece we do say the following which says that the use-case is privileged client process….

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

The conveyance of privilege (or under-privilege) is secondary, but
extremely useful.

(Was "multi-principal" my name for this?  No, I called them compound
authentication.  I prefer "compound".)

Local privilege or lack thereof is irrelevant to when compound
authentication is to be used.  The only relevant detail for that is: is
the client trusting the server's response in any way that could
compromise it or other users on the same client if the user on behalf of
which the RPC is being done could impersonate the server.  That's a
mouthful, sorry (shorter version: shared-cache).

>    unprivileged user-space program), 

That does not imply that compound contexts are only for privileged
processes.  Not at all.

> So you do need to be a ‘privileged client process’ - in order to use
> the client’s machine credentials.

No.  The client (the kernel, whatever) does it on behalf of the user.

> An evil user that can get root on a client machine wouldn’t need to
> [...]

Stop right there!  We *always* assume local security when dealing with
security protocols :)  There's no need to state this assumption.  It's
bedrock.  Kerberos, PKI, EAP, SSH, ... -- all assume local security, and
can't do anything but assume local security.

Obviously the cache poisoning problem is/can be a local security problem,
but one we can address via a protocol like this.  But we still assume
local security in that protocol.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Aug 2014 17:45:06 -0500

On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote:
> The union construct in 2.6.1 with the default case being an opaque
> is quite similar to the extensible union construct defined in
> draft-keiser-afs3-xdr-union; the only difference is that the
> encoding of the currently listed 'LABEL' and 'PRIVS' cases do not
> include a length field.  It might be nice to have afs3 and nfsv4

They don't need to.  They are struct types, and may (do) have lengths
embedded.

> agree on a consistent type for the extensible union primitive,
> though I understand that this is unlikely to happen on the timescale
> you desire for the rpcsec-gssv3 draft.

We should agree as to data model for this, but not necessarily as to
encoding.  NFS uses XDR.

> ---
> It feels a little strange to be talking about adding a way to
> specify privileges/restrictions via "assertions" onto a GSS-based

But that's what they are: the client asserting that some process local
to it is running with some privilege.  There's no way to authenticate
this as we don't and could not possibly have a credential for every set
of {user, <privs>}.

> security scheme, since GSS is philosophically more of a "request and
> check" scheme for features.  This is not a realy problem, of course,

This isn't GSS though.  It's RPSEC_GSS.  We could use GSS with naming
attributes to convey everything.  And a stackable GSS mechanism to do
compound authentication.  However, stackable GSS mechs went nowhere.

> it just takes some getting used to.  Actually, I guess it is still
> kind of "request and check", since the server only replies with the
> assertions it has accepted. Maybe this is indicative that the name
> could be more descriptive.

They aren't assertions in the send of a programming language "assert".
They are the client's assertions about local conditions, which the
client and only the client can know about.  The server's job is to
decide whether to accept those assertions considering all the context at
hand, including the compound authenticated principals.

> ---
> This draft makes no mention of the use of the 'critical' bit for
> structured privilege assertions, but does imply that the critical
> bit will apply to any future branches that are added to the
> rgss3_assertion_u. This strikes me as odd; at the very least it
> could say that the critical bit is ignored.  (That's my reading of
> what the behavior is supposed to be, from section 2.6.1.3.)

Criticality can always be decided by the client based on what the server
accepts, I suppose, so we could probably remove either the critical bit
or the echoing of accepted assertions in the reply.  I would rather
remove the critical bit than the latter.

> ---
> It seems like it would not adversely affect the document to move the
> definition of rgss3_chan_binding up to between rgss3_gss_mp_auth and
> the branches of rgss3_assertion, to match the layout of the
> rgss3_create_args structure.  Kind of minor, but helps the reader
> find things.

Channel binding is a lesser thing now that we never got RFC5660 widely
implemented (or at all).

> ---
> I think it's valid to assume that a successful call to GSS_GetMIC
> will never return a zero-length output, so the encoding of

The GSS-API never produces zero-length tokens (RFC2743 says this).

> rgss3_create_{args,res} could be reduced in size by just using an
> opaque for their respective _chan_bind_mic fields, instead of
> including the extra pointer in the type.  I don't know if there's
> enough need for space to make this worth doing, though.  There is
> some potential value in being able to easily differentiate "not
> present" from zero-length.

Good (if minor) point!

> ---
> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample
> code on page 7?  It is not otherwise mentioned in the draft, and the

Dunno.  It was never marked so in my draft.  Andy?

> ---
> And now, the minutiae:
> 
> The phrasing in section 2.3 that "RPCSEC_GSS version 3 MUST change
> the verifier" seems odd.  This is the specification of RPCSEC_GSSv3,
> [...]

Also not in my draft.

> In 2.6.1.1, the following text is a little confusing:
>    Thus a server may refuse to
>    unprivileged user-space program), or to a client acting alone (e.g.
> It makes more sense when one reads "client" to mean "in-kernel NFS
> client", but would probably be more clear if the "client is acting

This is tricky.  What's a "client"?  The TCP client?  The physical
hardware running it and the NFS client stack?  The process running the
NFS client?  Does it matter if it's in-kernel or a FUSE process, or some
micro-kernel thing?  For me the only thing that matters is if it has
access to GSS credentials that the server will understand as being a
"client's" as opposed to a "user's".

Wording this is hard, yes.

> on behalf of a user" is reworded, possibly to "on behalf of a single
> user, using only that user's credentials).  It looks like the

That's more verbose!  Yes, we need to distinguish "user with
credentials" from "user without credentials" (since identity assertions
are partly about the latter), but I think that should be clear anyways.

> "client" vs. "kernel service" distinction is fuzzy throughout the
> rest of the section, too.  I would prefer if the word "client"

We should absolutely not refer to "kernel" -- that's just an
implementation detail.  Instead we should refer to a "multi-user client"
or something of the sort.

> throughout the document referred only to "the RPC client", without
> any implications about whether the RPC client is a trusted

Yes, we could probably qualify "client" at every step, but it's not
clear what other qualifiers to use when referring to "the OS", the
"client service" (ah, maybe that's a good one), and so on.

> (in-kernel) service or a program run by the user or anything else.
> This document defines RPCSEC_GSSv3, not NFS; "client" should mean
> "RPC client", not "NFS client".

True, NFS is not the only application that could use RPCSEC_GSSv3, but
it's very likely the only one for a long time that will.

> Still on multi-principal authentication, the text says "Other
> multi-principal parent and inner context handle uses might
> eventually make sense."  It seems like any such uses would require
> standards action to specify them; you might as well also say that
> they would be introduced in a new revision of the RPCSEC_GSS
> protocol (e.g., v4).

Sure, but that's implied.  It's a forward-looking statement.  (GSS did
the same w.r.t. channel binding.)

More later.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 Aug 2014 01:47:06 -0400 (EDT)

I guess I'll split my replies amongst the existing thread instead of 
trying to reconsolidate everything.  Going in reverse order so as to try 
to avoid duplicating previous discussion...

> We should agree as to data model for this, but not necessarily as to

I think we're talking past each other.  AFS and NFS both use XDR; AFS is 
proposing to add a new fundamental data structure, in addition to the 
existing 'struct' and 'union' types.  This is a union type to which 
additional discriminant values (and corresponding data branches) may be 
added without causing existing implementations to fail to decode the 
binary data.  To do this requires that the encoded form for each branch of 
the union include a length field, for the length of the encoded form of 
the data branch.

I mention it because it is equivalent to having each data branch be an 
opaque, whose contents are the encoded form of the "actual" data, and here 
the default branch is just such an opaque.

> hand, including the compound authenticated principals.

I understand what they are.  All I am saying is that, while talking about 
"assertions" in this sense is normal for, e.g., SAML, it is not common in 
the GSS-API world.  This is an observation, not an actionable statement.

> remove the critical bit than the latter.

I don't think it's quite that cut-and-dried, as I can see cases where the 
client should be able to make non-critical requests, but also cases where 
the client should ask the server to fail the RPC if the request is not 
fulfillable.

> Dunno.  It was never marked so in my draft.  Andy?

(This is the comment in the saple code, in the definition of enum 
rpc_gss_proc_t.)

> are partly about the latter), but I think that should be clear anyways.

Hmm, I was talking about the distinction between "host with credentials" 
and "host without credentials".  Clearly there is still room for 
improvement :)

> or something of the sort.

I agree that we should not refer to "kernel"; this was intended as a 
comment about the use of the word "client" in this document and that it 
may not be appropriate in all the cases where it is currently used.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 Aug 2014 01:50:44 -0400 (EDT)

>> Well, it’s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!)

I meant "my email is getting long", not "the draft is getting long", just 
so we're clear.

>> Sure, but for the Multi-principal piece we do say the following which 
>> says that the use-case is privileged client process….
>

When I said "privileged", I mean "the thing maintaining the cache, which 
has its own credentials that are distinct from any other processes 
benefitting from the cache.

> No.  The client (the kernel, whatever) does it on behalf of the user.

I think we're actually in agreement on what's going on here, just using 
different words to describe it.

> security protocols :)  There's no need to state this assumption.  It's

Indeed, this is not the point I was trying to make.  More under separate 
cover.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 Aug 2014 02:04:31 -0400 (EDT)

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?
>
>>
> There is no “child’ as the child handle is the result of the successful 
> RPCSEC_GSS_CREATE call, and we are defining how success is determined.
>
>
>>> , so I think
> The child handle is varified on the target (server) by a successful 
> GSS_VerifyMIC using the user-principal GSS context and the nounce. This 
> exchange is the target
>>
>
>> In particular, the server could decline to validate the nonce-MIC at 
>> all, and grant access to anyone who claimed to be the user; we must 
>> trust that it does the verification properly.  (A proper verification 
>> confirms that the server does have a valid context handle for the inner 
>> context.)
>
> Correct, and that verification is noted in the sentence prior to the 
> quote above - this obviously could be clearer. I could separate the two 
> verifications into two paragraphs.
>

I'm not sure we're all on the same page about the concerns about the 
"inner" RPCSEC context handle of the multi-principal authentication.

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.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 3 Aug 2014 02:08:48 -0400 (EDT)

Yes.

> local privilege information is not understood?

"this" is the scenario wherein host credentials and user credentials are 
combined for the compound authentication.  I make no statement on local 
privilege information, rather I claim that scenarios such as combining 
user A's credentials with uesr B's credentials is not well understood.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 10:47:47 -0500

On Sun, Aug 03, 2014 at 01:47:06AM -0400, Benjamin Kaduk wrote:
> I think we're talking past each other.  AFS and NFS both use XDR;
> AFS is proposing to add a new fundamental data structure, in
> addition to the existing 'struct' and 'union' types.  This is a
> union type to which additional discriminant values (and
> corresponding data branches) may be added without causing existing
> implementations to fail to decode the binary data.  To do this
> requires that the encoded form for each branch of the union include
> a length field, for the length of the encoded form of the data
> branch.

Fair enough.

> I understand what they are.  All I am saying is that, while talking
> about "assertions" in this sense is normal for, e.g., SAML, it is
> not common in the GSS-API world.  This is an observation, not an
> actionable statement.

But this isn't GSS.  It's RPC, using GSS.  The term assertion here has
nothing to do with GSS.  What's being asserted has nothing to do with
GSS.

And incidentally, assertion in the SAML sense does fit what's happening
here.  Here the client makes assertions about the identity and/or
authorization attributes of a subject, "signs" them, and the server
decides what to do with them.

Other words can fit the bill, no doubt, but "assertion" seems best,
because it resembles the SAML usage, and because the English language
meaning of "assertion" fitst best.

> >>---
> >[...]
> 
> I don't think it's quite that cut-and-dried, as I can see cases
> where the client should be able to make non-critical requests, but
> also cases where the client should ask the server to fail the RPC if
> the request is not fulfillable.

Then you're proposing that criticality be described for the other cases
where it's provided, correct?  I agree.

> Hmm, I was talking about the distinction between "host with
> credentials" and "host without credentials".  Clearly there is still
> room for improvement :)

I'm not sure that we can have a "host without credentials" any more
since anonymous PKINIT (and equivalents for other mechanisms[*])
suffices for the purpose of protecting the client from the user.

And, obviously, in the case of a user-level, per-user inplementation of
NFSv4, there's no need for host credentials at all.

The server doesn't need to the client to use compound authentication --
that's for the client's protection.  But it may demand it in order to
grant more-than-normal privilege to the user.  Clearly anonymous client
credentials won't do in that case.  It's fair to expect that the clients
that should be authorized to have assertions honored must have
credentials!

[*] The key is that the user must not be able to determine the client's
    security contexts' session keys, even if the user is in full control
    of the wire.

> comment about the use of the word "client" in this document and that
> it may not be appropriate in all the cases where it is currently
> used.

Sure, that may be.  I'll take a look.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 10:50:45 -0500

On Sun, Aug 03, 2014 at 01:50:44AM -0400, Benjamin Kaduk wrote:
> I think we're actually in agreement on what's going on here, just
> using different words to describe it.

OK.

> Indeed, this is not the point I was trying to make.  More under
> separate cover.

I was responding to Andy :)

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 10:53:44 -0500

> >Though "none" always MICs the header.

This is important, BTW, because the RPCSEC_GSS context handle is part of
the header that gets MICed, and this is/was part of the compoung binding
as I recall envisioning it.

> "this" is the scenario wherein host credentials and user credentials
> are combined for the compound authentication.  I make no statement
> on local privilege information, rather I claim that scenarios such
> as combining user A's credentials with uesr B's credentials is not
> well understood.

Well, a user with some set of privileges might nonetheless want to
assert a subset of them without client/host credentials.  There's
nothing wrong with that.  It's the case of asserting more privilege than
normal that [generally] requires a trusted agent to vouch for the
assertion.

Nico
--

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 4 Aug 2014 12:00:16 -0400

> well-known, I didn't want to publicize it).

Oh, that's really helpful to know.

It'd be great if we could get a paragraph into the draft explaining
this.  (And also the server-to-server copy stuff, and any other example
uses.)  It's easier to understand with the motivations.

--b.

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 16:38:16 +0000

> Dunno.  It was never marked so in my draft.  Andy?

It is marked as “not used” in GSSv3 because GSSv3 provides it’s own channel binding method.

—>Andy

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 11:43:04 -0500

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

Note that such clients really need server support for this.  The only
other alternative for clients is to not share the NFSv4 cache _at all_,
but this is very difficult for some client architectures.

It's trivial for clients that can do Plan9-style namespace management,
though even then it's critical that when the system does an exec() it
doesn't trust any set-uid/gid bits from an executable's vnode.  I.e.,
it's critical that the cache not be shared even with the privilege
management parts of the system.

Even where cache non-sharing is trivial, cache sharing has significant
resource usage benefits in multi-user systems, therefore it is or can be
highly desirable.  It's worth noting that multi-user systems are
becoming less common, but multiple levels of privilege for a single
user's processes is still likely to be a common situation.

Yes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 11:44:08 -0500

> It is marked as “not used” in GSSv3 because GSSv3 provides it’s own channel binding method.

Ah, right, that's a v2 thing.  Thanks for reminding me!

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 16:55:57 +0000

On Aug 1, 2014, at 6:15 PM, Nico Williams <[email-masked]> wrote:

> authentication.  I prefer "compound”.)

Hi NIco

I changed the name from ‘compound’ to multi-principal’ in response the review comments at IETF 89 where many NFSv4 WG members expressed that ‘compound’ had too many meanings (especially in NFSv4.x) and led to confusion.

—>Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Aug 2014 13:22:22 -0400 (EDT)

> where it's provided, correct?  I agree.

I think so?  I'm not sure I understand exactly what you're saying.
The main thing I'm saying is that we define a critical bit for all types 
of rgss3_assertion, but do not specify what to set it to for one branch of 
the rgss3_assertion_u union.  That looks like what you're saying, too.

> suffices for the purpose of protecting the client from the user.

Many krb5 realms do not have PKINIT enabled on the KDC.

Yes.

Yes.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 13:07:03 -0500

On Mon, Aug 04, 2014 at 01:22:22PM -0400, Benjamin Kaduk wrote:
> The main thing I'm saying is that we define a critical bit for all
> types of rgss3_assertion, but do not specify what to set it to for
> one branch of the rgss3_assertion_u union.  That looks like what
> you're saying, too.

The critical bit is already factored out.  We should do the same for the
text.

> Many krb5 realms do not have PKINIT enabled on the KDC.

"Meh".  If they don't want PKINIT then they must key their clients.  If
they don't want to key their clients then they must enable anon PKINIT.

(Another possibility is to deploy a different mechanism for the
client<->server contexts.)

For single user systems where the user owns the system there is no need
for client credentials, and anyways, device enrolment can take care of
that.

The point is that clients can be expected to have credentials suitable
for this purpose.  I think this is quite clearly true.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 13:09:47 -0500

On Mon, Aug 04, 2014 at 04:55:57PM +0000, Adamson, Andy wrote:
> I changed the name from ‘compound’ to multi-principal’ in response
> the review comments at IETF 89 where many NFSv4 WG members expressed
> that ‘compound’ had too many meanings (especially in NFSv4.x) and
> led to confusion.

"Compound" is used as an adjective in all cases.  I don't see how
"compound authentication" (or "compound context handle", ...) is
confusable with "compound RPC".  But this isn't important enough to me;
aligning the terminology with AFS' rxgk is.  Ben, what does rxgk call
this?

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Aug 2014 14:13:20 -0400 (EDT)

> Ah, right, that's a v2 thing.  Thanks for reminding me!

Sorry if this is belaboring the point, but my reading of the text in -08 
is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to establish a 
channel over which RPCSEC_GSS_CREATE can be called, and implicitly 
disrecommends the use of this operation for any other use.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 13:45:05 -0500

On Mon, Aug 04, 2014 at 02:13:20PM -0400, Benjamin Kaduk wrote:
> Sorry if this is belaboring the point, but my reading of the text in
> -08 is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to
> establish a channel over which RPCSEC_GSS_CREATE can be called, and
> implicitly disrecommends the use of this operation for any other
> use.

 - v3 (all versions so far) permits the use of any RPCSEC_GSS context
   handle, whether a v1, v2, or v3 handle.

 - v2 handles may have been channel bound with RPCSEC_GSS_BIND_CHANNEL;
   this is implied and need not be stated, IMO.

RPCSEC_GSS_BIND_CHANNEL should be explicitly forbidden on v3 handles,
as v3 has a different mechanism for channel binding.  It is listed only
for completeness given that v3 is an extension of the earlier versions.

Do you agree?  Or did I miss the point?

Nico
--

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 18:59:27 +0000

>   handle, whether a v1, v2, or v3 handle.

No, multiple handle versions were left behind once we made v3 a proper superset of v2 (and v1). Only v3 handles allowed in v3.

>   this is implied and need not be stated, IMO.

No v2 handles

> for completeness given that v3 is an extension of the earlier versions.

Correct. This should be made more clear. When using v3 RPCSEC_GSS_BIND_CHANNEL is depricated in favor of the v3 channel binding mechanism.

—>Andy

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 14:07:17 -0500

On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote:
> No, multiple handle versions were left behind once we made v3 a proper
> superset of v2 (and v1). Only v3 handles allowed in v3.

My idea was that existing code to setup v1 contexts could be left as-is
and augmented with code that uses v1 contexts to setup v3 contexts when
compound authentication and/or assertions are required.

This would help interop: the client sets up v1 contexts, and if it can't
setup v3 contexts, then it either gives up (e.g., if it needs protection
for the shared-cache case, or if it has critical assertions to make) or
continues and hopes for the best (if it has non-critical assertions to
make).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 14:17:01 -0500

I should add that one personal motivation for v3 was "disk-less"
clients: they should be able to have access to shares they "own" as if
they had been local filesystems, but without the ability to make
arbitrary assertions about process credentials -user, group IDs,
privileges, labels- they couldn't quite get local filesystem access
control semantics.

I ran into this problem when Least Privilege integrated into Solaris,
something like 10 years ago or so.  Roughly around the same time that
(maybe a year after) I noticed the cache poisoning problem.

Without RPCSEC_GSSv3, the best a disk-less client can do w.r.t. shares
it "owns" is:

 - use AUTH_SYS, with all its limitations (no cryptographic security),
   for conveying subject process identity (user ID/group ID)

or

 - use host credentials ("root") and chown/chgrp new objects, and
   evaluate ACLs locally

Both of those options were just... awful.  The ability to securely make
arbitrary assertions, using name@domain form for identity assertions,
was my solution.  This explains the criticality design: the client can
just always make these assertions and let the server grant these for the
shares owned by the client and not for others.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Aug 2014 15:46:09 -0400 (EDT)

> The critical bit is already factored out.  We should do the same for the

Okay.  "Are you volunteering?"

> for this purpose.  I think this is quite clearly true.

I would like to live in a world where that is true.  I don't think we're 
quite in the state where we can say that this is "quite clearly" true yet, 
though.  (Consider people doing cloud deployments; provisioning a new 
image with its own credentials is a hassle unless you add your own tooling 
on top of stock kadmin.)  Anyway, I don't think this is a worthwhile topic 
for us to discuss here, and it doesn't seem very relevant to the actual 
text of the document in question.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Aug 2014 16:01:15 -0400 (EDT)

> aligning the terminology with AFS' rxgk is.  Ben, what does rxgk call

If I remember correclty from the talk from Toronto, Andy was not quite so 
keen to align with rxgk, but that may have been based on incomplete data.

Anyway, for rxgk, we don't talk very much about the actual ~compound 
token; the operation itself is CombineTokens or AFSCombineTokens, with the 
latter being the operation which is analogous to the rpcsec case.  The 
AFSCombineTokens case is a little convoluted, since rxgk-afs 
differentiates between "vlserver tokens" (roughly analogous to the MDS) 
and "fileserver tokens" (analogous to the DS).  AFSCombineTokens takes 
vlserver tokens as input and produces fileserver tokens as output, so a 
lot of the time they are just referred to as "fileserver tokens".

There are a couple places where we refer to the CombineTokens output as a 
"combined token", which is I think what you're looking for as an answer. 
That doesn't look like it translates very nicely to the rpcsec case, 
though. :(

-Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 20:37:00 +0000

> continues and hopes for the best (if it has non-critical assertions to

It’s not a big deal to negotiate GSS version at context initiation, my Linux prototype tries
v3 and falls back to v1 if it fails.
Not worrying about which context version is a win, and simplifies v3.
The new reply verifier is also a plus.

—>Andy

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Aug 2014 16:37:44 -0400 (EDT)

> continues and hopes for the best (if it has non-critical assertions to

Section 2.2 currently has:
    The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned
    by version 3 of a target with version 1 or version 2 of the same
    target.  The initiator MUST NOT attempt to use an RPCSEC_GSS handle
    returned by version 1 or version 2 of a target with version 3 of the
    same target.

which does not seem to permit this mixed-version worldview.

> for completeness given that v3 is an extension of the earlier versions.

Section 2.6 currently has:
    The client MUST use one of the following security services to protect
    the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message:

    o  rpc_gss_svc_integrity

    o  rpc_gss_svc_privacy

which does not match with the quoted statement above (I think is from 
Nico; copied from a different mail).

Note that though Section 2.6.1.4 permits rpc_gss_svc_channel_prot to be 
used by a child RPCSEC_GSSv3 handle that was created with channel 
bindings, but child handles are forbidden from being used for 
RPCSEC_GSS_CREATE calls by the last item in section 2 (aka section 2.0)

-Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 15:37:53 -0500

On Mon, Aug 04, 2014 at 03:46:09PM -0400, Benjamin Kaduk wrote:
> >The critical bit is already factored out.  We should do the same for
> >the text.
> 

I'd like to leave it to Andy for now.

> >The point is that clients can be expected to have credentials
> >suitable for this purpose.  I think this is quite clearly true.
> 
> I would like to live in a world where that is true.  I don't think
> we're quite in the state where we can say that this is "quite clearly"
> true yet, though.  (Consider people doing cloud deployments;
> provisioning a new image with its own credentials is a hassle unless
> you add your own tooling on top of stock kadmin.) Anyway, I don't
> think this is a worthwhile topic for us to discuss here, and it
> doesn't seem very relevant to the actual text of the document in
> question.

It really is true.  Provisioning is no more or less painful now than it
ever was, but since: a) truly multi-user systems generally need
server-like provisioning anyways (otherwise they couldn't authenticate
users with Kerberos!), b) anon PKINIT is available at rather low cost,
my statement is effectively true: it can be made true at low cost
anywhere that it already isn't.

Nico
--

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 20:38:36 +0000

On Aug 4, 2014, at 4:01 PM, Benjamin Kaduk <[email-masked]> wrote:

> If I remember correclty from the talk from Toronto, Andy was not quite so keen to align with rxgk, but that may have been based on incomplete data.

Well, I looked at the AFS ‘combined’ tokes, and thought they were close, but not close enough to re-use the name.

—>Andy
> 
> Anyway, for rxgk, we don't talk very much about the actual ~compound token; the operation itself is CombineTokens or AFSCombineTokens, with the latter being the operation which is analogous to the rpcsec case.  The AFSCombineTokens case is a little convoluted, since rxgk-afs differentiates between "vlserver tokens" (roughly analogous to the MDS) and "fileserver tokens" (analogous to the DS).  AFSCombineTokens takes vlserver tokens as input and produces fileserver tokens as output, so a lot of the time they are just referred to as "fileserver tokens".
> 
> There are a couple places where we refer to the CombineTokens output as a "combined token", which is I think what you're looking for as an answer. That doesn't look like it translates very nicely to the rpcsec case, though. :(
> 
> -Ben

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 15:40:17 -0500

On Mon, Aug 04, 2014 at 04:01:15PM -0400, Benjamin Kaduk wrote:
> If I remember correclty from the talk from Toronto, Andy was not
> quite so keen to align with rxgk, but that may have been based on
> incomplete data.

Well, it'd be nice to have that, but it isn't required.  rxgk's use of
"combine" is very specific to what it does, which is very different from
what RPCSEC_GSSv3 does in specifics though effectively the same, so
perhaps alignment with rxgk as to terminology would not be usefule
anyways.

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 4 Aug 2014 20:41:46 +0000

>   o  rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [4])

Yeah - thanks for the review - f rpc_gss_svc_channel_prot should also not be used. I can clean this up.

—>Andy
> 
>   o  rpc_gss_svc_integrity
> 
>   o  rpc_gss_svc_privacy
> 
> which does not match with the quoted statement above (I think is from Nico; copied from a different mail).
> 
> Note that though Section 2.6.1.4 permits rpc_gss_svc_channel_prot to be used by a child RPCSEC_GSSv3 handle that was created with channel bindings, but child handles are forbidden from being used for RPCSEC_GSS_CREATE calls by the last item in section 2 (aka section 2.0)
> 
> -Ben
> 
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Aug 2014 15:41:56 -0500

On Mon, Aug 04, 2014 at 08:37:00PM +0000, Adamson, Andy wrote:
> It’s not a big deal to negotiate GSS version at context initiation,
> my Linux prototype tries v3 and falls back to v1 if it fails.  Not
> worrying about which context version is a win, and simplifies v3.  The
> new reply verifier is also a plus.

OK, fair enough.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Aug 2014 11:31:50 -0400 (EDT)

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:

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