[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Derivation of Phase 1 keying material




[I appologize if this as a re-send -- my mailer (and evidently the IPsec
list) is confused .. ben]

>From IO-RES Appendix B:

   Encryption keys used to protect the ISAKMP SA are derived from
   SKEYID_e in an algorithm-specific manner. When SKEYID_e is not long
   enough to supply all the necessary keying material an algorithm
   requires, the key is derived from feeding the results of a pseudo-
   random function into itself, concatenating the results, and taking
   the highest necessary bits.

   For example, if (ficticious) algorithm AKULA requires 320-bits of key
   (and has no weak key check) and the prf used to generate SKEYID_e
   only generates 120 bits of material, the key for AKULA, would be the
   first 320-bits of Ka, where:

       Ka = K1 | K2 | K3
   and
       K1 = prf(SKEYID_e, 0)
       K2 = prf(SKEYID_e, K1)
       K3 = prf(SKEYID_e, K2)

I'm not really clear as to what we do if SKEYID_e has enough bits to
provide us with the encryption key we're looking for.  Perhaps one of
the following clarifications is appropriate?

   Encryption keys used to protect the ISAKMP SA are derived from
   SKEYID_e in an algorithm-specific manner.  If SKEYID_e is long enough
   to supply the necessary keying material the algorithm requires, then
   it is used without modification.  If it is not long enough, the key
   is derived from feeding the results of a pseudo-random function into
   itself, concatenating the results, and taking the highest necessary
   bits.

   For example,...

or

   Encryption keys used to protect the ISAKMP SA are derived from
   SKEYID_e in an algorithm-specific manner.  The key material is
   generated by taking the high order bits of the following string K:

       K = K1 | K2 | K3 | ...
   where
       K1 = prf(SKEYID_e, 0)
       KN+1 = prf(SKEYID_e, KN)

   and 0 is represented by a single octet.

   For example, if (ficticious) algorithm AKULA requires 320-bits of key
   (and has no weak key check) and the prf used to generate SKEYID_e
   only generates 120 bits of material, the key for AKULA, would be the
   first 320-bits of Ka, where:

       Ka = K1 | K2 | K3
   and
       K1 = prf(SKEYID_e, 0)
       K2 = prf(SKEYID_e, K1)
       K3 = prf(SKEYID_e, K2)

   where prf is the negotiated prf or the HMAC version of the negotiated
   hash function. Each result of the prf provides 120 bits of material
   for a total of 360 bits. AKULA would use the first 320 bits of that
   360 bit string.

I'm also not certain to do in the case where the first 8 bytes of this
keystring are weak.  Do we instead take bytes 1-9, or bytes 9-16?  Does
anyone see the need to include the weak key check in 3DES-CBC?  If so,
do we not allow keys for which any of the DES keys is weak, or only keys
where all three are weak?  If the first is the case, shold we allow
non-contiguous keys?  (ie, if bytes 9-16 are a weak key, do I build my
3DES key from bytes 1-8, 17-24 and 25-32, or take the contiguous block
of bytes 17-40 or 25-48?)


ben