Internet Engineering Task Force (IETF) H. Zhou
Request for Comments: 7170 N. Cam-Winget
Category: Standards Track J. Salowey
ISSN: 2070-1721 Cisco Systems
S. Hanna
Infineon Technologies
May 2014
Internet Engineering Task Force (IETF) H. Zhou
Request for Comments: 7170 N. Cam-Winget
Category: Standards Track J. Salowey
ISSN: 2070-1721 Cisco Systems
S. Hanna
Infineon Technologies
May 2014
Tunnel Extensible Authentication Protocol (TEAP) Version 1
隧道可扩展身份验证协议（TEAP）第1版
Abstract
摘要
This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server.
本文档定义了隧道可扩展身份验证协议（TEAP）版本1。TEAP是一种基于隧道的EAP方法，通过使用传输层安全（TLS）协议建立相互认证的隧道，实现对等方和服务器之间的安全通信。在隧道内，TLV对象用于在EAP对等方和EAP服务器之间传输与身份验证相关的数据。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7170.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7170.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Specification Requirements . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol-Layering Model . . . . . . . . . . . . . . . . . 8
3. TEAP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 9
3.2. TEAP Authentication Phase 1: Tunnel Establishment . . . . 10
3.2.1. TLS Session Resume Using Server State . . . . . . . . 11
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . 12
3.2.3. Transition between Abbreviated and Full TLS Handshake 13
3.3. TEAP Authentication Phase 2: Tunneled Authentication . . 14
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 14
3.3.2. Optional Password Authentication . . . . . . . . . . 15
3.3.3. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . 15
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 16
3.5. TEAP Session Identifier . . . . . . . . . . . . . . . . . 17
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. Outer-Layer Errors . . . . . . . . . . . . . . . . . 18
3.6.2. TLS Layer Errors . . . . . . . . . . . . . . . . . . 18
3.6.3. Phase 2 Errors . . . . . . . . . . . . . . . . . . . 19
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19
3.8. Peer Services . . . . . . . . . . . . . . . . . . . . . . 20
3.8.1. PAC Provisioning . . . . . . . . . . . . . . . . . . 21
3.8.2. Certificate Provisioning within the Tunnel . . . . . 22
3.8.3. Server Unauthenticated Provisioning Mode . . . . . . 23
3.8.4. Channel Binding . . . . . . . . . . . . . . . . . . . 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Specification Requirements . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Architectural Model . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol-Layering Model . . . . . . . . . . . . . . . . . 8
3. TEAP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 9
3.2. TEAP Authentication Phase 1: Tunnel Establishment . . . . 10
3.2.1. TLS Session Resume Using Server State . . . . . . . . 11
3.2.2. TLS Session Resume Using a PAC . . . . . . . . . . . 12
3.2.3. Transition between Abbreviated and Full TLS Handshake 13
3.3. TEAP Authentication Phase 2: Tunneled Authentication . . 14
3.3.1. EAP Sequences . . . . . . . . . . . . . . . . . . . . 14
3.3.2. Optional Password Authentication . . . . . . . . . . 15
3.3.3. Protected Termination and Acknowledged Result
Indication . . . . . . . . . . . . . . . . . . . . . 15
3.4. Determining Peer-Id and Server-Id . . . . . . . . . . . . 16
3.5. TEAP Session Identifier . . . . . . . . . . . . . . . . . 17
3.6. Error Handling . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. Outer-Layer Errors . . . . . . . . . . . . . . . . . 18
3.6.2. TLS Layer Errors . . . . . . . . . . . . . . . . . . 18
3.6.3. Phase 2 Errors . . . . . . . . . . . . . . . . . . . 19
3.7. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 19
3.8. Peer Services . . . . . . . . . . . . . . . . . . . . . . 20
3.8.1. PAC Provisioning . . . . . . . . . . . . . . . . . . 21
3.8.2. Certificate Provisioning within the Tunnel . . . . . 22
3.8.3. Server Unauthenticated Provisioning Mode . . . . . . 23
3.8.4. Channel Binding . . . . . . . . . . . . . . . . . . . 23
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. TEAP Message Format . . . . . . . . . . . . . . . . . . . 24
4.2. TEAP TLV Format and Support . . . . . . . . . . . . . . . 26
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . 28
4.2.2. Authority-ID TLV . . . . . . . . . . . . . . . . . . 29
4.2.3. Identity-Type TLV . . . . . . . . . . . . . . . . . . 30
4.2.4. Result TLV . . . . . . . . . . . . . . . . . . . . . 31
4.2.5. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.6. Error TLV . . . . . . . . . . . . . . . . . . . . . . 33
4.2.7. Channel-Binding TLV . . . . . . . . . . . . . . . . . 36
4.2.8. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 37
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . 38
4.2.10. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 40
4.2.11. Intermediate-Result TLV . . . . . . . . . . . . . . . 41
4.2.12. PAC TLV Format . . . . . . . . . . . . . . . . . . . 42
4.2.12.1. Formats for PAC Attributes . . . . . . . . . . . 43
4.2.12.2. PAC-Key . . . . . . . . . . . . . . . . . . . . 44
4.2.12.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . 44
4.2.12.4. PAC-Info . . . . . . . . . . . . . . . . . . . . 45
4.2.12.5. PAC-Acknowledgement TLV . . . . . . . . . . . . 47
4.2.12.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . 48
4.2.13. Crypto-Binding TLV . . . . . . . . . . . . . . . . . 48
4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . . 51
4.2.15. Basic-Password-Auth-Resp TLV . . . . . . . . . . . . 52
4.2.16. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . 53
4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 54
4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . . 55
4.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . 57
4.3.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . 57
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . 58
5.1. TEAP Authentication Phase 1: Key Derivations . . . . . . 58
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 59
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . 61
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 61
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
7. Security Considerations . . . . . . . . . . . . . . . . . . . 66
7.1. Mutual Authentication and Integrity Protection . . . . . 67
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . 67
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 67
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . 68
7.4.1. User Identity Protection and Verification . . . . . . 69
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . 70
7.4.3. Protection against Man-in-the-Middle Attacks . . . . 70
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . 71
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. TEAP Message Format . . . . . . . . . . . . . . . . . . . 24
4.2. TEAP TLV Format and Support . . . . . . . . . . . . . . . 26
4.2.1. General TLV Format . . . . . . . . . . . . . . . . . 28
4.2.2. Authority-ID TLV . . . . . . . . . . . . . . . . . . 29
4.2.3. Identity-Type TLV . . . . . . . . . . . . . . . . . . 30
4.2.4. Result TLV . . . . . . . . . . . . . . . . . . . . . 31
4.2.5. NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.6. Error TLV . . . . . . . . . . . . . . . . . . . . . . 33
4.2.7. Channel-Binding TLV . . . . . . . . . . . . . . . . . 36
4.2.8. Vendor-Specific TLV . . . . . . . . . . . . . . . . . 37
4.2.9. Request-Action TLV . . . . . . . . . . . . . . . . . 38
4.2.10. EAP-Payload TLV . . . . . . . . . . . . . . . . . . . 40
4.2.11. Intermediate-Result TLV . . . . . . . . . . . . . . . 41
4.2.12. PAC TLV Format . . . . . . . . . . . . . . . . . . . 42
4.2.12.1. Formats for PAC Attributes . . . . . . . . . . . 43
4.2.12.2. PAC-Key . . . . . . . . . . . . . . . . . . . . 44
4.2.12.3. PAC-Opaque . . . . . . . . . . . . . . . . . . . 44
4.2.12.4. PAC-Info . . . . . . . . . . . . . . . . . . . . 45
4.2.12.5. PAC-Acknowledgement TLV . . . . . . . . . . . . 47
4.2.12.6. PAC-Type TLV . . . . . . . . . . . . . . . . . . 48
4.2.13. Crypto-Binding TLV . . . . . . . . . . . . . . . . . 48
4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . . 51
4.2.15. Basic-Password-Auth-Resp TLV . . . . . . . . . . . . 52
4.2.16. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . 53
4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 54
4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . . 55
4.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . 57
4.3.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . 57
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . 58
5.1. TEAP Authentication Phase 1: Key Derivations . . . . . . 58
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 59
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . 61
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 61
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
7. Security Considerations . . . . . . . . . . . . . . . . . . . 66
7.1. Mutual Authentication and Integrity Protection . . . . . 67
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . 67
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 67
7.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies . . . . . . . . . . . . . . . . . . . . . . 68
7.4.1. User Identity Protection and Verification . . . . . . 69
7.4.2. Dictionary Attack Resistance . . . . . . . . . . . . 70
7.4.3. Protection against Man-in-the-Middle Attacks . . . . 70
7.4.4. PAC Binding to User Identity . . . . . . . . . . . . 71
7.5. Protecting against Forged Cleartext EAP Packets . . . . . 71
7.6. Server Certificate Validation . . . . . . . . . . . . . . 72
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 72
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 73
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1. Normative References . . . . . . . . . . . . . . . . . . 75
9.2. Informative References . . . . . . . . . . . . . . . . . 76
Appendix A. Evaluation against Tunnel-Based EAP Method
Requirements . . . . . . . . . . . . . . . . . . . . 79
A.1. Requirement 4.1.1: RFC Compliance . . . . . . . . . . . . 79
A.2. Requirement 4.2.1: TLS Requirements . . . . . . . . . . . 79
A.3. Requirement 4.2.1.1.1: Ciphersuite Negotiation . . . . . 79
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms 79
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key
Establishment . . . . . . . . . . . . . . . . . . . . . . 79
A.6. Requirement 4.2.1.2: Tunnel Replay Protection . . . . . . 79
A.7. Requirement 4.2.1.3: TLS Extensions . . . . . . . . . . . 80
A.8. Requirement 4.2.1.4: Peer Identity Privacy . . . . . . . 80
A.9. Requirement 4.2.1.5: Session Resumption . . . . . . . . . 80
A.10. Requirement 4.2.2: Fragmentation . . . . . . . . . . . . 80
A.11. Requirement 4.2.3: Protection of Data External to Tunnel 80
A.12. Requirement 4.3.1: Extensible Attribute Types . . . . . . 80
A.13. Requirement 4.3.2: Request/Challenge Response Operation . 80
A.14. Requirement 4.3.3: Indicating Criticality of Attributes . 80
A.15. Requirement 4.3.4: Vendor-Specific Support . . . . . . . 81
A.16. Requirement 4.3.5: Result Indication . . . . . . . . . . 81
A.17. Requirement 4.3.6: Internationalization of Display
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.18. Requirement 4.4: EAP Channel-Binding Requirements . . . . 81
A.19. Requirement 4.5.1.1: Confidentiality and Integrity . . . 81
A.20. Requirement 4.5.1.2: Authentication of Server . . . . . . 81
A.21. Requirement 4.5.1.3: Server Certificate Revocation
Checking . . . . . . . . . . . . . . . . . . . . . . . . 81
A.22. Requirement 4.5.2: Internationalization . . . . . . . . . 81
A.23. Requirement 4.5.3: Metadata . . . . . . . . . . . . . . . 82
A.24. Requirement 4.5.4: Password Change . . . . . . . . . . . 82
A.25. Requirement 4.6.1: Method Negotiation . . . . . . . . . . 82
A.26. Requirement 4.6.2: Chained Methods . . . . . . . . . . . 82
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication . . 82
A.29. Requirement 4.6.5: Method Metadata . . . . . . . . . . . 82
Appendix B. Major Differences from EAP-FAST . . . . . . . . . . 83
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 83
C.1. Successful Authentication . . . . . . . . . . . . . . . . 83
C.2. Failed Authentication . . . . . . . . . . . . . . . . . . 85
C.3. Full TLS Handshake Using Certificate-Based Ciphersuite . 86
7.5. Protecting against Forged Cleartext EAP Packets . . . . . 71
7.6. Server Certificate Validation . . . . . . . . . . . . . . 72
7.7. Tunnel PAC Considerations . . . . . . . . . . . . . . . . 72
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 73
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 74
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
9.1. Normative References . . . . . . . . . . . . . . . . . . 75
9.2. Informative References . . . . . . . . . . . . . . . . . 76
Appendix A. Evaluation against Tunnel-Based EAP Method
Requirements . . . . . . . . . . . . . . . . . . . . 79
A.1. Requirement 4.1.1: RFC Compliance . . . . . . . . . . . . 79
A.2. Requirement 4.2.1: TLS Requirements . . . . . . . . . . . 79
A.3. Requirement 4.2.1.1.1: Ciphersuite Negotiation . . . . . 79
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms 79
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key
Establishment . . . . . . . . . . . . . . . . . . . . . . 79
A.6. Requirement 4.2.1.2: Tunnel Replay Protection . . . . . . 79
A.7. Requirement 4.2.1.3: TLS Extensions . . . . . . . . . . . 80
A.8. Requirement 4.2.1.4: Peer Identity Privacy . . . . . . . 80
A.9. Requirement 4.2.1.5: Session Resumption . . . . . . . . . 80
A.10. Requirement 4.2.2: Fragmentation . . . . . . . . . . . . 80
A.11. Requirement 4.2.3: Protection of Data External to Tunnel 80
A.12. Requirement 4.3.1: Extensible Attribute Types . . . . . . 80
A.13. Requirement 4.3.2: Request/Challenge Response Operation . 80
A.14. Requirement 4.3.3: Indicating Criticality of Attributes . 80
A.15. Requirement 4.3.4: Vendor-Specific Support . . . . . . . 81
A.16. Requirement 4.3.5: Result Indication . . . . . . . . . . 81
A.17. Requirement 4.3.6: Internationalization of Display
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 81
A.18. Requirement 4.4: EAP Channel-Binding Requirements . . . . 81
A.19. Requirement 4.5.1.1: Confidentiality and Integrity . . . 81
A.20. Requirement 4.5.1.2: Authentication of Server . . . . . . 81
A.21. Requirement 4.5.1.3: Server Certificate Revocation
Checking . . . . . . . . . . . . . . . . . . . . . . . . 81
A.22. Requirement 4.5.2: Internationalization . . . . . . . . . 81
A.23. Requirement 4.5.3: Metadata . . . . . . . . . . . . . . . 82
A.24. Requirement 4.5.4: Password Change . . . . . . . . . . . 82
A.25. Requirement 4.6.1: Method Negotiation . . . . . . . . . . 82
A.26. Requirement 4.6.2: Chained Methods . . . . . . . . . . . 82
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 82
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication . . 82
A.29. Requirement 4.6.5: Method Metadata . . . . . . . . . . . 82
Appendix B. Major Differences from EAP-FAST . . . . . . . . . . 83
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 83
C.1. Successful Authentication . . . . . . . . . . . . . . . . 83
C.2. Failed Authentication . . . . . . . . . . . . . . . . . . 85
C.3. Full TLS Handshake Using Certificate-Based Ciphersuite . 86
C.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 89
C.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 91
C.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 94
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 95
C.9. Peer Requests Inner Method after Server Sends Result TLV 97
C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . . 99
C.4. Client Authentication during Phase 1 with Identity
Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 88
C.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 89
C.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 91
C.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 94
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange 95
C.9. Peer Requests Inner Method after Server Sends Result TLV 97
C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . . 99
A tunnel-based Extensible Authentication Protocol (EAP) method is an EAP method that establishes a secure tunnel and executes other EAP methods under the protection of that secure tunnel. A tunnel-based EAP method can be used in any lower-layer protocol that supports EAP authentication. There are several existing tunnel-based EAP methods that use Transport Layer Security (TLS) [RFC5246] to establish the secure tunnel. EAP methods supporting this include Protected EAP (PEAP) [PEAP], EAP Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], and EAP Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851]. However, they all are either vendor-specific or informational, and the industry calls for a Standards Track tunnel-based EAP method. [RFC6678] outlines the list of requirements for a standard tunnel-based EAP method.
基于隧道的可扩展身份验证协议（EAP）方法是建立安全隧道并在该安全隧道的保护下执行其他EAP方法的EAP方法。基于隧道的EAP方法可用于支持EAP身份验证的任何较低层协议。现有几种基于隧道的EAP方法使用传输层安全性（TLS）[RFC5246]来建立安全隧道。支持这一点的EAP方法包括受保护的EAP（PEAP）[PEAP]、EAP隧道传输层安全（EAP-TTLS）[RFC5281]和通过安全隧道的EAP灵活身份验证（EAP-FAST）[RFC4851]。然而，它们都是特定于供应商的或信息性的，行业要求采用基于标准轨道隧道的EAP方法。[RFC6678]概述了基于隧道的标准EAP方法的要求列表。
Since its introduction, EAP-FAST [RFC4851] has been widely adopted in a variety of devices and platforms. It has been adopted by the EMU working group as the basis for the standard tunnel-based EAP method. This document describes the Tunnel Extensible Authentication Protocol (TEAP) version 1, based on EAP-FAST [RFC4851] with some minor changes to meet the requirements outlined in [RFC6678] for a standard tunnel-based EAP method.
自推出以来，EAP-FAST[RFC4851]已广泛应用于各种设备和平台。EMU工作组已将其作为基于隧道的标准EAP方法的基础。本文件描述了基于EAP-FAST[RFC4851]的隧道可扩展认证协议（TEAP）第1版，并对其进行了一些小改动，以满足[RFC6678]中概述的标准隧道EAP方法的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Much of the terminology in this document comes from [RFC3748]. Additional terms are defined below:
本文档中的许多术语来自[RFC3748]。其他术语定义如下：
Protected Access Credential (PAC)
受保护访问凭据（PAC）
Credentials distributed to a peer for future optimized network authentication. The PAC consists of a minimum of two components: a shared secret and an opaque element. The shared secret component contains the pre-shared key between the peer and the authentication server. The opaque part is provided to the peer and is presented to the authentication server when the peer wishes to obtain access to network resources. The opaque element and shared secret are used with TLS stateless session resumption defined in [RFC5077] to establish a protected TLS session. The secret key and opaque part may be distributed using [RFC5077] messages or using TLVs within the TEAP tunnel. Finally, a PAC may optionally include other information that may be useful to the peer.
分发给对等方的凭据，用于将来优化的网络身份验证。PAC至少由两部分组成：一个共享秘密和一个不透明元素。共享密钥组件包含对等方和身份验证服务器之间的预共享密钥。不透明部分提供给对等方，并在对等方希望获得对网络资源的访问时呈现给认证服务器。不透明元素和共享机密与[RFC5077]中定义的TLS无状态会话恢复一起使用，以建立受保护的TLS会话。可使用[RFC5077]消息或TEAP隧道内的TLV分发密钥和不透明部分。最后，PAC可以选择性地包括对对等方可能有用的其他信息。
Type-Length-Value (TLV)
类型长度值（TLV）
The TEAP protocol utilizes objects in TLV format. The TLV format is defined in Section 4.2.
TEAP协议使用TLV格式的对象。TLV格式在第4.2节中定义。
TEAP authentication occurs in two phases after the initial EAP Identity request/response exchange. In the first phase, TEAP employs the TLS [RFC5246] handshake to provide an authenticated key exchange and to establish a protected tunnel. Once the tunnel is established, the second phase begins with the peer and server engaging in further conversations to establish the required authentication and authorization policies. TEAP makes use of TLV objects to carry out the inner authentication, results, and other information, such as channel-binding information.
TEAP身份验证在初始EAP身份请求/响应交换后分两个阶段进行。在第一阶段，技经评估组利用TLS[RFC5246]握手来提供经认证的密钥交换并建立受保护的隧道。一旦建立了隧道，第二阶段将开始，对等方和服务器将进行进一步的对话，以建立所需的身份验证和授权策略。TEAP利用TLV对象执行内部身份验证、结果和其他信息，如通道绑定信息。
TEAP makes use of the TLS SessionTicket extension [RFC5077], which supports TLS session resumption without requiring session-specific state stored at the server. In this document, the SessionTicket is referred to as the Protected Access Credential opaque data (or PAC-Opaque). The PAC-Opaque may be distributed through the use of the NewSessionTicket message or through a mechanism that uses TLVs within Phase 2 of TEAP. The secret key used to resume the session in TEAP is referred to as the Protected Access Credential key (or PAC-Key). When the NewSessionTicket message is used to distribute the PAC-Opaque, the PAC-Key is the master secret for the session. If TEAP
TEAP使用TLS SessionTicket扩展[RFC5077]，该扩展支持TLS会话恢复，而不需要存储在服务器上的特定于会话的状态。在本文档中，SessionTicket被称为受保护的访问凭据不透明数据（或PAC不透明）。PAC不透明可通过使用NewSessionTicket消息或通过在TEAP第2阶段内使用TLV的机制进行分发。TEAP中用于恢复会话的密钥称为受保护访问凭据密钥（或PAC密钥）。当NewSessionTicket消息用于分发PAC密钥时，PAC密钥是会话的主密钥。如果技经评估组
Phase 2 is used to distribute the PAC-Opaque, then the PAC-Key is distributed along with the PAC-Opaque. TEAP implementations MUST support the [RFC5077] mechanism for distributing a PAC-Opaque, and it is RECOMMENDED that implementations support the capability to distribute the ticket and secret key within the TEAP tunnel.
阶段2用于分发PAC不透明，然后PAC密钥与PAC不透明一起分发。TEAP实现必须支持[RFC5077]机制来分发PAC，建议实现支持在TEAP隧道内分发票据和密钥的功能。
The TEAP conversation is used to establish or resume an existing session to typically establish network connectivity between a peer and the network. Upon successful execution of TEAP, the EAP peer and EAP server both derive strong session key material that can then be communicated to the network access server (NAS) for use in establishing a link-layer security association.
技经评估组对话用于建立或恢复现有会话，以通常在对等方和网络之间建立网络连接。成功执行TEAP后，EAP对等方和EAP服务器都派生出强会话密钥材料，然后可以将其传送到网络访问服务器（NAS）以用于建立链路层安全关联。
The network architectural model for TEAP usage is shown below:
技经评估组使用的网络架构模型如下所示：
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
TEAP Architectural Model
技经评估组建筑模型
The entities depicted above are logical entities and may or may not correspond to separate network components. For example, the TEAP server and inner method server might be a single entity; the authenticator and TEAP server might be a single entity; or the functions of the authenticator, TEAP server, and inner method server might be combined into a single physical device. For example, typical IEEE 802.11 deployments place the authenticator in an access point (AP) while a RADIUS server may provide the TEAP and inner method server components. The above diagram illustrates the division of labor among entities in a general manner and shows how a distributed system might be constructed; however, actual systems might be realized more simply. The security considerations in Section 7.3 provide an additional discussion of the implications of separating the TEAP server from the inner method server.
上面描述的实体是逻辑实体，可能对应于也可能不对应于单独的网络组件。例如，TEAP服务器和内部方法服务器可能是单个实体；验证器和TEAP服务器可以是单个实体；或者，验证器、TEAP服务器和内部方法服务器的功能可以组合到单个物理设备中。例如，典型的IEEE 802.11部署将认证器放置在接入点（AP）中，而RADIUS服务器可以提供TEAP和内部方法服务器组件。上图以一般方式说明了实体之间的分工，并显示了如何构建分布式系统；然而，实际系统的实现可能更简单。第7.3节中的安全注意事项进一步讨论了将技经评估组服务器与内部方法服务器分离的含义。
TEAP packets are encapsulated within EAP; EAP in turn requires a transport protocol. TEAP packets encapsulate TLS, which is then used to encapsulate user authentication information. Thus, TEAP messaging can be described using a layered model, where each layer encapsulates the layer above it. The following diagram clarifies the relationship between protocols:
TEAP包被封装在EAP中；EAP反过来需要一个传输协议。TEAP数据包封装TLS，然后TLS用于封装用户身份验证信息。因此，可以使用分层模型来描述TEAP消息传递，其中每一层封装其上的层。下图阐明了协议之间的关系：
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS | Optional Outer TLVs |
|---------------------------------------------------------------|
| TEAP |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
+---------------------------------------------------------------+
| Inner EAP Method | Other TLV information |
|---------------------------------------------------------------|
| TLV Encapsulation (TLVs) |
|---------------------------------------------------------------|
| TLS | Optional Outer TLVs |
|---------------------------------------------------------------|
| TEAP |
|---------------------------------------------------------------|
| EAP |
|---------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+---------------------------------------------------------------+
Protocol-Layering Model
协议分层模型
The TLV layer is a payload with TLV objects as defined in Section 4.2. The TLV objects are used to carry arbitrary parameters between an EAP peer and an EAP server. All conversations in the TEAP protected tunnel are encapsulated in a TLV layer.
TLV层是具有第4.2节中定义的TLV对象的有效载荷。TLV对象用于在EAP对等方和EAP服务器之间传输任意参数。TEAP保护隧道中的所有对话都封装在TLV层中。
TEAP packets may include TLVs both inside and outside the TLS tunnel. The term "Outer TLVs" is used to refer to optional TLVs outside the TLS tunnel, which are only allowed in the first two messages in the TEAP protocol. That is the first EAP-server-to-peer message and first peer-to-EAP-server message. If the message is fragmented, the whole set of messages is counted as one message. The term "Inner TLVs" is used to refer to TLVs sent within the TLS tunnel. In TEAP Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no Inner TLVs are used. In Phase 2 of the TEAP conversation, TLS records may encapsulate zero or more Inner TLVs, but no Outer TLVs.
TEAP分组可以包括TLS隧道内外的tlv。术语“外部TLV”用于指TLS隧道外的可选TLV，仅在TEAP协议的前两条消息中允许。这是第一条EAP服务器到对等消息和第一条对等EAP服务器消息。如果消息是分段的，则整个消息集将计为一条消息。术语“内部TLV”用于指TLS隧道内发送的TLV。在技经评估组第1阶段，外部TLV用于帮助建立TLS隧道，但不使用内部TLV。在TEAP对话的第2阶段，TLS记录可以封装零个或多个内部TLV，但不能封装外部TLV。
Methods for encapsulating EAP within carrier protocols are already defined. For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to transport EAP between the peer and the authenticator; RADIUS [RFC3579] or Diameter [RFC4072] may be used to transport EAP between the authenticator and the EAP server.
已经定义了在载波协议中封装EAP的方法。例如，IEEE 802.1X[IEEE.802-1X.2013]可用于在对等方和认证方之间传输EAP；RADIUS[RFC3579]或Diameter[RFC4072]可用于在验证器和EAP服务器之间传输EAP。
The operation of the protocol, including Phase 1 and Phase 2, is the topic of this section. The format of TEAP messages is given in Section 4, and the cryptographic calculations are given in Section 5.
协议的操作，包括阶段1和阶段2，是本节的主题。TEAP消息的格式见第4节，加密计算见第5节。
TEAP packets contain a 3-bit Version field, following the TLS Flags field, which enables future TEAP implementations to be backward compatible with previous versions of the protocol. This specification documents the TEAP version 1 protocol; implementations of this specification MUST use a Version field set to 1.
TEAP数据包在TLS标志字段之后包含一个3位版本字段，该字段使未来的TEAP实现与协议的早期版本向后兼容。本规范记录了技经评估组第1版协议；此规范的实现必须使用设置为1的版本字段。
Version negotiation proceeds as follows:
版本谈判进行如下：
1. In the first EAP-Request sent with EAP type=TEAP, the EAP server MUST set the Version field to the highest version it supports.
1. 在使用EAP type=TEAP发送的第一个EAP请求中，EAP服务器必须将版本字段设置为其支持的最高版本。
2a. If the EAP peer supports this version of the protocol, it responds with an EAP-Response of EAP type=TEAP, including the version number proposed by the TEAP server.
2a。如果EAP对等方支持此版本的协议，则其响应为EAP type=TEAP的EAP响应，包括TEAP服务器建议的版本号。
2b. If the TEAP peer does not support the proposed version but supports a lower version, it responds with an EAP-Response of EAP type=TEAP and sets the Version field to its highest supported version.
2b。如果TEAP对等方不支持建议的版本，但支持较低的版本，则会使用EAP type=TEAP的EAP响应进行响应，并将版本字段设置为其支持的最高版本。
2c. If the TEAP peer only supports versions higher than the version proposed by the TEAP server, then use of TEAP will not be possible. In this case, the TEAP peer sends back an EAP-Nak either to negotiate a different EAP type or to indicate no other EAP types are available.
2c。如果技经评估组对等方只支持高于技经评估组服务器建议的版本，则不可能使用技经评估组。在这种情况下，TEAP对等方发回EAP Nak以协商不同的EAP类型或指示没有其他可用的EAP类型。
3a. If the TEAP server does not support the version number proposed by the TEAP peer, it MUST either terminate the conversation with an EAP Failure or negotiate a new EAP type.
3a。如果TEAP服务器不支持TEAP对等方建议的版本号，则它必须以EAP故障终止对话或协商新的EAP类型。
3b. If the TEAP server does support the version proposed by the TEAP peer, then the conversation continues using the version proposed by the TEAP peer.
3b。如果TEAP服务器确实支持TEAP对等方提出的版本，则对话将继续使用TEAP对等方提出的版本。
The version negotiation procedure guarantees that the TEAP peer and server will agree to the latest version supported by both parties. If version negotiation fails, then use of TEAP will not be possible, and another mutually acceptable EAP method will need to be negotiated if authentication is to proceed.
版本协商程序保证技经评估组对等方和服务器将同意双方支持的最新版本。如果版本协商失败，则无法使用TEAP，如果要继续进行认证，则需要协商另一种双方均可接受的EAP方法。
The TEAP version is not protected by TLS and hence can be modified in transit. In order to detect a modification of the TEAP version, the peers MUST exchange the TEAP version number received during version negotiation using the Crypto-Binding TLV described in Section 4.2.13. The receiver of the Crypto-Binding TLV MUST verify that the version received in the Crypto-Binding TLV matches the version sent by the receiver in the TEAP version negotiation. If the Crypto-Binding TLV fails to be validated, then it is a fatal error and is handled as described in Section 3.6.3.
技经评估组版本不受TLS保护，因此可在运输过程中进行修改。为了检测TEAP版本的修改，对等方必须使用第4.2.13节所述的加密绑定TLV交换版本协商期间收到的TEAP版本号。加密绑定TLV的接收方必须验证加密绑定TLV中接收的版本是否与TEAP版本协商中接收方发送的版本匹配。如果无法验证加密绑定TLV，则这是一个致命错误，将按照第3.6.3节所述进行处理。
TEAP relies on the TLS handshake [RFC5246] to establish an authenticated and protected tunnel. The TLS version offered by the peer and server MUST be TLS version 1.2 [RFC5246] or later. This version of the TEAP implementation MUST support the following TLS ciphersuites:
TEAP依靠TLS握手[RFC5246]来建立经过身份验证和保护的隧道。对等方和服务器提供的TLS版本必须是TLS版本1.2[RFC5246]或更高版本。此版本的TEAP实施必须支持以下TLS密码套件：
TLS_RSA_WITH_AES_128_CBC_SHA [RFC5246]
TLS_RSA_与_AES_128_CBC_SHA[RFC5246]
TLS_DHE_RSA_WITH_AES_128_CBC_SHA [RFC5246]
TLS_DHE_RSA_与_AES_128_CBC_SHA[RFC5246]
This version of the TEAP implementation SHOULD support the following TLS ciphersuite:
此版本的TEAP实施应支持以下TLS密码套件：
TLS_RSA_WITH_AES_256_CBC_SHA [RFC5246]
TLS_RSA_与_AES_256_CBC_SHA[RFC5246]
Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case when the inner authentication method provides mutual authentication, key generation, and resistance to man-in-the-middle and dictionary attacks. TLS ciphersuites that do not provide confidentiality MUST NOT be used. During the TEAP Phase 1 conversation, the TEAP endpoints MAY negotiate TLS compression. During TLS tunnel establishment, TLS extensions MAY be used. For instance, the Certificate Status Request extension [RFC6066] and the Multiple Certificate Status Request extension [RFC6961] can be used to leverage a certificate-status protocol such as Online Certificate Status Protocol (OCSP) [RFC6960] to check the validity of server certificates. TLS renegotiation indications defined in RFC 5746 [RFC5746] MUST be supported.
可能支持其他密码套件。要求匿名密码套件（如TLS_DH_anon_WITH_AES_128_CBC_SHA[RFC5246]）仅在内部身份验证方法提供相互身份验证、密钥生成以及抵抗中间人攻击和字典攻击的情况下使用。不得使用不提供机密性的TLS密码套件。在TEAP阶段1对话期间，TEAP端点可以协商TLS压缩。在TLS隧道建立期间，可使用TLS延伸。例如，证书状态请求扩展[RFC6066]和多证书状态请求扩展[RFC6961]可用于利用诸如在线证书状态协议（OCSP）[RFC6960]之类的证书状态协议来检查服务器证书的有效性。必须支持RFC 5746[RFC5746]中定义的TLS重新协商指示。
The EAP server initiates the TEAP conversation with an EAP request containing a TEAP/Start packet. This packet includes a set Start (S) bit, the TEAP version as specified in Section 3.1, and an authority identity TLV. The TLS payload in the initial packet is empty. The authority identity TLV (Authority-ID TLV) is used to provide the peer a hint of the server's identity that may be useful in helping the
EAP服务器使用包含TEAP/启动数据包的EAP请求启动TEAP对话。该数据包包括设置的起始位、第3.1节中规定的TEAP版本和授权标识TLV。初始数据包中的TLS有效负载为空。权限标识TLV（authority ID TLV）用于向对等方提供服务器标识的提示，这可能有助于
peer select the appropriate credential to use. Assuming that the peer supports TEAP, the conversation continues with the peer sending an EAP-Response packet with EAP type of TEAP with the Start (S) bit clear and the version as specified in Section 3.1. This message encapsulates one or more TLS handshake messages. If the TEAP version negotiation is successful, then the TEAP conversation continues until the EAP server and EAP peer are ready to enter Phase 2. When the full TLS handshake is performed, then the first payload of TEAP Phase 2 MAY be sent along with a server-finished handshake message to reduce the number of round trips.
对等选择要使用的相应凭据。假设对等方支持TEAP，对话将继续，对等方发送EAP类型为TEAP的EAP响应数据包，起始位清除，版本如第3.1节所述。此消息封装了一个或多个TLS握手消息。如果TEAP版本协商成功，则TEAP对话将继续，直到EAP服务器和EAP对等方准备好进入第2阶段。当执行完整TLS握手时，TEAP阶段2的第一有效载荷可以与服务器完成握手消息一起发送，以减少往返次数。
TEAP implementations MUST support mutual peer authentication during tunnel establishment using the TLS ciphersuites specified in this section. The TEAP peer does not need to authenticate as part of the TLS exchange but can alternatively be authenticated through additional exchanges carried out in Phase 2.
TEAP实施必须在隧道建立期间使用本节中指定的TLS密码套件支持相互对等身份验证。TEAP对等方不需要作为TLS交换的一部分进行身份验证，但也可以通过在第2阶段执行的附加交换进行身份验证。
The TEAP tunnel protects peer identity information exchanged during Phase 2 from disclosure outside the tunnel. Implementations that wish to provide identity privacy for the peer identity need to carefully consider what information is disclosed outside the tunnel prior to Phase 2. TEAP implementations SHOULD support the immediate renegotiation of a TLS session to initiate a new handshake message exchange under the protection of the current ciphersuite. This allows support for protection of the peer's identity when using TLS client authentication. An example of the exchanges using TLS renegotiation to protect privacy is shown in Appendix C.
TEAP隧道保护在阶段2期间交换的对等身份信息不被隧道外披露。希望为对等体身份提供身份隐私的实现需要仔细考虑在第2阶段之前在隧道外部公开什么信息。TEAP实施应支持立即重新协商TLS会话，以在当前密码套件的保护下启动新的握手消息交换。这允许在使用TLS客户端身份验证时支持对对等方身份的保护。使用TLS重新协商保护隐私的交易所示例如附录C所示。
The following sections describe resuming a TLS session based on server-side or client-side state.
以下各节描述基于服务器端或客户端状态恢复TLS会话。
TEAP session resumption is achieved in the same manner TLS achieves session resume. To support session resumption, the server and peer minimally cache the Session ID, master secret, and ciphersuite. The peer attempts to resume a session by including a valid Session ID from a previous TLS handshake in its ClientHello message. If the server finds a match for the Session ID and is willing to establish a new connection using the specified session state, the server will respond with the same Session ID and proceed with the TEAP Phase 1 tunnel establishment based on a TLS abbreviated handshake. After a successful conclusion of the TEAP Phase 1 conversation, the conversation then continues on to Phase 2.
TEAP会话恢复的实现方式与TLS实现会话恢复的方式相同。为了支持会话恢复，服务器和对等机最少缓存会话ID、主密钥和密码套件。对等方试图通过在其ClientHello消息中包含来自先前TLS握手的有效会话ID来恢复会话。如果服务器找到会话ID的匹配项并愿意使用指定的会话状态建立新连接，则服务器将使用相同的会话ID进行响应，并基于TLS简化握手继续TEAP阶段1隧道的建立。技经评估组第一阶段对话圆满结束后，对话继续进行到第二阶段。
TEAP supports the resumption of sessions based on server state being stored on the client side using the TLS SessionTicket extension techniques described in [RFC5077]. This version of TEAP supports the provisioning of a ticket called a Protected Access Credential (PAC) through the use of the NewSessionTicket handshake described in [RFC5077], as well as provisioning of a PAC inside the protected tunnel. Implementations MUST support the TLS Ticket extension [RFC5077] mechanism for distributing a PAC and may provide additional ways to provision the PAC, such as manual configuration. Since the PAC mentioned here is used for establishing the TLS tunnel, it is more specifically referred to as the Tunnel PAC. The Tunnel PAC is a security credential provided by the EAP server to a peer and comprised of:
TEAP支持使用[RFC5077]中描述的TLS SessionTicket扩展技术，根据存储在客户端的服务器状态恢复会话。此版本的TEAP支持通过使用[RFC5077]中描述的NewSessionTicket握手来提供称为受保护访问凭据（PAC）的票证，以及在受保护隧道内提供PAC。实现必须支持用于分发PAC的TLS票证扩展[RFC5077]机制，并且可以提供提供PAC的其他方式，例如手动配置。由于此处提到的PAC用于建立TLS隧道，因此更具体地称为隧道PAC。隧道PAC是EAP服务器向对等方提供的安全凭证，包括：
1. PAC-Key: this is the key used by the peer as the TLS master secret to establish the TEAP Phase 1 tunnel. The PAC-Key is a strong, high-entropy, at minimum 48-octet key and is typically the master secret from a previous TLS session. The PAC-Key is a secret and MUST be treated accordingly. Otherwise, if leaked, it could lead to user credentials being compromised if sent within the tunnel established using the PAC-Key. In the case that a PAC-Key is provisioned to the peer through another means, it MUST have its confidentiality and integrity protected by a mechanism, such as the TEAP Phase 2 tunnel. The PAC-Key MUST be stored securely by the peer.
1. PAC密钥：这是对等方用作TLS主密钥以建立TEAP第1阶段隧道的密钥。PAC密钥是一个强的、高熵的、至少48个八位字节的密钥，通常是来自先前TLS会话的主密钥。PAC密钥是一个秘密，必须进行相应的处理。否则，如果泄漏，如果在使用PAC密钥建立的隧道内发送，可能会导致用户凭据受损。在通过其他方式向对等方提供PAC密钥的情况下，其机密性和完整性必须受到诸如TEAP第2阶段隧道之类的机制的保护。对等方必须安全地存储PAC密钥。
2. PAC-Opaque: this is a variable-length field containing the ticket that is sent to the EAP server during the TEAP Phase 1 tunnel establishment based on [RFC5077]. The PAC-Opaque can only be interpreted by the EAP server to recover the required information for the server to validate the peer's identity and authentication. The PAC-Opaque includes the PAC-Key and other TLS session parameters. It may contain the PAC's peer identity. The PAC-Opaque format and contents are specific to the PAC issuing server. The PAC-Opaque may be presented in the clear, so an attacker MUST NOT be able to gain useful information from the PAC-Opaque itself. The server issuing the PAC-Opaque needs to ensure it is protected with strong cryptographic keys and algorithms. The PAC-Opaque may be distributed using the NewSessionTicket message defined in [RFC5077], or it may be distributed through another mechanism such as the Phase 2 TLVs defined in this document.
2. PAC不透明：这是一个可变长度字段，包含在TEAP第1阶段隧道建立期间根据[RFC5077]发送到EAP服务器的票证。PAC不透明只能由EAP服务器解释，以恢复服务器验证对等方身份和身份验证所需的信息。PAC不透明包括PAC密钥和其他TLS会话参数。它可能包含PAC的对等身份。PAC不透明格式和内容特定于PAC发布服务器。PAC不透明可能以透明形式显示，因此攻击者不能从PAC不透明本身获取有用信息。发出PAC不透明的服务器需要确保它受到强加密密钥和算法的保护。PAC可以使用[RFC5077]中定义的NewSessionTicket消息分发，也可以通过本文档中定义的第2阶段TLV等其他机制分发。
3. PAC-Info: this is an optional variable-length field used to provide, at a minimum, the authority identity of the PAC issuer. Other useful but not mandatory information, such as the PAC-Key lifetime, may also be conveyed by the PAC-issuing server to the peer during PAC provisioning or refreshment. PAC-Info is not included if the NewSessionTicket message is used to provision the PAC.
3. PAC Info：这是一个可选的可变长度字段，用于至少提供PAC颁发者的权限标识。在PAC供应或刷新期间，PAC发布服务器还可以将其他有用但非强制性的信息（如PAC密钥生存期）传送给对等方。如果NewSessionTicket消息用于提供PAC，则不包括PAC信息。
The use of the PAC is based on the SessionTicket extension defined in [RFC5077]. The EAP server initiates the TEAP conversation as normal. Upon receiving the Authority-ID TLV from the server, the peer checks to see if it has an existing valid PAC-Key and PAC-Opaque for the server. If it does, then it obtains the PAC-Opaque and puts it in the SessionTicket extension in the ClientHello. It is RECOMMENDED in TEAP that the peer include an empty Session ID in a ClientHello containing a PAC-Opaque. This version of TEAP supports the NewSessionTicket Handshake message as described in [RFC5077] for distribution of a new PAC, as well as the provisioning of PAC inside the protected tunnel. If the PAC-Opaque included in the SessionTicket extension is valid and the EAP server permits the abbreviated TLS handshake, it will select the ciphersuite from information within the PAC-Opaque and finish with the abbreviated TLS handshake. If the server receives a Session ID and a PAC-Opaque in the SessionTicket extension in a ClientHello, it should place the same Session ID in the ServerHello if it is resuming a session based on the PAC-Opaque. The conversation then proceeds as described in [RFC5077] until the handshake completes or a fatal error occurs. After the abbreviated handshake completes, the peer and the server are ready to commence Phase 2.
PAC的使用基于[RFC5077]中定义的SessionTicket扩展。EAP服务器正常启动TEAP对话。从服务器接收到授权ID TLV后，对等方将检查它是否具有服务器的现有有效PAC密钥和PAC不透明。如果是，则获取PAC不透明并将其放入ClientHello中的SessionTicket扩展中。在技经评估组中，建议对等方在包含PAC的ClientHello中包含一个空会话ID。此版本的TEAP支持[RFC5077]中所述的NewSessionTicket握手消息，用于分发新PAC，以及在受保护隧道内提供PAC。如果SessionTicket扩展中包含的PAC不透明有效，且EAP服务器允许缩写TLS握手，则它将从PAC不透明中的信息中选择密码套件，并以缩写TLS握手结束。如果服务器在ClientHello中的SessionTicket扩展中接收到会话ID和PAC不透明，则如果服务器正在基于PAC不透明恢复会话，则应在ServerHello中放置相同的会话ID。然后，对话按照[RFC5077]中所述继续进行，直到握手完成或出现致命错误。在简短握手完成后，对等方和服务器准备开始第2阶段。
If session resumption based on server-side or client-side state fails, the server can gracefully fall back to a full TLS handshake. If the ServerHello received by the peer contains an empty Session ID or a Session ID that is different than in the ClientHello, the server may fall back to a full handshake. The peer can distinguish the server's intent to negotiate a full or abbreviated TLS handshake by checking the next TLS handshake messages in the server response to the ClientHello. If ChangeCipherSpec follows the ServerHello in response to the ClientHello, then the server has accepted the session resumption and intends to negotiate the abbreviated handshake. Otherwise, the server intends to negotiate the full TLS handshake. A peer can request that a new PAC be provisioned after the full TLS handshake and mutual authentication of the peer and the server. A peer SHOULD NOT request that a new PAC be provisioned after the abbreviated handshake, as requesting a new session ticket based on resumed session is not permitted. In order to facilitate the
如果基于服务器端或客户端状态的会话恢复失败，服务器可以正常地退回到完全TLS握手。如果对等方接收的ServerHello包含空会话ID或与ClientHello中不同的会话ID，则服务器可能会退回到完全握手。对等方可以通过检查服务器对ClientHello的响应中的下一个TLS握手消息来区分服务器协商完整或缩写TLS握手的意图。如果ChangeCipherSpec跟随ServerHello响应ClientHello，则服务器已接受会话恢复，并打算协商缩短的握手。否则，服务器打算协商完整的TLS握手。对等方可以请求在对等方和服务器的完整TLS握手和相互认证之后提供新的PAC。对等方不应请求在简短握手后提供新的PAC，因为不允许基于恢复的会话请求新的会话票证。为了方便
fallback to a full handshake, the peer SHOULD include ciphersuites that allow for a full handshake and possibly PAC provisioning so the server can select one of these in case session resumption fails. An example of the transition is shown in Appendix C.
回退到完全握手，对等方应包括允许完全握手的密码套件，并可能包括PAC配置，以便服务器在会话恢复失败时可以选择其中之一。附录C中给出了一个过渡示例。
The second portion of the TEAP authentication occurs immediately after successful completion of Phase 1. Phase 2 occurs even if both peer and authenticator are authenticated in the Phase 1 TLS negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake fails, as that will compromise the security as the tunnel has not been established successfully. Phase 2 consists of a series of requests and responses encapsulated in TLV objects defined in Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV exchange described in Section 4.2.13 and a protected termination exchange described in Section 3.3.3. The TLV exchange may include the execution of zero or more EAP methods within the protected tunnel as described in Section 3.3.1. A server MAY proceed directly to the protected termination exchange if it does not wish to request further authentication from the peer. However, the peer and server MUST NOT assume that either will skip inner EAP methods or other TLV exchanges, as the other peer might have a different security policy. The peer may have roamed to a network that requires conformance with a different authentication policy, or the peer may request the server take additional action (e.g., channel binding) through the use of the Request-Action TLV as defined in Section 4.2.9.
技经评估组认证的第二部分在第1阶段成功完成后立即进行。即使对等方和身份验证者在第1阶段TLS协商中都经过身份验证，也会发生第2阶段。如果第1阶段TLS握手失败，则不得发生第2阶段，因为这将危及安全性，因为隧道尚未成功建立。阶段2包括一系列封装在第4.2节定义的TLV对象中的请求和响应。第2阶段必须始终以第4.2.13节所述的加密绑定TLV交换和第3.3.3节所述的受保护终端交换结束。TLV交换可能包括在第3.3.1节所述的受保护隧道内执行零个或多个EAP方法。如果服务器不希望从对等方请求进一步的身份验证，则可以直接进入受保护的终端交换。但是，对等方和服务器不得假设其中一方将跳过内部EAP方法或其他TLV交换，因为另一方可能具有不同的安全策略。对等方可能已漫游到需要符合不同身份验证策略的网络，或者对等方可能通过使用第4.2.9节中定义的请求操作TLV请求服务器采取附加操作（例如，通道绑定）。
EAP [RFC3748] prohibits use of multiple authentication methods within a single EAP conversation in order to limit vulnerabilities to man-in-the-middle attacks. TEAP addresses man-in-the-middle attacks through support for cryptographic protection of the inner EAP exchange and cryptographic binding of the inner authentication method(s) to the protected tunnel. EAP methods are executed serially in a sequence. This version of TEAP does not support initiating multiple EAP methods simultaneously in parallel. The methods need not be distinct. For example, EAP-TLS could be run twice as an inner method, first using machine credentials followed by a second instance using user credentials.
EAP[RFC3748]禁止在单个EAP会话中使用多个身份验证方法，以限制中间人攻击的漏洞。TEAP通过支持内部EAP交换的加密保护和内部身份验证方法到受保护隧道的加密绑定来解决中间人攻击。EAP方法按顺序串行执行。此版本的TEAP不支持同时并行启动多个EAP方法。方法不必是不同的。例如，EAP-TLS可以作为内部方法运行两次，首先使用计算机凭据，然后使用用户凭据运行第二个实例。
EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. If more than one method is going to be executed in the tunnel, then upon method completion, the server MUST send an Intermediate-Result TLV indicating the result. The peer MUST respond to the Intermediate-Result TLV indicating its result. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by
EAP方法消息在第4.2.10节中定义的EAP有效载荷TLV内传输。如果要在隧道中执行多个方法，则在方法完成时，服务器必须发送一个指示结果的中间结果TLV。对等方必须响应指示其结果的中间结果TLV。如果结果表明成功，中间结果TLV必须附有
a Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Sections 4.2.13 and 5.3. The Intermediate-Result TLVs can be included with other TLVs such as EAP-Payload TLVs starting a new EAP conversation or with the Result TLV used in the protected termination exchange.
加密绑定TLV。第4.2.13和5.3节进一步讨论了加密绑定TLV。中间结果TLV可以包括在其他TLV中，例如启动新EAP会话的EAP有效负载TLV，或者包括在受保护的终端交换中使用的结果TLV中。
If both peer and server indicate success, then the method is considered complete. If either indicates failure, then the method is considered failed. The result of failure of an EAP method does not always imply a failure of the overall authentication. If one authentication method fails, the server may attempt to authenticate the peer with a different method.
如果对等方和服务器都表示成功，则认为该方法已完成。如果其中一个指示失败，则该方法被视为失败。EAP方法失败的结果并不总是意味着整个身份验证失败。如果一种身份验证方法失败，服务器可能会尝试使用其他方法对对等方进行身份验证。
The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748]. Implementations should instead make use of the password authentication TLVs defined in this specification. The authentication server initiates password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If the peer wishes to participate in password authentication, then it responds with a Basic-Password-Auth-Resp TLV as defined in Section 4.2.15 that contains the username and password. If it does not wish to perform password authentication, then it responds with a NAK TLV indicating the rejection of the Basic-Password-Auth-Req TLV. Upon receiving the response, the server indicates the success or failure of the exchange using an Intermediate-Result TLV. Multiple round trips of password authentication requests and responses MAY be used to support some "housecleaning" functions such as a password or pin change before a user is authenticated.
TEAPv1不建议使用RFC 5421[RFC5421]中定义的EAP-FAST-GTC，因为EAP-FAST-GTC不符合[RFC3748]中定义的EAP-GTC。相反，实现应该使用本规范中定义的密码身份验证TLV。认证服务器通过发送第4.2.14节中定义的基本密码认证请求TLV来启动密码认证。如果对等方希望参与密码验证，则其将使用第4.2.15节中定义的基本密码验证响应TLV进行响应，该TLV包含用户名和密码。如果它不希望执行密码身份验证，那么它会以NAK TLV响应，指示拒绝基本密码身份验证请求TLV。收到响应后，服务器使用中间结果TLV指示交换的成功或失败。密码验证请求和响应的多次往返可用于支持某些“内部清理”功能，例如在用户被验证之前更改密码或pin。
A successful TEAP Phase 2 conversation MUST always end in a successful Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the Crypto-Binding TLV and Result TLV exchange without initiating any EAP conversation in TEAP Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated, and a cleartext EAP Success or EAP Failure is sent by the server. Peers implementing TEAP MUST NOT accept a cleartext EAP Success or failure packet prior to the peer and server reaching synchronized protected result indication.
成功的TEAP第2阶段对话必须始终以成功的加密绑定TLV和结果TLV交换结束。TEAP服务器可以启动加密绑定TLV和结果TLV交换，而无需在TEAP阶段2中启动任何EAP会话。在TLV交换的最终结果之后，TLS隧道终止，服务器发送明文EAP Success或EAP Failure。在对等方和服务器达到同步保护结果指示之前，实现TEAP的对等方不得接受明文EAP成功或失败数据包。
The Crypto-Binding TLV exchange is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type,
加密绑定TLV交换用于证明对等方和服务器都参与了隧道的建立和身份验证序列。它还提供了技经评估组类型的验证，
version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment. The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication. The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful EAP method in a sequence of one or more EAP methods. The server may send the final Result TLV along with an Intermediate-Result TLV and a Crypto-Binding TLV to indicate its intention to end the conversation. If the peer requires nothing more from the server, it will respond with a Result TLV indicating success accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if necessary. The server then tears down the tunnel and sends a cleartext EAP Success or EAP Failure.
版本协商，在TLS隧道建立之前交换外部TLV。无论是否存在内部EAP方法身份验证，在最终结果TLV交换之前，必须交换和验证加密绑定TLV。必须包括加密绑定TLV和中间结果TLV，以便在一个或多个EAP方法序列中的每个成功EAP方法之后执行加密绑定。服务器可以发送最终结果TLV以及中间结果TLV和加密绑定TLV，以指示其结束对话的意图。如果对等方不再需要来自服务器的任何东西，它将响应一个结果TLV，指示成功，并在必要时伴随一个加密绑定TLV和中间结果TLV。然后，服务器断开隧道并发送明文EAP Success或EAP Failure。
If the peer receives a Result TLV indicating success from the server, but its authentication policies are not satisfied (for example, it requires a particular authentication mechanism be run or it wants to request a PAC), it may request further action from the server using the Request-Action TLV. The Request-Action TLV is sent with a Status field indicating what EAP Success/Failure result the peer would expect if the requested action is not granted. The value of the Action field indicates what the peer would like to do next. The format and values for the Request-Action TLV are defined in Section 4.2.9.
如果对等方从服务器接收到指示成功的结果TLV，但其身份验证策略未得到满足（例如，它需要运行特定的身份验证机制或它想要请求PAC），则它可以使用请求操作TLV从服务器请求进一步的操作。发送请求操作TLV时，会附带一个状态字段，指示如果请求的操作未被授予，对等方将预期的EAP成功/失败结果。Action字段的值指示对等方下一步要做什么。第4.2.9节定义了请求操作TLV的格式和值。
Upon receiving the Request-Action TLV, the server may process the request or ignore it, based on its policy. If the server ignores the request, it proceeds with termination of the tunnel and sends the cleartext EAP Success or Failure message based on the Status field of the peer's Request-Action TLV. If the server honors and processes the request, it continues with the requested action. The conversation completes with a Result TLV exchange. The Result TLV may be included with the TLV that completes the requested action.
在收到请求操作TLV后，服务器可以根据其策略处理该请求或忽略该请求。如果服务器忽略该请求，则继续终止隧道，并根据对等方的请求操作TLV的状态字段发送明文EAP Success或Failure消息。如果服务器接受并处理请求，它将继续执行请求的操作。对话结束，结果是TLV交换。结果TLV可能包含在完成请求操作的TLV中。
Error handling for Phase 2 is discussed in Section 3.6.3.
第2阶段的错误处理在第3.6.3节中讨论。
The Peer-Id and Server-Id [RFC5247] may be determined based on the types of credentials used during either the TEAP tunnel creation or authentication. In the case of multiple peer authentications, all authenticated peer identities and their corresponding identity types (Section 4.2.3) need to be exported. In the case of multiple server authentications, all authenticated server identities need to be exported.
对等Id和服务器Id[RFC5247]可以基于TEAP隧道创建或认证期间使用的凭据类型来确定。在多个对等身份验证的情况下，需要导出所有已验证的对等身份及其相应的身份类型（第4.2.3节）。对于多个服务器身份验证，需要导出所有经过身份验证的服务器标识。
When X.509 certificates are used for peer authentication, the Peer-Id is determined by the subject and subjectAltName fields in the peer certificate. As noted in [RFC5280]:
当X.509证书用于对等身份验证时，对等Id由对等证书中的subject和subjectAltName字段确定。如[RFC5280]所述：
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY
be carried in the subject field and/or the subjectAltName
extension. . . . If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty sequence
and the subjectAltName extension MUST be critical.
The subject field identifies the entity associated with the public
key stored in the subject public key field. The subject name MAY
be carried in the subject field and/or the subjectAltName
extension. . . . If subject naming information is present only in
the subjectAltName extension (e.g., a key bound only to an email
address or URI), then the subject name MUST be an empty sequence
and the subjectAltName extension MUST be critical.
Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN).
如果不为空，则主题字段必须包含X.500可分辨名称（DN）。
If an inner EAP method is run, then the Peer-Id is obtained from the inner method.
如果运行内部EAP方法，则从内部方法获取对等Id。
When the server uses an X.509 certificate to establish the TLS tunnel, the Server-Id is determined in a similar fashion as stated above for the Peer-Id, e.g., the subject and subjectAltName fields in the server certificate define the Server-Id.
当服务器使用X.509证书建立TLS隧道时，服务器Id的确定方式与上述对等Id类似，例如，服务器证书中的subject和subjectAltName字段定义服务器Id。
The EAP session identifier [RFC5247] is constructed using the tls-unique from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by Section 3.1 of [RFC5929]. The Session-Id is defined as follows:
EAP会话标识符[RFC5247]是使用第2阶段开始时第1阶段外部隧道中唯一的tls构建的，如[RFC5929]第3.1节所定义。会话Id的定义如下：
Session-Id = teap_type || tls-unique
会话Id=teap|U类型| tls唯一
where teap_type is the EAP Type assigned to TEAP
其中，teap_type是分配给teap的EAP类型
tls-unique = tls-unique from the Phase 1 outer tunnel at the beginning of Phase 2 as defined by Section 3.1 of [RFC5929]
tls unique=根据[RFC5929]第3.1节的定义，在第2阶段开始时，第1阶段外部隧道的tls unique
|| means concatenation
||意味着连接
TEAP uses the error-handling rules summarized below:
技经评估组使用的错误处理规则概述如下：
1. Errors in the outer EAP packet layer are handled as defined in Section 3.6.1.
1. 外部EAP数据包层中的错误按照第3.6.1节中的定义进行处理。
2. Errors in the TLS layer are communicated via TLS alert messages in all phases of TEAP.
2. 在TEAP的所有阶段，TLS层中的错误通过TLS警报消息进行通信。
3. The Intermediate-Result TLVs carry success or failure indications of the individual EAP methods in TEAP Phase 2. Errors within the EAP conversation in Phase 2 are expected to be handled by individual EAP methods.
3. 中间结果TLV带有TEAP第2阶段中单个EAP方法的成功或失败指示。阶段2中EAP对话中的错误预计将由各个EAP方法处理。
4. Violations of the Inner TLV rules are handled using Result TLVs together with Error TLVs.
4. 使用结果TLV和错误TLV处理违反内部TLV规则的行为。
5. Tunnel-compromised errors (errors caused by a failed or missing Crypto-Binding) are handled using Result TLVs and Error TLVs.
5. 隧道泄露错误（由于加密绑定失败或丢失而导致的错误）使用结果TLV和错误TLV进行处理。
Errors on the TEAP outer-packet layer are handled in the following ways:
TEAP外部数据包层上的错误通过以下方式处理：
1. If Outer TLVs are invalid or contain unknown values, they will be ignored.
1. 如果外部TLV无效或包含未知值，它们将被忽略。
2. The entire TEAP packet will be ignored if other fields (version, length, flags, etc.) are inconsistent with this specification.
2. 如果其他字段（版本、长度、标志等）与本规范不一致，则整个TEAP数据包将被忽略。
If the TEAP server detects an error at any point in the TLS handshake or the TLS layer, the server SHOULD send a TEAP request encapsulating a TLS record containing the appropriate TLS alert message rather than immediately terminating the conversation so as to allow the peer to inform the user of the cause of the failure and possibly allow for a restart of the conversation. The peer MUST send a TEAP response to an alert message. The EAP-Response packet sent by the peer may encapsulate a TLS ClientHello handshake message, in which case the TEAP server MAY allow the TEAP conversation to be restarted, or it MAY contain a TEAP response with a zero-length message, in which case the server MUST terminate the conversation with an EAP Failure packet. It is up to the TEAP server whether or not to allow restarts, and, if allowed, how many times the conversation can be restarted. Per TLS [RFC5246], TLS restart is only allowed for non-fatal alerts. A TEAP server implementing restart capability SHOULD impose a limit on the number of restarts, so as to protect against denial-of-service attacks. If the TEAP server does not allow restarts, it MUST terminate the conversation with an EAP Failure packet.
如果TEAP服务器在TLS握手或TLS层的任何点检测到错误，服务器应发送TEAP请求，封装包含适当TLS警报消息的TLS记录，而不是立即终止对话，以便允许对等方通知用户故障原因，并可能允许重新启动对话。对等方必须向警报消息发送TEAP响应。对等方发送的EAP响应包可以封装TLS ClientHello握手消息，在这种情况下，TEAP服务器可以允许重新启动TEAP会话，或者它可以包含长度为零的消息的TEAP响应，在这种情况下，服务器必须使用EAP故障包终止会话。由技经评估组服务器决定是否允许重新启动，如果允许，对话可以重新启动多少次。根据TLS[RFC5246]，TLS重启仅允许用于非致命警报。实现重启功能的TEAP服务器应限制重启次数，以防止拒绝服务攻击。如果TEAP服务器不允许重新启动，则必须使用EAP故障数据包终止对话。
If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer SHOULD send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message. The server may restart the conversation by sending a TEAP request packet encapsulating the
如果TEAP对等方在TLS层的任何点检测到错误，TEAP对等方应发送TEAP响应，封装包含适当TLS警报消息的TLS记录。服务器可以通过发送封装会话的TEAP请求包来重新启动会话
TLS HelloRequest handshake message. The peer may allow the TEAP conversation to be restarted, or it may terminate the conversation by sending a TEAP response with a zero-length message.
TLS HelloRequest握手消息。对等方可以允许重新启动TEAP对话，也可以通过发送长度为零的TEAP响应来终止对话。
Any time the peer or the server finds a fatal error outside of the TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of failure and an Error TLV with the appropriate error code. For errors involving the processing of the sequence of exchanges, such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error code is Unexpected TLVs Exchanged. For errors involving a tunnel compromise, the error code is Tunnel Compromise Error. Upon sending a Result TLV with a fatal Error TLV, the sender terminates the TLS tunnel. Note that a server will still wait for a message from the peer after it sends a failure; however, the server does not need to process the contents of the response message.
在第2阶段TLV处理期间，当对等方或服务器在TLS层之外发现致命错误时，它必须发送失败的结果TLV和带有适当错误代码的错误TLV。对于涉及交换序列处理的错误，例如违反TLV规则（例如，多个EAP有效负载TLV），错误代码是意外的TLV交换。对于涉及隧道妥协的错误，错误代码为隧道妥协错误。在发送带有致命错误TLV的结果TLV时，发送方终止TLS隧道。请注意，服务器在发送失败消息后仍将等待来自对等方的消息；但是，服务器不需要处理响应消息的内容。
For the inner method, retransmission is not needed and SHOULD NOT be attempted, as the Outer TLS tunnel can be considered a reliable transport. If there is a non-fatal error handling the inner method, instead of silently dropping the inner method request or response and not responding, the receiving side SHOULD use an Error TLV with error code Inner Method Error to indicate an error processing the current inner method. The side receiving the Error TLV MAY decide to start a new inner method instead or send back a Result TLV to terminate the TEAP authentication session.
对于内部方法，不需要也不应该尝试重新传输，因为外部TLS隧道可以被视为可靠的传输。如果处理内部方法时出现非致命错误，则接收方应使用带有错误代码的错误TLV INTERNAR method error来指示处理当前内部方法的错误，而不是静默地丢弃内部方法请求或响应而不响应。接收错误TLV的一方可以决定启动新的内部方法，或者返回结果TLV以终止TEAP认证会话。
If a server receives a Result TLV of failure with a fatal Error TLV, it MUST send a cleartext EAP Failure. If a peer receives a Result TLV of failure, it MUST respond with a Result TLV indicating failure. If the server has sent a Result TLV of failure, it ignores the peer response, and it MUST send a cleartext EAP Failure.
如果服务器收到带有致命错误TLV的故障结果TLV，则必须发送明文EAP failure。如果对等方收到失败的结果TLV，它必须以指示失败的结果TLV进行响应。如果服务器发送了失败的结果TLV，它将忽略对等响应，并且必须发送明文EAP失败。
A single TLS record may be up to 16384 octets in length, but a TLS message may span multiple TLS records, and a TLS certificate message may, in principle, be as long as 16 MB. This is larger than the maximum size for a message on most media types; therefore, it is desirable to support fragmentation. Note that in order to protect against reassembly lockup and denial-of-service attacks, it may be desirable for an implementation to set a maximum size for one such group of TLS messages. Since a typical certificate chain is rarely longer than a few thousand octets, and no other field is likely to be anywhere near as long, a reasonable choice of maximum acceptable message length might be 64 KB. This is still a fairly large message packet size so a TEAP implementation MUST provide its own support for
单个TLS记录的长度可能高达16384个八位字节，但TLS消息可能跨越多个TLS记录，原则上，TLS证书消息的长度可能长达16 MB。这大于大多数媒体类型上消息的最大大小；因此，支持碎片化是可取的。注意，为了防止重组锁定和拒绝服务攻击，实现可能需要为一组这样的TLS消息设置最大大小。由于一个典型的证书链的长度很少超过几千个八位字节，而且没有其他字段可能接近于此长度，因此可以合理选择的最大可接受消息长度可能是64 KB。这仍然是一个相当大的消息包大小，因此TEAP实现必须提供它自己对消息包的支持
fragmentation and reassembly. Section 3.1 of [RFC3748] discusses determining the MTU usable by EAP, and Section 4.3 discusses retransmissions in EAP.
碎片和重组。[RFC3748]第3.1节讨论了确定EAP可用的MTU，第4.3节讨论了EAP中的重传。
Since EAP is a lock-step protocol, fragmentation support can be added in a simple manner. In EAP, fragments that are lost or damaged in transit will be retransmitted, and since sequencing information is provided by the Identifier field in EAP, there is no need for a fragment offset field.
由于EAP是一种锁步协议，因此可以以简单的方式添加碎片支持。在EAP中，在传输过程中丢失或损坏的片段将被重新传输，并且由于序列信息由EAP中的标识符字段提供，因此不需要片段偏移字段。
TEAP fragmentation support is provided through the addition of flag bits within the EAP-Response and EAP-Request packets, as well as a Message Length field of four octets. Flags include the Length included (L), More fragments (M), and TEAP Start (S) bits. The L flag is set to indicate the presence of the four-octet Message Length field and MUST be set for the first fragment of a fragmented TLS message or set of messages. It MUST NOT be present for any other message. The M flag is set on all but the last fragment. The S flag is set only within the TEAP start message sent from the EAP server to the peer. The Message Length field is four octets and provides the total length of the message that may be fragmented over the data fields of multiple packets; this simplifies buffer allocation.
TEAP分段支持是通过在EAP响应和EAP请求数据包中添加标志位以及四个八位字节的消息长度字段来提供的。标志包括包含的长度（L）、更多片段（M）和TEAP开始位。设置L标志以指示存在四个八位字节的消息长度字段，并且必须为分段TLS消息或消息集的第一个片段设置L标志。对于任何其他消息，它不得出现。除最后一个片段外，所有片段都设置了M标志。S标志仅在从EAP服务器发送到对等方的TEAP启动消息中设置。消息长度字段为四个八位字节，并提供消息的总长度，该消息可在多个分组的数据字段上分段；这简化了缓冲区分配。
When a TEAP peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP Type of TEAP and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value.
当TEAP对等方接收到设置了M位的EAP请求数据包时，它必须以EAP类型为TEAP且无数据的EAP响应进行响应。这是一个片段。EAP服务器必须等到收到EAP响应后再发送另一个片段。为了防止处理片段时出错，EAP服务器必须增加EAP请求中包含的每个片段的标识符字段，并且对等方必须在EAP响应中包含的片段确认中包含此标识符值。重新传输的片段将包含相同的标识符值。
Similarly, when the TEAP server receives an EAP-Response with the M bit set, it responds with an EAP-Request with EAP Type of TEAP and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP-Response.
类似地，当TEAP服务器接收到设置了M位的EAP响应时，它会以EAP类型为TEAP且无数据的EAP请求进行响应。这是一个片段。EAP对等方必须等到收到EAP请求后再发送另一个片段。为了防止片段处理中出现错误，EAP服务器必须增加EAP请求中包含的每个片段ACK的标识符值，并且对等方必须在EAP响应中包含的后续片段中包含该标识符值。
Several TEAP services, including server unauthenticated provisioning, PAC provisioning, certificate provisioning, and channel binding, depend on the peer trusting the TEAP server. Peers MUST authenticate
几个TEAP服务，包括服务器未经验证的配置、PAC配置、证书配置和通道绑定，都依赖于信任TEAP服务器的对等方。对等方必须进行身份验证
the server before these peer services are used. TEAP peer implementations MUST have a configuration where authentication fails if server authentication cannot be achieved. In many cases, the server will want to authenticate the peer before providing these services as well.
使用这些对等服务之前的服务器。TEAP对等实现必须具有这样的配置：如果无法实现服务器身份验证，则身份验证将失败。在许多情况下，服务器也会希望在提供这些服务之前对对等方进行身份验证。
TEAP peers MUST track whether or not server authentication has taken place. Server authentication results if the peer trusts the provided server certificate. Typically, this involves both validating the certificate to a trust anchor and confirming the entity named by the certificate is the intended server. Server authentication also results when the procedures in Section 3.2 are used to resume a session in which the peer and server were previously mutually authenticated. Alternatively, peer services can be used if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK Compound Message Authentication Code (MAC) is correctly validated (Section 4.2.13). This is further described in Section 3.8.3.
TEAP对等方必须跟踪是否进行了服务器身份验证。如果对等方信任提供的服务器证书，则会产生服务器身份验证结果。通常，这包括向信任锚验证证书，以及确认由证书命名的实体是预期的服务器。当第3.2节中的过程用于恢复对等方和服务器先前相互验证的会话时，也会产生服务器验证。或者，如果执行了提供相互认证和扩展主会话密钥（EMSK）的内部EAP方法，并且正确验证了与EMSK复合消息认证码（MAC）的加密绑定，则可以使用对等服务（第4.2.13节）。第3.8.3节对此作了进一步说明。
An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how authentication is achieved, only some of these parties may have confidence in it. For example, if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who participate in the authentication need to be considered when evaluating whether to use peer services.
当隧道方法对多方进行身份验证（例如对EAP服务器的对等机器和对等用户进行身份验证）时，会产生额外的复杂性。根据身份验证的实现方式，只有其中一些方可能对其有信心。例如，如果使用强共享机密对用户和EAP服务器进行相互身份验证，则如果机器无法信任用户不向攻击者披露共享机密，则机器可能不相信EAP服务器是经过身份验证的一方。在这些情况下，在评估是否使用对等服务时，需要考虑参与身份验证的各方。
To request provisioning of a PAC, a peer sends a PAC TLV as defined in Section 4.2.12 containing a PAC Attribute as defined in Section 4.2.12.1 of PAC-Type set to the appropriate value. The peer MUST successfully authenticate the EAP server and validate the Crypto-Binding TLV as defined in Section 4.2.13 before issuing the request. The peer MUST send separate PAC TLVs for each type of PAC it wants to be provisioned. Multiple PAC TLVs can be sent in the same packet or in different packets. 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. The server MAY cache the request and provision the PACs requested after all of its internal policies have been satisfied. If a peer receives a PAC with an unknown type, it MUST ignore it.
为了请求提供PAC，对等方发送第4.2.12节中定义的PAC TLV，其中包含第4.2.12.1节中定义的PAC属性，并将其设置为适当的值。在发出请求之前，对等方必须成功验证EAP服务器并验证第4.2.13节中定义的加密绑定TLV。对等方必须为要配置的每种类型的PAC发送单独的PAC TLV。多个PAC TLV可以在同一数据包或不同数据包中发送。EAP服务器将在满足其内部策略后发送PACs，或者，如果其策略要求，它可能会忽略该请求或请求额外的身份验证。服务器可以缓存请求，并在满足其所有内部策略后提供请求的PACs。如果对等方收到类型未知的PAC，则必须忽略它。
A PAC TLV containing a PAC-Acknowledge attribute MUST be sent by the peer to acknowledge the receipt of the Tunnel PAC. A PAC TLV containing a PAC-Acknowledge attribute MUST NOT be used by the peer to acknowledge the receipt of other types of PACs. If the peer receives a PAC TLV with an unknown attribute, it SHOULD ignore the unknown attribute.
对等方必须发送包含PAC确认属性的PAC TLV，以确认隧道PAC的接收。对等方不得使用包含PAC确认属性的PAC TLV确认收到其他类型的PAC。如果对等方收到具有未知属性的PAC TLV，则应忽略该未知属性。
Provisioning of a peer's certificate is supported in TEAP by performing the Simple PKI Request/Response from [RFC5272] using PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a PKCS#10 CertificateRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a Simple PKI Response using a PKCS#7 [RFC2315] degenerate "Certificates Only" message encoded into the body of a PKCS#7 TLV (see Section 4.2.16), only after an authentication method has run and provided an identity proof on the peer prior to a certificate is being issued.
技经评估组通过分别使用PKCS#10和PKCS#7 TLV从[RFC5272]执行简单的PKI请求/响应来支持对等方证书的提供。对等方使用PKCS#10 TLV主体中编码的PKCS#10 CertificateRequest[RFC2986]发送简单PKI请求（参见第4.2.17节）。TEAP服务器使用PKCS#7[RFC2315]退化的“仅证书”消息发出简单的PKI响应，该消息编码到PKCS#7 TLV的主体中（参见第4.2.16节），只有在认证方法运行并在颁发证书之前在对等方上提供身份证明之后。
In order to provide linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request, the peer generating the request SHOULD obtain the tls-unique value from the TLS subsystem as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer operations between obtaining the tls_unique value through generation of the Certification Signing Request (CSR) that contains the current tls_unique value and the subsequent verification of this value by the TEAP server are the "phases of the application protocol during which application-layer authentication occurs" that are protected by the synchronization interoperability mechanism described in the interoperability note in "Channel Bindings for TLS" ([RFC5929], Section 3.1). When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used.
为了通过在签名认证请求中包含特定于当前已认证TLS会话的信息来提供链接身份和占有证明，生成请求的对等方应从“TLS的通道绑定”[RFC5929]中定义的TLS子系统获取TLS唯一值。通过生成包含当前tls_唯一值的认证签名请求（CSR）获得tls_唯一值与TEAP服务器随后验证该值之间的TEAP对等操作是“应用层认证发生期间的应用协议阶段”受“TLS通道绑定”（[RFC5929]，第3.1节）互操作性说明中描述的同步互操作性机制保护的。执行重新协商时，必须使用TLS“安全重新协商”[RFC5746]。
The tls-unique value is base-64-encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challengePassword field ([RFC2985], Section 5.4.1). The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing ciphersuite would result in an issue with this limitation). If tls-unique information is not embedded within the certification request, the challengePassword field MUST be empty to indicate that the peer did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information).
tls唯一值按照[RFC4648]第4节的规定进行base-64编码，生成的字符串放在认证请求challengePassword字段（[RFC2985]，第5.4.1节）中。challengePassword字段限制为255个八位字节（RFC5246第7.4.9节指出，现有密码套件不会导致此限制问题）。如果认证请求中未嵌入tls唯一信息，则challengePassword字段必须为空，以表明对等方未包含可选的通道绑定信息（服务器会将提交的任何值验证为tls唯一信息）。
The server SHOULD verify the tls-unique information. This ensures that the authenticated TEAP peer is in possession of the private key used to sign the certification request.
服务器应验证tls唯一信息。这确保经过身份验证的TEAP对等方拥有用于签署认证请求的私钥。
The Simple PKI Request/Response generation and processing rules of [RFC5272] SHALL apply to TEAP, with the exception of error conditions. In the event of an error, the TEAP server SHOULD respond with an Error TLV using the most descriptive error code possible; it MAY ignore the PKCS#10 request that generated the error.
[RFC5272]的简单PKI请求/响应生成和处理规则应适用于技经评估组，但错误情况除外。在发生错误的情况下，技经评估组服务器应使用最具描述性的错误代码以错误TLV作出响应；它可能会忽略生成错误的PKCS#10请求。
In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in Phase 1, and the peer and server negotiate an EAP method in Phase 2 that supports mutual authentication and key derivation that is resistant to attacks such as man-in-the-middle and dictionary attacks. This provisioning mode enables the bootstrapping of peers when the peer lacks the ability to authenticate the server during Phase 1. This includes both cases in which the ciphersuite negotiated does not provide authentication and in which the ciphersuite negotiated provides the authentication but the peer is unable to validate the identity of the server for some reason.
在服务器未经身份验证的配置模式中，在第1阶段建立未经身份验证的隧道，对等方和服务器在第2阶段协商EAP方法，该方法支持相互身份验证和密钥派生，可抵抗中间人攻击和字典攻击等攻击。当对等方在第1阶段缺乏对服务器进行身份验证的能力时，此配置模式启用对等方的引导。这包括协商的密码套件不提供身份验证和协商的密码套件提供身份验证但对等方由于某种原因无法验证服务器身份的两种情况。
Upon successful completion of the EAP method in Phase 2, the peer and server exchange a Crypto-Binding TLV to bind the inner method with the outer tunnel and ensure that a man-in-the-middle attack has not been attempted.
在阶段2中成功完成EAP方法后，对等方和服务器交换加密绑定TLV，以将内部方法与外部隧道绑定，并确保未尝试中间人攻击。
Support for the Server Unauthenticated Provisioning Mode is optional. The ciphersuite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when using Server Unauthenticated Provisioning Mode, but other anonymous ciphersuites MAY be supported as long as the TLS pre-master secret is generated from contribution from both peers. Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, provide key generation, and be resistant to dictionary attack. Example inner methods include EAP-pwd [RFC5931] and EAP-EKE [RFC6124].
支持服务器未经验证的配置模式是可选的。当使用服务器未经验证的配置模式时，建议使用带有AES_128_CBC_SHA的密码套件TLS_DH_anon_，但只要从两个对等方的贡献中生成TLS预主密钥，则可以支持其他匿名密码套件。在服务器未经身份验证的配置模式中使用的阶段2 EAP方法必须提供相互身份验证，提供密钥生成，并抵抗字典攻击。示例内部方法包括EAP pwd[RFC5931]和EAP-EKE[RFC6124]。
[RFC6677] defines EAP channel bindings to solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the Authentication, Authorization, and Accounting (AAA) server protected within the EAP method. This allows the server to verify the authenticator is providing information to
[RFC6677]定义EAP通道绑定，以解决“说谎NAS”和“说谎提供者”问题，使用EAP对等方向EAP方法中保护的身份验证、授权和计费（AAA）服务器提供有关身份验证者提供的服务特征的信息的过程。这允许服务器验证验证器是否向提供信息
the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator.
与从该验证器接收的信息以及存储的有关该验证器的信息一致的对等方。
TEAP supports EAP channel binding using the Channel-Binding TLV defined in Section 4.2.7. If the TEAP server wants to request the channel-binding information from the peer, it sends an empty Channel-Binding TLV to indicate the request. The peer responds to the request by sending a Channel-Binding TLV containing a channel-binding message as defined in [RFC6677]. The server validates the channel-binding message and sends back a Channel-Binding TLV with a result code. If the server didn't initiate the channel-binding request and the peer still wants to send the channel-binding information to the server, it can do that by using the Request-Action TLV along with the Channel-Binding TLV. The peer MUST only send channel-binding information after it has successfully authenticated the server and established the protected tunnel.
TEAP支持使用第4.2.7节中定义的通道绑定TLV进行EAP通道绑定。如果TEAP服务器想要从对等方请求通道绑定信息，它将发送一个空的通道绑定TLV来指示该请求。对等方通过发送包含[RFC6677]中定义的通道绑定消息的通道绑定TLV来响应请求。服务器验证通道绑定消息并发回带有结果代码的通道绑定TLV。如果服务器没有启动通道绑定请求，而对等方仍然希望将通道绑定信息发送给服务器，则可以通过使用请求操作TLV和通道绑定TLV来完成。对等方只能在成功验证服务器并建立受保护的隧道后发送通道绑定信息。
The following sections describe the message formats used in TEAP. The fields are transmitted from left to right in network byte order.
以下各节介绍技经评估组中使用的信息格式。字段按网络字节顺序从左向右传输。
A summary of the TEAP Request/Response packet format is shown below.
技经评估组请求/响应数据包格式摘要如下所示。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Outer TLV Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Message Length :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Message Length | Outer TLV Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Outer TLV Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
密码
The Code field is one octet in length and is defined as follows:
代码字段的长度为一个八位字节，定义如下：
1 Request
1请求
2 Response
2回应
Identifier
标识符
The Identifier field is one octet and aids in matching responses with requests. The Identifier field MUST be changed on each Request packet. The Identifier field in the Response packet MUST match the Identifier field from the corresponding request.
标识符字段是一个八位字节，有助于将响应与请求匹配。必须在每个请求数据包上更改标识符字段。响应数据包中的标识符字段必须与相应请求中的标识符字段匹配。
Length
长
The Length field is two octets and indicates the length of the EAP packet including the Code, Identifier, Length, Type, Flags, Ver, Message Length, TLS Data, and Outer TLVs fields. Octets outside the range of the Length field should be treated as Data Link Layer padding and should be ignored on reception.
长度字段是两个八位字节，表示EAP数据包的长度，包括代码、标识符、长度、类型、标志、版本、消息长度、TLS数据和外部TLV字段。长度字段范围之外的八位字节应视为数据链路层填充，在接收时应忽略。
Type
类型
55 for TEAP
技经评估组为55人
Flags
旗帜
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+
0 1 2 3 4
+-+-+-+-+-+
|L M S O R|
+-+-+-+-+-+
L Length included; set to indicate the presence of the four-octet Message Length field. It MUST be present for the first fragment of a fragmented message. It MUST NOT be present for any other message.
L包括长度；设置为指示存在四个八位字节的消息长度字段。它必须出现在片段消息的第一个片段中。对于任何其他消息，它不得出现。
M More fragments; set on all but the last fragment.
更多的碎片；设置为除最后一个片段以外的所有片段。
S TEAP start; set in a TEAP Start message sent from the server to the peer.
S技经评估组开始；在从服务器发送到对等方的TEAP启动消息中设置。
O Outer TLV length included; set to indicate the presence of the four-octet Outer TLV Length field. It MUST be present only in the initial request and response messages. If the initial message is fragmented, then it MUST be present only on the first fragment.
O包括外部TLV长度；设置为指示存在四个八位组的外部TLV长度字段。它必须仅出现在初始请求和响应消息中。如果初始消息是分段的，那么它必须仅出现在第一个片段上。
R Reserved (MUST be zero and ignored upon receipt)
R保留（必须为零并在收到时忽略）
Ver
版本
This field contains the version of the protocol. This document describes version 1 (001 in binary) of TEAP.
此字段包含协议的版本。本文件介绍技经评估组第1版（001二进制）。
Message Length
消息长度
The Message Length field is four octets and is present only if the L bit is set. This field provides the total length of the message that may be fragmented over the data fields of multiple packets.
消息长度字段为四个八位字节，仅当设置了L位时才出现。此字段提供可能在多个数据包的数据字段上分段的消息的总长度。
Outer TLV Length
外TLV长度
The Outer TLV Length field is four octets and is present only if the O bit is set. This field provides the total length of the Outer TLVs if present.
外部TLV长度字段为四个八位字节，仅当设置了O位时才存在。此字段提供外部TLV（如果存在）的总长度。
TLS Data
TLS数据
When the TLS Data field is present, it consists of an encapsulated TLS packet in TLS record format. A TEAP packet with Flags and Version fields, but with zero length TLS Data field, is used to indicate TEAP acknowledgement for either a fragmented message, a TLS Alert message, or a TLS Finished message.
当TLS数据字段存在时，它由TLS记录格式的封装TLS数据包组成。具有标志和版本字段，但具有零长度TLS数据字段的TEAP数据包用于指示片段消息、TLS警报消息或TLS完成消息的TEAP确认。
Outer TLVs
外部TLV
The Outer TLVs consist of the optional data used to help establish the TLS tunnel in TLV format. They are only allowed in the first two messages in the TEAP protocol. That is the first EAP-server-to-peer message and first peer-to-EAP-server message. The start of the Outer TLVs can be derived from the EAP Length field and Outer TLV Length field.
外部TLV包括用于帮助以TLV格式建立TLS隧道的可选数据。它们只允许出现在TEAP协议的前两条消息中。这是第一条EAP服务器到对等消息和第一条对等EAP服务器消息。外部TLV的开始可以从EAP长度字段和外部TLV长度字段中导出。
The TLVs defined here are TLV objects. The TLV objects could be used to carry arbitrary parameters between an EAP peer and EAP server within the protected TLS tunnel.
此处定义的TLV是TLV对象。TLV对象可用于在受保护的TLS隧道内的EAP对等方和EAP服务器之间传输任意参数。
The EAP peer may not necessarily implement all the TLVs supported by the EAP server. To allow for interoperability, TLVs are designed to allow an EAP server to discover if a TLV is supported by the EAP peer using the NAK TLV. The mandatory bit in a TLV indicates whether support of the TLV is required. If the peer or server does not support a TLV marked mandatory, then it MUST send a NAK TLV in the response, and all the other TLVs in the message MUST be ignored. If an EAP peer or server finds an unsupported TLV that is marked as optional, it can ignore the unsupported TLV. It MUST NOT send a NAK TLV for a TLV that is not marked mandatory. If all TLVs in a message are marked optional and none are understood by the peer, then a NAK TLV or Result TLV could be sent to the other side in order to continue the conversation.
EAP对等方不一定实现EAP服务器支持的所有TLV。为了实现互操作性，TLV被设计为允许EAP服务器发现使用NAK TLV的EAP对等方是否支持TLV。TLV中的强制位指示是否需要TLV支持。如果对等方或服务器不支持标记为强制的TLV，则它必须在响应中发送NAK TLV，并且必须忽略消息中的所有其他TLV。如果EAP对等方或服务器发现标记为可选的不受支持的TLV，则可以忽略不受支持的TLV。它不能为未标记为强制的TLV发送NAK TLV。如果消息中的所有TLV都标记为可选，并且对等方都不理解，则可以向另一方发送NAK TLV或结果TLV以继续对话。
Note that a peer or server may support a TLV with the mandatory bit set but may not understand the contents. The appropriate response to a supported TLV with content that is not understood is defined by the individual TLV specification.
请注意，对等方或服务器可能支持设置了强制位的TLV，但可能不理解其内容。单个TLV规范定义了对包含不可理解内容的受支持TLV的适当响应。
EAP implementations compliant with this specification MUST support TLV exchanges as well as the processing of mandatory/optional settings on the TLV. Implementations conforming to this specification MUST support the following TLVs:
符合本规范的EAP实施必须支持TLV交换以及TLV上强制/可选设置的处理。符合本规范的实施必须支持以下TLV：
Authority-ID TLV
授权ID TLV
Identity-Type TLV
标识类型TLV
Result TLV
结果TLV
NAK TLV
NAK TLV
Error TLV
错误TLV
Request-Action TLV
请求操作TLV
EAP-Payload TLV
EAP有效载荷TLV
Intermediate-Result TLV
中间结果TLV
Crypto-Binding TLV
加密绑定TLV
Basic-Password-Auth-Req TLV
基本密码验证请求TLV
Basic-Password-Auth-Resp TLV
基本密码验证响应TLV
TLVs are defined as described below. The fields are transmitted from left to right.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 Optional TLV
0可选TLV
1 Mandatory TLV
1强制性TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
A 14-bit field, denoting the TLV type. Allocated types include:
14位字段，表示TLV类型。分配的类型包括：
0 Unassigned
0未分配
1 Authority-ID TLV (Section 4.2.2)
1机构ID TLV（第4.2.2节）
2 Identity-Type TLV (Section 4.2.3)
2标识类型TLV（第4.2.3节）
3 Result TLV (Section 4.2.4)
3结果TLV（第4.2.4节）
4 NAK TLV (Section 4.2.5)
4 NAK TLV（第4.2.5节）
5 Error TLV (Section 4.2.6)
5错误TLV（第4.2.6节）
6 Channel-Binding TLV (Section 4.2.7)
6信道绑定TLV（第4.2.7节）
7 Vendor-Specific TLV (Section 4.2.8)
7供应商特定TLV（第4.2.8节）
8 Request-Action TLV (Section 4.2.9)
8请求行动TLV（第4.2.9节）
9 EAP-Payload TLV (Section 4.2.10)
9 EAP有效载荷TLV（第4.2.10节）
10 Intermediate-Result TLV (Section 4.2.11)
10中间结果TLV（第4.2.11节）
11 PAC TLV (Section 4.2.12)
11 PAC TLV（第4.2.12节）
12 Crypto-Binding TLV (Section 4.2.13)
12加密绑定TLV（第4.2.13节）
13 Basic-Password-Auth-Req TLV (Section 4.2.14)
13基本密码认证要求TLV（第4.2.14节）
14 Basic-Password-Auth-Resp TLV (Section 4.2.15)
14基本密码验证和TLV（第4.2.15节）
15 PKCS#7 TLV (Section 4.2.16)
15 PKCS#7 TLV（第4.2.16节）
16 PKCS#10 TLV (Section 4.2.17)
16 PKCS#10 TLV（第4.2.17节）
17 Trusted-Server-Root TLV (Section 4.2.18)
17受信任服务器根TLV（第4.2.18节）
Length
长
The length of the Value field in octets.
值字段的长度（以八位字节为单位）。
Value
价值
The value of the TLV.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
1 - Authority-ID
1-机构ID
Length
长
The Length field is two octets and contains the length of the ID field in octets.
长度字段是两个八位字节，包含ID字段的长度（以八位字节为单位）。
ID
身份证件
Hint of the identity of the server to help the peer to match the credentials available for the server. It should be unique across the deployment.
服务器标识的提示，以帮助对等方匹配服务器可用的凭据。它在整个部署中应该是唯一的。
The Identity-Type TLV allows an EAP server to send a hint to help the EAP peer select the right type of identity, for example, user or machine. TEAPv1 implementations MUST support this TLV. Only one Identity-Type TLV SHOULD be present in the TEAP request or response packet. The Identity-Type TLV request MUST come with an EAP-Payload TLV or Basic-Password-Auth-Req TLV. If the EAP peer does have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the requested type. If the Identity-Type field does not contain one of the known values or if the EAP peer does not have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the one of available identity types. If the server receives an identity type in the response that does not match the requested type, then the peer does not possess the requested credential type, and the server SHOULD proceed with authentication for the credential type proposed by the peer, proceed with requesting another credential type, or simply apply the network policy based on the configured policy, e.g., sending Result TLV with Failure.
标识类型TLV允许EAP服务器发送提示，以帮助EAP对等方选择正确的标识类型，例如用户或机器。TEAPv1实现必须支持此TLV。TEAP请求或响应数据包中只应存在一个标识类型TLV。标识类型TLV请求必须附带EAP有效负载TLV或基本密码验证请求TLV。如果EAP对等方具有与请求的标识类型相对应的标识，则对等方应使用具有请求类型的标识类型TLV进行响应。如果标识类型字段不包含已知值之一，或者EAP对等方没有与请求的标识类型对应的标识，则对等方应使用可用标识类型之一的标识类型TLV进行响应。如果服务器在响应中接收到与请求的类型不匹配的标识类型，则对等方不具有请求的凭据类型，服务器应继续验证对等方建议的凭据类型，继续请求另一个凭据类型，或者简单地根据配置的策略应用网络策略，例如，发送失败的结果TLV。
The Identity-Type 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 (Optional)
0（可选）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
2 - Identity-Type TLV
2-标识类型TLV
Length
长
2
2.
Identity-Type
身份类型
The Identity-Type field is two octets. Values include:
标识类型字段是两个八位字节。价值包括：
1 User
1用户
2 Machine
2机器
The Result TLV provides support for acknowledged success and failure messages for protected termination within TEAP. If the Status field does not contain one of the known values, then the peer or EAP server MUST treat this as a fatal error of Unexpected TLVs Exchanged. The behavior of the Result TLV is further discussed in Sections 3.3.3 and 3.6.3. A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV. The Result TLV is defined as follows:
结果TLV为TEAP内受保护终端的确认成功和失败消息提供支持。如果状态字段不包含已知值之一，则对等服务器或EAP服务器必须将其视为意外TLV交换的致命错误。第3.3.3节和第3.6.3节进一步讨论了结果TLV的行为。指示故障的结果TLV不得伴随以下TLV：NAK、EAP有效负载TLV或加密绑定TLV。结果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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
3 - Result TLV
3-结果TLV
Length
长
2
2.
Status
地位
The Status field is two octets. Values include:
状态字段是两个八位字节。价值包括：
1 Success
1成功
2 Failure
2失败
The NAK TLV allows a peer to detect TLVs that are not supported by the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV, instead a Result TLV of failure should be sent indicating failure and an Error TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows:
NAK TLV允许对等方检测其他对等方不支持的TLV。TEAP数据包可以包含0个或多个NAK TLV。NAK TLV不应与其他TLV一起使用。不得发送NAK TLV以响应包含结果TLV的消息，而应发送失败的结果TLV，指示失败，并交换意外TLV的错误TLV。NAK 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAK-Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
4 - NAK TLV
4-NAK TLV
Length
长
>=6
>=6
Vendor-Id
供应商Id
The Vendor-Id field is four octets and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0, and the low-order three octets are the Structure of Management
供应商Id字段是四个八位字节，包含不受支持的TLV的供应商Id。高阶八位组为0，低阶三位组为管理结构
Information (SMI) Network Management Private Enterprise Number of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
信息（SMI）网络管理供应商的私有企业编号（按网络字节顺序）。对于非特定于供应商的TLV，供应商Id字段必须为零。
NAK-Type
NAK型
The NAK-Type field is two octets. The field contains the type of the TLV that was not supported. A TLV of this type MUST have been included in the previous packet.
NAK类型字段是两个八位字节。该字段包含不受支持的TLV类型。此类型的TLV必须包含在前一个数据包中。
TLVs
阈限值
This field contains a list of zero or more TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs are for future extensibility to communicate why the offending TLV was determined to be unsupported.
此字段包含零个或多个TLV的列表，每个TLV不得设置强制位。这些可选的TLV是为了将来的扩展性，以传达为什么确定不支持有问题的TLV。
The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure, and the conversation is terminated as described in Section 3.6.3.
错误TLV允许EAP对等方或服务器向另一方指示错误。TEAP数据包可以包含0个或多个错误TLV。错误代码字段描述错误的类型。错误代码1-999表示成功的结果（信息性消息），1000-1999表示警告，2000-2999表示致命错误。致命错误TLV必须伴随一个结果TLV，指示失败，并且对话按照第3.6.3节的说明终止。
Many of the error codes below refer to errors in inner method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes.
下面的许多错误代码涉及内部方法处理中的错误，如果内部方法可用，则可以检索这些错误。实现必须注意错误消息不会向攻击者透露太多信息。例如，不建议使用错误消息1031（用户帐户凭据不正确），因为它允许攻击者通过区分此响应与其他响应来确定有效用户名。它只能用于故障排除目的。
The Error 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
5 - Error TLV
5-错误TLV
Length
长
4
4.
Error-Code
错误代码
The Error-Code field is four octets. Currently defined values for Error-Code include:
错误代码字段是四个八位字节。当前定义的错误代码值包括：
1 User account expires soon
1用户帐户即将到期
2 User account credential expires soon
2用户帐户凭据即将过期
3 User account authorizations change soon
3用户帐户授权即将更改
4 Clock skew detected
检测到4个时钟偏移
5 Contact administrator
5联系管理员
6 User account credentials change required
6需要更改用户帐户凭据
1001 Inner Method Error
1001内部方法错误
1002 Unspecified authentication infrastructure problem
1002未指定的身份验证基础结构问题
1003 Unspecified authentication failure
1003未指定的身份验证失败
1004 Unspecified authorization failure
1004未指定的授权失败
1005 User account credentials unavailable
1005用户帐户凭据不可用
1006 User account expired
1006用户帐户已过期
1007 User account locked: try again later
1007用户帐户已锁定：请稍后重试
1008 User account locked: admin intervention required
1008用户帐户已锁定：需要管理员干预
1009 Authentication infrastructure unavailable
1009身份验证基础架构不可用
1010 Authentication infrastructure not trusted
1010身份验证基础结构不受信任
1011 Clock skew too great
1011时钟偏移太大
1012 Invalid inner realm
1012无效的内部领域
1013 Token out of sync: administrator intervention required
1013令牌不同步：需要管理员干预
1014 Token out of sync: PIN change required
1014令牌不同步：需要更改PIN码
1015 Token revoked
1015令牌已吊销
1016 Tokens exhausted
1016个代币用完了
1017 Challenge expired
1017挑战到期
1018 Challenge algorithm mismatch
1018挑战算法不匹配
1019 Client certificate not supplied
1019未提供客户端证书
1020 Client certificate rejected
1020客户端证书被拒绝
1021 Realm mismatch between inner and outer identity
1021内部标识和外部标识之间的域不匹配
1022 Unsupported Algorithm In Certificate Signing Request
1022证书签名请求中不支持的算法
1023 Unsupported Extension In Certificate Signing Request
1023证书签名请求中不支持的扩展
1024 Bad Identity In Certificate Signing Request
1024证书签名请求中存在错误标识
1025 Bad Certificate Signing Request
1025错误的证书签名请求
1026 Internal CA Error
1026内部CA错误
1027 General PKI Error
1027一般PKI错误
1028 Inner method's channel-binding data required but not supplied
1028需要但未提供内部方法的通道绑定数据
1029 Inner method's channel-binding data did not include required information
1029内部方法的通道绑定数据未包含所需信息
1030 Inner method's channel binding failed
1030内部方法的通道绑定失败
1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
1031用户帐户凭据不正确[不建议使用]
2001 Tunnel Compromise Error
2001隧道折衷误差
2002 Unexpected TLVs Exchanged
2002年意外TLV交换
The Channel-Binding TLV provides a mechanism for carrying channel-binding data from the peer to the EAP server and a channel-binding response from the EAP server to the peer as described in [RFC6677]. TEAPv1 implementations MAY support this TLV, which cannot be responded to with a NAK TLV. If the Channel-Binding data field does not contain one of the known values or if the EAP server does not support this TLV, then the server MUST ignore the value. The Channel-Binding TLV is defined as follows:
通道绑定TLV提供了一种机制，用于将通道绑定数据从对等端传送到EAP服务器，以及将通道绑定响应从EAP服务器传送到对等端，如[RFC6677]所述。TEAPv1实现可能支持此TLV，不能用NAK TLV响应。如果通道绑定数据字段不包含已知值之一，或者EAP服务器不支持此TLV，则服务器必须忽略该值。通道绑定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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 (Optional)
0（可选）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
6 - Channel-Binding TLV
6通道绑定TLV
Length
长
variable
变量
Data
数据
The data field contains a channel-binding message as defined in Section 5.3 of [RFC6677].
数据字段包含[RFC6677]第5.3节中定义的通道绑定消息。
The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV attribute can contain one or more TLVs, referred to as Vendor TLVs. The TLV type of a Vendor-TLV is defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV belong to the same vendor. There can be multiple Vendor-Specific TLVs from different vendors in the same message. Error handling in the Vendor TLV could use the vendor's own specific error-handling mechanism or use the standard TEAP error codes defined.
特定于供应商的TLV可用于允许供应商支持其自身不适合一般用途的扩展属性。特定于供应商的TLV属性可以包含一个或多个TLV，称为供应商TLV。供应商TLV的TLV类型由供应商定义。单个供应商特定TLV内的所有供应商TLV属于同一供应商。同一消息中可能有来自不同供应商的多个供应商特定TLV。供应商TLV中的错误处理可以使用供应商自己的特定错误处理机制，或者使用定义的标准TEAP错误代码。
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional. If the Vendor-Specific TLV is marked as mandatory, then it is expected that the receiving side needs to recognize the vendor ID, parse all Vendor TLVs within, and deal with error handling within the Vendor-Specific TLV as defined by the vendor.
供应商TLV可以是可选的，也可以是强制性的。随结果TLV一起发送的供应商TLV必须标记为可选。如果特定于供应商的TLV被标记为强制性，则接收方需要识别供应商ID，解析其中的所有供应商TLV，并处理供应商定义的特定于供应商的TLV中的错误处理。
The Vendor-Specific 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 or 1
0或1
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
7 - Vendor-Specific TLV
7-供应商特定TLV
Length
长
4 + cumulative length of all included Vendor TLVs
4+包括的所有供应商TLV的累计长度
Vendor-Id
供应商Id
The Vendor-Id field is four octets and contains the Vendor-Id of the TLV. The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Number of the Vendor in network byte order.
供应商Id字段是四个八位字节，包含TLV的供应商Id。高阶八位字节为0，低阶三位八位字节为供应商的SMI网络管理私有企业编号，按网络字节顺序排列。
Vendor TLVs
供应商TLV
This field is of indefinite length. It contains Vendor-Specific TLVs, in a format defined by the vendor.
此字段的长度不定。它包含特定于供应商的TLV，格式由供应商定义。
The Request-Action TLV MAY be sent by both the peer and the server in response to a successful or failed Result TLV. It allows the peer or server to request the other side to negotiate additional EAP methods or process TLVs specified in the response packet. The receiving side MUST process this TLV. The processing for the TLV is as follows:
请求操作TLV可由对等方和服务器发送，以响应成功或失败的结果TLV。它允许对等方或服务器请求另一方协商响应数据包中指定的其他EAP方法或处理TLV。接收方必须处理该TLV。TLV的处理如下所示：
The receiving entity MAY choose to process any of the TLVs that are included in the message.
接收实体可以选择处理包括在消息中的任何tlv。
If the receiving entity chooses NOT to process any TLV in the list, then it sends back a Result TLV with the same code in the Status field of the Request-Action TLV.
如果接收实体选择不处理列表中的任何TLV，则它将返回一个结果TLV，该结果TLV在请求操作TLV的状态字段中具有相同的代码。
If multiple Request-Action TLVs are in the request, the session can continue if any of the TLVs in any Request-Action TLV are processed.
如果请求中存在多个请求操作TLV，则如果处理了任何请求操作TLV中的任何TLV，则会话可以继续。
If multiple Request-Action TLVs are in the request and none of them is processed, then the most fatal status should be used in the Result TLV returned. If a status code in the Request-Action TLV is not understood by the receiving entity, then it should be treated as a fatal error.
如果请求中存在多个请求操作TLV，且未处理其中任何一个，则应在返回的结果TLV中使用最致命的状态。如果接收实体不理解请求操作TLV中的状态代码，则应将其视为致命错误。
After processing the TLVs or EAP method in the request, another round of Result TLV exchange would occur to synchronize the final status on both sides.
在处理请求中的TLV或EAP方法后，将进行另一轮结果TLV交换，以同步双方的最终状态。
The peer or the server MAY send multiple Request-Action TLVs to the other side. Two Request-Action TLVs MUST NOT occur in the same TEAP packet if they have the same Status value. The order of processing multiple Request-Action TLVs is implementation dependent. If the receiving side processes the optional (non-fatal) items first, it is possible that the fatal items will disappear at a later time. If the receiving side processes the fatal items first, the communication time will be shorter.
对等方或服务器可以向另一方发送多个请求操作TLV。如果两个请求操作TLV具有相同的状态值，则它们不得出现在同一TEAP数据包中。处理多个请求操作TLV的顺序取决于实现。如果接收方首先处理可选（非致命）项目，则致命项目可能会在以后消失。如果接收方首先处理致命项目，则通信时间将更短。
The peer or the server MAY return a new set of Request-Action TLVs after one or more of the requested items has been processed and the other side has signaled it wants to end the EAP conversation.
对等方或服务器可以在一个或多个请求项已被处理且另一方发出想要结束EAP对话的信号后返回一组新的请求操作TLV。
The Request-Action 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Action | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Action | TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
8 - Request-Action TLV
8-请求操作TLV
Length
长
2 + cumulative length of all included TLVs
2+所有包含TLV的累积长度
Status
地位
The Status field is one octet. This indicates the result if the server does not process the action requested by the peer. Values include:
状态字段是一个八位字节。这表示服务器未处理对等方请求的操作时的结果。价值包括：
1 Success
1成功
2 Failure
2失败
Action
行动
The Action field is one octet. Values include:
动作字段是一个八位字节。价值包括：
1 Process-TLV
1工艺TLV
2 Negotiate-EAP
2谈判EAP
TLVs
阈限值
This field is of indefinite length. It contains TLVs that the peer wants the server to process.
此字段的长度不定。它包含对等方希望服务器处理的TLV。
To allow piggybacking an EAP request or response with other TLVs, the EAP-Payload TLV is defined, which includes an encapsulated EAP packet and a list of optional TLVs. The optional TLVs are provided for future extensibility to provide hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. The EAP-Payload TLV is defined as follows:
为了允许与其他TLV搭载EAP请求或响应，定义了EAP有效负载TLV，其中包括封装的EAP数据包和可选TLV列表。提供可选TLV是为了将来的扩展性，以提供有关当前EAP身份验证的提示。消息中只允许一个EAP有效负载TLV。EAP有效载荷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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
9 - EAP-Payload TLV
9-EAP有效载荷TLV
Length
长
length of embedded EAP packet + cumulative length of additional TLVs
嵌入式EAP数据包的长度+附加TLV的累积长度
EAP packet
EAP数据包
This field contains a complete EAP packet, including the EAP header (Code, Identifier, Length, Type) fields. The length of this field is determined by the Length field of the encapsulated EAP packet.
此字段包含完整的EAP数据包，包括EAP标头（代码、标识符、长度、类型）字段。此字段的长度由封装的EAP数据包的长度字段确定。
TLVs
阈限值
This (optional) field contains a list of TLVs associated with the EAP packet field. The TLVs MUST NOT have the mandatory bit set. The total length of this field is equal to the Length field of the EAP-Payload TLV, minus the Length field in the EAP header of the EAP packet field.
此（可选）字段包含与EAP数据包字段关联的TLV列表。TLV不得设置强制位。此字段的总长度等于EAP有效负载TLV的长度字段减去EAP数据包字段的EAP报头中的长度字段。
The Intermediate-Result TLV provides support for acknowledged intermediate Success and Failure messages between multiple inner EAP methods within EAP. An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV. The optional TLVs associated with this TLV are provided for future extensibility to provide hints about the current result. The Intermediate-Result TLV is defined as follows:
中间结果TLV支持EAP中多个内部EAP方法之间已确认的中间成功和失败消息。指示成功的中间结果TLV必须伴有加密绑定TLV。提供与此TLV关联的可选TLV用于将来的扩展，以提供有关当前结果的提示。中间结果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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
10 - Intermediate-Result TLV
10-中间结果TLV
Length
长
2 + cumulative length of the embedded associated TLVs
2+嵌入式相关TLV的累积长度
Status
地位
The Status field is two octets. Values include:
状态字段是两个八位字节。价值包括：
1 Success
1成功
2 Failure
2失败
TLVs
阈限值
This field is of indeterminate length and contains zero or more of the TLVs associated with the Intermediate Result TLV. The TLVs in this field MUST NOT have the mandatory bit set.
此字段的长度不确定，并且包含零个或多个与中间结果TLV关联的TLV。此字段中的TLV不得设置强制位。
The PAC TLV provides support for provisioning the Protected Access Credential (PAC). 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提供对设置受保护访问凭据（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 or 1
0或1
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
1-PAC密钥
2 - PAC-Opaque
2-PAC不透明
3 - PAC-Lifetime
3-PAC寿命
4 - A-ID
4-A-ID
5 - I-ID
5-I-ID
6 - Reserved
6-保留
7 - A-ID-Info
7-A-ID-Info
8 - PAC-Acknowledgement
8-PAC确认
9 - PAC-Info
9-PAC信息
10 - PAC-Type
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 that is 48 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中。密钥是一个随机生成的八位字节字符串，长度为48个八位字节。此密钥的生成器是凭证的颁发者，凭证由授权标识符（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 the length of the key.
2-表示键长度的八位字节长度。
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.
只要服务器希望发布或续订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
PAC不透明对对等方来说是不透明的，因此对等方不得试图解释它。已由服务器发出PAC的对等方存储该数据，并根据其PAC类型将其显示回服务器。隧道PAC在[RFC5077]中定义的ClientHello SessionTicket扩展字段中使用。如果一个对等方拥有多个服务器向其发布的不透明数据，那么它将根据a-ID分别存储每个服务器发布的数据。这一要求允许对等方将每个不透明数据作为独立的PAC配对进行维护和使用，PAC密钥映射到由a-ID标识的PAC不透明。由于PAC密钥和PAC不透明之间存在一对一的对应关系，对等方确定PAC密钥
and corresponding PAC-Opaque based on the A-ID provided in the TEAP/Start message and the A-ID provided in the PAC-Info when it was provisioned with a PAC-Opaque.
以及基于TEAP/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 field 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.12.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.12.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 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 Authority-ID the server used to establish the tunnel. One method for generating the A-ID is to use a high-quality random number generator to generate a random number. An alternate method would be to take the hash of the public key or public key certificate belonging to a server represented by the A-ID.
A-ID是颁发PAC的机构的身份。A-ID在所有发布服务器上都是唯一的，以避免名称空间冲突。对等方使用A-ID来确定使用哪个PAC。A-ID被视为不透明的八位字节字符串。此属性必须包含在PAC Info属性中。A-ID必须与用于建立隧道的服务器的授权ID匹配。生成A-ID的一种方法是使用高质量随机数生成器生成随机数。另一种方法是获取属于由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 authentication or from the client-side authentication during tunnel establishment if inner authentication is not used. The server employs the I-ID in the TEAP Phase 2 conversation to validate that the same peer identity used to execute TEAP Phase 1 is also used in at minimum one inner authentication in TEAP Phase 2. If the server is enforcing the I-ID validation on the inner authentication, then the I-ID MUST be included in the PAC-Info, to enable the peer to also enforce a unique PAC for each unique user. If the I-ID is missing from the PAC-Info, it
启动器标识符（I-ID）是与凭据关联的对等身份。如果未使用内部身份验证，则此标识将从内部身份验证或隧道建立期间的客户端身份验证中派生。服务器在TEAP第2阶段对话中使用I-ID来验证用于执行TEAP第1阶段的相同对等身份是否也用于TEAP第2阶段中的至少一个内部身份验证。如果服务器正在对内部身份验证强制执行I-ID验证，则I-ID必须包含在PAC信息中，以使对等方也能够为每个唯一的用户强制执行唯一的PAC。如果PAC信息中缺少I-ID，则
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策略。
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
1-成功
2 - Failure
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 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
1-隧道PAC
The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment.
加密绑定TLV用于证明对等方和服务器都参与了隧道的建立和身份验证序列。它还提供了在TLS隧道建立之前交换的TEAP类型、协商版本和外部TLV的验证。
The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether there is an inner EAP method authentication or not. It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods, before proceeding with another inner EAP method. The Crypto-Binding TLV is valid only if the following checks pass:
无论是否存在内部EAP方法身份验证，在最终结果TLV交换之前，必须交换和验证加密绑定TLV。它必须包含在中间结果TLV中，以便在一系列EAP方法中的每个成功EAP方法之后执行加密绑定，然后再继续执行另一个内部EAP方法。只有通过以下检查，加密绑定TLV才有效：
o The Crypto-Binding TLV version is supported.
o 支持加密绑定TLV版本。
o The MAC verifies correctly.
o MAC验证正确。
o The received version in the Crypto-Binding TLV matches the version sent by the receiver during the EAP version negotiation.
o 加密绑定TLV中接收到的版本与EAP版本协商期间接收方发送的版本匹配。
o The subtype is set to the correct value.
o 子类型设置为正确的值。
If any of the above checks fails, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.6.3
如果上述任何检查失败，则TLV无效。无效的加密绑定TLV是一个致命错误，按照第3.6.3节的说明进行处理
The Crypto-Binding 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EMSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ EMSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MSK Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
Mandatory, set to one (1)
必须，设置为一（1）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
12 - Crypto-Binding TLV
12-加密绑定TLV
Length
长
76
76
Reserved
含蓄的
Reserved, set to zero (0)
保留，设置为零（0）
Version
版本
The Version field is a single octet, which is set to the version of Crypto-Binding TLV the TEAP method is using. For an implementation compliant with this version of TEAP, the version number MUST be set to one (1).
版本字段是一个八位字节，设置为TEAP方法使用的加密绑定TLV的版本。对于符合本版本技经评估组的实施，版本号必须设置为一（1）。
Received Ver
收到的版本
The Received Ver field is a single octet and MUST be set to the TEAP version number received during version negotiation. Note that this field only provides protection against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides.
Received Ver字段是一个八位字节，必须设置为版本协商期间收到的TEAP版本号。请注意，此字段仅提供针对降级攻击的保护，其中双方都需要支持此TLV的EAP版本。
Flags
旗帜
The Flags field is four bits. Defined values include
标志字段为四位。定义的值包括
1 EMSK Compound MAC is present
存在1个EMSK复合MAC
2 MSK Compound MAC is present
存在2个MSK复合MAC
3 Both EMSK and MSK Compound MAC are present
3 EMSK和MSK复合MAC均存在
Sub-Type
子类型
The Sub-Type field is four bits. Defined values include
子类型字段为四位。定义的值包括
0 Binding Request
0绑定请求
1 Binding Response
1结合反应
Nonce
暂时
The Nonce field is 32 octets. It contains a 256-bit nonce that is temporally unique, used for Compound MAC key derivation at each end. The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1).
Nonce字段是32个八位字节。它包含一个在时间上唯一的256位nonce，用于每一端的复合MAC密钥派生。请求中的nonce必须将其最低有效位设置为零（0），响应中的nonce必须与请求nonce具有相同的值，但最低有效位必须设置为一（1）。
EMSK Compound MAC
EMSK复合MAC
The EMSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 5.3.
EMSK复合MAC字段为20个八位字节。这可以是服务器MAC（B1_MAC）或客户端MAC（B2_MAC）。第5.3节描述了MAC的计算。
MSK Compound MAC
MSK复合MAC
The MSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 5.3.
MSK复合MAC字段为20个八位字节。这可以是服务器MAC（B1_MAC）或客户端MAC（B2_MAC）。第5.3节描述了MAC的计算。
The Basic-Password-Auth-Req TLV is used by the authentication server to request a username and password from the peer. It contains an optional user prompt message for the request. The peer is expected to obtain the username and password and send them in a Basic-Password-Auth-Resp TLV.
身份验证服务器使用基本密码Auth Req TLV从对等方请求用户名和密码。它包含请求的可选用户提示消息。对等方应获取用户名和密码，并以基本密码验证响应TLV发送它们。
The Basic-Password-Auth-Req TLV is defined as follows:
基本密码Auth Req 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 (Optional)
0（可选）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
13 - Basic-Password-Auth-Req TLV
13-基本密码验证请求TLV
Length
长
variable
变量
Prompt
促使
optional user prompt message in UTF-8 [RFC3629] format
UTF-8[RFC3629]格式的可选用户提示消息
The Basic-Password-Auth-Resp TLV is used by the peer to respond to a Basic-Password-Auth-Req TLV with a username and password. The TLV contains a username and password. The username and password are in UTF-8 [RFC3629] format.
对等方使用基本密码验证响应TLV以用户名和密码响应基本密码验证请求TLV。TLV包含用户名和密码。用户名和密码为UTF-8[RFC3629]格式。
The Basic-Password-Auth-Resp 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
M
0 (Optional)
0（可选）
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
14 - Basic-Password-Auth-Resp TLV
14-基本密码验证和TLV
Length
长
variable
变量
Userlen
乌瑟伦
Length of Username field in octets
用户名字段的长度（以八位字节为单位）
Username
用户名
Username in UTF-8 [RFC3629] format
UTF-8[RFC3629]格式的用户名
Passlen
帕斯伦
Length of Password field in octets
密码字段的长度（以八位字节为单位）
Password
暗语
Password in UTF-8 [RFC3629] format
UTF-8[RFC3629]格式的密码
The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to the peer. The format consists of a certificate or certificate chain in binary DER encoding [X.690] in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652].
EAP服务器使用PKCS#7 TLV向对等方传递证书。该格式由二进制DER编码[X.690]的证书或证书链组成，该证书或证书链位于[RFC5652]中定义的仅限证书的PKCS#7签名数据内容中。
When used in response to a Trusted-Server-Root TLV request from the peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate enrollment request from the peer, the EAP server MUST send the PKCS#7 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP implementations that support the Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the certificates in a PKCS#7 TLV are in any order.
当用于响应来自对等方的受信任服务器根TLV请求时，EAP服务器必须在受信任服务器根TLV内发送PKCS#7 TLV。当用于响应来自对等方的PKCS#10证书注册请求时，EAP服务器必须发送PKCS#7 TLV，而不发送受信任的服务器根TLV。PKCS#7 TLV始终标记为可选，不能用NAK TLV响应。支持受信任服务器根TLV或PKCS#10 TLV的TEAP实现必须支持此TLV。对等方不得假设PKCS#7 TLV中的证书是任何顺序的。
TEAP servers MAY return self-signed certificates. Peers that handle self-signed certificates or trust anchors MUST NOT implicitly trust these certificates merely due to their presence in the certificate bag. Note: Peers are advised to take great care in deciding whether to use a received certificate as a trust anchor. The authenticated nature of the tunnel in which a PKCS#7 bag is received can provide a level of authenticity to the certificates contained therein. Peers are advised to take into account the implied authority of the EAP server and to constrain the trust it can achieve through the trust anchor received in a PKCS#7 TLV.
TEAP服务器可能返回自签名证书。处理自签名证书或信任锚的对等方不能仅仅因为证书包中存在这些证书而隐式信任这些证书。注意：建议对等方在决定是否将收到的证书用作信任锚定时非常小心。接收PKCS#7包的隧道的认证性质可以为其中包含的证书提供一定程度的真实性。建议对等方考虑EAP服务器的隐含权限，并限制其通过PKCS#7 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型
15 - PKCS#7 TLV
15-PKCS#7 TLV
Length
长
The length of the PKCS#7 Data field.
PKCS#7数据字段的长度。
PKCS#7 Data
PKCS#7数据
This field contains the DER-encoded X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.
此字段包含DER编码的X.509证书或仅证书PKCS#7 SignedData消息中的证书链。
The PKCS#10 TLV is used by the peer to initiate the "simple PKI" Request/Response from [RFC5272]. The format of the request is as specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always marked as optional, which cannot be responded to with a NAK TLV.
对等方使用PKCS#10 TLV从[RFC5272]发起“简单PKI”请求/响应。请求的格式如[RFC4945]第6.4节所述。PKCS#10 TLV始终标记为可选，不能用NAK TLV响应。
The PKCS#10 TLV is defined as follows:
PKCS#10 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#10 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#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
M
0 - Optional TLV
0-可选TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
16 - PKCS#10 TLV
16-PKCS#10 TLV
Length
长
The length of the PKCS#10 Data field.
PKCS#10数据字段的长度。
PKCS#10 Data
PKCS#10数据
This field contains the DER-encoded PKCS#10 certificate request.
此字段包含DER编码的PKCS#10证书请求。
Trusted-Server-Root TLV facilitates the request and delivery of a trusted server root certificate. The Trusted-Server-Root TLV can be exchanged in regular TEAP authentication mode or provisioning mode. The Trusted-Server-Root TLV is always marked as optional and cannot be responded to with a Negative Acknowledgement (NAK) TLV. The Trusted-Server-Root TLV MUST only be sent as an Inner TLV (inside the protection of the tunnel).
受信任的服务器根TLV有助于请求和传递受信任的服务器根证书。可在常规TEAP身份验证模式或配置模式下交换受信任的服务器根TLV。受信任的服务器根TLV始终标记为可选，并且无法使用否定确认（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 Trusted-Server-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 the Trusted-Server-Root TLV. The EAP server MAY also choose not to honor the request.
对等方确定已成功验证EAP服务器并验证加密绑定TLV后，可发送一个或多个受信任服务器根TLV（标记为可选），以从EAP服务器请求受信任服务器根证书。EAP服务器可以在受信任的服务器根TLV内发送一个或多个具有公钥加密系统#7（PKCS#7）TLV的根证书。EAP服务器也可以选择不接受该请求。
The Trusted-Server-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 Trusted-Server-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 Trusted-Server-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.
如果受信任服务器根TLV凭据格式包含对等方未知的值，则EAP对等方应忽略TLV。
The Trusted-Server-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 - Optional TLV
0-可选TLV
R
R
Reserved, set to zero (0)
保留，设置为零（0）
TLV Type
TLV型
17 - Trusted-Server-Root TLV
17-受信任的服务器根TLV
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请求服务器信任根时，对等方可能会将此字段留空。
To save round trips, multiple TLVs can be sent in a single TEAP packet. However, multiple EAP Payload TLVs, multiple Basic Password Authentication TLVs, or an EAP Payload TLV with a Basic Password Authentication TLV within one single TEAP packet is not supported in this version and MUST NOT be sent. If the peer or EAP server
为了节省往返，可以在一个TEAP数据包中发送多个TLV。但是，此版本不支持多个EAP有效负载TLV、多个基本密码验证TLV或在一个TEAP数据包内具有基本密码验证TLV的EAP有效负载TLV，因此不得发送。如果是对等服务器或EAP服务器
receives multiple EAP Payload TLVs, then it MUST terminate the connection with the Result TLV. The order of TLVs in TEAP does not matter, except one should always process the Identity-Type TLV before processing the EAP TLV or Basic Password Authentication TLV as the Identity-Type TLV is a hint to the type of identity that is to be authenticated.
接收多个EAP有效负载TLV，然后必须使用结果TLV终止连接。技经评估组中TLV的顺序无关紧要，但在处理EAP TLV或基本密码认证TLV之前，应始终处理标识类型TLV，因为标识类型TLV是对待认证标识类型的提示。
The following define the meaning of the table entries in the sections below:
以下各节定义了表格条目的含义：
0 This TLV MUST NOT be present in the message.
0此TLV不能出现在消息中。
0+ Zero or more instances of this TLV MAY be present in the message.
消息中可能存在0+零个或多个此TLV实例。
0-1 Zero or one instance of this TLV MAY be present in the message.
0-1消息中可能存在此TLV的零个或一个实例。
1 Exactly one instance of this TLV MUST be present in the message.
1消息中必须正好存在此TLV的一个实例。
The following table provides a guide to which TLVs may be included in the TEAP packet outside the TLS channel, which kind of packets, and in what quantity:
下表提供了关于哪些TLV可以包括在TLS信道之外的TEAP数据包中、哪些类型的数据包以及数量的指南：
Request Response Success Failure TLVs 0-1 0 0 0 Authority-ID 0-1 0-1 0 0 Identity-Type 0+ 0+ 0 0 Vendor-Specific
请求-响应成功失败TLVs 0-1 0 0 0 0权限ID 0-1 0-1 0 0身份类型0+0+0 0特定于供应商
Outer TLVs MUST be marked as optional. Vendor-TLVs inside Vendor-Specific TLV MUST be marked as optional when included in Outer TLVs. Outer TLVs MUST NOT be included in messages after the first two TEAP messages sent by peer and EAP-server respectively. That is the first EAP-server-to-peer message and first peer-to-EAP-server message. If the message is fragmented, the whole set of messages is counted as one message. If Outer TLVs are included in messages after the first two TEAP messages, they MUST be ignored.
外部TLV必须标记为可选。当包含在外部TLV中时，供应商特定TLV内的供应商TLV必须标记为可选。外部TLV不得包含在对等和EAP服务器分别发送的前两条TEAP消息之后的消息中。这是第一条EAP服务器到对等消息和第一条对等EAP服务器消息。如果消息是分段的，则整个消息集将计为一条消息。如果前两条TEAP消息之后的消息中包含外部TLV，则必须忽略它们。
The following table provides a guide to which Inner TLVs may be encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in what quantity. The messages are as follows: Request is a TEAP Request, Response is a TEAP Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.
下表提供了TEAP第2阶段中哪些内部TLV可以封装在TLS中、封装在哪种类型的数据包中以及封装数量的指南。消息如下：请求是TEAP请求，响应是TEAP响应，成功是包含成功结果TLV的消息，失败是包含失败结果TLV的消息。
Request Response Success Failure TLVs
0-1 0-1 0 0 Identity-Type
0-1 0-1 1 1 Result
0+ 0+ 0 0 NAK
0+ 0+ 0+ 0+ Error
0-1 0-1 0 0 Channel-Binding
0+ 0+ 0+ 0+ Vendor-Specific
0+ 0+ 0+ 0+ Request-Action
0-1 0-1 0 0 EAP-Payload
0-1 0-1 0-1 0-1 Intermediate-Result
0+ 0+ 0+ 0 PAC TLV
0-1 0-1 0-1 0-1 Crypto-Binding
0-1 0 0 0 Basic-Password-Auth-Req
0 0-1 0 0 Basic-Password-Auth-Resp
0-1 0 0-1 0 PKCS#7
0 0-1 0 0 PKCS#10
0-1 0-1 0-1 0 Trusted-Server-Root
Request Response Success Failure TLVs
0-1 0-1 0 0 Identity-Type
0-1 0-1 1 1 Result
0+ 0+ 0 0 NAK
0+ 0+ 0+ 0+ Error
0-1 0-1 0 0 Channel-Binding
0+ 0+ 0+ 0+ Vendor-Specific
0+ 0+ 0+ 0+ Request-Action
0-1 0-1 0 0 EAP-Payload
0-1 0-1 0-1 0-1 Intermediate-Result
0+ 0+ 0+ 0 PAC TLV
0-1 0-1 0-1 0-1 Crypto-Binding
0-1 0 0 0 Basic-Password-Auth-Req
0 0-1 0 0 Basic-Password-Auth-Resp
0-1 0 0-1 0 PKCS#7
0 0-1 0 0 PKCS#10
0-1 0-1 0-1 0 Trusted-Server-Root
NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional.
注：随结果TLV一起发送的供应商TLV（包括在供应商特定TLV中）必须标记为可选。
For key derivation and crypto-binding, TEAP uses the Pseudorandom Function (PRF) and MAC algorithms negotiated in the underlying TLS session. Since these algorithms depend on the TLS version and ciphersuite, TEAP implementations need a mechanism to determine the version and ciphersuite in use for a particular session. The implementation can then use this information to determine which PRF and MAC algorithm to use.
对于密钥推导和加密绑定，TEAP使用在底层TLS会话中协商的伪随机函数（PRF）和MAC算法。由于这些算法依赖于TLS版本和密码套件，TEAP实现需要一种机制来确定特定会话使用的版本和密码套件。然后，实现可以使用该信息来确定使用哪个PRF和MAC算法。
With TEAPv1, the TLS master secret is generated as specified in TLS. If a PAC is used, then the master secret is obtained as described in [RFC5077].
使用TEAPv1，TLS主密钥将按照TLS中的指定生成。如果使用PAC，则按照[RFC5077]中的说明获取主密钥。
TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to derive the session_key_seed. The label used in the derivation is "EXPORTER: teap session key seed". The length of the session key seed material is 40 octets. No context data is used in the export process.
TEAPv1使用[RFC5705]中定义的TLS键控材质导出器来导出会话密钥种子。派生中使用的标签是“导出器：teap会话密钥种子”。会话密钥种子材料的长度为40个八位字节。导出过程中未使用上下文数据。
The session_key_seed is used by the TEAP authentication Phase 2 conversation to both cryptographically bind the inner method(s) to the tunnel as well as generate the resulting TEAP session keys. The other TLS keying materials are derived and used as defined in [RFC5246].
TEAP身份验证阶段2对话使用会话密钥种子以加密方式将内部方法绑定到隧道，并生成生成的TEAP会话密钥。其他TLS键控材料按照[RFC5246]中的定义衍生和使用。
The session_key_seed derived as part of TEAP Phase 2 is used in TEAP Phase 2 to generate an Intermediate Compound Key (IMCK) used to verify the integrity of the TLS tunnel after each successful inner authentication and in the generation of Master Session Key (MSK) and Extended Master Session Key (EMSK) defined in [RFC3748]. Note that the IMCK MUST be recalculated after each successful inner EAP method.
TEAP第2阶段中衍生的会话密钥种子用于TEAP第2阶段中生成中间复合密钥（IMCK），用于在每次成功内部身份验证后以及在生成[RFC3748]中定义的主会话密钥（MSK）和扩展主会话密钥（EMSK）时验证TLS隧道的完整性。注意，在每次成功的内部EAP方法之后，必须重新计算IMCK。
The first step in these calculations is the generation of the base compound key, IMCK[n] from the session_key_seed, and any session keys derived from the successful execution of nth inner EAP methods. The inner EAP method(s) may provide Inner Method Session Keys (IMSKs), IMSK1..IMSKn, corresponding to inner method 1 through n.
这些计算的第一步是从会话密钥种子生成基本复合密钥IMCK[n]，以及从成功执行第n个内部EAP方法派生的任何会话密钥。内部EAP方法可以提供内部方法会话密钥（imsk），IMSK1..IMSKn，对应于内部方法1到n。
If an inner method supports export of an Extended Master Session Key (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in [RFC5295]. The usage label used is "TEAPbindkey@ietf.org", and the length is 64 octets. Optional data parameter is not used in the derivation.
如果内部方法支持导出扩展主会话密钥（EMSK），则应根据[RFC5295]中的定义从EMSK派生IMSK。使用的用法标签为“TEAPbindkey@ietf.org，长度为64个八位字节。派生中未使用可选数据参数。
IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" | "\0" | 64)
IMSK=TLS-PRF（EMSK）的前32个八位字节TEAPbindkey@ietf.org" | "\0" | 64)
where "|" denotes concatenation, EMSK is the EMSK from the inner method, "TEAPbindkey@ietf.org" consists the ASCII value for the label "TEAPbindkey@ietf.org" (without quotes), "\0" = is a NULL octet (0x00 in hex), length is the 2-octet unsigned integer in network byte order, and TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].
其中“|”表示串联，EMSK是来自内部方法的EMSKTEAPbindkey@ietf.org“包含标签的ASCII值”TEAPbindkey@ietf.org“（不带引号），“\0”=是一个空八位字节（十六进制中的0x00），长度是网络字节顺序中的2个八位无符号整数，TLS-PRF是作为TLS握手的一部分协商的PRF[RFC5246]。
If an inner method does not support export of an Extended Master Session Key (EMSK), then IMSK is the MSK of the inner method. The MSK is truncated at 32 octets if it is longer than 32 octets or padded to a length of 32 octets with zeros if it is less than 32 octets.
如果内部方法不支持导出扩展主会话密钥（EMSK），则IMSK是内部方法的MSK。如果MSK的长度大于32个八位字节，则将其截断为32个八位字节；如果MSK的长度小于32个八位字节，则将其填充为32个八位字节，并加上零。
However, it's possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place.
但是，对等端和服务器端可能不具备导出EMSK的相同能力。为了在防止降级攻击的同时保持最大的灵活性，以下机制已就位。
On the sender of the Crypto-Binding TLV side:
在加密绑定TLV端的发送方：
If the EMSK is not available, then the sender computes the Compound MAC using the MSK of the inner method.
如果EMSK不可用，则发送方使用内部方法的MSK计算复合MAC。
If the EMSK is available and the sender's policy accepts MSK-based MAC, then the sender computes two Compound MAC values. The first is computed with the EMSK. The second one is computed using the MSK. Both MACs are then sent to the other side.
如果EMSK可用且发送方的策略接受基于MSK的MAC，则发送方计算两个复合MAC值。第一个是使用EMSK计算的。第二个是使用MSK计算的。然后，两个MAC都被发送到另一端。
If the EMSK is available but the sender's policy does not allow downgrading to MSK-generated MAC, then the sender SHOULD only send EMSK-based MAC.
如果EMSK可用，但发送方的策略不允许降级到MSK生成的MAC，则发送方应仅发送基于EMSK的MAC。
On the receiver of the Crypto-Binding TLV side:
在加密绑定TLV端的接收器上：
If the EMSK is not available and an MSK-based Compound MAC was sent, then the receiver validates the Compound MAC and sends back an MSK-based Compound MAC response.
如果EMSK不可用并且发送了基于MSK的复合MAC，则接收机验证复合MAC并发回基于MSK的复合MAC响应。
If the EMSK is not available and no MSK-based Compound MAC was sent, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error.
如果EMSK不可用且未发送基于MSK的复合MAC，则接收器将处理无效的加密绑定TLV，并出现致命错误。
If the EMSK is available and an EMSK-based Compound MAC was sent, then the receiver validates it and creates a response Compound MAC using the EMSK.
如果EMSK可用并且发送了基于EMSK的复合MAC，则接收机验证它并使用EMSK创建响应复合MAC。
If the EMSK is available but no EMSK-based Compound MAC was sent and its policy accepts MSK-based MAC, then the receiver validates it using the MSK and, if successful, generates and returns an MSK-based Compound MAC.
如果EMSK可用，但未发送基于EMSK的复合MAC，且其策略接受基于MSK的MAC，则接收方使用MSK对其进行验证，如果成功，则生成并返回基于MSK的复合MAC。
If the EMSK is available but no EMSK Compound MAC was sent and its policy does not accept MSK-based MAC, then the receiver handles like an invalid Crypto-Binding TLV with a fatal error.
如果EMSK可用，但没有发送EMSK复合MAC，且其策略不接受基于MSK的MAC，则接收方将处理无效的加密绑定TLV，并出现致命错误。
If the ith inner method does not generate an EMSK or MSK, then IMSKi is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method fails, then it is not included in this calculation. The derivation of S-IMCK is as follows:
如果第i个内部方法不生成EMSK或MSK，则IMSKi设置为零（例如，MSKi=0x00s的32个八位字节）。如果内部方法失败，则不包括在该计算中。S-IMCK的推导如下：
S-IMCK[0] = session_key_seed For j = 1 to n-1 do IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) S-IMCK[j] = first 40 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j]
S-IMCK[0]=会话密钥\u种子，用于j=1到n-1执行IMCK[j]=TLS-PRF（S-IMCK[j-1]，“内部方法复合密钥”，IMSK[j]，60）S-IMCK[j]=IMCK[j]的前40个八位组CMK[j]=IMCK[j]的最后20个八位组
where TLS-PRF is the PRF negotiated as part of TLS handshake [RFC5246].
其中TLS-PRF是作为TLS握手的一部分协商的PRF[RFC5246]。
For authentication methods that generate keying material, further protection against man-in-the-middle attacks is provided through cryptographically binding keying material established by both TEAP Phase 1 and TEAP Phase 2 conversations. After each successful inner EAP authentication, EAP EMSK and/or MSKs are cryptographically combined with key material from TEAP Phase 1 to generate a Compound Session Key (CMK). The CMK is used to calculate the Compound MAC as part of the Crypto-Binding TLV described in Section 4.2.13, which helps provide assurance that the same entities are involved in all communications in TEAP. During the calculation of the Compound MAC, the MAC field is filled with zeros.
对于生成密钥材料的认证方法，通过TEAP第1阶段和TEAP第2阶段对话建立的加密绑定密钥材料，提供了针对中间人攻击的进一步保护。在每次成功的内部EAP身份验证之后，EAP EMSK和/或MSK以加密方式与TEAP第1阶段的密钥材料相结合，以生成复合会话密钥（CMK）。CMK用于计算复合MAC，作为第4.2.13节所述加密绑定TLV的一部分，这有助于确保TEAP中的所有通信都涉及相同的实体。在计算复合MAC期间，MAC字段用零填充。
The Compound MAC computation is as follows:
复合MAC计算如下：
CMK = CMK[j] Compound-MAC = MAC( CMK, BUFFER )
CMK=CMK[j]复合MAC=MAC（CMK，缓冲器）
where j is the number of the last successfully executed inner EAP method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and BUFFER is created after concatenating these fields in the following order:
其中j是最后一个成功执行的内部EAP方法的编号，MAC是TLS 1.2[RFC5246]中协商的MAC函数，缓冲区在按以下顺序连接这些字段后创建：
1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK Compound MAC fields zeroed out.
1将EMSK和MSK复合MAC字段归零的整个加密绑定TLV属性。
2 The EAP Type sent by the other party in the first TEAP message.
2另一方在第一条TEAP消息中发送的EAP类型。
3 All the Outer TLVs from the first TEAP message sent by EAP server to peer. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
3 EAP服务器发送给对等方的第一条TEAP消息中的所有外部TLV。如果单个TEAP消息被分割成多个TEAP数据包，则必须包括该消息所有片段中的外部TLV。
4 All the Outer TLVs from the first TEAP message sent by the peer to the EAP server. If a single TEAP message is fragmented into multiple TEAP packets, then the Outer TLVs in all the fragments of that message MUST be included.
4对等方发送到EAP服务器的第一条TEAP消息中的所有外部TLV。如果单个TEAP消息被分割成多个TEAP数据包，则必须包括该消息所有片段中的外部TLV。
TEAP authentication assures the Master Session Key (MSK) and Extended Master Session Key (EMSK) output from the EAP method are the result of all authentication conversations by generating an Intermediate Compound Key (IMCK). The IMCK is mutually derived by the peer and the server as described in Section 5.2 by combining the MSKs from
TEAP身份验证通过生成中间复合密钥（IMCK），确保从EAP方法输出的主会话密钥（MSK）和扩展主会话密钥（EMSK）是所有身份验证会话的结果。如第5.2节所述，通过组合来自的MSK，对等方和服务器相互派生IMCK
inner EAP methods with key material from TEAP Phase 1. The resulting MSK and EMSK are generated as part of the IMCKn key hierarchy as follows:
采用TEAP第1阶段关键材料的内部EAP方法。生成的MSK和EMSK作为IMCKn密钥层次结构的一部分生成，如下所示：
MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) EMSK = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function", 64)
MSK=TLS-PRF（S-IMCK[j]，“会话密钥生成函数”，64）EMSK=TLS-PRF（S-IMCK[j]，“扩展会话密钥生成函数”，64）
where j is the number of the last successfully executed inner EAP method.
其中j是最后一个成功执行的内部EAP方法的编号。
The EMSK is typically only known to the TEAP peer and server and is not provided to a third party. The derivation of additional keys and transportation of these keys to a third party are outside the scope of this document.
EMSK通常仅为TEAP对等方和服务器所知，不提供给第三方。额外密钥的推导以及这些密钥向第三方的传输不在本文档的范围内。
If no EAP methods have been negotiated inside the tunnel or no EAP methods have been successfully completed inside the tunnel, the MSK and EMSK will be generated directly from the session_key_seed meaning S-IMCK = session_key_seed.
如果在隧道内没有协商EAP方法，或者在隧道内没有成功完成EAP方法，则MSK和EMSK将直接从会话密钥种子生成，意思是S-IMCK=会话密钥种子。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the TEAP protocol, in accordance with BCP 26 [RFC5226].
本节根据BCP 26[RFC5226]向互联网分配号码管理局（IANA）提供了与技经评估组协议有关的数值登记指南。
The EAP Method Type number 55 has been assigned for TEAP.
EAP方法类型编号55已分配给TEAP。
The document defines a registry for TEAP TLV types, which may be assigned by Specification Required as defined in [RFC5226]. Section 4.2 defines the TLV types that initially populate the registry. A summary of the TEAP TLV types is given below:
本文件定义了TEAP TLV类型的注册表，可根据[RFC5226]中定义的规范进行分配。第4.2节定义了最初填充注册表的TLV类型。技经评估组TLV类型概述如下：
0 Unassigned
0未分配
1 Authority-ID TLV
1机构ID TLV
2 Identity-Type TLV
2身份类型TLV
3 Result TLV
3结果TLV
4 NAK TLV
4 NAK TLV
5 Error TLV
5错误TLV
6 Channel-Binding TLV
6通道绑定TLV
7 Vendor-Specific TLV
7特定于供应商的TLV
8 Request-Action TLV
8请求行动TLV
9 EAP-Payload TLV
9 EAP有效载荷TLV
10 Intermediate-Result TLV
10中间结果TLV
11 PAC TLV
11 PAC TLV
12 Crypto-Binding TLV
12加密绑定TLV
13 Basic-Password-Auth-Req TLV
13基本密码验证请求TLV
14 Basic-Password-Auth-Resp TLV
14基本密码验证和TLV
15 PKCS#7 TLV
15件PKC#7件TLV
16 PKCS#10 TLV
16件PKCS#10件TLV
17 Trusted-Server-Root TLV
17受信任的服务器根TLV
The Identity-Type defined in Section 4.2.3 contains an identity type code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial types defined are:
第4.2.3节中定义的标识类型包含根据[RFC5226]中定义的规范要求分配的标识类型代码。最初定义的类型为：
1 User
1用户
2 Machine
2机器
The Result TLV defined in Section 4.2.4, Request-Action TLV defined in Section 4.2.9, and Intermediate-Result TLV defined in Section 4.2.11 contain a Status code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial types defined are:
第4.2.4节中定义的结果TLV、第4.2.9节中定义的请求操作TLV以及第4.2.11节中定义的中间结果TLV包含根据[RFC5226]中定义的规范要求分配的状态代码。最初定义的类型为：
1 Success
1成功
2 Failure
2失败
The Error-TLV defined in Section 4.2.6 requires an error code. TEAP Error-TLV error codes are assigned based on a Specification Required basis as defined in [RFC5226]. The initial list of error codes is as follows:
第4.2.6节中定义的错误TLV需要错误代码。TEAP错误TLV错误代码根据[RFC5226]中定义的规范要求分配。错误代码的初始列表如下所示：
1 User account expires soon
1用户帐户即将到期
2 User account credential expires soon
2用户帐户凭据即将过期
3 User account authorizations change soon
3用户帐户授权即将更改
4 Clock skew detected
检测到4个时钟偏移
5 Contact administrator
5联系管理员
6 User account credentials change required
6需要更改用户帐户凭据
1001 Inner Method Error
1001内部方法错误
1002 Unspecified authentication infrastructure problem
1002未指定的身份验证基础结构问题
1003 Unspecified authentication failure
1003未指定的身份验证失败
1004 Unspecified authorization failure
1004未指定的授权失败
1005 User account credentials unavailable
1005用户帐户凭据不可用
1006 User account expired
1006用户帐户已过期
1007 User account locked: try again later
1007用户帐户已锁定：请稍后重试
1008 User account locked: admin intervention required
1008用户帐户已锁定：需要管理员干预
1009 Authentication infrastructure unavailable
1009身份验证基础架构不可用
1010 Authentication infrastructure not trusted
1010身份验证基础结构不受信任
1011 Clock skew too great
1011时钟偏移太大
1012 Invalid inner realm
1012无效的内部领域
1013 Token out of sync: administrator intervention required
1013令牌不同步：需要管理员干预
1014 Token out of sync: PIN change required
1014令牌不同步：需要更改PIN码
1015 Token revoked
1015令牌已吊销
1016 Tokens exhausted
1016个代币用完了
1017 Challenge expired
1017挑战到期
1018 Challenge algorithm mismatch
1018挑战算法不匹配
1019 Client certificate not supplied
1019未提供客户端证书
1020 Client certificate rejected
1020客户端证书被拒绝
1021 Realm mismatch between inner and outer identity
1021内部标识和外部标识之间的域不匹配
1022 Unsupported Algorithm In Certificate Signing Request
1022证书签名请求中不支持的算法
1023 Unsupported Extension In Certificate Signing Request
1023证书签名请求中不支持的扩展
1024 Bad Identity In Certificate Signing Request
1024证书签名请求中存在错误标识
1025 Bad Certificate Signing Request
1025错误的证书签名请求
1026 Internal CA Error
1026内部CA错误
1027 General PKI Error
1027一般PKI错误
1028 Inner method's channel-binding data required but not supplied
1028需要但未提供内部方法的通道绑定数据
1029 Inner method's channel-binding data did not include required information
1029内部方法的通道绑定数据未包含所需信息
1030 Inner method's channel binding failed
1030内部方法的通道绑定失败
1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
1031用户帐户凭据不正确[不建议使用]
2001 Tunnel Compromise Error
2001隧道折衷误差
2002 Unexpected TLVs Exchanged
2002年意外TLV交换
The Request-Action TLV defined in Section 4.2.9 contains an action code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial actions defined are:
第4.2.9节中定义的请求行动TLV包含根据[RFC5226]中定义的规范要求分配的行动代码。定义的初始操作包括：
1 Process-TLV
1工艺TLV
2 Negotiate-EAP
2谈判EAP
The PAC Attribute defined in Section 4.2.12.1 contains a Type code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial types defined are:
第4.2.12.1节中定义的PAC属性包含根据[RFC5226]中定义的规范要求分配的类型代码。最初定义的类型为：
1 PAC-Key
1个PAC密钥
2 PAC-Opaque
2 PAC不透明
3 PAC-Lifetime
3 PAC寿命
4 A-ID
4 A-ID
5 I-ID
5身份证
6 Reserved
6保留
7 A-ID-Info
7 A-ID-Info
8 PAC-Acknowledgement
8 PAC确认书
9 PAC-Info
9 PAC信息
10 PAC-Type
10 PAC型
The PAC-Type defined in Section 4.2.12.6 contains a type code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial type defined is:
第4.2.12.6节中定义的PAC类型包含根据[RFC5226]中定义的规范要求分配的类型代码。定义的初始类型为：
1 Tunnel PAC
1隧道PAC
The Trusted-Server-Root TLV defined in Section 4.2.18 contains a Credential-Format code that is assigned on a Specification Required basis as defined in [RFC5226]. The initial type defined is:
第4.2.18节中定义的受信任服务器根TLV包含根据[RFC5226]中定义的规范要求分配的凭证格式代码。定义的初始类型为：
1 PKCS#7-Server-Certificate-Root
1 PKCS#7-Server-Certificate-Root
The various values under the Vendor-Specific TLV are assigned by Private Use and do not need to be assigned by IANA.
供应商特定TLV下的各种值由私人使用分配，无需IANA分配。
TEAP registers the label "EXPORTER: teap session key seed" in the TLS Exporter Label Registry [RFC5705]. This label is used in derivation as defined in Section 5.1.
TEAP在TLS导出器标签注册表[RFC5705]中注册标签“导出器：TEAP会话密钥种子”。本标签用于第5.1节中定义的衍生。
TEAP registers a TEAP binding usage label from the "User Specific Root Keys (USRK) Key Labels" name space defined in [RFC5295] with a value "TEAPbindkey@ietf.org".
TEAP使用值从[RFC5295]中定义的“用户特定根键（USRK）键标签”名称空间注册TEAP绑定使用标签TEAPbindkey@ietf.org".
TEAP is designed with a focus on wireless media, where the medium itself is inherent to eavesdropping. Whereas in wired media an attacker would have to gain physical access to the wired medium, wireless media enables anyone to capture information as it is transmitted over the air, enabling passive attacks. Thus, physical security can not be assumed, and security vulnerabilities are far greater. The threat model used for the security evaluation of TEAP is defined in EAP [RFC3748].
技经评估组的设计重点是无线媒体，而无线媒体本身就是窃听所固有的。在有线媒体中，攻击者必须获得对有线媒体的物理访问，而无线媒体使任何人都能够在信息通过空中传输时捕获信息，从而实现被动攻击。因此，无法假设物理安全性，安全漏洞要大得多。EAP[RFC3748]中定义了用于技经评估组安全评估的威胁模型。
As a whole, TEAP provides message and integrity protection by establishing a secure tunnel for protecting the authentication method(s). The confidentiality and integrity protection is defined by TLS and provides the same security strengths afforded by TLS employing a strong entropy shared master secret. The integrity of the key generating authentication methods executed within the TEAP tunnel is verified through the calculation of the Crypto-Binding TLV. This ensures that the tunnel endpoints are the same as the inner method endpoints.
作为一个整体，TEAP通过建立一个用于保护认证方法的安全隧道来提供消息和完整性保护。机密性和完整性保护由TLS定义，并提供与采用强熵共享主密钥的TLS相同的安全强度。通过计算加密绑定TLV，验证TEAP隧道内执行的密钥生成认证方法的完整性。这确保了隧道端点与内部方法端点相同。
The Result TLV is protected and conveys the true Success or Failure of TEAP, and it should be used as the indicator of its success or failure respectively. However, as EAP terminates with either a cleartext EAP Success or Failure, a peer will also receive a cleartext EAP Success or Failure. The received cleartext EAP Success or Failure MUST match that received in the Result TLV; the peer SHOULD silently discard those cleartext EAP Success or Failure messages that do not coincide with the status sent in the protected Result TLV.
结果TLV受到保护并传达TEAP的真正成功或失败，应分别作为其成功或失败的指标。然而，由于EAP以明文EAP成功或失败终止，对等方也将收到明文EAP成功或失败。收到的明文EAP成功或失败必须与结果TLV中收到的一致；对等方应默默地丢弃那些与受保护结果TLV中发送的状态不一致的明文EAP成功或失败消息。
As is true for any negotiated EAP protocol, NAK packets used to suggest an alternate authentication method are sent unprotected and, as such, are subject to spoofing. During unprotected EAP method negotiation, NAK packets may be interjected as active attacks to negotiate down to a weaker form of authentication, such as EAP-MD5 (which only provides one-way authentication and does not derive a key). Both the peer and server should have a method selection policy that prevents them from negotiating down to weaker methods. Inner method negotiation resists attacks because it is protected by the mutually authenticated TLS tunnel established. Selection of TEAP as an authentication method does not limit the potential inner authentication methods, so TEAP should be selected when available.
与任何协商EAP协议一样，用于建议备用身份验证方法的NAK数据包在不受保护的情况下发送，因此会受到欺骗。在无保护的EAP方法协商期间，NAK数据包可能作为主动攻击被打断，以协商到较弱的身份验证形式，例如EAP-MD5（它只提供单向身份验证，不派生密钥）。对等方和服务器都应该有一个方法选择策略，以防止它们向下协商到较弱的方法。内部方法协商抵抗攻击，因为它受到建立的相互认证的TLS隧道的保护。选择技经评估组作为身份验证方法并不限制潜在的内部身份验证方法，因此应在可用时选择技经评估组。
An attacker cannot readily determine the inner EAP method used, except perhaps by traffic analysis. It is also important that peer implementations limit the use of credentials with an unauthenticated or unauthorized server.
攻击者无法轻易确定所使用的内部EAP方法，除非可能通过流量分析。对等实现限制未经验证或未经授权的服务器使用凭据也很重要。
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a different server than the Phase 2 conversation can introduce vulnerabilities if there is not a proper trust relationship and
不建议将技经评估组第1阶段与第2阶段对话分开。如果不存在适当的信任关系，并且
protection for the protocol between the two servers. Some vulnerabilities include:
保护两台服务器之间的协议。一些漏洞包括：
o Loss of identity protection
o 丧失身份保护
o Offline dictionary attacks
o 脱机字典攻击
o Lack of policy enforcement
o 缺乏政策执行
o Man-in-the-middle attacks (as described in [RFC7029])
o 中间人攻击（如[RFC7029]中所述）
There may be cases where a trust relationship exists between the Phase 1 and Phase 2 servers, such as on a campus or between two offices within the same company, where there is no danger in revealing the inner identity and credentials of the peer to entities between the two servers. In these cases, using a proxy solution without end-to-end protection of TEAP MAY be used. The TEAP encrypting/decrypting gateway MUST, at a minimum, provide support for IPsec, TLS, or similar protection in order to provide confidentiality for the portion of the conversation between the gateway and the EAP server. In addition, separation of the inner and outer method servers allows for crypto-binding based on the inner method MSK to be thwarted as described in [RFC7029]. Implementation and deployment SHOULD adopt various mitigation strategies described in [RFC7029]. If the inner method is deriving EMSK, then this threat is mitigated as TEAP utilizes the mutual crypto-binding based on EMSK as described in [RFC7029].
可能存在第1阶段和第2阶段服务器之间存在信任关系的情况，例如在校园内或同一公司内的两个办公室之间，在这两个服务器之间暴露对等实体的内部身份和凭据没有危险。在这些情况下，可以使用没有TEAP端到端保护的代理解决方案。TEAP加密/解密网关必须至少提供IPsec、TLS或类似保护的支持，以便为网关和EAP服务器之间的对话部分提供机密性。此外，内部和外部方法服务器的分离允许阻止基于内部方法MSK的加密绑定，如[RFC7029]中所述。实施和部署应采用[RFC7029]中所述的各种缓解策略。如果内部方法是推导EMSK，则TEAP利用[RFC7029]中所述的基于EMSK的相互加密绑定，从而缓解了该威胁。
TEAP addresses the known deficiencies and weaknesses in the EAP method. By employing a shared secret between the peer and server to establish a secured tunnel, TEAP enables:
技经评估组解决了EAP方法中的已知缺陷和弱点。通过利用对等方和服务器之间的共享秘密来建立安全隧道，TEAP能够：
o Per-packet confidentiality and integrity protection
o 每个数据包的机密性和完整性保护
o User identity protection
o 用户身份保护
o Better support for notification messages
o 更好地支持通知消息
o Protected EAP inner method negotiation
o 受保护的EAP内部方法协商
o Sequencing of EAP methods
o EAP方法的排序
o Strong mutually derived MSKs
o 强互导MSK
o Acknowledged success/failure indication
o 确认成功/失败指示
o Faster re-authentications through session resumption
o 通过会话恢复加快重新身份验证
o Mitigation of dictionary attacks
o 字典攻击的缓解
o Mitigation of man-in-the-middle attacks
o 缓解中间人攻击
o Mitigation of some denial-of-service attacks
o 缓解某些拒绝服务攻击
It should be noted that in TEAP, as in many other authentication protocols, a denial-of-service attack can be mounted by adversaries sending erroneous traffic to disrupt the protocol. This is a problem in many authentication or key agreement protocols and is therefore noted for TEAP as well.
应当指出，在技经评估组中，如同在许多其他认证协议中一样，敌方可以发起拒绝服务攻击，发送错误的通信量以破坏协议。这是许多认证或密钥协议协议中的一个问题，因此TEAP也注意到了这一点。
TEAP was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. To that extent, the TEAP authentication mitigates several vulnerabilities, such as dictionary attacks, by protecting the weak credential-based authentication method. The protection is based on strong cryptographic algorithms in TLS to provide message confidentiality and integrity. The keys derived for the protection relies on strong random challenges provided by both peer and server as well as an established key with strong entropy. Implementations should follow the recommendation in [RFC4086] when generating random numbers.
技经评估组的设计重点是受保护的认证方法，这些方法通常依赖于弱凭证，例如基于密码的机密。在这种程度上，TEAP身份验证通过保护基于弱凭证的身份验证方法减轻了一些漏洞，如字典攻击。该保护基于TLS中的强加密算法，以提供消息机密性和完整性。用于保护的密钥依赖于对等方和服务器提供的强随机挑战以及具有强熵的已建立密钥。生成随机数时，实现应遵循[RFC4086]中的建议。
The initial identity request response exchange is sent in cleartext outside the protection of TEAP. Typically, the Network Access Identifier (NAI) [RFC4282] in the identity response is useful only for the realm of information that is used to route the authentication requests to the right EAP server. This means that the identity response may contain an anonymous identity and just contain realm information. In other cases, the identity exchange may be eliminated altogether if there are other means for establishing the destination realm of the request. In no case should an intermediary place any trust in the identity information in the identity response since it is unauthenticated and may not have any relevance to the authenticated identity. TEAP implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2.
初始身份请求-响应交换以明文形式发送，不受TEAP的保护。通常，标识响应中的网络访问标识符（NAI）[RFC4282]仅对用于将认证请求路由到正确的EAP服务器的信息领域有用。这意味着标识响应可能包含匿名标识，并且只包含领域信息。在其他情况下，如果存在用于建立请求的目标域的其他方法，则可以完全消除身份交换。在任何情况下，中介机构都不应信任身份响应中的身份信息，因为该信息未经身份验证，并且可能与经身份验证的身份没有任何关联。TEAP实现不应试图将初始明文EAP标识响应包中披露的任何标识与第2阶段中认证的标识进行比较。
Identity request/response exchanges sent after the TEAP tunnel is established are protected from modification and eavesdropping by attackers.
TEAP隧道建立后发送的身份请求/响应交换受到保护，免受攻击者的修改和窃听。
Note that since TLS client certificates are sent in the clear, if identity protection is required, then it is possible for the TLS authentication to be renegotiated after the first server authentication. To accomplish this, the server will typically not request a certificate in the server_hello; then, after the server_finished message is sent and before TEAP Phase 2, the server MAY send a TLS hello_request. This allows the peer to perform client authentication by sending a client_hello if it wants to or send a no_renegotiation alert to the server indicating that it wants to continue with TEAP Phase 2 instead. Assuming that the peer permits renegotiation by sending a client_hello, then the server will respond with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages. Since this renegotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using an EAP method (for example, EAP-TLS) within the TLS session in TEAP Phase 2 instead of using TLS handshake renegotiation.
请注意，由于TLS客户端证书是以明文形式发送的，如果需要身份保护，那么在第一次服务器身份验证之后可以重新协商TLS身份验证。为了实现这一点，服务器通常不会在服务器中请求证书；然后，在发送server_finished消息之后和TEAP阶段2之前，服务器可以发送TLS hello_请求。这允许对等方通过发送客户端hello（如果它想）或向服务器发送no_重新协商警报来执行客户端身份验证，指示它想继续执行TEAP第2阶段。假设对等方通过发送客户机你好来允许重新协商，那么服务器将使用服务器你好、证书和证书请求消息进行响应。对等方回复证书、客户端密钥交换和证书验证消息。由于此重新协商发生在加密的TLS通道内，因此不会显示客户端证书的详细信息。可以在TEAP阶段2中的TLS会话中使用EAP方法（例如，EAP-TLS）执行证书认证，而不是使用TLS握手重新协商。
TEAP was designed with a focus on protected authentication methods that typically rely on weak credentials, such as password-based secrets. TEAP mitigates dictionary attacks by allowing the establishment of a mutually authenticated encrypted TLS tunnel providing confidentiality and integrity to protect the weak credential-based authentication method.
技经评估组的设计重点是受保护的认证方法，这些方法通常依赖于弱凭证，例如基于密码的机密。TEAP通过允许建立相互认证的加密TLS隧道来减轻字典攻击，该隧道提供机密性和完整性，以保护基于弱凭证的认证方法。
Allowing methods to be executed both with and without the protection of a secure tunnel opens up a possibility of a man-in-the-middle attack. To avoid man-in-the-middle attacks it is recommended to always deploy authentication methods with the protection of TEAP. TEAP provides protection from man-in-the-middle attacks even if a deployment chooses to execute inner EAP methods both with and without TEAP protection. TEAP prevents this attack in two ways:
允许在有或没有安全隧道保护的情况下执行方法，可能会导致中间人攻击。为了避免中间人攻击，建议始终部署具有TEAP保护的身份验证方法。即使部署选择在有TEAP保护和无TEAP保护的情况下执行内部EAP方法，TEAP也可以提供中间人攻击的保护。TEAP通过两种方式防止此攻击：
1. By using the PAC-Key to mutually authenticate the peer and server during TEAP authentication Phase 1 establishment of a secure tunnel.
1. 在TEAP认证阶段1建立安全隧道期间，使用PAC密钥对对等方和服务器进行相互认证。
2. By using the keys generated by the inner authentication method (if the inner methods are key generating) in the crypto-binding exchange and in the generation of the key material exported by the EAP method described in Section 5.
2. 通过在加密绑定交换和第5节所述EAP方法导出的密钥材料的生成中使用内部认证方法生成的密钥（如果内部方法生成密钥）。
TEAP crypto binding does not guarantee man-in-the-middle protection if the client allows a connection to an untrusted server, such as in the case where the client does not properly validate the server's certificate. If the TLS ciphersuite derives the master secret solely from the contribution of secret data from one side of the conversation (such as ciphersuites based on RSA key transport), then an attacker who can convince the client to connect and engage in authentication can impersonate the client to another server even if a strong inner method is executed within the tunnel. If the TLS ciphersuite derives the master secret from the contribution of secrets from both sides of the conversation (such as in ciphersuites based on Diffie-Hellman), then crypto binding can detect an attacker in the conversation if a strong inner method is used.
如果客户端允许连接到不受信任的服务器（例如客户端未正确验证服务器的证书），TEAP加密绑定不保证中间人保护。如果TLS密码套件仅从会话一方的机密数据（例如基于RSA密钥传输的密码套件）中获取主密钥，然后，能够说服客户端连接并进行身份验证的攻击者可以将客户端模拟到另一台服务器，即使在隧道中执行了强内部方法。如果TLS密码套件从会话双方的秘密贡献中获得主秘密（例如在基于Diffie Hellman的密码套件中），则如果使用强内部方法，则加密绑定可以检测会话中的攻击者。
A PAC may be bound to a user identity. A compliant implementation of TEAP MUST validate that an identity obtained in the PAC-Opaque field matches at minimum one of the identities provided in the TEAP Phase 2 authentication method. This validation provides another binding to ensure that the intended peer (based on identity) has successfully completed the TEAP Phase 1 and proved identity in the Phase 2 conversations.
PAC可以绑定到用户标识。TEAP的兼容实现必须验证在PAC不透明字段中获得的身份与TEAP第2阶段身份验证方法中提供的至少一个身份匹配。此验证提供了另一个绑定，以确保目标对等方（基于身份）已成功完成TEAP第1阶段，并在第2阶段对话中证明身份。
EAP Success and EAP Failure packets are, in general, sent in cleartext and may be forged by an attacker without detection. Forged EAP Failure packets can be used to attempt to convince an EAP peer to disconnect. Forged EAP Success packets may be used to attempt to convince a peer that authentication has succeeded, even though the authenticator has not authenticated itself to the peer.
EAP成功和EAP失败数据包通常以明文形式发送，攻击者可以在未经检测的情况下伪造这些数据包。伪造的EAP故障数据包可用于试图说服EAP对等方断开连接。伪造的EAP成功数据包可用于尝试说服对等方身份验证已成功，即使身份验证方未向对等方进行身份验证。
By providing message confidentiality and integrity, TEAP provides protection against these attacks. Once the peer and authentication server (AS) initiate the TEAP authentication Phase 2, compliant TEAP implementations MUST silently discard all cleartext EAP messages, unless both the TEAP peer and server have indicated success or failure using a protected mechanism. Protected mechanisms include the TLS alert mechanism and the protected termination mechanism described in Section 3.3.3.
通过提供消息机密性和完整性，TEAP提供了针对这些攻击的保护。一旦对等方和认证服务器（AS）启动TEAP认证阶段2，符合TEAP的实施必须以静默方式放弃所有明文EAP消息，除非TEAP对等方和服务器都使用受保护的机制指示成功或失败。受保护机制包括第3.3.3节所述的TLS警报机制和受保护终止机制。
The success/failure decisions within the TEAP tunnel indicate the final decision of the TEAP authentication conversation. After a success/failure result has been indicated by a protected mechanism, the TEAP peer can process unprotected EAP Success and EAP Failure messages; however, the peer MUST ignore any unprotected EAP Success
TEAP隧道内的成功/失败决策指示TEAP身份验证对话的最终决策。受保护机制指示成功/失败结果后，TEAP对等方可以处理未受保护的EAP成功和EAP失败消息；但是，对等方必须忽略任何未受保护的EAP成功
or Failure messages where the result does not match the result of the protected mechanism.
或失败消息，其中结果与受保护机制的结果不匹配。
To abide by [RFC3748], the server sends a cleartext EAP Success or EAP Failure packet to terminate the EAP conversation. However, since EAP Success and EAP Failure packets are not retransmitted, the final packet may be lost. While a TEAP-protected EAP Success or EAP Failure packet should not be a final packet in a TEAP conversation, it may occur based on the conditions stated above, so an EAP peer should not rely upon the unprotected EAP Success and Failure messages.
为了遵守[RFC3748]，服务器发送明文EAP Success或EAP Failure数据包以终止EAP对话。然而，由于EAP成功和EAP失败分组不被重新传输，最终分组可能丢失。虽然受TEAP保护的EAP成功或EAP失败数据包不应是TEAP对话中的最终数据包，但它可能基于上述条件发生，因此EAP对等方不应依赖未受保护的EAP成功和失败消息。
As part of the TLS negotiation, the server presents a certificate to the peer. The peer SHOULD verify the validity of the EAP server certificate and SHOULD also examine the EAP server name presented in the certificate in order to determine whether the EAP server can be trusted. When performing server certificate validation, implementations MUST provide support for the rules in [RFC5280] for validating certificates against a known trust anchor. In addition, implementations MUST support matching the realm portion of the peer's NAI against a SubjectAltName of type dNSName within the server certificate. However, in certain deployments, this might not be turned on. Please note that in the case where the EAP authentication is remote, the EAP server will not reside on the same machine as the authenticator, and therefore, the name in the EAP server's certificate cannot be expected to match that of the intended destination. In this case, a more appropriate test might be whether the EAP server's certificate is signed by a certification authority (CA) controlling the intended domain and whether the authenticator can be authorized by a server in that domain.
作为TLS协商的一部分，服务器向对等方提供证书。对等方应验证EAP服务器证书的有效性，还应检查证书中显示的EAP服务器名称，以确定是否可以信任EAP服务器。执行服务器证书验证时，实现必须支持[RFC5280]中的规则，以便根据已知的信任锚验证证书。此外，实现必须支持将对等方NAI的领域部分与服务器证书中dNSName类型的SubjectAltName进行匹配。但是，在某些部署中，这可能不会启用。请注意，如果EAP身份验证是远程的，EAP服务器将不会与身份验证程序驻留在同一台计算机上，因此，EAP服务器证书中的名称不能与预期目标的名称匹配。在这种情况下，更合适的测试可能是EAP服务器的证书是否由控制预期域的证书颁发机构（CA）签名，以及认证者是否可以由该域中的服务器授权。
Since the Tunnel PAC is stored by the peer, special care should be given to the overall security of the peer. The Tunnel PAC MUST be securely stored by the peer to prevent theft or forgery of any of the Tunnel PAC components. In particular, the peer MUST securely store the PAC-Key and protect it from disclosure or modification. Disclosure of the PAC-Key enables an attacker to establish the TEAP tunnel; however, disclosure of the PAC-Key does not reveal the peer or server identity or compromise any other peer's PAC credentials. Modification of the PAC-Key or PAC-Opaque components of the Tunnel PAC may also lead to denial of service as the tunnel establishment will fail. The PAC-Opaque component is the effective TLS ticket extension used to establish the tunnel using the techniques of [RFC5077]. Thus, the security considerations defined by [RFC5077]
由于隧道PAC由对等方存储，因此应特别注意对等方的整体安全性。隧道PAC必须由对等方安全存储，以防止任何隧道PAC组件被盗或伪造。特别是，对等方必须安全地存储PAC密钥，并保护其不被泄露或修改。泄露PAC密钥使攻击者能够建立TEAP隧道；但是，泄露PAC密钥不会泄露对等方或服务器身份，也不会损害任何其他对等方的PAC凭据。修改隧道PAC的PAC密钥或PAC不透明组件也可能导致拒绝服务，因为隧道建立将失败。PAC不透明组件是有效的TLS票证扩展，用于使用[RFC5077]的技术建立隧道。因此，[RFC5077]定义的安全注意事项
also apply to the PAC-Opaque. The PAC-Info may contain information about the Tunnel PAC such as the identity of the PAC issuer and the Tunnel PAC lifetime for use in the management of the Tunnel PAC. The PAC-Info should be securely stored by the peer to protect it from disclosure and modification.
也适用于PAC不透明。PAC信息可能包含有关隧道PAC的信息，例如PAC颁发者的身份和隧道PAC寿命，以用于隧道PAC的管理。PAC信息应由对等方安全存储，以防止其被披露和修改。
This section provides the needed security claim requirement for EAP [RFC3748].
本节提供了EAP[RFC3748]所需的安全索赔要求。
Auth. mechanism: Certificate-based, shared-secret-based, and various tunneled authentication mechanisms.
Auth。机制：基于证书、基于共享秘密和各种隧道式身份验证机制。
Ciphersuite negotiation: Yes
Ciphersuite协商：是
Mutual authentication: Yes
相互认证：是
Integrity protection: Yes. Any method executed within the TEAP tunnel is integrity protected. The cleartext EAP headers outside the tunnel are not integrity protected.
完整性保护：是的。TEAP隧道内执行的任何方法都受到完整性保护。隧道外的明文EAP标头不受完整性保护。
Replay protection: Yes
重播保护：是
Confidentiality: Yes
保密：是的
Key derivation: Yes
关键词：是的
Key strength: See Note 1 below.
关键强度：见下文注1。
Dictionary attack prot.: Yes
字典攻击保护：是
Fast reconnect: Yes
快速重新连接：是的
Cryptographic binding: Yes
加密绑定：是
Session independence: Yes
会议独立性：是的
Fragmentation: Yes
碎片化：是的
Key Hierarchy: Yes
密钥层次结构：是
Channel binding: Yes
通道绑定：是
Notes
笔记
1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The National Institute for Standards and Technology (NIST) also offers advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766], Section 5 advises use of the following required RSA or DH (Diffie-Hellman) module and DSA (Digital Signature Algorithm) subgroup size in bits for a given level of attack resistance in bits. Based on the table below, a 2048-bit RSA key is required to provide 112-bit equivalent key strength:
1. BCP 86[RFC3766]提供有关适当密钥大小的建议。国家标准与技术研究所（NIST）也在[NIST-SP-800-57]中提供了关于适当键尺寸的建议。[RFC3766]第5节建议使用以下要求的RSA或DH（Diffie-Hellman）模块和DSA（数字签名算法）子组大小（以位为单位），以位为单位表示给定级别的抗攻击能力。根据下表，需要2048位RSA密钥才能提供112位等效密钥强度：
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 482
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 482
This specification is based on EAP-FAST [RFC4851], which included the ideas and efforts of Nancy Cam-Winget, David McGrew, Joe Salowey, Hao Zhou, Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of Cisco Systems, Inc.
本规范以EAP-FAST[RFC4851]为基础，其中包括思科系统公司的南希·卡姆·温吉、大卫·麦克格雷夫、乔·萨洛维、周浩、帕德·贾卡哈利、马克·克里斯彻、道格·史密斯和格伦·佐恩的想法和努力。
The TLV processing was inspired from work on the Protected Extensible Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan Smith, Sean Turner, and Simon Josefsson.
TLV处理的灵感来自Ashwin Palekar、Dan Smith、Sean Turner和Simon Josefsson在受保护的可扩展身份验证协议版本2（PEAPv2）上的工作。
The method for linking identity and proof-of-possession by placing the tls-unique value in the challengePassword field of the CSR as described in Section 3.8.2 was inspired by the technique described in "Enrollment over Secure Transport" [RFC7030].
如第3.8.2节所述，通过在CSR的challengePassword字段中放置tls唯一值来链接身份和占有证明的方法受到“安全传输注册”中所述技术的启发[RFC7030]。
Helpful review comments were provided by Russ Housley, Jari Arkko, Ilan Frenkel, Jeremy Steiglitz, Dan Harkins, Sam Hartman, Jim Schaad, Barry Leiba, Stephen Farrell, Chris Lonvick, and Josh Howlett.
Russ Housley、Jari Arkko、Ilan Frenkel、Jeremy Steiglitz、Dan Harkins、Sam Hartman、Jim Schaad、Barry Leiba、Stephen Farrell、Chris Lonvick和Josh Howlett提供了有用的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[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月。
[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月。
[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月。
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008.
[RFC5295]Salowey，J.，Dondeti，L.，Narayanan，V.，和M.Nakhjiri，“从扩展主会话密钥（EMSK）派生根密钥的规范”，RFC 52952008年8月。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, March 2010.
[RFC5705]Rescorla，E.“传输层安全（TLS）关键材料导出器”，RFC 57052010年3月。
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010.
[RFC5746]Rescorla，E.，Ray，M.，Dispensa，S.，和N.Oskov，“传输层安全（TLS）重新协商指示扩展”，RFC 57462010年2月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929]Altman，J.，Williams，N.，和L.Zhu，“TLS的通道绑定”，RFC 59292010年7月。
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, July 2012.
[RFC6677]Hartman，S.，Clancy，T.，和K.Hoeper，“可扩展身份验证协议（EAP）方法的通道绑定支持”，RFC 6677，2012年7月。
[IEEE.802-1X.2013] IEEE, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X, December 2013.
[IEEE.802-1X.2013]IEEE，“局域网和城域网：基于端口的网络访问控制”，IEEE标准802.1X，2013年12月。
[NIST-SP-800-57] National Institute of Standards and Technology, "Recommendation for Key Management", NIST Special Publication 800-57, July 2012.
[NIST-SP-800-57]国家标准与技术研究所，“关键管理建议”，NIST特别出版物800-57，2012年7月。
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", February 2014.
[PEAP]微软公司，[MS-PEAP]：受保护的可扩展身份验证协议（PEAP）”，2014年2月。
[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月。
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, November 2000.
[RFC2985]Nystrom，M.和B.Kaliski，“PKCS#9：选定对象类和属性类型版本2.0”，RFC 29852000年11月。
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.
[RFC2986]Nystrom，M.和B.Kaliski，“PKCS#10：认证请求语法规范版本1.7”，RFC 2986，2000年11月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[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月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.
[RFC4072]Eronen，P.，Hiller，T.，和G.Zorn，“直径可扩展认证协议（EAP）应用”，RFC 4072，2005年8月。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]Eastlake，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，2005年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月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[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月。
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1 /ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4945]Korver，B.“IKEv1/ISAKMP、IKEv2和PKIX的互联网IP安全PKI配置文件”，RFC 49452007年8月。
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.
[RFC4962]Housley，R.和B.Aboba，“认证、授权和记帐（AAA）密钥管理指南”，BCP 132，RFC 4962，2007年7月。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, August 2008.
[RFC5247]Aboba，B.，Simon，D.，和P.Eronen，“可扩展认证协议（EAP）密钥管理框架”，RFC 5247，2008年8月。
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5272]Schaad，J.和M.Myers，“CMS上的证书管理（CMC）”，RFC 52722008年6月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5281]Funk，P.和S.Blake Wilson，“可扩展认证协议隧道传输层安全认证协议版本0（EAP-TTLSv0）”，RFC 52812008年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月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652]Housley，R.，“加密消息语法（CMS）”，STD 70，RFC 56522009年9月。
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, August 2010.
[RFC5931]Harkins，D.和G.Zorn，“仅使用密码的可扩展身份验证协议（EAP）身份验证”，RFC 59312010年8月。
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011.
[RFC6066]Eastlake，D.，“传输层安全（TLS）扩展：扩展定义”，RFC6066，2011年1月。
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An EAP Authentication Method Based on the Encrypted Key Exchange (EKE) Protocol", RFC 6124, February 2011.
[RFC6124]Sheffer，Y.，Zorn，G.，Tschofenig，H.，和S.Fluhrer，“基于加密密钥交换（EKE）协议的EAP认证方法”，RFC 61242011年2月。
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey, "Requirements for a Tunnel-Based Extensible Authentication Protocol (EAP) Method", RFC 6678, July 2012.
[RFC6678]Hoeper，K.，Hanna，S.，Zhou，H.，和J.Salowey，“基于隧道的可扩展认证协议（EAP）方法的要求”，RFC 6678，2012年7月。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013.
[RFC6960]Santesson，S.，Myers，M.，Ankney，R.，Malpani，A.，Galperin，S.，和C.Adams，“X.509互联网公钥基础设施在线证书状态协议-OCSP”，RFC 69602013年6月。
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, June 2013.
[RFC6961]Pettersen，Y.，“传输层安全（TLS）多证书状态请求扩展”，RFC 69612013年6月。
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible Authentication Protocol (EAP) Mutual Cryptographic Binding", RFC 7029, October 2013.
[RFC7029]Hartman，S.，Wasserman，M.，和D.Zhang，“可扩展认证协议（EAP）相互加密绑定”，RFC 70292013年10月。
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over Secure Transport", RFC 7030, October 2013.
[RFC7030]Pritikin，M.，Yee，P.，和D.Harkins，“通过安全传输注册”，RFC 7030，2013年10月。
[X.690] ITU-T, "ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, November 2008.
[X.690]ITU-T，“ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范”，ITU-T建议X.690，2008年11月。
This section evaluates all tunnel-based EAP method requirements described in [RFC6678] against TEAP version 1.
本节根据TEAP第1版评估[RFC6678]中描述的所有基于隧道的EAP方法要求。
TEAPv1 meets this requirement by being compliant with RFC 3748 [RFC3748], RFC 4017 [RFC4017], RFC 5247 [RFC5247], and RFC 4962 [RFC4962]. It is also compliant with the "cryptographic algorithm agility" requirement by leveraging TLS 1.2 for all cryptographic algorithm negotiation.
TEAPv1符合RFC 3748[RFC3748]、RFC 4017[RFC4017]、RFC 5247[RFC5247]和RFC 4962[RFC4962]的要求，从而满足该要求。通过利用TLS 1.2进行所有加密算法协商，它还符合“加密算法敏捷性”要求。
TEAPv1 meets this requirement by mandating TLS version 1.2 support as defined in Section 3.2.
TEAPv1通过强制提供第3.2节中定义的TLS 1.2版支持来满足此要求。
TEAPv1 meets this requirement by using TLS to provide protected ciphersuite negotiation.
TEAPv1通过使用TLS提供受保护的密码套件协商来满足这一要求。
TEAPv1 meets this requirement by mandating TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory-to-implement ciphersuite as defined in Section 3.2.
TEAPv1通过强制TLS_RSA_和_AES_128_CBC_SHA实现第3.2节中定义的密码套件来满足这一要求。
TEAPv1 meets this requirement by mandating TLS_RSA_WITH_AES_128_CBC_SHA as a mandatory-to-implement ciphersuite that provides certificate-based authentication of the server and is approved by NIST. The mandatory-to-implement ciphersuites only include ciphersuites that use strong cryptographic algorithms. They do not include ciphersuites providing mutually anonymous authentication or static Diffie-Hellman ciphersuites as defined in Section 3.2.
TEAPv1通过强制TLS_RSA_和_AES_128_CBC_SHA实现密码套件来满足这一要求，该密码套件为服务器提供基于证书的身份验证，并得到NIST的批准。实现密码套件的强制要求仅包括使用强密码算法的密码套件。它们不包括提供相互匿名认证的密码套件或第3.2节中定义的静态Diffie-Hellman密码套件。
TEAPv1 meets this requirement by using TLS to provide sufficient replay protection.
TEAPv1通过使用TLS提供足够的重放保护来满足这一要求。
TEAPv1 meets this requirement by allowing TLS extensions, such as TLS Certificate Status Request extension [RFC6066] and SessionTicket extension [RFC5077], to be used during TLS tunnel establishment.
TEAPv1通过允许在TLS隧道建立期间使用TLS扩展（如TLS证书状态请求扩展[RFC6066]和SessionTicket扩展[RFC5077]）来满足此要求。
TEAPv1 meets this requirement by establishment of the TLS tunnel and protection identities specific to the inner method. In addition, the peer certificate can be sent confidentially (i.e., encrypted).
TEAPv1通过建立TLS隧道和特定于内部方法的保护标识来满足这一要求。此外，对等证书可以秘密发送（即加密）。
TEAPv1 meets this requirement by mandating support of TLS session resumption as defined in Section 3.2.1 and TLS session resume using a PAC as defined in Section 3.2.2 .
TEAPv1通过强制支持第3.2.1节中定义的TLS会话恢复和使用第3.2.2节中定义的PAC恢复TLS会话来满足此要求。
TEAPv1 meets this requirement by leveraging fragmentation support provided by TLS as defined in Section 3.7.
TEAPv1通过利用第3.7节中定义的TLS提供的碎片支持来满足这一要求。
TEAPv1 meets this requirement by including the TEAP version number received in the computation of the Crypto-Binding TLV as defined in Section 4.2.13.
TEAPv1通过包括在第4.2.13节中定义的加密绑定TLV计算中收到的TEAP版本号来满足此要求。
TEAPv1 meets this requirement by using an extensible TLV data layer inside the tunnel as defined in Section 4.2.
TEAPv1通过在隧道内使用第4.2节中定义的可扩展TLV数据层满足此要求。
TEAPv1 meets this requirement by allowing multiple TLVs to be sent in a single EAP request or response packet, while maintaining the half-duplex operation typical of EAP.
TEAPv1通过允许在单个EAP请求或响应数据包中发送多个TLV来满足此要求，同时保持EAP典型的半双工操作。
TEAPv1 meets this requirement by having a mandatory bit in each TLV to indicate whether it is mandatory to support or not as defined in Section 4.2.
TEAPv1通过在每个TLV中具有一个强制位来满足此要求，以指示是否强制支持第4.2节中定义的要求。
TEAPv1 meets this requirement by having a Vendor-Specific TLV to allow vendors to define their own attributes as defined in Section 4.2.8.
TEAPv1通过具有特定于供应商的TLV来满足此要求，允许供应商定义第4.2.8节中定义的自身属性。
TEAPv1 meets this requirement by having a Result TLV to exchange the final result of the EAP authentication so both the peer and server have a synchronized state as defined in Section 4.2.4.
TEAPv1通过使用结果TLV交换EAP身份验证的最终结果来满足此要求，因此对等方和服务器都具有第4.2.4节中定义的同步状态。
TEAPv1 meets this requirement by supporting UTF-8 format in the Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and the Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.
TEAPv1通过在第4.2.14节定义的基本密码验证请求TLV和第4.2.15节定义的基本密码验证响应TLV中支持UTF-8格式满足此要求。
TEAPv1 meets this requirement by having a Channel-Binding TLV to exchange the EAP channel-binding data as defined in Section 4.2.7.
TEAPv1通过具有通道绑定TLV以交换第4.2.7节中定义的EAP通道绑定数据来满足此要求。
TEAPv1 meets this requirement by running the password authentication inside a protected TLS tunnel.
TEAPv1通过在受保护的TLS隧道内运行密码验证来满足此要求。
TEAPv1 meets this requirement by mandating authentication of the server before establishment of the protected TLS and then running inner password authentication as defined in Section 3.2.
TEAPv1通过在建立受保护的TLS之前强制服务器身份验证，然后运行第3.2节中定义的内部密码身份验证来满足此要求。
TEAPv1 meets this requirement by supporting TLS Certificate Status Request extension [RFC6066] during tunnel establishment.
TEAPv1通过在隧道建立期间支持TLS证书状态请求扩展[RFC6066]来满足此要求。
TEAPv1 meets this requirement by supporting UTF-8 format in Basic-Password-Auth-Req TLV as defined in Section 4.2.14 and Basic-Password-Auth-Resp TLV as defined in Section 4.2.15.
TEAPv1通过支持第4.2.14节中定义的基本密码验证请求TLV和第4.2.15节中定义的基本密码验证响应TLV中的UTF-8格式满足此要求。
TEAPv1 meets this requirement by supporting Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.
TEAPv1通过支持第4.2.3节中定义的标识类型TLV来满足此要求，以指示认证是针对用户还是针对机器。
TEAPv1 meets this requirement by supporting multiple Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV exchanges within a single EAP authentication, which allows "housekeeping"" functions such as password change.
TEAPv1通过在单个EAP身份验证中支持多个基本密码身份验证请求TLV和基本密码身份验证响应TLV交换来满足此要求，从而允许“内务管理”功能，如密码更改。
TEAPv1 meets this requirement by supporting inner EAP method negotiation within the protected TLS tunnel.
TEAPv1通过在受保护的TLS隧道内支持内部EAP方法协商来满足此要求。
TEAPv1 meets this requirement by supporting inner EAP method chaining within protected TLS tunnels as defined in Section 3.3.1.
TEAPv1通过支持第3.3.1节中定义的受保护TLS隧道内的内部EAP方法链接满足此要求。
TEAPv1 meets this requirement by supporting cryptographic binding of the inner EAP method keys with the keys derived from the TLS tunnel as defined in Section 4.2.13.
TEAPv1通过支持内部EAP方法密钥与第4.2.13节中定义的TLS隧道派生密钥的加密绑定来满足此要求。
TEAPv1 meets this requirement by supporting the Request-Action TLV as defined in Section 4.2.9 to allow a peer to initiate another inner EAP method.
TEAPv1通过支持第4.2.9节中定义的请求操作TLV来满足此要求，以允许对等方启动另一个内部EAP方法。
TEAPv1 meets this requirement by supporting the Identity-Type TLV as defined in Section 4.2.3 to indicate whether the authentication is for a user or a machine.
TEAPv1通过支持第4.2.3节中定义的标识类型TLV来满足此要求，以指示认证是针对用户还是针对机器。
This document is a new standard tunnel EAP method based on revision of EAP-FAST version 1 [RFC4851] that contains improved flexibility, particularly for negotiation of cryptographic algorithms. The major changes are:
本文件是基于EAP-FAST第1版[RFC4851]修订版的一种新的标准隧道EAP方法，其中包含改进的灵活性，特别是对于密码算法的协商。主要的变化是：
1. The EAP method name has been changed from EAP-FAST to TEAP; this change thus requires that a new EAP Type be assigned.
1. EAP方法名称已从EAP-FAST更改为TEAP；因此，此更改需要分配新的EAP类型。
2. This version of TEAP MUST support TLS 1.2 [RFC5246].
2. 此版本的TEAP必须支持TLS 1.2[RFC5246]。
3. The key derivation now makes use of TLS keying material exporters [RFC5705] and the PRF and hash function negotiated in TLS. This is to simplify implementation and better support cryptographic algorithm agility.
3. 密钥派生现在使用TLS密钥导出器[RFC5705]和TLS中协商的PRF和哈希函数。这是为了简化实现并更好地支持加密算法的灵活性。
4. TEAP is in full conformance with TLS ticket extension [RFC5077] as described in Section 3.2.2.
4. TEAP完全符合第3.2.2节所述的TLS票证扩展[RFC5077]。
5. Support is provided for passing optional Outer TLVs in the first two message exchanges, in addition to the Authority-ID TLV data in EAP-FAST.
5. 除了EAP-FAST中的授权ID TLV数据外，还支持在前两次消息交换中传递可选的外部TLV。
6. Basic password authentication on the TLV level has been added in addition to the existing inner EAP method.
6. 除了现有的内部EAP方法外，还添加了TLV级别的基本密码验证。
7. Additional TLV types have been defined to support EAP channel binding and metadata. They are the Identity-Type TLV and Channel-Binding TLVs, defined in Section 4.2.
7. 已定义其他TLV类型以支持EAP通道绑定和元数据。它们是第4.2节中定义的标识类型TLV和通道绑定TLV。
The following exchanges show a successful TEAP authentication with basic password authentication and optional PAC refreshment. The conversation will appear as follows:
以下交换显示了成功的TEAP身份验证，包括基本密码身份验证和可选的PAC刷新。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello with PAC-Opaque in SessionTicket extension)->
EAP响应/EAP类型=TEAP，V=1（TLS客户端\u你好，会话密钥扩展中PAC不透明）->
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, (TLS change_cipher_spec, TLS finished)
<-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u您好，（TLS更改\u密码\u规范，TLS完成）
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established (messages sent within the TLS channel)
TLS通道已建立（在TLS通道内发送的消息）
<- Basic-Password-Auth-Req TLV, Challenge
<-基本密码验证请求TLV，质询
Basic-Password-Auth-Resp TLV, Response with both username and password) ->
基本密码验证响应TLV，使用用户名和密码进行响应）->
optional additional exchanges (new pin mode, password change, etc.) ...
可选的附加交换（新pin模式、密码更改等）。。。
<- Crypto-Binding TLV (Request), Result TLV (Success), (Optional PAC TLV)
<-加密绑定TLV（请求），结果TLV（成功），（可选PAC TLV）
Crypto-Binding TLV(Response), Result TLV (Success), (PAC-Acknowledgement TLV) ->
加密绑定TLV（响应），结果TLV（成功），（PAC确认TLV）->
TLS channel torn down (messages sent in cleartext)
TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
The following exchanges show a failed TEAP authentication due to wrong user credentials. The conversation will appear as follows:
以下交换显示由于错误的用户凭据而导致TEAP身份验证失败。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/ Identity (MyID1) ->
EAP响应/标识（MyID1）->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello with PAC-Opaque in SessionTicket extension)->
EAP响应/EAP类型=TEAP，V=1（TLS客户端\u你好，会话密钥扩展中PAC不透明）->
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, (TLS change_cipher_spec, TLS finished)
<-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u您好，（TLS更改\u密码\u规范，TLS完成）
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established (messages sent within the TLS channel)
TLS通道已建立（在TLS通道内发送的消息）
<- Basic-Password-Auth-Req TLV, Challenge
<-基本密码验证请求TLV，质询
Basic-Password-Auth-Resp TLV, Response with both username and password) ->
基本密码验证响应TLV，使用用户名和密码进行响应）->
<- Result TLV (Failure)
<-结果TLV（故障）
Result TLV (Failure) ->
结果TLV（故障）->
TLS channel torn down (messages sent in cleartext)
TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
In the case within TEAP Phase 1 where an abbreviated TLS handshake is tried, fails, and falls back to the certificate-based full TLS handshake, the conversation will appear as follows:
在技经评估组第1阶段中，如果尝试了一次简短的TLS握手，但失败，并退回到基于证书的完整TLS握手，对话将如下所示：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route the authentication request to EAP server, instead of the full user identity.
//在清除中发送的标识。可能是帮助将身份验证请求路由到EAP服务器的提示，而不是完整的用户标识。
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello with
PAC-Opaque in SessionTicket extension)->
// Peer sends PAC-Opaque of Tunnel PAC along with a list of ciphersuites supported. If the server rejects the PAC-Opaque, it falls through to the full TLS handshake.
//对等方发送隧道PAC的PAC和支持的密码套件列表。如果服务器拒绝PAC不透明，则会进行完整的TLS握手。
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)
<-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u你好，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u你好\u完成）
EAP-Response/ EAP-Type=TEAP, V=1 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS change_cipher_spec, TLS finished, EAP-Payload-TLV[EAP-Request/ Identity])
EAP响应/EAP类型=TEAP，V=1（[TLS证书，]TLS客户端密钥交换，[TLS证书验证，]TLS更改密码规范，TLS完成）-><-EAP请求/EAP类型=TEAP，V=1（TLS更改密码规范，TLS完成，EAP有效负载TLV[EAP请求/标识]）
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel.
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护。
EAP-Payload-TLV [EAP-Response/Identity (MyID2)]->
EAP有效负载TLV[EAP响应/标识（MyID2）]->
// identity protected by TLS.
//受TLS保护的身份。
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
//方法X交换后进行受保护端接
<- Intermediate-Result-TLV (Success), Crypto-Binding TLV (Request), Result TLV (Success)
<-中间结果TLV（成功）、加密绑定TLV（请求）、结果TLV（成功）
Intermediate-Result-TLV (Success), Crypto-Binding TLV (Response), Result-TLV (Success) ->
中间结果TLV（成功）、加密绑定TLV（响应）、结果TLV（成功）->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
In the case where a certificate-based TLS handshake occurs within TEAP Phase 1 and client certificate authentication and identity privacy is desired (and therefore TLS renegotiation is being used to transmit the peer credentials in the protected TLS tunnel), the conversation will appear as follows:
如果TEAP阶段1内发生基于证书的TLS握手，并且需要客户端证书身份验证和身份隐私（因此TLS重新协商用于在受保护的TLS隧道中传输对等凭据），则对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route the authentication request to EAP server, instead of the full user identity.
//在清除中发送的标识。可能是帮助将身份验证请求路由到EAP服务器的提示，而不是完整的用户标识。
<- EAP-Request/ EAP-Type=TEAP, V=1 (TEAP Start, S bit set, Authority-ID) EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello)-> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_key_exchange, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS change_cipher_spec, TLS finished, EAP-Payload-TLV[EAP-Request/ Identity])
<-EAP请求/EAP类型=TEAP，V=1（TEAP开始，S位设置，权限ID）EAP响应/EAP类型=TEAP，V=1（TLS客户端\u hello）-><-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u hello，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u hello\u完成）EAP响应/EAP类型=TEAP，V=1（TLS客户端密钥交换、TLS更改密码规范、TLS完成）-><-EAP请求/EAP类型=TEAP，V=1（TLS更改密码规范、TLS完成、EAP有效负载TLV[EAP请求/标识]）
// TLS channel established (EAP Payload messages sent within the TLS channel)
//TLS信道已建立（在TLS信道内发送的EAP有效负载消息）
// peer sends TLS client_hello to request TLS renegotiation
//对等方发送TLS客户端\u hello以请求TLS重新协商
TLS client_hello ->
TLS客户端\u您好->
<- TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done
[TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished ->
<- TLS change_cipher_spec, TLS finished, Crypto-Binding TLV (Request), Result TLV (Success)
<-TLS更改\u密码\u规范，TLS完成，加密绑定TLV（请求），结果TLV（成功）
Crypto-Binding TLV (Response), Result-TLV (Success)) ->
加密绑定TLV（响应），结果TLV（成功））->
//TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
In the case where TEAP fragmentation is required, the conversation will appear as follows:
在需要技经评估组分段的情况下，对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done) (Fragment 1: L, M bits set)
<-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u你好，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u你好\u完成）（片段1:L，M位设置）
EAP-Response/
EAP-Type=TEAP, V=1 ->
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 3)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 2: M bit set)
EAP-Response/
EAP-Type=TEAP, V=1 ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(Fragment 3)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished)
(Fragment 1: L, M bits set)->
<- EAP-Request/
EAP-Type=TEAP, V=1
EAP-Response/
EAP-Type=TEAP, V=1
(Fragment 2)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
[EAP-Payload-TLV[
EAP-Request/Identity]])
<- EAP-Request/
EAP-Type=TEAP, V=1
EAP-Response/
EAP-Type=TEAP, V=1
(Fragment 2)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
[EAP-Payload-TLV[
EAP-Request/Identity]])
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel.
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护。
EAP-Payload-TLV [EAP-Response/Identity (MyID2)]->
EAP有效负载TLV[EAP响应/标识（MyID2）]->
// identity protected by TLS.
//受TLS保护的身份。
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
// Method X exchanges followed by Protected Termination
//方法X交换后进行受保护端接
<- Intermediate-Result-TLV (Success), Crypto-Binding TLV (Request), Result TLV (Success)
<-中间结果TLV（成功）、加密绑定TLV（请求）、结果TLV（成功）
Intermediate-Result-TLV (Success), Crypto-Binding TLV (Response), Result-TLV (Success) ->
中间结果TLV（成功）、加密绑定TLV（响应）、结果TLV（成功）->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
When TEAP is negotiated with a sequence of EAP method X followed by method Y, the conversation will occur as follows:
当TEAP与EAP方法X和方法Y的顺序协商时，对话将按如下方式进行：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Identity-Type TLV,
EAP-Payload-TLV[
EAP-Request/Identity])
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS server_hello,
TLS certificate,
[TLS server_key_exchange,]
[TLS certificate_request,]
TLS server_hello_done)
EAP-Response/
EAP-Type=TEAP, V=1
([TLS certificate,]
TLS client_key_exchange,
[TLS certificate_verify,]
TLS change_cipher_spec,
TLS finished) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS change_cipher_spec,
TLS finished,
Identity-Type TLV,
EAP-Payload-TLV[
EAP-Request/Identity])
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护
Identity_Type TLV EAP-Payload-TLV [EAP-Response/Identity] ->
标识\类型TLV EAP有效负载TLV[EAP响应/标识]->
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
// Optional additional X Method exchanges...
//可选的附加X方法交换。。。
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV [EAP-Response/EAP-Type=X]->
EAP有效负载TLV[EAP响应/EAP类型=X]->
<- Intermediate Result TLV (Success), Crypto-Binding TLV (Request), Identity-Type TLV, EAP Payload TLV [EAP-Type=Y],
<-中间结果TLV（成功）、加密绑定TLV（请求）、标识类型TLV、EAP有效负载TLV[EAP Type=Y]，
// Next EAP conversation started after successful completion of previous method X. The Intermediate-Result and Crypto-Binding TLVs are sent in next packet to minimize round trips. In this example, an identity request is not sent before negotiating EAP-Type=Y.
//下一个EAP会话在成功完成前一个方法X后开始。中间结果和加密绑定TLV将在下一个数据包中发送，以最小化往返。在此示例中，在协商EAP Type=Y之前不发送标识请求。
// Compound MAC calculated using keys generated from EAP method X and the TLS tunnel.
//使用EAP方法X和TLS隧道生成的密钥计算复合MAC。
Intermediate Result TLV (Success), Crypto-Binding TLV (Response), EAP-Payload-TLV [EAP-Type=Y] ->
中间结果TLV（成功）、加密绑定TLV（响应）、EAP有效负载TLV[EAP Type=Y]->
// Optional additional Y Method exchanges...
//可选的附加Y方法交换。。。
<- EAP Payload TLV [ EAP-Type=Y]
<-EAP有效负载TLV[EAP类型=Y]
EAP Payload TLV [EAP-Type=Y] ->
EAP有效负载TLV[EAP Type=Y]->
<- Intermediate-Result-TLV (Success), Crypto-Binding TLV (Request), Result TLV (Success)
<-中间结果TLV（成功）、加密绑定TLV（请求）、结果TLV（成功）
Intermediate-Result-TLV (Success), Crypto-Binding TLV (Response), Result-TLV (Success) ->
中间结果TLV（成功）、加密绑定TLV（响应）、结果TLV（成功）->
// Compound MAC calculated using keys generated from EAP methods X and Y and the TLS tunnel. Compound keys are generated using keys generated from EAP methods X and Y and the TLS tunnel.
//使用EAP方法X和Y以及TLS隧道生成的密钥计算复合MAC。使用EAP方法X和Y以及TLS隧道生成的密钥生成复合密钥。
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
The following exchanges show a failed crypto-binding validation. The conversation will appear as follows:
以下交换显示加密绑定验证失败。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello without
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1
(TLS client_hello without
PAC-Opaque in SessionTicket extension)->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TLS Server Key Exchange
TLS Server Hello Done)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS Client Key Exchange
TLS change_cipher_spec,
TLS finished)
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS change_cipher_spec TLS finished) EAP-Payload-TLV[ EAP-Request/Identity])
<-EAP请求/EAP类型=TEAP，V=1（TLS更改\u密码\u规范TLS完成）EAP有效负载TLV[EAP请求/标识]）
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to the TLS Finished as Application Data and protected by the TLS tunnel.
//第一个EAP有效载荷TLV作为应用程序数据装载到TLS，并由TLS隧道保护。
EAP-Payload TLV/ EAP Identity Response ->
EAP有效负载TLV/EAP标识响应->
<- EAP Payload TLV, EAP-Request, (EAP-MSCHAPV2, Challenge)
<-EAP有效负载TLV，EAP请求，（EAP-MSCHAPV2，质询）
EAP Payload TLV, EAP-Response, (EAP-MSCHAPV2, Response) ->
EAP有效负载TLV，EAP响应，（EAP-MSCHAPV2，响应）->
<- EAP Payload TLV, EAP-Request, (EAP-MSCHAPV2, Success Request)
<-EAP有效负载TLV，EAP请求，（EAP-MSCHAPV2，成功请求）
EAP Payload TLV, EAP-Response, (EAP-MSCHAPV2, Success Response) ->
EAP有效负载TLV，EAP响应，（EAP-MSCHAPV2，成功响应）->
<- Intermediate-Result-TLV (Success), Crypto-Binding TLV (Request), Result TLV (Success)
<-中间结果TLV（成功）、加密绑定TLV（请求）、结果TLV（成功）
Intermediate-Result-TLV (Success), Result TLV (Failure) Error TLV with (Error Code = 2001) ->
中间结果TLV（成功），结果TLV（失败）错误TLV（错误代码=2001）->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Failure
<-EAP故障
When TEAP is negotiated with a sequence of EAP methods followed by a Vendor-Specific TLV exchange, the conversation will occur as follows:
当技经评估组与一系列EAP方法协商，然后进行供应商特定的TLV交换时，对话将按如下方式进行：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello)-> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)
EAP响应/EAP类型=TEAP，V=1（TLS客户端\u hello）-><-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u hello，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u hello\u完成）
EAP-Response/ EAP-Type=TEAP, V=1 ([TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS change_cipher_spec, TLS finished, EAP-Payload-TLV[ EAP-Request/Identity])
EAP响应/EAP类型=TEAP，V=1（[TLS证书，]TLS客户端密钥交换，[TLS证书验证，]TLS更改密码规范，TLS完成）-><-EAP请求/EAP类型=TEAP，V=1（TLS更改密码规范，TLS完成，EAP有效负载TLV[EAP请求/标识]）
// TLS channel established (messages sent within the TLS channel)
//TLS通道已建立（在TLS通道内发送的消息）
// First EAP Payload TLV is piggybacked to 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-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV [EAP-Response/EAP-Type=X]->
EAP有效负载TLV[EAP响应/EAP类型=X]->
<- Intermediate Result TLV (Success), Crypto-Binding TLV (Request), Vendor-Specific TLV,
<-中间结果TLV（成功）、加密绑定TLV（请求）、供应商特定TLV、，
// Vendor-Specific TLV exchange started after successful completion of previous method X. The Intermediate-Result and Crypto-Binding TLVs are sent with Vendor-Specific TLV in next packet to minimize round trips.
//供应商特定TLV交换在成功完成之前的方法X后开始。中间结果和加密绑定TLV在下一个数据包中与供应商特定TLV一起发送，以最小化往返。
// Compound MAC calculated using keys generated from EAP method X and the TLS tunnel.
//使用EAP方法X和TLS隧道生成的密钥计算复合MAC。
Intermediate Result TLV (Success), Crypto-Binding TLV (Response), Vendor-Specific TLV ->
中间结果TLV（成功）、加密绑定TLV（响应）、特定于供应商的TLV->
// Optional additional Vendor-Specific TLV exchanges...
//可选的附加供应商特定TLV交换。。。
<- Vendor-Specific TLV
<-特定于供应商的TLV
Vendor-Specific TLV -> <- Result TLV (Success)
供应商特定TLV-><-结果TLV（成功）
Result-TLV (Success) ->
结果TLV（成功）->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
In the case where the peer is authenticated during Phase 1 and the server sends back a Result TLV but the peer wants to request another inner method, the conversation will appear as follows:
如果对等方在阶段1期间经过身份验证，并且服务器发回结果TLV，但对等方希望请求另一个内部方法，则对话将如下所示：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/Identity
EAP-Response/
Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route the authentication request to EAP server, instead of the full user identity.
//在清除中发送的标识。可能是帮助将身份验证请求路由到EAP服务器的提示，而不是完整的用户标识。
<- EAP-Request/ EAP-Type=TEAP, V=1 (TEAP Start, S bit set, Authority-ID) EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello)-> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, TLS certificate, [TLS server_key_exchange,] [TLS certificate_request,] TLS server_hello_done)
<-EAP请求/EAP类型=TEAP，V=1（TEAP开始，S位设置，权限ID）EAP响应/EAP类型=TEAP，V=1（TLS客户端\u hello）-><-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u hello，TLS证书，[TLS服务器\u密钥交换，][TLS证书\u请求，]TLS服务器\u hello\u完成）
EAP-Response/ EAP-Type=TEAP, V=1 [TLS certificate,] TLS client_key_exchange, [TLS certificate_verify,] TLS change_cipher_spec, TLS finished -> <- EAP-Request/ EAP-Type=TEAP, V=1 (TLS change_cipher_spec, TLS finished, Crypto-Binding TLV (Request), Result TLV (Success))
EAP响应/EAP Type=TEAP，V=1[TLS证书，]TLS客户端密钥交换，[TLS证书验证，]TLS更改密码规范，TLS完成-><-EAP请求/EAP Type=TEAP，V=1（TLS更改密码规范，TLS完成，加密绑定TLV（请求），结果TLV（成功））
// TLS channel established (TLV Payload messages sent within the TLS channel)
//TLS信道已建立（TLS信道内发送的TLV有效负载消息）
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Negotiate-EAP)->
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Negotiate-EAP)->
<- EAP-Payload-TLV [EAP-Request/Identity]
<-EAP有效负载TLV[EAP请求/标识]
EAP-Payload-TLV [EAP-Response/Identity] ->
EAP有效负载TLV[EAP响应/标识]->
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
EAP-Payload-TLV
[EAP-Response/EAP-Type=X] ->
<- EAP-Payload-TLV [EAP-Request/EAP-Type=X]
<-EAP有效负载TLV[EAP请求/EAP类型=X]
EAP-Payload-TLV [EAP-Response/EAP-Type=X]->
EAP有效负载TLV[EAP响应/EAP类型=X]->
<- Intermediate Result TLV (Success), Crypto-Binding TLV (Request), Result TLV (Success)
<-中间结果TLV（成功）、加密绑定TLV（请求）、结果TLV（成功）
Intermediate Result TLV (Success), Crypto-Binding TLV (Response), Result-TLV (Success)) ->
中间结果TLV（成功）、加密绑定TLV（响应）、结果TLV（成功））->
// TLS channel torn down (messages sent in cleartext)
//TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
The following exchanges show a successful TEAP authentication with basic password authentication and channel binding using a Request-Action TLV. The conversation will appear as follows:
以下交换显示了一个成功的TEAP身份验证，使用请求操作TLV进行基本密码身份验证和通道绑定。对话将显示如下：
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
Authenticating Peer Authenticator
------------------- -------------
<- EAP-Request/
Identity
EAP-Response/
Identity (MyID1) ->
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
<- EAP-Request/
EAP-Type=TEAP, V=1
(TEAP Start, S bit set, Authority-ID)
EAP-Response/ EAP-Type=TEAP, V=1 (TLS client_hello with PAC-Opaque in SessionTicket extension)->
EAP响应/EAP类型=TEAP，V=1（TLS客户端\u你好，会话密钥扩展中PAC不透明）->
<- EAP-Request/ EAP-Type=TEAP, V=1 (TLS server_hello, (TLS change_cipher_spec, TLS finished)
<-EAP请求/EAP类型=TEAP，V=1（TLS服务器\u您好，（TLS更改\u密码\u规范，TLS完成）
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
EAP-Response/
EAP-Type=TEAP, V=1 ->
(TLS change_cipher_spec,
TLS finished)
TLS channel established (messages sent within the TLS channel)
TLS通道已建立（在TLS通道内发送的消息）
<- Basic-Password-Auth-Req TLV, Challenge
<-基本密码验证请求TLV，质询
Basic-Password-Auth-Resp TLV, Response with both username and password) ->
基本密码验证响应TLV，使用用户名和密码进行响应）->
optional additional exchanges (new pin mode, password change, etc.) ...
可选的附加交换（新pin模式、密码更改等）。。。
<- Crypto-Binding TLV (Request), Result TLV (Success),
<-加密绑定TLV（请求），结果TLV（成功），
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Process-TLV,
TLV=Channel-Binding TLV)->
Crypto-Binding TLV(Response),
Request-Action TLV
(Status=Failure, Action=Process-TLV,
TLV=Channel-Binding TLV)->
<- Channel-Binding TLV (Response), Result TLV (Success),
<-通道绑定TLV（响应），结果TLV（成功），
Result-TLV (Success) ->
结果TLV（成功）->
TLS channel torn down (messages sent in cleartext)
TLS通道中断（以明文发送的消息）
<- EAP-Success
<-EAP成功
Authors' Addresses
作者地址
Hao Zhou Cisco Systems 4125 Highlander Parkway Richfield, OH 44286 US
郝州思科系统4125美国俄亥俄州汉兰达大道里奇菲尔德44286号
EMail: hzhou@cisco.com
EMail: hzhou@cisco.com
Nancy Cam-Winget Cisco Systems 3625 Cisco Way San Jose, CA 95134 US
美国加利福尼亚州圣何塞市思科路3625号南希·坎·威吉思科系统公司，邮编95134
EMail: ncamwing@cisco.com
EMail: ncamwing@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
Stephen Hanna Infineon Technologies 79 Parsons Street Brighton, MA 02135 US
斯蒂芬·汉娜·英飞凌科技美国马萨诸塞州布莱顿帕森斯街79号，邮编02135
EMail: steve.hanna@infineon.com
EMail: steve.hanna@infineon.com