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
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支持。它定义了一个新的Diameter ERP应用程序，用于在ER认证器和ER服务器之间传输ERP消息，以及一组新的属性值对（AVP），可用于传输重新认证服务器所需的加密材料。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2013 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. 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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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:
Cao等人[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服务器之间的一次往返交换，导致相互身份验证。为了支持EAP重新认证功能，ERP定义了两个新的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等人[RFC5295]的第7.4节详细介绍了此密钥分发的安全注意事项。
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）是从特定于域的根密钥（DSRK）而不是EMSK派生的重新认证根密钥（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）或“引导材料”是指从EMSK派生的rRK或rDSRK，具体取决于ER服务器位于主域还是外域。
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>（第10.1节）的Diameter EAP请求和Diameter EAP应答命令；当消息中的应用程序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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
本文档假设给定域中最多存在一个逻辑ER服务器实体。如果部署多个物理服务器以实现健壮性，则必须部署复制机制以在这些服务器之间同步ERP状态（例如，根密钥）。任何此类复制机制都不在本文档的范围内。如果域中部署了多个ER服务器，我们假设它们可以互换使用。如果多个ER服务器跨多个域部署，我们假设ERP中只涉及一个ER服务器，在拓扑上靠近对等服务器，距离以直径跃点来度量。
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.
本文档还假设主域中最多存在一个EAP服务器实体。在多个物理家庭EAP服务器的情况下，如果ER服务器想要到达同一个家庭EAP服务器，ER服务器应该缓存其请求的家庭EAP服务器对应的目标主机AVP。
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.
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。第6节详细介绍了ERP/DER消息的生成。
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服务器，则必须配置Diameter路由，以便此ERP/DER消息到达该服务器，即使目标域与本地域不同。
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服务器，则根据从keyName NAI属性的领域组件提取的目标领域AVP内容路由消息。如RFC 6696中所述，在引导exchange的情况下，此域是对等方的主域（“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_canable_TO_DELIVER，并将其返回给验证器。验证器可以缓存此信息（有限的持续时间），以避免进一步尝试使用此域执行ERP。它还可以回退到完全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
当ER服务器接收到ERP/DER消息时，它会在其本地数据库中搜索与用户名AVP的keyName部分匹配的有效、未过期的根密钥。如果找到该密钥，ER服务器将处理
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.
如RFC 6696所述，ERP消息随后创建ERP/DEA应答，如第6节所述。重新认证主会话密钥（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.
最后，认证器从ERP/DEA中提取rMSK，如RFC 6696中所述，并将EAP有效负载AVP的内容、EAP完成/重新认证消息转发给对等方。
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交换的对等方。否则，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创建时）、第一次重新身份验证期间或这些事件之间的某个时间。在下面的小节中，我们只考虑本说明书中的前两种可能性。
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路由，以便Diameter EAP应用程序消息通过该代理进行路由。下图说明了这种机制。
ER server &
Authenticator EAP Proxy Home EAP server
============= =========== ===============
------------------------->
Diameter EAP/DER
(EAP-Response)
------------------------->
Diameter EAP/DER
(EAP-Response)
(ERP-RK-Request)
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
<==================================================>
Multi-round Diameter EAP exchanges, unmodified
<-------------------------
Diameter EAP/DEA
(EAP-Success)
(MSK)
(Key AVP (rRK))
<-------------------------
Diameter EAP/DEA
(EAP-Success)
(MSK)
[ERP-Realm]
<-------------------------
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请求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.
如果home Diameter服务器不支持Diameter ERP扩展，它将忽略ERP RK请求AVP，并按照RFC 4072[RFC4072]中的规定继续。如果服务器支持ERP扩展，它将保存ERP RK请求AVP中的ERP领域AVP值，并继续执行EAP身份验证。认证完成后，如果认证成功且EAP方法已生成EMSK，则服务器必须使用保存的ERP领域名称派生RFC 6696中指定的rRK。然后，它将rRK包含在密钥AVP（第8.3节）中，密钥类型AVP设置为rRK，然后像往常一样发送DEA。
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服务器代理Diameter EAP应答消息时，其会话Id与添加了ERP RK请求AVP的消息相对应，且结果代码为Diameter_SUCCESS，则必须检查该消息，并保存和删除密钥类型AVP设置为rRK的任何密钥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领域信息通知对等方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被重用以派生根密钥，因此资源密集度较低。另一方面，第一次重新认证需要与家庭EAP服务器进行一次往返交换，因为EMSK在初始EAP认证期间生成，并且从不离开家庭EAP服务器，这比隐式引导效率低。
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服务器接收ERP/DER消息，其中包含设置了“B”标志的EAP Initiate/Re auth消息。它使用接收到的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.
从ERP/DER消息中提取ERP RK请求AVP，该消息包含ER服务器所在域的名称，并将其添加到新创建的ERP/DER消息中。
Then, the newly created EAP/DER is sent and routed to the home Diameter EAP application server.
然后，新创建的EAP/DER被发送并路由到home 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.
如果home Diameter EAP服务器不支持ERP扩展，则无法理解具有未知ERP特定代码（EAP Initiate）的EAP数据包。在这种情况下，home Diameter EAP服务器必须发送EAP/DEA，其结果代码指示永久性故障（例如，Diameter\u错误\u EAP\u代码\u未知或Diameter\u无法遵守）。必须包括故障AVP AVP，并包含EAP有效负载AVP的副本。否则，它将处理DSRK请求，如RFC 6696中所述。特别是，它包括域名TLV属性和来自ERP领域AVP的内容。服务器创建EAP/DEA回复消息[RFC4072]，包括密钥类型AVP设置为rRK的密钥AVP实例（第8.3节）和包含ERP领域AVP内容的域名TLV属性实例。
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).
提取并缓存密钥类型设置为rRK的密钥AVP的内容，如第5.1）节所述。
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)
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))
<------------------------
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 ]
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
----------------------->
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
<===============================
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.
对等方通过验证器向ER服务器发送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（纯直径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消息时，按照RFC 6696中关于EAP状态机的描述处理该消息。它按照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>.
身份验证应用程序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属性用于创建用户名和目标域AVP的内容。
The Auth-Request-Type AVP content is set to the appropriate value.
身份验证请求类型AVP内容设置为适当的值。
The EAP-Payload AVP contains the EAP-Initiate/Re-auth message.
EAP有效负载AVP包含EAP启动/重新验证消息。
Then, this ERP/DER message is sent as described in Section 4.
然后，如第4节所述发送此ERP/DER消息。
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等人[RFC4072]中描述的一般流程创建ERP/DEA消息，其区别如下：
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>.
身份验证应用程序Id AVP的值也设置为<Diameter ERP>。
The EAP-Payload AVP contains the EAP-Finish/Re-auth message.
EAP有效负载AVP包含EAP完成/重新验证消息。
If authentication is successful, an instance of the Key AVP containing the rMSK derived by ERP is included.
如果认证成功，则包括包含由ERP派生的rMSK的密钥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应用规范[RFC4072]和RFC 6696中的描述进行处理：EAP有效载荷AVP的内容转发给对等方，键控材料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].
我们在本文中定义了一个新的Diameter应用程序Diameter ERP，其应用程序Id值为13。担任ER服务器角色的符合本规范的Diameter节点必须通过在功能交换请求和功能交换应答命令[RFC6733]中包含值为Diameter ERP的身份验证应用程序Id AVP来公布支持。
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请求AVP（AVP代码618）属于分组AVP类型。ER服务器使用此AVP表示其愿意充当特定会话的ER服务器。
This AVP has the 'M' and 'V' bits cleared.
此AVP清除了“M”和“V”位。
ERP-RK-Request ::= < AVP Header: 618 >
{ ERP-Realm }
* [ AVP ]
ERP-RK-Request ::= < AVP Header: 618 >
{ ERP-Realm }
* [ AVP ]
Figure 5: ERP-RK-Request ABNF
图5:ERP RK请求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领域AVP（AVP代码619）为直径类型。它包含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以及相关属性。本应用中密钥AVP及其组成AVP的用法在以下小节中规定。
The value of the Key-Type AVP MUST be set to 1 for rRK or 2 for rMSK.
密钥类型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.
密钥材料AVP包含家庭EAP服务器发送到ER服务器的rRK，以响应包含ERP RK请求AVP的请求，或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.
密钥生存期AVP包含密钥材料的生存期（以秒为单位）。其不得大于材料来源的EMSK的剩余寿命。
This section defines new Result-Code [RFC6733] values that MUST be supported by all Diameter implementations that conform to this specification.
本节定义了所有符合本规范的Diameter实现必须支持的新结果代码[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.
属于永久故障类别的错误用于通知对等方请求失败，不应再次尝试。
DIAMETER_ERROR_EAP_CODE_UNKNOWN (5048)
直径错误EAP代码未知（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有效负载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已使用“所需规范”策略[RFC5226]，从“标准行动”数字范围的“应用程序ID”注册表中分配了一个新值“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已根据Fajardo等人[RFC6733]第11.1节规定的政策，从“AVP代码”注册表中为以下AVP分配了新值：
ERP-RK-Request (code: 618)
ERP RK请求（代码：618）
ERP-Realm (code: 619)
ERP领域（代码：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已根据Fajardo等人[RFC6733]第11.3.2节规定的政策，从“结果代码AVP值（代码268）-永久故障”注册表中为以下结果代码分配了一个新值：
DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: 5048)
直径错误EAP代码未知（代码：5048）
This Result-Code value is defined in Section 9.
该结果代码值在第9节中定义。
The security considerations from the following documents apply here:
以下文件中的安全注意事项适用于此处：
o Eronen, et al. [RFC4072]
o Eronen等[RFC4072]
o Salowey, et al. [RFC5295]
o Salowey等[RFC5295]
o Cao, et al. [RFC6696]
o 曹等人[RFC6696]
o Fajardo, et al. [RFC6733]
o Fajardo等[RFC6733]
o Zorn, et al. [RFC6734]
o Zorn等人[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，则协商的批量加密算法必须为非空。如果使用ESP，则加密算法必须为非空。
Hannes Tschofenig wrote the initial draft of this document.
Hannes Tschofenig编写了这份文件的初稿。
Lakshminath Dondeti contributed to the early drafts of the document.
Lakshminath Dondeti为该文件的早期草案做出了贡献。
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 Stiemering和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，“可扩展身份验证协议（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，“直径可扩展认证协议（EAP）应用”，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，“在RFCs中编写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 52952008年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再认证协议（ERP）的EAP扩展”，RFC 66962012年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，“直径基准协议”，RFC 67332012年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]互联网分配号码管理局，“身份验证、授权和记帐（AAA）参数”<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，“直径基础协议”，RFC 3588，2003年9月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，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，“传输层安全（TLS）协议版本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，“数据报传输层安全版本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号伊西-勒穆勒内克斯92794
EMail: julien.bournelle@orange.com
EMail: julien.bournelle@orange.com
Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-Les-Moulineaux 92794 France
法国莱克勒将军街38-40号莱昂内尔·莫兰橙实验室
EMail: lionel.morand@orange.com
EMail: lionel.morand@orange.com
Sebastien Decugis INSIDE Secure 41 Parc Club du Golf Aix-en-Provence 13856 France
塞巴斯蒂安·德库吉斯（Sebastien Decugis）位于法国普罗旺斯艾克斯41公园高尔夫俱乐部，邮编13856
Phone: +33 (0)4 42 39 63 00
EMail: sdecugis@freediameter.net
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
中国江苏省南京市雨花区软件大道101号秦武华为技术有限公司210012
EMail: sunseawq@huawei.com
EMail: sunseawq@huawei.com
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
格伦佐恩网络禅宗227/358泰国曼谷Thanon Sanphawut Bang Na 10260
EMail: glenzorn@gmail.com
EMail: glenzorn@gmail.com