[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: SKEYID lengths and IVs
Hi,
For a keyed hash function such as MD5 the SKEYID is the length of the
output, ie 128bits which is an acceptable key length for keyed hashes
and so SKEYID can be used as a key input to generate SKEYID_d etc...
However for prf functions such as 3DES the key needs to be 192 bits but
the output of 3DES prf is only 64bits so SKEYID needs to be expanded to
be used as a key to the next prf (SKEYID_d...).
For IV of phase two treat the blob generated from the hash of the DH
public values as the "last CBC block" and then apply the method
described in the appendix.
Bye.
----
Greg "Geek Spice" Carter, Entrust Technologies
greg.carter@entrust.com
>----------
>From: owner-ipsec@ex.tis.com[SMTP:owner-ipsec@ex.tis.com]
>Sent: Thursday, February 05, 1998 10:18 AM
>To: ipsec@tis.com
>Subject: SKEYID lengths and IVs
>
>Hi. I had some questions on Appendix B of the Resolution draft:
>
>1. SKEYID length: Appendix B of the resolution draft explains a method to
>increase the length of the SKEYIDs if the output of the PRF is not long
>enough. How is the length of the SKEYIDs determined in the first place?
>Is it 'atleast' 90 bits as per the Oakley draft? Also, if SKEYID_d is
>going to be derived this way, what is the reason for expanding SKEYID? Is
>this method for use with SKEYID_d only or would it be used for SKEYID_e
>also? If it is to be used with SKEYID_e, then why use the key expansion
>method described later on instead of just expanding SKEYID_e, and then
>using the required number of octets from it as the encryption key?
>
>2. IV generation for phase 2 messages: Appendix B also describes how to
>generate IVs for encrypting phase 2 exchanges. It states that the IV for
>the first phase 2 message is derived from a hash of the concatenation of
>the last phase 1CBC output block and the phase 2 message id. Since the
>Aggressive exchange does not encrypt any messages, there would be no phase
>1CBC output blocks. How would the phase 2 IV be derived in this case?
>Should the hash of the concatenation of the two sides' public
>Diffie-Hellman values be used instead?
>
>Thanks,
>
>Sumit A. Vakil
>3Com, Corp.
>
>
>
>
>