[要約] 要約：RFC 6738は、IKEv2サーバーとDiameterサーバーの相互作用をサポートするために共有キーを使用する方法について説明しています。 目的：このRFCの目的は、IKEv2プロトコルとDiameterプロトコルの統合を可能にし、セキュアな通信を確保するために、共有キーを使用する方法を提供することです。
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).
インターネットキーエクスチェンジプロトコルバージョン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ピアがSKでIKEv2を使用して認証する場合のIKEv2-server-to-Diameter-server通信を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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]は、2つのパリティを相互認証し、IKEv2ピアとサーバー間の通信を効率的に保護するために使用できるセキュリティアソシエーション（SA）を確立するために使用されます。セキュリティペイロード（ESP）[RFC4303]または認証ヘッダー（AH）[RFC4302]。 IKEv2プロトコルを使用すると、拡張認証プロトコル（EAP）、証明書、SKなど、IKEv2ピアを認証するためのさまざまなメカニズムを使用できます。
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サーバーは、おそらくオペレーターのDiameterサーバーの支援を得て、IKEv2ピアが要求されたサービスに対して許可されていることを確認する必要があります。 [RFC5778]は、モバイルノードがIKEv2プロトコルと拡張認証プロトコル（EAP）[RFC3748]またはモバイルIPv6認証プロトコル[RFC4285]を使用して認証する場合、ホームエージェントをDiameterクライアントからDiameterサーバーへの通信として定義します。このドキュメントは、IKEv2ピアがSKでIKEv2を使用して認証する場合のIKEv2-server-to-Diameter-server通信を指定します。
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 +---------------+
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シグナリングがIPsecを使用して保護されているモバイルIPv6展開です。モバイルノードはIKEv2ピアとして機能し、ホームエージェントはIKEv2サーバーとして機能します。この使用例では、SKベースのイニシエーター認証を使用するIKEv2がIPsec SAのセットアップに使用されます。 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アプリケーションを使用することによって実現されます。このドキュメントでは、Diameterサーバーと通信するDiameterクライアントとしてのIKEv2サーバーに焦点を当て、この通信に必要な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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
AH Authentication Header
AH認証ヘッダー
AVP Attribute-Value Pair
AVP属性値ペア
EAP Extensible Authentication Protocol
EAP拡張認証プロトコル
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
SK共有キー
SPI Security Parameter Index
SPIセキュリティパラメータインデックス
This specification defines a new Diameter application and its respective Application Identifier:
この仕様は、新しいDiameterアプリケーションとそのそれぞれのアプリケーション識別子を定義します。
Diameter IKE SK (IKESK) 11
ぢあめてｒ いけ ＳＫ （いけＳＫ） １１
The IKESK Application Identifier is used when the IKEv2 peer is to be authenticated and authorized using IKEv2 with SK-based authentication.
IKEvアプリケーションピアは、IKEv2ピアがSKベースの認証でIKEv2を使用して認証および承認される場合に使用されます。
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ベースのイニシエーター認証で使用される場合、このドキュメントで定義されているDiameterコマンドIKEv2-SK-Request / Answerは、IKEv2サーバーとホームAAA（HAAA）サーバーの間で使用され、サービスのIKEv2ピアを承認します。 IKEv2ピアからIKE_AUTHメッセージを受信すると、IKEv2サーバーはIDi [RFC5996]で受信した情報を使用して、IKEv2ピアとSPI（利用可能な場合）を識別し、このIKEv2ピアの正しいSKを決定します。このIKEv2ピアに関連付けられたSKが見つからない場合、IKEv2サーバーはAuthorize-Only（Auth-Request-Typeを "Authorize-Only"に設定）Diameter IKEv2-SK-RequestメッセージをHAAAに送信してSKを取得する必要があります。 IKE_AUTHメッセージから抽出されたIDiペイロードに、ネットワークアクセス識別子（NAI）などのDiameterインフラストラクチャにとって意味のあるIDが含まれている場合、IKEv2サーバーはこれを使用して、Diameterメッセージにユーザー名AVPを入力する必要があります。それ以外の場合、IKEv2サーバーがIDiペイロードで受信した値をユーザー名AVPにマップする方法と、ユーザー名AVPがIKEv2-SK-Requestメッセージに含まれているかどうかは、このドキュメントの範囲外です。同じDiameterメッセージで、IKEv2サーバーは、初期IKEv2交換中に交換されたイニシエーターとレスポンダーのナンス（NiおよびNr）を持つIKEv2-Nonces AVPも含める必要があります（SHALL）。最後に、IKEv2サーバーは、IKEv2-SK-RequestメッセージにIKEv2-Identity AVPを含める必要があります。 Initiator-Identity AVPには、IKE_AUTHメッセージから抽出されたIDiフィールドを設定する必要があります（SHALL）。 IDrペイロードがIKEv2ピアから受信したIKE_AUTHメッセージに含まれていた場合、IKEv2サーバーは、受信したIDrが入力されたResponder-Identity 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-SK-RequestメッセージをIKEv2ピアのHAAAに送信します。 Diameterメッセージは、[RFC6733]に従って正しい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:
HAAAは、IKEv2サーバーからDiameter IKEv2-SK-Requestメッセージを受信すると、User-Name AVP（存在する場合）やInitiator-Identity AVPを使用して、関連するキー情報を取得します（SHALL）。このドキュメントで指定されているデフォルトのSK生成手順が使用される場合、IKEv2ピアにSKを提供するピア側とDiameterサーバーは、セクション3.1で指定されているのと同様の方法に従う同じSK派生を使用する必要があります（SHALL）。 [RFC5295]の具体的：
SK = KDF(PSK, key label | "\0" | Ni | Nr | IDi | length)
SK = KDF（PSK、キーラベル| "\ 0" | Ni | Nr | IDi | length）
Where:
ただし：
o KDF is the default key derivation function based on HMAC-SHA-256 as specified in Section 3.1.2 of [RFC5295].
o [RFC5295]のセクション3.1.2で指定されているように、KDFは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」はNULLオクテット（16進数で0x00）
o Length is a 2-octet unsigned integer in network byte order of the output key length, in octets.
o 長さは、出力キーの長さのネットワークバイトオーダーの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生成アルゴリズムを定義する場合、ノンスNiおよびNrを計算で使用することを強くお勧めします。 IDiを使用することも推奨されます。 IDrは、SK生成アルゴリズムでは使用しないでください。計算でIDrを使用するアプリケーションでは、IKEv2ピアによってアサートされたIDrが、IKEv2レスポンダによって返されたIDrと同じでない可能性があることを考慮する必要があります。この不一致により、異なるSKが生成されます。 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メッセージを確認します。 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セッション状態を維持する場合と、ステートレスの場合があります。これは、応答メッセージに含まれるAuth-Session-State 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を終了すると、承認されたセッションが終了したことをHAAAに通知するために、Session-Termination-Request（STR）メッセージ[RFC6733]を送信する必要があります。
The Session-Termination-Answer (STA) message [RFC6733] is sent by the HAAA to acknowledge the notification that the session has been terminated.
Session-Termination-Answer（STA）メッセージ[RFC6733]は、セッションが終了したという通知を確認するためにHAAAによって送信されます。
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.
Abort-Session-Request（ASR）メッセージ[RFC6733]は、承認されたセッションを終了するために、HAAAによってIKEv2サーバーに送信されます。 IKEv2サーバーは、ASRメッセージを受信すると、対応するIKE_SAおよびそれを介して設定されたすべてのCHILD_SAを削除する必要があります。
The Abort-Session-Answer (ASA) message [RFC6733] is sent by the IKEv2 server in response to an ASR message.
Abort-Session-Answer（ASA）メッセージ[RFC6733]は、ASRメッセージへの応答としてIKEv2サーバーによって送信されます。
This section defines new Command Code values that MUST be supported by all Diameter implementations conforming to this specification.
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートする必要がある新しいコマンドコード値を定義します。
+------------------+---------+------+-----------------+-------------+
| 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-Requestメッセージは、コマンドコードが329に設定され、コマンドフラグフィールドに「R」ビットが設定されて示され、IKEv2サーバーからHAAAに送信され、SK認証でIKEv2を開始します。この場合、DiameterヘッダーのApplication-IdフィールドをDiameter IKE SK Application-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 ]
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-Requestメッセージには、最初のIKEv2交換中にスワップされたNiおよびNrナンスを含むIKEv2-Nonces AVPを含める必要があります。 IKEv2-SK-RequestメッセージはKey-SPI AVPを含むかもしれません（Key-SPI AVPは[RFC6734]で指定されています）。含まれている場合、適切なSKを識別するために、他のパラメーター（たとえば、Initiator-Identity）に加えて、HAAAが使用する必要があるSPIが含まれます。 IKEv2-SK-Requestメッセージには、IKEv2-Identity AVPを含める必要があります。 Initiator-Identity AVPには、IKE_AUTHメッセージで受信したIDiが含まれている必要があります（SHALL）。 IDrペイロードがIKEv2ピアから受信したIKE_AUTHメッセージに含まれている場合は、レスポンダIDのAVPをIKEv2- SK-Requestメッセージに含める必要があります。含まれている場合、Responder-Identity 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).
IKEv2-SK-Answer（IKESKA）メッセージ（コマンドコードフィールドが329に設定され、コマンドフラグフィールドの「R」ビットがクリアされていることで示される）は、IKESKRコマンドへの応答として、HAAAによってIKEv2サーバーに送信されます。この場合、DiameterヘッダーのApplication-IdフィールドをDiameter IKE SK Application-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 ]
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-Answerメッセージには、[RFC6734]で指定されているKey AVPが含まれる必要があります（SHALL）。 Key-Type AVPの値をIKEv2 SK（3）に設定する必要があります。 Keying-Material AVPにはSKが含まれている必要があります。 Key-SPI AVPがIKEv2-SK-Requestで受信された場合、Key-SPI AVPがKey AVPに含まれる必要があります。 Key-Lifetime AVPが含まれる場合があります。その場合、ライフタイムの期限が切れている場合、関連付けられたキーは回答の受信者によって使用されないものとします。最後に、Responder-Identity 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サーバー間で交換されるナンスが含まれています。ナンスはSK生成に使用されます。
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 Dataフィールドに含まれているIKEv2イニシエーターナンスが含まれています。
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 Dataフィールドに含まれる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-Identity AVP（コード590）はグループ化されたタイプであり、IKEv2ピアからIKEv2サーバーに送信されるIKE_AUTHメッセージに含まれるイニシエーターおよび場合によってはレスポンダーIDを含みます。
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.
Initiator-Identity AVP（AVPコード591）のタイプはGroupedで、IKE_AUTHメッセージのIDiペイロードのIDタイプと識別データが含まれています。
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）はEnumeratedタイプで、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.
Identification-Data AVP（AVPコード593）はタイプOctetStringであり、IKE_AUTHメッセージのIDiペイロードのIdentification Dataフィールドが含まれています。
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.
Responder-Identity AVP（AVPコード594）のタイプはGroupedで、IKE_AUTHメッセージのIDrペイロードのIDタイプと識別データが含まれています。
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）はEnumeratedタイプであり、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.
Identification-Data AVP（AVPコード593）はタイプOctetStringであり、IKE_AUTHメッセージのIDrペイロードのIdentification Dataフィールドが含まれています。
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つのインスタンスがメッセージに存在する場合があります。
1: One instance of the AVP MUST be present in the message.
1：AVPの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.
次の表は、Diameter 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 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
This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in [RFC6733].
この仕様では、[RFC6733]で定義されているAVPコード名前空間から、次の新しいAVPをIANAに登録する必要があります。
o IKEv2-Nonces - 587
o IKEv2-ノンス-587
o Ni - 588
o に ー ５８８
o Nr - 589
o いいえ-589
o IKEv2-Identity - 590
o IKEv2-Identity-590
o Initiator-Identity - 591
o イニシエーター-アイデンティティ-591
o ID-Type - 592
o IDタイプ-592
o Identification-Data - 593
o 識別データ-593
o Responder-Identity - 594
o Responder-Identity-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は、Key-Type 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]で定義されているApplication Identifier名前空間から1つの新しい値「Diameter IKE SK」を割り当てる必要があります。
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メッセージは、1つ以上のAAAブローカーまたはDiameterエージェントを介して転送されます。この場合、IKEv2サーバーからDiameterサーバーへのAAA通信はホップバイホップで保護されます。したがって、それは、仲介するAAA相互接続ネットワーク、AAAブローカー、およびDiameterエージェントのセキュリティプロパティに依存します。さらに、IKEv2-SK-Answerメッセージを処理するすべてのエージェントは、Key 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-Requestに含まれるノンスの使用を強く推奨しています。キー導出の詳細は、この仕様を活用しているシステムのセキュリティ特性に依存します（たとえば、[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]ケント、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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 5295、2008年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 5996、2010年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、「Diameter Base Protocol」、RFC 6733、2012年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、「Extensible Authentication Protocol（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、「Authentication Protocol for Mobile 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 Mobile IPv6：Support for Home Agent to Diameter Server Interaction」、RFC 5778、2010年2月。
[X.S0047] 3GPP2: X.S0047, "Mobile IPv6 Enhancements", February 2009.
[X.S0047] 3GPP2：X.S0047、「Mobile IPv6 Enhancements」、2009年2月。
[X.S0058] 3GPP2: X.S0058, "WiMAX-HRPD Interworking: Core Network Aspects", June 2010.
[X.S0058] 3GPP2：X.S0058、「WiMAX-HRPD Interworking：Core Network Aspects」、2010年6月。
Authors' Addresses
著者のアドレス
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US
Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill、NJ 07974 US
Phone: +1 908 582 3207
EMail: violeta.cakulev@alcatel-lucent.com
Avi Lior Bridgewater Systems 303 Terry Fox Drive Ottawa, Ontario K2K 3J1 Canada
Avi Lior Bridgewater Systems 303 Terry Fox Driveオタワオンタリオ州K2K 3J1カナダ
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 Murray Hill、NJ 07974 US
Phone: +1 908 582 0729
EMail: Simon.Mizikovsky@alcatel-lucent.com