One document matched: draft-nir-ipsecme-cafr-00.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-00" category="std">
<front>
<title abbrev="child adoption following reauth">Adopting 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, adoption, 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="adopt_child_sa" title="Adopting Child SAs">
<t> This document defines a new notification that is added to the IKE_AUTH exchange that is
used to re-authenticate. The notification proves that the current participant in the
IKE_AUTH exchange is the same one that had participated in the old IKE SA. If both peers
send this notification, and it verifies correctly, 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> Following a successful re-authentication exchange, the old IKE SA is deleted by the
Initiator.</t>
<section anchor="notif_format" title="The ADOPT_CHILD_SAS Notification">
<figure><preamble>The ADOPT_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 ! ADOPT_CHILD_SAS Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork><postamble>Figure 1</postamble>
</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>ADOPT_CHILD_SAS Notify Message Type (2 octets) - MUST be xxxxx, the value assigned
for ADOPT_CHILD_SAS. TBA by IANA.</t>
<t>Notification Data (variable) - contains the proof of ownership of the previous IKE
SA. Calculation of this field is described in <xref target="pop_calc" />.</t></list></t>
</section>
<section anchor="pop_calc" title="Calculating the Proof of Possession Value">
<figure><preamble>The notification data field in the ADOPT_CHILD_SAS notification is
calculated as follows:</preamble>
<artwork><![CDATA[
InitiatorPOP = prf(SK_pi, "Adopting Child SAs for Initiator")
ResponderPOP = ptr(SK_pr, "Adopting Child SAs for Responder")
]]></artwork>
</figure>
<t> InitiatorPOP and ResponderPOP are respectively sent the initiator and responder in the
IKE_AUTH exchange that creates the reauthenticated IKE SA. The roles may be reversed from
those of the original IKE SA, but it is still the new Initiator that uses the old SK_pi
value. The algorithms used, the PRF keys and the length of the output are all those from
the old IKE SA, not the new one.</t>
</section>
<section anchor="pop_verif" title="Verifying the Proof of Possesion Value">
<t> Both sides of the IKE_AUTH exchange should be in possession of the SK_pi and SK_pr
values from the previous IKE SA. This allows both sides to make the calculation and
verify that it is correct. This verification MUST be done only after the other side has
been authenticated. If the value does not verify, the IKE_AUTH exchange MUST be
terminated, and an INVALID_SYNTAX notification MUST be sent.</t>
<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.</t>
<t> The authenticated identities of both sides are the same as those in the old 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. See <xref target="race" /> for a discussion of a possible race condition.</t>
<t> The proof of possession values in the ADOPT_CHILD_SAS notification both validated.
The responder MUST NOT continue in sending the last IKE_AUTH packet if this condition
is not satisfied. See <xref target="race" /> for a discussion of what happens if the
responder's notification does not validate.</t></list></t>
</section>
</section>
<section anchor="race" title="Dealing With the Possible Race Condition">
<t> The sections above describe two kinds of failures in the IKE_AUTH exchange:<list style="numbers">
<t> An authentication failure. This could be something as sinister as an attack, or as
innocent as a temporary failure to contact an OCSP server.</t>
<t> A validation failure of the ADOPT_CHILD_SAS notification.</t></list></t>
<t> If either of those failures occurs for the Initiator, there is no problem. The IKE_AUTH
exchange is aborted, the old IKE SA is still valid, and all the Child SAs belong to that
old IKE SA.</t>
<t> If, however, the failure occurs for the Responder, we may have a problem. Having sent the
last IKE_AUTH response, the responder is confident that the exchange has completed
successfully, and can transfer the Child SAs to the new IKE SA. However, when the Initiator
sees that last response, one of the two errors happens, and this leads it to delete the new
IKE SA. The Responder erases the new IKE SA, deleting with it all the Child SAs. The result
is a mismatch in databases, where the Initiator still has the valid SAs, while the
Responder does not.</t>
<t> If the Child SAs have been transferred, and the new IKE SA has been deleted, but the old
IKE SA has not yet been deleted, then the Responder MUST delete the old IKE SA (using a
DELETE payload) immediately after receiving the deletion of the new IKE SA. If the Child
SAs have not yet been transferred, then the Responder MAY keep the old IKE SA along with
the Child SAs until they are deleted by the peer or expire according to policy.</t>
<t> The Initiator MUST NOT delete the old IKE SA because of a failure of IKE to create a new
IKE SA. The old IKE SA may only be deleted if policy dictates it, such as when a
reauthentication timer expires.</t>
<t> Following a successful verification and transfer of the Child SAs, the Initiator SHOULD
delete 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="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 "ADOPT_CHILD_SAS"</t>
</section>
<section anchor="security" title="Security Considerations">
<t> Comparing the authenticated identities of the new IKE SA with those of the old IKE SA is
critical. Without it, attackers would be able to authenticate as themselves, steal the
Child SAs, and then close them. The proof of possession seems to be superfluous, and in
most cases it really is. However, there are some uses of IKE by multiple entities with a
shared identity and a shared credential. Calculating and verifying the proof of possession
blocks such entities from stealing each others SAs. </t>
<t> An on-path attacker may get the Initiator to send the ADOPT_CHILD_SAS notification before
failing authentication. This notification is a PRF calculated with a secret key over a
known message. The security properties of PRFs are such that this does not reveal any
secret data such as IKE SA keys.</t>
</section>
<section anchor="delta" title="Changes from Previous Versions">
<t> First version </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 14:46:25 |