[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
Hi all
The latest Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt, does not have
definitions for 40 Bit DES and 3DES 112 bit, in IPSEC ESP transform
identifiers.
Also the document Feb 13 1998 draft-ietf-ipsec-isakmp-oakley-06.txt does
not have class values for 40 Bit DES and 3DES 112 bit
for Encryption algorithms.
Ramesh
-----Original Message-----
From: Daniel Harkins <dharkins@cisco.com>
To: Ben Rogers <ben@Ascend.COM>
Cc: Theodore Y. Ts'o <tytso@MIT.EDU>; ipsec@tis.com <ipsec@tis.com>
Date: Wednesday, February 18, 1998 5:59 PM
Subject: 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
>
>
Follow-Ups: