[要約] RFC 6867は、EAP再認証プロトコル（ERP）をサポートするためのIKEv2拡張を提供します。このRFCの目的は、IKEv2セッション中にEAP再認証をサポートするための仕組みを提供することです。
Internet Engineering Task Force (IETF) Y. Nir
Request for Comments: 6867 Check Point
Category: Experimental Q. Wu
ISSN: 2070-1721 Huawei
January 2013
An Internet Key Exchange Protocol Version 2 (IKEv2) Extension to Support EAP Re-authentication Protocol (ERP)
EAP再認証プロトコル（ERP）をサポートするインターネットキー交換プロトコルバージョン2（IKEv2）拡張
Abstract
概要
This document updates the Internet Key Exchange Protocol version 2 (IKEv2) described in RFC 5996. This extension allows an IKE Security Association (SA) to be created and authenticated using the Extensible Authentication Protocol (EAP) Re-authentication Protocol extension, as described in RFC 6696.
このドキュメントは、RFC 5996で説明されているInternet Key Exchange Protocolバージョン2（IKEv2）を更新します。この拡張により、IKE Security Association（SA）を作成し、Extensible Authentication Protocol（EAP）Re-authentication Protocol拡張を使用して認証することができます。 RFC 6696。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6867.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6867で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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に記載されているように保証なしで提供されます。
IKEv2, as specified in [RFC5996], allows (Section 2.16) authentication of the initiator using an EAP method. Using EAP significantly increases the count of round trips required to establish the IPsec SA and also may require user interaction. This makes it inconvenient to allow a single remote access client to create multiple IPsec tunnels with multiple IPsec gateways that belong to the same domain.
[RFC5996]で指定されているIKEv2は、EAP方式を使用したイニシエーターの認証を許可します（セクション2.16）。 EAPを使用すると、IPsec SAの確立に必要な往復回数が大幅に増加し、ユーザーの操作が必要になる場合もあります。このため、単一のリモートアクセスクライアントが、同じドメインに属する複数のIPsecゲートウェイで複数のIPsecトンネルを作成できるようにするのは不便です。
The EAP Re-authentication Protocol (ERP), as described in [RFC6696], allows an EAP peer to authenticate to multiple authenticators while performing the full EAP method only once. Subsequent authentications require fewer round trips and no user interaction.
[RFC6696]で説明されているEAP再認証プロトコル（ERP）により、EAPピアは、完全なEAPメソッドを1回だけ実行しながら、複数のオーセンティケーターに対して認証できます。以降の認証では、ラウンドトリップが少なく、ユーザーの操作は必要ありません。
Bringing these two technologies together allows a remote access IPsec client to create multiple tunnels with different gateways that belong to a single domain as well as using the keys from other contexts of using EAP, such as network access within the same domain, to transparently connect to VPN gateways within this domain.
これら2つのテクノロジーを組み合わせると、リモートアクセスIPsecクライアントは、単一ドメインに属する異なるゲートウェイを使用して複数のトンネルを作成し、同じドメイン内のネットワークアクセスなどのEAPを使用する他のコンテキストからのキーを使用して透過的に接続できます。このドメイン内のVPNゲートウェイ。
Additionally, it allows for faster set up of new tunnels when previous tunnels have been torn down due to things like network outage, device suspension, or a temporary move out of range. This is similar to the session resumption mechanism described in [RFC5723]. One exception being that instead of a ticket stored by the client, the re-authentication Master Session Key (rMSK) (see Section 4.6 of [RFC6696]) is used as the session key stored on both the client and the Authentication, Authorization, and Accounting (AAA) server.
さらに、ネットワークの停止、デバイスの一時停止、または一時的な範囲外への移動などによって以前のトンネルが切断された場合に、新しいトンネルをより速くセットアップできます。これは、[RFC5723]で説明されているセッション再開メカニズムに似ています。 1つの例外は、クライアントによって保存されたチケットの代わりに、再認証マスターセッションキー（rMSK）（[RFC6696]のセクション4.6を参照）が、クライアントと認証、承認、およびアカウンティング（AAA）サーバー。
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]で説明されているように解釈されます。
This work is motivated by the following scenarios:
この作業は、以下のシナリオによって動機付けられています。
o Multiple tunnels for a single remote access VPN client. Suppose a company has offices in New York City, Paris, and Shanghai. For historical reasons, the email server is located in the Paris office, most of the servers hosting the company's intranet are located in Shanghai, and the finance department servers are in New York City. An employee using a remote access VPN may need to connect to servers from all three locations. While it is possible to connect to a single gateway, and have that gateway route the requests to the other gateways (perhaps through site to site VPN), this is not efficient; it is more desirable to have the client initiate three different tunnels. It is, however, not desirable to have the user type in a password three times.
o 単一のリモートアクセスVPNクライアント用の複数のトンネル。ニューヨーク市、パリ、上海にオフィスがあるとします。歴史的な理由により、電子メールサーバーはパリのオフィスにあり、会社のイントラネットをホストするサーバーのほとんどは上海にあり、財務部門のサーバーはニューヨーク市にあります。リモートアクセスVPNを使用する従業員は、3つの場所すべてからサーバーに接続する必要がある場合があります。単一のゲートウェイに接続し、そのゲートウェイに要求を他のゲートウェイに（おそらくサイト間VPN経由で）ルーティングさせることは可能ですが、これは効率的ではありません。クライアントに3つの異なるトンネルを開始させるほうが望ましいです。ただし、ユーザーがパスワードを3回入力することは望ましくありません。
o Roaming. In these days of mobile phones and tablets, users often move from the wireless LAN in their office, where access may be granted through 802.1x, to a cellular network, where a VPN is necessary, and back again. Both the VPN server and the 802.1x access point are authenticators that connect to the same AAA servers. So it makes sense to make the transition smooth, without requiring user interaction. The device still needs to detect whether it is within the protected network, in which case it should not use VPN. However, this process is beyond the scope of this document. [SECBEAC] is a now-abandoned attempt at this.
o ローミング。最近の携帯電話やタブレットでは、ユーザーは、802.1xを介してアクセスが許可されるオフィスの無線LANから、VPNが必要なセルラーネットワークに移動したり、戻ったりすることがよくあります。 VPNサーバーと802.1xアクセスポイントはどちらも、同じAAAサーバーに接続する認証システムです。したがって、ユーザーの操作を必要とせずに、移行をスムーズにすることが理にかなっています。デバイスは、保護されたネットワーク内にあるかどうかを検出する必要があります。その場合、VPNを使用しないでください。ただし、このプロセスはこのドキュメントの範囲外です。 [SECBEAC]はこれを放棄した試みです。
o Resumption. If a device gets disconnected from an IKE peer, ERP can be used to reconnect to the same gateway without user intervention.
o 再開。デバイスがIKEピアから切断された場合、ERPを使用して、ユーザーの介入なしに同じゲートウェイに再接続できます。
Supporting EAP Re-authentication Extension (ERX) requires an EAP payload in the first IKE_AUTH request. This is a deviation from the rules in [RFC5996], so support needs to be indicated through a Notify payload in the IKE_SA_INIT response. This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start message of ERX, as specified in Section 5.3.1 of [RFC6696]. The "Domain Name" field contains the content of the Domain-Name TLV as specified in Section 5.3.1.1 of the same document.
EAP再認証拡張（ERX）をサポートするには、最初のIKE_AUTH要求にEAPペイロードが必要です。これは[RFC5996]のルールとは異なるため、IKE_SA_INIT応答のNotifyペイロードを通じてサポートを示す必要があります。この通知は、[RFC6696]のセクション5.3.1で指定されているように、ERXのEAP-Initiate / Re-auth-Startメッセージと同じ目的を果たします。 「ドメイン名」フィールドには、同じドキュメントのセクション5.3.1.1で指定されているドメイン名TLVの内容が含まれています。
A supporting initiator that has unexpired keys for this domain will send the EAP-Initiate/Re-auth message in an EAP payload in the first IKE_AUTH request.
このドメインの有効期限が切れていないキーを持つサポート開始側は、最初のIKE_AUTH要求のEAPペイロードでEAP-Initiate / Re-authメッセージを送信します。
The responder sends the EAP payload content to a backend AAA server. If that server has a valid rMSK for that session, it sends those along with an EAP-Finish/Re-auth message. The responder then forwards the EAP-Finish/Re-auth message to the initiator in an EAP payload within the first IKE_AUTH response.
レスポンダは、EAPペイロードコンテンツをバックエンドAAAサーバーに送信します。そのサーバーにそのセッションの有効なrMSKがある場合、サーバーはそれらをEAP-Finish / Re-authメッセージと共に送信します。次にレスポンダは、最初のIKE_AUTH応答内のEAPペイロードでEAP-Finish / Re-authメッセージをイニシエータに転送します。
The initiator then sends an additional IKE_AUTH request that includes the AUTH payload, which has been calculated using the rMSK in the role of the MSK as described in Sections 2.15 and 2.16 of [RFC5996]. The responder replies similarly, and the IKE_AUTH exchange is finished.
次に、[RFC5996]のセクション2.15および2.16で説明されているように、MSKの役割でrMSKを使用して計算されたAUTHペイロードを含む追加のIKE_AUTH要求をイニシエーターが送信します。レスポンダも同様に応答し、IKE_AUTH交換が終了します。
If the backend AAA server does not have valid keys for the Re-auth-Start message, it sends back a normal EAP request, and no rMSK key. EAP flow continues as in [RFC5996].
バックエンドAAAサーバーにRe-auth-Startメッセージの有効なキーがない場合、サーバーは通常のEAPリクエストを送信し、rMSKキーは送信しません。 EAPフローは[RFC5996]のように続行されます。
The following figure is adapted from Appendixes C.1 and C.3 of [RFC5996], with most of the optional payloads removed. Note that the EAP-Initiate/Re-auth message is added.
次の図は、[RFC5996]の付録C.1とC.3から抜粋したもので、ほとんどのオプションのペイロードが削除されています。 EAP-Initiate / Re-authメッセージが追加されることに注意してください。
IKE_SA_INIT Exchange:
| init request --> SA, KE, Ni,
|
| init response <-- SA, KE, Nr,
| N[ERX_SUPPORTED]
IKE_AUTH Exchanges:
| first request --> EAP(EAP-Initiate/Re-auth),
| IDi,
| SA, TSi, TSr
|
| first response <-- IDr, [CERT+], AUTH,
| EAP(EAP-Finish/Re-auth)
|
| last request --> AUTH
|
| last response <-- AUTH,
| SA, TSi, TSr
The IDi payload MUST have ID Type ID_RFC822_ADDR, and the data field MUST contain the same value as the KeyName-NAI TLV in the EAP-Initiate/Re-auth message. See Section 3.2 for details.
IDiペイロードにはIDタイプID_RFC822_ADDRが必要であり、データフィールドには、EAP-Initiate / Re-authメッセージのKeyName-NAI TLVと同じ値が含まれている必要があります。詳細については、セクション3.2を参照してください。
Section 3.16 of [RFC5996] enumerates the EAP codes in EAP messages that are carried in EAP payloads. The enumeration goes only to 4. It is not clear whether or not that list is supposed to be exhaustive.
[RFC5996]のセクション3.16は、EAPペイロードで伝送されるEAPメッセージのEAPコードを列挙しています。列挙は4にしか行きません。そのリストが網羅的であると思われるかどうかは明らかではありません。
To clarify, an implementation conforming to this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) from Section 5.3 of [RFC6696], in addition to the four codes enumerated in [RFC5996]. This document is intentionally silent about other EAP codes that are not enumerated in those documents.
明確にするために、この仕様に準拠する実装は、[RFC5996]に列挙されている4つのコードに加えて、少なくとも[RFC6696]のセクション5.3の開始および終了（5および6）のコードを含むEAPメッセージを受け入れて送信する必要があります。このドキュメントは、それらのドキュメントに列挙されていない他のEAPコードについては意図的にサイレントにしています。
The authors, as well as participants of the HOKEY and IPsecME working groups, believe that all use cases for this extension to IKE have a single backend AAA server doing both the authentication and the re-authentication. The reasoning behind this is that IKE runs over the Internet and would naturally connect to the user's home network.
作成者、およびHOKEYおよびIPsecMEワーキンググループの参加者は、IKEへのこの拡張のすべての使用例に、認証と再認証の両方を実行する単一のバックエンドAAAサーバーがあると信じています。これの背後にある理由は、IKEがインターネット上で実行され、ユーザーのホームネットワークに自然に接続するためです。
This section addresses instances where this is not the case.
このセクションでは、そうでない場合について説明します。
Section 5.3.2 of [RFC6696] describes the EAP-Initiate/Re-auth packet, which, in the case of IKEv2, is carried in the first IKE_AUTH request. This packet contains the KeyName-NAI TLV. This TLV contains the username used in authentication. It is relayed to the AAA server in the AccessRequest message and is returned from the AAA server in the AccessAccept message.
[RFC6696]のセクション5.3.2は、EAP-Initiate / Re-authパケットについて説明しています。これは、IKEv2の場合、最初のIKE_AUTHリクエストで伝送されます。このパケットには、KeyName-NAI TLVが含まれています。このTLVには、認証で使用されるユーザー名が含まれています。これは、AccessRequestメッセージでAAAサーバーに中継され、AccessAcceptメッセージでAAAサーバーから返されます。
The username part of the Network Access Identifier (NAI) within the TLV is the EMSKName [RFC5295] encoded in hexadecimal digits. The domain part is the domain name of the home domain of the user. The username part is ephemeral in the sense that a new one is generated for each full authentication. This ephemeral value is not a good basis for making policy decisions, and it is also a poor source of user identification for the purposes of logging.
TLV内のネットワークアクセス識別子（NAI）のユーザー名部分は、16進数でエンコードされたEMSKName [RFC5295]です。ドメイン部分は、ユーザーのホームドメインのドメイン名です。ユーザー名の部分は、完全な認証ごとに新しい名前が生成されるという意味で短命です。この一時的な値は、ポリシー決定を行うための適切な基盤ではありません。また、ロギングの目的でユーザーを識別するための不十分な情報源でもあります。
Instead, it is up to the implementation in the IPsec gateway to make policy decisions based on other factors. The following list is by no means exhaustive:
代わりに、他の要因に基づいてポリシーを決定するのは、IPsecゲートウェイの実装次第です。以下のリストは決して完全なものではありません。
o In some cases, the home domain name may be enough to make policy decisions. If all users with a particular home domain get the same authorization, then policy does not depend on the real username. Meaningful logs can still be issued by correlating VPN gateway IKE events with AAA servers access records.
o 場合によっては、ホームドメイン名で十分なポリシーを決定できます。特定のホームドメインを持つすべてのユーザーが同じ認証を受ける場合、ポリシーは実際のユーザー名に依存しません。 VPNゲートウェイのIKEイベントをAAAサーバーアクセスレコードと関連付けることで、意味のあるログを引き続き発行できます。
o Sometimes users receive different authorizations based on groups to which they belong. The AAA server can communicate such information to the VPN gateway, for example, using the CLASS attribute [RFC2865] in RADIUS and Diameter [RFC6733]. Logging again depends on correlation with AAA servers.
o ユーザーは、所属するグループに基づいて異なる承認を受ける場合があります。 AAAサーバーは、たとえば、RADIUSおよびDiameter [RFC6733]のCLASS属性[RFC2865]を使用して、このような情報をVPNゲートウェイに伝達できます。ロギングは、AAAサーバーとの相関に依存します。
o AAA servers may support extensions that allow them to communicate with their clients (in our case -- the VPN gateway) to push user information. For example, a certain product integrates a RADIUS server with the Lightweight Directory Access Protocol (LDAP) [RFC4511], so a client could query the server using LDAP and receive the real record for this user. Others may provide this data through vendor-specific extensions to RADIUS or Diameter.
o AAAサーバーは、クライアント（この場合はVPNゲートウェイ）と通信してユーザー情報をプッシュできる拡張機能をサポートしている場合があります。たとえば、特定の製品はRADIUSサーバーをライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4511]と統合しているため、クライアントはLDAPを使用してサーバーにクエリを実行し、このユーザーの実際のレコードを受信できます。他のベンダーは、RADIUSまたはDiameterに対するベンダー固有の拡張機能を通じてこのデータを提供する場合があります。
In any case, authorization is a major issue in deployments, if the backend AAA server supporting the re-authentication is different from the AAA server that had supported the original authentication. It is up to the re-authenticating AAA server to provide the necessary information for authorization. A conforming implementation of this protocol MAY reject initiators for which it is unable to make policy decisions because of these reasons.
いずれの場合でも、再認証をサポートするバックエンドAAAサーバーが元の認証をサポートしていたAAAサーバーと異なる場合、承認は展開における主要な問題です。承認に必要な情報を提供するのは、再認証するAAAサーバーです。このプロトコルの適合実装は、これらの理由のためにポリシー決定を行うことができないイニシエーターを拒否する場合があります。
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 ! ERX Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Domain Name !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Protocol ID (1 octet) - MUST be zero, as this message is related to an IKE SA.
o プロトコルID（1オクテット）-このメッセージはIKE SAに関連しているため、ゼロでなければなりません。
o Security Parameter Index (SPI) Size (1 octet) - MUST be zero, in conformance with Section 3.10 of [RFC5996].
o セキュリティパラメータインデックス（SPI）サイズ（1オクテット）-[RFC5996]のセクション3.10に準拠して、ゼロでなければなりません。
o ERX Notify Message Type (2 octets) - MUST be 16427, the value assigned for ERX.
o ERX通知メッセージタイプ（2オクテット）-ERXに割り当てられた値である16427である必要があります。
o Domain Name (variable) - contains the domain name or realm, as these terms are used in [RFC6696] and encoded as ASCII, as specified in [RFC4282].
o ドメイン名（変数）-これらの用語は[RFC6696]で使用され、[RFC4282]で指定されているとおりにASCIIとしてエンコードされるため、ドメイン名またはレルムが含まれます。
This specification changes the behavior of IKE peers, both initiators and responders. The behavior of backend AAA servers is not changed by this specification, but they are required to support [RFC6696]. The same goes for the EAP client, if it's not integrated into the IKE initiator (for example, if the EAP client is an operating system component).
この仕様は、イニシエーターとレスポンダーの両方のIKEピアの動作を変更します。バックエンドAAAサーバーの動作はこの仕様によって変更されていませんが、[RFC6696]をサポートするために必要です。 EAPクライアントについても、IKEイニシエーターに統合されていない場合（EAPクライアントがオペレーティングシステムコンポーネントである場合など）は同じです。
This specification is silent about key storage and key lifetimes on either the EAP client or the EAP server. These issues are covered in Sections 3, 4, and 5 of [RFC6696]. The key lifetime may be communicated from the AAA server to the EAP client via the Lifetime attribute in the EAP-Finish/Re-auth message. If the server does not have a valid key, while the client does have one, regular EAP is used (see Section 3). This should not happen if lifetimes are communicated. In such a case, the IKEv2 initiator / EAP client MAY alert the user and MAY log the event. Note that this does not necessarily indicate an attack. It could simply be a loss of state on the AAA server.
この仕様は、EAPクライアントまたはEAPサーバーでのキーの保存とキーの有効期間については触れていません。これらの問題は、[RFC6696]のセクション3、4、および5で説明されています。鍵の有効期間は、EAP-Finish / Re-authメッセージのLifetime属性を介して、AAAサーバーからEAPクライアントに伝達されます。サーバーに有効なキーがない場合、クライアントには有効ですが、通常のEAPが使用されます（セクション3を参照）。これは、ライフタイムが伝達される場合は発生しません。そのような場合、IKEv2イニシエーター/ EAPクライアントはユーザーに警告し、イベントをログに記録してもよい（MAY）。これは必ずしも攻撃を示すものではないことに注意してください。単にAAAサーバーの状態が失われる可能性があります。
The protocol extension described in this document extends the authentication from one EAP context, which may or may not be part of IKEv2, to an IKEv2 context. Successful completion of the protocol proves to the authenticator, which in our case is a VPN gateway, that the supplicant or VPN client has authenticated in some other EAP context.
このドキュメントで説明されているプロトコル拡張は、IKEv2の一部である場合とそうでない場合がある1つのEAPコンテキストからIKEv2コンテキストに認証を拡張します。プロトコルが正常に完了すると、認証者（この場合はVPNゲートウェイ）が、サプリカントまたはVPNクライアントが他のEAPコンテキストで認証したことが証明されます。
The protocol supplies the authenticator with the domain name with which the supplicant has authenticated, but does not supply it with a specific identity. Instead, the gateway receives an EMSKName, which is an ephemeral ID. With this variant of the IKEv2 protocol, the initiator never sends its real identity on the wire while the server does. This is different from the usual IKEv2 practice of the initiator revealing its identity first.
プロトコルは、サプリカントが認証したドメイン名をオーセンティケータに提供しますが、特定のIDを提供しません。代わりに、ゲートウェイはエフェメラルIDであるEMSKNameを受け取ります。このIKEv2プロトコルのバリアントでは、サーバーが送信している間、イニシエーターが実際のIDをネットワーク上で送信することはありません。これは、最初にIDを明らかにするイニシエーターの通常のIKEv2プラクティスとは異なります。
If the domain name is sufficient to make access control decisions, this is enough. If not, then the gateway needs to find out either the real name or authorization information for that particular user. This may be done using the AAA protocol or by some other federation protocol, which is out of scope for this specification.
ドメイン名がアクセス制御の決定を行うのに十分である場合、これで十分です。そうでない場合、ゲートウェイは、その特定のユーザーの実際の名前または認証情報を見つける必要があります。これは、AAAプロトコルを使用して、またはこの仕様の範囲外である他のフェデレーションプロトコルを使用して行うことができます。
IANA has assigned a notify message type of 16427 from the "IKEv2 Notify Message Types - Status Types" registry with the name "ERX_SUPPORTED".
IANAは、「IKEv2通知メッセージタイプ-ステータスタイプ」レジストリから「ERX_SUPPORTED」という名前の通知メッセージタイプ16427を割り当てました。
The authors would like to thank Yaron Sheffer for comments and suggested text that have contributed to this document.
著者は、このドキュメントに貢献したコメントおよび提案されたテキストについて、Yaron Shefferに感謝します。
Thanks also to Juergen Schoenwaelder for his OPS-DIR review comments.
OPS-DIRレビューのコメントを提供してくれたJuergen Schoenwaelderにも感謝します。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「The Network Access Identifier」、RFC 4282、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月。
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, July 2012.
[RFC6696] Cao、Z.、He、B.、Shi、Y.、Wu、Q。、およびG. Zorn、「EAP Extensions for the EAP Re-authentication Protocol（ERP）」、RFC 6696、2012年7月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル」、RFC 4511、2006年6月。
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
[RFC5723] Sheffer、Y。およびH. Tschofenig、「インターネットキーエクスチェンジプロトコルバージョン2（IKEv2）セッションの再開」、RFC 5723、2010年1月。
[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月。
[SECBEAC] Sheffer, Y. and Y. Nir, "Secure Beacon: Securely Detecting a Trusted Network", Work in Progress, June 2009.
[SECBEAC] Sheffer、Y。およびY. Nir、「Secure Beacon：Securely Detecting a Trusted Network」、Work in Progress、2009年6月。
Authors' Addresses
著者のアドレス
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st. Tel Aviv 67897 Israel
Yoav Nir Check Point Software Technologies Ltd. 5 Hasolelim st。テルアビブ67897イスラエル
EMail: ynir@checkpoint.com
Qin Wu Huawei Technologies Co., Ltd. 101 Software Avenue, Yuhua District Nanjing, JiangSu 210012 China
Wuhu AのQはテクノロジー株式会社です。101ソフトウェアアベニュー、Y U塗装区NaN京、江蘇210012中国
EMail: sunseawq@huawei.com