draft-ietf-ipsecme-implicit-iv-08.txt   draft-ietf-ipsecme-implicit-iv-09.txt 
IPSECME D. Migault IPSECME D. Migault
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track T. Guggemos Intended status: Standards Track T. Guggemos
Expires: April 18, 2020 LMU Munich Expires: April 20, 2020 LMU Munich
Y. Nir Y. Nir
Dell EMC Dell EMC
October 16, 2019 October 18, 2019
Implicit IV for Counter-based Ciphers in Encapsulating Security Payload Implicit IV for Counter-based Ciphers in Encapsulating Security Payload
(ESP) (ESP)
draft-ietf-ipsecme-implicit-iv-08 draft-ietf-ipsecme-implicit-iv-09
Abstract Abstract
Encapsulating Security Payload (ESP) sends an initialization vector Encapsulating Security Payload (ESP) sends an initialization vector
(IV) in each packet. The size of IV depends on the applied (IV) in each packet. The size of IV depends on the applied
transform, being usually 8 or 16 octets for the transforms defined by transform, being usually 8 or 16 octets for the transforms defined by
the time this document is written. Some algorithms such as AES-GCM, the time this document is written. Some algorithms such as AES-GCM,
AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to
generate a nonce that is used as an input parameter for encrypting generate a nonce that is used as an input parameter for encrypting
and decrypting. These algorithms require a unique IV but do not and decrypting. This IV must be unique but can be predictable. As a
require an unpredictable IV. As a result, the value provided in the result, the value provided in the ESP Sequence Number (SN) can be
ESP Sequence Number (SN) can be used instead to generate the nonce. used instead to generate the nonce. This avoids sending the IV
This avoids sending the IV itself, and saves in the case of AES-GCM, itself, and saves in the case of AES-GCM, AES-CCM and
AES-CCM and ChaCha20-Poly1305 8 octets per packet. This document ChaCha20-Poly1305 8 octets per packet. This document describes how
describes how to do this. to do this.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2020. This Internet-Draft will expire on April 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 49 skipping to change at page 2, line 49
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14 "OPTIONAL" in this document are to be interpreted as described BCP 14
[RFC2119], [RFC8174] when, and only when, they appear in all [RFC2119], [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Introduction 2. Introduction
Counter-based AES modes of operation such as AES-CCM ([RFC4309]), and Counter-based AES modes of operation such as AES-CCM ([RFC4309]), and
AES-GCM ([RFC4106]) require the specification of an nonce for each AES-GCM ([RFC4106]) require the specification of an nonce for each
ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634]). ESP packet. The same applies for ChaCha20-Poly1305 ([RFC7634]).
Currently this nonce is generated thanks to the Initialize Vector Currently this nonce is generated thanks to the Initialization Vector
(IV) provided in each ESP packet ([RFC4303]). This practice is (IV) provided in each ESP packet ([RFC4303]). This practice is
designated in this document as "explicit IV". designated in this document as "explicit IV".
In some contexts, such as IoT, it may be preferable to avoid carrying In some contexts, such as IoT, it may be preferable to avoid carrying
the extra bytes associated to the IV and instead generate it locally the extra bytes associated to the IV and instead generate it locally
on each peer. The local generation of the IV is designated in this on each peer. The local generation of the IV is designated in this
document as "implicit IV". document as "implicit IV".
The size of this IV depends on the specific algorithm, but all of the The size of this IV depends on the specific algorithm, but all of the
algorithms mentioned above take an 8-octet IV. algorithms mentioned above take an 8-octet IV.
This document defines how to compute the IV locally when it is This document defines how to compute the IV locally when it is
implicit. It also specifies how peers agree with the Internet Key implicit. It also specifies how peers agree with the Internet Key
Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus Exchange version 2 (IKEv2 - [RFC7296]) on using an implicit IV versus
an explicit IV. an explicit IV.
This document limits its scope to the algorithms mentioned above. This document limits its scope to the algorithms mentioned above.
Other algorithms with similar properties may later be defined to use Other algorithms with similar properties may later be defined to use
similar mechanism. similar mechanisms.
This document does not consider AES-CBC ([RFC3602]) as AES-CBC This document does not consider AES-CBC ([RFC3602]) as AES-CBC
requires the IV to be unpredictable. Deriving it directly from the requires the IV to be unpredictable. Deriving it directly from the
packet counter as described below is insecure as mentioned in packet counter as described below is insecure as mentioned in
Security Consideration of [RFC3602] and has led to real world chosen Security Consideration of [RFC3602] and has led to real world chosen
plain-text attack such as BEAST [BEAST]. plain-text attack such as BEAST [BEAST].
This document does not consider AES-CTR [RFC3686] as it focuses on This document does not consider AES-CTR [RFC3686] as it focuses on
the recommended AEAD suites provided in [RFC8221]. the recommended AEAD suites provided in [RFC8221].
 End of changes. 7 change blocks. 
12 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/