[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
>
>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
>
The question is whether we want to define the process of key
derivation for all prf's or want to leave that to the specification of
individual prf's. Notice that prf's that do not support arbitraty-length
keys will need to adjust the length of the keys in all the modes
of the protocol (depending on the length of Ni and Nr in the
encryption and signature modes, and depending on the length of
the pre-shared key in the case of pre-shared mode).
If we want the former then Lewis suggestion is ok with the
*added clarification* that in the encryption mode the first block (BLOCK1)
is *always* computed regardless of the size of the concatenated Ni|Nr.
(For example, if we use 3DES as the prf and we "happen" to use nonces of length
84 bits each, then we still apply hash(Ni|Nr) first, eventhough Ni|Nr
by itself already has the right length of 168 bits).
If we go for an expansion/shortening definition of keys as Lewis suggests
we should consider using HMAC for this instead of the plain hash, i.e.
B1 = HMAC(Ni|Nr, 0)
B2 = HMAC(Ni|Nr, B2)
B3 = HMAC(Ni|Nr, B3)
.....
Notice that this is exactly the way that key expansion is defined in
Appendix B for expanding encryption keys (page 28). In our case
the particular prf is HMAC (using the negotiated hash function).
That is, we would be letting people negotiate any prf of their choice,
but we will require the derivation of a key for this prf to go via HMAC.
(It wil be an overkill for some cases, e.g. when the prf itself is HMAC,
but it will make the specification more uniform).
Hugo