Independent Submission Y. Nir
Request for Comments: 6023 Check Point
Category: Experimental H. Tschofenig
ISSN: 2070-1721 NSN
H. Deng
China Mobile
R. Singh
Cisco
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
Cisco
October 2010
A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)
Internet密钥交换版本2（IKEv2）安全关联（SA）的无子女启动
Abstract
摘要
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.
本文档描述了对Internet密钥交换版本2（IKEv2）协议的扩展，该协议允许在不生成子SA的情况下创建和验证IKEv2安全关联（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 http://www.rfc-editor.org/info/rfc6023.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6023.
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 (http://trustee.ietf.org/license-info) 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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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盒。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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的原因。
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.
如果通知包含在IKE_SA_INIT响应中，则支持启动器可以发送第5节所述的修改后的IKE_AUTH请求。如果通知不存在，则启动器不得发送修改的IKE_AUTH请求。
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.
通过在IKE_SA_INIT响应中包含通知来公布支持的支持响应程序必须处理修改的IKE_AUTH请求，并且必须使用修改的IKE_AUTH响应进行回复。如果发起方未发送修改的IKE_认证请求，则此类响应方不得使用修改的IKE_认证响应进行响应。
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.
已配置为不支持此协议扩展的支持响应程序的行为必须与不支持此扩展时的行为相同。如果客户机发送IKE_AUTH请求（如第5节所述进行了修改），则它不得使用通知来公布功能，并应使用无效的_语法Notify有效负载进行回复。
The Notify payload is as described in [RFC5996]
通知有效负载如[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_分配的值。
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].
为简洁起见，此处仅介绍身份验证交换的可扩展身份验证协议（EAP）版本。非EAP版本非常相似。下图基于[RFC5996]的附录C.3。
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[V+][N+]
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[V+][N+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+]
第一个响应<--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+]
最后一次答复<--AUTH[CP（CFG_REPLY）]，[V+][N+]
Note what is missing:
请注意缺少的内容：
o The optional notifications: IPCOMP_SUPPORTED, USE_TRANSPORT_MODE, ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
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。
This protocol variation inherits all the security properties of regular IKEv2 as described in [RFC5996].
此协议变体继承了[RFC5996]中所述的常规IKEv2的所有安全属性。
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.
使用IKE_身份验证交换的身份验证有效负载进行身份验证。此外，两个对等方都必须配置为使用交换的这种变体，以便响应方接受来自发起方的无子女提议。
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”的通知消息类型。
[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月。
[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.
[SecureBeacon]Sheffer，Y.和Y.Nir，“安全信标：安全检测可信网络”，正在进行的工作，2009年6月。
Authors' Addresses
作者地址
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
以色列特拉维夫Hasolelim街5号Yoav Nir Check Point软件技术有限公司67897
EMail: ynir@checkpoint.com
EMail: ynir@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Hui Deng China Mobile 53A,Xibianmennei Ave. Xuanwu District Beijing 100053 China
惠登中国移动北京市宣武区西边门内大街53A，邮编100053
EMail: denghui02@gmail.com
EMail: denghui02@gmail.com
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
EMail: rsj@cisco.com
Phone: +91 80 4103 3563
EMail: rsj@cisco.com