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

["Adamson, Andy" <[e-mail]>]

On Aug 1, 2014, at 1:54 AM, Nico Williams <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4