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

Re: IPSEC WORKING GROUP LAST CALL

  Ben,

  If you read a bit further down in Appendix B of IKE it will
tell you how to obtain the key out of the blob of bits. For instance:

   The key for IDEA-CBC is derived from the first sixteen (16) bytes of
   SKEYID_e.  The IV is the first eight (8) bytes of the IV material
   derived above.
 
   The key for Blowfish-CBC is either the negotiated key size, or the
   first fifty-six (56) bytes of a key (if no key size is negotiated)
   derived in the aforementioned pseudo-random function feedback method.
   The IV is the first eight (8) bytes of the IV material derived above.

if you're doing IDEA or Blowfish. The blob of bits is either SKEYID_e
directly or the result of the feedback mechanism. It's all there in
Appendix B.

  I included a weak key check for the mandatory-to-implement encryption
algorithm but not the others. Since it is mandatory to implement I felt it
was necessary to note the weak keys. Based on the lack of responses to your
3 postings of this message I guess no one else wants to add discussions
on weak keys for other optional encryption algorithms.

  There are quite a few independent implementations of IKE (yes, with 
multiple encryption algorithm support too!) around so the text in Appendix 
B is probably clear enough. It could always be made better, but a decent 
enough clarity test is whether more that, say five, people can read it and 
all interpret it the same way. They did and they have.

  Dan.

> >From IKE 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?  (Without the
> clarification, there exists a definite ambiuity).
> 
>    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
References: