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

RE: Questions/comments re draft-ietf-ipsec-esp-rc5-cbc-00.txt

>I have some questions and comments regarding
>draft-ietf-ipsec-esp-rc5-cbc-00.txt.
>
>The first question I have is why 40 bits? I am under the
>impression the IPsec wg, for political reasons, chose to
>exclude export weakened cipher usage.

What this drafts states is that the key size may be as small as 40 bits.
 It is more of a flexibility issue than an export one.  Policy will be
able to reject any proposal that requests a smaller key size than it
allows.

>I'm a bit confused about the following paragraph from the
>document.
>
>> 2.3 Payload
>>
>>    RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets
>>    (64 bits) that immediately precedes the cipher-text in the payload.
>>    A new IV must be pseudo-randomly generated for each packet and then
>>    used to encrypt that plain-text.  When decrypting, the first 8
>>    octets of the payload are used as a IV to decrypt the remaining
>>    payload octets.
>>
>
>Those statements are really confusing. They say the IV
>precedes the cipher-text but then say first 8 octets of the
>payload (the SPI and sequence number?) are used to decrypt the
>rest. As Scoobe Doo says, Er? The CBC method seems a bit weird to
>me too. Is the IV XORed with each block?

This draft relates to the upcoming ESP draft
(draft-ietf-ipsec-new-esp-01).  In that draft, the explicit IV has been
taken out of the ESP 'template' and must be documented in the individual
ESP algorithm drafts.  

Thus ESP starts off like:

   SPI (32 bits)
   Sequence Number (32 bits)
   Payload (variable)
   ......

So within the Payload we start off with a 64 bit IV followed by the
cipher text.  That explicit IV is then used to decrypt the cipher text.
>
>Regarding key material, why is the key material derived as
>stated in section 4 rather than slice and dice?

Section 4 does talk about 'slicing and dicing'.  This is inline with
what was discussed and agreed upon in Memphis.  The specific algorithm
would dictate how many bits of keying material it would require, so that
ISAKMP (or any other higher layer) can provide it.  Then the algorithm
simply slices the key material into sections (x bits for the cipher key,
y bits for the authentication key).
>
Follow-Ups: