Internet Engineering Task Force (IETF) V. Cakulev
Request for Comments: 6738 Alcatel Lucent
Category: Standards Track A. Lior
ISSN: 2070-1721 Bridgewater Systems
S. Mizikovsky
Alcatel Lucent
October 2012
Internet Engineering Task Force (IETF) V. Cakulev
Request for Comments: 6738 Alcatel Lucent
Category: Standards Track A. Lior
ISSN: 2070-1721 Bridgewater Systems
S. Mizikovsky
Alcatel Lucent
October 2012
Diameter IKEv2 SK: Using Shared Keys to Support Interaction between IKEv2 Servers and Diameter Servers
Diameter IKEv2 SK：使用共享密钥支持IKEv2服务器和Diameter服务器之间的交互
Abstract
摘要
The Internet Key Exchange Protocol version 2 (IKEv2) is a component of the IPsec architecture and is used to perform mutual authentication as well as to establish and to maintain IPsec Security Associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and Shared Key (SK).
Internet密钥交换协议版本2（IKEv2）是IPsec体系结构的一个组件，用于执行相互身份验证以及在各方之间建立和维护IPsec安全关联（SA）。IKEv2支持几种不同的身份验证机制，例如可扩展身份验证协议（EAP）、证书和共享密钥（SK）。
Diameter interworking for Mobile IPv6 between the Home Agent (HA), as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for SK-based authentication available with IKEv2. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK.
已指定作为Diameter客户端的归属代理（HA）与Diameter服务器之间移动IPv6的Diameter互通。然而，该规范侧重于EAP的使用，不包括对IKEv2提供的基于SK的认证的支持。本文档指定了当IKEv2对等方使用IKEv2和SK进行身份验证时，IKEv2服务器到Diameter服务器的通信。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6738.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6738.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
2.1. Abbreviations ..............................................4
3. Application Identifier ..........................................5
4. Protocol Description ............................................5
4.1. Support for IKEv2 and Shared Keys ..........................5
4.2. Session Management .........................................7
4.2.1. Session-Termination-Request/Answer ..................7
4.2.2. Abort-Session-Request/Answer ........................7
5. Command Codes for Diameter IKEv2 with SK ........................7
5.1. IKEv2-SK-Request (IKESKR) Command ..........................8
5.2. IKEv2-SK-Answer (IKESKA) Command ...........................9
6. Attribute-Value Pair Definitions ...............................10
6.1. IKEv2-Nonces ..............................................10
6.1.1. Ni .................................................10
6.1.2. Nr .................................................10
6.2. IKEv2-Identity ............................................10
6.2.1. Initiator-Identity .................................10
6.2.2. Responder-Identity .................................11
7. AVP Occurrence Tables ..........................................12
8. AVP Flag Rules .................................................13
9. IANA Considerations ............................................14
9.1. Command Codes .............................................14
9.2. AVP Codes .................................................14
9.3. AVP Values ................................................14
9.4. Application Identifier ....................................14
10. Security Considerations .......................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
2.1. Abbreviations ..............................................4
3. Application Identifier ..........................................5
4. Protocol Description ............................................5
4.1. Support for IKEv2 and Shared Keys ..........................5
4.2. Session Management .........................................7
4.2.1. Session-Termination-Request/Answer ..................7
4.2.2. Abort-Session-Request/Answer ........................7
5. Command Codes for Diameter IKEv2 with SK ........................7
5.1. IKEv2-SK-Request (IKESKR) Command ..........................8
5.2. IKEv2-SK-Answer (IKESKA) Command ...........................9
6. Attribute-Value Pair Definitions ...............................10
6.1. IKEv2-Nonces ..............................................10
6.1.1. Ni .................................................10
6.1.2. Nr .................................................10
6.2. IKEv2-Identity ............................................10
6.2.1. Initiator-Identity .................................10
6.2.2. Responder-Identity .................................11
7. AVP Occurrence Tables ..........................................12
8. AVP Flag Rules .................................................13
9. IANA Considerations ............................................14
9.1. Command Codes .............................................14
9.2. AVP Codes .................................................14
9.3. AVP Values ................................................14
9.4. Application Identifier ....................................14
10. Security Considerations .......................................15
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................16
The Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] is used to mutually authenticate two parities and to establish a Security Association (SA) that can be used to efficiently secure the communication between the IKEv2 peer and server, for example, using Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) [RFC4302]. The IKEv2 protocol allows several different mechanisms for authenticating an IKEv2 peer to be used, such as the Extensible Authentication Protocol (EAP), certificates, and SK.
互联网密钥交换协议版本2（IKEv2）[RFC5996]用于相互认证两个对等方，并建立安全关联（SA），该关联可用于有效保护IKEv2对等方和服务器之间的通信，例如，使用封装安全有效负载（ESP）[RFC4303]和/或认证头（AH）[RFC4302]。IKEv2协议允许使用几种不同的机制对IKEv2对等机进行身份验证，例如可扩展身份验证协议（EAP）、证书和SK。
From a service provider perspective, it is important to ensure that a user is authorized to use the services. Therefore, the IKEv2 server must verify that the IKEv2 peer is authorized for the requested services, possibly with the assistance of the operator's Diameter servers. [RFC5778] defines the home agent as a Diameter-client-to-Diameter-server communication when the mobile node authenticates using the IKEv2 protocol with the Extensible Authentication Protocol (EAP) [RFC3748] or using the Mobile IPv6 Authentication Protocol [RFC4285]. This document specifies the IKEv2-server-to-Diameter-server communication when the IKEv2 peer authenticates using IKEv2 with SK.
从服务提供商的角度来看，确保用户有权使用服务是很重要的。因此，IKEv2服务器必须验证IKEv2对等方是否已获得请求服务的授权，可能需要运营商Diameter服务器的协助。[RFC5778]当移动节点使用IKEv2协议和可扩展身份验证协议（EAP）[RFC3748]或使用移动IPv6身份验证协议[RFC4285]进行身份验证时，将归属代理定义为Diameter客户端到Diameter服务器的通信。本文档指定了当IKEv2对等方使用IKEv2和SK进行身份验证时，IKEv2服务器到Diameter服务器的通信。
Figure 1 depicts the reference architecture for this document.
图1描述了本文档的参考体系结构。
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | IKEv2 Server<->HAAA Server
Support | Interaction
Protocol | (this document)
v
+---------+ +---------------+
| IKEv2 | Front-End Protocol |IKEv2 Server/ |
| Peer |<-------------------->|Diameter Client|
+---------+ IKEv2 +---------------+
+--------+
|Diameter|
|Server |
+--------+
^
Back-End | IKEv2 Server<->HAAA Server
Support | Interaction
Protocol | (this document)
v
+---------+ +---------------+
| IKEv2 | Front-End Protocol |IKEv2 Server/ |
| Peer |<-------------------->|Diameter Client|
+---------+ IKEv2 +---------------+
Figure 1: Architecture Overview
图1：架构概述
An example use case for this architecture is Mobile IPv6 deployment in which the Mobile IPv6 signaling between the Mobile Node and the Home Agent is protected using IPsec. The Mobile node acts as the IKEv2 peer and the Home Agent acts as an IKEv2 server. In this use case, IKEv2 with SK-based initiator authentication is used for the setup of the IPsec SAs. The HA obtains the SK using the Diameter application specified in this document.
此体系结构的一个示例用例是移动IPv6部署，其中移动节点和归属代理之间的移动IPv6信令使用IPsec进行保护。移动节点充当IKEv2对等方，归属代理充当IKEv2服务器。在本用例中，使用具有基于SK的启动器身份验证的IKEv2来设置IPsec SAs。HA使用本文件中指定的Diameter应用程序获取SK。
This document assumes that the SK provided to the IKEv2 peer as well as the SK delivered to the IKEv2 server by the Diameter server are established or derived using the same rules. Furthermore, it assumes that these rules are agreed to by the external protocol on a peer side providing the key to the IKEv2 peer, and on the Diameter server side providing the key to the IKEv2 server. This document allows for the SK to be obtained for a specific IKEv2 session and exchanged between IKEv2 server and the Home Authentication, Authorization, and Accounting (HAAA) server. The protocol provides IKEv2 attributes to allow the HAAA to compute the SK specific to the session if desired (see Section 10). This is accomplished through the use of a new Diameter application specifically designed for performing IKEv2 authorization decisions. This document focuses on the IKEv2 server, as a Diameter client, communicating to the Diameter server, and it specifies the Diameter application needed for this communication. Other protocols leveraging this Diameter application MAY specify their own SK derivation scheme. For example see [X.S0047] and [X.S0058]. This document specifies the default procedure for derivation of the SK used in IKEv2 authentication when protocols leveraging this Diameter application do not specify their own derivation procedure. Selection of either default or other SK derivation procedure is done by the external protocol between the Peer and the Diameter Server, and is outside the scope of this document.
本文档假设提供给IKEv2对等机的SK以及Diameter服务器交付给IKEv2服务器的SK是使用相同的规则建立或派生的。此外，它假设外部协议在向IKEv2对等方提供密钥的对等方和向IKEv2服务器提供密钥的Diameter服务器端同意这些规则。本文档允许获取特定IKEv2会话的SK，并在IKEv2服务器和家庭身份验证、授权和计费（HAAA）服务器之间进行交换。协议提供IKEv2属性，允许HAAA在需要时计算特定于会话的SK（参见第10节）。这是通过使用专门设计用于执行IKEv2授权决策的新Diameter应用程序实现的。本文档重点介绍IKEv2服务器作为Diameter客户机与Diameter服务器通信，并指定此通信所需的Diameter应用程序。利用此Diameter应用程序的其他协议可以指定它们自己的SK派生方案。例如，请参见[X.S0047]和[X.S0058]。当利用此Diameter应用程序的协议未指定其自己的派生过程时，本文档指定了IKEv2身份验证中使用的SK派生的默认过程。默认或其他SK派生过程的选择由对等方和Diameter服务器之间的外部协议完成，不在本文档的范围内。
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]中所述进行解释。
AH Authentication Header
AH认证头
AVP Attribute-Value Pair
属性值对
EAP Extensible Authentication Protocol
可扩展认证协议
ESP Encapsulating Security Payload
封装安全有效载荷的ESP
HAAA Home Authentication, Authorization, and Accounting
HAAA家庭身份验证、授权和记帐
IKEv2 Internet Key Exchange Protocol version 2
IKEv2互联网密钥交换协议版本2
NAI Network Access Identifier
网络访问标识符
PSK Pre-Shared Key
预共享密钥
SA Security Association
南非安全协会
SK Shared Key
共享密钥
SPI Security Parameter Index
安全参数索引
This specification defines a new Diameter application and its respective Application Identifier:
本规范定义了新的直径应用及其各自的应用标识符：
Diameter IKE SK (IKESK) 11
直径IKESK（IKESK）11
The IKESK Application Identifier is used when the IKEv2 peer is to be authenticated and authorized using IKEv2 with SK-based authentication.
当使用基于SK的IKEv2身份验证对IKEv2对等方进行身份验证和授权时，使用IKESK应用程序标识符。
When IKEv2 is used with SK-based initiator authentication, the Diameter commands IKEv2-SK-Request/Answer defined in this document are used between the IKEv2 server and a Home AAA (HAAA) server to authorize the IKEv2 peer for the services. Upon receiving the IKE_AUTH message from the IKEv2 peer, the IKEv2 server uses the information received in IDi [RFC5996] to identify the IKEv2 peer and the SPI, if available, to determine the correct SK for this IKEv2 peer. If no SK associated with this IKEv2 peer is found, the IKEv2 server MUST send an Authorize-Only (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-SK-Request message to the HAAA to obtain the SK. If the IDi payload extracted from the IKE_AUTH message contains an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NAI), it SHALL be used by the IKEv2 server to populate the User-Name AVP in the Diameter message. Otherwise, it is out of scope of this document how the IKEv2 server maps the value received in the IDi payload to the User-Name AVP and whether or not the User-Name AVP is included in the IKEv2-SK-Request message. In the same Diameter message, the IKEv2 server SHALL also include the IKEv2-Nonces AVP with the initiator and responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange. Finally, the IKEv2 server SHALL include the IKEv2-Identity AVP in the IKEv2-SK-Request message. The Initiator-Identity AVP SHALL be populated with the IDi field extracted from the IKE_AUTH message. If the IDr payload was included in the IKE_AUTH message received from the IKEv2 peer, the IKEv2 server SHALL also include a Responder-Identity AVP populated with the received IDr.
当IKEv2与基于SK的启动器身份验证一起使用时，在IKEv2服务器和家庭AAA（HAAA）服务器之间使用本文档中定义的DIAMER命令IKEv2 SK Request/Answer来授权IKEv2对等方进行服务。IKEv2服务器从IKEv2对等方接收IKE_AUTH消息后，使用IDi[RFC5996]中接收到的信息来识别IKEv2对等方和SPI（如果可用），以确定该IKEv2对等方的正确SK。如果未找到与此IKEv2对等机关联的SK，则IKEv2服务器必须向HAAA发送仅授权（授权请求类型设置为“仅授权”）IKEv2 SK请求消息以获取SK。如果从IKE_AUTH消息提取的IDi有效载荷包含对Diameter基础设施有意义的标识，如网络访问标识符（NAI），IKEv2服务器应使用该标识在Diameter消息中填充用户名AVP。否则，IKEv2服务器如何将IDi有效负载中接收到的值映射到用户名AVP以及用户名AVP是否包含在IKEv2 SK请求消息中超出了本文的范围。在相同的Diameter消息中，IKEv2服务器还应包括初始IKEv2交换期间交换的发起方和响应方的IKEv2 Nonces AVP（Ni和Nr）。最后，IKEv2服务器应在IKEv2 SK请求消息中包含IKEv2标识AVP。应使用从IKE_认证消息中提取的IDi字段填充启动器标识AVP。如果IDr有效载荷包括在从IKEv2对等方接收的IKE_AUTH消息中，IKEv2服务器还应包括用接收到的IDr填充的响应者标识AVP。
The IKEv2 server sends the IKEv2-SK-Request message to the IKEv2 peer's HAAA. The Diameter message is routed to the correct HAAA per [RFC6733].
IKEv2服务器向IKEv2对等方的HAAA发送IKEv2 SK请求消息。根据[RFC6733]，Diameter消息被路由到正确的HAAA。
Upon receiving a Diameter IKEv2-SK-Request message from the IKEv2 server, the HAAA SHALL use the User-Name AVP (if present) and/or Initiator-Identity AVP to retrieve the associated keying material. When the default SK-generation procedure specified in this document is used, the peer side that provides the SK to the IKEv2 peer, as well as the Diameter server, SHALL use the same SK derivation that follows the methodology similar to that specified in Section 3.1 of [RFC5295], specifically:
收到来自IKEv2服务器的Diameter IKEv2 SK请求消息后，HAAA应使用用户名AVP（如果存在）和/或启动器标识AVP来检索相关的键控材料。当使用本文件中规定的默认SK生成程序时，向IKEv2对等方以及Diameter服务器提供SK的对等方应使用与[RFC5295]第3.1节中规定的方法类似的相同SK推导，具体如下：
SK = KDF(PSK, key label | "\0" | Ni | Nr | IDi | length)
SK=KDF（PSK，键标签|“\0”| Ni | Nr | IDi |长度）
Where:
哪里：
o KDF is the default key derivation function based on HMAC-SHA-256 as specified in Section 3.1.2 of [RFC5295].
o KDF是基于[RFC5295]第3.1.2节规定的HMAC-SHA-256的默认密钥派生函数。
o Pre-Shared Key (PSK) is the key available to the protocol leveraging this Diameter application, e.g., the long-term shared secret, or the Extended Master Session Key (EMSK) as the result of prior EAP authentication, etc. Selection of this value is left up to the protocol leveraging this Diameter application.
o 预共享密钥（PSK）是利用此Diameter应用程序的协议可用的密钥，例如，长期共享密钥，或作为先前EAP身份验证的结果的扩展主会话密钥（EMSK），等等。此值的选择由利用此Diameter应用程序的协议决定。
o Key label is set to 'sk4ikev2@ietf.org'.
o 键标签设置为'sk4ikev2@ietf.org'.
o | denotes concatenation
o |表示串联
o "\0" is a NULL octet (0x00 in hex)
o “\0”是空八位字节（十六进制中的0x00）
o Length is a 2-octet unsigned integer in network byte order of the output key length, in octets.
o Length是一个2个八位无符号整数，按输出密钥长度的网络字节顺序，以八位字节为单位。
When applications using this protocol define their own SK-generation algorithm, it is strongly RECOMMENDED that the nonces Ni and Nr be used in the computation. It is also RECOMMENDED that IDi be used. IDr SHOULD NOT be used in the SK generation algorithm. Applications that want to use IDr in the computation should take into consideration that the IDr asserted by the IKEv2 peer may not be the same as the IDr returned by the IKEv2 responder. This mismatch will result in different SKs being generated. The HAAA returns the SK to the IKEv2 server using the Key AVP as specified in [RFC6734].
当使用此协议的应用程序定义自己的SK生成算法时，强烈建议在计算中使用nonce Ni和Nr。还建议使用IDi。在SK生成算法中不应使用IDr。希望在计算中使用IDr的应用程序应考虑IKEv2对等方声明的IDr可能与IKEv2响应程序返回的IDr不同。这种不匹配将导致生成不同的SKs。HAAA使用[RFC6734]中指定的密钥AVP将SK返回给IKEv2服务器。
Once the IKEv2 server receives the SK from the HAAA, the IKEv2 server verifies the IKE_AUTH message received from the IKEv2 peer. If the verification of AUTH is successful, the IKEv2 server sends the IKE message back to the IKEv2 peer.
一旦IKEv2服务器从HAAA接收到SK，IKEv2服务器将验证从IKEv2对等方接收到的IKE_AUTH消息。如果身份验证成功，IKEv2服务器将IKE消息发送回IKEv2对等方。
The HAAA may maintain Diameter session state or may be stateless. This is indicated by the presence or absence of the Auth-Session-State AVP included in the answer message. The IKEv2 server MUST support the Authorization Session State Machine defined in [RFC6733].
HAAA可以保持Diameter会话状态，也可以是无状态的。这通过应答消息中包含的身份验证会话状态AVP的存在或不存在来表示。IKEv2服务器必须支持[RFC6733]中定义的授权会话状态机。
In the case where the HAAA is maintaining session state, when the IKEv2 server terminates the SA, it SHALL send a Session-Termination-Request (STR) message [RFC6733] to inform the HAAA that the authorized session has been terminated.
在HAAA保持会话状态的情况下，当IKEv2服务器终止SA时，它应发送会话终止请求（STR）消息[RFC6733]，通知HAAA授权会话已终止。
The Session-Termination-Answer (STA) message [RFC6733] is sent by the HAAA to acknowledge the notification that the session has been terminated.
HAAA发送会话终止应答（STA）消息[RFC6733]以确认会话已终止的通知。
The Abort-Session-Request (ASR) message [RFC6733] is sent by the HAAA to the IKEv2 server to terminate the authorized session. When the IKEv2 server receives the ASR message, it MUST delete the corresponding IKE_SA and all CHILD_SAs set up through it.
HAAA向IKEv2服务器发送中止会话请求（ASR）消息[RFC6733]，以终止授权会话。当IKEv2服务器接收到ASR消息时，它必须删除相应的IKE_SA和通过它设置的所有子SA。
The Abort-Session-Answer (ASA) message [RFC6733] is sent by the IKEv2 server in response to an ASR message.
IKEv2服务器发送中止会话应答（ASA）消息[RFC6733]以响应ASR消息。
This section defines new Command Code values that MUST be supported by all Diameter implementations conforming to this specification.
本节定义了所有符合本规范的直径实施必须支持的新命令代码值。
+------------------+---------+------+-----------------+-------------+
| Command Name | Abbrev. | Code | Section | Application |
| | | | Reference | |
+------------------+---------+------+-----------------+-------------+
| IKEv2-SK-Request | IKESKR | 329 | Section 5.1 | IKESK |
| | | | | |
| IKEv2-SK-Answer | IKESKA | 329 | Section 5.2 | IKESK |
+------------------+---------+------+-----------------+-------------+
+------------------+---------+------+-----------------+-------------+
| Command Name | Abbrev. | Code | Section | Application |
| | | | Reference | |
+------------------+---------+------+-----------------+-------------+
| IKEv2-SK-Request | IKESKR | 329 | Section 5.1 | IKESK |
| | | | | |
| IKEv2-SK-Answer | IKESKA | 329 | Section 5.2 | IKESK |
+------------------+---------+------+-----------------+-------------+
Table 1: Command Codes
表1：命令代码
The IKEv2-SK-Request message, indicated with the Command Code set to 329 and the 'R' bit set in the Command Flags field, is sent from the IKEv2 server to the HAAA to initiate IKEv2 with SK authorization. In this case, the Application-Id field of the Diameter header MUST be set to the Diameter IKE SK Application-Id (11).
IKEv2 SK请求消息由设置为329的命令代码和命令标志字段中设置的“R”位指示，从IKEv2服务器发送到HAAA，以通过SK授权启动IKEv2。在这种情况下，直径标头的应用程序Id字段必须设置为直径IKE SK应用程序Id（11）。
Message format
消息格式
<IKEv2-SK-Request> ::= < Diameter Header: 329, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ Origin-State-Id ]
[ User-Name ]
[ Key-SPI ]
{ IKEv2-Identity }
[ Auth-Session-State ]
{ IKEv2-Nonces }
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
<IKEv2-SK-Request> ::= < Diameter Header: 329, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ NAS-Identifier ]
[ NAS-IP-Address ]
[ NAS-IPv6-Address ]
[ NAS-Port ]
[ Origin-State-Id ]
[ User-Name ]
[ Key-SPI ]
{ IKEv2-Identity }
[ Auth-Session-State ]
{ IKEv2-Nonces }
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
The IKEv2-SK-Request message MUST include an IKEv2-Nonces AVP containing the Ni and Nr nonces swapped during initial IKEv2 exchange. The IKEv2-SK-Request message MAY contain a Key-SPI AVP (Key-SPI AVP is specified in [RFC6734]). If included, it contains the SPI that HAAA SHALL use, in addition to the other parameters (e.g., Initiator-Identity), to identify the appropriate SK. The IKEv2-SK-Request message MUST include IKEv2-Identity AVP. The Initiator-Identity AVP SHALL contain IDi as received in IKE_AUTH message. The Responder-Identity AVP SHALL be included in the IKEv2- SK-Request message, if IDr payload was included in the IKE_AUTH message received from the IKEv2 peer. If included, the Responder-Identity AVP contains the received IDr.
IKEv2 SK请求消息必须包括一个IKEv2 Nonces AVP，其中包含初始IKEv2交换期间交换的Ni和Nr Nonces。IKEv2 SK请求消息可能包含密钥SPI AVP（密钥SPI AVP在[RFC6734]中指定）。如果包括，它包含HAAA应使用的SPI，以及其他参数（例如，启动器标识），以识别适当的SK。IKEv2 SK请求消息必须包括IKEv2标识AVP。启动器标识AVP应包含IKE_认证消息中接收到的IDi。如果IDr有效载荷包含在从IKEv2对等方接收的IKE_AUTH消息中，则响应者标识AVP应包含在IKEv2-SK请求消息中。如果包括，响应者标识AVP包含接收到的IDr。
The IKEv2-SK-Answer (IKESKA) message, indicated by the Command Code field set to 329 and the 'R' bit cleared in the Command Flags field, is sent by the HAAA to the IKEv2 server in response to the IKESKR command. In this case, the Application-Id field of the Diameter header MUST be set to the Diameter IKE SK Application-Id (11).
由设置为329的命令代码字段和在命令标志字段中清除的“R”位指示的IKEv2 SK应答（IKESKA）消息由HAAA发送到IKEv2服务器以响应IKESKR命令。在这种情况下，直径标头的应用程序Id字段必须设置为直径IKE SK应用程序Id（11）。
Message format
消息格式
<IKEv2-SK-Answer> ::= < Diameter Header: 329, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Key ]
[ Responder-Identity ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
<IKEv2-SK-Answer> ::= < Diameter Header: 329, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ User-Name ]
[ Key ]
[ Responder-Identity ]
[ Auth-Session-State ]
[ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
[ Origin-State-Id ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ]
* [ Proxy-Info ]
* [ Route-Record ]
...
* [ AVP ]
If the authorization procedure is successful, then the IKEv2-SK-Answer message SHALL include the Key AVP as specified in [RFC6734]. The value of the Key-Type AVP SHALL be set to IKEv2 SK (3). The Keying-Material AVP SHALL contain the SK. If the Key-SPI AVP is received in IKEv2-SK-Request, the Key-SPI AVP SHALL be included in the Key AVP. The Key-Lifetime AVP may be included; if so, then the associated key SHALL NOT be used by the receiver of the answer if the lifetime has expired. Finally, the Responder-Identity AVP may be included.
如果授权程序成功，则IKEv2 SK应答消息应包括[RFC6734]中规定的密钥AVP。钥匙类型AVP的值应设置为IKEv2 SK（3）。键控材料AVP应包含SK。如果在IKEv2 SK请求中接收到密钥SPI AVP，则密钥SPI AVP应包含在密钥AVP中。可以包括密钥生存期AVP；如果是这样，那么如果生存期已过，则应答接收者不得使用相关密钥。最后，可以包括响应者身份AVP。
This section defines new AVPs for IKEv2 with SK.
本节定义了带有SK的IKEv2的新AVP。
The IKEv2-Nonces AVP (Code 587) is of type Grouped and contains the nonces exchanged between the IKEv2 peer and the IKEv2 server during IKEv2 initial exchange. The nonces are used for SK generation.
IKEv2 Nonces AVP（代码587）属于分组类型，包含IKEv2对等方和IKEv2服务器在IKEv2初始交换期间交换的Nonces。nonce用于生成SK。
IKEv2-Nonces ::= < AVP Header: 587 >
{Ni}
{Nr}
*[AVP]
IKEv2-Nonces ::= < AVP Header: 587 >
{Ni}
{Nr}
*[AVP]
The Ni AVP (AVP Code 588) is of type OctetString and contains the IKEv2 initiator nonce as contained in Nonce Data field.
Ni AVP（AVP代码588）的类型为OctetString，包含包含在nonce数据字段中的IKEv2启动器nonce。
The Nr AVP (AVP Code 589) is of type OctetString and contains the IKEv2 responder nonce as contained in Nonce Data field.
Nr AVP（AVP代码589）的类型为OctetString，包含nonce数据字段中包含的IKEv2响应器nonce。
The IKEv2-Identity AVP (Code 590) is of type Grouped and contains the Initiator and possibly Responder identities as included in IKE_AUTH message sent from the IKEv2 peer to the IKEv2 server.
IKEv2标识AVP（代码590）属于分组类型，包含发起方和可能的响应方标识，这些标识包含在从IKEv2对等方发送到IKEv2服务器的IKE_AUTH消息中。
IKEv2-Identity ::= < AVP Header: 590 >
{Initiator-Identity}
[Responder-Identity]
*[AVP]
IKEv2-Identity ::= < AVP Header: 590 >
{Initiator-Identity}
[Responder-Identity]
*[AVP]
The Initiator-Identity AVP (AVP Code 591) is of type Grouped and contains the identity type and identification data of the IDi payload of the IKE_AUTH message.
发起方标识AVP（AVP代码591）属于分组类型，并且包含IKE_AUTH消息的IDi有效载荷的标识类型和标识数据。
Initiator-Identity ::= < AVP Header: 591 >
{ID-Type}
{Identification-Data}
*[AVP]
Initiator-Identity ::= < AVP Header: 591 >
{ID-Type}
{Identification-Data}
*[AVP]
The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the ID type value of IDi payload of the IKE_AUTH message.
ID类型AVP（AVP代码592）属于枚举类型，并且包含IKE_AUTH消息的IDi有效负载的ID类型值。
The Identification-Data AVP (AVP Code 593) is of type OctetString and contains the Identification Data field of IDi payload of the IKE_AUTH message.
标识数据AVP（AVP代码593）为OctetString类型，包含IKE_AUTH消息的IDi有效载荷的标识数据字段。
The Responder-Identity AVP (AVP Code 594) is of type Grouped and contains the identity type and identification data of the IDr payload of the IKE_AUTH message.
响应者标识AVP（AVP代码594）属于分组类型，并且包含IKE_AUTH消息的IDr有效载荷的标识类型和标识数据。
Responder-Identity ::= < AVP Header: 594 >
{ID-Type}
{Identification-Data}
*[AVP]
Responder-Identity ::= < AVP Header: 594 >
{ID-Type}
{Identification-Data}
*[AVP]
The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the ID type value of IDr payload of the IKE_AUTH message.
ID类型AVP（AVP代码592）属于枚举类型，并且包含IKE_AUTH消息的IDr有效负载的ID类型值。
The Identification-Data AVP (AVP Code 593) is of type OctetString and contains the Identification Data field of IDr payload of the IKE_AUTH message.
标识数据AVP（AVP代码593）是OctetString类型，并且包含IKE_AUTH消息的IDr有效载荷的标识数据字段。
The following tables present the AVPs defined or used in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table.
下表显示了本文档中定义或使用的AVP及其在Diameter消息中的出现情况。请注意，此表中未显示只能出现在分组AVP中的AVP。
The table uses the following symbols:
该表使用以下符号：
0: The AVP MUST NOT be present in the message.
0:消息中不得存在AVP。
0+: Zero or more instances of the AVP MAY be present in the message.
0+：消息中可能存在零个或多个AVP实例。
0-1: Zero or one instance of the AVP MAY be present in the message.
0-1：消息中可能存在零个或一个AVP实例。
1: One instance of the AVP MUST be present in the message.
1：消息中必须存在一个AVP实例。
+-------------------+
| Command Code |
|---------+---------+
AVP Name | IKESKR | IKESKA |
-------------------------------|---------+---------+
Key | 0 | 0-1 |
Key-SPI | 0-1 | 0 |
IKEv2-Nonces | 1 | 0 |
IKEv2-Identity | 1 | 0 |
Responder-Identity | 0 | 0-1 |
+---------+---------+
+-------------------+
| Command Code |
|---------+---------+
AVP Name | IKESKR | IKESKA |
-------------------------------|---------+---------+
Key | 0 | 0-1 |
Key-SPI | 0-1 | 0 |
IKEv2-Nonces | 1 | 0 |
IKEv2-Identity | 1 | 0 |
Responder-Identity | 0 | 0-1 |
+---------+---------+
IKESKR and IKESKA Commands AVP Table
IKESKR和IKESKA命令AVP表
The following table describes the Diameter AVPs, their AVP Code values, types, and possible flag values. The Diameter base protocol [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5.
下表介绍了直径AVP、其AVP代码值、类型和可能的标志值。Diameter基本协议[RFC6733]在第4.5节中规定了AVP的AVP标志规则。
+---------+
|AVP Flag |
| Rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------+----+----+
|Key 581 Note 1 Grouped | M | V |
+---------------------------------------------+----+----+
|Keying-Material 583 Note 1 OctetString| M | V |
+---------------------------------------------+----+----+
|Key-Lifetime 584 Note 1 Integer64 | M | V |
+---------------------------------------------+----+----+
|Key-SPI 585 Note 1 Unsigned32 | M | V |
+---------------------------------------------+----+----+
|Key-Type 582 Note 1 Enumerated | M | V |
+---------------------------------------------+----+----+
|IKEv2-Nonces 587 6.1 Grouped | M | V |
+---------------------------------------------+----+----+
|Ni 588 6.1.1 OctetString| M | V |
+---------------------------------------------+----+----+
|Nr 589 6.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|IKEv2-Identity 590 6.2 Grouped | M | V |
+---------------------------------------------+----+----+
|Initiator-Identity 591 6.2.1 Grouped | M | V |
+---------------------------------------------+----+----+
|ID-Type 592 6.2.1.1 Enumerated | M | V |
+---------------------------------------------+----+----+
|Identification-Data 593 6.2.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|Responder-Identity 594 6.2.2 Grouped | M | V |
+---------------------------------------------+----+----+
+---------+
|AVP Flag |
| Rules |
+----+----+
AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------+----+----+
|Key 581 Note 1 Grouped | M | V |
+---------------------------------------------+----+----+
|Keying-Material 583 Note 1 OctetString| M | V |
+---------------------------------------------+----+----+
|Key-Lifetime 584 Note 1 Integer64 | M | V |
+---------------------------------------------+----+----+
|Key-SPI 585 Note 1 Unsigned32 | M | V |
+---------------------------------------------+----+----+
|Key-Type 582 Note 1 Enumerated | M | V |
+---------------------------------------------+----+----+
|IKEv2-Nonces 587 6.1 Grouped | M | V |
+---------------------------------------------+----+----+
|Ni 588 6.1.1 OctetString| M | V |
+---------------------------------------------+----+----+
|Nr 589 6.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|IKEv2-Identity 590 6.2 Grouped | M | V |
+---------------------------------------------+----+----+
|Initiator-Identity 591 6.2.1 Grouped | M | V |
+---------------------------------------------+----+----+
|ID-Type 592 6.2.1.1 Enumerated | M | V |
+---------------------------------------------+----+----+
|Identification-Data 593 6.2.1.2 OctetString| M | V |
+---------------------------------------------+----+----+
|Responder-Identity 594 6.2.2 Grouped | M | V |
+---------------------------------------------+----+----+
AVP Flag Rules Table
AVP标志规则表
Note 1: The Key, Keying-Material, Key-Lifetime, Key-SPI, and Key-Type AVPs are defined in [RFC6734].
注1：密钥、密钥材料、密钥寿命、密钥SPI和密钥类型AVP在[RFC6734]中定义。
IANA has allocated a Command Code value for the following new command from the Command Code namespace defined in [RFC6733].
IANA已从[RFC6733]中定义的命令代码命名空间为以下新命令分配了命令代码值。
Command Code | Value
---------------------------------+------
IKEv2-SK-Request/Answer | 329
Command Code | Value
---------------------------------+------
IKEv2-SK-Request/Answer | 329
This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in [RFC6733].
本规范要求IANA从[RFC6733]中定义的AVP代码命名空间注册以下新AVP。
o IKEv2-Nonces - 587
o IKEv2 Nonces-587
o Ni - 588
o Ni-588
o Nr - 589
o Nr-589
o IKEv2-Identity - 590
o IKEv2标识-590
o Initiator-Identity - 591
o 启动器标识-591
o ID-Type - 592
o 身份证类型-592
o Identification-Data - 593
o 识别数据-593
o Responder-Identity - 594
o 响应者身份-594
The AVPs are defined in Section 6.
AVP的定义见第6节。
IANA is requested to create a new value for the Key-Type AVP. The new value 3 signifies that IKEv2 SK is being sent.
请求IANA为密钥类型AVP创建一个新值。新值3表示正在发送IKEv2 SK。
This specification requires IANA to allocate one new value "Diameter IKE SK" from the Application Identifier namespace defined in [RFC6733].
本规范要求IANA从[RFC6733]中定义的应用程序标识符命名空间中分配一个新值“Diameter IKE SK”。
Application Identifier | Value
-------------------------------+------
Diameter IKE SK (IKESK) | 11
Application Identifier | Value
-------------------------------+------
Diameter IKE SK (IKESK) | 11
The security considerations of the Diameter base protocol [RFC6733] are applicable to this document (e.g., it is expected that Diameter protocol is used with security mechanism and that Diameter messages are secured).
Diameter基本协议[RFC6733]的安全注意事项适用于本文件（例如，预期Diameter协议与安全机制一起使用，并且Diameter消息是安全的）。
In addition, the assumption is that the IKEv2 server and the Diameter server, where the SK is generated, are in a trusted relationship. Hence, the assumption is that there is an appropriate security mechanism to protect the communication between these servers. For example, the IKEv2 server and the Diameter server would be deployed in the same secure network or would utilize transport-layer security as specified in [RFC6733].
此外，假设生成SK的IKEv2服务器和Diameter服务器处于可信关系。因此，假设存在适当的安全机制来保护这些服务器之间的通信。例如，IKEv2服务器和Diameter服务器将部署在同一个安全网络中，或者使用[RFC6733]中指定的传输层安全性。
The Diameter messages between the IKEv2 server and the HAAA may be transported via one or more AAA brokers or Diameter agents. In this case, the IKEv2 server to the Diameter server AAA communication is hop-by-hop protected; hence, it relies on the security properties of the intermediating AAA inter-connection networks, AAA brokers, and Diameter agents. Furthermore, any agents that process IKEv2-SK-Answer messages can see the contents of the Key AVP.
IKEv2服务器和HAAA之间的Diameter消息可以通过一个或多个AAA代理或Diameter代理进行传输。在这种情况下，IKEv2服务器到Diameter服务器AAA通信是逐跳保护的；因此，它依赖于中间AAA互连网络、AAA代理和Diameter代理的安全属性。此外，任何处理IKEv2 SK应答消息的代理都可以看到密钥AVP的内容。
To mitigate the threat of exposing a long-lived PSK, this specification expects that the HAAA derive and return the associated SK to the IKEv2 server. Given that SK derivation is security-critical, for the SK derivation, this specification recommends the use of short-lived secrets, possibly based on a previous network access authentication, if such secrets are available. To ensure key freshness and to limit the key scope, this specification strongly recommends the use of nonces included in the IKEv2-SK-Request. The specifics of key derivation depend on the security characteristics of the system that is leveraging this specification (for example, see [X.S0047] and [X.S0058]); therefore, this specification does not define how the Diameter server derives required keys for these systems. For systems and protocols that leverage this Diameter application but do not specify the key derivation procedure, this document specifies the default key derivation procedure that preserves expected security characteristics.
为了减轻暴露长寿命PSK的威胁，本规范要求HAAA派生相关SK并将其返回给IKEv2服务器。鉴于SK派生是安全关键的，对于SK派生，本规范建议使用短期机密，如果此类机密可用，则可能基于先前的网络访问身份验证。为了确保密钥新鲜度并限制密钥范围，本规范强烈建议使用IKEv2 SK请求中包含的nonce。密钥派生的细节取决于利用此规范的系统的安全特性（例如，请参见[X.S0047]和[X.S0058]）；因此，本规范未定义Diameter服务器如何为这些系统导出所需密钥。对于利用此Diameter应用程序但未指定密钥派生过程的系统和协议，本文档指定保留预期安全特性的默认密钥派生过程。
[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月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[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月。
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733]Fajardo，V.，Arkko，J.，Loughney，J.，和G.Zorn，“直径基准协议”，RFC 67332012年10月。
[RFC6734] Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", RFC 6734, October 2012.
[RFC6734]Zorn，G.，Wu，W.和V.Cakulev，“加密密钥传输的直径属性值对”，RFC 6734，2012年10月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[RFC4285]Patel，A.，Leung，K.，Khalil，M.，Akhtar，H.，和K.Chowdhury，“移动IPv6认证协议”，RFC 4285，2006年1月。
[RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction", RFC 5778, February 2010.
[RFC5778]Korhonen，J.，Tschofenig，H.，Bournelle，J.，Giaretta，G.，和M.Nakhjiri，“Diameter移动IPv6：对归属代理到Diameter服务器交互的支持”，RFC 5778，2010年2月。
[X.S0047] 3GPP2: X.S0047, "Mobile IPv6 Enhancements", February 2009.
[X.S0047]3GPP2:X.S0047，“移动IPv6增强”，2009年2月。
[X.S0058] 3GPP2: X.S0058, "WiMAX-HRPD Interworking: Core Network Aspects", June 2010.
[X.S0058]3GPP2:X.S0058，“WiMAX HRPD互通：核心网络方面”，2010年6月。
Authors' Addresses
作者地址
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
Violeta Cakulev Alcatel-Lucent美国新泽西州默里山3D-517山地大道600号，邮编：07974
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Avi Lior Bridgewater Systems 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
加拿大安大略省渥太华市特里福克斯大道303号Avi Lior Bridgewater Systems K2K 3J1
Phone: +1 613-591-6655
EMail: avi.ietf@lior.org
Phone: +1 613-591-6655
EMail: avi.ietf@lior.org
Semyon Mizikovsky Alcatel Lucent 600 Mountain Ave. 3C-506 Murray Hill, NJ 07974 US
Semyon Mizikovsky Alcatel-Lucent 600 Mountain Ave.美国新泽西州默里山3C-506号，邮编：07974
Phone: +1 908 582 0729
EMail: Simon.Mizikovsky@alcatel-lucent.com
Phone: +1 908 582 0729
EMail: Simon.Mizikovsky@alcatel-lucent.com