A Childless Initiation of the IKE SACheck Point Software Technologies Ltd.5 Hasolelim st.Tel Aviv67897Israelynir@checkpoint.comNokia Siemens NetworksLinnoitustie 6Espoo02600Finland+358 (50) 4871445Hannes.Tschofenig@gmx.nethttp://www.tschofenig.priv.atChina Mobile53A,Xibianmennei Ave.Xuanwu DistrictBeijing100053Chinadenghui02@gmail.comCisco Systems, Inc.O'Shaugnessy RoadBangaloreKarnataka560025India+91 80 4103 3563rsj@cisco.com
Security Area
Internet-Draft This document describes an extension to the IKEv2 protocol that allows an IKE SA to be
created and authenticated without generating a child SA. IKEv2, as specified in 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. An IKE SA without any child SA is not a fruitless endeavor. Even without Child SAs, an
IKE SA allows: Checking the liveness status of the peer via liveness checks. Quickly setting up child SAs without public key operations, and without user
interaction. Authentication of the peer. Detection of NAT boxes between two hosts on the InternetThe 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 . Several scenarios motivated this proposal: 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). Location aware security, as in . 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. 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". 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
. Childless IKE can be used for where we use IKEv2 as a
method for user authentication. 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. A future extension may have IKE SAs used for generating keying material for
applications, without ever requiring child SAs. This is similar to what is doing in TLS. 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. 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 , within the IKE_SA_INIT
response. A supporting initiator MAY send the modified IKE_AUTH request, described in , 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. 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. 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
. The VID payload is as described in with a 16-octets data field
as follows: 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. 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
. Note what is missing: The optional notifications: IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED,
and NON_FIRST_FRAGMENTS_ALSO. The SA payload. The traffic selector payloads. Any notification, extension payload or VendorID that has to do with child SA
negotiation. TBA There are no IANA considerations for this document.Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keywordInternet Key Exchange (IKEv2) ProtocolIKEv2 Clarifications and Implementation GuidelinesNokiaVPN ConsortiumSecure Beacon: Securely Detecting a Trusted NetworkCheck PointCheck PointKeying Material Exporters for Transport Layer Security (TLS)RTFM, Inc.Security of H(e)NB3GPPThe Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) MethodNokia Siemens NetworksNokia Siemens NetworksNECToshibaFrance Telecom