Subject: [nfsv4] I-D Action: draft-ietf-nfsv4-rpcsec-gssv3-16.txt

From: [email-masked]
Date: Thu, 21 Jan 2016 11:10:52 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network File System Version 4 Working Group of the IETF.

        Title           : Remote Procedure Call (RPC) Security Version 3
        Authors         : William A. (Andy) Adamson
                          Nico Williams
	Filename        : draft-ietf-nfsv4-rpcsec-gssv3-16.txt
	Pages           : 23
	Date            : 2016-01-21

Abstract:
   This document specifies version 3 of the Remote Procedure Call (RPC)
   security protocol (RPCSEC_GSS).  This protocol provides support for
   multi-principal authentication of client hosts and user principals to
   a server (constructed by generic composition), security label
   assertions for multi-level and type enforcement, structured privilege
   assertions, and channel bindings.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpcsec-gssv3-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 23 Jan 2016 14:47:38 -0500 (EST)

> https://www.ietf.org/rfcdiff?url2=draft-ietf-nfsv4-rpcsec-gssv3-16

The change in this version that is attempting to remediate the issue
raised by Nico is:

OLD:
A MIC of the RPC call header up to and including the credential is
computed using the GSS-API security context associated with the inner
context handle and is placed in rgmp_rpcheader_mic field.

NEW:
A MIC of the RPC call header up to and including the credential plus the
GSS security mechanism client host principal name is computed using the
GSS-API security context associated with the inner context
handle and is placed in rgmp_rpcheader_mic field.

Unfortunately, I do not think this is sufficient to produce interoperable
implementations.  Is "plus the [principal name]" supposed to mean that I
put it at the beginning, the end or in the middle.  Furthermore (and more
problematic), GSS name objects have a lot of moving parts and different
representations.  In order to get all the pieces lined up, something like
this would be needed, I think: "a GSS name identifying the client host is
constructed, of type GSS_C_NT_HOSTBASED_SERVICE, converted to a mechanism
name for the GSS mechanism in use with GSS_Canonicalize_name(), then
converted to wire format with GSS_Export_name().  The resulting octet
string is included in the MIC."

Given the extra complications, I would suggest a more explicit description
of the input to the MIC operation than the running prose currently used.

-Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Mon, 25 Jan 2016 15:48:50 +0000

> On Jan 23, 2016, at 2:47 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

I see your point. Is this acceptable?

—>Andy

NEW:

A MIC is computed using the GSS-API security context associated with 
the inner context handle over the RPC call header 
up to and including the credential directly followed by a GSS name 
identifying the client host labeled the “gss_client_host_name” below in 
figure X.  The MIC is placed in the rgmp_rpcheader_mic field.

The gss_client_hosname is a name of type 
GSS_C_NT_HOSTBASED_SERVICE that is converted to a mechanism 
name for the GSS mechanism in use with  GSS_Canonicalize_name(), 
and then converted to wire format with GSS_Export_name().

rgmp_rpcheader_mic is computed over the following data:
   
  unsigned int xid;
  msg_type mtype;    /* set to CALL */
  unsigned int rpcvers;
  unsigned int prog;
  unsigned int vers;
  unsigned int proc;
  opaque_auth  cred; /* captures the RPCSEC_GSS handle */
  opaque gss_client_hostname; 

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Jan 2016 19:36:15 -0500 (EST)

> I see your point. Is this acceptable?

That's much better (though the RFC Editor will want to tweak the grammar
a bit, I'm sure).  Just a couple notes inline.

> identifying the client host labeled the “gss_client_host_name” below in

I hope it is clear from context that figure X is the XDR for the structure
in question, but maybe it should be said explicitly.

> figure X.  The MIC is placed in the rgmp_rpcheader_mic field.

The rgmp_rpcheader_mic field is in a different structure than what the
previous sentence was talking about, so it's probably best to call it out
at "the rgmp_rpcheader_mic field of struct XXX".

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Jan 2016 21:10:33 -0500 (EST)

> >   opaque gss_client_hostname;

I guess it should be noted that the gss_client_hostname is not necessarily
a multiple of four octets, and the input to the MIC should include the
zero-padding to retain the mandatory XDR alignment.  (Or don't include it;
I don't really care, but it should be specified one way or the other.)

-Ben

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 26 Jan 2016 16:32:42 +0000

> On Jan 25, 2016, at 9:10 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

In my GSSv3 prototype, I have so far been able to avoid an expensive upcall to handle RPCSEC_GSS_CREATE payloads.  Since neither GSS_Canonicalize_name() nor GSS_Export_name is typically available in the kernel, I would like to consider Nico’s other suggestion, the use of privacy protection for multi-principal authentication payloads.

—>Andy

--- On Jan 11, 2016, at 8:01 PM, Nico Williams <[email-masked]> wrote: —

There are two fixes, the simplest of which is to require that the
RPCSEC_GSS_CREATE procedure be called with privacy protection when using
the multi-principal authentication feature.

——

OLD - from draft-16

         Multi-principal binding is done by including an assertion of
          type rgss3_gss_mp_auth in the RPCSEC_GSS_CREATE rgss3_create_args
          call data. The inner context handle is placed in the rgmp_handle
          field.  A MIC of the RPC call header up to and including the
          credential plus the GSS security mechanism client host
          principal name is computed using the GSS-API security context
          associated with the inner context handle and is placed in
          rgmp_rpcheader_mic field.

NEW - modified draft-15 text

   Multi-principal binding is done by including an assertion of type
   rgss3_gss_mp_auth in the RPCSEC_GSS_CREATE rgss3_create_args call
   data.  The inner context handle is placed in the rgmp_handle field.
   A MIC of the RPC call header up to and including the credential is
   computed using the GSS-API security context associated with the inner
   context handle and is placed in rgmp_rpcheader_mic field.
  Note that the rgmp_rpcheader_mic only identifies the client host GSS 
  context by it’s context handle (the parent context handle) in the rpc header.

  An RPCSEC_GSS_CREATE control procedure with a multi-principal
  authentication payload MUST use the rpc_gss_svc_privacy security
  service for protection. This is to prevent an attacker from intercepting
  the RPCSEC_GSS_CREATE control procedure, re-assigning the
  (parent) context handle, and stealing the user’s identity