[要約] RFC 6942は、Diameterプロトコルを使用してEAP再認証プロトコル（ERP）をサポートするための仕様です。目的は、ネットワーク上でのユーザーの再認証を効率的かつ安全に行うことです。
Internet Engineering Task Force (IETF) J. Bournelle
Request for Comments: 6942 L. Morand
Category: Standards Track Orange Labs
ISSN: 2070-1721 S. Decugis
INSIDE Secure
Q. Wu
Huawei
G. Zorn
Network Zen
May 2013
Diameter Support for the EAP Re-authentication Protocol (ERP)
EAP再認証プロトコル（ERP）のDiameterサポート
Abstract
概要
The EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re-authentication between the peer and an EAP Re-authentication (ER) server through a compatible authenticator. This document specifies Diameter support for ERP. It defines a new Diameter ERP application to transport ERP messages between an ER authenticator and the ER server, and a set of new Attribute-Value Pairs (AVPs) that can be used to transport the cryptographic material needed by the re-authentication server.
EAP再認証プロトコル（ERP）は、拡張認証プロトコル（EAP）の拡張機能を定義し、互換性のある認証システムを介したピアとEAP再認証（ER）サーバー間の効率的な再認証をサポートします。このドキュメントでは、ERPのDiameterサポートについて説明します。 ERオーセンティケーターとERサーバーの間でERPメッセージを転送するための新しいDiameter ERPアプリケーションと、再認証サーバーが必要とする暗号化マテリアルを転送するために使用できる新しい属性値ペア（AVP）のセットを定義します。
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/rfc6942.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6942で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
5. Bootstrapping the ER Server . . . . . . . . . . . . . . . . . 6
5.1. Bootstrapping during the Initial EAP Authentication . . . 6
5.2. Bootstrapping during the First Re-authentication . . . . 8
6. Re-authentication . . . . . . . . . . . . . . . . . . . . . . 11
7. Application Id . . . . . . . . . . . . . . . . . . . . . . . 12
8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . 13
8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . 13
8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 13
8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . 14
8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . 14
9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 14
9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. Diameter Application Identifier . . . . . . . . . . . . 14
10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . 15
10.3. New Permanent Failures Result-Code AVP Values . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . . 15
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . 17
Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol (ERP). It consists of the following steps:
曹、他[RFC6696]は、EAP再認証プロトコル（ERP）を定義しています。次の手順で構成されます。
Bootstrapping
ブートストラップ
A root key for re-authentication is derived from the Extended Master Session Key (EMSK) created during EAP authentication [RFC5295]. This root key is transported from the EAP server to the ER server.
再認証のルートキーは、EAP認証中に作成された拡張マスターセッションキー（EMSK）から派生します[RFC5295]。このルートキーは、EAPサーバーからERサーバーに転送されます。
Re-authentication
再認証
A one-round-trip exchange between the peer and the ER server, resulting in mutual authentication. To support the EAP re-authentication functionality, ERP defines two new EAP codes -- EAP-Initiate and EAP-Finish.
ピアとERサーバー間の1往復の交換で、相互認証が行われます。 EAP再認証機能をサポートするために、ERPは2つの新しいEAPコード、EAP-InitiateとEAP-Finishを定義しています。
This document defines how Diameter transports the ERP messages during the re-authentication process. For this purpose, we define a new Application Identifier for ERP and reuse the Diameter EAP commands Diameter-EAP-Request (DER) / Diameter-EAP-Answer (DEA).
このドキュメントでは、Diameterが再認証プロセス中にERPメッセージを転送する方法を定義します。この目的のために、ERPの新しいアプリケーション識別子を定義し、Diameter EAPコマンドDiameter-EAP-Request（DER）/ Diameter-EAP-Answer（DEA）を再利用します。
This document also discusses the distribution of the root key during bootstrapping, in conjunction with either the initial EAP authentication (implicit bootstrapping) or the first ERP exchange (explicit bootstrapping). Security considerations for this key distribution are detailed in Section 7.4 of Salowey, et al. [RFC5295].
このドキュメントでは、最初のEAP認証（暗黙的なブートストラップ）または最初のERP交換（明示的なブートストラップ）と組み合わせて、ブートストラップ中のルートキーの配布についても説明します。このキー配布のセキュリティに関する考慮事項は、Saloweyらのセクション7.4で詳しく説明されています。 [RFC5295]。
This document uses terminology defined in Aboba, et al. [RFC3748], Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et al. [RFC4072].
このドキュメントでは、Abobaなどで定義された用語を使用します。 [RFC3748]、Salowey、他。 [RFC5295]、Cao、他。 [RFC6696]、およびEronenなど。 [RFC4072]。
Following RFC 5295, the term "domain" herein refers to a key management domain unless otherwise qualified. Similarly, the terms "home domain" and "local domain" have the same meaning here as in RFC 6696.
RFC 5295に準拠して、ここでの「ドメイン」という用語は、特に限定されない限り、キー管理ドメインを指します。同様に、「ホームドメイン」および「ローカルドメイン」という用語は、RFC 6696と同じ意味です。
The re-authentication Domain-Specific Root Key (rDSRK) is a re-authentication Root Key (rRK) [RFC6696] derived from the Domain-Specific Root Key (DSRK) instead of the EMSK.
再認証ドメイン固有ルートキー（rDSRK）は、EMSKではなく、ドメイン固有ルートキー（DSRK）から派生した再認証ルートキー（rRK）[RFC6696]です。
"Root key" (RK) or "bootstrapping material" refers to the rRK or rDSRK derived from an EMSK, depending on whether the ER server is located in the home or a foreign domain.
「ルートキー」（RK）または「ブートストラップ資料」とは、ERサーバーがホームドメインにあるか外部ドメインにあるかに応じて、EMSKから派生したrRKまたはrDSRKを指します。
We use the notation "ERP/DER" and "ERP/DEA" in this document to refer to Diameter-EAP-Request and Diameter-EAP-Answer commands with the Application Id set to <Diameter ERP> (Section 10.1); the same commands are denoted "EAP/DER" and "EAP/DEA" when the Application Id in the message is set to <Diameter EAP> [RFC4072].
このドキュメントでは、「ERP / DER」および「ERP / DEA」という表記を使用して、アプリケーションIDを<Diameter ERP>に設定したDiameter-EAP-RequestおよびDiameter-EAP-Answerコマンドを参照しています（セクション10.1）。メッセージのアプリケーションIDが<Diameter EAP> [RFC4072]に設定されている場合、同じコマンドは「EAP / DER」と「EAP / DEA」で示されます。
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 document assumes the existence of, at most, one logical ER server entity in a given domain. If several physical servers are deployed for robustness, a replication mechanism must be deployed to synchronize the ERP state (e.g., root keys) between these servers. Any such replication mechanism is outside the scope of this document. If multiple ER servers are deployed in the domain, we assume that they can be used interchangeably. If multiple ER servers are deployed across multiple domains, we assume that only one ER server, topologically close to the peer, is involved in ERP, with distance being measured in terms of Diameter hops.
このドキュメントでは、特定のドメインに最大で1つの論理ERサーバーエンティティが存在することを前提としています。堅牢性のために複数の物理サーバーが展開されている場合、これらのサーバー間でERP状態（ルートキーなど）を同期するためにレプリケーションメカニズムを展開する必要があります。このような複製メカニズムは、このドキュメントの範囲外です。ドメインに複数のERサーバーが展開されている場合、それらは互換的に使用できると見なされます。複数のドメインに複数のERサーバーが配置されている場合、トポロジー的にピアに近いERサーバーのみがERPに関与し、距離はDiameterホップで測定されると想定します。
This document also assumes the existence of, at most, one EAP server entity in the home domain. In case of multiple physical home EAP servers, if the ER server wants to reach the same home EAP server, the ER server SHOULD cache the Destination-Host AVP corresponding to the home EAP server it requests.
このドキュメントでは、ホームドメインに最大で1つのEAPサーバーエンティティが存在することも前提としています。複数の物理ホームEAPサーバーの場合、ERサーバーが同じホームEAPサーバーに到達する必要がある場合、ERサーバーは、要求するホームEAPサーバーに対応する宛先ホストAVPをキャッシュする必要があります（SHOULD）。
In general, it is assumed that key management domain names and Diameter realm names are identical for any given domain/realm.
一般に、キー管理ドメイン名とDiameterレルム名は、特定のドメイン/レルムで同一であると想定されています。
The following figure illustrates the components involved in ERP and their interactions.
次の図は、ERPに関連するコンポーネントとその相互作用を示しています。
Diameter +--------+
+-------------+ ERP +-----------+ (*) | Home |
Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
+-------------+ +-----------+ | server |
+--------+
(*) Diameter EAP application; explicit bootstrapping scenario only.
Figure 1: Diameter ERP Overview
図1：Diameter ERPの概要
The ER server is located either in the home domain (same as the EAP server) or in the local domain (same as the authenticator, when it differs from the home domain).
ERサーバーは、ホームドメイン（EAPサーバーと同じ）またはローカルドメイン（ホームドメインと異なる場合はオーセンティケーターと同じ）にあります。
When the peer initiates an ERP exchange, the authenticator creates a DER message [RFC4072]. The Application Id of the message is set to that of the Diameter ERP application (Section 10.1) in the message. The generation of the ERP/DER message is detailed in Section 6.
ピアがERP交換を開始すると、オーセンティケータはDERメッセージ[RFC4072]を作成します。メッセージのアプリケーションIDは、メッセージ内のDiameter ERPアプリケーション（セクション10.1）のアプリケーションIDに設定されます。 ERP / DERメッセージの生成については、セクション6で詳しく説明します。
If there is an ER server in the same domain as the authenticator (i.e., the local domain), Diameter routing MUST be configured so that this ERP/DER message reaches that server, even if the Destination-Realm is not the same as the local domain.
オーセンティケーターと同じドメイン（つまり、ローカルドメイン）にERサーバーがある場合、Destination-Realmがローカルと同じでなくても、このERP / DERメッセージがそのサーバーに到達するようにDiameterルーティングを構成する必要があります。ドメイン。
If there is no local ER server, the message is routed according to its Destination-Realm AVP content, extracted from the realm component of the keyName-NAI attribute. As specified in RFC 6696, this realm is the home domain of the peer in the case of bootstrapping exchange ('B' flag is set in ERP message) or the domain of the bootstrapped ER server otherwise.
ローカルERサーバーがない場合、メッセージはDestination-Realm AVPコンテンツに従ってルーティングされ、keyName-NAI属性のレルムコンポーネントから抽出されます。 RFC 6696で指定されているように、このレルムは、ブートストラップ交換（ERPメッセージで「B」フラグが設定されている）の場合はピアのホームドメインであり、それ以外の場合はブートストラップERサーバーのドメインです。
If no ER server is available in the home domain either, the ERP/DER message cannot be delivered and an error, DIAMETER_UNABLE_TO_DELIVER, MUST be generated, as specified in RFC 6733, and returned to the authenticator. The authenticator MAY cache this information (with limited duration) to avoid further attempts to execute ERP with this realm. It MAY also fallback to full EAP authentication to authenticate the peer.
ホームドメインでもERサーバーが利用できない場合は、ERP / DERメッセージを配信できず、RFC 6733で指定されているように、DIAMETER_UNABLE_TO_DELIVERエラーが生成され、認証システムに返される必要があります。オーセンティケーターは、このレルムでERPを実行しようとするさらなる試みを回避するために、（限られた期間で）この情報をキャッシュできます（MAY）。また、ピアを認証するために完全なEAP認証にフォールバックする場合もあります。
When an ER server receives the ERP/DER message, it searches its local database for a valid, unexpired root key matching the keyName part of the User-Name AVP. If such key is found, the ER server processes the ERP message, as described in RFC 6696, then creates the ERP/DEA answer, as described in Section 6. The re-authentication Master Session Key (rMSK) is included in this answer.
ERサーバーは、ERP / DERメッセージを受信すると、ローカルデータベースを検索して、ユーザー名AVPのkeyName部分に一致する有効な、期限が切れていないルートキーを探します。そのようなキーが見つかると、ERサーバーはRFC 6696で説明されているようにERPメッセージを処理し、セクション6で説明されているようにERP / DEA回答を作成します。この認証には再認証マスターセッションキー（rMSK）が含まれます。
Finally, the authenticator extracts the rMSK from the ERP/DEA, as described in RFC 6696, and forwards the content of the EAP-Payload AVP, the EAP-Finish/Re-auth message, to the peer.
最後に、オーセンティケータはRFC 6696で説明されているようにERP / DEAからrMSKを抽出し、EAP-Payload AVPのコンテンツであるEAP-Finish / Re-authメッセージをピアに転送します。
The ER server may or may not possess the root key in its local database. If the EAP-Initiate/Re-auth message has its 'B' flag set (bootstrapping exchange) and the ER server possesses the root key, the ER server SHOULD respond directly to the peer that initiated the ERP exchange. Otherwise, the ER server SHOULD act as a proxy and forward the message to the home EAP server after changing its Application Id to Diameter EAP and adding the ERP-RK-Request AVP to request the root key. See Section 5 for more detail on this process.
ERサーバーは、ローカルデータベースにルートキーを持っている場合と持っていない場合があります。 EAP-Initiate / Re-authメッセージに「B」フラグセット（ブートストラップ交換）があり、ERサーバーがルートキーを所有している場合、ERサーバーは、ERP交換を開始したピアに直接応答する必要があります（SHOULD）。それ以外の場合、ERサーバーはプロキシとして機能し、アプリケーションIDをDiameter EAPに変更し、ERP-RK-Request AVPを追加してルートキーを要求した後、メッセージをホームEAPサーバーに転送する必要があります。このプロセスの詳細については、セクション5を参照してください。
The bootstrapping process involves the home EAP server and the ER server, but also impacts the peer and the authenticator. In ERP, the peer must derive the same keying material as the ER server. To achieve this, it must learn the domain name of the ER server. How this information is acquired is outside the scope of this specification, but the authenticator might be configured to advertise this domain name, especially in the case of re-authentication after a handover.
ブートストラッププロセスには、ホームEAPサーバーとERサーバーが含まれますが、ピアと認証システムにも影響します。 ERPでは、ピアはERサーバーと同じキー情報を導出する必要があります。これを実現するには、ERサーバーのドメイン名を学習する必要があります。この情報の取得方法はこの仕様の範囲外ですが、オーセンティケーターは、特にハンドオーバー後の再認証の場合に、このドメイン名をアドバタイズするように構成されている可能性があります。
The bootstrapping of an ER server with a given root key happens either during the initial EAP authentication of the peer when the EMSK -- from which the root key is derived -- is created, during the first re-authentication, or sometime between those events. We only consider the first two possibilities in this specification, in the following subsections.
特定のルートキーによるERサーバーのブートストラップは、ピアの最初のEAP認証中に、EMSK（ルートキーの派生元）が作成されたとき、最初の再認証中に、またはこれらのイベントの間に発生します。 。次のサブセクションでは、この仕様の最初の2つの可能性のみを考慮します。
Bootstrapping the ER server during the initial EAP authentication (also known as implicit bootstrapping) offers the advantage that the server is immediately available for re-authentication of the peer, thus minimizing the re-authentication delay. On the other hand, it is possible that only a small number of peers will use re-authentication in the local domain. Deriving and caching key material for all the peers (for example, for the peers that do not support ERP) is a waste of resources and should be avoided.
初期EAP認証中のERサーバーのブートストラップ（暗黙のブートストラップとも呼ばれます）は、サーバーがピアの再認証にすぐに利用できるという利点を提供し、再認証の遅延を最小限に抑えます。一方、ローカルドメインでは、少数のピアのみが再認証を使用する可能性があります。すべてのピア（ERPをサポートしていないピアなど）のキーマテリアルを取得してキャッシュすることは、リソースの浪費であり、避ける必要があります。
To achieve implicit bootstrapping, the ER server acts as a Diameter EAP Proxy, and Diameter routing MUST be configured so that Diameter EAP application messages are routed through this proxy. The figure below illustrates this mechanism.
暗黙的なブートストラップを実現するには、ERサーバーがDiameter EAPプロキシとして機能し、Diameter EAPアプリケーションメッセージがこのプロキシ経由でルーティングされるようにDiameterルーティングを構成する必要があります。次の図は、このメカニズムを示しています。
ER server &
Authenticator EAP Proxy Home EAP server
============= =========== ===============
------------------------->
Diameter EAP/DER
(EAP-Response)
------------------------->
Diameter EAP/DER
(EAP-Response)
(ERP-RK-Request)
<==================================================>
Multi-round Diameter EAP exchanges, unmodified
<-------------------------
Diameter EAP/DEA
(EAP-Success)
(MSK)
(Key AVP (rRK))
<-------------------------
Diameter EAP/DEA
(EAP-Success)
(MSK)
[ERP-Realm]
Figure 2: ERP Bootstrapping during Full EAP Authentication
図2：完全なEAP認証中のERPブートストラップ
The authenticator creates the first DER of the full EAP authentication and sends it to the ER server. The ER server proxies the first DER of the full EAP authentication and adds the ERP-RK-Request AVP inside, then forwards the request to the home EAP server.
オーセンティケーターは、完全なEAP認証の最初のDERを作成し、それをERサーバーに送信します。 ERサーバーは、完全なEAP認証の最初のDERをプロキシし、ERP-RK-Request AVPを内部に追加してから、要求をホームEAPサーバーに転送します。
If the home Diameter server does not support the Diameter ERP extensions, it simply ignores the ERP-RK-Request AVP and continues as specified in RFC 4072 [RFC4072]. If the server supports the ERP extensions, it saves the value of the ERP-Realm AVP found inside the ERP-RK-Request AVP, and continues with the EAP authentication. When the authentication completes, if it is successful and the EAP method has generated an EMSK, the server MUST derive the rRK as specified in RFC 6696, using the saved ERP realm name. It then includes the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to rRK, before sending the DEA as usual.
ホームDiameterサーバーがDiameter ERP拡張をサポートしていない場合、ERP-RK-Request AVPを単に無視し、RFC 4072 [RFC4072]で指定されたとおりに続行します。サーバーがERP拡張機能をサポートしている場合、サーバーはERP-RK-Request AVP内にあるERP-Realm AVPの値を保存し、EAP認証を続行します。認証が完了し、成功し、EAPメソッドがEMSKを生成した場合、サーバーは、保存されたERPレルム名を使用して、RFC 6696で指定されているようにrRKを導出する必要があります。次に、通常どおりDEAを送信する前に、Key-Type AVPがrRKに設定されたKey AVP（セクション8.3）内にrRKを含めます。
When the ER server proxies a Diameter-EAP-Answer message with a Session-Id corresponding to a message to which it added an ERP-RK-Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine the message and save and remove any Key AVP (Section 8.3) with Key-Type AVP set to rRK. If the message does not contain such a Key AVP, the ER server may cache the information that re-authentication via ERP is not possible for the session in order to avoid any subsequent attempts. In any case, the information stored in the ER server concerning a session should not have a lifetime greater than the EMSK for this session.
ERサーバーが、ERP-RK-Request AVPを追加したメッセージに対応するSession-IdでDiameter-EAP-Answerメッセージをプロキシし、Result-CodeがDIAMETER_SUCCESSである場合、メッセージを検査して保存および削除する必要があります。 Key-Type AVPがrRKに設定された任意のKey AVP（セクション8.3）。メッセージにそのようなキーAVPが含まれていない場合、ERサーバーは、その後の試行を回避するために、ERPを介した再認証がセッションで不可能であるという情報をキャッシュすることがあります。いずれの場合も、セッションに関するERサーバーに格納された情報の有効期間は、このセッションのEMSKより長くないようにする必要があります。
If the ER server is successfully bootstrapped, it should also add the ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the EAP/DEA message. This ERP-Realm information can be used by the authenticator to notify the peer that the ER server is bootstrapped, and for which domain. How this information can be transmitted to the peer is outside the scope of this document. This information needs to be sent to the peer if both implicit and explicit bootstrapping mechanisms are possible, because the ERP message and the root key used for protecting this message are different in bootstrapping exchanges and non-bootstrapping exchanges.
ERサーバーが正常にブートストラップされる場合、EAP / DEAメッセージでキータイプがrRKのキーAVPを削除した後、ERPレルムAVPも追加する必要があります。オーセンティケーターはこのERP-Realm情報を使用して、ERサーバーがブートストラップされたこと、およびそのドメインをピアに通知できます。この情報をピアに送信する方法は、このドキュメントの範囲外です。ブートストラップ交換と非ブートストラップ交換ではERPメッセージとこのメッセージの保護に使用されるルートキーが異なるため、暗黙的および明示的なブートストラップメカニズムの両方が可能な場合、この情報をピアに送信する必要があります。
Bootstrapping the ER server during the first re-authentication (also known as explicit bootstrapping) is only needed when there is no ER server in the local domain and there is an ER server in the home domain. It is less resource intensive, since the EMSK generated during initial EAP authentication is reused to derive root keys. On the other hand, the first re-authentication requires a one-round-trip exchange with the home EAP server, since the EMSK is generated during the initial EAP authentication and never leaves the home EAP server, which is less efficient than implicit bootstrapping.
最初の再認証中のERサーバーのブートストラップ（明示的ブートストラップとも呼ばれる）が必要になるのは、ローカルドメインにERサーバーがなく、ホームドメインにERサーバーがある場合のみです。最初のEAP認証中に生成されたEMSKがルートキーを取得するために再利用されるため、リソースの消費が少なくなります。一方、EMSKは最初のEAP認証中に生成され、ホームEAPサーバーから出ることはないため、最初の再認証ではホームEAPサーバーとの1往復の交換が必要であり、暗黙的にブートストラップするよりも効率的ではありません。
The EAP-Initiate/Re-auth message is sent to the home ER server. The home ER server receives the ERP/DER message containing the EAP-Initiate/Re-auth message with the 'B' flag set. It creates the new EAP/DER message using the received ERP/DER message and performs the following processing:
EAP-Initiate / Re-authメッセージがホームERサーバーに送信されます。ホームERサーバーは、「B」フラグが設定されたEAP-Initiate / Re-authメッセージを含むERP / DERメッセージを受信します。受信したERP / DERメッセージを使用して新しいEAP / DERメッセージを作成し、次の処理を実行します。
Set the Application Id in the header of the message to <Diameter EAP> [RFC4072].
メッセージのヘッダーのアプリケーションIDを<Diameter EAP> [RFC4072]に設定します。
Extract the ERP-RK-Request AVP from the ERP/DER message, which contains the name of the domain where the ER server is located, and add it to the newly created ERP/DER message.
ERサーバーが配置されているドメインの名前を含むERP / DERメッセージからERP-RK-Request AVPを抽出し、新しく作成されたERP / DERメッセージに追加します。
Then, the newly created EAP/DER is sent and routed to the home Diameter EAP application server.
次に、新しく作成されたEAP / DERが送信され、ホームDiameter EAPアプリケーションサーバーにルーティングされます。
If the home Diameter EAP server does not support ERP extensions, EAP packets with an unknown ERP-specific code (EAP-Initiate) will not be understood. In such a case, the home Diameter EAP server MUST send an EAP/DEA with a Result-Code indicating a Permanent Failure (for example, DIAMETER_ERROR_EAP_CODE_UNKNOWN or DIAMETER_UNABLE_TO_COMPLY). The Failed-AVP AVP MUST be included and contain a copy of the EAP-Payload AVP. Otherwise, it processes the DSRK request, as described in RFC 6696. In particular, it includes the Domain-Name TLV attribute with the content from the ERP-Realm AVP. The server creates the EAP/DEA reply message [RFC4072], including an instance of the Key AVP (Section 8.3) with the Key-Type AVP set to rRK and an instance of the Domain-Name TLV attribute with the content from the ERP-Realm AVP.
ホームDiameter EAPサーバーがERP拡張をサポートしていない場合、不明なERP固有コード（EAP-Initiate）を含むEAPパケットは認識されません。このような場合、ホームDiameter EAPサーバーは、永続的な障害を示すResult-Code（たとえば、DIAMETER_ERROR_EAP_CODE_UNKNOWNまたはDIAMETER_UNABLE_TO_COMPLY）を含むEAP / DEAを送信する必要があります。 Failed-AVP AVPを含め、EAP-Payload AVPのコピーを含める必要があります。それ以外の場合は、RFC 6696で説明されているように、DSRK要求を処理します。特に、ERPレルムAVPからのコンテンツを含むドメイン名TLV属性が含まれています。サーバーは、EAP / DEA応答メッセージ[RFC4072]を作成します。これには、Key-Type AVPがrRKに設定されたKey AVP（セクション8.3）のインスタンスと、ERPからのコンテンツが含まれるDomain-Name TLV属性のインスタンスが含まれます。レルムAVP。
The ER server receives this EAP/DEA and proxies it as follows, in addition to standard proxy operations:
ERサーバーはこのEAP / DEAを受信し、標準のプロキシ操作に加えて、次のようにプロキシします。
Set the Application Id back to Diameter ERP Application Id (Section 10.1).
アプリケーションIDをDiameter ERPアプリケーションIDに戻します（セクション10.1）。
Extract and cache the content of the Key AVP with Key-Type set to rRK, as described in Section 5.1).
セクション5.1で説明されているように、Key-TypeがrRKに設定されたKey AVPのコンテンツを抽出してキャッシュします。
The ERP/DEA message is then forwarded to the authenticator that can use the rMSK as described in RFC 6696.
その後、ERP / DEAメッセージは、RFC 6696で説明されているように、rMSKを使用できる認証システムに転送されます。
The figure below captures this proxy behavior:
次の図は、このプロキシの動作を示しています。
Authenticator ER server Home Diameter server
============= ========= ====================
----------------------->
Diameter ERP/DER
(EAP-Initiate)
------------------------>
Diameter EAP/DER
(EAP-Response)
(ERP-RK-Request)
<------------------------
Diameter EAP/DEA
(EAP-Success)
(Key AVP (rRK))
(Key AVP (rMSK))
<----------------------
Diameter ERP/DEA
(EAP-Finish)
(Key AVP (rMSK))
Figure 3: ERP Explicit Bootstrapping Message Flow
図3：ERPの明示的なブートストラップメッセージフロー
This section describes in detail a re-authentication exchange with an ER server that was previously bootstrapped. The following figure summarizes the re-authentication exchange.
このセクションでは、以前にブートストラップされたERサーバーとの再認証交換について詳しく説明します。次の図は、再認証交換の概要を示しています。
ER server
Peer Authenticator (bootstrapped)
==== ============= ======================
[ <------------------------ ]
[optional EAP-Initiate/Re-auth-start,]
[ possibly with ERP domain name ]
----------------------->
EAP-Initiate/Re-auth
===============================>
Diameter ERP, cmd code DER
User-Name: keyName-NAI
EAP-Payload: EAP-Initiate/Re-auth
<===============================
Diameter ERP, cmd code DEA
EAP-Payload: EAP-Finish/Re-auth
Key AVP: rMSK
<----------------------
EAP-Finish/Re-auth
Figure 4: Diameter ERP Re-authentication Exchange
図4：Diameter ERP再認証交換
The peer sends an EAP-Initiate/Re-auth message to the ER server via the authenticator. Alternatively, the authenticator may send an EAP-Initiate/Re-auth-Start message to the peer to trigger the mechanism. In this case, the peer responds with an EAP-Initiate/Re-auth message.
ピアは、オーセンティケータを介してEAPサーバーにEAP-Initiate / Re-authメッセージを送信します。あるいは、オーセンティケータは、ピアにEAP-Initiate / Re-auth-Startメッセージを送信して、メカニズムをトリガーすることもできます。この場合、ピアはEAP-Initiate / Re-authメッセージで応答します。
If the authenticator does not support ERP (pure Diameter EAP [RFC4072] support), it discards the EAP packets with an unknown ERP-specific code (EAP-Initiate). The peer should fall back to full EAP authentication in this case.
オーセンティケーターがERP（純粋なDiameter EAP [RFC4072]サポート）をサポートしない場合、不明なERP固有のコード（EAP-Initiate）を含むEAPパケットを破棄します。この場合、ピアは完全なEAP認証にフォールバックする必要があります。
When the authenticator receives an EAP-Initiate/Re-auth message from the peer, the message is processed as described in RFC 6696, with regard to the EAP state machine. It creates a Diameter ERP/DER message following the general process of Diameter EAP [RFC4072], with the following differences:
オーセンティケーターがピアからEAP-Initiate / Re-authメッセージを受信すると、メッセージはEAPステートマシンに関してRFC 6696で説明されているように処理されます。 Diameter EAP [RFC4072]の一般的なプロセスに従って、Diameter ERP / DERメッセージを作成しますが、次の違いがあります。
The Application Id in the header is set to <Diameter ERP> (code 13).
ヘッダーのアプリケーションIDは<Diameter ERP>（コード13）に設定されています。
The value in the Auth-Application-Id AVP is also set to <Diameter ERP>.
Auth-Application-Id AVPの値も<Diameter ERP>に設定されます。
The keyName-NAI attribute from the ERP message is used to create the content of the User-Name and Destination-Realm AVPs.
ERPメッセージのkeyName-NAI属性を使用して、User-NameおよびDestination-Realm AVPのコンテンツを作成します。
The Auth-Request-Type AVP content is set to the appropriate value.
Auth-Request-Type AVPコンテンツが適切な値に設定されます。
The EAP-Payload AVP contains the EAP-Initiate/Re-auth message.
EAP-Payload AVPには、EAP-Initiate / Re-authメッセージが含まれています。
Then, this ERP/DER message is sent as described in Section 4.
次に、このERP / DERメッセージがセクション4で説明されているように送信されます。
The ER server receives and processes this request as described in Section 4. It then creates an ERP/DEA message following the general process described in Eronen, et al. [RFC4072], with the following differences:
ERサーバーは、セクション4で説明されているように、この要求を受信して処理します。次に、ERonenなどで説明されている一般的なプロセスに従って、ERP / DEAメッセージを作成します。 [RFC4072]、以下の違いがあります：
The Application Id in the header is set to <Diameter ERP> (code 13).
ヘッダーのアプリケーションIDは<Diameter ERP>（コード13）に設定されています。
The value of the Auth-Application-Id AVP is also set to <Diameter ERP>.
Auth-Application-Id AVPの値も<Diameter ERP>に設定されます。
The EAP-Payload AVP contains the EAP-Finish/Re-auth message.
EAP-Payload AVPには、EAP-Finish / Re-authメッセージが含まれています。
If authentication is successful, an instance of the Key AVP containing the rMSK derived by ERP is included.
認証が成功した場合、ERPによって導出されたrMSKを含むKey AVPのインスタンスが含まれます。
When the authenticator receives this ERP/DEA answer, it processes it as described in the Diameter EAP Application specification [RFC4072] and RFC 6696: the content of the EAP-Payload AVP is forwarded to the peer, and the contents of the Keying-Material AVP [RFC6734] is used as a shared secret for a secure association protocol specific to the lower layer in use.
オーセンティケーターはこのERP / DEA応答を受信すると、Diameter EAP Application仕様[RFC4072]およびRFC 6696で説明されているように処理します。EAP-PayloadAVPのコンテンツはピアに転送され、Keying-MaterialのコンテンツはAVP [RFC6734]は、使用中の下位層に固有のセキュアアソシエーションプロトコルの共有秘密として使用されます。
We define a new Diameter application in this document, Diameter ERP, with an Application Id value of 13. Diameter nodes conforming to this specification in the role of the ER server MUST advertise support by including an Auth-Application-Id AVP with a value of Diameter ERP in the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands [RFC6733].
このドキュメントでは、アプリケーションID値が13の新しいDiameterアプリケーションを定義します。DiameterERPは、ERサーバーの役割でこの仕様に準拠するDiameterノードが、Auth-Application-Id AVPの値を指定してサポートをアドバタイズする必要があります。 Capabilities-Exchange-RequestコマンドとCapabilities-Exchange-AnswerコマンドのDiameter ERP [RFC6733]。
The primary use of the Diameter ERP Application Id is to ensure proper routing of the messages, and that the nodes that advertise the support for this application do understand the new AVPs defined in Section 8, although these AVPs have the 'M' flag cleared.
Diameter ERPアプリケーションIDの主な用途は、メッセージの適切なルーティングを確保することと、このアプリケーションのサポートをアドバタイズするノードがセクション8で定義された新しいAVPを理解することですが、これらのAVPは「M」フラグがクリアされています。
The following subsections discuss the AVPs used by the Diameter ERP application.
次のサブセクションでは、Diameter ERPアプリケーションで使用されるAVPについて説明します。
The ERP-RK-Request AVP (AVP Code 618) is of type Grouped AVP. This AVP is used by the ER server to indicate its willingness to act as the ER server for a particular session.
ERP-RK-Request AVP（AVPコード618）は、グループ化されたAVPタイプです。このAVPは、特定のセッションでERサーバーとして機能する意思を示すためにERサーバーによって使用されます。
This AVP has the 'M' and 'V' bits cleared.
このAVPは「M」および「V」ビットがクリアされています。
ERP-RK-Request ::= < AVP Header: 618 >
{ ERP-Realm }
* [ AVP ]
Figure 5: ERP-RK-Request ABNF
図5：ERP-RK-Request ABNF
The ERP-Realm AVP (AVP Code 619) is of type DiameterIdentity. It contains the name of the realm in which the ER server is located.
ERP-Realm AVP（AVPコード619）のタイプはDiameterIdentityです。これには、ERサーバーが配置されているレルムの名前が含まれています。
This AVP has the 'M' and 'V' bits cleared.
このAVPは「M」および「V」ビットがクリアされています。
The Key AVP [RFC6734] is of type Grouped and is used to carry the rRK or rMSK and associated attributes. The usage of the Key AVP and its constituent AVPs in this application is specified in the following subsections.
キーAVP [RFC6734]はグループ化されたタイプであり、rRKまたはrMSKおよび関連する属性を運ぶために使用されます。このアプリケーションでのKey AVPとその構成AVPの使用法は、次のサブセクションで指定されています。
The value of the Key-Type AVP MUST be set to 1 for rRK or 2 for rMSK.
Key-Type AVPの値は、rRKの場合は1に、rMSKの場合は2に設定する必要があります。
The Keying-Material AVP contains the rRK sent by the home EAP server to the ER server, in answer to a request containing an ERP-RK-Request AVP, or the rMSK sent by the ER server to the authenticator. How this material is derived and used is specified in RFC 6696.
Keying-Material AVPには、ERP-RK-Request AVPを含む要求への応答として、ホームEAPサーバーからERサーバーに送信されたrRK、またはERサーバーから認証システムに送信されたrMSKが含まれています。この資料の派生方法と使用方法は、RFC 6696で指定されています。
This AVP contains the EMSKname that identifies the keying material. The derivation of this name is specified in RFC 6696.
このAVPには、キー情報を識別するEMSKnameが含まれています。この名前の派生はRFC 6696で指定されています。
The Key-Lifetime AVP contains the lifetime of the keying material in seconds. It MUST NOT be greater than the remaining lifetime of the EMSK from which the material was derived.
Key-Lifetime AVPには、キーイングマテリアルの寿命が秒単位で含まれています。材料の元となったEMSKの残りの寿命を超えてはなりません。
This section defines new Result-Code [RFC6733] values that MUST be supported by all Diameter implementations that conform to this specification.
このセクションでは、この仕様に準拠するすべてのDiameter実装でサポートする必要がある新しいResult-Code [RFC6733]値を定義します。
Errors that fall within the Permanent Failures category are used to inform the peer that the request failed and SHOULD NOT be attempted again.
Permanent Failuresカテゴリに該当するエラーは、リクエストが失敗したことをピアに通知するために使用され、再試行すべきではありません。
DIAMETER_ERROR_EAP_CODE_UNKNOWN (5048)
DIAMETER_ERROR_EAP_CODE_UNKNOWN（5048）
This error code is used by the Diameter server to inform the peer that the received EAP-Payload AVP contains an EAP packet with an unknown EAP code.
Diameterサーバーはこのエラーコードを使用して、受信したEAP-Payload AVPに未知のEAPコードのEAPパケットが含まれていることをピアに通知します。
IANA has registered the following new elements in the Authentication, Authorization, and Accounting (AAA) Parameters registries [AAAPARAMS].
IANAは、認証、承認、およびアカウンティング（AAA）パラメータレジストリ[AAAPARAMS]に次の新しい要素を登録しました。
IANA has allocated a new value "Diameter ERP" (code: 13) in the "Application IDs" registry from the "Standards Action" range of numbers using the "Specification Required" policy [RFC5226]; see Section 11.3 of RFC 3588 [RFC3588] for further details.
IANAは、「Specification Required」ポリシー[RFC5226]を使用して、「Standards Action」範囲の数値から「Application IDs」レジストリに新しい値「Diameter ERP」（コード：13）を割り当てました。詳細については、RFC 3588 [RFC3588]のセクション11.3を参照してください。
IANA has allocated new values from the "AVP Codes" registry according to the policy specified in Section 11.1 of Fajardo, et al. [RFC6733] for the following AVPs:
IANAは、ファハルドらのセクション11.1で指定されたポリシーに従って、「AVPコード」レジストリから新しい値を割り当てました。 [RFC6733]以下のAVP向け：
ERP-RK-Request (code: 618)
ERP-RK-Request（コード：618）
ERP-Realm (code: 619)
ERP-Realm（コード：619）
These AVPs are defined in Section 8.
これらのAVPはセクション8で定義されています。
IANA has allocated a new value from the "Result-Code AVP Values (code 268) - Permanent Failure" registry according to the policy specified in Section 11.3.2 of Fajardo, et al. [RFC6733] for the following Result-Code:
IANAは、ファハルドらのセクション11.3.2で指定されたポリシーに従って、「結果コードAVP値（コード268）-永続的な障害」レジストリから新しい値を割り当てました。 [RFC6733]次の結果コードの場合：
DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: 5048)
DIAMETER_ERROR_EAP_CODE_UNKNOWN（コード：5048）
This Result-Code value is defined in Section 9.
このResult-Code値はセクション9で定義されています。
The security considerations from the following documents apply here:
ここでは、次のドキュメントのセキュリティに関する考慮事項が適用されます。
o Eronen, et al. [RFC4072]
o エロネン他[RFC4072]
o Salowey, et al. [RFC5295]
o Salowey、他。 [RFC5295]
o Cao, et al. [RFC6696]
o 曹、他[RFC6696]
o Fajardo, et al. [RFC6733]
o Fjrdhら[ラフサタ]
o Zorn, et al. [RFC6734]
o Zorn、et al。 [RFC6734]
Because this application involves the transmission of sensitive data, including cryptographic keys, it MUST be protected using Transport Layer Security (TLS) [RFC5246], Datagram Transport Layer Security (DTLS) [RFC6347], or IP Encapsulating Security Payload (ESP) [RFC4303]. If TLS or DTLS is used, the bulk encryption algorithm negotiated MUST be non-null. If ESP is used, the encryption algorithm MUST be non-null.
このアプリケーションは、暗号鍵を含む機密データの送信を伴うため、トランスポート層セキュリティ（TLS）[RFC5246]、データグラムトランスポート層セキュリティ（DTLS）[RFC6347]、またはIPカプセル化セキュリティペイロード（ESP）[RFC4303を使用して保護する必要があります。 ]。 TLSまたはDTLSを使用する場合、ネゴシエートされるバルク暗号化アルゴリズムはnull以外にする必要があります。 ESPを使用する場合、暗号化アルゴリズムはnull以外にする必要があります。
Hannes Tschofenig wrote the initial draft of this document.
Hannes Tschofenigがこのドキュメントの最初の草稿を書きました。
Lakshminath Dondeti contributed to the early drafts of the document.
ラクシュミナート・ドンデティはこの文書の初期草稿に貢献した。
Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem Dodge, Vincent Roca, Stephen Farrell, Sean Turner, Pete Resnick, Russ Housley, Martin Stiemerling, and Jouni Korhonen provided useful reviews.
Hannes Tschofenig、Zhen Cao、Benoit Claise、Elwyn Davies、Menachem Dodge、Vincent Roca、Stephen Farrell、Sean Turner、Pete Resnick、Russ Housley、Martin Stiemerling、およびJouni Korhonenは有益なレビューを提供しました。
Vidya Narayanan reviewed a rough draft version of the document and found some errors.
Vidya Narayananがこの文書のラフドラフトバージョンをレビューしたところ、いくつかのエラーが見つかりました。
Many thanks to these people!
これらの人々に感謝します！
[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月。
[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月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072] Eronen、P.、Hiller、T。、およびG. Zorn、「Diameter Extensible Authentication Protocol（EAP）Application」、RFC 4072、2005年8月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[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月。
[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月。
[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, Q., and V. Cakulev, "Diameter Attribute-Value Pairs for Cryptographic Key Transport", RFC 6734, October 2012.
[RFC6734] Zorn、G.、Wu、Q。、およびV. Cakulev、「暗号化キートランスポートの直径の属性値ペア」、RFC 6734、2012年10月。
[AAAPARAMS] Internet Assigned Numbers Authority, "Authentication, Authorization, and Accounting (AAA) Parameters", <http://www.iana.org/assignments/aaa-parameters/>.
[AAAPARAMS] Internet Assigned Numbers Authority、「Authentication、Authorization、and Accounting（AAA）Parameters」、<http://www.iana.org/assignments/aaa-parameters/>。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588] Calhoun、P.、Loughney、J.、Guttman、E.、Zorn、G。、およびJ. Arkko、「Diameter Base Protocol」、RFC 3588、2003年9月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月。
Authors' Addresses
著者のアドレス
Julien Bournelle Orange Labs 38-40 rue du general Leclerc Issy-Les-Moulineaux 92794 France
Julien Bournelle Orange Labs 38-40 rue du general Leclercイシレムリノー92794フランス
EMail: julien.bournelle@orange.com
Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-Les-Moulineaux 92794 France
ライオネルモランオレンジラボ38-40 rue du generalルクレールイシレムリノー92794フランス
EMail: lionel.morand@orange.com
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Aix-en-Provence 13856 France
Sebastien Decugis INSIDE Secure 41 Parc Club du Golfエクスアンプロヴァンス13856フランス
Phone: +33 (0)4 42 39 63 00
EMail: sdecugis@freediameter.net
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
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thailand
EMail: glenzorn@gmail.com