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

On Aug 4, 2014, at 4:37 PM, Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> 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 <nico@cryptonector.com> 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])

Yeah - thanks for the review - f rpc_gss_svc_channel_prot should also not be used. I can clean this up.

—>Andy
> 
>   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
> 
> _______________________________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten