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

["Adamson, Andy" <[e-mail]>]

On Aug 4, 2014, at 2:45 PM, Nico Williams <[e-mail]> wrote:

> On Mon, Aug 04, 2014 at 02:13:20PM -0400, Benjamin Kaduk wrote:
>> On Mon, 4 Aug 2014, Nico Williams wrote:
>> 
>>> On Mon, Aug 04, 2014 at 04:38:16PM +0000, Adamson, Andy wrote:
>>>> On Aug 1, 2014, at 6:45 PM, Nico Williams <[e-mail]> wrote:
>>>>>> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample
>>>>>> code on page 7?  It is not otherwise mentioned in the draft, and the
>>>>> 
>>>>> Dunno.  It was never marked so in my draft.  Andy?
>>>> 
>>>> It is marked as “not used” in GSSv3 because GSSv3 provides it’s own channel binding method.
>>> 
>>> Ah, right, that's a v2 thing.  Thanks for reminding me!
>> 
>> Sorry if this is belaboring the point, but my reading of the text in
>> -08 is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to
>> establish a channel over which RPCSEC_GSS_CREATE can be called, and
>> implicitly disrecommends the use of this operation for any other
>> use.
> 
> - 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.

> 
> - v2 handles may have been channel bound with RPCSEC_GSS_BIND_CHANNEL;
>   this is implied and need not be stated, IMO.

No v2 handles

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


Correct. This should be made more clear. When using v3 RPCSEC_GSS_BIND_CHANNEL is depricated in favor of the v3 channel binding mechanism.

—>Andy

> 
> Do you agree?  Or did I miss the point?
> 
> Nico
> --