Network Working Group N. Cam-Winget
Request for Comments: 5421 H. Zhou
Category: Informational Cisco Systems
March 2009
Network Working Group N. Cam-Winget
Request for Comments: 5421 H. Zhou
Category: Informational Cisco Systems
March 2009
Basic Password Exchange within the 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-GTC reuses the EAP type code assigned to EAP-GTC (6). The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748.
EAP方法EAP-FAST-GTC重用分配给EAP-GTC的EAP类型代码（6）。重复使用先前分配的EAP类型代码与RFC 3748中定义的EAP方法协商不兼容。
Since EAP-GTC does not support method-specific version negotiation, the use of EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during authentication. This behavior may cause problems in implementations where the use of another vendor's EAP-GTC is required. 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-GTC不支持特定于方法的版本协商，因此在身份验证期间在EAP-FAST隧道内使用时暗示使用EAP-FAST-GTC。在需要使用其他供应商的EAP-GTC的实施中，此行为可能会导致问题。由于这种支持需要在隧道内执行方法的特殊情况，因此在隧道方法内外使用相同方法代码的实现也会变得复杂。如果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. Within this tunnel, a basic password exchange, based on the Generic Token Card method (EAP-GTC), may be executed to authenticate the peer.
通过安全隧道可扩展认证协议（EAP-FAST）的灵活认证方法通过使用传输层安全性（TLS）建立相互认证的隧道，实现对等方和服务器之间的安全通信。在该隧道内，可以执行基于通用令牌卡方法（EAP-GTC）的基本密码交换来认证对等方。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Specification Requirements .................................3
2. EAP-FAST GTC Authentication .....................................3
3. Security Considerations .........................................7
3.1. Security Claims ............................................7
4. IANA Considerations .............................................8
5. Acknowledgments .................................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
1. Introduction ....................................................2
1.1. Specification Requirements .................................3
2. EAP-FAST GTC Authentication .....................................3
3. Security Considerations .........................................7
3.1. Security Claims ............................................7
4. IANA Considerations .............................................8
5. Acknowledgments .................................................9
6. References ......................................................9
6.1. Normative References .......................................9
6.2. Informative References .....................................9
EAP-FAST [RFC4851] is an EAP method that can be used to mutually authenticate a peer and server. This document describes the EAP-FAST inner EAP method, EAP-FAST-GTC, which is used to authenticate the peer through a basic password exchange. EAP-FAST-GTC was developed to support using cleartext passwords to authenticate to legacy user databases, to facilitate password change, and to support one time password features such as new pin mode. Message exchanges, including user credentials, are cleartext strings transferred within the encrypted TLS tunnel and thus are considered secure. For historical reasons, EAP-FAST-GTC uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. Note that EAP-FAST-GTC payloads used in EAP-FAST require specific formatting and therefore will not necessarily be
EAP-FAST[RFC4851]是一种EAP方法，可用于对对等方和服务器进行相互身份验证。本文档描述了EAP-FAST内部EAP方法EAP-FAST-GTC，该方法用于通过基本密码交换对对等方进行身份验证。EAP-FAST-GTC的开发目的是支持使用明文密码对遗留用户数据库进行身份验证，方便密码更改，并支持一次性密码功能，如新pin模式。消息交换，包括用户凭证，是在加密的TLS隧道内传输的明文字符串，因此被认为是安全的。出于历史原因，EAP-FAST-GTC使用EAP类型6，最初分配给EAP-GTC[RFC3748]。请注意，EAP-FAST中使用的EAP-FAST-GTC有效载荷需要特定的格式，因此不一定是
compatible with EAP-GTC mechanisms used outside of EAP-FAST. To avoid interference between these two methods, EAP-FAST-GTC MUST NOT be used outside an EAP-FAST tunnel, and EAP-GTC MUST NOT be used inside an EAP-FAST tunnel. All EAP-FAST-GTC packets sent within the TLS tunnel must be encapsulated in EAP Payload TLVs, described in [RFC4851].
与EAP-FAST外部使用的EAP-GTC机制兼容。为避免这两种方法之间的干扰，EAP-FAST-GTC不得在EAP-FAST隧道外使用，且EAP-GTC不得在EAP-FAST隧道内使用。在TLS隧道内发送的所有EAP-FAST-GTC数据包必须封装在EAP有效负载TLV中，如[RFC4851]所述。
It is assumed that a reader of this document is familiar with EAP-FAST [RFC4851].
假设本文件的读者熟悉EAP-FAST[RFC4851]。
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]中所述进行解释。
All EAP-FAST-GTC packets inside EAP-FAST other than the empty acknowledgment packet MUST follow the "LABEL=Value" format. All Labels are in ASCII text and SHALL NOT contain the space character. Currently, three Labels are defined:
EAP-FAST内部的所有EAP-FAST-GTC数据包（空确认数据包除外）必须遵循“标签=值”格式。所有标签均为ASCII文本，不得包含空格字符。目前，定义了三个标签：
o "CHALLENGE", the server request packet MUST be in the form of "CHALLENGE=Value", where Value is the server challenge, such as "please enter your password".
o “质询”，服务器请求数据包必须采用“质询=值”的形式，其中值为服务器质询，如“请输入密码”。
o "RESPONSE", the peer response packet MUST be in the form of "RESPONSE=Value", where Value is the peer response.
o “响应”，对等响应数据包必须采用“响应=值”的形式，其中值是对等响应。
o "E", the server failure packet MUST be in the form of "E=Value", where Value is the error message generated by the server.
o “E”，服务器故障数据包必须采用“E=Value”的形式，其中Value是服务器生成的错误消息。
If the peer or the server receives an EAP-FAST-GTC request or response that is not in the format specified above, it SHOULD fail the authentication by sending a Result TLV with a failure.
如果对等方或服务器收到的EAP-FAST-GTC请求或响应不是上述指定的格式，则应通过发送结果TLV使认证失败。
After the TLS encryption tunnel is established and EAP-FAST Authentication phase 2 starts, the EAP server sends an EAP-FAST-GTC Request, which contains a server challenge. The server challenge is a displayable message for use by the peer to prompt the user.
TLS加密隧道建立且EAP-FAST身份验证阶段2开始后，EAP服务器发送一个包含服务器质询的EAP-FAST-GTC请求。服务器质询是一条可显示的消息，供对等方用于提示用户。
A peer MAY prompt the user for the user credentials, or decide to use the user credentials gained through some other means without prompting the user. The peer sends the user credentials back in the EAP-FAST-GTC Response using the following format:
对等方可以提示用户输入用户凭据，或者决定在不提示用户的情况下使用通过某些其他方式获得的用户凭据。对等方使用以下格式在EAP-FAST-GTC响应中发回用户凭据：
"RESPONSE=user@example.com\0secret"
“答复=user@example.com\0秘密”
where "user@example.com" is the actual username and "secret" is the actual password. The NULL character "\0" is used to separate the username and password.
“在哪里”user@example.com“是实际用户名，“secret”是实际密码。空字符“\0”用于分隔用户名和密码。
The username and password are included in a single message in the first response packet as an optimization by eliminating the inner method EAP-Identity exchange to save an extra round trip.
作为优化，用户名和密码包含在第一个响应数据包的单个消息中，通过消除内部方法EAP身份交换来节省额外的往返。
Once the EAP-FAST server receives the user credentials, it SHOULD first validate the user identity with the Initiator ID (I-ID) [RFC5422] in the PAC-Opaque (Protected Access Credential) and if it matches, it will continue to authenticate the user with internal or external user databases.
EAP-FAST服务器收到用户凭据后，应首先使用PAC不透明（受保护访问凭据）中的启动器ID（I-ID）[RFC5422]验证用户身份，如果匹配，则将继续使用内部或外部用户数据库验证用户身份。
Additional exchanges MAY occur between the EAP-FAST server and peer to facilitate various user authentications. The EAP-FAST server might send additional challenges to prompt the peer for additional information, such as a request for the next token or a new pin in the one time password case, or a server failure packet to indicate an error. The peer displays the prompt to the user again and sends back the needed information in an EAP-FAST-GTC Response. The exchange ends when a Result TLV is received.
EAP-FAST服务器和对等方之间可能会发生额外的交换，以促进各种用户身份验证。EAP-FAST服务器可能会发送额外的质询以提示对等方提供额外的信息，例如在一次性密码情况下请求下一个令牌或新pin，或者发送服务器故障数据包以指示错误。对等方再次向用户显示提示，并在EAP-FAST-GTC响应中发回所需信息。当收到结果TLV时，交换结束。
An EAP-FAST-GTC server implementation within EAP-FAST uses the following format to indicate an error if an authentication fails:
如果认证失败，EAP-FAST中的EAP-FAST-GTC服务器实现将使用以下格式指示错误：
"E=eeeeeeeeee R=r M=<msg>"
"E=eeeeeeeeee R=r M=<msg>"
where:
哪里：
The "eeeeeeeeee" is the ASCII representation of a decimal error code corresponding to one of those listed below, though peer implementations SHOULD deal with codes not on this list gracefully.
“EEEE”是十进制错误代码的ASCII表示形式，对应于下面列出的其中一个错误代码，尽管对等实现应该优雅地处理不在此列表中的代码。
The error code need not be 10 digits long.
错误代码不必是10位数。
Below is a complete list of predefined error codes:
以下是预定义错误代码的完整列表：
o 646 ERROR_RESTRICTED_LOGON_HOURS
o 646错误\u限制\u登录\u小时
Indicates that access is attempted outside the allowed hours. Peer implementations SHOULD display the error message to the user and ask the user to try at a later time.
指示在允许的时间之外尝试访问。对等实现应该向用户显示错误消息，并要求用户稍后再试。
o 647 ERROR_ACCT_DISABLED
o 647错误帐户已禁用
Indicates that the requested account is disabled. Peer implementations SHOULD display the error message to the user, which helps the user to resolve the issue with the administrator.
指示已禁用请求的帐户。对等实现应该向用户显示错误消息，这有助于用户与管理员解决问题。
o 648 ERROR_PASSWD_EXPIRED
o 648错误\u密码\u已过期
Indicates that the password has expired and a password change is required. Peer implementations SHOULD prompt the user for a new password and send back the new password in the peer response packet.
表示密码已过期，需要更改密码。对等实现应提示用户输入新密码，并在对等响应数据包中发回新密码。
o 649 ERROR_NO_DIALIN_PERMISSION
o 649错误\u无\u拨入\u权限
Indicates that access has been denied due to lack of dial-in permission. Peer implementations SHOULD display the error message to the user, which helps the user to resolve the issue with the administrator.
表示由于缺少拨入权限而拒绝访问。对等实现应该向用户显示错误消息，这有助于用户与管理员解决问题。
o 691 ERROR_AUTHENTICATION_FAILURE
o 691错误\身份验证\失败
Indicates that there was authentication failure due to an incorrect username or password. Based on the retry flag described below, peer implementations MAY prompt the user again for a new set of username and password or simply send back an empty acknowledgment packet to acknowledge the failure and go into the termination phase of the authentication session.
表示由于用户名或密码不正确而导致身份验证失败。基于下面描述的重试标志，对等实现可以再次提示用户输入一组新的用户名和密码，或者简单地发回一个空的确认包以确认失败并进入认证会话的终止阶段。
o 709 ERROR_CHANGING_PASSWORD
o 709更改密码时出错
Indicates that the password change failed, most likely because the new password fails to meet the password complexity policy. Peer implementations SHOULD display the error message and prompt the user again for the new password.
指示密码更改失败，很可能是因为新密码不符合密码复杂性策略。对等实现应显示错误消息并再次提示用户输入新密码。
o 755 ERROR_PAC_I-ID_NO_MATCH
o 755错误\u PAC\u I-ID\u不匹配
Indicates that the PAC used to establish the EAP-FAST session cannot be used to authenticate to this user account. Based on the retry flag described below, peer implementations MAY prompt the user again for a new set of username and password or simply send back an empty acknowledgment packet to acknowledge the failure and go into the termination phase of the authentication session.
指示用于建立EAP-FAST会话的PAC不能用于对此用户帐户进行身份验证。基于下面描述的重试标志，对等实现可以再次提示用户输入一组新的用户名和密码，或者简单地发回一个空的确认包以确认失败并进入认证会话的终止阶段。
The "r" is a single character ASCII flag set to '1' if a retry is allowed, and '0' if not. When the server sets this flag to '1', it disables short timeouts, expecting the peer to prompt the user for
“r”是一个单字符ASCII标志，如果允许重试，则设置为“1”；如果不允许重试，则设置为“0”。当服务器将此标志设置为“1”时，它将禁用短超时，期望对等方提示用户输入
new credentials and to resubmit the response. When the server sets this flag to '0', the peer SHOULD NOT prompt the user for new credentials to try again without restarting the EAP-FAST authentication from the beginning.
创建新凭据并重新提交响应。当服务器将此标志设置为“0”时，对等方不应提示用户输入新凭据，以便在不从头重新启动EAP-FAST身份验证的情况下重试。
The <msg> is human-readable ASCII text. Current implementations only support ASCII text.
<msg>是人类可读的ASCII文本。当前的实现只支持ASCII文本。
The server failure packet can be broken into Label/Value pairs using the space character as the separator. The only value that may contain the space character is the <msg> value, which is always the last value pair in the failure packet. The peer SHOULD ignore any unknown label/value pair in the failure packet.
可以使用空格字符作为分隔符将服务器故障数据包分成标签/值对。唯一可能包含空格字符的值是<msg>值，它始终是故障数据包中的最后一个值对。对等方应忽略故障数据包中的任何未知标签/值对。
The error format described above is similar to what is defined in the Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2) [RFC2759], except for the omission of a server challenge. So if the EAP-FAST server is distributing MSCHAPv2 exchanges to the backend inner method server, it can simply return what the backend inner method server returns less the server challenge. In the case of connecting to a one time password or Lightweight Directory Access Protocol (LDAP) [RFC4511] server, the EAP-FAST server can translate the error message into this format. With the addition of the retry count, the peer can potentially prompt the user for new credentials to try again without restarting the EAP-FAST authentication from the beginning. The peer will respond to the error code with another EAP-FAST-GTC Response packet with both the new username and password, or in case of other unrecoverable failures, an empty EAP-FAST-GTC packet for acknowledgement. The peer uses empty EAP-FAST-GTC payload as an acknowledgment of the unrecoverable failure.
上述错误格式类似于Microsoft质询握手身份验证协议版本2（MSCHAPv2）[RFC2759]中定义的格式，只是省略了服务器质询。因此，如果EAP-FAST服务器正在将MSCHAPv2交换分发到后端内部方法服务器，那么它可以简单地返回后端内部方法服务器返回的内容，而不是服务器挑战。在连接到一次性密码或轻型目录访问协议（LDAP）[RFC4511]服务器的情况下，EAP-FAST服务器可以将错误消息转换为该格式。通过添加重试计数，对等方可能会提示用户输入新凭据以重试，而无需从头重新启动EAP-FAST身份验证。对等方将使用另一个带有新用户名和密码的EAP-FAST-GTC响应数据包响应错误代码，或者在其他无法恢复的故障情况下，使用一个空的EAP-FAST-GTC数据包进行确认。对等方使用空EAP-FAST-GTC有效负载作为不可恢复故障的确认。
If the EAP-FAST server finishes authentication for the EAP-FAST-GTC inner method, it will proceed to Protected Termination as described in [RFC4851]. In the case of an unrecoverable EAP-FAST-GTC authentication failure, the EAP server can send an EAP-FAST-GTC error code as described above, along with the Result TLV for protected termination. This way, no extra round trips will occur. The peer can acknowledge the EAP-FAST-GTC failure as well as the Result TLV within the same EAP-FAST packet. Once the server receives the acknowledgement, the TLS tunnel will be torn down and a clear text EAP-Failure will be sent.
如果EAP-FAST服务器完成了EAP-FAST-GTC内部方法的身份验证，它将继续进行[RFC4851]中所述的受保护终止。在不可恢复的EAP-FAST-GTC身份验证失败的情况下，EAP服务器可以发送如上所述的EAP-FAST-GTC错误代码，以及受保护终止的结果TLV。这样，就不会发生额外的往返。对等方可以确认EAP-FAST-GTC故障以及同一EAP-FAST数据包内的结果TLV。一旦服务器收到确认，TLS隧道将被拆除，并发送明文EAP故障。
The username and password, as well as server challenges, MAY support non-ASCII characters. In this case, international username, password, and messages are based on the use of Unicode characters, encoded as UTF-8 [RFC3629] and processed with a certain algorithm to
用户名和密码以及服务器挑战可能支持非ASCII字符。在这种情况下，国际用户名、密码和消息基于Unicode字符的使用，编码为UTF-8[RFC3629]，并通过特定算法处理以
ensure a canonical representation. The username and password input SHOULD be processed according to Section 2.4 of [RFC4282], and the server challenges SHOULD be processed according to [RFC5198].
确保规范化表示。用户名和密码输入应根据[RFC4282]第2.4节进行处理，服务器质询应根据[RFC5198]进行处理。
Since EAP-FAST-GTC does not generate session keys, the MSKi (Master Session Key) used for crypto-binding for EAP-FAST will be filled with all zeros.
由于EAP-FAST-GTC不生成会话密钥，因此用于EAP-FAST加密绑定的MSKi（主会话密钥）将用全零填充。
The EAP-FAST-GTC method sends password information in the clear and MUST NOT be used outside of a protected tunnel providing strong protection, such as the one provided by EAP-FAST. Weak encryption, such as 40-bit encryption or NULL cipher, MUST NOT be used. In addition, the peer MUST authenticate the server before disclosing its credentials. Since EAP-FAST Server-Unauthenticated Provisioning Mode does not authenticate the server, EAP-FAST-GTC MUST NOT be used as the inner method in this mode. EAP-FAST-GTC MAY be used in EAP-FAST authentication and Server-Authenticated Provisioning Mode [RFC5422], where the server is authenticated. Since EAP-FAST-GTC requires the server to have access to the actual authentication secret, it is RECOMMENDED to vary the stored authentication validation data by domain so that a compromise of a server at one location does not compromise others.
EAP-FAST-GTC方法以明文形式发送密码信息，不得在提供强大保护的受保护隧道（如EAP-FAST提供的隧道）外使用。不能使用弱加密，例如40位加密或空密码。此外，对等方必须在披露其凭据之前对服务器进行身份验证。由于EAP-FAST Server Unauthenticated Provisioning Mode不会对服务器进行身份验证，因此在此模式下，EAP-FAST-GTC不得用作内部方法。EAP-FAST-GTC可用于EAP-FAST身份验证和服务器身份验证配置模式[RFC5422]，其中服务器经过身份验证。由于EAP-FAST-GTC要求服务器能够访问实际的身份验证机密，因此建议按域更改存储的身份验证数据，以使一个位置的服务器受损不会危及其他位置。
This section provides the needed security claim requirement for EAP [RFC3748].
本节提供了EAP[RFC3748]所需的安全索赔要求。
Auth. mechanism: Password based. Ciphersuite negotiation: No. However, such negotiation is provided by EAP-FAST for the outer authentication. Mutual authentication: No. However, EAP-FAST provides server-side authentication. Integrity protection: No. However, any method executed within the EAP-FAST tunnel is protected. Replay protection: See above. Confidentiality: See above. Key derivation: Keys are not generated, see Section 2. However, when used inside EAP-FAST, the outer method will provide keys. See [RFC4851] for the properties of those keys. Key strength: See above. Dictionary attack prot.: No. However, when used inside the EAP-FAST tunnel, the protection provided by the TLS tunnel prevents an off-line dictionary attack.
Auth。机制：基于密码。Ciphersuite协商：否。但是，这种协商是由EAP-FAST为外部身份验证提供的。相互身份验证：否。但是，EAP-FAST提供服务器端身份验证。完整性保护：否。但是，EAP-FAST隧道内执行的任何方法都受到保护。重播保护：见上文。保密性：见上文。密钥派生：不生成密钥，请参见第2节。但是，当在EAP-FAST内部使用时，外部方法将提供密钥。有关这些键的属性，请参见[RFC4851]。关键优势：见上文。字典攻击保护：否。但是，当在EAP-FAST隧道内使用时，TLS隧道提供的保护可防止离线字典攻击。
Fast reconnect: No. However, EAP-FAST provides a fast reconnect capability that allows the reuse of an earlier session authenticated by EAP-FAST-GTC. Cryptographic binding: No. Given that no keys are generated, EAP-FAST-GTC or its use within EAP-FAST cannot provide a cryptographic assurance that no binding attack has occurred. EAP-FAST-GTC is required only to run within a protected tunnel, but even the use of the same credentials in some other, unprotected context might lead to a vulnerability. As a result, credentials used in EAP-FAST-GTC SHOULD NOT be used in other unprotected authentication mechanisms. Session independence: No. However, EAP-FAST provides session independence. Fragmentation: No. However, EAP-FAST provides support for this. Key Hierarchy: Not applicable. Channel binding: No, though EAP-FAST can be extended for this.
快速重新连接：否。但是，EAP-Fast提供了一种快速重新连接功能，允许重用由EAP-Fast-GTC认证的早期会话。加密绑定：否。鉴于未生成密钥，EAP-FAST-GTC或其在EAP-FAST中的使用无法提供未发生绑定攻击的加密保证。EAP-FAST-GTC仅需要在受保护的隧道内运行，但即使在其他未受保护的上下文中使用相同的凭据也可能导致漏洞。因此，EAP-FAST-GTC中使用的凭据不应用于其他未受保护的身份验证机制。会话独立性：否。但是，EAP-FAST提供会话独立性。碎片：否。但是，EAP-FAST为此提供了支持。密钥层次结构：不适用。通道绑定：否，但EAP-FAST可以为此进行扩展。
EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type in [RFC3748].
EAP-FAST-GTC对[RFC3748]中的EAP类型使用赋值6（EAP-GTC）。
This document defines a registry for EAP-FAST-GTC error codes when running inside EAP-FAST, named "EAP-FAST GTC Error Codes". It may be assigned by Specification Required as defined in [RFC5226]. A summary of the error codes defined so far is given below:
本文档定义了在EAP-FAST内部运行时EAP-FAST-GTC错误代码的注册表，名为“EAP-FAST GTC错误代码”。可根据[RFC5226]中规定的规范进行分配。目前定义的错误代码汇总如下：
o 646 ERROR_RESTRICTED_LOGON_HOURS
o 646错误\u限制\u登录\u小时
o 647 ERROR_ACCT_DISABLED
o 647错误帐户已禁用
o 648 ERROR_PASSWD_EXPIRED
o 648错误\u密码\u已过期
o 649 ERROR_NO_DIALIN_PERMISSION
o 649错误\u无\u拨入\u权限
o 691 ERROR_AUTHENTICATION_FAILURE
o 691错误\身份验证\失败
o 709 ERROR_CHANGING_PASSWORD
o 709更改密码时出错
o 755 ERROR_PAC_I-ID_NO_MATCH
o 755错误\u PAC\u I-ID\u不匹配
No IANA registry will be created for Labels, as current implementations only support the Labels defined in this document and new Labels are not expected; if necessary, new Labels can be defined in documents updating this document.
不会为标签创建IANA注册表，因为当前的实现只支持本文档中定义的标签，不需要新标签；如有必要，可以在更新此文档的文档中定义新标签。
The authors would like thank Joe Salowey and Amir Naftali for their contributions of the problem space, and Jouni Malinen, Pasi Eronen, Jari Arkko, and Chris Newman for reviewing this document.
作者要感谢Joe Salowey和Amir Naftali对问题空间的贡献，以及Jouni Malinen、Pasi Eronen、Jari Arkko和Chris Newman对本文件的审阅。
[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月。
[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月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282]Aboba，B.，Beadles，M.，Arkko，J.，和P.Erenen，“网络访问标识符”，RFC 42822005年12月。
[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月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年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月。
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, January 2000.
[RFC2759]Zorn，G.，“微软PPP CHAP扩展，第2版”，RFC 2759，2000年1月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)", RFC 5422, March 2009.
[RFC5422]Cam Winget，N.，McGrew，D.，Salowey，J.，和H.Zhou，“通过安全隧道可扩展身份验证协议（EAP-FAST）使用灵活身份验证的动态资源调配”，RFC 5422，2009年3月。
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
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
郝州思科系统4125美国俄亥俄州汉兰达大道里奇菲尔德44286号
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com