One document matched: draft-nir-ike-nochild-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="yes" ?>
<?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-ike-nochild-00" category="std">
<front>
<title abbrev="IKE WITHOUT CHILD">A Childless Initiation of the IKE SA</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>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date year="2009"/>
<area>Security Area</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document describes an extension to the IKEv2 protocol that allows an IKE SA to be
created and authenticated without generating a child SA.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> IKEv2, as specified in <xref target="RFC4306"/> requires that in an IKE_AUTH exchange, a
child SA is created along with the IKE SA. This requirement is sometimes inconvenient, as
some implementations need to use IKE for authentication only, while other implementations
would like to set up the IKE SA before there is any actual traffic to protect.</t>
<t> An IKE SA without any child SA is not a fruitless endeavor. Even without Child SAs, an
IKE SA allows:<list style="symbols">
<t> Checking the liveness status of the peer via liveness checks.</t>
<t> Quickly setting up child SAs without public key operations, and/or without user
interaction.</t>
<t> Authentication of the peer.</t></list></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>
</section>
</section>
<section anchor="scenarios" title="Usage Scenarios">
<t> Several scenarios motivated this proposal:<list style="symbols">
<t> Interactive remote access VPN: the user tells the client to "connect", which may
involve interactive authentication. There is still no traffic, but some may come later.
Since there is no traffic, it is impossible for the gateway to know what selectors to
use (how to narrow down the client's proposal).</t>
<t> Location aware security, as in <xref target="SecureBeacon"/>. The user is roaming
between trusted and untrusted networks. While in an untrusted network, all traffic
should be encrypted, but on the trusted network, only the IKE SA needs to be
maintained.</t>
<t> A future extension may have IKE SAs used for generating keying material for
applications, without ever requiring child SAs. This is similar to what <xref
target="extractors"/> is doing in TLS.</t></list></t>
<t> In some of these cases it may be possible to create a dummy Child SA and then remove
it, but this creates undesirable side effects and race conditions. Moreover, the IKE
peer might see the deletion of the Child SA as a reason to delete the IKE SA.</t>
</section>
<section anchor="outline" title="Protocol Outline">
<t> The decision of whether or not to support an IKE_AUTH exchage without the piggy-backed
child SA negotiation is ultimately up to the reponsder. A supporting resonder MUST
include the VID payload, described in <xref target="vid"/>, within the IKE_INIT
response.</t>
<t> A supporting initiator MAY send the modified IKE_AUTH request, described in <xref
target="ike_auth"/>, if the VID payload was included in the IKE_INIT response. The
initiator MUST NOT send the modified IKE_AUTH request if the VID was not present.</t>
<t> A supporting responder that advertised the VID payload in the IKE_INIT response MUST
process a modified IKE_AUTH request, and MUST reply with a modified IKE_AUTH response.
Such a responder MUST NOT reply with a modified IKE_AUTH response if the initiator did
not send a modified IKE_AUTH request.</t>
</section>
<section anchor="vid" title="VID Payload">
<t> The VID payload is as described in <xref target="RFC4306"/> with the data as follows:
<figure>
<artwork><![CDATA[
73da4b423dd9f75563b15b9f918650fc
]]></artwork>
</figure></t>
<t> This value was obtained by hashing the string "Will do IKE_AUTH without child SA payloads"</t>
</section>
<section anchor="ike_auth" title="Modified IKE_AUTH Exchange">
<t> For brevity, only the EAP version of an AUTH exchange will be presented here. The
non-EAP version is very similar. The figures below are based on appendix A.3 of
<xref target="RFC4718"/>.<figure>
<artwork><![CDATA[
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[V+]
first response <-- IDr, [CERT+], AUTH,
EAP,
[V+]
/ --> EAP
repeat 1..N times |
\ <-- EAP
last request --> AUTH
last response <-- AUTH,
[CP(CFG_REPLY)],
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
]]></artwork>
</figure></t>
<t> Note what is missing:<list style="symbols">
<t> The optional notifications: IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED,
and NON_FIRST_FRAGMENTS_ALSO.</t>
<t> The SA payload.</t>
<t> The traffic selector payloads.</t>
<t> Any notification, extension payload or VendorID that has to do with child SA
negotiation.</t></list></t>
</section>
<section anchor="security" title="Security Considerations">
<t> TBA </t>
</section>
<section anchor="iana" title="IANA Considerations">
<t> There are no IANA considerations for this document.</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='RFC4306'>
<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<date year='2005' month='December' />
</front>
<seriesInfo name='RFC' value='4306' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4306.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc4306.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc4306.xml' />
</reference>
<reference anchor='RFC4718'>
<front>
<title>IKEv2 Clarifications and Implementation Guidelines</title>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization>Nokia</organization></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization>VPN Consortium</organization></author>
<date year='2006' month='October' />
</front>
<seriesInfo name='RFC' value='4718' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc4718.txt' />
<format type='HTML' target='http://xml.resource.org/public/rfc/html/rfc4718.html' />
<format type='XML' target='http://xml.resource.org/public/rfc/xml/rfc4718.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='SecureBeacon'>
<front>
<title>Secure Beacon: Securely Detecting a Trusted Network</title>
<author initials='Y.' surname='Sheffer' fullname='Yaron Sheffer'>
<organization>Check Point</organization></author>
<author initials='Y.' surname='Nir' fullname='Yoav Nir'>
<organization>Check Point</organization></author>
<date year='2008' month='January' />
</front>
<seriesInfo name='Internet-Draft' value='draft-sheffer-ipsec-secure-beacon' />
<format type='TXT'
target='http://tools.ietf.org/id/draft-sheffer-ipsec-secure-beacon' />
<format type='HTML'
target='http://tools.ietf.org/html/draft-sheffer-ipsec-secure-beacon' />
</reference>
<reference anchor='extractors'>
<front>
<title>Keying Material Exporters for Transport Layer Security (TLS)</title>
<author initials='E.' surname='Rescorla' fullname='Eric Rescorla'>
<organization>RTFM, Inc.</organization></author>
<date year='2009' month='March' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-tls-extractor' />
<format type='TXT'
target='http://tools.ietf.org/id/draft-ietf-tls-extractor' />
<format type='HTML'
target='http://tools.ietf.org/html/draft-ietf-tls-extractor' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:30:15 |