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)
インターネット鍵交換バージョン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.
この文書では、子SAを生成せずに作成し、認証されるのIKEv2セキュリティアソシエーション（SA）を可能にするインターネットキー交換バージョン2（IKEv2）プロトコルの拡張について説明します。
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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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]
IKEv2のは、[RFC5996]で指定されるように、IKE_AUTH交換はIKEv2のSAと一緒に子供SAを作成しようとする必要があります。いくつかの実装は、他の人が保護するために、実際のトラフィックがある前に、IKEv2のSAを設定したいと思いながら、認証だけのためのIKEv2を使用する必要があるとして、この要件は、時々不便または不必要です。この文書で説明する拡張機能も子SAを作成しようとすることなく、IKEv2のSAを作成することができます。用語のIKEv2、IKEv2のSA、子SAおよび種々のIKEv2交換は[RFC5996]で定義されています
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.
インターネット上の2つのホスト間のNATボックスのO検出。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
[SecureBeacon]のようにO位置認識セキュリティ、。ユーザーは、信頼と信頼できないネットワークの間でローミングしています。信頼できないネットワークにある間、すべてのトラフィックが暗号化されなければならないが、信頼できるネットワーク上で、唯一の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".
IPsecトラフィックがない場合でも、oを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は、我々は、ユーザ認証のための方法としてのIKEv2を使用する[RFC5106]のために使用することができます。
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トラフィックを受信したノードは、INVALID_SPI通知を送信する必要があります。このトラフィックは、それがそのIPアドレスに基づいて認識し、ピア、から来ている場合は、保護INFORMATIONAL交換で通知を送信することができるように、このノードは、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のSAは、これまで子SAを必要とせずに、アプリケーションのための鍵材料を生成するために使用されていてもよいです。これは、[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のピアは、IKEv2のSAを削除する理由として、子供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.
ピギーバックの子SAネゴシエーションなしのIKE_AUTH交換をサポートするか否かの判断は、最終的には、レスポンダまでです。支持レスポンダは、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_AUTH要求を処理しなければならないIKE_SA_INIT応答の通知を含むことによってサポートをアドバタイズしている、および修飾IKE_AUTH応答で応答しなければならない支持レスポンダ。イニシエータが修正さIKE_AUTH要求を送信しなかった場合、このような応答は、変更IKE_AUTH応答で返答してはなりません。
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.
それがこの拡張をサポートしていませんでしたかのようにプロトコルにこの拡張をサポートしないように構成されているサポートするレスポンダは同じように動作しなければなりません。これは、通知と機能をアドバタイズてはならない、そしてそれは、クライアントが第5節で説明するように変更されたIKE_AUTH要求を送信した場合のペイロードを通知INVALID_SYNTAXで応答すべきです。
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 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) MUST be 1, as this message is related to an IKEv2 SA.
このメッセージは、IKEv2のSAに関連しているように、OプロトコルID（1オクテット）は、1でなければなりません。
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、CHILDLESS_IKEV2_SUPPORTEDのために割り当てられた値である必要があります。
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].
簡潔にするため、AUTH交換の唯一の拡張認証プロトコル（EAP）のバージョンは、ここに表示されます。非EAPバージョンは非常に似ています。以下の図は、[RFC5996]の付録C.3に基づいています。
first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST)], [V+][N+]
最初の要求 - > 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
最後の要求 - > 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_SUPPORTED、USE_TRANSPORT_MODE、ESP_TFC_PADDING_NOT_SUPPORTED、およびNON_FIRST_FRAGMENTS_ALSO。
o The SA payload.
SAペイロードO。
o The traffic selector payloads.
トラフィックセレクタペイロードO。
o Any notification, extension payload or VendorID that has to do with Child SA negotiation.
チャイルドSAのネゴシエーションに関係している任意の通知、拡張ペイロードまたはベンダーID、O。
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_AUTH交換のAUTHペイロードを使用して認証されているので、検出されることなく鍛造又は敵対者によって追加することができません。さらに、両方のピアは、レスポンダは、イニシエータから子どもが提案を受け入れるために、交換のこの変化を使用するように構成されなければなりません。
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は名前「CHILDLESS_IKEV2_SUPPORTED」と値「16418」と「IKEv2の通知メッセージタイプ」レジストリから通知メッセージタイプを割り当てています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]カウフマン、C.、ホフマン、P.、ニール、Y.、およびP. Eronen、 "インターネット鍵交換プロトコルバージョン2（IKEv2の）"、RFC 5996、2010年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.0、2009年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.、オオバ、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]レスコラ、E.、RFC 5705 "トランスポート層セキュリティ（TLS）のための鍵材料輸出"、2010年3月。
[SecureBeacon] Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting a Trusted Network", Work in Progress, June 2009.
[SecureBeacon]シェファー、Y.とY.ニール、「ビーコンセキュア：しっかりトラステッドネットワークの検出」、進歩、2009年6月に作業。
Authors' Addresses
著者のアドレス
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
ヨアフニールは、ポイント・ソフトウェア・テクノロジーズ株式会社5 Hasolelim STをチェックしてください。テルアビブ67897イスラエル
EMail: ynir@checkpoint.com
メールアドレス：ynir@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：Hannes.Tschofenig@gmx.net URI：http://www.tschofenig.priv.at
Hui Deng China Mobile 53A,Xibianmennei Ave. Xuanwu District Beijing 100053 China
ホイ鄧小平中国移動53A、ξサイドドアAVE。地区北京100053中国なしX UA N
EMail: denghui02@gmail.com
メールアドレス：denghui02@gmail.com
Rajeshwar Singh Jenwar Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India
RajeshwarシンJenwarシスコシステムズ、株式会社O'Shaugnessyロードバンガロール、カルナータカ560025インド
Phone: +91 80 4103 3563 EMail: rsj@cisco.com
電話：+91 80 4103 3563 Eメール：rsj@cisco.com