Network Working Group N. Cam-Winget
Request for Comments: 5422 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
March 2009
Network Working Group N. Cam-Winget
Request for Comments: 5422 D. McGrew
Category: Informational J. Salowey
H. Zhou
Cisco Systems
March 2009
Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
通过安全隧道可扩展身份验证协议（EAP-FAST）使用灵活身份验证的动态资源调配
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
IESG Note
IESG注释
EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST.
EAP-FAST已经被许多供应商实现，并在互联网上使用。本规范的发布旨在通过记录EAP-FAST中现有EAP方法的当前使用情况来促进互操作性。
The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In order to minimize the risk associated with an anonymous tunnel, changes to the method were made that are not interoperable with EAP-MSCHAPv2. Since EAP-MSCHAPv2 does not support method-specific version negotiation, the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous EAP-FAST tunnel. This behavior may cause problems in implementations where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous EAP-FAST tunnel. Since such support requires special case execution of a method within a tunnel, it also complicates implementations that use the same method code both within and outside of the tunnel method. If EAP-FAST were to be designed today, these difficulties could be avoided by utilization of unique EAP Type codes. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future.
EAP方法EAP-FAST-MSCHAPv2重用分配给EAP-MSCHAPv2（26）的EAP类型代码，以便在匿名TLS隧道内进行身份验证。为了最大限度地降低与匿名隧道相关的风险，对方法进行了无法与EAP-MSCHAPv2互操作的更改。由于EAP-MSCHAPv2不支持特定于方法的版本协商，因此通过使用匿名EAP-FAST隧道来暗示EAP-FAST-MSCHAPv2的使用。在匿名EAP-FAST隧道内需要使用未经更改的EAP-MSCHAPv2的实现中，此行为可能会导致问题。由于这种支持需要在隧道内执行方法的特殊情况，因此在隧道方法内外使用相同方法代码的实现也会变得复杂。如果EAP-FAST是今天设计的，这些困难可以通过使用独特的EAP类型代码来避免。鉴于这些问题，指定的方法类型在将来的隧道方法中不得以不同的含义重复使用。
Abstract
摘要
The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) method enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. EAP-FAST also enables the provisioning credentials or other information through this protected tunnel. This document describes the use of EAP-FAST for dynamic provisioning.
通过安全隧道可扩展认证协议（EAP-FAST）的灵活认证方法通过使用传输层安全性（TLS）建立相互认证的隧道，实现对等方和服务器之间的安全通信。EAP-FAST还通过此受保护的隧道启用设置凭据或其他信息。本文档介绍了EAP-FAST在动态资源调配中的使用。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Specification Requirements .................................4
1.2. Terminology ................................................4
2. EAP-FAST Provisioning Modes .....................................5
3. Dynamic Provisioning Using EAP-FAST Conversation ................6
3.1. Phase 1 TLS Tunnel .........................................7
3.1.1. Server-Authenticated Tunnel .........................7
3.1.2. Server-Unauthenticated Tunnel .......................7
3.2. Phase 2 - Tunneled Authentication and Provisioning .........7
3.2.1. Server-Authenticated Tunneled Authentication ........8
3.2.2. Server-Unauthenticated Tunneled Authentication ......8
3.2.3. Authenticating Using EAP-FAST-MSCHAPv2 ..............8
3.2.4. Use of Other Inner EAP Methods for EAP-FAST
Provisioning ........................................9
3.3. Key Derivations Used in the EAP-FAST Provisioning
Exchange ..................................................10
3.4. Peer-Id, Server-Id, and Session-Id ........................11
3.5. Network Access after EAP-FAST Provisioning ................11
4. Information Provisioned in EAP-FAST ............................12
1. Introduction ....................................................4
1.1. Specification Requirements .................................4
1.2. Terminology ................................................4
2. EAP-FAST Provisioning Modes .....................................5
3. Dynamic Provisioning Using EAP-FAST Conversation ................6
3.1. Phase 1 TLS Tunnel .........................................7
3.1.1. Server-Authenticated Tunnel .........................7
3.1.2. Server-Unauthenticated Tunnel .......................7
3.2. Phase 2 - Tunneled Authentication and Provisioning .........7
3.2.1. Server-Authenticated Tunneled Authentication ........8
3.2.2. Server-Unauthenticated Tunneled Authentication ......8
3.2.3. Authenticating Using EAP-FAST-MSCHAPv2 ..............8
3.2.4. Use of Other Inner EAP Methods for EAP-FAST
Provisioning ........................................9
3.3. Key Derivations Used in the EAP-FAST Provisioning
Exchange ..................................................10
3.4. Peer-Id, Server-Id, and Session-Id ........................11
3.5. Network Access after EAP-FAST Provisioning ................11
4. Information Provisioned in EAP-FAST ............................12
4.1. Protected Access Credential ...............................12
4.1.1. Tunnel PAC .........................................13
4.1.2. Machine Authentication PAC .........................13
4.1.3. User Authorization PAC .............................13
4.1.4. PAC Provisioning ...................................14
4.2. PAC TLV Format ............................................15
4.2.1. Formats for PAC Attributes .........................16
4.2.2. PAC-Key ............................................16
4.2.3. PAC-Opaque .........................................17
4.2.4. PAC-Info ...........................................18
4.2.5. PAC-Acknowledgement TLV ............................20
4.2.6. PAC-Type TLV .......................................21
4.3. Trusted Server Root Certificate ...........................21
4.3.1. Server-Trusted-Root TLV ............................22
4.3.2. PKCS#7 TLV .........................................23
5. IANA Considerations ............................................24
6. Security Considerations ........................................25
6.1. Provisioning Modes and Man-in-the-Middle Attacks ..........25
6.1.1. Server-Authenticated Provisioning Mode and
Man-in-the-Middle Attacks ..........................26
6.1.2. Server-Unauthenticated Provisioning Mode
and Man-in-the-Middle Attacks ......................26
6.2. Dictionary Attacks ........................................27
6.3. Considerations in Selecting a Provisioning Mode ...........28
6.4. Diffie-Hellman Groups .....................................28
6.5. Tunnel PAC Usage ..........................................28
6.6. Machine Authentication PAC Usage ..........................29
6.7. User Authorization PAC Usage ..............................29
6.8. PAC Storage Considerations ................................29
6.9. Security Claims ...........................................31
7. Acknowledgements ...............................................31
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. Examples .............................................33
A.1. Example 1: Successful Tunnel PAC Provisioning .............33
A.2. Example 2: Failed Provisioning ............................35
A.3. Example 3: Provisioning an Authentication Server's
Trusted Root Certificate ..................................37
4.1. Protected Access Credential ...............................12
4.1.1. Tunnel PAC .........................................13
4.1.2. Machine Authentication PAC .........................13
4.1.3. User Authorization PAC .............................13
4.1.4. PAC Provisioning ...................................14
4.2. PAC TLV Format ............................................15
4.2.1. Formats for PAC Attributes .........................16
4.2.2. PAC-Key ............................................16
4.2.3. PAC-Opaque .........................................17
4.2.4. PAC-Info ...........................................18
4.2.5. PAC-Acknowledgement TLV ............................20
4.2.6. PAC-Type TLV .......................................21
4.3. Trusted Server Root Certificate ...........................21
4.3.1. Server-Trusted-Root TLV ............................22
4.3.2. PKCS#7 TLV .........................................23
5. IANA Considerations ............................................24
6. Security Considerations ........................................25
6.1. Provisioning Modes and Man-in-the-Middle Attacks ..........25
6.1.1. Server-Authenticated Provisioning Mode and
Man-in-the-Middle Attacks ..........................26
6.1.2. Server-Unauthenticated Provisioning Mode
and Man-in-the-Middle Attacks ......................26
6.2. Dictionary Attacks ........................................27
6.3. Considerations in Selecting a Provisioning Mode ...........28
6.4. Diffie-Hellman Groups .....................................28
6.5. Tunnel PAC Usage ..........................................28
6.6. Machine Authentication PAC Usage ..........................29
6.7. User Authorization PAC Usage ..............................29
6.8. PAC Storage Considerations ................................29
6.9. Security Claims ...........................................31
7. Acknowledgements ...............................................31
8. References .....................................................31
8.1. Normative References ......................................31
8.2. Informative References ....................................32
Appendix A. Examples .............................................33
A.1. Example 1: Successful Tunnel PAC Provisioning .............33
A.2. Example 2: Failed Provisioning ............................35
A.3. Example 3: Provisioning an Authentication Server's
Trusted Root Certificate ..................................37
EAP-FAST [RFC4851] is an EAP method that can be used to mutually authenticate the peer and server. Credentials such as a pre-shared key, certificate trust anchor, or a Protected Access Credential (PAC) must be provisioned to the peer before it can establish mutual authentication with the server. In many cases, the provisioning of such information presents deployment hurdles. Through the use of the protected TLS [RFC5246] tunnel, EAP-FAST can enable dynamic in-band provisioning to address such deployment obstacles.
EAP-FAST[RFC4851]是一种EAP方法，可用于对对等方和服务器进行相互身份验证。必须向对等方提供凭据，例如预共享密钥、证书信任锚或受保护的访问凭据（PAC），然后对等方才能与服务器建立相互身份验证。在许多情况下，提供此类信息会带来部署障碍。通过使用受保护的TLS[RFC5246]隧道，EAP-FAST可以实现动态带内资源调配，以解决此类部署障碍。
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]中所述进行解释。
Much of the terminology used in this document comes from [RFC3748]. The terms "peer" and "server" are used interchangeably with the terms "EAP peer" and "EAP server", respectively. Additional terms are defined below:
本文件中使用的许多术语来自[RFC3748]。术语“对等”和“服务器”分别与术语“EAP对等”和“EAP服务器”互换使用。其他术语定义如下：
Man in the Middle (MITM)
中间人（米特）
An adversary that can successfully inject itself between a peer and EAP server. The MITM succeeds by impersonating a valid peer or server.
能够在对等服务器和EAP服务器之间成功注入自身的对手。MITM通过模拟有效的对等方或服务器而成功。
Provisioning
供应
Providing a peer with a trust anchor, shared secret, or other appropriate information needed to establish a security association.
为对等方提供建立安全关联所需的信任锚、共享秘密或其他适当信息。
Protected Access Credential (PAC)
受保护访问凭据（PAC）
Credentials distributed to a peer for future optimized network authentication. The PAC consists of at most three components: a shared secret, an opaque element, and optional information. The shared secret part contains the secret key shared between the peer and server. The opaque part contains the shared secret encrypted by a private key only known to the server. It is provided to the peer and is presented back to the server when the peer wishes to obtain access to network resources. Finally, a PAC may optionally include other information that may be useful to the peer.
分发给对等方的凭据，用于将来优化的网络身份验证。PAC最多由三部分组成：共享机密、不透明元素和可选信息。共享密钥部分包含对等方和服务器之间共享的密钥。不透明部分包含由只有服务器知道的私钥加密的共享秘密。它被提供给对等方，并在对等方希望访问网络资源时返回给服务器。最后，PAC可以选择性地包括对对等方可能有用的其他信息。
Tunnel PAC
隧道PAC
A set of credentials stored by the peer and consumed by both the peer and the server to establish a TLS tunnel.
由对等方存储并由对等方和服务器使用以建立TLS隧道的一组凭据。
User Authorization PAC
用户授权PAC
A User Authorization PAC is server-encrypted data containing authorization information associated with a previously authenticated user. The User Authorization PAC does not contain a key, but rather it is generally bound to a Tunnel PAC, which is used with the User Authorization PAC.
用户授权PAC是服务器加密的数据，其中包含与先前经过身份验证的用户关联的授权信息。用户授权PAC不包含密钥，而是通常绑定到隧道PAC，该隧道PAC与用户授权PAC一起使用。
Machine Authentication PAC
机器认证PAC
A Machine Authentication PAC contains server-encrypted data containing authorization information associated with a device. A Machine Authentication PAC may be used instead of a Tunnel PAC to establish the TLS tunnel to provide machine authentication and authorization information. The Machine Authentication PAC is useful in cases where the machine needs to be authenticated and authorized to access a network before a user has logged in.
机器身份验证PAC包含服务器加密数据，其中包含与设备关联的授权信息。可以使用机器认证PAC代替隧道PAC来建立TLS隧道以提供机器认证和授权信息。机器身份验证PAC在用户登录之前需要对机器进行身份验证和授权才能访问网络的情况下非常有用。
EAP-FAST supports two modes for provisioning:
EAP-FAST支持两种配置模式：
1. Server-Authenticated Provisioning Mode - Provisioning inside a TLS tunnel that provides server-side authentication.
1. 服务器身份验证配置模式—在提供服务器端身份验证的TLS隧道内进行配置。
2. Server-Unauthenticated Provisioning Mode - Provisioning inside an anonymous TLS tunnel.
2. 服务器未经身份验证的配置模式-在匿名TLS隧道内进行配置。
The EAP-FAST provisioning modes use EAP-FAST phase 2 inside a secure TLS tunnel established during phase 1. [RFC4851] describes the EAP-FAST phases in greater detail.
EAP-FAST配置模式在第1阶段建立的安全TLS隧道内使用EAP-FAST第2阶段。[RFC4851]更详细地描述了EAP-FAST阶段。
In the Server-Authenticated Provisioning Mode, the peer has successfully authenticated the EAP server as part of EAP-FAST phase 1 (i.e., TLS tunnel establishment). Additional exchanges MAY occur inside the tunnel to allow the EAP server to authenticate the EAP peer before provisioning any information.
在服务器认证供应模式下，对等方已成功认证EAP服务器，作为EAP-FAST阶段1（即TLS隧道建立）的一部分。隧道内可能会发生额外的交换，以允许EAP服务器在提供任何信息之前对EAP对等方进行身份验证。
In the Server-Unauthenticated Provisioning Mode, an unauthenticated TLS tunnel is established in the EAP-FAST phase 1. The peer MUST negotiate a TLS anonymous Diffie-Hellman-based ciphersuite to signal
在服务器未经验证的配置模式下，在EAP-FAST阶段1中建立未经验证的TLS隧道。对等方必须协商基于TLS匿名Diffie-Hellman的密码套件以发出信号
that it wishes to use Server-Unauthenticateded Provisioning Mode. This provisioning mode enables the bootstrapping of peers where the peer lacks strong credentials usable for mutual authentication with the server.
它希望使用未经验证的服务器配置模式。此配置模式支持对等机的引导，其中对等机缺少可用于与服务器进行相互身份验证的强凭据。
Since the server is not authenticated in the Server-Unauthenticated Provisioning Mode, it is possible that an attacker may intercept the TLS tunnel. If an anonymous tunnel is used, then the peer and server MUST negotiate and successfully complete an EAP method supporting mutual authentication and key derivation as described in Section 6. The peer then uses the Crypto-Binding TLV to validate the integrity of the TLS tunnel, thereby verifying that the exchange was not subject to a man-in-the-middle attack.
由于服务器未在服务器未经身份验证的配置模式下进行身份验证，因此攻击者可能会拦截TLS隧道。如果使用匿名隧道，则对等方和服务器必须协商并成功完成支持相互认证和密钥派生的EAP方法，如第6节所述。然后，对等方使用加密绑定TLV来验证TLS隧道的完整性，从而验证交换没有受到中间人攻击。
Server-Authenticated Provisioning Mode protects against the man-in-the-middle attack; however, it requires provisioning the peer with the credentials necessary to authenticate the server. Environments willing to trade off the security risk of a man-in-the-middle attack for ease of deployment can choose to use the Server-Unauthenticated Provisioning Mode.
服务器认证配置模式可防止中间人攻击；但是，它需要为对等方提供对服务器进行身份验证所需的凭据。如果环境愿意权衡中间人攻击的安全风险以便于部署，则可以选择使用服务器未经验证的资源调配模式。
Assuming that an inner EAP method and Crypto-Binding TLV exchange is successful, the server will subsequently provide credential information, such as a shared key using a PAC TLV or the trusted certificate root(s) of the server using a Server-Trusted-Root TLV. Once the EAP-FAST Provisioning conversation completes, the peer is expected to use the provisioned credentials in subsequent EAP-FAST authentications.
假设内部EAP方法和加密绑定TLV交换成功，服务器随后将提供凭据信息，例如使用PAC TLV的共享密钥或使用服务器受信任根TLV的服务器受信任证书根。一旦EAP-FAST配置会话完成，对等方将在后续EAP-FAST身份验证中使用配置的凭据。
The provisioning occurs in the following steps, which are detailed in the subsequent sections and in RFC 4851. First, the EAP-FAST phase 1 TLS tunnel is established. During this process, extra material is extracted from the TLS key derivation for use as challenges in the subsequent authentication exchange. Next, an inner EAP method, such as EAP-FAST-MSCHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2), is executed within the EAP-FAST phase 2 TLS tunnel to authenticate the client using the challenges derived from the phase 1 TLS exchange. Following successful authentication and Crypto-Binding TLV exchange, the server provisions the peer with PAC information including the secret PAC-Key and the PAC-Opaque. Finally, the EAP-FAST conversation completes with Result TLV exchanges defined in RFC 4851. The exported EAP Master Session Key (MSK) and Extended MSK (EMSK) are derived from a combination of the tunnel key material and key material from the inner EAP method exchange.
供应在以下步骤中进行，这些步骤将在后续章节和RFC 4851中详细说明。首先，建立EAP-FAST一期TLS隧道。在此过程中，将从TLS密钥派生中提取额外的材料，以用作后续身份验证交换中的挑战。接下来，在EAP-FAST第2阶段TLS隧道内执行内部EAP方法，例如EAP-FAST-MSCHAPv2（Microsoft质询握手身份验证协议版本2），以使用源自第1阶段TLS交换的质询对客户端进行身份验证。成功进行身份验证和加密绑定TLV交换后，服务器向对等方提供PAC信息，包括机密PAC密钥和PAC密钥。最后，EAP-FAST对话以RFC 4851中定义的结果TLV交换完成。导出的EAP主会话密钥（MSK）和扩展MSK（EMSK）来自隧道密钥材料和内部EAP方法交换的密钥材料的组合。
The provisioning EAP-FAST exchange uses the same sequence as the EAP-FAST authentication phase 1 to establish a protected TLS tunnel. Implementations supporting this version of the Sever-Authenticated Provisioning Mode MUST support the following TLS ciphersuites defined in [RFC5246]:
配置EAP-FAST exchange使用与EAP-FAST身份验证阶段1相同的顺序来建立受保护的TLS隧道。支持此版本的服务器身份验证配置模式的实现必须支持[RFC5246]中定义的以下TLS密码套件：
TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_与_RC4_128_SHA TLS_RSA_与_AES_128_CBC_SHA TLS_DHE_RSA_与_AES_128_CBC_SHA
Other TLS ciphersuites that provide server authentication and encryption MAY be supported. The server MAY authenticate the peer during the TLS handshake in Server-Authenticated Provisioning Mode. To adhere to best security practices, the peer MUST validate the server's certificate chain when performing server-side authentication to obtain the full security benefits of Server-Authenticated provisioning.
可能支持提供服务器身份验证和加密的其他TLS密码套件。服务器可在TLS握手期间以服务器认证的供应模式认证对等方。为了遵守最佳安全实践，对等方必须在执行服务器端身份验证时验证服务器的证书链，以获得服务器身份验证配置的全部安全好处。
Implementations supporting this version of the Sever-Unauthenticated Provisioning Mode MUST support the following TLS ciphersuite defined in [RFC5246]:
支持此版本服务器未经验证的配置模式的实现必须支持[RFC5246]中定义的以下TLS密码套件：
TLS_DH_anon_WITH_AES_128_CBC_SHA
TLS_DH_anon_与_AES_128_CBC_SHA
Anonymous ciphersuites SHOULD NOT be allowed outside of EAP-FAST Server-Unauthenticated Provisioning Mode. Any ciphersuites that are used for Server-Unauthenticated Provisioning Mode MUST provide a key agreement contributed by both parties. Therefore, ciphersuites based on RSA key transport MUST NOT be used for this mode. Ciphersuites that are used for provisioning MUST provide encryption.
在EAP-FAST服务器未经身份验证的配置模式之外，不允许使用匿名密码套件。用于服务器未经验证的配置模式的任何密码套件必须提供双方共同提供的密钥协议。因此，基于RSA密钥传输的密码套件不能用于此模式。用于设置的密码套件必须提供加密。
Once a protected tunnel is established and the server is unauthenticated, the peer and server MUST execute additional authentication and perform integrity checks of the TLS tunnel. Even if both parties are authenticated during TLS tunnel establishment, the peer and server MAY wish to perform additional authentication within the tunnel. As defined in [RFC4851], the authentication exchange will be followed by an Intermediate-Result TLV and a Crypto-Binding TLV, if the EAP method succeeded. The Crypto-Binding TLV
一旦建立了受保护的隧道且服务器未经身份验证，对等方和服务器必须执行附加身份验证，并对TLS隧道执行完整性检查。即使双方在TLS隧道建立期间都经过身份验证，对等方和服务器也可能希望在隧道内执行附加身份验证。如[RFC4851]中所定义，如果EAP方法成功，则身份验证交换之后将出现中间结果TLV和加密绑定TLV。加密绑定TLV
provides a check on the integrity of the tunnel with respect to the endpoints of the EAP method. If the preceding is successful, then a provisioning exchange MAY take place. The provisioning exchange will use a PAC TLV exchange if a PAC is being provisioned and a Server-Trusted-Root TLV if a trusted root certificate is being provisioned. The provisioning MAY be solicited by the peer or it MAY be unsolicited. The PAC TLV exchange consists of the server distributing the PAC in a corresponding PAC TLV to the peer and the peer confirming its receipt in a final PAC TLV Acknowledgement message. The peer may also use the PAC TLV to request that the server send a PAC. The provisioning TLVs MAY be piggybacked onto the Result TLV. Many implementations process TLVs in the order they are received; thus, for proper provisioning to occur, the Result TLV MUST precede the TLVs to be provisioned (e.g., Tunnel PAC, Machine Authentication PAC, and User Authorization PAC). A PAC TLV MUST NOT be accepted if it is not encapsulated in an encrypted TLS tunnel.
提供有关EAP方法端点的隧道完整性检查。如果上述操作成功，则可能会进行资源调配交换。如果正在提供PAC，则提供exchange将使用PAC TLV exchange；如果正在提供受信任的根证书，则提供exchange将使用服务器受信任的根TLV。该供应可以由对等方请求，也可以是未经请求的。PAC TLV交换由服务器将对应PAC TLV中的PAC分发给对等方和对等方在最终PAC TLV确认消息中确认其接收组成。对等方还可以使用PAC TLV请求服务器发送PAC。配置TLV可以被装载到结果TLV上。许多实现按接收顺序处理TLV；因此，为了进行适当的配置，结果TLV必须位于要配置的TLV之前（例如，隧道PAC、机器认证PAC和用户授权PAC）。如果PAC TLV未封装在加密的TLS隧道中，则不得接受该TLV。
A fresh PAC MAY be distributed if the server detects that the PAC is expiring soon. In-band PAC refreshing is through the PAC TLV mechanism. The decision of whether or not to refresh the PAC is determined by the server. Based on the PAC-Opaque information, the server MAY determine not to refresh a peer's PAC, even if the PAC-Key has expired.
如果服务器检测到PAC即将到期，则可以分发新的PAC。带内PAC刷新是通过PAC TLV机制实现的。是否刷新PAC的决定由服务器决定。基于PAC不透明信息，服务器可能会决定不刷新对等方的PAC，即使PAC密钥已过期。
If Server-Authenticated Provisioning Mode is in use, then any EAP method may be used within the TLS tunnel to authenticate the peer that is allowed by the peer's policy.
如果正在使用服务器验证的配置模式，则可以在TLS隧道内使用任何EAP方法来验证对等方策略允许的对等方。
If Server-Unauthenticated Provisioning Mode is in use, then peer authenticates the server and the server authenticates the peer within the tunnel. The only method for performing authentication defined in this version of EAP-FAST is EAP-FAST-MSCHAPv2 (in a special way as described in the following section). It is possible for other methods to be defined to perform this authentication in the future.
如果正在使用服务器未经身份验证的配置模式，则对等方对服务器进行身份验证，服务器对隧道内的对等方进行身份验证。执行此版本EAP-FAST中定义的身份验证的唯一方法是EAP-FAST-MSCHAPv2（按照以下章节中所述的特殊方式）。将来可以定义其他方法来执行此身份验证。
EAP-FAST-MSCHAPv2 is a specific instantiation of EAP-MSCHAPv2 [EAP-MSCHAPv2] defined for use within EAP-FAST. The 256-bit inner session key (ISK) is generated from EAP-FAST-MSCHAPv2 by combining the 128-bit master keys derived according to RFC 3079 [RFC3079], with the MasterSendKey taking the first 16 octets and MasterReceiveKey taking the last 16 octets.
EAP-FAST-MSCHAPv2是为在EAP-FAST中使用而定义的EAP-MSCHAPv2[EAP-MSCHAPv2]的特定实例。256位内部会话密钥（ISK）由EAP-FAST-MSCHAPv2通过组合根据RFC 3079[RFC3079]导出的128位主密钥生成，其中MasterSendKey取前16个八位字节，MasterReceiveKey取后16个八位字节。
Implementations of this version of the EAP-FAST Server-Unauthenticated Provisioning Mode MUST support EAP-FAST-MSCHAPv2 as the inner authentication method. While other authentication methods exist, EAP-FAST-MSCHAPv2 was chosen for several reasons:
此版本的EAP-FAST服务器未经身份验证的配置模式的实现必须支持EAP-FAST-MSCHAPv2作为内部身份验证方法。虽然存在其他身份验证方法，但选择EAP-FAST-MSCHAPv2有几个原因：
o It provides the ability to slow an active attack by using a hash-based challenge-response protocol.
o 通过使用基于哈希的质询-响应协议，它提供了减缓主动攻击的能力。
o Its use of a challenge-response protocol, such as MSCHAPv2, provides some ability to detect a man-in-the-middle attack during Server-Unauthenticated Provisioning Mode.
o 它使用质询-响应协议（如MSCHAPv2），在服务器未经验证的配置模式下提供了检测中间人攻击的能力。
o It is already supported by a large deployed base.
o 它已经得到了一个大型部署基地的支持。
o It allows support for password change during the EAP-FAST provisioning modes.
o 它允许在EAP-FAST配置模式期间更改密码。
When using an anonymous Diffie-Hellman (DH) key agreement, the challenges MUST be generated as defined in Section 3.3. This forms a binding between the tunnel and the EAP-FAST-MSCHAPv2 exchanges by using keying material generated during the EAP-FAST tunnel establishment as the EAP-FAST-MSCHAPv2 challenges instead of using the challenges exchanged within the protocol itself. The exchanged challenges are zeroed upon transmission, ignored upon reception, and the challenges derived from the TLS key exchange are used in the calculations. When EAP-FAST-MSCHAPv2 is used within a tunnel established using a ciphersuite other than one that provides anonymous key agreement, the randomly generated EAP-FAST-MSCHAPv2 challenges MUST be exchanged and used.
当使用匿名Diffie-Hellman（DH）密钥协议时，必须按照第3.3节中的定义生成挑战。这通过使用EAP-FAST隧道建立期间生成的键控材料作为EAP-FAST-MSCHAPv2质询，而不是使用协议本身内交换的质询，在隧道和EAP-FAST-MSCHAPv2交换之间形成绑定。交换的质询在传输时归零，在接收时忽略，并且在计算中使用从TLS密钥交换导出的质询。当EAP-FAST-MSCHAPv2在使用密码套件而不是提供匿名密钥协议的密码套件建立的隧道内使用时，必须交换和使用随机生成的EAP-FAST-MSCHAPv2挑战。
The EAP-FAST-MSCHAPv2 exchange forces the server to provide a valid ServerChallengeResponse, which must be a function of the server challenge, peer challenge, and password as part of its response. This reduces the window of vulnerability of a man-in-the-middle attack spoofing the server by requiring the attacker to successfully break the password within the peer's challenge-response time limit.
EAP-FAST-MSCHAPv2 exchange强制服务器提供有效的ServerChallengeResponse，该响应必须是服务器质询、对等质询和密码的函数，作为其响应的一部分。通过要求攻击者在对等方的质询响应时间限制内成功破解密码，这减少了中间人攻击欺骗服务器的漏洞窗口。
Once a protected tunnel is established, typically the peer authenticates itself to the server before the server can provision the peer. If the authentication mechanism does not support mutual authentication and protection from man-in-the-middle attacks, then Server-Authenticated Provisioning Mode MUST be used. Within a server side, authenticated tunnel authentication mechanisms such as EAP-FAST-GTC (Generic Token Card) [RFC5421] MAY be used. This will enable peers using other authentication mechanisms such as password database and one-time passwords to be provisioned in-band as well.
一旦建立了受保护的隧道，通常情况下，对等方会在服务器提供对等方之前向服务器进行自身身份验证。如果身份验证机制不支持相互身份验证和防止中间人攻击，则必须使用服务器身份验证的配置模式。在服务器端内，可以使用诸如EAP-FAST-GTC（通用令牌卡）[RFC5421]之类的经过认证的隧道认证机制。这将使使用其他身份验证机制（如密码数据库和一次性密码）的对等方也能够在带内配置。
This version of the EAP-FAST provisioning mode implementation MUST support both EAP-FAST-GTC and EAP-FAST-MSCHAPv2 within the tunnel in Server-Authenticated Provisioning Mode.
此版本的EAP-FAST配置模式实施必须在隧道内以服务器身份验证配置模式支持EAP-FAST-GTC和EAP-FAST-MSCHAPv2。
It should be noted that Server-Authenticated Provisioning Mode provides significant security advantages over Server-Unauthenticated Provisioning Mode even when EAP-FAST-MSCHAPv2 is being used as the inner method. It protects the EAP-FAST-MSCHAPv2 exchanges from potential active MITM attacks by verifying the server's authenticity before executing EAP-FAST-MSCHAPv2. Server-Authenticated Provisioning Mode is the recommended provisioning mode. The EAP-FAST peer MUST use the Server- Authenticated Provisioning Mode whenever it is configured with a valid trust root for a particular server.
应该注意的是，即使将EAP-FAST-MSCHAPv2用作内部方法，服务器身份验证的配置模式也比服务器未经身份验证的配置模式具有显著的安全优势。它通过在执行EAP-FAST-MSCHAPv2之前验证服务器的真实性，保护EAP-FAST-MSCHAPv2交换机免受潜在的主动MITM攻击。建议使用服务器身份验证的配置模式。EAP-FAST对等机在为特定服务器配置有效的信任根时，必须使用服务器身份验证的配置模式。
The TLS tunnel key is calculated according to the TLS version with an extra 72 octets of key material derived from the end of the key_block. Portions of the extra 72 octets are used for the EAP-FAST provisioning exchange session key seed and as the random challenges in the EAP-FAST-MSCHAPv2 exchange.
TLS隧道密钥根据TLS版本进行计算，从密钥块末端衍生出额外的72个八位组密钥材料。额外的72个八位字节中的一部分用于EAP-FAST配置exchange会话密钥种子，并作为EAP-FAST-MSCHAPv2交换中的随机挑战。
To generate the key material, compute:
要生成关键材质，请计算：
key_block = PRF(master_secret, "key expansion", server_random + client_random);
密钥块=PRF（主密钥，“密钥扩展”，服务器随机+客户端随机）；
until enough output has been generated.
直到产生足够的输出。
For example, the key_block for TLS 1.0 [RFC2246] is partitioned as follows:
例如，TLS 1.0[RFC2246]的key_块划分如下：
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
client_write_IV[IV_size]
server_write_IV[IV_size]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
and the key_block for subsequent versions is partitioned as follows:
后续版本的key_块划分如下：
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
client_write_MAC_secret[hash_size]
server_write_MAC_secret[hash_size]
client_write_key[Key_material_length]
server_write_key[key_material_length]
session_key_seed[40]
ServerChallenge[16]
ClientChallenge[16]
In the extra key material, session_key_seed is used for the EAP-FAST Crypto-Binding TLV exchange while the ServerChallenge and ClientChallenge correspond to the authentication server's EAP-FAST-MSCHAPv2 challenge and the peer's EAP-FAST-MSCHAPv2 challenge, respectively. The ServerChallenge and ClientChallenge are only used for the EAP-FAST-MSCHAPv2 exchange when Diffie-Hellman anonymous key agreement is used in the EAP-FAST tunnel establishment.
在额外密钥材料中，会话密钥种子用于EAP-FAST加密绑定TLV交换，而ServerChallenge和ClientChallenge分别对应于身份验证服务器的EAP-FAST-MSCHAPv2质询和对等方的EAP-FAST-MSCHAPv2质询。当EAP-FAST隧道建立中使用Diffie-Hellman匿名密钥协议时，ServerChallenge和ClientChallenge仅用于EAP-FAST-MSCHAPv2交换。
The provisioning modes of EAP-FAST do not change the general EAP-FAST protocol and thus how the Peer-Id, Server-Id, and Session-Id are determined is based on the [RFC4851] techniques.
EAP-FAST的供应模式不会改变通用EAP-FAST协议，因此对等Id、服务器Id和会话Id的确定方式基于[RFC4851]技术。
Section 3.4 of [RFC4851] describes how the Peer-Id and Server-Id are determined; Section 3.5 describes how the Session-Id is generated.
[RFC4851]第3.4节描述了如何确定对等Id和服务器Id；第3.5节描述了如何生成会话Id。
After successful provisioning, network access MAY be granted or denied depending upon the server policy. For example, in the Server-Authenticated Provisioning Mode, access can be granted after the EAP server has authenticated the peer and provisioned it with a Tunnel PAC (i.e., a PAC used to mutually authenticate and establish the EAP-FAST tunnel). Additionally, peer policy MAY instruct the peer to disconnect the current provisioning connection and initiate a new EAP-FAST exchange for authentication utilizing the newly provisioned information. At the end of the Server-Unauthenticated Provisioning Mode, network access SHOULD NOT be granted as this conversation is intended for provisioning only and thus no network access is authorized. The server MAY grant access at the end of a successful Server-Authenticated provisioning exchange.
成功设置后，可能会根据服务器策略授予或拒绝网络访问。例如，在服务器认证设置模式中，可以在EAP服务器对对等方进行认证并使用隧道PAC（即，用于相互认证和建立EAP-FAST隧道的PAC）对其进行设置后授予访问权限。此外，对等策略可指示对等方断开当前供应连接并发起新的EAP-FAST交换以利用新供应的信息进行认证。在服务器未经验证的配置模式结束时，不应授予网络访问权限，因为此对话仅用于配置，因此未授权网络访问。服务器可以在成功的服务器身份验证配置交换结束时授予访问权限。
If after successful provisioning access to the network is denied, the EAP Server SHOULD conclude with an EAP Failure. The EAP server SHALL NOT grant network access or distribute any session keys to the Network Access Server (NAS) if this exchange is not intended to provide network access. Even though the provisioning mode completes
如果在成功设置网络访问后被拒绝，EAP服务器应以EAP故障结束。如果该交换机不打算提供网络访问，EAP服务器不得向网络访问服务器（NAS）授予网络访问权限或分发任何会话密钥。即使配置模式已完成
with a successful inner termination (e.g., a successful Result TLV), the server policy defines whether or not the peer gains network access. Thus, it is feasible that the server, while providing a successful Result TLV, may conclude that its authentication policy was not satisfied and terminate the conversation with an EAP Failure.
对于成功的内部终止（例如，成功的结果TLV），服务器策略定义对等方是否获得网络访问权。因此，在提供成功结果TLV的同时，服务器可以得出其认证策略不满足的结论，并在EAP失败时终止会话，这是可行的。
Denying network access after EAP-FAST Provisioning may cause disruption in scenarios such as wireless devices (e.g., in IEEE 802.11 devices, an EAP Failure may trigger a full 802.11 disassociation). While a full EAP restart can be performed, a smooth transition to the subsequent EAP-FAST authentications to enable network access can be achieved by the peer or server initiating TLS renegotiation, where the newly provisioned credentials can be used to establish a server-authenticated or mutually authenticated TLS tunnel for authentication. Either the peer or server may reject the request for TLS renegotiation. Upon completion of the TLS negotiation and subsequent authentication, normal network access policy on EAP-FAST authentication can be applied.
在EAP-FAST配置后拒绝网络访问可能会导致无线设备等场景中的中断（例如，在IEEE 802.11设备中，EAP故障可能会触发完全802.11解除关联）。虽然可以执行完整的EAP重启，但通过对等方或服务器发起TLS重新协商，可以实现到后续EAP-FAST身份验证的平滑过渡以启用网络访问，其中新配置的凭据可用于建立用于身份验证的服务器身份验证或相互身份验证的TLS隧道。对等方或服务器都可以拒绝TLS重新协商的请求。完成TLS协商和后续认证后，可以应用EAP-FAST认证的正常网络访问策略。
Multiple types of credentials MAY be provisioned within EAP-FAST. The most common credential is the Tunnel PAC that is used to establish the EAP-FAST phase 1 tunnel. In addition to the Tunnel PAC, other types of credentials and information can also be provisioned through EAP-FAST. They may include trusted root certificates, PACs for specific purposes, and user identities, to name a few. Typically, provisioning is invoked after both the peer and server authenticate each other and after a successful Crypto-Binding TLV exchange. However, depending on the information being provisioned, mutual authentication MAY not be needed.
EAP-FAST中可以提供多种类型的凭据。最常见的凭证是用于建立EAP-FAST第1阶段隧道的隧道PAC。除了隧道PAC之外，还可以通过EAP-FAST提供其他类型的凭证和信息。它们可能包括受信任的根证书、用于特定目的的PAC和用户身份，仅举几例。通常，在对等方和服务器相互验证后以及在成功的加密绑定TLV交换后调用配置。然而，根据所提供的信息，可能不需要相互认证。
At a minimum, either the peer or server must prove authenticity before credentials are provisioned to ensure that information is not freely provisioned to or by adversaries. For example, the EAP server may not need to authenticate the peer to provision it with trusted root certificates. However, the peer SHOULD authenticate the server before it can accept a trusted server root certificate.
至少，在提供凭据之前，对等方或服务器必须证明真实性，以确保信息不是免费提供给对手或由对手提供的。例如，EAP服务器可能不需要对对等方进行身份验证以向其提供受信任的根证书。但是，对等方应该先对服务器进行身份验证，然后才能接受受信任的服务器根证书。
A Protected Access Credential (PAC) is a security credential generated by the server that holds information specific to a peer. The server distributes all PAC information through the use of a PAC TLV. Different types of PAC information are identified through the PAC Type and other PAC attributes defined in this section. This document defines three types of PACs: a Tunnel PAC, a Machine Authentication PAC, and a User Authorization PAC.
受保护访问凭据（PAC）是由服务器生成的安全凭据，用于保存特定于对等方的信息。服务器通过使用PAC TLV分发所有PAC信息。不同类型的PAC信息通过本节中定义的PAC类型和其他PAC属性进行标识。本文档定义了三种类型的PAC：隧道PAC、机器身份验证PAC和用户授权PAC。
The server distributes the Tunnel PAC to the peer, which uses it in subsequent attempts to establish a secure EAP-FAST TLS tunnel with the server. The Tunnel PAC includes a secret key (PAC-Key), data that is opaque to the peer (PAC-Opaque), and other information (PAC-Info) that the peer can interpret. The opaque data is generated by the server and cryptographically protected so it cannot be modified or interpreted by the peer. The Tunnel PAC conveys the server policy of what must and can occur in the protected phase 2 tunnel. It is up to the server policy to include what is necessary in a PAC-Opaque to enforce the policy in subsequent TLS handshakes. For example, user identity, I-ID, can be included as the part of the server policy. This I-ID information limits the inner EAP methods to be carried only on the specified user identity. Other types of information can also be included, such as which EAP method(s) and which TLS ciphersuites are allowed. If the server policy is not included in a PAC-Opaque, then there is no limitation imposed by the PAC on the usage of the inner EAP methods or user identities inside the tunnel established by the use of that PAC.
服务器将隧道PAC分发给对等方，对等方在随后尝试与服务器建立安全的EAP-FAST TLS隧道时使用它。隧道PAC包括一个密钥（PAC密钥）、对对等方不透明的数据（PAC不透明）以及对等方可以解释的其他信息（PAC信息）。不透明数据由服务器生成，并受到加密保护，因此对等方无法对其进行修改或解释。隧道PAC传达服务器策略，即在受保护的第2阶段隧道中必须发生和可能发生的事情。由服务器策略在PAC中包含在后续TLS握手中强制实施策略所需的内容。例如，可以将用户标识I-ID作为服务器策略的一部分。此I-ID信息将内部EAP方法限制为仅在指定的用户标识上进行。还可以包括其他类型的信息，例如允许使用哪种EAP方法和哪种TLS密码套件。如果服务器策略未包含在PAC中，则PAC不会对内部EAP方法的使用或使用该PAC建立的隧道内的用户身份施加限制。
The Machine Authentication PAC contains information in the PAC-Opaque that identifies the machine. It is meant to be used by a machine when network access is required and no user is logged in. Typically, a server will only grant the minimal amount of access required for a machine without a user present based on the Machine Authentication PAC. The Machine Authentication PAC MAY be provisioned during the authentication of a user. It SHOULD be stored by the peer in a location that is only accessible to the machine. This type of PAC typically persists across sessions.
机器身份验证PAC包含PAC中标识机器的信息。当需要网络访问且没有用户登录时，机器将使用它。通常，服务器将根据机器身份验证PAC只授予没有用户在场的机器所需的最小访问量。机器认证PAC可以在用户的认证期间设置。对等方应将其存储在机器只能访问的位置。这种类型的PAC通常在会话之间持续存在。
The peer can use the Machine Authentication PAC as the Tunnel PAC to establish the TLS tunnel. The EAP server MAY have a policy to bypass additional inner EAP method and grant limited network access based on information in the Machine Authentication PAC. The server MAY request additional exchanges to validate machine's other authorization criteria, such as posture information etc., before granting network access.
对等方可以使用机器身份验证PAC作为隧道PAC来建立TLS隧道。EAP服务器可能有一个策略，可以绕过额外的内部EAP方法，并根据机器身份验证PAC中的信息授予有限的网络访问权限。在授予网络访问权之前，服务器可能会请求额外的交换以验证机器的其他授权标准，如姿势信息等。
The User Authorization PAC contains information in the PAC-Opaque that identifies a user and provides authorization information. This type of PAC does not contain a PAC-Key. The PAC-Opaque portion of the User Authorization PAC is presented within the protected EAP-FAST TLS tunnel to provide user information during stateless session
用户授权PAC在PAC中包含标识用户并提供授权信息的信息。此类型的PAC不包含PAC密钥。用户授权PAC的PAC不透明部分显示在受保护的EAP-FAST TLS隧道中，以在无状态会话期间提供用户信息
resume so user authentication MAY be skipped. The User Authorization PAC MAY be provisioned after user authentication. It is meant to be short lived and not persisted across logon sessions. The User Authorization PAC SHOULD only be available to the user for which it is provisioned. The User Authorization PAC SHOULD be deleted from the peer when the local authorization state of a user's session changes, such as upon the user logs out.
恢复，以便可以跳过用户身份验证。用户授权PAC可以在用户认证之后设置。这意味着它是短暂的，不会在登录会话中持久化。用户授权PAC应仅对为其设置的用户可用。当用户会话的本地授权状态发生更改时（例如用户注销时），应从对等方删除用户授权PAC。
Once the EAP-FAST phase 1 TLS tunnel is established, the peer MAY present a User Authorization PAC to the server in a PAC TLV. This is sent as TLS application data, but it MAY be included in the same message as the Finished Handshake message sent by the peer. The User Authorization PAC MUST only be sent within the protection of an encrypted tunnel to an authenticated entity. The server will decrypt the PAC and evaluate the contents. If the contents are valid and the server policy allows the session to be resumed based on this information, then the server will complete the session resumption and grant access to the peer without requiring an inner authentication method. This is called stateless session resume in EAP-FAST. In this case, the server sends the Result TLV indicating success without the Crypto-Binding TLV and the peer sends back a Result TLV indicating success. If the User Authorization PAC fails the server validation or the server policy, the server MAY either reject the request or continue with performing full user authentication within the tunnel.
一旦EAP-FAST第1阶段TLS隧道建立，对等方可以在PAC TLV中向服务器提供用户授权PAC。这是作为TLS应用程序数据发送的，但它可能包含在与对等方发送的完成握手消息相同的消息中。用户授权PAC只能在加密隧道的保护范围内发送给经过身份验证的实体。服务器将解密PAC并评估内容。如果内容有效且服务器策略允许基于此信息恢复会话，则服务器将完成会话恢复并授予对等方访问权限，而无需内部身份验证方法。这在EAP-FAST中称为无状态会话恢复。在这种情况下，服务器发送指示成功的结果TLV，而不发送加密绑定TLV，对等方发送回指示成功的结果TLV。如果用户授权PAC未通过服务器验证或服务器策略，则服务器可以拒绝请求或继续在隧道内执行完全用户身份验证。
To request provisioning of a PAC, a peer sends a PAC TLV containing a PAC attribute of PAC Type set to the appropriate value. For a Tunnel PAC, the value is '1'; for a Machine Authentication PAC, the value is '2'; and for a User Authorization PAC, the value is '3'. The request MAY be issued after the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV to ensure that the TLS tunnel's integrity is intact. Since anonymous DH ciphersuites are only allowed for provisioning a Tunnel PAC, if an anonymous ciphersuite is negotiated, the Tunnel PAC MAY be provisioned automatically by the server. The peer MUST send separate PAC TLVs for each type of PAC it wants to provision. Multiple PAC TLVs can be sent in the same packet or different packets. When requesting the Machine Authentication PAC, the peer SHOULD include an I-ID TLV containing the machine name prefixed by "host/". The EAP server will send the PACs after its internal policy has been satisfied, or it MAY ignore the request or request additional authentications if its policy dictates. If a peer receives a PAC with an unknown type, it MUST ignore it.
要请求提供PAC，对等方将发送一个包含PAC类型PAC属性的PAC TLV，该属性设置为适当的值。对于隧道PAC，值为“1”；对于机器身份验证PAC，值为“2”；对于用户授权PAC，值为“3”。该请求可在对等方确定其已成功验证EAP服务器并验证加密绑定TLV以确保TLS隧道的完整性完好无损后发出。由于匿名DH密码套件仅允许配置隧道PAC，如果协商匿名密码套件，则服务器可能会自动配置隧道PAC。对等方必须为其想要提供的每种类型的PAC发送单独的PAC TLV。可以在同一数据包或不同数据包中发送多个PAC TLV。当请求机器身份验证PAC时，对等方应包括一个I-ID TLV，其中包含前缀为“host/”的机器名。EAP服务器将在满足其内部策略后发送PACs，或者，如果其策略要求，它可能会忽略该请求或请求额外的身份验证。如果对等方收到类型未知的PAC，则必须忽略它。
A PAC-TLV containing PAC-Acknowledge attribute MUST be sent by the peer to acknowledge the receipt of the Tunnel PAC. A PAC-Acknowledge TLV MUST NOT be used by the peer to acknowledge the receipt of other types of PACs.
对等方必须发送包含PAC确认属性的PAC-TLV，以确认隧道PAC的接收。对等方不得使用PAC确认TLV来确认收到其他类型的PAC。
Please see Appendix A.1 for an example of packet exchanges to provision a Tunnel PAC.
有关提供隧道PAC的数据包交换示例，请参见附录A.1。
The PAC TLV provides support for provisioning the Protected Access Credential (PAC) defined within [RFC4851]. The PAC TLV carries the PAC and related information within PAC attribute fields. Additionally, the PAC TLV MAY be used by the peer to request provisioning of a PAC of the type specified in the PAC Type PAC attribute. The PAC TLV MUST only be used in a protected tunnel providing encryption and integrity protection. A general PAC TLV format is defined as follows:
PAC TLV支持设置[RFC4851]中定义的受保护访问凭据（PAC）。PAC TLV在PAC属性字段中携带PAC和相关信息。此外，对等方可以使用PAC TLV请求提供PAC type PAC属性中指定类型的PAC。PAC TLV只能在提供加密和完整性保护的受保护隧道中使用。通用PAC TLV格式定义如下：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 - Non-mandatory TLV 1 - Mandatory TLV
0-非强制性TLV 1-强制性TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
11 - PAC TLV
11-PAC TLV
Length
长
Two octets containing the length of the PAC attributes field in octets.
包含PAC属性字段长度（以八位字节为单位）的两个八位字节。
PAC Attributes
PAC属性
A list of PAC attributes in the TLV format.
TLV格式的PAC属性列表。
Each PAC attribute in a PAC TLV is formatted as a TLV defined as follows:
PAC TLV中的每个PAC属性都被格式化为TLV，定义如下：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
The Type field is two octets, denoting the attribute type. Allocated Types include:
类型字段是两个八位字节，表示属性类型。分配的类型包括：
1 - PAC-Key 2 - PAC-Opaque 3 - PAC-Lifetime 4 - A-ID 5 - I-ID 6 - Reserved 7 - A-ID-Info 8 - PAC-Acknowledgement 9 - PAC-Info 10 - PAC-Type
1-PAC密钥2-PAC不透明3-PAC生存期4-A-ID 5-I-ID 6-保留7-A-ID-Info 8-PAC确认9-PAC信息10-PAC类型
Length
长
Two octets containing the length of the Value field in octets.
包含值字段长度的两个八位字节（以八位字节为单位）。
Value
价值
The value of the PAC attribute.
PAC属性的值。
The PAC-Key is a secret key distributed in a PAC attribute of type PAC-Key. The PAC-Key attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC that is bound to a key such as a Tunnel PAC. The key is a randomly generated octet string, which is 32 octets in length. The generator of this key is the issuer of the credential, which is identified by the Authority Identifier (A-ID).
PAC密钥是分布在PAC密钥类型的PAC属性中的密钥。只要服务器希望发布或续订绑定到密钥（如隧道PAC）的PAC，PAC密钥属性就会包含在PAC TLV中。密钥是随机生成的八位字节字符串，长度为32个八位字节。此密钥的生成器是凭证的颁发者，凭证由授权标识符（A-ID）标识。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
1 - PAC-Key
1-PAC密钥
Length
长
2-octet length indicating a 32-octet key
2个八位字节的长度表示32个八位字节的键
Key
钥匙
The value of the PAC-Key.
PAC键的值。
The PAC-Opaque attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC or the client wishes to present a User Authorization PAC to the server.
只要服务器希望发布或续订PAC，或者客户端希望向服务器提供用户授权PAC，PAC不透明属性就会包含在PAC TLV中。
The PAC-Opaque is opaque to the peer and thus the peer MUST NOT attempt to interpret it. A peer that has been issued a PAC-Opaque by a server stores that data and presents it back to the server according to its PAC Type. The Tunnel PAC is used in the ClientHello SessionTicket extension field defined in [RFC5077]. If a peer has opaque data issued to it by multiple servers, then it stores the data issued by each server separately according to the A-ID. This requirement allows the peer to maintain and use each opaque datum as an independent PAC pairing, with a PAC-Key mapping to a PAC-Opaque identified by the A-ID. As there is a one-to-one correspondence between the PAC-Key and PAC-Opaque, the peer determines the PAC-Key and corresponding PAC-Opaque based on the A-ID provided in the EAP-FAST/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque.
PAC不透明对对等方来说是不透明的，因此对等方不得试图解释它。已由服务器发出PAC的对等方存储该数据，并根据其PAC类型将其显示回服务器。隧道PAC在[RFC5077]中定义的ClientHello SessionTicket扩展字段中使用。如果一个对等方拥有多个服务器向其发布的不透明数据，那么它将根据a-ID分别存储每个服务器发布的数据。这一要求允许对等方将每个不透明数据作为独立的PAC配对进行维护和使用，PAC密钥映射到由a-ID标识的PAC不透明。由于PAC密钥和PAC不透明之间存在一对一的对应关系，对等方根据EAP-FAST/Start消息中提供的a-ID和PAC信息中提供的a-ID确定PAC密钥和相应的PAC不透明。
The PAC-Opaque attribute format is summarized as follows:
PAC不透明属性格式总结如下：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
2 - PAC-Opaque
2-PAC不透明
Length
长
The Length filed is two octets, which contains the length of the Value field in octets.
长度字段是两个八位字节，其中包含值字段的长度（以八位字节为单位）。
Value
价值
The Value field contains the actual data for the PAC-Opaque. It is specific to the server implementation.
值字段包含PAC的实际数据。它特定于服务器实现。
The PAC-Info is comprised of a set of PAC attributes as defined in Section 4.2.1. The PAC-Info attribute MUST contain the A-ID, A-ID-Info, and PAC-Type attributes. Other attributes MAY be included in the PAC-Info to provide more information to the peer. The PAC-Info attribute MUST NOT contain the PAC-Key, PAC-Acknowledgement, PAC-Info, or PAC-Opaque attributes. The PAC-Info attribute is included within the PAC TLV whenever the server wishes to issue or renew a PAC.
PAC信息由第4.2.1节中定义的一组PAC属性组成。PAC Info属性必须包含A-ID、A-ID-Info和PAC类型属性。PAC信息中可能包含其他属性，以向对等方提供更多信息。PAC Info属性不得包含PAC密钥、PAC确认、PAC Info或PAC不透明属性。只要服务器希望发布或续订PAC，PAC TLV中就会包含PAC Info属性。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
9 - PAC-Info
9-PAC信息
Length
长
2-octet Length field containing the length of the attributes field in octets.
2-八位字节长度字段，包含八位字节中属性字段的长度。
Attributes
属性
The attributes field contains a list of PAC attributes. Each mandatory and optional field type is defined as follows:
属性字段包含PAC属性的列表。每个必填和可选字段类型的定义如下：
3 - PAC-LIFETIME
3-PAC寿命
This is a 4-octet quantity representing the expiration time of the credential expressed as the number of seconds, excluding leap seconds, after midnight UTC, January 1, 1970. This attribute MAY be provided to the peer as part of the PAC-Info.
这是一个4个八位字节的数量，表示凭证的过期时间，表示为UTC（1970年1月1日）午夜之后的秒数（不包括闰秒）。该属性可以作为PAC信息的一部分提供给对等方。
4 - A-ID
4-A-ID
The A-ID is the identity of the authority that issued the PAC. The A-ID is intended to be unique across all issuing servers to avoid namespace collisions. The A-ID is used by the peer to determine which PAC to employ. The A-ID is treated as an opaque octet string. This attribute MUST be included in the PAC-Info attribute. The A-ID MUST match the A-ID the server used to establish the tunnel. Since many existing implementations expect the A-ID to be 16 octets in length, it is RECOMMENDED that the length of an A-ID be 16 octets for maximum interoperability. One method for generating the A-ID is to use a high-quality random number generator to generate a 16-octet random number. An alternate method would be to take the hash of the public key or public key certificate belonging a server represented by the A-ID.
A-ID是颁发PAC的机构的身份。A-ID在所有发布服务器上都是唯一的，以避免名称空间冲突。对等方使用A-ID来确定使用哪个PAC。A-ID被视为不透明的八位字节字符串。此属性必须包含在PAC Info属性中。A-ID必须与用于建立隧道的服务器的A-ID匹配。由于许多现有实现预期A-ID的长度为16个八位字节，因此建议A-ID的长度为16个八位字节，以实现最大的互操作性。生成A-ID的一种方法是使用高质量随机数生成器生成16个八位组的随机数。另一种方法是获取属于由a-ID表示的服务器的公钥或公钥证书的散列。
5 - I-ID
5-I-ID
Initiator identifier (I-ID) is the peer identity associated with the credential. This identity is derived from the inner EAP exchange or from the client-side authentication during tunnel establishment if inner EAP method authentication is not used. The server employs the I-ID in the EAP-FAST phase 2 conversation to validate that the same peer identity used to execute EAP-FAST phase 1 is also used in at minimum one inner EAP method in EAP-FAST phase 2. If the server is enforcing the I-ID validation on the inner EAP method, then the I-ID MUST be included in the PAC-Info, to
启动器标识符（I-ID）是与凭据关联的对等身份。如果未使用内部EAP方法身份验证，则此标识来自内部EAP交换或隧道建立期间的客户端身份验证。服务器在EAP-FAST阶段2对话中使用I-ID，以验证用于执行EAP-FAST阶段1的相同对等身份是否也用于EAP-FAST阶段2中至少一个内部EAP方法。如果服务器在内部EAP方法上强制执行I-ID验证，则I-ID必须包含在PAC信息中，以便
enable the peer to also enforce a unique PAC for each unique user. If the I-ID is missing from the PAC-Info, it is assumed that the Tunnel PAC can be used for multiple users and the peer will not enforce the unique-Tunnel-PAC-per-user policy.
使对等方也能够为每个唯一的用户强制实施唯一的PAC。如果PAC信息中缺少I-ID，则假定隧道PAC可用于多个用户，并且对等方不会强制实施每个用户的唯一隧道PAC策略。
7 - A-ID-Info
7-A-ID-Info
Authority Identifier Information is intended to provide a user-friendly name for the A-ID. It may contain the enterprise name and server name in a human-readable format. This TLV serves as an aid to the peer to better inform the end-user about the A-ID. The name is encoded in UTF-8 [RFC3629] format. This attribute MUST be included in the PAC-Info.
授权标识符信息旨在为a-ID提供一个用户友好的名称。它可以包含人类可读格式的企业名称和服务器名称。该TLV可帮助对等方更好地通知最终用户A-ID。名称以UTF-8[RFC3629]格式编码。此属性必须包含在PAC信息中。
10 - PAC-type
10-PAC型
The PAC-Type is intended to provide the type of PAC. This attribute SHOULD be included in the PAC-Info. If the PAC-Type is not present, then it defaults to a Tunnel PAC (Type 1).
PAC类型旨在提供PAC的类型。此属性应包含在PAC信息中。如果PAC类型不存在，则默认为隧道PAC（类型1）。
The PAC-Acknowledgement is used to acknowledge the receipt of the Tunnel PAC by the peer. The peer includes the PAC-Acknowledgement TLV in a PAC-TLV sent to the server to indicate the result of the processing and storing of a newly provisioned Tunnel PAC. This TLV is only used when Tunnel PAC is provisioned.
PAC确认用于确认对等方收到隧道PAC。对等方在发送到服务器的PAC-TLV中包括PAC确认TLV，以指示处理和存储新配置的隧道PAC的结果。此TLV仅在提供隧道PAC时使用。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
8 - PAC-Acknowledgement
8-PAC确认
Length
长
The length of this field is two octets containing a value of 2.
此字段的长度为两个八位字节，值为2。
Result
后果
The resulting value MUST be one of the following:
结果值必须是以下值之一：
1 - Success 2 - Failure
1-成功2-失败
The PAC-Type TLV is a TLV intended to specify the PAC type. It is included in a PAC-TLV sent by the peer to request PAC provisioning from the server. Its format is described below:
PAC类型TLV是用于指定PAC类型的TLV。它包含在对等方发送的PAC-TLV中，以请求服务器提供PAC。其格式如下所述：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAC Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
10 - PAC-Type
10-PAC型
Length
长
2-octet Length field with a value of 2
值为2的2-八位组长度字段
PAC Type
PAC型
This 2-octet field defines the type of PAC being requested or provisioned. The following values are defined:
此2-octet字段定义所请求或提供的PAC的类型。定义了以下值：
1 - Tunnel PAC 2 - Machine Authentication PAC 3 - User Authorization PAC
1-隧道PAC 2-机器身份验证PAC 3-用户授权PAC
Server-Trusted-Root TLV facilitates the request and delivery of a trusted server root certificate. The Server-Trusted-Root TLV can be exchanged in regular EAP-FAST authentication mode or provisioning mode. The Server-Trusted-Root TLV is always marked as optional, and
服务器受信任根TLV有助于请求和传递受信任的服务器根证书。可以在常规EAP-FAST身份验证模式或配置模式下交换服务器受信任的根TLV。服务器受信任的根TLV始终标记为可选，并且
cannot be responded to with a Negative Acknowledgement (NAK) TLV. The Server-Trusted-Root TLV MUST only be sent as an inner TLV (inside the protection of the tunnel).
无法使用否定确认（NAK）TLV响应。服务器受信任的根TLV只能作为内部TLV（在隧道的保护内）发送。
After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Server-Trusted-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server. The EAP server MAY send one or more root certificates with a Public Key Cryptographic System #7 (PKCS#7) TLV inside Server-Trusted-Root TLV. The EAP server MAY also choose not to honor the request. Please see Appendix A.3 for an example of a server provisioning a server trusted root certificate.
对等方确定已成功验证EAP服务器并验证加密绑定TLV后，可发送一个或多个服务器受信任根TLV（标记为可选），以从EAP服务器请求受信任服务器根证书。EAP服务器可以在服务器受信任的根TLV内发送一个或多个具有公钥加密系统#7（PKCS#7）TLV的根证书。EAP服务器也可以选择不接受该请求。请参阅附录A.3，了解服务器设置服务器受信任根证书的示例。
The Server-Trusted-Root TLV allows the peer to send a request to the EAP server for a list of trusted roots. The server may respond with one or more root certificates in PKCS#7 [RFC2315] format.
服务器受信任根TLV允许对等方向EAP服务器发送请求，以获取受信任根列表。服务器可以使用PKCS#7[RFC2315]格式的一个或多个根证书进行响应。
If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Server-Trusted-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the Server certificate is a self-signed certificate, then the root is the self-signed certificate.
如果EAP服务器将凭证格式设置为PKCS#7-server-Certificate-Root，则服务器受信任的根TLV应包含向封装在PKCS#7 TLV中的EAP服务器颁发的证书的证书链的根。如果服务器证书是自签名证书，则根证书是自签名证书。
If the Server-Trusted-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.
如果服务器受信任的根TLV凭据格式包含对等方未知的值，则EAP对等方应忽略TLV。
The Server-Trusted-Root TLV is defined as follows:
服务器受信任根TLV的定义如下：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Non-mandatory TLV
0-非强制性TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
18 - Server-Trusted-Root TLV [RFC4851]
18-服务器受信任的根TLV[RFC4851]
Length
长
>=2 octets
>=2个八位组
Credential-Format
凭证格式
The Credential-Format field is two octets. Values include:
凭证格式字段是两个八位字节。价值包括：
1 - PKCS#7-Server-Certificate-Root
1-PKCS#7-Server-Certificate-Root
Cred TLVs
Cred TLV
This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots.
此字段的长度不定。它包含与凭证格式关联的TLV。当使用此TLV请求服务器信任根时，对等方可能会将此字段留空。
The PKCS#7 TLV is sent by the EAP server to the peer inside the Server-Trusted-Root TLV. It contains PKCS#7-wrapped [RFC2315] X.509 certificates. The format consists of a certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message as defined in [RFC2311].
PKCS#7 TLV由EAP服务器发送到服务器受信任根TLV内的对等方。它包含PKCS#7包装的[RFC2315]X.509证书。该格式由[RFC2311]中定义的仅证书PKCS#7签名数据消息中的证书或证书链组成。
The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. EAP-FAST server implementations that claim to support the dynamic provisioning defined in this document SHOULD support this TLV. EAP-FAST peer implementations MAY support this TLV.
PKCS#7 TLV始终标记为可选，不能用NAK TLV响应。声称支持本文档中定义的动态资源调配的EAP-FAST服务器实现应支持此TLV。EAP-FAST对等实现可能支持此TLV。
If the PKCS#7 TLV contains a certificate or certificate chain that is not acceptable to the peer, then the peer MUST ignore the TLV.
如果PKCS#7 TLV包含对等方不可接受的证书或证书链，则对等方必须忽略TLV。
The PKCS#7 TLV is defined as follows:
PKCS#7 TLV的定义如下：
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS #7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS #7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0-可选TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
20 - PKCS#7 TLV [RFC4851]
20-PKCS#7 TLV[RFC4851]
Length
长
The length of the PKCS #7 Data field.
PKCS#7数据字段的长度。
PKCS #7 Data
PKCS#7数据
This field contains the X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.
此字段包含仅限证书的PKCS#7 SignedData消息中的X.509证书或证书链。
This section explains the criteria to be used by the IANA for assignment of Type value in the PAC attribute, the PAC Type value in the PAC- Type TLV, and the Credential-Format value in the Server-Trusted-Root TLV. The "Specification Required" policy is used here with the meaning defined in BCP 26 [RFC5226].
本节解释IANA用于分配PAC属性中的类型值、PAC类型TLV中的PAC类型值以及服务器受信任根TLV中的凭证格式值的标准。此处使用的“所需规范”政策具有BCP 26[RFC5226]中定义的含义。
A registry of values, named "EAP-FAST PAC Attribute Types", has been created for the PAC attribute types. The initial values that populate the registry are:
已为PAC属性类型创建名为“EAP-FAST PAC属性类型”的值注册表。填充注册表的初始值为：
1 - PAC-Key 2 - PAC-Opaque 3 - PAC-Lifetime 4 - A-ID 5 - I-ID 6 - Reserved 7 - A-ID-Info 8 - PAC-Acknowledgement 9 - PAC-Info 10 - PAC-Type
1-PAC密钥2-PAC不透明3-PAC生存期4-A-ID 5-I-ID 6-保留7-A-ID-Info 8-PAC确认9-PAC信息10-PAC类型
Values from 11 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
从11到63的值由Cisco分配用于管理。为值64到255分配了“所需规格”策略。
A registry of values, named "EAP-FAST PAC Types", has been created for PAC-Type values used in the PAC-Type TLV. The initial values that populate the registry are:
已为PAC类型TLV中使用的PAC类型值创建了一个名为“EAP-FAST PAC Types”的值注册表。填充注册表的初始值为：
1 - Tunnel PAC 2 - Machine Authentication PAC 3 - User Authorization PAC
1-隧道PAC 2-机器身份验证PAC 3-用户授权PAC
Values from 4 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
Cisco为管理分配了从4到63的值。为值64到255分配了“所需规格”策略。
A registry of values, named "EAP-FAST Server-Trusted-Root Credential Format Types", has been created for Credential-Format values used in the Server-Trusted-Root TLV. The initial values that populate the registry are:
已为服务器受信任根TLV中使用的凭据格式值创建名为“EAP-FAST服务器受信任根凭据格式类型”的值注册表。填充注册表的初始值为：
1 - PKCS#7-Server-Certificate-Root
1-PKCS#7-Server-Certificate-Root
Values from 2 to 63 are allocated for management by Cisco. Values 64 to 255 are assigned with a "Specification Required" policy.
Cisco为管理分配了从2到63的值。为值64到255分配了“所需规格”策略。
The Dynamic Provisioning EAP-FAST protocol shares the same security considerations outlined in [RFC4851]. Additionally, it also has its unique security considerations described below:
动态资源调配EAP-FAST协议与[RFC4851]中概述的安全注意事项相同。此外，它还具有如下所述的独特安全注意事项：
EAP-FAST can be invoked in two different provisioning modes: Server-Authenticated Provisioning Mode and Server-Unauthenticated Provisioning Mode. Each mode provides different levels of resistance to man-in-the-middle attacks. The following list identifies some of the problems associated with a man-in-the-middle attack:
EAP-FAST可以在两种不同的配置模式下调用：服务器验证的配置模式和服务器未验证的配置模式。每种模式对中间人攻击提供不同程度的抵抗力。下表列出了与中间人攻击相关的一些问题：
o Disclosure of secret information such as keys, identities, and credentials to an attacker
o 向攻击者泄露密钥、身份和凭据等机密信息
o Spoofing of a valid server to a peer and the distribution of false credentials
o 向对等方欺骗有效服务器并分发虚假凭据
o Spoofing of a valid peer and receiving credentials generated for that peer
o 欺骗有效对等方并接收为该对等方生成的凭据
o Denial of service
o 拒绝服务
6.1.1. Server-Authenticated Provisioning Mode and Man-in-the-Middle Attacks
6.1.1. 服务器身份验证配置模式和中间人攻击
In Server-Authenticated Provisioning Mode, the TLS handshake assures protected communications with the server because the peer must have been securely pre-provisioned with the trust roots and/or other authentication information necessary to authenticate the server during the handshake. This pre-provisioning step prevents an attacker from inserting themselves as a man-in-the-middle of the communications. Unfortunately, secure pre-provisioning can be difficult to achieve in many environments.
在服务器身份验证配置模式中，TLS握手确保与服务器的通信受到保护，因为对等方必须已安全地预先配置了信任根和/或握手期间对服务器进行身份验证所需的其他身份验证信息。此预配置步骤可防止攻击者在通信过程中以人的身份插入自己。不幸的是，在许多环境中很难实现安全的预资源调配。
Cryptographic binding of inner authentication mechanisms to the TLS tunnel provides additional protection from man-in-the-middle attacks resulting from the tunneling of authentication mechanisms.
内部身份验证机制与TLS隧道的加密绑定提供了额外的保护，以防止身份验证机制隧道导致的中间人攻击。
Server-Authenticated Provisioning Mode provides a high degree of protection from man-in-the-middle attacks.
服务器身份验证的资源调配模式提供了高度的保护，防止中间人攻击。
6.1.2. Server-Unauthenticated Provisioning Mode and Man-in-the-Middle Attacks
6.1.2. 服务器未经验证的配置模式和中间人攻击
In Server-Unauthenticated Provisioning Mode, the TLS handshake does not assure protected communications with the server because either an anonymous handshake is negotiated or the peer lacks the necessary information to complete the authentication of the server. This allows an attacker to insert itself in the middle of the TLS communications.
在服务器未经身份验证的配置模式下，TLS握手不能确保与服务器的通信受到保护，因为匿名握手是协商的，或者对等方缺少完成服务器身份验证所需的信息。这允许攻击者将自己插入到TLS通信的中间。
EAP-FAST Server-Unauthenticated Provisioning Mode mitigates the man-in-the-middle attack through the following techniques:
EAP-FAST服务器未经验证的配置模式通过以下技术缓解中间人攻击：
o Binding the phase 2 authentication method to secret values derived from the phase 1 TLS exchange:
o 将阶段2身份验证方法绑定到从阶段1 TLS交换派生的秘密值：
In the case of EAP-FAST-MSCHAPv2 used with an anonymous Diffie-Hellman ciphersuite, the challenges for the EAP-FAST-MSCHAPv2 exchange are derived from the TLS handshake and are not transmitted within the EAP-FAST-MSCHAPv2 exchange. Since the man-in-the-middle attack does not know these challenges, it cannot successfully impersonate the server without cracking the EAP-FAST-MSCHAPv2 message from the peer before the peer times out.
在EAP-FAST-MSCHAPv2与匿名Diffie-Hellman密码套件一起使用的情况下，EAP-FAST-MSCHAPv2交换的挑战来自TLS握手，不会在EAP-FAST-MSCHAPv2交换中传输。由于中间人攻击不知道这些挑战，因此在对等超时之前，如果不破解来自对等方的EAP-FAST-MSCHAPv2消息，它无法成功模拟服务器。
o Cryptographic binding of secret values derived from the phase 2 authentication exchange with secret values derived from the phase 1 TLS exchange:
o 从阶段2身份验证交换派生的秘密值与从阶段1 TLS交换派生的秘密值的加密绑定：
This makes use of the cryptographic binding exchange defined within EAP-FAST to discover the presence of a man-in-the-middle attack by binding secret information obtained from the phase 2 EAP-FAST-MSCHAPv2 exchange with secret information from the phase 1 TLS exchange.
这利用了EAP-FAST中定义的加密绑定交换，通过将从第2阶段EAP-FAST-MSCHAPv2交换获得的机密信息与来自第1阶段TLS交换的机密信息绑定，来发现中间人攻击的存在。
While it would be sufficient to only support the cryptographic binding to mitigate the MITM, the binding of the EAP-FAST-MSCHAPv2 random challenge derivations to the TLS key agreement protocol enables early detection of a man-in-the-middle attack. This guards against adversaries who may otherwise relay the inner EAP authentication messages between the true peer and server, and it enforces that the adversary successfully respond with a valid challenge response.
虽然仅支持加密绑定就足以缓解MITM，但将EAP-FAST-MSCHAPv2随机质询派生绑定到TLS密钥协议协议能够早期检测中间人攻击。这可以防止对手以其他方式在真正的对等方和服务器之间中继内部EAP身份验证消息，并强制对手使用有效的质询响应成功响应。
The ciphersuite used to establish phase 1 of the Server-Unauthenticated Provisioning Mode MUST be one in which both the peer and server provide contribution to the derived TLS master key. Ciphersuites that use RSA key transport do not meet this requirement. The authenticated and anonymous ephemeral Diffie-Hellman ciphersuites provide this type of key agreement.
用于建立服务器未经验证的配置模式的第1阶段的密码套件必须是对等方和服务器都为派生的TLS主密钥提供贡献的密码套件。使用RSA密钥传输的密码套件不符合此要求。经过身份验证和匿名的临时Diffie-Hellman密码套件提供了这种类型的密钥协议。
This document specifies EAP-FAST-MSCHAPv2 as the inner authentication exchange; however, it is possible that other inner authentication mechanisms to authenticate the tunnel may be developed in the future. Since the strength of the man-in-the-middle protection is directly dependent on the strength of the inner method, it is RECOMMENDED that any inner method used provide at least as much resistance to attack as EAP-FAST-MSCHAPv2. Cleartext passwords MUST NOT be used in Server-Unauthenticated Provisioning Mode. Note that an active man-in-the-middle attack may observe phase 2 authentication method exchange until the point that the peer determines that authentication mechanism fails or is aborted. This allows for the disclosure of sensitive information such as identity or authentication protocol exchanges to the man-in-the-middle attack.
本文件指定EAP-FAST-MSCHAPv2为内部认证交换机；然而，将来可能会开发用于认证隧道的其他内部认证机制。由于中间人保护的强度直接取决于内部方法的强度，因此建议使用的任何内部方法提供至少与EAP-FAST-MSCHAPv2相同的抗攻击能力。明文密码不得在服务器未经验证的配置模式下使用。请注意，主动中间人攻击可能会观察第2阶段身份验证方法交换，直到对等方确定身份验证机制失败或中止。这允许向中间人攻击泄露敏感信息，如身份或身份验证协议交换。
It is often the case that phase 2 authentication mechanisms are based on password credentials. These exchanges may be vulnerable to both online and off-line dictionary attacks. The two provisioning modes provide various degrees of protection from these attacks.
通常情况下，第2阶段身份验证机制基于密码凭据。这些交换可能容易受到在线和离线字典攻击。这两种配置模式提供了不同程度的保护，以抵御这些攻击。
In online dictionary attacks, the attacker attempts to discover the password by repeated attempts at authentication using a guessed password. Neither mode prevents this type of attack by itself. Implementations should provide controls that limit how often an attacker can execute authentication attempts.
在在线字典攻击中，攻击者试图通过使用猜测的密码反复尝试身份验证来发现密码。这两种模式都不能单独阻止这种类型的攻击。实现应提供控制，以限制攻击者执行身份验证尝试的频率。
In off-line dictionary attacks, the attacker captures information that can be processed off-line to recover the password. Server-Authenticated Provisioning Mode provides effecting mitigation because the peer will not engage in phase 2 authentication without first authenticating the server during phase 1. Server-Unauthenticated Provisioning Mode is vulnerable to this type of attack. If, during phase 2 authentication, a peer receives no response or an invalid response from the server, then there is a possibility there is a man-in-the-middle attack in progress. Implementations SHOULD log these events and, if possible, provide warnings to the user. Implementations are also encouraged to provide controls, which are appropriate to their environment, that limit how and where Server-Unauthenticated Provisioning Mode can be performed. For example, an implementation may limit this mode to be used only on certain interfaces or require user intervention before allowing this mode if provisioning has succeeded in the past.
在脱机字典攻击中，攻击者捕获可以脱机处理以恢复密码的信息。服务器身份验证的配置模式提供了有效的缓解措施，因为在阶段1期间，如果不首先对服务器进行身份验证，对等方将不会参与阶段2身份验证。服务器未经身份验证的配置模式容易受到此类攻击。如果在第2阶段身份验证期间，对等方未收到来自服务器的响应或无效响应，则可能存在中间人攻击。实现应该记录这些事件，并在可能的情况下向用户提供警告。还鼓励实现提供适合其环境的控件，以限制如何以及在何处执行服务器未经验证的资源调配模式。例如，实现可能会将此模式限制为仅在某些接口上使用，或者在允许此模式之前需要用户干预（如果在过去成功设置）。
Another mitigation technique that should not be overlooked is the choice of good passwords that have sufficient complexity and length and a password-changing policy that requires regular password changes.
另一个不应忽视的缓解技术是选择具有足够复杂性和长度的好密码，以及需要定期更改密码的密码更改策略。
Since Server-Authenticated Provisioning Mode provides much better protection from attacks than Server-Unauthenticated Provisioning Mode, Server-Authenticated Provisioning Mode SHOULD be used whenever possible. The Server-Unauthenticated Provisioning Mode provides a viable option as there may be deployments that can physically confine devices during the provisioning or are willing to accept the risk of an active dictionary attack. Further, it is the only option that enables zero-touch provisioning and facilitates simpler deployments requiring little to no peer configuration. The peer MAY choose to use alternative secure out-of-band mechanisms for PAC provisioning that afford better security than the Server Unauthenticated Provisioning Mode.
由于服务器身份验证的配置模式比服务器未经身份验证的配置模式提供更好的攻击防护，因此应尽可能使用服务器身份验证的配置模式。服务器未经验证的资源调配模式提供了一个可行的选项，因为可能存在在资源调配期间物理限制设备的部署，或者愿意接受活动字典攻击的风险。此外，它是实现零接触资源调配和简化部署的唯一选项，几乎不需要对等配置。对等方可以选择使用替代的安全带外机制进行PAC资源调配，该机制提供了比服务器未经验证的资源调配模式更好的安全性。
To encourage interoperability implementations of EAP-FAST, anonymous provisioning modes MUST support the 2048-bit group "14" in [RFC3526].
为了鼓励EAP-FAST的互操作性实施，匿名供应模式必须支持[RFC3526]中的2048位组“14”。
The basic usage of the Tunnel PAC is to establish the TLS tunnel. In this operation, it does not have to provide user authentication as user authentication is expected to be carried out in phase 2 of EAP-FAST. The EAP-FAST Tunnel PAC MAY contain information about the
隧道PAC的基本用途是建立TLS隧道。在此操作中，它不必提供用户身份验证，因为用户身份验证预计将在EAP-FAST的第2阶段执行。EAP-FAST隧道PAC可能包含以下信息：
identity of a peer to prevent a particular Tunnel PAC from being used to establish a tunnel that can perform phase 2 authentication other peers. While it is possible for the server to accept the Tunnel PAC as authentication for the peer, many current implementations do not do this. The ability to use PAC to authenticate peers and provide authorizations will be the subject of a future document. [RFC5077] gives an example PAC-Opaque format in the Recommended Ticket Construction section.
对等方的标识，以防止特定的隧道PAC被用于建立可在其他对等方执行阶段2身份验证的隧道。虽然服务器可以接受隧道PAC作为对等方的身份验证，但当前的许多实现都没有这样做。使用PAC对对等方进行身份验证和提供授权的能力将是未来文档的主题。[RFC5077]给出了推荐票证构造部分中的PAC不透明格式示例。
In general, the Machine Authorization PAC is expected to provide the minimum access required by a machine without a user. This will typically be a subset of the privilege a registered user has. The server provisioning the PAC should include information necessary to validate it at a later point in time. This would include expiration information. The Machine Authentication PAC includes a key so it can be used as a Tunnel PAC. The PAC-Key MUST be kept secret by the peer.
通常，机器授权PAC应提供无用户机器所需的最低访问权限。这通常是注册用户拥有的特权的子集。提供PAC的服务器应包括在以后某个时间点对其进行验证所需的信息。这将包括到期信息。机器身份验证PAC包含一个密钥，因此它可以用作隧道PAC。对等方必须对PAC密钥保密。
The User Authorization PAC provides the privilege associated with a user. The server provisioning the PAC should include the information necessary to validate it at a later point in time. This includes expiration and other information associated with the PAC. The User Authorization PAC is a bearer credential such that it does not have a key that used to authenticate its ownership. For this reason, this type of PAC MUST NOT be sent in the clear. For additional protection, the PAC MAY be bound to a Tunnel PAC used to establish the TLS tunnel. On the peer, the User Authorization PAC SHOULD only be accessible by the user for which it is provisioned.
用户授权PAC提供与用户关联的权限。提供PAC的服务器应包括在以后某个时间点对其进行验证所需的信息。这包括过期和与PAC相关的其他信息。用户授权PAC是一个承载凭证，因此它没有用于验证其所有权的密钥。因此，此类PAC不得以明文形式发送。为获得额外保护，PAC可绑定到用于建立TLS隧道的隧道PAC。在对等机上，用户授权PAC应该只能由为其提供授权的用户访问。
The main goal of EAP-FAST is to protect the authentication stream over the media link. However, host security is still an issue. Some care should be taken to protect the PAC on both the peer and server. The peer must securely store both the PAC-Key and PAC-Opaque, while the server must secure storage of its security association context used to consume the PAC-Opaque. Additionally, if alternate provisioning is employed, the transportation mechanism used to distribute the PAC must also be secured.
EAP-FAST的主要目标是保护媒体链路上的认证流。但是，主机安全仍然是一个问题。应注意保护对等机和服务器上的PAC。对等方必须安全地存储PAC密钥和PAC不透明，而服务器必须安全地存储用于使用PAC不透明的安全关联上下文。此外，如果采用备用供应，用于分发PAC的传输机制也必须得到保护。
Most of the attacks described here would require some level of effort to execute: conceivably greater than their value. The main focus therefore, should be to ensure that proper protections are used on both the peer and server. There are a number of potential attacks that can be considered against secure key storage such as:
这里描述的大多数攻击都需要一定程度的努力才能执行：可以想象，这比它们的价值还要大。因此，主要的重点应该是确保在对等机和服务器上使用适当的保护。可以考虑针对安全密钥存储的一些潜在攻击，例如：
o Weak Passphrases
o 弱密码短语
On the peer side, keys are usually protected by a passphrase. In some environments, this passphrase may be associated with the user's password. In either case, if an attacker can obtain the encrypted key for a range of users, he may be able to successfully attack a weak passphrase. The tools are already in place today to enable an attacker to easily attack all users in an enterprise environment through the use of email viruses and other techniques.
在对等端，密钥通常由密码短语保护。在某些环境中，此密码短语可能与用户的密码相关联。在这两种情况下，如果攻击者能够为一系列用户获取加密密钥，则他可能能够成功攻击弱密码短语。这些工具现在已经到位，使攻击者能够通过使用电子邮件病毒和其他技术轻松攻击企业环境中的所有用户。
o Key Finding Attacks
o 密钥查找攻击
Key finding attacks are usually mentioned in reference to web servers where the private Secure Socket Layer (SSL) key may be stored securely, but at some point, it must be decrypted and stored in system memory. An attacker with access to system memory can actually find the key by identifying their mathematical properties. To date, this attack appears to be purely theoretical and primarily acts to argue strongly for secure access controls on the server itself to prevent such unauthorized code from executing.
密钥查找攻击通常指的是web服务器，其中可以安全地存储私有安全套接字层（SSL）密钥，但在某些情况下，它必须解密并存储在系统内存中。具有系统内存访问权限的攻击者可以通过识别密钥的数学属性来找到密钥。到目前为止，这种攻击似乎纯粹是理论上的，主要是为了强烈主张对服务器本身进行安全访问控制，以防止此类未经授权的代码执行。
o Key duplication, Key substitution, Key modification
o 密钥复制、密钥替换、密钥修改
Once keys are accessible to an attacker on either the peer or server, they fall under three forms of attack: key duplication, key substitution, and key modification. The first option would be the most common, allowing the attacker to masquerade as the user in question. The second option could have some use if an attacker could implement it on the server. Alternatively, an attacker could use one of the latter two attacks on either the peer or server to force a PAC re-key, and take advantage of the potential MITM/dictionary attack vulnerability of the EAP-FAST Server-Unauthenticated Provisioning Mode.
一旦对等方或服务器上的攻击者可以访问密钥，它们就会受到三种形式的攻击：密钥复制、密钥替换和密钥修改。第一个选项是最常见的，允许攻击者伪装成有问题的用户。如果攻击者可以在服务器上实现第二个选项，那么第二个选项可能会有一些用处。或者，攻击者可以在对等方或服务器上使用后两种攻击之一来强制PAC重新密钥，并利用EAP-FAST服务器未经验证的配置模式的潜在MITM/字典攻击漏洞。
Another consideration is the use of secure mechanisms afforded by the particular device. For instance, some laptops enable secure key storage through a special chip. It would be worthwhile for implementations to explore the use of such a mechanism.
另一个考虑因素是使用特定设备提供的安全机制。例如，一些笔记本电脑通过一个特殊的芯片实现安全的密钥存储。对于实现来说，探索这种机制的使用是值得的。
The [RFC3748] security claims for EAP-FAST are given in Section 7.8 of [RFC4851]. When using anonymous provisioning mode, there is a greater risk of off-line dictionary attack since it is possible for a man-in-the-middle attack to capture the beginning of the inner EAP-FAST-MSCHAPv2 conversation. However, as noted previously, it is possible to detect the man-in-the-middle attack.
EAP-FAST的[RFC3748]安全声明见[RFC4851]第7.8节。使用匿名设置模式时，离线字典攻击的风险更大，因为中间人攻击可能捕获内部EAP-FAST-MSCHAPv2对话的开始。然而，如前所述，可以检测到中间人的攻击。
The EAP-FAST design and protocol specification is based on the ideas and contributions from Pad Jakkahalli, Mark Krischer, Doug Smith, Ilan Frenkel, Max Pritikin, Jan Vilhuber, and Jeremy Steiglitz. The authors would also like to thank Jouni Malinen, Pasi Eronen, Jari Arkko, Chris Newman, Ran Canetti, and Vijay Gurbani for reviewing this document.
EAP-FAST设计和协议规范基于Pad Jakkahalli、Mark Krischer、Doug Smith、Ilan Frenkel、Max Pritikin、Jan Vilhuber和Jeremy Steiglitz的想法和贡献。作者还要感谢Jouni Malinen、Pasi Eronen、Jari Arkko、Chris Newman、Ran Canetti和Vijay Gurbani对本文件的审阅。
[EAP-MSCHAPv2] Microsoft Corporation, "MS-CHAP: Extensible Authentication Protocol Method for Microsoft Challenge Handshake Authentication Protocol (CHAP) Specification", January 2009. http://msdn2.microsoft.com/ en-us/library/cc224612.aspx
[EAP-MSCHAPv2]微软公司，“MS-CHAP：微软挑战握手认证协议（CHAP）规范的可扩展认证协议方法”，2009年1月。http://msdn2.microsoft.com/ en us/library/cc224612.aspx
[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月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.
[RFC2311]Dusse，S.，Hoffman，P.，Ramsdell，B.，Lundblade，L.，和L.Repka，“S/MIME版本2消息规范”，RFC 23111998年3月。
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998.
[RFC2315]Kaliski，B.，“PKCS#7：加密消息语法版本1.5”，RFC 2315，1998年3月。
[RFC3079] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)", RFC 3079, March 2001.
[RFC3079]Zorn，G.“导出用于Microsoft点对点加密（MPPE）的密钥”，RFC 3079，2001年3月。
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003.
[RFC3526]Kivinen，T.和M.Kojo，“互联网密钥交换（IKE）的更多模指数（MODP）Diffie-Hellman群”，RFC 3526，2003年5月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, May 2007.
[RFC4851]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展认证协议方法（EAP-FAST）的灵活认证”，RFC 4851，2007年5月。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, January 2008.
[RFC5077]Salowey，J.，Zhou，H.，Eronen，P.，和H.Tschofenig，“无服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，2008年1月。
[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月。
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5421, March 2009.
[RFC5421]Cam Winget，N.和H.Zhou，“通过安全隧道可扩展身份验证协议（EAP-FAST）的灵活身份验证中的基本密码交换”，RFC 54212009年3月。
[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月。
The following exchanges show anonymous DH with a successful EAP-FAST-MSCHAPv2 exchange within phase 2 to provision a Tunnel PAC. The conversation will appear as follows:
以下交换显示匿名DH在第2阶段内成功交换EAP-FAST-MSCHAPv2，以提供隧道PAC。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST,
(S=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST,
(S=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without PAC-Opaque in SessionTicket extension)->
EAP响应/EAP-FAST（在SessionTicket扩展中没有PAC不透明的TLS客户端Hello）->
<- EAP-Request/EAP-FAST (TLS Server Hello, TLS Server Key Exchange TLS Server Hello Done)
<-EAP请求/EAP-FAST（TLS服务器你好，TLS服务器密钥交换TLS服务器你好完成）
EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec TLS Finished) ->
EAP响应/EAP-FAST（TLS客户端密钥交换TLS更改密码规范TLS已完成）->
<- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
<-EAP请求/EAP-FAST（TLS更改\u密码\u规范，TLS完成，EAP有效负载TLV（EAP请求/标识））
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV搭载在TLS上，作为应用程序数据完成，并受TLS隧道保护
EAP Payload TLV
(EAP-Response/Identity) ->
EAP Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAP有效载荷TLV（EAP请求/EAP-FAST-MSCHAPv2（挑战））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAP有效负载TLV（EAP响应/EAP-FAST-MSCHAPv2（响应））->
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2) (Success)) EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success)) -> <- Intermediate Result TLV(Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC)
<-EAP有效负载TLV（EAP请求/EAP-FAST-MSCHAPv2）（成功））EAP有效负载TLV（EAP响应/EAP-FAST-MSCHAPv2（成功））->-中间结果TLV（成功）加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC）
Intermediate Result TLV (Success) Crypto-Binding-TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC) PAC-TLV (Type=1) <- Result TLV (Success) PAC TLV
中间结果TLV（成功）加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC）PAC-TLV（类型=1）<-结果TLV（成功）PAC-TLV
Result TLV (Success) PAC Acknowledgment ->
结果TLV（成功）PAC确认->
TLS channel torn down (messages sent in cleartext)
TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
The following exchanges show a failed EAP-FAST-MSCHAPv2 exchange within phase 2, where the peer failed to authenticate the server. The conversation will appear as follows:
以下交换显示了第2阶段中失败的EAP-FAST-MSCHAPv2交换，其中对等方未能对服务器进行身份验证。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(s=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without SessionTicket extension)->
EAP响应/EAP-FAST（不带SessionTicket扩展的TLS客户端Hello）->
<- EAP-Request/EAP-FAST (TLS Server Hello TLS Server Key Exchange TLS Server Hello Done) EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec, TLS Finished) ->
<-EAP请求/EAP-FAST（TLS服务器Hello TLS服务器密钥交换TLS服务器Hello Done）EAP响应/EAP-FAST（TLS客户端密钥交换TLS更改密码规范，TLS完成）->
<- EAP-Request/EAP-FAST ( TLS change_cipher_spec, TLS finished, EAP-Payload-TLV (EAP-Request/Identity))
<-EAP请求/EAP-FAST（TLS更改\u密码\u规范，TLS完成，EAP有效负载TLV（EAP请求/标识））
// TLS channel established (Subsequent messages sent within the TLS channel, encapsulated within EAP-FAST)
//建立TLS通道（在TLS通道内发送的后续消息，封装在EAP-FAST内）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV搭载在TLS上，作为应用程序数据完成，并受TLS隧道保护
EAP Payload TLV (EAP-Response/Identity)->
EAP有效负载TLV（EAP响应/标识）->
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAP有效载荷TLV（EAP请求/EAP-FAST-MSCHAPv2（挑战））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAP有效负载TLV（EAP响应/EAP-FAST-MSCHAPv2（响应））->
<- EAP Payload TLV (EAP-Request EAP-FAST-MSCHAPv2 (Success))
<-EAP有效负载TLV（EAP请求EAP-FAST-MSCHAPv2（成功））
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Failure)) ->
// peer failed to verify server MSCHAPv2 response
EAP Payload TLV
(EAP-Response/EAP-FAST-MSCHAPv2
(Failure)) ->
<- Result TLV (Failure)
<-结果TLV（故障）
Result TLV (Failure) -> TLS channel torn down (messages sent in cleartext)
结果TLV（失败）->TLS通道已断开（以明文发送的消息）
<- EAP-Failure
<-EAP故障
A.3. Example 3: Provisioning an Authentication Server's Trusted Root Certificate
A.3. 示例3：设置身份验证服务器的受信任根证书
The following exchanges show a successful provisioning of a server trusted root certificate using anonymous DH and EAP-FAST-MSCHAPv2 exchange within phase 2. The conversation will appear as follows:
以下交换显示在第2阶段中使用匿名DH和EAP-FAST-MSCHAPv2交换成功设置服务器受信任根证书。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Requese/EAP-FAST
(s=1, A-ID)
EAP-Response/EAP-FAST (TLS Client Hello without SessionTicket extension)-> <- EAP-Request/EAP-FAST (TLS Server Hello, (TLS Server Key Exchange TLS Server Hello Done)
EAP响应/EAP-FAST（不带SessionTicket扩展的TLS客户端Hello）-><-EAP请求/EAP-FAST（TLS服务器Hello，（TLS服务器密钥交换TLS服务器Hello完成）
EAP-Response/EAP-FAST (TLS Client Key Exchange TLS Change Cipher Spec, TLS Finished) ->
EAP响应/EAP-FAST（TLS客户端密钥交换TLS更改密码规范，TLS完成）->
<- EAP-Request/EAP-FAST (TLS Change Cipher Spec TLS Finished) (EAP-Payload-TLV( EAP-Request/Identity))
<-EAP请求/EAP-FAST（TLS更改密码规范TLS完成）（EAP有效负载TLV（EAP请求/标识））
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked on the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV搭载在TLS上，作为应用程序数据完成，并受TLS隧道保护
EAP-Payload TLV
(EAP-Response/Identity) ->
EAP-Payload TLV
(EAP-Response/Identity) ->
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (Challenge))
<-EAP有效载荷TLV（EAP请求/EAP-FAST-MSCHAPv2（挑战））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Response)) ->
EAP有效负载TLV（EAP响应/EAP-FAST-MSCHAPv2（响应））->
<- EAP Payload TLV (EAP-Request/EAP-FAST-MSCHAPv2 (success))
<-EAP有效负载TLV（EAP请求/EAP-FAST-MSCHAPv2（成功））
EAP Payload TLV (EAP-Response/EAP-FAST-MSCHAPv2 (Success) ->
EAP有效负载TLV（EAP响应/EAP-FAST-MSCHAPv2（成功）->
<- Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1, EAP-FAST Version=1, Nonce, CompoundMAC),
<-中间结果TLV（成功）加密绑定TLV（版本=1，EAP-FAST版本=1，Nonce，CompoundMAC），
Intermediate Result TLV(Success) Crypto-Binding TLV (Version=1 EAP-FAST Version=1, Nonce, CompoundMAC) Server-Trusted-Root TLV (Type = PKCS#7) -> <- Result TLV (Success) Server-Trusted-Root TLV (PKCS#7 TLV)
中间结果TLV（成功）加密绑定TLV（版本=1 EAP-FAST版本=1，Nonce，CompoundMAC）服务器受信任根TLV（类型=PKCS#7）-><-结果TLV（成功）服务器受信任根TLV（PKCS#7 TLV）
Result TLV (Success) ->
结果TLV（成功）->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
Authors' Addresses
作者地址
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
美国加利福尼亚州圣何塞市思科路3625号南希·坎·威吉思科系统公司，邮编95134
EMail: ncamwing@cisco.com
EMail: ncamwing@cisco.com
David McGrew Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
美国加利福尼亚州圣何塞市思科路3625号，邮编95134
EMail: mcgrew@cisco.com
EMail: mcgrew@cisco.com
Joseph Salowey Cisco Systems 2901 3rd Ave Seattle, WA 98121 US
美国华盛顿州西雅图第三大道2901号Joseph Salowey Cisco Systems 98121
EMail: jsalowey@cisco.com
EMail: jsalowey@cisco.com
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
郝州思科系统4125美国俄亥俄州汉兰达大道里奇菲尔德44286号
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com