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/