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

No Subject



(8.8.8/8.7.3) with ESMTP id XAA03960 for <ipsec@lists.tislabs.com>; Fri, 7 May 1999 23:09:58 -0400 
(EDT)
Message-ID: <3733D528.1D9FAEEC@netrover.com>
Date: Fri, 07 May 1999 23:09:45 -0700
From: Loretta Zhou <lzhou@netrover.com>
X-Mailer: Mozilla 4.51 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec@lists.tislabs.com
Subject: Question on IV for ESP payload
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

I have some questions on the creation and the size of IV
for ESP payload.

RFC 2407 defines the following IPSEC ESP Transform Identifiters:

       Transform ID                        Value
       ------------                        -----
       RESERVED                            0
       ESP_DES_IV64                        1
       ESP_DES                             2
       ESP_3DES                            3
       ESP_RC5                             4
       ESP_IDEA                            5
       ESP_CAST                            6
       ESP_BLOWFISH                        7
       ESP_3IDEA                           8
       ESP_DES_IV32                        9
       ESP_RC4                             10
       ESP_NULL                            11

It also indicates the following for the transform ids:

 o For ESP_DES_IV64 (1) and ESP_DES_IV32 (9), the transform type
   specifie the DES-CBC transform defined RFC-1827 and RFC-1829.

 o For ESP_DES (2), all implementation within the IPSEC DOI MUST
   support the suite defined as [DES] transofrm (RFC2405).

 o For ESP_3DES (3), all implementation within the IPSEC DOI MUST
   support the suite defined as [ESPCBC] transofrm (RFC2451).

By looking at the 3 RFCs mentioned above for information on IV,
RFC1829 says that "A common acceptable technique is simply a counter,
beginning with a randomly chosen value", while RFC2405 and RFC2451
indicate that "Common practice is to use random data for the first IV
and the last 8 octets of encrypted data from an encryption process as
the IV for the next encryption proces".

At the mean time, appendix B of RFC2409(The Internet Key Exchange)
states the following:

   In phase 2, material for the initialization vector for CBC mode
   encryption of the first message of a Quick Mode exchange is derived
   from a hash of a concatenation of the last phase 1 CBC output block
   and the phase 2 message id using the negotiated hash algorithm. The
   IV for subsequent messages within a Quick Mode exchange is the CBC
   output block from the previous message. Padding and IVs for
   subsequent messages are done as in phase 1.

Q1) Should we create the first IV using a random number or using
    the algorithm defined in appendix B of RFC2409? If we follow
    RFC2409, do we store IV (last phase 1 CBC output block) as part
    of the SA fields?

Q2) RFC2406 (IP ESP) indicates that the IV size of 32 and 64 bits are
    required to be supported. It also states that "When the size is
    32-bits, a 64-bit IV is formed from the 32-bit value followed by
    (concatenated with) the bit-wise complement of the 32-bit value".

    Since the IV is always going to be 64-bit, why do we have to support
    size 32 and 64? If we use the method defined in appendix B of
    RFC2409, we're always going to get a 64-bit block, how do we support
    size 32 anyway? What determines if we need to do size 32 or 64 IV
    for encryption (eg. user provisiong, default, ...)?

Q3) What's the difference between transform ID 1/9 (ESP_DES_IV64/ESP_DES_IV32)

    and ID 2 (ESP_DES)? If the SA is negotiated to support ID 2, it still
    needs to have an IV64/IV32 for CBC operation later, is it not right?


Regards,
Li Zhou.