draft-ietf-emu-rfc7170bis-15.txt | draft-ietf-emu-rfc7170bis-16.txt | |||
---|---|---|---|---|
EMU working group A. DeKok (Ed) | EMU working group A. DeKok (Ed) | |||
Internet-Draft 26 February 2024 | Internet-Draft 26 March 2024 | |||
Obsoletes: 7170 (if approved) | Obsoletes: 7170 (if approved) | |||
Updates: 9427 (if approved) | Updates: 9427 (if approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: 29 August 2024 | Expires: 27 September 2024 | |||
Tunnel Extensible Authentication Protocol (TEAP) Version 1 | Tunnel Extensible Authentication Protocol (TEAP) Version 1 | |||
draft-ietf-emu-rfc7170bis-15 | draft-ietf-emu-rfc7170bis-16 | |||
Abstract | Abstract | |||
This document defines the Tunnel Extensible Authentication Protocol | This document defines the Tunnel Extensible Authentication Protocol | |||
(TEAP) version 1. TEAP is a tunnel-based EAP method that enables | (TEAP) version 1. TEAP is a tunnel-based EAP method that enables | |||
secure communication between a peer and a server by using the | secure communication between a peer and a server by using the | |||
Transport Layer Security (TLS) protocol to establish a mutually | Transport Layer Security (TLS) protocol to establish a mutually | |||
authenticated tunnel. Within the tunnel, TLV objects are used to | authenticated tunnel. Within the tunnel, TLV objects are used to | |||
convey authentication-related data between the EAP peer and the EAP | convey authentication-related data between the EAP peer and the EAP | |||
server. This document obsoletes RFC 7170. | server. This document obsoletes RFC 7170. | |||
skipping to change at page 2, line 10 ¶ | skipping to change at page 2, line 10 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on 29 August 2024. | This Internet-Draft will expire on 27 September 2024. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
skipping to change at page 3, line 39 ¶ | skipping to change at page 3, line 39 ¶ | |||
4.2.13. Crypto-Binding TLV . . . . . . . . . . . . . . . . . 50 | 4.2.13. Crypto-Binding TLV . . . . . . . . . . . . . . . . . 50 | |||
4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . . 53 | 4.2.14. Basic-Password-Auth-Req TLV . . . . . . . . . . . . . 53 | |||
4.2.15. Basic-Password-Auth-Resp TLV . . . . . . . . . . . . 54 | 4.2.15. Basic-Password-Auth-Resp TLV . . . . . . . . . . . . 54 | |||
4.2.16. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . 55 | 4.2.16. PKCS#7 TLV . . . . . . . . . . . . . . . . . . . . . 55 | |||
4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 56 | 4.2.17. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 56 | |||
4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . . 57 | 4.2.18. Trusted-Server-Root TLV . . . . . . . . . . . . . . . 57 | |||
4.2.19. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 59 | 4.2.19. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 59 | |||
4.2.20. Identity-Hint TLV . . . . . . . . . . . . . . . . . . 60 | 4.2.20. Identity-Hint TLV . . . . . . . . . . . . . . . . . . 60 | |||
4.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 61 | 4.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
4.3.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . 62 | 4.3.1. Outer TLVs . . . . . . . . . . . . . . . . . . . . . 62 | |||
4.3.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . 62 | 4.3.2. Inner TLVs . . . . . . . . . . . . . . . . . . . . . 63 | |||
5. Cryptographic Calculations . . . . . . . . . . . . . . . . . 63 | 5. Cryptographic Calculations . . . . . . . . . . . . . . . . . 63 | |||
5.1. TEAP Authentication Phase 1: Key Derivations . . . . . . 63 | 5.1. TEAP Authentication Phase 1: Key Derivations . . . . . . 63 | |||
5.2. Intermediate Compound Key Derivations . . . . . . . . . . 64 | 5.2. Intermediate Compound Key Derivations . . . . . . . . . . 64 | |||
5.3. Computing the Compound MAC . . . . . . . . . . . . . . . 67 | 5.3. Computing the Compound MAC . . . . . . . . . . . . . . . 67 | |||
5.4. EAP Master Session Key Generation . . . . . . . . . . . . 68 | 5.4. EAP Master Session Key Generation . . . . . . . . . . . . 68 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 | |||
6.1. TEAP TLV Types . . . . . . . . . . . . . . . . . . . . . 69 | 6.1. TEAP TLV Types . . . . . . . . . . . . . . . . . . . . . 69 | |||
6.2. TEAP Error TLV (value 5) Error Codes . . . . . . . . . . 69 | 6.2. TEAP Error TLV (value 5) Error Codes . . . . . . . . . . 70 | |||
6.3. TLS Exporter Labels . . . . . . . . . . . . . . . . . . . 70 | 6.3. TLS Exporter Labels . . . . . . . . . . . . . . . . . . . 70 | |||
6.4. Extended Master Session Key (EMSK) Parameters . . . . . . 70 | 6.4. Extended Master Session Key (EMSK) Parameters . . . . . . 71 | |||
6.5. Extensible Authentication Protocol (EAP) Registry . . . . 70 | 6.5. Extensible Authentication Protocol (EAP) Registry . . . . 71 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 70 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 71 | |||
7.1. Mutual Authentication and Integrity Protection . . . . . 70 | 7.1. Mutual Authentication and Integrity Protection . . . . . 71 | |||
7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . 71 | 7.2. Method Negotiation . . . . . . . . . . . . . . . . . . . 72 | |||
7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 71 | 7.3. Separation of Phase 1 and Phase 2 Servers . . . . . . . . 72 | |||
7.4. Mitigation of Known Vulnerabilities and Protocol | 7.4. Mitigation of Known Vulnerabilities and Protocol | |||
Deficiencies . . . . . . . . . . . . . . . . . . . . . . 72 | Deficiencies . . . . . . . . . . . . . . . . . . . . . . 73 | |||
7.4.1. User Identity Protection and Verification . . . . . . 73 | 7.4.1. User Identity Protection and Verification . . . . . . 74 | |||
7.5. Dictionary Attack Resistance . . . . . . . . . . . . . . 74 | 7.5. Dictionary Attack Resistance . . . . . . . . . . . . . . 75 | |||
7.5.1. Protection against On-Path Attacks . . . . . . . . . 74 | 7.5.1. Protection against On-Path Attacks . . . . . . . . . 75 | |||
7.6. Protecting against Forged Cleartext EAP Packets . . . . . 75 | 7.6. Protecting against Forged Cleartext EAP Packets . . . . . 76 | |||
7.7. Use of Clear-text Passwords . . . . . . . . . . . . . . . 75 | 7.7. Use of Clear-text Passwords . . . . . . . . . . . . . . . 76 | |||
7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 75 | 7.8. Security Claims . . . . . . . . . . . . . . . . . . . . . 76 | |||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 | |||
9. Changes from RFC 7170 . . . . . . . . . . . . . . . . . . . . 77 | 9. Changes from RFC 7170 . . . . . . . . . . . . . . . . . . . . 78 | |||
Appendix A Evaluation against Tunnel-Based EAP Method | Appendix A Evaluation against Tunnel-Based EAP Method | |||
Requirements . . . . . . . . . . . . . . . . . . . . . . 78 | Requirements . . . . . . . . . . . . . . . . . . . . . . 79 | |||
A.1. Requirement 4.1.1: RFC Compliance . . . . . . . . . . . . 78 | A.1. Requirement 4.1.1: RFC Compliance . . . . . . . . . . . . 79 | |||
A.2. Requirement 4.2.1: TLS Requirements . . . . . . . . . . . 78 | A.2. Requirement 4.2.1: TLS Requirements . . . . . . . . . . . 79 | |||
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation . . . . . 78 | A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation . . . . . 79 | |||
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection | A.4. Requirement 4.2.1.1.2: Tunnel Data Protection | |||
Algorithms . . . . . . . . . . . . . . . . . . . . . . . 79 | Algorithms . . . . . . . . . . . . . . . . . . . . . . . 80 | |||
A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key | A.5. Requirement 4.2.1.1.3: Tunnel Authentication and Key | |||
Establishment . . . . . . . . . . . . . . . . . . . . . 79 | Establishment . . . . . . . . . . . . . . . . . . . . . 80 | |||
A.6. Requirement 4.2.1.2: Tunnel Replay Protection . . . . . . 79 | A.6. Requirement 4.2.1.2: Tunnel Replay Protection . . . . . . 80 | |||
A.7. Requirement 4.2.1.3: TLS Extensions . . . . . . . . . . . 79 | A.7. Requirement 4.2.1.3: TLS Extensions . . . . . . . . . . . 80 | |||
A.8. Requirement 4.2.1.4: Peer Identity Privacy . . . . . . . 79 | A.8. Requirement 4.2.1.4: Peer Identity Privacy . . . . . . . 80 | |||
A.9. Requirement 4.2.1.5: Session Resumption . . . . . . . . . 79 | A.9. Requirement 4.2.1.5: Session Resumption . . . . . . . . . 80 | |||
A.10. Requirement 4.2.2: Fragmentation . . . . . . . . . . . . 79 | A.10. Requirement 4.2.2: Fragmentation . . . . . . . . . . . . 80 | |||
A.11. Requirement 4.2.3: Protection of Data External to | A.11. Requirement 4.2.3: Protection of Data External to | |||
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 79 | Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 80 | |||
A.12. Requirement 4.3.1: Extensible Attribute Types . . . . . 80 | A.12. Requirement 4.3.1: Extensible Attribute Types . . . . . 81 | |||
A.13. Requirement 4.3.2: Request/Challenge Response | A.13. Requirement 4.3.2: Request/Challenge Response | |||
Operation . . . . . . . . . . . . . . . . . . . . . . . 80 | Operation . . . . . . . . . . . . . . . . . . . . . . . 81 | |||
A.14. Requirement 4.3.3: Indicating Criticality of | A.14. Requirement 4.3.3: Indicating Criticality of | |||
Attributes . . . . . . . . . . . . . . . . . . . . . . . 80 | Attributes . . . . . . . . . . . . . . . . . . . . . . . 81 | |||
A.15. Requirement 4.3.4: Vendor-Specific Support . . . . . . . 80 | A.15. Requirement 4.3.4: Vendor-Specific Support . . . . . . . 81 | |||
A.16. Requirement 4.3.5: Result Indication . . . . . . . . . . 80 | A.16. Requirement 4.3.5: Result Indication . . . . . . . . . . 81 | |||
A.17. Requirement 4.3.6: Internationalization of Display | A.17. Requirement 4.3.6: Internationalization of Display | |||
Strings . . . . . . . . . . . . . . . . . . . . . . . . 80 | Strings . . . . . . . . . . . . . . . . . . . . . . . . 81 | |||
A.18. Requirement 4.4: EAP Channel-Binding Requirements . . . 80 | A.18. Requirement 4.4: EAP Channel-Binding Requirements . . . 81 | |||
A.19. Requirement 4.5.1.1: Confidentiality and Integrity . . . 80 | A.19. Requirement 4.5.1.1: Confidentiality and Integrity . . . 81 | |||
A.20. Requirement 4.5.1.2: Authentication of Server . . . . . 81 | A.20. Requirement 4.5.1.2: Authentication of Server . . . . . 82 | |||
A.21. Requirement 4.5.1.3: Server Certificate Revocation | A.21. Requirement 4.5.1.3: Server Certificate Revocation | |||
Checking . . . . . . . . . . . . . . . . . . . . . . . . 81 | Checking . . . . . . . . . . . . . . . . . . . . . . . . 82 | |||
A.22. Requirement 4.5.2: Internationalization . . . . . . . . 81 | A.22. Requirement 4.5.2: Internationalization . . . . . . . . 82 | |||
A.23. Requirement 4.5.3: Metadata . . . . . . . . . . . . . . 81 | A.23. Requirement 4.5.3: Metadata . . . . . . . . . . . . . . 82 | |||
A.24. Requirement 4.5.4: Password Change . . . . . . . . . . . 81 | A.24. Requirement 4.5.4: Password Change . . . . . . . . . . . 82 | |||
A.25. Requirement 4.6.1: Method Negotiation . . . . . . . . . 81 | A.25. Requirement 4.6.1: Method Negotiation . . . . . . . . . 82 | |||
A.26. Requirement 4.6.2: Chained Methods . . . . . . . . . . . 81 | A.26. Requirement 4.6.2: Chained Methods . . . . . . . . . . . 82 | |||
A.27. Requirement 4.6.3: Cryptographic Binding with the TLS | A.27. Requirement 4.6.3: Cryptographic Binding with the TLS | |||
Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 81 | Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . 82 | |||
A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication . . 82 | A.28. Requirement 4.6.4: Peer-Initiated EAP Authentication . . 83 | |||
A.29. Requirement 4.6.5: Method Metadata . . . . . . . . . . . 82 | A.29. Requirement 4.6.5: Method Metadata . . . . . . . . . . . 83 | |||
Appendix B. Major Differences from EAP-FAST . . . . . . . . . . 82 | Appendix B. Major Differences from EAP-FAST . . . . . . . . . . 83 | |||
Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 82 | Appendix C. Examples . . . . . . . . . . . . . . . . . . . . . . 83 | |||
C.1. Successful Authentication . . . . . . . . . . . . . . . . 83 | C.1. Successful Authentication . . . . . . . . . . . . . . . . 84 | |||
C.2. Failed Authentication . . . . . . . . . . . . . . . . . . 84 | C.2. Failed Authentication . . . . . . . . . . . . . . . . . . 85 | |||
C.3. Full TLS Handshake Using Certificate-Based Cipher | C.3. Full TLS Handshake Using Certificate-Based Cipher | |||
Suite . . . . . . . . . . . . . . . . . . . . . . . . . 86 | Suite . . . . . . . . . . . . . . . . . . . . . . . . . 87 | |||
C.4. Client Authentication during Phase 1 with Identity | C.4. Client Authentication during Phase 1 with Identity | |||
Privacy . . . . . . . . . . . . . . . . . . . . . . . . 87 | Privacy . . . . . . . . . . . . . . . . . . . . . . . . 88 | |||
C.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 89 | C.5. Fragmentation and Reassembly . . . . . . . . . . . . . . 90 | |||
C.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 91 | C.6. Sequence of EAP Methods . . . . . . . . . . . . . . . . . 92 | |||
C.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 93 | C.7. Failed Crypto-Binding . . . . . . . . . . . . . . . . . . 94 | |||
C.8. Sequence of EAP Method with Vendor-Specific TLV | C.8. Sequence of EAP Method with Vendor-Specific TLV | |||
Exchange . . . . . . . . . . . . . . . . . . . . . . . . 94 | Exchange . . . . . . . . . . . . . . . . . . . . . . . . 95 | |||
C.9. Peer Requests Inner Method after Server Sends Result | C.9. Peer Requests Inner Method after Server Sends Result | |||
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . 96 | TLV . . . . . . . . . . . . . . . . . . . . . . . . . . 97 | |||
C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . 98 | C.10. Channel Binding . . . . . . . . . . . . . . . . . . . . 99 | |||
C.11. PKCS Exchange . . . . . . . . . . . . . . . . . . . . . 99 | C.11. PKCS Exchange . . . . . . . . . . . . . . . . . . . . . 100 | |||
C.12. Failure Scenario . . . . . . . . . . . . . . . . . . . . 101 | C.12. Failure Scenario . . . . . . . . . . . . . . . . . . . . 102 | |||
C.13. Client certificate in Phase 1 . . . . . . . . . . . . . 102 | C.13. Client certificate in Phase 1 . . . . . . . . . . . . . 103 | |||
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 | References . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 | |||
Normative References . . . . . . . . . . . . . . . . . . . . . 103 | Normative References . . . . . . . . . . . . . . . . . . . . . 104 | |||
Informative References . . . . . . . . . . . . . . . . . . . . 105 | Informative References . . . . . . . . . . . . . . . . . . . . 106 | |||
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 110 | Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 111 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 110 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 111 | |||
1. Introduction | 1. Introduction | |||
A tunnel-based Extensible Authentication Protocol (EAP) method is an | A tunnel-based Extensible Authentication Protocol (EAP) method is an | |||
EAP method that establishes a secure tunnel and executes other EAP | EAP method that establishes a secure tunnel and executes other EAP | |||
methods under the protection of that secure tunnel. A tunnel-based | methods under the protection of that secure tunnel. A tunnel-based | |||
EAP method can be used in any lower-layer protocol that supports EAP | EAP method can be used in any lower-layer protocol that supports EAP | |||
authentication. There are several existing tunnel-based EAP methods | authentication. There are several existing tunnel-based EAP methods | |||
that use Transport Layer Security (TLS) [RFC8446] to establish the | that use Transport Layer Security (TLS) [RFC8446] to establish the | |||
secure tunnel. EAP methods supporting this include Protected EAP | secure tunnel. EAP methods supporting this include Protected EAP | |||
skipping to change at page 6, line 39 ¶ | skipping to change at page 6, line 39 ¶ | |||
1.2. Terminology | 1.2. Terminology | |||
Much of the terminology in this document comes from [RFC3748]. | Much of the terminology in this document comes from [RFC3748]. | |||
Additional terms are defined below: | Additional terms are defined below: | |||
Type-Length-Value (TLV) | Type-Length-Value (TLV) | |||
The TEAP protocol utilizes objects in TLV format. The TLV format | The TEAP protocol utilizes objects in TLV format. The TLV format | |||
is defined in Section 4.2. | is defined in Section 4.2. | |||
Inner method | Inner Method | |||
An authentication method which is sent as application data inside | An authentication method which is sent as application data inside | |||
of a TLS exchange which is carried over TEAP. The inner method | of a TLS exchange which is carried over TEAP. The inner method | |||
can be an EAP authentication method, a username / password | can be an EAP authentication method, a username / password | |||
authentication, or a vendor-specific authentication method. Where | authentication, or a vendor-specific authentication method. Where | |||
the TLS connection is authenticated, the inner method could also | the TLS connection is authenticated, the inner method could also | |||
be a PKCS exchange. | be a PKCS exchange. | |||
2. Protocol Overview | 2. Protocol Overview | |||
skipping to change at page 11, line 42 ¶ | skipping to change at page 11, line 42 ¶ | |||
peer and server MUST be TLS version 1.2 [RFC5246] or later. This | peer and server MUST be TLS version 1.2 [RFC5246] or later. This | |||
version of the TEAP implementation MUST support the following TLS | version of the TEAP implementation MUST support the following TLS | |||
cipher suites: | cipher suites: | |||
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | * TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | |||
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | * TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | |||
Other cipher suites MAY be supported. Implementations MUST implement | Other cipher suites MAY be supported. Implementations MUST implement | |||
the recommended cipher suites in [RFC9325] Section 4.2 for TLS 1.2, | the recommended cipher suites in [RFC9325] Section 4.2 for TLS 1.2, | |||
and in [RFC9325] Section 4.2 for TLS 1.3. | and in [RFC9325] Section 4.3 for TLS 1.3. | |||
It is REQUIRED that anonymous cipher suites such as | It is REQUIRED that anonymous cipher suites such as | |||
TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case | TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case | |||
when the inner method provides mutual authentication, key generation, | when the inner method provides mutual authentication, key generation, | |||
and resistance to on-path and dictionary attacks. TLS cipher suites | and resistance to on-path and dictionary attacks. TLS cipher suites | |||
that do not provide confidentiality MUST NOT be used. During the | that do not provide confidentiality MUST NOT be used. During the | |||
TEAP Phase 1, the TEAP endpoints MAY negotiate TLS compression. | TEAP Phase 1, the TEAP endpoints MAY negotiate TLS compression. | |||
During TLS tunnel establishment, TLS extensions MAY be used. For | During TLS tunnel establishment, TLS extensions MAY be used. For | |||
instance, the Certificate Status Request extension [RFC6066] and the | instance, the Certificate Status Request extension [RFC6066] and the | |||
Multiple Certificate Status Request extension [RFC6961] can be used | Multiple Certificate Status Request extension [RFC6961] can be used | |||
skipping to change at page 13, line 16 ¶ | skipping to change at page 13, line 16 ¶ | |||
Server Certificates MUST include a subjectAltName extension, with the | Server Certificates MUST include a subjectAltName extension, with the | |||
dnsName attribute containing an FQDN string. Server certificates MAY | dnsName attribute containing an FQDN string. Server certificates MAY | |||
also include with a SubjectDN containing a single element, "CN=" | also include with a SubjectDN containing a single element, "CN=" | |||
containing the FQDN of the server. However, this use of SubjectDN is | containing the FQDN of the server. However, this use of SubjectDN is | |||
deprecated for TEAP, and is forbidden in [RFC9525] Section 2. | deprecated for TEAP, and is forbidden in [RFC9525] Section 2. | |||
The KeyUsage extension MAY be included, but are not required. | The KeyUsage extension MAY be included, but are not required. | |||
The ExtendedKeyUsage extensions defined in [RFC5280] MAY also be | The ExtendedKeyUsage extensions defined in [RFC5280] MAY also be | |||
included, but their use is discouraged. Systems SHOULD use a a | included, but their use is discouraged. Systems SHOULD use a private | |||
private Certification Authority (CA) for EAP in preference to public | Certification Authority (CA) for EAP in preference to public CAs. | |||
CAs. | ||||
3.4. Server Certificate Validation | 3.4. Server Certificate Validation | |||
As part of the TLS negotiation, the server usually presents a | As part of the TLS negotiation, the server usually presents a | |||
certificate to the peer. In most cases the certificate needs to be | certificate to the peer. In most cases the certificate needs to be | |||
validated, but there are a number of situations where the EAP peer | validated, but there are a number of situations where the EAP peer | |||
need not do certificate validation: | need not do certificate validation: | |||
* when the peer has the Server's End Entity (EE) certificate pinned | * when the peer has the Server's End Entity (EE) certificate pinned | |||
or loaded directly into it's Trusted Anchor store [RFC4949]; | or loaded directly into it's Trusted Anchor store [RFC4949]; | |||
skipping to change at page 18, line 48 ¶ | skipping to change at page 18, line 48 ¶ | |||
The basic password authentication defined here is similar in | The basic password authentication defined here is similar in | |||
functionality to that used by EAP-TTLS ([RFC5281]) with inner | functionality to that used by EAP-TTLS ([RFC5281]) with inner | |||
password authentication. It shares a similar security and risk | password authentication. It shares a similar security and risk | |||
analysis. | analysis. | |||
Multiple round trips of password authentication requests and | Multiple round trips of password authentication requests and | |||
responses MAY be used to support some "housekeeping" functions such | responses MAY be used to support some "housekeeping" functions such | |||
as a password or pin change before a user is considered to be | as a password or pin change before a user is considered to be | |||
authenticated. Multiple rounds MAY also be used to communicate a | authenticated. Multiple rounds MAY also be used to communicate a | |||
users password, and separately a one-time password such as TOTP | users password, and separately a one-time password such as Time-Based | |||
[RFC6238]. | One-Time Passwords (TOTP) [RFC6238]. | |||
Implementations MUST limit the number of rounds trips for password | Implementations MUST limit the number of rounds trips for password | |||
authentication. It is reasonable to use one or two round trips. | authentication. It is reasonable to use one or two round trips. | |||
Further round trips are likely to be problematic, and SHOULD be | Further round trips are likely to be problematic, and SHOULD be | |||
avoided. | avoided. | |||
The first Basic-Password-Auth-Req TLV received in a session MUST | The first Basic-Password-Auth-Req TLV received in a session MUST | |||
include a prompt, which the peer displays to the user. Subsequent | include a prompt, which the peer displays to the user. Subsequent | |||
authentication rounds SHOULD include a prompt, but it is not always | authentication rounds SHOULD include a prompt, but it is not always | |||
necessary. | necessary. | |||
skipping to change at page 19, line 40 ¶ | skipping to change at page 19, line 40 ¶ | |||
server MUST send an Intermediate-Result TLV indicating the result. | server MUST send an Intermediate-Result TLV indicating the result. | |||
The peer MUST respond to the Intermediate-Result TLV indicating its | The peer MUST respond to the Intermediate-Result TLV indicating its | |||
result. If the result indicates success, the Intermediate-Result TLV | result. If the result indicates success, the Intermediate-Result TLV | |||
MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV | MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV | |||
is further discussed in Section 4.2.13 and Section 5.3. | is further discussed in Section 4.2.13 and Section 5.3. | |||
The Intermediate-Result TLVs can be included with other TLVs which | The Intermediate-Result TLVs can be included with other TLVs which | |||
indicate a subsequent authentication, or with the Result TLV used in | indicate a subsequent authentication, or with the Result TLV used in | |||
the protected termination exchange. | the protected termination exchange. | |||
The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT | The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED | |||
RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with | with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC | |||
EAP-GTC defined in [RFC3748]. Implementations should instead make | defined in [RFC3748]. Implementations should instead make use of the | |||
use of the password authentication TLVs defined in this | password authentication TLVs defined in this specification. | |||
specification. | ||||
3.6.3. EAP-MSCHAPv2 | 3.6.3. EAP-MSCHAPv2 | |||
If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST- | If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST- | |||
MSCHAPv2 variant defined in Section 3.2.3 of [RFC5422] MUST be used, | MSCHAPv2 variant defined in Section 3.2.3 of [RFC5422] MUST be used, | |||
instead of the derivation defined in [MSCHAP]. | instead of the derivation defined in [MSCHAP]. | |||
The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the | The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the | |||
first and the second 16 octets of EAP-MSCHAPv2 MSK are swapped when | first and the second 16 octets of EAP-MSCHAPv2 MSK are swapped when | |||
it is used as the Inner Method Session Keys (IMSK) for TEAP. | it is used as the Inner Method Session Keys (IMSK) for TEAP. | |||
skipping to change at page 29, line 5 ¶ | skipping to change at page 29, line 5 ¶ | |||
with an Error TLV using the most descriptive error code possible; it | with an Error TLV using the most descriptive error code possible; it | |||
MAY ignore the PKCS#10 request that generated the error. | MAY ignore the PKCS#10 request that generated the error. | |||
3.11.2. Certificate Content and Uses | 3.11.2. Certificate Content and Uses | |||
It is not enough to verify that the CSR provided by the peer to the | It is not enough to verify that the CSR provided by the peer to the | |||
authenticator is from an authenticated user. The CSR itself should | authenticator is from an authenticated user. The CSR itself should | |||
also be examined by the authenticator or Certification Authority (CA) | also be examined by the authenticator or Certification Authority (CA) | |||
before any certificate is issued. | before any certificate is issued. | |||
The format of a CSR is complex, and contain a substantial amount of | The format of a CSR is complex, and contains a substantial amount of | |||
information. That information could be incorrect, such as a user | information. That information could be incorrect, such as a user | |||
claiming a wrong physical address, email address, etc. | claiming a wrong physical address, email address, etc. | |||
Alternatively, the supplied information could contain private data | Alternatively, the supplied information could contain private data | |||
which should not be sent over a TLS 1.2 connection where that data | which should not be sent over a TLS 1.2 connection where that data | |||
would be exposed. | would be exposed. | |||
It is RECOMMENDED that systems provisioning these certificates | It is RECOMMENDED that systems provisioning these certificates | |||
validate that the CSR both contains the expected data, and also that | validate that the CSR both contains the expected data, and also that | |||
is does not contain unexpected data. For example, a CA could refuse | is does not contain unexpected data. For example, a CA could refuse | |||
to issue the certificate if the CSR contained unknown fields, or a | to issue the certificate if the CSR contained unknown fields, or a | |||
skipping to change at page 31, line 5 ¶ | skipping to change at page 31, line 5 ¶ | |||
Implementations SHOULD exchange minimal data in Server | Implementations SHOULD exchange minimal data in Server | |||
Unauthenticated Provisioning Mode. Instead, they should use that | Unauthenticated Provisioning Mode. Instead, they should use that | |||
mode to set up a secure / authenticated tunnel, and then use that | mode to set up a secure / authenticated tunnel, and then use that | |||
tunnel to perform any needed data exchange. | tunnel to perform any needed data exchange. | |||
It is RECOMMENDED that client implementations and deployments | It is RECOMMENDED that client implementations and deployments | |||
authenticate TEAP servers if at all possible. Authenticating the | authenticate TEAP servers if at all possible. Authenticating the | |||
server means that a client can be provisioned securely with no chance | server means that a client can be provisioned securely with no chance | |||
of an attacker eaves-dropping on the connection. | of an attacker eaves-dropping on the connection. | |||
Note that server unauthenticated provisioning can only use anonymous | Note that server Unauthenticated Provisioning can only use anonymous | |||
cipher suites in TLS 1.2 and earlier. These cipher suites have been | cipher suites in TLS 1.2 and earlier. These cipher suites have been | |||
deprecated in TLS 1.3 ([RFC8446] Section C.5). For TLS 1.3, the | deprecated in TLS 1.3 ([RFC8446] Section C.5). For TLS 1.3, the | |||
server MUST provide a certificate, and the peer performs server | server MUST provide a certificate, and the peer performs server | |||
unauthenticated provisioning by not validating the certificate chain | unauthenticated provisioning by not validating the certificate chain | |||
or any of its contents. | or any of its contents. | |||
3.11.4. Channel Binding | 3.11.4. Channel Binding | |||
[RFC6677] defines channel bindings for WAP which solve the "lying | [RFC6677] defines channel bindings for EAP which solve the "lying | |||
NAS" and the "lying provider" problems, using a process in which the | NAS" and the "lying provider" problems, using a process in which the | |||
EAP peer gives information about the characteristics of the service | EAP peer gives information about the characteristics of the service | |||
provided by the authenticator to the Authentication, Authorization, | provided by the authenticator to the Authentication, Authorization, | |||
and Accounting (AAA) server protected within the EAP authentication | and Accounting (AAA) server protected within the EAP authentication | |||
method. This allows the server to verify the authenticator is | method. This allows the server to verify the authenticator is | |||
providing information to the peer that is consistent with the | providing information to the peer that is consistent with the | |||
information received from this authenticator as well as the | information received from this authenticator as well as the | |||
information stored about this authenticator. | information stored about this authenticator. | |||
TEAP supports EAP channel binding using the Channel-Binding TLV | TEAP supports EAP channel binding using the Channel-Binding TLV | |||
skipping to change at page 52, line 36 ¶ | skipping to change at page 52, line 36 ¶ | |||
2 MSK Compound MAC is present | 2 MSK Compound MAC is present | |||
3 Both EMSK and MSK Compound MAC are present | 3 Both EMSK and MSK Compound MAC are present | |||
Sub-Type | Sub-Type | |||
The Sub-Type field is four bits. Defined values include | The Sub-Type field is four bits. Defined values include | |||
0 Binding Request | 0 Binding Request | |||
< 1 Binding Response | 1 Binding Response | |||
Nonce | Nonce | |||
The Nonce field is 32 octets. It contains a 256-bit nonce that is | The Nonce field is 32 octets. It contains a 256-bit nonce that is | |||
temporally unique, used for Compound MAC key derivation at each | temporally unique, used for Compound MAC key derivation at each | |||
end. The nonce in a request MUST have its least significant bit | 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 | 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 | value as the request nonce except the least significant bit MUST | |||
be set to one (1). | be set to one (1). | |||
skipping to change at page 59, line 17 ¶ | skipping to change at page 59, line 17 ¶ | |||
The CSR-Attributes TLV provides information from the server to the | The CSR-Attributes TLV provides information from the server to the | |||
peer on how certificate signing requests should be formed. The | peer on how certificate signing requests should be formed. The | |||
purpose of CSR attributes is described in Section 4.5 of [RFC7030]. | purpose of CSR attributes is described in Section 4.5 of [RFC7030]. | |||
Servers MAY send the CSR-Attributes TLV directly after the TLS | Servers MAY send the CSR-Attributes TLV directly after the TLS | |||
session has been established. A server MAY also send in the same | session has been established. A server MAY also send in the same | |||
message a Request Action frame for a PKCS#10 TLV. This is an | message a Request Action frame for a PKCS#10 TLV. This is an | |||
indication to the peer that the server would like the peer to renew | indication to the peer that the server would like the peer to renew | |||
its certificate using the parameters provided in this TLV. Servers | its certificate using the parameters provided in this TLV. Servers | |||
shall construct the contents of the CSR-Attributes TLV as specified | shall construct the contents of the CSR-Attributes TLV as specified | |||
in [RFC7030] Section 4.5.2 with the exception that the DER encoding | in [RFC7030] Section 4.5.2 with the exception that the DER encoding | |||
MUST NOT be encoded in base64. The base64 encoding in used in | MUST NOT be encoded in base64. The base64 encoding is used in | |||
[RFC7030] because the transport protocol used there requires textual | [RFC7030] because the transport protocol used there requires textual | |||
encoding. In contrast, TEAP attributes can transport arbitrary | encoding. In contrast, TEAP attributes can transport arbitrary | |||
binary data. | binary data. | |||
Servers and peers MUST follow the guidance provided in | Servers and peers MUST follow the guidance provided in | |||
[I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes | [I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes | |||
TLV. Peers MAY ignore the contents of the TLV if they are unable to | TLV. Peers MAY ignore the contents of the TLV if they are unable to | |||
do so, but then servers may not process PKCS#10 certificate requests | do so, but then servers may not process PKCS#10 certificate requests | |||
for this or any other reason. | for this or any other reason. | |||
skipping to change at page 60, line 21 ¶ | skipping to change at page 60, line 21 ¶ | |||
The purpose of this TLV is to solve the "bootstrapping" problem for | The purpose of this TLV is to solve the "bootstrapping" problem for | |||
the server. In order to perform authentication, the server must | the server. In order to perform authentication, the server must | |||
choose an inner method. However, the server has no knowledge of what | choose an inner method. However, the server has no knowledge of what | |||
methods are supported by the peer. Without an identity hint, the | methods are supported by the peer. Without an identity hint, the | |||
server needs to propose a method, and then have the peer return a | server needs to propose a method, and then have the peer return a | |||
response indicating that the requested method is not available. This | response indicating that the requested method is not available. This | |||
negotiation increases the number of round trips required for TEAP to | negotiation increases the number of round trips required for TEAP to | |||
conclude, with no additional benefit. | conclude, with no additional benefit. | |||
When the Identity-Hint is use, the peer can signal which identities | When the Identity-Hint is used, the peer can signal which identities | |||
it has available, which enables the server to choose an inner method | it has available, which enables the server to choose an inner method | |||
which is appropriate for that identity. | which is appropriate for that identity. | |||
The peer SHOULD send an Identity-Hint TLV for each Identity-Type | The peer SHOULD send an Identity-Hint TLV for each Identity-Type | |||
which is available to it. For example, if the peer can do both | which is available to it. For example, if the peer can do both | |||
Machine and User authentication, it can send two Identity-Hint TLVs, | Machine and User authentication, it can send two Identity-Hint TLVs, | |||
with values "host/name.example.com" (for a machine with hostname | with values "host/name.example.com" (for a machine with hostname | |||
"name.example.com"), and "user@example.com" (for a person with | "name.example.com"), and "user@example.com" (for a person with | |||
identity "user@example.com"). | identity "user@example.com"). | |||
skipping to change at page 60, line 44 ¶ | skipping to change at page 60, line 44 ¶ | |||
Machine identities might not follow that format. As these identities | Machine identities might not follow that format. As these identities | |||
are never used for AAA routing as discussed in [RFC7542] Section 3, | are never used for AAA routing as discussed in [RFC7542] Section 3, | |||
the format and definition of these identities is entirely site local. | the format and definition of these identities is entirely site local. | |||
Robust implementations MUST support arbitrary data in the content of | Robust implementations MUST support arbitrary data in the content of | |||
this TLV, including binary octets. | this TLV, including binary octets. | |||
As the Identity-Hint TLV is a "hint", server implementations are free | As the Identity-Hint TLV is a "hint", server implementations are free | |||
to ignore the hints given, and do whatever is required by site-local | to ignore the hints given, and do whatever is required by site-local | |||
policies. | policies. | |||
The Identity-Hint TLV is used only as a guide to selecting which | The Identity-Hint TLV is used only as a guide when selecting which | |||
inner methods to use. This TLV has no other meaning, and it MUST NOT | inner methods to use. This TLV has no other meaning, and it MUST NOT | |||
be used for any other purpose. Specifically. server implementations | be used for any other purpose. Specifically. server implementations | |||
MUST NOT compare the identities given this TLV to later identities | MUST NOT compare the identities given this TLV to later identities | |||
given as part of the inner methods. There is no issue with the | given as part of the inner methods. There is no issue with the | |||
hint(s) failing to match any subsequent identity which is used. | hint(s) failing to match any subsequent identity which is used. | |||
The Identity-Hint TLV MUST NOT be used for Server Unauthenticated | ||||
Provisioning. This TLV is only used as a hint for normal | ||||
authentication. | ||||
The Identity-Hint TLV is defined as follows: | The Identity-Hint TLV is defined as follows: | |||
0 1 2 3 | 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 | 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 | | |M|R| TLV Type | Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Identity Hint | | | Identity Hint | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |||
skipping to change at page 67, line 50 ¶ | skipping to change at page 68, line 10 ¶ | |||
3. All the Outer TLVs from the first TEAP message sent by EAP server | 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 | to peer. If a single TEAP message is fragmented into multiple | |||
TEAP packets, then the Outer TLVs in all the fragments of that | TEAP packets, then the Outer TLVs in all the fragments of that | |||
message MUST be included. | message MUST be included. | |||
4. All the Outer TLVs from the first TEAP message sent by the peer | 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 | to the EAP server. If a single TEAP message is fragmented into | |||
multiple TEAP packets, then the Outer TLVs in all the fragments | multiple TEAP packets, then the Outer TLVs in all the fragments | |||
of that message MUST be included. | of that message MUST be included. | |||
is run then no EMSK or MSK will be generated. If an IMSK needs to be | If no inner method is run, then no EMSK or MSK will be generated. If | |||
generated then the MSK and therefore the IMSK is set to all zeroes | an IMSK needs to be generated then the MSK and therefore the IMSK is | |||
(i.e., IMSK = MSK = 32 octets of 0x00s). | set to all zeroes (i.e., IMSK = MSK = 32 octets of 0x00s). | |||
Note that there is no boundary marker between the fields in steps (3) | ||||
and (4). However, the server calculates the compound MAC using the | ||||
outer TLVs it sent, and the outer TLVs it received from the peer. On | ||||
the other side, the peer calculates the compound MAC using the outer | ||||
TLVs it sent, and the outer TLVs it received from the server. As a | ||||
result, and modification in transit of the outer TLVs will be | ||||
detected because the two sides will calculate different values for | ||||
the compound MAC. | ||||
If no key generating inner method is run then no EMSK or MSK will be | ||||
generated. If an IMSK needs to be generated then the MSK and | ||||
therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets | ||||
of 0x00s) | ||||
5.4. EAP Master Session Key Generation | 5.4. EAP Master Session Key Generation | |||
TEAP authentication assures the Master Session Key (MSK) and Extended | TEAP authentication assures the Master Session Key (MSK) and Extended | |||
Master Session Key (EMSK) output from running TEAP are the combined | Master Session Key (EMSK) output from running TEAP are the combined | |||
result of all inner methods by generating an Intermediate Compound | result of all inner methods by generating an Intermediate Compound | |||
Key (IMCK). The IMCK is mutually derived by the peer and the server | Key (IMCK). The IMCK is mutually derived by the peer and the server | |||
as described in Section 5.2 by combining the MSKs from inner methods | as described in Section 5.2 by combining the MSKs from inner methods | |||
with key material from TEAP Phase 1. The resulting MSK and EMSK are | with key material from TEAP Phase 1. The resulting MSK and EMSK are | |||
generated from the final ("n"th) inner method, as part of the IMCK[n] | generated from the final ("n"th) inner method, as part of the IMCK[n] | |||
skipping to change at page 68, line 27 ¶ | skipping to change at page 68, line 50 ¶ | |||
"Session Key Generating Function") | "Session Key Generating Function") | |||
EMSK = the first 64 octets of TLS-PRF(S-IMCK[n], | EMSK = the first 64 octets of TLS-PRF(S-IMCK[n], | |||
"Extended Session Key Generating Function") | "Extended Session Key Generating Function") | |||
The TLS-PRF is defined in [RFC5246] as | The TLS-PRF is defined in [RFC5246] as | |||
PRF(secret, label, seed) = P_<hash>(secret, label | seed). | PRF(secret, label, seed) = P_<hash>(secret, label | seed). | |||
where "|" denotes concatenation. The secret is S-IMCK[n] where n is | where "|" denotes concatenation. The secret is S-IMCK[n] where n is | |||
the number of the last generated S-IMCK[j] from Section 5.2. The | the number of the last generated S-IMCK[j] from Section 5.2. The | |||
label is is the ASCII value for the string without quotes. The seed | label is the ASCII value for the string without quotes. The seed is | |||
is empty (0 length) and is omitted from the derivation. | empty (0 length) and is omitted from the derivation. | |||
The EMSK is typically only known to the TEAP peer and server and is | 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 | not provided to a third party. The derivation of additional keys and | |||
transportation of these keys to a third party are outside the scope | transportation of these keys to a third party are outside the scope | |||
of this document. | of this document. | |||
If no inner method has created an EMSK or MSK, the MSK and EMSK will | If no inner method has created an EMSK or MSK, the MSK and EMSK will | |||
be generated directly from the session_key_seed meaning S-IMCK[0] = | be generated directly from the session_key_seed meaning S-IMCK[0] = | |||
session_key_seed. | session_key_seed. | |||
skipping to change at page 69, line 13 ¶ | skipping to change at page 69, line 37 ¶ | |||
protocol, in accordance with BCP 26 [RFC5226]. | protocol, in accordance with BCP 26 [RFC5226]. | |||
Except as noted below, IANA is instructed to update the "Tunnel | Except as noted below, IANA is instructed to update the "Tunnel | |||
Extensible Authentication Protocol (TEAP) Parameters" registry to | Extensible Authentication Protocol (TEAP) Parameters" registry to | |||
change the Reference field in all tables from [RFC7170] to [THIS- | change the Reference field in all tables from [RFC7170] to [THIS- | |||
DOCUMENT]. | DOCUMENT]. | |||
6.1. TEAP TLV Types | 6.1. TEAP TLV Types | |||
IANA is instructed to update the references in the "TEAP TLV Types" | IANA is instructed to update the references in the "TEAP TLV Types" | |||
registry as follows. | registry as follows. Most references to [RFC7170] are changed to | |||
this document. TLV 11 is deprecated. TLV 18 and TLV 19 are new | ||||
additions to the registry. | ||||
Value,Description,Reference | Value,Description,Reference | |||
0,Unassigned, | 0,Unassigned, | |||
1,Authority-ID TLV,[THIS-DOCUMENT] | 1,Authority-ID TLV,[THIS-DOCUMENT] | |||
2,Identity-Type TLV,[THIS-DOCUMENT] | 2,Identity-Type TLV,[THIS-DOCUMENT] | |||
3,Result TLV,[THIS-DOCUMENT] | 3,Result TLV,[THIS-DOCUMENT] | |||
4,NAK TLV,[THIS-DOCUMENT] | 4,NAK TLV,[THIS-DOCUMENT] | |||
5,Error TLV,[THIS-DOCUMENT] | 5,Error TLV,[THIS-DOCUMENT] | |||
6,Channel-Binding TLV,[THIS-DOCUMENT] | 6,Channel-Binding TLV,[THIS-DOCUMENT] | |||
7,Vendor-Specific TLV,[THIS-DOCUMENT] | 7,Vendor-Specific TLV,[THIS-DOCUMENT] | |||
skipping to change at page 71, line 5 ¶ | skipping to change at page 71, line 44 ¶ | |||
As a whole, TEAP provides message and integrity protection by | As a whole, TEAP provides message and integrity protection by | |||
establishing a secure tunnel for protecting the inner method(s). The | establishing a secure tunnel for protecting the inner method(s). The | |||
confidentiality and integrity protection is defined by TLS and | confidentiality and integrity protection is defined by TLS and | |||
provides the same security strengths afforded by TLS employing a | provides the same security strengths afforded by TLS employing a | |||
strong entropy shared master secret. The integrity of the key | strong entropy shared master secret. The integrity of the key | |||
generating inner methods executed within the TEAP tunnel is verified | generating inner methods executed within the TEAP tunnel is verified | |||
through the calculation of the Crypto-Binding TLV. This ensures that | through the calculation of the Crypto-Binding TLV. This ensures that | |||
the tunnel endpoints are the same as the inner method endpoints. | the tunnel endpoints are the same as the inner method endpoints. | |||
Where Server Unauthenticated Provisioning is performed, TEAP requires | ||||
that the inner provisioning method provide for mutual authentication. | ||||
7.2. Method Negotiation | 7.2. Method Negotiation | |||
As is true for any negotiated EAP protocol, EAP NAK message used to | As is true for any negotiated EAP protocol, EAP NAK message used to | |||
suggest an alternate EAP authentication method are sent unprotected | suggest an alternate EAP authentication method are sent unprotected | |||
and, as such, are subject to spoofing. During unprotected EAP method | and, as such, are subject to spoofing. During unprotected EAP method | |||
negotiation, NAK packets may be interjected as active attacks to bid- | negotiation, NAK packets may be interjected as active attacks to bid- | |||
down to a weaker form of authentication, such as EAP-MD5 (which only | 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 | provides one-way authentication and does not derive a key). Both the | |||
peer and server should have a method selection policy that prevents | peer and server should have a method selection policy that prevents | |||
them from negotiating down to weaker methods. Inner method | them from negotiating down to weaker methods. Inner method | |||
skipping to change at page 73, line 29 ¶ | skipping to change at page 74, line 29 ¶ | |||
response may contain an anonymous identity and just contain realm | response may contain an anonymous identity and just contain realm | |||
information. In other cases, the identity exchange may be eliminated | information. In other cases, the identity exchange may be eliminated | |||
altogether if there are other means for establishing the destination | altogether if there are other means for establishing the destination | |||
realm of the request. In no case should an intermediary place any | realm of the request. In no case should an intermediary place any | |||
trust in the identity information in the identity response since it | trust in the identity information in the identity response since it | |||
is unauthenticated and may not have any relevance to the | is unauthenticated and may not have any relevance to the | |||
authenticated identity. TEAP implementations should not attempt to | authenticated identity. TEAP implementations should not attempt to | |||
compare any identity disclosed in the initial cleartext EAP Identity | compare any identity disclosed in the initial cleartext EAP Identity | |||
response packet with those Identities authenticated in Phase 2. | response packet with those Identities authenticated in Phase 2. | |||
Identity request/response exchanges sent after the TEAP tunnel is | When the server is authenticated, identity request/response exchanges | |||
established are protected from modification and eavesdropping by | sent after the TEAP tunnel is established are protected from | |||
attackers. | modification and eavesdropping by attackers. For server | |||
unauthenticated provisioning, the outer TLS session provides little | ||||
security, and the provisioning method must necessarily provide this | ||||
protection instead. | ||||
When a client certificate is sent outside of the TLS tunnel in Phase | When a client certificate is sent outside of the TLS tunnel in Phase | |||
1, the peer MUST include Identity-Type as an outer TLV, in order to | 1, the peer MUST include Identity-Type as an outer TLV, in order to | |||
signal the type of identity which that client certificate is for. | signal the type of identity which that client certificate is for. | |||
Further, when a client certificate is sent outside of the TLS tunnel, | Further, when a client certificate is sent outside of the TLS tunnel, | |||
the server MUST proceed with Phase 2. If there is no Phase 2 data, | the server MUST proceed with Phase 2. If there is no Phase 2 data, | |||
then the EAP server MUST reject the session. | then the EAP server MUST reject the session. | |||
Issues related to confidentiality of a client certificate are | Issues related to confidentiality of a client certificate are | |||
discussed above in Section 3.4.1 | discussed above in Section 3.4.1 | |||
skipping to change at page 76, line 5 ¶ | skipping to change at page 77, line 5 ¶ | |||
TEAP can carry clear-text passwords in the Basic-Password-Auth-Resp | TEAP can carry clear-text passwords in the Basic-Password-Auth-Resp | |||
TLV. Implementations should take care to protect this data. For | TLV. Implementations should take care to protect this data. For | |||
example, passwords should not normally be logged, and password data | example, passwords should not normally be logged, and password data | |||
should be securely scrubbed from memory when it is no longer needed. | should be securely scrubbed from memory when it is no longer needed. | |||
7.8. Security Claims | 7.8. Security Claims | |||
This section provides the needed security claim requirement for EAP | This section provides the needed security claim requirement for EAP | |||
[RFC3748]. | [RFC3748]. | |||
Auth. mechanism: Certificate-based, shared-secret-based, and | Auth. mechanism: Certificate-based, shared-secret-based, and | |||
various tunneled authentication mechanisms. | various tunneled authentication mechanisms. | |||
Cipher Suite negotiation: Yes | Cipher Suite negotiation: Yes | |||
Mutual authentication: Yes | Mutual authentication: Yes | |||
Integrity protection: Yes. Any method executed within the TEAP | Integrity protection: Yes. Any method executed within the TEAP | |||
tunnel is integrity protected. The | tunnel is integrity protected. The | |||
cleartext EAP headers outside the tunnel are | cleartext EAP headers outside the tunnel are | |||
not integrity protected. | not integrity protected. Server | |||
unauthenticated provisioning provides its own | ||||
protection mechanisms. | ||||
Replay protection: Yes | Replay protection: Yes | |||
Confidentiality: Yes | Confidentiality: Yes | |||
Key derivation: Yes | Key derivation: Yes | |||
Key strength: See Note 1 below. | Key strength: See Note 1 below. | |||
Dictionary attack prot.: See Note 2 below. | Dictionary attack prot.: See Note 2 below. | |||
Fast reconnect: Yes | Fast reconnect: Yes | |||
Cryptographic binding: Yes | Cryptographic binding: Yes | |||
Session independence: Yes | Session independence: Yes | |||
Fragmentation: Yes | Fragmentation: Yes | |||
Key Hierarchy: Yes | Key Hierarchy: Yes | |||
Channel binding: Yes | Channel binding: Yes | |||
Notes | Notes | |||
Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. | Note 1. BCP 86 [RFC3766] offers advice on appropriate key sizes. | |||
The National Institute for Standards and Technology (NIST) also | The National Institute for Standards and Technology (NIST) also | |||
offers advice on appropriate key sizes in [NIST-SP-800-57]. | offers advice on appropriate key sizes in [NIST-SP-800-57]. | |||
[RFC3766], Section 5 advises use of the following required RSA or DH | [RFC3766], Section 5 advises use of the following required RSA or DH | |||
(Diffie-Hellman) module and DSA (Digital Signature Algorithm) | (Diffie-Hellman) module and DSA (Digital Signature Algorithm) | |||
subgroup size in bits for a given level of attack resistance in bits. | 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 | Based on the table below, a 2048-bit RSA key is required to provide | |||
skipping to change at page 104, line 13 ¶ | skipping to change at page 105, line 13 ¶ | |||
Normative References | Normative References | |||
[BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [BCP14] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. | |||
[I-D.ietf-lamps-rfc7030-csrattrs] | [I-D.ietf-lamps-rfc7030-csrattrs] | |||
Richardson, M., Friel, O., von Oheimb, D., and D. Harkins, | Richardson, M., Friel, O., von Oheimb, D., and D. Harkins, | |||
"Clarification of RFC7030 CSR Attributes definition", Work | "Clarification of RFC7030 CSR Attributes definition", Work | |||
in Progress, Internet-Draft, draft-ietf-lamps-rfc7030- | in Progress, Internet-Draft, draft-ietf-lamps-rfc7030- | |||
csrattrs-07, 10 October 2023, | csrattrs-08, 3 March 2024, | |||
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- | |||
rfc7030-csrattrs-07>. | rfc7030-csrattrs-08>. | |||
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object | |||
Classes and Attribute Types Version 2.0", RFC 2985, | Classes and Attribute Types Version 2.0", RFC 2985, | |||
DOI 10.17487/RFC2985, November 2000, | DOI 10.17487/RFC2985, November 2000, | |||
<https://www.rfc-editor.org/rfc/rfc2985>. | <https://www.rfc-editor.org/rfc/rfc2985>. | |||
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification | |||
Request Syntax Specification Version 1.7", RFC 2986, | Request Syntax Specification Version 1.7", RFC 2986, | |||
DOI 10.17487/RFC2986, November 2000, | DOI 10.17487/RFC2986, November 2000, | |||
<https://www.rfc-editor.org/rfc/rfc2986>. | <https://www.rfc-editor.org/rfc/rfc2986>. | |||
End of changes. 57 change blocks. | ||||
121 lines changed or deleted | 147 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |