rfc8750xml2.original.xml   rfc8750.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8750" category="std"
RFC.2119.xml"> consensus="true" docName="draft-ietf-ipsecme-implicit-iv-11"
<!ENTITY RFC3602 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
RFC.3602.xml"> xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true"
<!ENTITY RFC3686 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. version="3">
RFC.3686.xml">
<!ENTITY RFC4104 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4104.xml">
<!ENTITY RFC4106 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4106.xml">
<!ENTITY RFC4302 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4302.xml">
<!ENTITY RFC4303 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4303.xml">
<!ENTITY RFC4309 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4309.xml">
<!ENTITY RFC4434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.4434.xml">
<!ENTITY RFC5374 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.5374.xml">
<!ENTITY RFC6311 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6311.xml">
<!ENTITY RFC6407 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.6407.xml">
<!ENTITY RFC7296 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7296.xml">
<!ENTITY RFC7383 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7383.xml">
<!ENTITY RFC7634 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.7634.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8174.xml">
<!ENTITY RFC8247 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8247.xml">
<!ENTITY RFC8221 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.
RFC.8221.xml">
<!ENTITY I-D.yeung-g-ikev2 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3
/reference.I-D.yeung-g-ikev2.xml">
]>
<rfc category="std" <front>
docName="draft-ietf-ipsecme-implicit-iv-11" <title abbrev="Implicit IV in ESP">Implicit Initialization Vector (IV) for C
ipr="trust200902"> ounter-Based
<front>
<title abbrev="Implicit IV in ESP">Implicit IV for Counter-based
Ciphers in Encapsulating Security Payload (ESP) </title> Ciphers in Encapsulating Security Payload (ESP) </title>
<author fullname="Daniel Migault" initials="D." surname="Migault">
<organization>Ericsson</organization> <seriesInfo name="RFC" value="8750"/>
<address> <author fullname="Daniel Migault" initials="D." surname="Migault">
<postal> <organization>Ericsson</organization>
<street>8275 Trans Canada Route</street> <address>
<city>Saint Laurent, QC H4S 0B6</city> <postal>
<street>8275 Trans Canada Route</street>
<city>Saint Laurent</city>
<region>QC</region>
<code>H4S 0B6</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>daniel.migault@ericsson.com</email> <email>daniel.migault@ericsson.com</email>
</address>
</address> </author>
</author> <author fullname="Tobias Guggemos" initials="T." surname="Guggemos">
<organization>LMU Munich</organization>
<author fullname="Tobias Guggemos" initials="T." surname="Guggemos"> <address>
<organization>LMU Munich</organization> <postal>
<address> <street>Oettingenstr. 67</street>
<postal> <city>Munich</city>
<street>Oettingenstr. 67</street> <region>Bavaria</region>
<city>80538 Munich</city> <code>80538</code>
<region>Bavaria</region> <country>Germany</country>
<country>Germany</country> </postal>
</postal> <phone/>
<phone/> <email>guggemos@nm.ifi.lmu.de</email>
<facsimile/> <uri>http://mnm-team.org/~guggemos</uri>
<email>guggemos@mnm-team.org</email> </address>
<uri>http://mnm-team.org/~guggemos</uri> </author>
</address> <author initials="Y." surname="Nir" fullname="Yoav Nir">
</author> <organization>Dell Technologies</organization>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization >Dell EMC</organization>
<address> <address>
<postal> <postal>
<street>9 Andrei Sakharov St</street> <street>9 Andrei Sakharov St</street>
<city>Haifa</city> <city>Haifa</city>
<code>3190500</code> <code>3190500</code>
<country>Israel</country> <country>Israel</country>
</postal> </postal>
<email>ynir.ietf@gmail.com</email> <email>ynir.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date month="March" year="2020"/>
<area>INTERNET</area>
<workgroup>IPSECME</workgroup>
<date/> <keyword>IKE</keyword>
<area>INTERNET</area> <keyword>IPsec</keyword>
<workgroup>IPSECME</workgroup> <keyword>GCM</keyword>
<abstract> <keyword>CCM</keyword>
<keyword>ChaCha20</keyword>
<t>Encapsulating Security Payload (ESP) sends an initialization vector
(IV) in each packet. The size of IV depends on the applied transform,
being usually 8 or 16 octets for the transforms defined by 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 generate a nonce
that is used as an input parameter for encrypting and decrypting. This
IV must be unique but can be predictable. As a result, the value
provided in the ESP Sequence Number (SN) can be used instead to generate
the nonce. This avoids sending the IV itself, and saves in the case of
AES-GCM, AES-CCM and ChaCha20-Poly1305 8 octets per packet. This
document describes how to do this.</t>
</abstract>
</front>
<middle>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described BCP 14
<xref target="RFC2119"/>, <xref target="RFC8174"/> when, and only when,
they appear in all capitals, as shown here.</t>
</section>
<section anchor="intro" title="Introduction">
<t>Counter-based AES modes of operation such as AES-CCM (<xref
target="RFC4309"/>), and AES-GCM (<xref target="RFC4106"/>) require the
specification of an nonce for each ESP packet. The same applies for
ChaCha20-Poly1305 (<xref target="RFC7634"/>). Currently this nonce is
generated thanks to the Initialization Vector (IV) provided in each ESP
packet (<xref target="RFC4303"/>). This practice is designated in this
document as "explicit IV".</t>
<t>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 on
each peer. The local generation of the IV is designated in this
document as "implicit IV".</t>
<t>The size of this IV depends on the specific algorithm, but all of
the algorithms mentioned above take an 8-octet IV.</t>
<t>This document defines how to compute the IV locally when it is
implicit. It also specifies how peers agree with the Internet Key
Exchange version 2 (IKEv2 - <xref target="RFC7296"/>) on using an
implicit IV versus an explicit IV.</t>
<t>This document limits its scope to the algorithms mentioned above.
Other algorithms with similar properties may later be defined to use
similar mechanisms.</t>
<t> This document does not consider AES-CBC (<xref target="RFC3602"/>)
as AES-CBC requires the IV to be unpredictable. Deriving it directly
from the packet counter as described below is insecure as mentioned in
Security Consideration of <xref target="RFC3602"/> and has led to real
world chosen plain-text attack such as BEAST <xref target="BEAST"/>.</t>
<t>This document does not consider AES-CTR <xref target="RFC3686"/> as
it focuses on the recommended AEAD suites provided in <xref
target="RFC8221"/>.</t>
</section>
<section anchor="sec:terminology" title="Terminology">
<t><list style="symbols">
<t>IoT: Internet of Things.</t>
<t>IV: Initialization Vector.</t>
<t>IIV: Implicit Initialization Vector.</t>
<t>Nonce: a fixed-size octet string used only once. In our case, the nonce takes
the IV as input and is provided as an input parameter for
encryption/decryption. </t>
</list></t>
</section>
<!--
<section anchor="sec-aes-cbc" title="Implicit IV with AES CBC">
<t>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).</t>
<t>Keys key_iv_initiator and key_iv_responder MUST be agreed prior IPsec
packets are exchanged. When IKEv2 <xref target="RFC7296"/> is used these
keys are derived from the KEYMAT. key_iv_initiator is the first key
generated, followed by key_iv_responder.</t>
<t><xref target="fig-aes-cbc-ct-sn"/> (resp. <xref <abstract>
target="fig-aes-cbc-ct-esn"/>) defines a clear text payload derived from <t>Encapsulating Security Payload (ESP) sends an initialization vector
a 4 byte Sequence Number (resp. a 8-byte Extended Sequence Number)</t> (IV) in each packet. The size of the IV depends on the applied transform
and is usually 8 or 16 octets for the transforms defined at the time
this document was written. When used with IPsec, some algorithms, such
as AES-GCM, AES-CCM, and ChaCha20-Poly1305, take the IV to generate a
nonce that is used as an input parameter for encrypting and
decrypting. This IV must be unique but can be predictable. As a result,
the value provided in the ESP Sequence Number (SN) can be used instead
to generate the nonce. This avoids sending the IV itself and saves 8
octets per packet in the case of AES-GCM, AES-CCM, and
ChaCha20-Poly1305. This document describes how to do this.</t>
</abstract>
</front>
<middle>
<figure anchor="fig-aes-cbc-ct-sn" title="Clear Text Payload for AES-CBC"> <section anchor="intro" numbered="true" toc="default">
<artwork><![CDATA[ <name>Introduction</name>
0 1 2 3 <t>Counter-based AES modes of operation such as AES-CCM <xref
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 target="RFC4309" format="default"/> and AES-GCM <xref target="RFC4106"
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ format="default"/> require the specification of a nonce for each ESP
| | packet. The same applies for ChaCha20-Poly1305 <xref target="RFC7634"
| Zero | format="default"/>. Currently, this nonce is generated thanks to the
| | initialization vector (IV) provided in each ESP packet <xref
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ target="RFC4303" format="default"/>. This practice is designated in
| Sequence Number | this document as "explicit IV".</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where, <t>In some contexts, such as the Internet of Things (IoT), it may be
<list hangIndent="3" style="hanging"> preferable to avoid carrying the extra bytes associated to the IV and
<t hangText="-">Sequence Number: the 4 byte Sequence Number carried in the E instead generate it locally on each peer. The local generation of the IV
SP packet.</t> is designated in this document as "implicit IV".</t>
<t hangText="-">Zero: a 12 byte array with all bits set to zero.</t> <t>The size of this IV depends on the specific algorithm, but all of the
algorithms mentioned above take an 8-octet IV.</t>
<t>This document defines how to compute the IV locally when it is
implicit. It also specifies how peers agree with the Internet Key
Exchange version 2 (IKEv2) <xref target="RFC7296" format="default"/> on
using an implicit IV versus an explicit IV.</t>
<t>This document limits its scope to the algorithms mentioned above.
Other algorithms with similar properties may later be defined to use
similar mechanisms.</t>
<t> This document does not consider AES-CBC <xref target="RFC3602"
format="default"/>, as AES-CBC requires the IV to be
unpredictable. Deriving it directly from the packet counter as described
below is insecure, as mentioned in <xref target="RFC3602"
sectionFormat="of" section="6"/>, and has led to real-world chosen
plaintext attacks such as BEAST <xref target="BEAST"
format="default"/>.</t>
<t>This document does not consider AES-CTR <xref target="RFC3686" format="
default"/>, as
it focuses on the recommended Authenticated Encryption with Associated Data (AEA
D) suites provided in <xref target="RFC8221" format="default"/>.</t>
</section>
</list></t> <section numbered="true" toc="default">
<name>Requirements Notation</name>
<figure anchor="fig-aes-cbc-ct-esn" title="Clear Text Payload for AES-CBC with E <t>
xtended Sequence Number"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<artwork><![CDATA[ IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
0 1 2 3 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
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 RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
| Zero | be interpreted as
| | described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ when, and only when, they appear in all capitals, as shown here.
| Extended | </t>
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where, </section>
<list hangIndent="3" style="hanging">
<t hangText="-">Extended Sequence Number: the 8-byte Extended Sequence <section anchor="sec_terminology" numbered="true" toc="default">
Number of the Security Association. The 4 byte low order bytes are <name>Terminology</name>
carried in the ESP packet.</t>
<t hangText="-">Zero: a 8-byte array with all bits set to zero.</t> <dl newline="false" indent="9" spacing="normal">
<dt>IoT:</dt> <dd>Internet of Things</dd>
<dt>IV:</dt> <dd>Initialization Vector</dd>
<dt>IIV:</dt> <dd>Implicit Initialization Vector</dd>
</list></t> <dt>Nonce:</dt> <dd>A fixed-size octet string used only once. In this
document, the IV is used to generate the nonce input for the
encryption/decryption. </dd>
</dl>
</section> </section>
<section anchor="sec-aes-ctr-ccm-cgm" title="Implicit IV"> <section anchor="sec-aes-ctr-ccm-cgm" numbered="true" toc="default">
<name>Implicit IV</name>
<t>With the algorithms listed in <xref target="intro"
format="default"/>, the 8-byte IV <bcp14>MUST NOT</bcp14> repeat for a
given key. The binding between an ESP packet and its IV is provided
using the Sequence Number or the Extended Sequence Number.
<t>With the algorithms listed in <xref target="intro"/>, the 8-byte Figures <xref target="fig-aes-ctr-ccm-gcm-iv-sn" format="counter"/> and <xref
IV MUST NOT repeat for a given key. The binding between an ESP packet target="fig-aes-ctr-ccm-gcm-iv-esn" format="counter"/> represent the IV with a
and its IV is provided using the Sequence Number or the Extended regular 4-byte Sequence Number and an 8-byte Extended Sequence Number,
Sequence Number. <xref target="fig-aes-ctr-ccm-gcm-iv-sn"/> and <xref
target="fig-aes-ctr-ccm-gcm-iv-esn"/> represent the IV with a regular
4-byte Sequence Number and with an 8-byte Extended Sequence Number
respectively.</t> respectively.</t>
<figure anchor="fig-aes-ctr-ccm-gcm-iv-sn">
<figure anchor="fig-aes-ctr-ccm-gcm-iv-sn" title="Implicit IV with a 4 byte Sequ <name>Implicit IV with a 4-Byte Sequence Number</name>
ence Number"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork><![CDATA[
0 1 2 3 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 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 | | Zero |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<t><list style="symbols">
<t>Sequence Number: the 4 byte Sequence Number carried in the ESP packet.</t>
<t>Zero: a 4 byte array with all bits set to zero.</t> <dl newline="true" spacing="normal">
<dt>Sequence Number:</dt>
<dd>The 4-byte Sequence Number carried in the ESP packet.</dd>
</list></t> <dt>Zero:</dt>
<dd>A 4-byte array with all bits set to zero.</dd>
</dl>
<figure anchor="fig-aes-ctr-ccm-gcm-iv-esn" title="Implicit IV with an 8-byte Ex <figure anchor="fig-aes-ctr-ccm-gcm-iv-esn">
tended Sequence Number"> <name>Implicit IV with an 8-Byte Extended Sequence Number</name>
<artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 | | Extended |
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>Extended Sequence Number:</dt> <dd>The 8-byte Extended Sequence
Number of the Security Association. The four low-order bytes are
<t>Extended Sequence Number: the 8-byte Extended Sequence Number of the carried in the ESP packet.</dd>
Security Association. The 4 byte low order bytes are carried in the ESP </dl>
packet.</t> <t> This document solely defines the IV generation of the algorithms
defined in <xref target="RFC4106"/> for AES-GCM, <xref
</list></t> target="RFC4309"/> for AES-CCM, and <xref target="RFC7634"/> for
ChaCha20-Poly1305. All other aspects and parameters of those algorithms
<t> This document solely defines the IV generation of the algorithms are unchanged and are used as defined in their respective
defined in [RFC4106] for AES-GCM, [RFC4309] for AES-CCM and [RFC7634] specifications.</t>
for ChaCha20-Poly1305. All other aspects and parameters of those algorithms
are unchanged, and are used as defined in their respective
specifications.</t>
<!--
<t>Section
3.5 of <xref target="RFC6407"/> provides a mechanism that MAY be used to
prevent IV collisions when the same key is used by multiple users. The
mechanism consists in partitioning the IV space between users by
assigning the most significant byte to a user. When implicit IV
transforms are used, such mechanism cannot be applied as the IV is not
sent, but instead it is derived from the Sequence Number. A similar
mechanism could be used by associating the most significant byte of the
Sequence Number to a sender, while the 3 remaining bytes will be used to
carry the counter value. Such mechanism prevents the use of Extended
Sequence Number and limits the number of packet to be sent to 2** 24 =
16777216, that is 16 M. Note that associating instead the least
significant byte of the Sequence Number to the sender, would enable the
system to use Extended Sequence Number and as such extend the limit of
packet to be sent to 2 ** ( 24 + 32 ) = 72057594037927936, that is 72 P.
Note also that in both cases the Sequence Number are not interpreted as
numeric values which impacts the replay window processing defined in
<xref target="RFC4302"/> and <xref target="RFC4302"/>.</t>
<t>Unless some mechanism are provided to avoid collision between
Sequence Number, ( and so IV ), Implicit IV MUST NOT be used. As such,
it is NOT RECOMMENDED to use Implicit IV with Multicast.</t>
</section> </section>
<!-- <section numbered="true" toc="default">
<section anchor="nego" title="Implicit IV Agreement"> <name>IKEv2 Initiator Behavior</name>
<t>An initiator supporting this feature <bcp14>SHOULD</bcp14> propose impl
<t>NOTE: THIS SECTION SHOWS SEVERAL WAYS TO DO THE SAME THING. OBVIOUSLY icit IV (IIV)
THIS DOCUMENT WILL NOT BE PUBLISHED LIKE THAT. WE EXPECT WG DISCUSSION
TO PARE THIS DOWN TO JUST ONE WAY OF NEGOTIATING THE USE OF IMPLICIT IV
(IIV).</t>
<t>Negotiation of the use of implicit IV can be done in 3 different
ways: <list style="symbols">
<t> An IMPLICIT IV Transform Type. A proposal that contains this
transform type requires (if accepted) that IPsec use the implicit IV and
not include an explicit IV in the packets. To facilitate backward
compatibility with non-supporting implementations the Initiator SHOULD
add another proposal that does not include this transform type as well
as cryptographic suite the Initiator does not support the implicit
IV.</t>
<t> An IMPLICIT IV Transform ID. This doubles the number of ENCR
transform IDs by creating an ENCR_AES_CCM_16_IIV for each
ENCR_AES_CCM_16.</t>
<t> An IMPLICIT IV Transform Attribute, which would be associated to a
Transform Type ID, specifying the use of an implicit IV. marks a
particular ENCR transform as using implicit IVs. To facilitate backward
compatibility with non-supporting implementations the Initiator SHOULD
add another ENCR transform for each algorithm so marked. In other words,
for each ENCR_AES_CCM_16 with keylength=256 and IIV=1, there will need
to be an ENCR_AES_CCM_16 with keylength=256 and no IIV attribute.</t>
</list> </t>
</section>
<section title="IKEv2 Initiator Behavior">
<t>An initiator supporting this feature SHOULD propose implicit IV (IIV)
algorithms in the Transform Type 1 (Encryption Algorithm) Substructure algorithms in the Transform Type 1 (Encryption Algorithm) Substructure
of the Proposal Substructure inside the Security Association Payload (SA of the Proposal Substructure inside the Security Association (SA)
Payload) in the IKEv2 Exchange. To facilitate backward compatibility payload in the IKEv2 Exchange. To facilitate backward compatibility
with non-supporting peers the initiator SHOULD also include those same with non-supporting peers, the initiator <bcp14>SHOULD</bcp14> also include thos
e same
algorithms with explicit IV as separate transforms.</t> algorithms with explicit IV as separate transforms.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IKEv2 Responder Behavior</name>
<section title="IKEv2 Responder Behavior"> <t>The rules of SA payload processing require that the responder pick its
algorithms from the proposal sent by the initiator, thus
<t>The rules of SA Payload processing require that responder picks its ensuring that the responder will never send an SA payload containing the
algorithms from the proposal sent by the initiator, thus this will
ensure that the responder will never send an SA payload containing the
IIV transform to an initiator that did not propose it.</t> IIV transform to an initiator that did not propose it.</t>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
</section> <section title="Security Considerations"> <t>Nonce generation for these algorithms has not been explicitly
defined. It has been left to the implementation as long as certain
<t>Nonce generation for these algorithms has not been explicitly security requirements are met. Typically, for AES-GCM, AES-CCM, and
defined. It has been left to the implementation as long as certain ChaCha20-Poly1305, the IV is not allowed to be repeated for one
security requirements are met. Typically, for AES-GCM, AES-CCM particular key. This document provides an explicit and normative way to
and ChaCha20-Poly1305, the IV is not allowed to be repeated for one generate IVs. The mechanism described in this document meets the IV
particular key. This document provides an explicit and normative way to security requirements of all relevant algorithms.</t>
generate IVs. The mechanism described in this document meets the IV <t> As the IV must not repeat for one SA when Counter-Mode ciphers are
security requirements of all relevant algorithms.</t> used, implicit IV as described in this document <bcp14>MUST NOT</bcp14>
be used in setups with the chance that the Sequence Number overlaps for
<t> As the IV must not repeat for one SA when Counter-Mode ciphers are one SA.
used, implicit IV as described in this document MUST NOT be used in
setups with the chance that the Sequence Number overlaps for one SA.
The sender's counter and the receiver's counter MUST be reset (by
establishing a new SA and thus a new key) prior to the transmission of
the 2^32nd packet for an SA that uses a non extended Sequence Number
(respectively the 2^64nd packet for an SA that uses an Extended Sequence
Number). This prevents sequence number overlaps for the mundane
point-to-point case. Multicast as described in <xref
target="RFC5374"/>, <xref target="RFC6407"/> and <xref
target="I-D.yeung-g-ikev2"/> is a prominent example, where many senders
share one secret and thus one SA. As such, Implicit IV may only be used
with Multicast if some mechanisms are employed that prevent Sequence
Number to overlap for one SA, otherwise Implicit IV MUST NOT be used
with Multicast. </t>
<t>This document defines three new encryption transforms that use
implicit IV. Unlike most encryption transforms defined to date, which
can be used for both ESP and IKEv2, these transforms are defined for ESP
only and cannot be used in IKEv2. The reason is that IKEv2 messages
don't contain a unique per-message value that can be used for IV
generation. The Message-ID field in IKEv2 header is similar to the SN
field in ESP header, but recent IKEv2 extensions (<xref
target="RFC6311"/>, <xref target="RFC7383"/>) do allow it to repeat, so
there is not an easy way to derive unique IV from IKEv2 header
fields.</t>
</section>
<section title="IANA Considerations"> The sender's counter and the receiver's counter <bcp14>MUST</bcp14> be reset
(by establishing a new SA and thus a new key) prior to the transmission of the
2^32nd packet for an SA that does not use an Extended Sequence Number and
prior to the transmission of the 2^64th packet for an SA that does use an
Extended Sequence Number. This prevents Sequence Number overlaps for the
mundane point-to-point case. Multicast as described in <xref target="RFC5374"
format="default"/>, <xref target="RFC6407" format="default"/>, and <xref
target="I-D.ietf-ipsecme-g-ikev2" format="default"/> is a prominent example in w
hich
many senders share one secret and thus one SA. As such, implicit IV may only
be used with Multicast if some mechanisms are employed that prevent the
Sequence Number from overlapping for one SA; otherwise, implicit IV
<bcp14>MUST NOT</bcp14> be used with Multicast. </t>
<t>The IANA has updated the "Internet Key Exchange Version 2 (IKEv2) <t>This document defines three new encryption transforms that use
Parameters" <xref target="RFC7296"/> by adding new code points to the implicit IV. Unlike most encryption transforms defined to date, which
"Transform Type Values"/"Transform Type 1 - Encryption Algorithm can be used for both ESP and IKEv2, these transforms are defined for ESP
Transform IDs" registry <xref target="IANA"/>: only and cannot be used in IKEv2. The reason for this is that IKEv2 messag
es
don't contain a unique per-message value that can be used for IV
generation. The Message-ID field in the IKEv2 header is similar to the SN
field in the ESP header, but recent IKEv2 extensions <xref target="RFC6311
"
format="default"/> <xref target="RFC7383" format="default"/> do allow
it to repeat, so there is not an easy way to derive unique IV from IKEv2
header fields.</t>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has updated the "Internet Key Exchange Version 2 (IKEv2)
Parameters" registry <xref target="RFC7296" format="default"/> by adding
the following new code points to the "Transform Type 1 - Encryption
Algorithm Transform IDs" subregistry under the "Transform Type Values"
registry <xref target="IANA" format="default"/>:
<list hangIndent="3" style="hanging"> </t>
<t hangText="-">ENCR_AES_CCM_8_IIV: 29</t>
<t hangText="-">ENCR_AES_GCM_16_IIV: 30</t>
<t hangText="-">ENCR_CHACHA20_POLY1305_IIV: 31</t>
</list></t>
<t>These algorithms should be added with this document as ESP Reference <table anchor="iana-registry" align="left">
and "Not Allowed" for IKEv2 Reference.</t> <name>Additions to "Transform Type 1 - Encryption Algorithm Transform IDs" Reg
istry</name>
<thead>
<tr>
<th>Number</th>
<th>Name</th>
<th>ESP Reference</th>
<th>IKEv2 Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>29</td>
<td>ENCR_AES_CCM_8_IIV</td>
<td>RFC 8750</td>
<td>Not allowed</td>
</tr>
<tr>
<td>30</td>
<td>ENCR_AES_GCM_16_IIV</td>
<td>RFC 8750</td>
<td>Not allowed</td>
</tr>
<tr>
<td>31</td>
<td>ENCR_CHACHA20_POLY1305_IIV</td>
<td>RFC 8750</td>
<td>Not allowed</td>
</tr>
</tbody>
</table>
</section> </section>
<section title="Acknowledgements"> </middle>
<back>
<t>We would like to thank Valery Smyslov, Eric Vyncke, Alexey Melnikov, <displayreference target="I-D.ietf-ipsecme-g-ikev2" to="G-IKEv2"/>
Adam Roach, Magnus Nystrom (security directorate), as well as our three
Security ADs Eric Rescorla, Benjamin Kaduk and Roman Danyliw for their
valuable comments. We also would like to thank David Schinazi for its
implementation, as well as the ipseceme chairs Tero Kivinen and David
Waltermire for moving this work forward.</t>
<t>NOTE TO THE EDITOR Eric has a accent on E and Magnus has double <references>
points on o.</t> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3602.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3686.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4106.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4303.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4309.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5374.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6311.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6407.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7634.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7383.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</middle> FC.8174.xml"/>
<back> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<references title="Normative References"> FC.8221.xml"/>
&RFC2119; </references>
&RFC3602; <references>
&RFC3686; <name>Informational References</name>
&RFC4106;
<!-- &RFC4302; -->
&RFC4303;
&RFC4309;
&RFC5374;
&RFC6311;
&RFC6407;
&RFC7296;
&RFC7634;
&RFC7383;
<!-- &RFC8247; -->
&RFC8174;
&RFC8221;
</references>
<references title="Informational References"> <!-- draft-yeung-g-ikev2 Replaced by draft-ietf-ipsecme-g-ikev2, which is I-D Ex
&I-D.yeung-g-ikev2; ists -->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-ipsecme-g-ikev2.xml"/>
<reference anchor="BEAST" <reference anchor="BEAST" target="https://www.researchgate.net/publicati
target="https://www.researchgate.net/publication/266529975_Here_Come_The_Ninjas" on/266529975_Here_Come_The_Ninjas">
> <front>
<front>
<title>Here Come The xor Ninjas</title> <title>Here Come The xor Ninjas</title>
<author initials="T. Duong" surname="Thai" fullname="Thai <author initials="T." surname="Duong" fullname="Thai Duong">
Duong"> <organization/>
<organization />
</author> </author>
<author initials="J. Rizzo" surname="Juliano" <author initials="J." surname="Rizzo" fullname="Juliano Rizzo">
fullname="Juliano Rizzo"> <organization/>
<organization />
</author> </author>
<date day="13" month="May" year="2011" /> <date month="May" year="2011"/>
</front> </front>
<seriesInfo name="" value="" /> </reference>
</reference>
<reference anchor="IANA" <reference anchor="IANA" target="https://www.iana.org/assignments/ikev2-
target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml parameters">
#ikev2-parameters-5"> <front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author><organization>IANA</organization></author>
<front> </front>
<title>IANA IKEv2 Parameter - Type 1 - Encryption Algorithm </reference>
Transform IDs </title> </references>
<author/>
<date/>
</front>
</reference> </references>
</references>
</back> <section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>We would like to thank <contact fullname="Valery Smyslov"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Alexey Melnikov"/>,
<contact fullname="Adam Roach"/>, and <contact fullname="Magnus
Nyström"/> (security directorate) as well as our three Security ADs --
<contact fullname="Eric Rescorla"/>, <contact fullname="Benjamin
Kaduk"/>, and <contact fullname="Roman Danyliw"/> -- for their valuable
comments. We also would like to thank <contact fullname="David
Schinazi"/> for his implementation as well as
<contact fullname="Tero Kivinen"/> and <contact fullname="David
Waltermire"/> (the IPSECME Chairs) for moving this work forward.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 48 change blocks. 
452 lines changed or deleted 327 lines changed or added

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