Re: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt

Scott G. Kelly writes:
> We added the PRF support after that text was written (rather than
> writing a separate doc), and in the interest of flexibility, chose
> to allow variable length keys.  I'm wondering now if that was a
> mistake, and we should have had a single position on key sizes. That
> would definitely simplify things. 

No, you definately want to support variable length keys for the PRF in
the IKEv2 use. Otherwise you end up similar problems than what
happened with the PRF_AES128_XCBC. The problem there was that EAP MSK
is at minimum 512 bits long and that is given as a key to the PRF, so
PRF must be able to handle keys that long to be able to be used with
EAP. 

> As for padding short keys, it certainly adds no security. It is
> there to explicitly tell implementors what to do (so they don't
> instead hash the key, and use the output). It's called out for the
> sake of interoperability.  

That also makes it possible to use IKEv2 shared secret that do not
match the key length required for the PRF_HMAC_SHA2_256. If PRF was
defined to use fixed length keys then the shared secret would be
required to be exactly the length of that fixed key and that could
cause problems (i.e. for example you could not update from the
PRF_AES128_XCBC to PRF_HMAC_SHA2_256 without changing the keying
material too. 

> >Stepping back a bit, I personally would rather see a single RFC describing
> >how to use a number of different hash functions with HMAC.  I could almost
> >use a set of text editor substitution patterns to change this draft from
> >SHA-256 to SHA-384 or SHA-512.  The core of such a document would be a
> >table listing acceptable key sizes and truncation sizes for each function
> >considered.  An appendix could list test vectors.
> 
> Russ just mentioned that NSA-B requires SHA-384 support, and I was
> looking at the draft to see if that could be cleanly dropped in -
> this might be one way to do it.  If there is general support for
> this approach, we can look at what it would take to re-spin the doc. 

Yes, I think it would be better to add SHA-384 and SHA-512 to this
draft too. On the other hand I think it is better not to have too many
different combinations, i.e. I can see use for PRF_HMAC_SHA2_384 and
PRF_HMAC_SHA2_512, but I do not know how many different truncation
lengths we need.

Perhaps it would be enough to define AUTH_HMAC_SHA2_256_128,
AUTH_HMAC_SHA2_384_192 and AUTH_HMAC_SHA2_512_256, and skip all other
truncation lengths (including the AUTH_HMAC_SHA2_256_192 already
defined in the draft).
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec