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

[Nicolas Williams <[e-mail]>]

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
-- 
_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4