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

[Benjamin Kaduk <[e-mail]>]

On Mon, 4 Aug 2014, Nico Williams wrote:

> On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote:
>> On Aug 4, 2014, at 2:45 PM, Nico Williams <[e-mail]> wrote:
>>> - v3 (all versions so far) permits the use of any RPCSEC_GSS context
>>>   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.
>
> 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).

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.


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

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_channel_prot (see RPCSEC_GSSv2 [4])

    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