Re: [nfsv4] Last call start for "RPCSEC_GSS Version 2"

["Mike Eisler" <[e-mail]>]

> There's no guarantee, as you point out, that all channel bindings sepcs
> will be "small", so I realized last night that we may still want to keep
> the hash thing, at least as an option.
>
> If we want it to be an option, then we could say that the empty OID
> (zero-length octet string) means "identity function" and that the client
> MUST pick a hash only if the channel bindings are larger than the output
> size of any of the hash functions available and acceptable to the
> client.
>
> If you don't want it to be an option then I don't object, and I retract
> my comment about removing the feature.

Cool. We will leave it as is then.


On Fri, June 13, 2008 1:41 pm, Nicolas Williams wrote:
> On Fri, Jun 13, 2008 at 01:21:48PM -0700, Mike Eisler wrote:
>> On Wed, June 11, 2008 4:16 pm, Nicolas Williams wrote:
>> > On Mon, Jun 02, 2008 at 11:30:43PM -0500, Spencer Shepler wrote:
>> >> http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-rpcsec-gss-v2-03.txt
>>
>> >
>> >     - rbcva_chan_bind_hash_oid, should we actually need it (see below)
>> >       should be described as containing the DER encoding of an OID.
>> >
>> >     - But I don't think we need to hash the channel bindings at all
>> >       because: a) gss_get/verify_mic() can handle large amounts of
>> input
>> >       data anyways, thus no need to hash it down, b) using a hash adds
>> >       complexity (including hash agility considerations), c) channel
>> >       bindings will typically be hashed data to begin with[*].
>>
>> OK, I'm very confused.
>>
>> You wrote on April 21:
>>
>> ``The primary change here is this: rather than use the raw public keys I
>
> The change was to draft-williams-ipsec-channel-binding to make use of a
> hash *there* rather than in RPCSEC_GSSv2.
>
>> want to use a hash of them.  The main reason is: so keeping channel
>> binding data in kernel mode implementations is not too difficult (by
>> reducing the size of the data to keep around).  Hash agility is pushed
>> to the application, which will require a change to RPCSEC_GSSv2 (which
>> is still an I-D and has not progressed yet).''
>
> What I meant by pushing hash agility to the application is that it's the
> IPsec implementation's job to implement one or more hashes, and the
> app's job to pick one.
>
> The change to RPCSEC_GSSv2 is to remove the need for a hash there.  (But
> see below.)
>
>> The current RPCSEC_GSSv2 i-d is consistent with what you wrote on April
>> 21. But you didn't say how you wanted the  RPCSEC_GSSv2 changed. So
>> in absence of guidance, this is what you get.
>>
>> As for "typically be hashed data" that's not good enough. RPCSEC_GSS
>> creds and verifiers are limited to 400 bytes. Public keys can easily
>> exceed 400 bytes.
>
> We don't send the channel bindings though.  Just a MIC, so the 400 byte
> issue is a non-issue.
>
> The main reason to worry about channel bindings size is that you have to
> keep track of them in kernel-land, which can be a pain.
>
> There's no guarantee, as you point out, that all channel bindings sepcs
> will be "small", so I realized last night that we may still want to keep
> the hash thing, at least as an option.
>
> If we want it to be an option, then we could say that the empty OID
> (zero-length octet string) means "identity function" and that the client
> MUST pick a hash only if the channel bindings are larger than the output
> size of any of the hash functions available and acceptable to the
> client.
>
> If you don't want it to be an option then I don't object, and I retract
> my comment about removing the feature.
>
> Nico
> --
>


-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/



_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4