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

[Benjamin Kaduk <[e-mail]>]

On Thu, 21 Jan 2016, [e-mail] 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.

-Ben