One document matched: draft-nir-ipsecme-cafr-01.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-ipsecme-cafr-01" category="std">
<front>
<title abbrev="child adoption following reauth">Handing Over Child SAs Following Re-Authentication in IKEv2</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>6789735</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date />
<area>Security</area>
<workgroup>IPsecME Working Group</workgroup>
<keyword>IKEv2, reauth, reauthentication, Child SA, childless</keyword>
<abstract>
<t> This document describes an extension to the IKEv2 protocol whereby Child SAs are moved to
the new IKE SA following re-authentication. This allows for a smoother transition with no
loss of connectivity.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> The Internet Key Exchange version 2 (IKEv2) protocol, as specified in
<xref target="RFC5996bis" /> associates Child SAs with the IKE SAs under which the exchange
that created them took place. With the deletion of the IKE SA due to expiry, policy change,
or an explicit message from the peer, the child SAs associated with it are implicitly
closed as described in section 1.4.1 of the IKEv2 document. This behavior is not desired
when IKE SAs are replaced rather than deleted, because those child SAs could still be
valid and there is no security reason to create new ones prematurely.</t>
<t> There are two cases where an IKE SA is replaced. <list style="numbers">
<t> Rekeying, where new keys are generated. This is described in section 2.18 of RFC 5996.
This is done mainly for key freshness.</t>
<t> Re-Authentication, where both sides authenticate, and new keys are generated. This is
done as part of a risk management policy, to limit the time that compromised IKE SA keys
can be used to provide the attacker access to the network. No reauthentication exchange
is specified in the RFC. Instead, it's simply the Initial and Authentication exchanges
done as if from scratch. This is described in section 2.8.3 of RFC 5996.</t></list></t>
<t> For rekeying, RFC 5996 provides a way to avoid having to re-create all child SAs. When
an IKE SA is rekeyed, all the Child SAs under the old IKE SA are inherited by the new IKE
SA, so that the subsequent deletion of the old IKE SA does not affect the Child SAs. This
behavior is described in section 2.8 paragraph 4 of RFC 5996.</t>
<t> For reauthentication, RFC 5996 does not provide a similar mechanism, and section 2.8.3
explicitly says that Child SAs need to be created from scratch. This is often inconvenient,
as IPsec systems usually create Child SAs only in response to traffic and multiple Child
SAs may exist for a single IKE SA. The protocol extension in this draft closes this gap.</t>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<t>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 <xref target="RFC2119"/>.</t>
<t> The terms IKE SA, Child SA, Rekeying, and Reauthentication are as described in the RFC
5996.</t>
</section>
</section>
<section anchor="HAND_OVER_CHILD_sa" title="Handing Over Child SAs">
<t> This document defines a new notification that can be sent over an old IKE SA, just after
an IKE_AUTH exchange has been used to re-authenticate. The notification tells the peer to
transfer all Child SAs that belong to the current (old) IKE SA to be owned by the new IKE
SA, so that when the old IKE SA is deleted, those Child SAs are not. If both peers send this
notification, all Child SAs belonging to the old IKE SA are immediately inherited by the
new IKE SA.</t>
<t> In addition to the Child SAs, any IP address assigned to either peer through the use of
the CFG payload (as described in section 2.19 of RFC 5996), is also associated with the new
IKE SA.</t>
<t> The new notification MAY be accompanied by a DELETE payload, so as to transfer the Child
SAs and delete the old IKE SA at the same time.</t>
<section anchor="notif_format" title="The HAND_OVER_CHILD_SAS Notification">
<figure><preamble>The HAND_OVER_CHILD_SA notification is formatted as follows:</preamble>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! HAND_OVER_CHILD_SAS Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
]]></artwork>
</figure>
<t><list style="symbols">
<t>Protocol ID (1 octet) MUST be 1, denoting an IKE SA. Note that previous versions of
RFC 5996 explicitly mentioned the possibility, but the current version omits this as
prior to this specification there were no cases where the value 1 should have been
used.</t>
<t>SPI Size (1 octet) MUST be 16, as that is the size of the concatenation of the IKE
SPIs.</t>
<t> Security Parameter Index (16 octets) - contains the concatenated SPIs of the old
IKE SA. The Initiator SPI comes first, similar to the first 16 bytes of the IKE
header.</t>
<t>HAND_OVER_CHILD_SAS Notify Message Type (2 octets) - MUST be xxxxx, the value
assigned for HAND_OVER_CHILD_SAS. TBA by IANA.</t></list></t>
</section>
<section anchor="notif_verif" title="Verifying the HAND_OVER_CHILD_SAS Notification">
<t> To go through with the new IKE SA inheriting the SAs of the old IKE SA, all of the
following MUST apply:<list style="symbols">
<t> Both sides have to be successfully authenticated, and the new IKE SA has to be
established.</t>
<t> The authenticated identities of both sides under the new IKE SA are the same as those
under the old IKE SA. If the authenticated identity of one peer differs from the
authenticated identity that it had in the previous IKE SA, the other side MUST respond
with an INVALID_SYNTAX notification.</t></list></t>
<t> If either of the above conditions does not apply, a conformant implementation MUST NOT
send the HAND_OVER_CHILD_SAS Notification. Additionally, an implementation MUST NOT hand
over the child SAs if the other side has not sent the notification, and MUST hand them
over if both it and the other side had sent the notification.</t>
</section>
</section>
<section anchor="diagram" title="The Illustrated Protocol">
<t>The Informational exchange after creating a new IKE SA:</t>
<figure><artwork><![CDATA[
Initiator Responder
-----------------------------------------------------------------
HDR, SK {
N(HAND_OVER_IKE_SAS, new IKE SA SPIs),
DELETE
} -->
HDR, SK {
N(HAND_OVER_IKE_SAS, new IKE SA SPIs)
<-- }
Figure 2
]]></artwork></figure>
<t> Note that in the above figure, the HDR has the IKE SPIs of the old IKE SAs, and the SK
payload uses the keys of the old IKE SA, because this message is sent over the old IKE SA.</t>
</section>
<section anchor="interact" title="Interaction with Other Standards">
<t> This document changes things so that there is often no need to create new Child SAs along
with the new IKE SA when reauthenticating. This makes the full IKE_AUTH exchange with the
piggy-backed Child SA exchange (as described in RFC 5996) superfluous. Implementations
should consider implementing the childless extension of IKEv2 (<xref target="RFC6023" />)
in addition to this specification.</t>
</section>
<!-- ====================================================================== -->
<section anchor="ack" title="Acknowledgements">
<t> The author would like to thank Valery Smyslov for the suggestion of moving the hand-over
from the IKE_AUTH to an Informational under the old IKE SA. This changed (in version -01)
simplified the protocol significantly.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> IANA is requested to assign a notify message type from the status types range
(16418-40959) of the "IKEv2 Notify Message Types" registry with name "HAND_OVER_CHILD_SAS"</t>
</section>
<section anchor="security" title="Security Considerations">
<t> The HAND_OVER_CHILD_SAS notification is sent protected by the old IKE SA. This protects
against stealing child SAs. The requirement for sameness of authenticated identity protects
against errors by one peer transferring child SAs to some other peer, although we cannot
think of any attack that would exploit this.</t>
</section>
<section anchor="delta" title="Changes from Previous Versions">
<t>[NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION]</t>
<t> Version -01 moved the sending of the notification from the IKE_AUTH exchange that is part
of reauthentication to the Informational exchange that is part of closing the old IKE SA.
This made cryptographic binding to the old IKE SA unnecessary.</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5703' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor="RFC5996bis">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author initials="C" surname="Kaufman" fullname="Charlie Kaufman"><organization/></author>
<author initials="P" surname="Hoffman" fullname="Paul Hoffman"><organization/></author>
<author initials="Y" surname="Nir" fullname="Yoav Nir"><organization/></author>
<author initials="P" surname="Eronen" fullname="Pasi Eronen"><organization/></author>
<author initials="T" surname="Kivinen" fullname="Tero Kivinen"><organization/></author>
<date month="August" day="9" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-kivinen-ipsecme-ikev2-rfc5996bis-00"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC6023">
<front>
<title>A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)</title>
<author initials="Y." surname="Nir" fullname="Y. Nir"><organization/></author>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig"><organization/></author>
<author initials="H." surname="Deng" fullname="H. Deng"><organization/></author>
<author initials="R." surname="Singh" fullname="R. Singh"><organization/></author>
<date year="2010" month="October"/>
</front>
<seriesInfo name="RFC" value="6023"/>
<format type="TXT" octets="12560" target="http://www.rfc-editor.org/rfc/rfc6023.txt"/>
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:29:41 |