Re: [nfsv4] binding user credentials to client host in draft-ietf-nfsv4-rpcsec-gssv3-16

> On Jan 23, 2016, at 2:47 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
> 
> On Thu, 21 Jan 2016, internet-drafts@ietf.org wrote:
> 
>> 
>> 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
> 
> 
> 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.

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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4