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

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

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.

So your original instincts from April 21 seem correct.

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

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4