[要約] 要約：RFC 6023は、IKEv2セキュリティアソシエーション（SA）の子供でない初期化に関する情報を提供します。 目的：このRFCの目的は、IKEv2 SAの子供でない初期化に関するガイドラインと手順を提供することです。
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.
このドキュメントでは、INTERNTERのキーエクスチェンジバージョン2（IKEV2）プロトコルの拡張機能について説明します。これにより、IKEV2セキュリティアソシエーション（SA）を子供SAを生成せずに作成および認証することができます。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6023.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
IKEv2, as specified in [RFC5996], requires that the IKE_AUTH exchange try to create a Child SA along with the IKEv2 SA. This requirement is sometimes inconvenient or superfluous, as some implementations need to use IKEv2 for authentication only, while others would like to set up the IKEv2 SA before there is any actual traffic to protect. The extension described in this document allows the creation of an IKEv2 SA without also attempting to create a Child SA. The terms IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are defined in [RFC5996]
[RFC5996]で指定されているIKEV2では、IKE_AUTH ExchangeがIKEV2 SAとともにチャイルドSAを作成しようとする必要があります。いくつかの実装は認証のみにIKEV2を使用する必要があるため、この要件は不便または不必要な場合がありますが、他の実装は実際のトラフィックがある前にIKEV2 SAをセットアップしたいと考えています。このドキュメントで説明されている拡張機能は、子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は、実りのない努力ではありません。子SASがなくても、IKEV2 SAは次のことを許可します。
o Checking the liveness status of the peer via liveness checks.
o livensionチェックを介してピアの活性ステータスを確認します。
o Quickly setting up Child SAs without public key operations and without user interaction.
o 公開キーの操作なしでユーザーの相互作用なしで、子SASをすばやくセットアップします。
o Authentication of the peer.
o ピアの認証。
o Detection of NAT boxes between two hosts on the Internet.
o インターネット上の2つのホスト間のNATボックスの検出。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Several scenarios motivated this proposal:
いくつかのシナリオがこの提案を動機付けました：
o Interactive remote access VPN: the user tells the client to "connect", which may involve interactive authentication. There is still no traffic, but some may come later. Since there is no traffic, it is impossible for the gateway to know what selectors to use (how to narrow down the client's proposal).
o インタラクティブなリモートアクセスVPN：ユーザーはクライアントに「接続」するように指示します。これには、インタラクティブ認証が含まれる場合があります。まだトラフィックはありませんが、後で来るかもしれません。トラフィックがないため、ゲートウェイがどのセレクターを使用するかを知ることは不可能です（クライアントの提案を絞り込む方法）。
o Location-aware security, as in [SecureBeacon]. The user is roaming between trusted and untrusted networks. While in an untrusted network, all traffic should be encrypted, but on the trusted network, only the IKEv2 SA needs to be maintained.
o [SecureBeacon]のように、位置認識セキュリティ。ユーザーは、信頼できるネットワークと信頼できないネットワークの間を歩き回っています。信頼されていないネットワークでは、すべてのトラフィックを暗号化する必要がありますが、信頼できるネットワークでは、IKEV2 SAのみを維持する必要があります。
o An IKEv2 SA may be needed between peers even when there is not IPsec traffic. Such IKEv2 peers use liveness checks, and report to the administrator the status of the "VPN links".
o IPSECトラフィックがない場合でも、ピア間でIKEV2 SAが必要になる場合があります。このようなIKEV2ピアは、livensionチェックを使用し、「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 ChildLess IKEV2は[RFC5106]に使用できます。ここでは、IKEV2をユーザー認証の方法として使用できます。
o A node receiving IPsec traffic with an unrecognized Security Parameter Index (SPI) should send an INVALID_SPI notification. If this traffic comes from a peer, which it recognizes based on its IP address, then this node may set up an IKEv2 SA so as to be able to send the notification in a protected INFORMATIONAL exchange.
o 認識されていないセキュリティパラメーターインデックス（SPI）を使用してIPSECトラフィックを受信するノードは、nivalID_SPI通知を送信する必要があります。このトラフィックがIPアドレスに基づいて認識されるピアから来ている場合、このノードはIKEV2 SAを設定して、保護された情報交換で通知を送信できるようにすることができます。
o A future extension may have IKEv2 SAs used for generating keying material for applications, without ever requiring Child SAs. This is similar to what [RFC5705] is doing in Transport Layer Security (TLS).
o 将来の拡張では、子供のSASを必要とせずに、アプリケーション用のキーイング材料の生成に使用されるIKEV2 SASが使用される場合があります。これは、[RFC5705]が輸送層セキュリティ（TLS）で行っていることに似ています。
In some of these cases, it may be possible to create a dummy Child SA and then remove it, but this creates undesirable side effects and race conditions. Moreover, the IKEv2 peer might see the deletion of the Child SA as a reason to delete the IKEv2 SA.
これらのケースの一部では、ダミーチャイルドSAを作成してから削除することが可能かもしれませんが、これにより、望ましくない副作用と人種条件が生成されます。さらに、IKEV2ピアは、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_SA_INIT応答に通知を含めることでサポートを宣伝したサポートレスポンダーは、変更されたIKE_AUTH要求を処理する必要があり、変更された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.
o このメッセージはIKEV2 SAに関連しているため、プロトコルID（1 Octet）は1でなければなりません。
o SPI Size (1 octet) MUST be zero, in conformance with section 3.10 of [RFC5996].
o [RFC5996]のセクション3.10に準拠して、SPIサイズ（1オクテット）はゼロでなければなりません。
o Childless Notify Message Type (2 octets) - MUST be 16418, the value assigned for CHILDLESS_IKEV2_SUPPORTED.
o Childless Notifyメッセージタイプ（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].
簡潔にするために、認証交換の拡張可能な認証プロトコル（EAP）バージョンのみがここに表示されます。EAP以外のバージョンは非常に似ています。以下の図は、[RFC5996]の付録C.3に基づいています。
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[V+][N+]
first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+]
最初の応答<-idr、[cert]、auth、eap、[v] [n]
/ --> EAP repeat 1..N times | \ <-- EAP
/ - > EAP Repeat 1..n times |\ <-EAP
last request --> AUTH
最後のリクエスト - > auth
last response <-- AUTH, [CP(CFG_REPLY)], [V+][N+]
最後の応答<-uth、[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.
o SAペイロード。
o The traffic selector payloads.
o トラフィックセレクターのペイロード。
o Any notification, extension payload or VendorID that has to do with Child SA negotiation.
o 子供SAの交渉に関係する通知、拡張ペイロード、またはベンドリド。
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 Exchangeの認証ペイロードで認証されるため、検出せずに敵によって偽造または追加することはできません。さらに、レスポンダーがイニシエーターから子供のいない提案を受け入れるために、両方のピアをこの交換のこのバリエーションを使用するように構成する必要があります。
IANA has assigned a notify message type from the "IKEv2 Notify Message Types" registry with the name "CHILDLESS_IKEV2_SUPPORTED" and the value "16418".
IANAは、「ikev2 Notifyメッセージタイプ」から「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、Nir、Y。、およびP. Eronen、「Internet Key Exchange Protocolバージョン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.、Ohba、Y.、およびF. Bersani、 "拡張可能な認証プロトコルインターネットキー交換プロトコルバージョン2（EAP-kikev2）メソッド、RFC 5106、2008年2月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705] Rescorla、E。、「輸送層のセキュリティのためのキーキーリングマテリアル輸出業者（TLS）」、RFC 5705、2010年3月。
[SecureBeacon] Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting a Trusted Network", Work in Progress, June 2009.
[SecureBeacon] Sheffer、Y。およびY. Nir、「セキュアビーコン：信頼できるネットワークを安全に検出する」、2009年6月、進行中の作業。
Authors' Addresses
著者のアドレス
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
yoav nirチェックポイントソフトウェアテクノロジーズLtd. 5 hasolelim st。Tel Aviv 67897イスラエル
EMail: ynir@checkpoint.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Hui Deng China Mobile 53A,Xibianmennei Ave. Xuanwu District Beijing 100053 China
Hui Deng China Mobile 53a、Xibianmennei Ave. Xuanwu District Beijing 100053 China
EMail: denghui02@gmail.com
Rajeshwar Singh Jenwar Cisco Systems, Inc. O'Shaugnessy Road Bangalore, Karnataka 560025 India
Rajeshwar Singh Jenwar Cisco Systems、Inc。O'Shaugnessy Road Bangalore、Karnataka 560025 India
Phone: +91 80 4103 3563
EMail: rsj@cisco.com