[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
Hugo Krawczyk writes:
> Finally, let me offer a specification for SKEYID for the encryption
> mode which is slightly different than what I requested in the
> previous message. This one has the same effect but may make the
> change from the previous definition even simpler:
>
> SKEYID = prf(hash(Ni|Nr), CKY-I | CKY-R)
[and in a later message]
> The spec specifies which key to use with the prf in each case.
> However, different prf's may require a diferent number of key bits.
> While HMAC is defined for any length of key, 3DES-CBC-MAC (which is
> my preferred candidate for use as a prf for key derivation) is
> defined with *exactly* 168 bits of key. What do we do in order to use
> it with another key length? Whoever specifies 3DES-CBC-MAC for use in
> isakmp/oakley will need to define how to get the right number of key
> bits in this case. Same for other prf's.
Also the spec feeds a couple of different size keys to p.r.f.s in
different computations. For the sake of generality I suggest defining
in isakmp-oakley a general expansion mechanism for prf keying material
(like the feedback method in Appendix B for expanding key material to
be used in encrypting ISAKMP messages) and specific indications
for each known prf (as is currently done for specific ciphers in
Appendix B). Perhaps the prf key would be the first n bits of the
sequence BLOCK1 = hash(Ni | Nr), BLOCK2 = hash(Ni| Nr | BLOCK1),
BLOCK3 = hash(Ni | Nr | BLOCK2), ...
Do we have a current draft that derives key material with feedback in
an unkeyed hash function? isakmp-oakley uses feedback in a prf, and
key-derivation-01 uses feedback in a block cipher.
-Lewis
References: