]> Ericsson

8400 boulevard Decarie Montreal, QC H4P 2N2 Canada mglt.ietf@gmail.com

LMU Munich

Am Osteroesch 9 87637 Seeg Bavaria Germany tobias.guggemos@gmail.com

INTERNET IPSECME IPsec ESP with AES-CBC, AES-CTR, AES-CCM or AES-GCM sends an IV in each IP packet, which represents 8 or 16 additional bytes. In some context, such as IoT, the cost of sending bytes over computing these bytes is generally in favor of the computation. As a result, it would be better to compute the IV on each party then to send it. The document describes how to the IV can be generated instead of being sent. This document limits the IV generation for AES-CBC, AES-CTR, AES-CCM and AES-GCM but can be used for additional cryptographic mode and suites.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in.

Using AES in one of the AES-CBC , AES-CTR encryption mode, or in one of the AES-CCM and AES-GCM combined requires the specification of an IV for each ESP packet. Currently this IV is sent in each ESP packet . IoT devices present new characteristics over traditional devices. One of them is that the balance between extra computation and extra byte sent over the wire is most of the time in favor of extra computation. For such devices, embedding the IV in each packet constitutes an extra cost over computing the IV of each associated packet. Depending on the the AES mode, the IV can be of different sizes and have different properties. AES-CBC needs a 16 byte IV. This IV MUST be chosen at random and MUST be unpredictable. In addition IV MUST NOT be generated with low Hamming distance (like counter) for example -- Section 3. AES-CTR and AES-CCM need an 8 byte IV. This IV MUST be unique ( Section 2.1). Finally, AES-GCM requires 8 byte IV, that must be unique for a given key -- Section 2. This document defines how for each of the AES-CBC, AES-CTR, AES-CCM and AES-GCM, the IV can be computed by each peer instead of being included in the ESP packet. This document limits its scope to AES as most of devices in the IoT have hardware acceleration for AES, and use AES. However, the description may be extended to additional crypto suites.

IoT: Internet of Things IV: Initialization Vector

With AES-CBC, the IV is 16 bytes, random and unpredictable. In this document, the binding between IV and ESP packet is performed using the Sequence Number or the Extended Sequence Number. A clear text payload is derived from the Sequence Number or the Extended Sequence Number. In order to generate the IV randomly, AES is used as a random permutation. A dedicated 16 byte key is used for each peer. key_iv_initiator (resp. key_iv_responder) is used to derive the IV emitted by the initiator (resp. the responder). Keys key_iv_initiator and key_iv_responder MUST be agreed prior IPsec packets are exchanged. When IKEv2 is used these keys are derived from the KEYMAT. key_iv_initiator is the first key generated, followed by key_iv_responder. (resp. ) defines a clear text payload derived from a 4 byte Sequence Number (resp. a 8 byte Extended Sequence Number)

Where, Sequence Number: the 4 byte Sequence Number carried in the ESP packet. Zero: a 12 byte array with all bits set to zero.

Where, Extended Sequence Number: the 8 byte Extended Sequence Number of the Security Association. The 4 byte low order bytes are carried in the ESP packet. Zero: a 8 byte array with all bits set to zero.

With AES-CTR, AES-CCM and AES-GCM, the 8 byte IV MUST NOT repeat. The binding between a ESP packet and its IV is provided using the Sequence Number or the Extended Sequence Number. (resp ) represents the IV with a regular 4 byte Sequence Number (resp. a 8 byte Extended Sequence Number).

Where, Sequence Number: the 4 byte Sequence Number carried in the ESP packet. Zero: a 4 byte array with all bits set to zero.

Where, Extended Sequence Number: the 8 byte Extended Sequence Number of the Security Association. The 4 byte low order bytes are carried in the ESP packet.

IV generation of the AES-CBC, AES-CTR, AES-CCM and AES-GCM have not been explicitly defined. It has been left to the implementation as long as certain security requirements are met. This document provides an explicit and normative way to generate IVs. The mechanism described in this document meets the IV security requirements of AES-CBC, AES-CTR, AES-CCM and AES-GCM. Randomness is provided by using AES. If this hypothesis is no longer valid, than most probably, none of the AES mode will be considered secure.

Each of the AES-CBC, AES-CTR, AES-CCM and AES-GCM crypto suite needs to have their associated cryptographic suite with implicit IV. That is to say the transforms below should be added to the Transform Type 1 - Encryption Algorithm Transform IDs: ENCR_AES_CBC_IMPLICIT_IV ENCR_AES_CTR_IMPLICIT_IV ENCR_AES-CCM_8_IMPLICIT_IV ENCR_AES-CCM_12_IMPLICIT_IV ENCR_AES-CCM_16_IMPLICIT_IV AES-GCM with 8 octet ICV and implicit IV AES-GCM with 12 octet ICV and implicit IV AES-GCM with 16 octet ICV and implicit IV

&RFC2119; &RFC3602; &RFC3686; &RFC4104; &RFC4303; &RFC4309; &RFC7296;

[draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: changing affiliation. [draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: First version published.