One document matched: draft-nir-ipsecme-childless-01.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-ipsecme-childless-01" category="std">
<front>
<title abbrev="Childless IKE Initiation">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>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="NSN">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="H." surname="Deng" fullname="Hui Deng">
<organization abbrev="China Mobile">China Mobile</organization>
<address>
<postal>
<street>53A,Xibianmennei Ave.</street>
<street>Xuanwu District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>denghui02@gmail.com</email>
</address>
</author>
<author initials="R." surname="Singh" fullname="Rajeshwar Singh Jenwar">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>O'Shaugnessy Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560025</code>
<country>India</country>
</postal>
<phone>+91 80 4103 3563</phone>
<email>rsj@cisco.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 the IKE_AUTH exchange try
to create a child SA along with the IKE SA. This requirement is sometimes inconvenient or
superfluous, as some implementations need to use IKE for authentication only, while others
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 without user
interaction.</t>
<t> Authentication of the peer.</t>
<t> Detection of NAT boxes between two hosts on the Internet</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> An IKE SA may be needed between peers even when there is not IPsec traffic. Such IKE
peers use liveness checks, and report to the administrator the status of the "VPN
links".</t>
<t> IKE may be used on some physically secure links, where authentication is necessary,
but traffic protection is not. An example of this in the PON links as described in
<xref target="3GPP.33.820"/>.</t>
<t> Childless IKE can be used for <xref target="EAP-IKEv2"/> where we use IKEv2 as a
method for user authentication.</t>
<t> A node receiving IPsec traffic with an unrecognized SPI should send an INVALID_SPI
notification. If this traffic comes from a peer, which it recognizes based on its IP
address, then this node may set up an IKE SA so as to be able to send the notification
in a protected IKE_INFORMATIONAL exchange. </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_SA_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_SA_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_SA_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>
<t> A supporting responder that has been configured not to support this extension to the
protocol MUST behave as the same as if it didn't support this extension. It MUST NOT
advertise the capability with a VID payload, and it SHOULD reply with an INVALID_SYNTAX
Notify payload if the client sends an IKE_AUTH request that is modified as described in
<xref target="ike_auth"/>.</t>
</section>
<section anchor="vid" title="VID Payload">
<t> The VID payload is as described in <xref target="RFC4306"/> with a 16-octets data field
as follows:</t>
<figure>
<artwork><![CDATA[
73da4b423dd9f75563b15b9f918650fc
]]></artwork>
</figure>
<t> This value was obtained by hashing the string "Will do IKE_AUTH without child SA payloads"
using the MD5 algorithms. Note that this is only an explanation, and the actual content
of the VID data MUST be the value above.</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"/>.</t>
<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> 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://tools.ietf.org/html/rfc2119' />
</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://tools.ietf.org/html/rfc4306' />
</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://tools.ietf.org/html/rfc4718' />
</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='2009' month='June' />
</front>
<seriesInfo name='Internet-Draft' value='draft-sheffer-ipsecme-secure-beacon' />
<format type='TXT'
target='http://tools.ietf.org/id/draft-sheffer-ipsecme-secure-beacon' />
<format type='HTML'
target='http://tools.ietf.org/html/draft-sheffer-ipsecme-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>
<reference anchor="3GPP.33.820">
<front>
<title>Security of H(e)NB</title>
<author>
<organization>3GPP</organization>
</author>
<date year='2009' month='March' />
</front>
<seriesInfo name="3GPP TR" value="33.820 8.0.0" />
<format type="HTML" target="http://www.3gpp.org/ftp/Specs/html-info/33820.htm" />
</reference>
<reference anchor='EAP-IKEv2'>
<front>
<title>The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method</title>
<author initials='H.' surname='Tschofenig' fullname='H. Tschofenig'>
<organization>Nokia Siemens Networks</organization></author>
<author initials='D.' surname='Kroeselberg' fullname='D. Kroeselberg'>
<organization>Nokia Siemens Networks</organization></author>
<author initials='A.' surname='Pashalidis' fullname='A. Pashalidis'>
<organization>NEC</organization></author>
<author initials='Y.' surname='Ohba' fullname='Y. Ohba'>
<organization>Toshiba</organization></author>
<author initials='F.' surname='Bersani' fullname='F. Bersani'>
<organization>France Telecom</organization></author>
<date year='2008' month='February' />
</front>
<seriesInfo name='RFC' value='5106' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc5106.txt' />
<format type='HTML' target='http://tools.ietf.org/html/rfc5106' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 14:44:33 |