Internet DRAFT - draft-mglt-6lo-aes-implicit-iv
draft-mglt-6lo-aes-implicit-iv
IPSECME D. Migault, Ed.
Internet-Draft Ericsson
Intended status: Standards Track T. Guggemos, Ed.
Expires: August 21, 2015 LMU Munich
February 17, 2015
Implicit IV for AES-CBC, AES-CTR, AES-CCM and AES-GCM
draft-mglt-6lo-aes-implicit-iv-01.txt
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 21, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
Migault & Guggemos Expires August 21, 2015 [Page 1]
Internet-Draft Implicit IV February 2015
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Implicit IV with AES CBC . . . . . . . . . . . . . . . . . . 3
5. Implicit IV with AES-CTR, AES-CCM and AES-GCM . . . . . . . . 4
6. Security Consideration . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Requirements notation
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[RFC2119].
2. Introduction
Using AES in one of the AES-CBC [RFC3602], AES-CTR [RFC3686]
encryption mode, or in one of the AES-CCM [RFC4309] and AES-GCM
[RFC4104] combined requires the specification of an IV for each ESP
packet. Currently this IV is sent in each ESP packet [RFC4303].
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
-- [RFC3602] Section 3. AES-CTR and AES-CCM need an 8 byte IV. This
Migault & Guggemos Expires August 21, 2015 [Page 2]
Internet-Draft Implicit IV February 2015
IV MUST be unique ([RFC3686] Section 2.1). Finally, AES-GCM requires
8 byte IV, that must be unique for a given key -- [RFC4104]
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.
3. Terminology
- IoT: Internet of Things
- IV: Initialization Vector
4. Implicit IV with AES CBC
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 [RFC7296] is used these keys are
derived from the KEYMAT. key_iv_initiator is the first key generated,
followed by key_iv_responder.
Figure 1 (resp. Figure 2) defines a clear text payload derived from
a 4 byte Sequence Number (resp. a 8 byte Extended Sequence Number)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Zero |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Clear Text Payload for AES-CBC
Migault & Guggemos Expires August 21, 2015 [Page 3]
Internet-Draft Implicit IV February 2015
Where,
- Sequence Number: the 4 byte Sequence Number carried in the ESP
packet.
- Zero: a 12 byte array with all bits set to zero.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended |
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Clear Text Payload for AES-CBC with Extended Sequence
Number
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.
5. Implicit IV with AES-CTR, AES-CCM and AES-GCM
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. Figure 3 (resp
Figure 4) represents the IV with a regular 4 byte Sequence Number
(resp. a 8 byte Extended Sequence Number).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IV for AES-CTR, AES-CCM and AES-GCM with 4 byte Sequence
Number
Where,
Migault & Guggemos Expires August 21, 2015 [Page 4]
Internet-Draft Implicit IV February 2015
- Sequence Number: the 4 byte Sequence Number carried in the ESP
packet.
- Zero: a 4 byte array with all bits set to zero.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended |
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IV for AES-CTR, AES-CCM and AES-GCM with 8 byte Extended
Sequence Number
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.
6. Security Consideration
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.
7. IANA Considerations
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
Migault & Guggemos Expires August 21, 2015 [Page 5]
Internet-Draft Implicit IV February 2015
- 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
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC4104] Pana, M., Reyes, A., Barba, A., Moron, D., and M. Brunner,
"Policy Core Extension Lightweight Directory Access
Protocol Schema (PCELS)", RFC 4104, June 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, October 2014.
Appendix A. Document Change Log
[draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: changing
affiliation.
[draft-mglt-ipsecme-diet-esp-IV-generation-00.txt]: First version
published.
Migault & Guggemos Expires August 21, 2015 [Page 6]
Internet-Draft Implicit IV February 2015
Authors' Addresses
Daniel Migault (editor)
Ericsson
8400 boulevard Decarie
Montreal, QC H4P 2N2
Canada
Email: mglt.ietf@gmail.com
Tobias Guggemos (editor)
LMU Munich
Am Osteroesch 9
87637 Seeg, Bavaria
Germany
Email: tobias.guggemos@gmail.com
Migault & Guggemos Expires August 21, 2015 [Page 7]
