Independent Submission                                            Y. Nir
Request for Comments: 6023                                   Check Point
Category: Experimental                                     H. Tschofenig
ISSN: 2070-1721                                                      NSN
                                                                 H. Deng
                                                            China Mobile
                                                                R. Singh
                                                            October 2010
Independent Submission                                            Y. Nir
Request for Comments: 6023                                   Check Point
Category: Experimental                                     H. Tschofenig
ISSN: 2070-1721                                                      NSN
                                                                 H. Deng
                                                            China Mobile
                                                                R. Singh
                                                            October 2010

A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)




This document describes an extension to the Internet Key Exchange version 2 (IKEv2) protocol that allows an IKEv2 Security Association (SA) to be created and authenticated without generating a Child SA.


Status of This Memo


This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.


This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文档为互联网社区定义了一个实验协议。这是对RFC系列的贡献,独立于任何其他RFC流。RFC编辑器已选择自行发布此文档,并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准;见RFC 5741第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2010 IETF信托基金和确定为文件作者的人员。版权所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。

1. Introduction
1. 介绍

IKEv2, as specified in [RFC5996], requires that the IKE_AUTH exchange try to create a Child SA along with the IKEv2 SA. This requirement is sometimes inconvenient or superfluous, as some implementations need to use IKEv2 for authentication only, while others would like to set up the IKEv2 SA before there is any actual traffic to protect. The extension described in this document allows the creation of an IKEv2 SA without also attempting to create a Child SA. The terms IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are defined in [RFC5996]

[RFC5996]中指定的IKEv2要求IKE_身份验证交换尝试与IKEv2 SA一起创建子SA。此要求有时不方便或多余,因为一些实现只需要将IKEv2用于身份验证,而其他实现则希望在有任何实际流量需要保护之前设置IKEv2 SA。本文档中描述的扩展允许创建IKEv2 SA,而无需尝试创建子SA。[RFC5996]中定义了术语IKEv2、IKEv2 SA和子SA以及各种IKEv2交换

An IKEv2 SA without any Child SA is not a fruitless endeavor. Even without Child SAs, an IKEv2 SA allows:

没有任何子SA的IKEv2 SA不是徒劳的。即使没有子SA,IKEv2 SA也允许:

o Checking the liveness status of the peer via liveness checks.

o 通过活动性检查检查对等方的活动性状态。

o Quickly setting up Child SAs without public key operations and without user interaction.

o 快速设置子SA,无需公钥操作和用户交互。

o Authentication of the peer.

o 对等方的身份验证。

o Detection of NAT boxes between two hosts on the Internet.

o 检测Internet上两台主机之间的NAT盒。

1.1. Conventions Used in This Document
1.1. 本文件中使用的公约

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 [RFC2119].


2. Usage Scenarios
2. 使用场景

Several scenarios motivated this proposal:


o 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).

o 交互式远程访问VPN:用户告诉客户端“连接”,这可能涉及交互式身份验证。仍然没有车辆,但有些可能会晚些时候来。由于没有流量,网关不可能知道要使用什么选择器(如何缩小客户建议的范围)。

o Location-aware security, as in [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 IKEv2 SA needs to be maintained.

o 位置感知安全,如[SecureBeacon]中所述。用户正在受信任和不受信任的网络之间漫游。在不受信任的网络中,所有通信都应该加密,但在受信任的网络上,只需要维护IKEv2 SA。

o An IKEv2 SA may be needed between peers even when there is not IPsec traffic. Such IKEv2 peers use liveness checks, and report to the administrator the status of the "VPN links".

o 即使没有IPsec通信,对等方之间也可能需要IKEv2 SA。此类IKEv2对等点使用活动性检查,并向管理员报告“VPN链路”的状态。

o IKEv2 may be used on some physically secure links, where authentication is necessary but traffic protection is not. An example of this is the Passive Optical Network (PON) links as described in [3GPP.33.820].

o IKEv2可用于某些物理安全链路,其中需要身份验证,但不需要流量保护。这方面的一个例子是[3GPP.33.820]中描述的无源光网络(PON)链路。

o Childless IKEv2 can be used for [RFC5106] where we use IKEv2 as a method for user authentication.

o 无子女IKEv2可用于[RFC5106],其中我们使用IKEv2作为用户身份验证的方法。

o A node receiving IPsec traffic with an unrecognized Security Parameter Index (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 IKEv2 SA so as to be able to send the notification in a protected INFORMATIONAL exchange.

o 接收具有无法识别的安全参数索引(SPI)的IPsec通信的节点应发送无效的\u SPI通知。如果该流量来自对等方(它根据其IP地址识别),则该节点可以设置IKEv2 SA,以便能够在受保护的信息交换中发送通知。

o A future extension may have IKEv2 SAs used for generating keying material for applications, without ever requiring Child SAs. This is similar to what [RFC5705] is doing in Transport Layer Security (TLS).

o 未来的扩展可能会使用IKEv2 SAs为应用程序生成键控材料,而不需要子SAs。这类似于[RFC5705]在传输层安全性(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 IKEv2 peer might see the deletion of the Child SA as a reason to delete the IKEv2 SA.

在其中一些情况下,可能会创建一个虚拟子SA,然后将其删除,但这会产生不良的副作用和竞争条件。此外,IKEv2对等方可能会将子SA的删除视为删除IKEv2 SA的原因。

3. Protocol Outline
3. 协议大纲

The decision of whether or not to support an IKE_AUTH exchange without the piggy-backed Child SA negotiation is ultimately up to the responder. A supporting responder MUST include the Notify payload, described in Section 4, within the IKE_SA_INIT response.

是否支持IKE_AUTH交换而不进行piggy-backed Child SA协商的决定最终取决于响应者。支持响应程序必须在IKE_SA_INIT响应中包含第4节所述的通知有效负载。

A supporting initiator MAY send the modified IKE_AUTH request, described in Section 5, if the notification was included in the IKE_SA_INIT response. The initiator MUST NOT send the modified IKE_AUTH request if the notification was not present.


A supporting responder that has advertised support by including the notification 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 notification, and it SHOULD reply with an INVALID_SYNTAX Notify payload if the client sends an IKE_AUTH request that is modified as described in Section 5.


4. 无子女IKEV2支持的通知

The Notify payload is as described in [RFC5996]


                            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    ! Childless Notify Message Type !
                            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    ! Childless Notify Message Type !

o Protocol ID (1 octet) MUST be 1, as this message is related to an IKEv2 SA.

o 协议ID(1个八位字节)必须为1,因为此消息与IKEv2 SA相关。

o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of [RFC5996].

o SPI大小(1个八位字节)必须为零,符合[RFC5996]第3.10节的规定。

o Childless Notify Message Type (2 octets) - MUST be 16418, the value assigned for CHILDLESS_IKEV2_SUPPORTED.

o 无子女通知消息类型(2个八位字节)-必须为16418,支持为无子女IKEV2_分配的值。

5. Modified IKE_AUTH Exchange
5. 修改的IKE_身份验证交换

For brevity, only the Extensible Authentication Protocol (EAP) version of an AUTH exchange will be presented here. The non-EAP version is very similar. The figures below are based on Appendix C.3 of [RFC5996].


    first request       --> IDi,
                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
    first request       --> IDi,
                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],

first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+]


/ --> EAP repeat 1..N times | \ <-- EAP

/-->EAP重复1..N次| \<--EAP

last request --> AUTH


last response <-- AUTH, [CP(CFG_REPLY)], [V+][N+]


Note what is missing:



o 可选通知:支持IPCOMP、使用传输模式、不支持ESP、TFC和非优先片段。

o The SA payload.

o SA有效载荷。

o The traffic selector payloads.

o 交通选择器有效载荷。

o Any notification, extension payload or VendorID that has to do with Child SA negotiation.

o 与子SA协商有关的任何通知、扩展负载或供应商ID。

6. Security Considerations
6. 安全考虑

This protocol variation inherits all the security properties of regular IKEv2 as described in [RFC5996].


The new notification carried in the initial exchange advertises the capability, and cannot be forged or added by an adversary without being detected, because the response to the initial exchange is


authenticated with the AUTH payload of the IKE_AUTH exchange. Furthermore, both peers have to be configured to use this variation of the exchange in order for the responder to accept a childless proposal from the initiator.


7. IANA Considerations
7. IANA考虑

IANA has assigned a notify message type from the "IKEv2 Notify Message Types" registry with the name "CHILDLESS_IKEV2_SUPPORTED" and the value "16418".

IANA已从“IKEv2 notify message Types”注册表中分配了一个名为“CHILDLESS_IKEv2_SUPPORTED”且值为“16418”的通知消息类型。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.

[RFC5996]Kaufman,C.,Hoffman,P.,Nir,Y.,和P.Eronen,“互联网密钥交换协议版本2(IKEv2)”,RFC 59962010年9月。

8.2. Informative References
8.2. 资料性引用

[3GPP.33.820] 3GPP, "Security of H(e)NB", 3GPP TR 33.820 8.0.0, March 2009.

[3GPP.33.820]3GPP,“H(e)NB的安全”,3GPP TR 33.820 8.0.012009年3月。

[RFC5106] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008.

[RFC5106]Tschofenig,H.,Kroeselberg,D.,Pashalidis,A.,Ohba,Y.,和F.Bersani,“可扩展认证协议互联网密钥交换协议版本2(EAP-IKEv2)方法”,RFC 5106,2008年2月。

[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.

[RFC5705]Rescorla,E.“传输层安全(TLS)关键材料导出器”,RFC 57052010年3月。

[SecureBeacon] Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting a Trusted Network", Work in Progress, June 2009.


Authors' Addresses


Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel

以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司67897


Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland

Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600

   Phone: +358 (50) 4871445
   Phone: +358 (50) 4871445

Hui Deng China Mobile 53A,Xibianmennei Ave. Xuanwu District Beijing 100053 China



Rajeshwar Singh Jenwar Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India

印度卡纳塔克邦班加罗尔O'Shaugnessy路Rajeshwar Singh Jenwar Cisco Systems,Inc.560025

   Phone: +91 80 4103 3563
   Phone: +91 80 4103 3563