rfc9930v1.txt   rfc9930.txt 
skipping to change at line 128 skipping to change at line 128
5.2. Explanation and Background 5.2. Explanation and Background
5.3. Next Steps 5.3. Next Steps
6. Cryptographic Calculations 6. Cryptographic Calculations
6.1. TEAP Authentication Phase 1: Key Derivations 6.1. TEAP Authentication Phase 1: Key Derivations
6.2. Intermediate Compound Key Derivations 6.2. Intermediate Compound Key Derivations
6.2.1. Generating the Inner Method Session Key 6.2.1. Generating the Inner Method Session Key
6.2.2. Generating S-IMCK 6.2.2. Generating S-IMCK
6.2.3. Choosing Inner Methods Securely 6.2.3. Choosing Inner Methods Securely
6.2.4. Managing and Computing Crypto-Binding 6.2.4. Managing and Computing Crypto-Binding
6.2.5. Unintended Side Effects 6.2.5. Unintended Side Effects
6.3. Computing the Compound-MAC 6.3. Computing the Compound MAC
6.4. EAP Master Session Key Generation 6.4. EAP Master Session Key Generation
7. IANA Considerations 7. IANA Considerations
7.1. TEAP TLV Types 7.1. TEAP TLV Types
7.2. TEAP Error TLV (value 5) Error Codes 7.2. TEAP Error TLV (value 5) Error Codes
7.3. TLS Exporter Labels 7.3. TLS Exporter Labels
7.4. Extended Master Session Key (EMSK) Parameters 7.4. Extended Master Session Key (EMSK) Parameters
7.5. Extensible Authentication Protocol (EAP) Registry 7.5. Extensible Authentication Protocol (EAP) Registry
8. Security Considerations 8. Security Considerations
8.1. Mutual Authentication and Integrity Protection 8.1. Mutual Authentication and Integrity Protection
8.2. Method Negotiation 8.2. Method Negotiation
skipping to change at line 150 skipping to change at line 150
8.4. Mitigation of Known Vulnerabilities and Protocol 8.4. Mitigation of Known Vulnerabilities and Protocol
Deficiencies Deficiencies
8.4.1. User Identity Protection and Verification 8.4.1. User Identity Protection and Verification
8.5. Dictionary Attack Resistance 8.5. Dictionary Attack Resistance
8.5.1. Protection Against On-Path Attacks 8.5.1. Protection Against On-Path Attacks
8.6. Protecting Against Forged Cleartext EAP Packets 8.6. Protecting Against Forged Cleartext EAP Packets
8.7. Use of Cleartext Passwords 8.7. Use of Cleartext Passwords
8.8. Accidental or Unintended Behavior 8.8. Accidental or Unintended Behavior
8.9. Implicit Challenge 8.9. Implicit Challenge
8.10. Security Claims 8.10. Security Claims
9. Changes from RFC 7170 9. References
10. References 9.1. Normative References
10.1. Normative References 9.2. Informative References
10.2. Informative References
Appendix A. Evaluation Against Tunnel-Based EAP Method Appendix A. Evaluation Against Tunnel-Based EAP Method
Requirements Requirements
A.1. Requirement 4.1.1: RFC Compliance A.1. Requirement 4.1.1: RFC Compliance
A.2. Requirement 4.2.1: TLS Requirements A.2. Requirement 4.2.1: TLS Requirements
A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation A.3. Requirement 4.2.1.1.1: Cipher Suite Negotiation
A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms A.4. Requirement 4.2.1.1.2: Tunnel Data Protection Algorithms
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 Establishment
A.6. Requirement 4.2.1.2: Tunnel Replay Protection A.6. Requirement 4.2.1.2: Tunnel Replay Protection
A.7. Requirement 4.2.1.3: TLS Extensions A.7. Requirement 4.2.1.3: TLS Extensions
skipping to change at line 202 skipping to change at line 201
C.4. Client Authentication During Phase 1 with Identity Privacy C.4. Client Authentication During Phase 1 with Identity Privacy
C.5. Fragmentation and Reassembly C.5. Fragmentation and Reassembly
C.6. Sequence of EAP Methods C.6. Sequence of EAP Methods
C.7. Failed Crypto-Binding C.7. Failed Crypto-Binding
C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange C.8. Sequence of EAP Method with Vendor-Specific TLV Exchange
C.9. Peer Requests Inner Method After Server Sends Result TLV C.9. Peer Requests Inner Method After Server Sends Result TLV
C.10. Channel Binding C.10. Channel Binding
C.11. PKCS Exchange C.11. PKCS Exchange
C.12. Failure Scenario C.12. Failure Scenario
C.13. Client Certificate in Phase 1 C.13. Client Certificate in Phase 1
Appendix D. Changes from RFC 7170
Acknowledgments Acknowledgments
Contributors Contributors
Author's Address Author's Address
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
skipping to change at line 247 skipping to change at line 247
1.1. Interoperability Issues 1.1. Interoperability Issues
This document contains substantial changes from [RFC7170]. These This document contains substantial changes from [RFC7170]. These
changes are largely clarifications and corrections to that changes are largely clarifications and corrections to that
specification. specification.
However, there is one major change from [RFC7170] in the However, there is one major change from [RFC7170] in the
specification of the cryptographic-binding information. While there specification of the cryptographic-binding information. While there
were multiple implementations of [RFC7170], the text in that document were multiple implementations of [RFC7170], the text in that document
was interpreted differently by each implementation. The was interpreted differently by each implementation. The
implementations are interoperable but only for a subset of the implementations are interoperable, but only for a subset of the
functionality described in [RFC7170]. functionalities described in [RFC7170].
This specification describes how TEAPv1 works in theory but also This specification describes how TEAPv1 works in theory but also
explains what subset of TEAPv1 is currently interoperable. In order explains what subset of TEAPv1 is currently interoperable. In order
to simplify the description of an already complex specification, all to simplify the description of an already complex specification, all
interoperability issues are documented separately from the normal interoperability issues are documented separately from the normal
protocol operation. protocol operation.
Please see Section 5 for further discussion of interoperability Please see Section 5 for further discussion of interoperability
issues. issues.
skipping to change at line 273 skipping to change at line 273
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.3. Terminology 1.3. 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 utilizes objects in TLV format. The TLV format is
is defined in Section 4.2. defined in Section 4.2.
Inner Method Inner Method
An authentication method that is sent as application data inside An authentication method that is sent as application data inside
of a TLS exchange that is carried over TEAP. The inner method can of a TLS exchange that is carried over TEAP. The Inner Method can
be an EAP authentication method, a username/password 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 Public Key Cryptography Standard (PKCS) exchange. be a Public Key Cryptography Standard (PKCS) exchange.
2. Protocol Overview 2. Protocol Overview
TEAP authentication occurs in two phases after the initial EAP TEAP authentication occurs in two phases after the initial EAP
Identity request/response exchange. In the first phase, TEAP employs Identity request/response exchange. In the first phase, TEAP employs
the TLS [RFC8446] handshake to provide an authenticated key exchange the TLS [RFC8446] handshake to provide an authenticated key exchange
and to establish a protected tunnel. Once the tunnel is established, and to establish a protected tunnel. Once the tunnel is established,
the second phase begins with the peer and server engaging in further the second phase begins with the peer and server engaging in further
conversations to establish the required authentication and conversations to establish the required authentication and
skipping to change at line 340 skipping to change at line 340
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method | | Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server | | | | ticator | | server | | server |
| | | | | | | | | | | | | | | |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+
Figure 1: TEAP Architectural Model Figure 1: TEAP Architectural Model
The Peer and Authenticator are defined in [RFC3748], Section 1.2. The Peer and Authenticator are defined in [RFC3748], Section 1.2.
The TEAP server is the "backend authentication server" defined in The TEAP server is the "backend authentication server" defined in
[RFC3748], Section 1.2. The "Inner Method server" is usually part of [RFC3748], Section 1.2. The "Inner Method server" is usually part of
the TEAP server and handles the application data (inner methods, EAP, the TEAP server and handles the application data (Inner Methods, EAP,
passwords, etc.) inside of the TLS tunnel. passwords, etc.) inside of the TLS tunnel.
The entities depicted above are logical entities and may or may not The entities depicted above are logical entities and may or may not
correspond to separate network components. For example, the TEAP correspond to separate network components. For example, the TEAP
server and Inner Method server might be a single entity; the server and Inner Method server might be a single entity; the
authenticator and TEAP server might be a single entity; or the authenticator and TEAP server might be a single entity; or the
functions of the authenticator, TEAP server, and Inner Method server functions of the authenticator, TEAP server, and Inner Method server
might be combined into a single physical device. For example, might be combined into a single physical device. For example,
typical IEEE 802.11 deployments place the authenticator in an access typical IEEE 802.11 deployments place the authenticator in an access
point (AP) while a RADIUS server may provide the TEAP and inner point (AP) while a RADIUS server may provide the TEAP and inner
skipping to change at line 402 skipping to change at line 402
the authenticator and the EAP server. the authenticator and the EAP server.
2.3. Outer TLVs Versus Inner TLVs 2.3. Outer TLVs Versus Inner TLVs
TEAP packets may include TLVs both inside and outside the TLS tunnel TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows: defined as follows:
Outer TLVs Outer TLVs
This term is used to refer to optional TLVs outside the TLS This term is used to refer to optional TLVs outside the TLS
tunnel, which are only allowed in the first two messages in the tunnel, which are only allowed in the first two messages in the
TEAP protocol. That is the first EAP-server-to-peer message and TEAP. That is the first EAP-server-to-peer message and first
first peer-to-EAP-server message. If the message is fragmented, peer-to-EAP-server message. If the message is fragmented, the
the whole set of fragments is counted as one message. whole set of fragments is counted as one message.
Inner TLVs Inner TLVs
This term is used to refer to TLVs sent within the TLS tunnel. In This term is used to refer to TLVs sent within the TLS tunnel. In
TEAP Phase 1, Outer TLVs are used to help establish the TLS TEAP Phase 1, Outer TLVs are used to help establish the TLS
tunnel, but no Inner TLVs are used. In Phase 2 of TEAP, TLS tunnel, but no Inner TLVs are used. In Phase 2 of TEAP, TLS
records may encapsulate zero or more Inner TLVs, but no Outer TLVs records may encapsulate zero or more Inner TLVs, but no Outer TLVs
are used. are used.
3. TEAP Protocol 3. TEAP Protocol
skipping to change at line 498 skipping to change at line 498
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.3 for TLS 1.3. and in [RFC8446], Section 9.1 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
to leverage a certificate-status protocol such as the Online to leverage a certificate-status protocol such as the Online
Certificate Status Protocol (OCSP) [RFC6960] to check the validity of Certificate Status Protocol (OCSP) [RFC6960] to check the validity of
server certificates. TLS renegotiation indications defined in server certificates. TLS renegotiation indications defined in
[RFC5746] MUST be supported. [RFC5746] MUST be supported.
skipping to change at line 565 skipping to change at line 565
Server certificates MUST include a subjectAltName extension, with the Server certificates MUST include a subjectAltName extension, with the
dnsName attribute containing a Fully Qualified Domain Name (FQDN) dnsName attribute containing a Fully Qualified Domain Name (FQDN)
string. Server certificates MAY also include a SubjectDN containing string. Server certificates MAY also include a SubjectDN containing
a single element, "CN=", which contains the FQDN of the server. a single element, "CN=", which contains the FQDN of the server.
However, this use of SubjectDN is deprecated for TEAP and is However, this use of SubjectDN is deprecated for TEAP and is
forbidden in [RFC9525], Section 2. forbidden in [RFC9525], Section 2.
The KeyUsage extensions MAY be included but are not required. The KeyUsage extensions MAY be included but are not required.
The ExtendedKeyUsage extensions defined in [RFC5280] MAY also be The Extended Key Usage extensions defined in [RFC5280] MAY also be
included, but their use is discouraged. Systems SHOULD use a private included, but their use is discouraged. Systems SHOULD use a private
Certification Authority (CA) for EAP in preference to public CAs. Certification Authority (CA) for EAP in preference to public CAs.
The most commonly used public CAs are focused on the web, and those The most commonly used public CAs are focused on the web, and those
certificates are not always suitable for use with EAP. In contrast, certificates are not always suitable for use with EAP. In contrast,
private CAs can be designed for any purposes and can be restricted to private CAs can be designed for any purposes and can be restricted to
an enterprise or an other organization. an enterprise or an other organization.
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
does not need to do certificate validation: does not need to 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 information [RFC4949]; or loaded directly into it's trusted anchor information [RFC4949];
* when the peer is requesting server unauthenticated provisioning; * when the peer is requesting server unauthenticated provisioning;
* when the peer is certain that it will be using an authenticated * when the peer is certain that it will be using an authenticated
inner method. Inner Method.
In some cases, such as onboarding (or "bootstrapping"), the In some cases, such as onboarding (or "bootstrapping"), the
certificate validation may be delayed. However, once the onboarding certificate validation may be delayed. However, once the onboarding
has taken place, the validation steps described below MUST still be has taken place, the validation steps described below MUST still be
performed. performed.
In all other cases, the EAP peer MUST validate the server In all other cases, the EAP peer MUST validate the server
certificate. This validation is done in the same manner as is done certificate. This validation is done in the same manner as is done
for EAP-TLS, which is discussed in [RFC9190], Section 5.3 and in for EAP-TLS, which is discussed in [RFC9190], Section 5.3 and in
[RFC5216], Section 5.3. Further guidance on server identity [RFC5216], Section 5.3. Further guidance on server identity
validation can be found in [RFC9525], Section 6. validation can be found in [RFC9525], Section 6.
Where the EAP peer has an NAI, EAP peers MUST use the realm to Where the EAP peer has an NAI, EAP peers MUST use the realm to
perform the DNS-ID validation as per [RFC9525], Section 6. The realm perform the DNS-ID validation as per [RFC9525], Section 6. The realm
is used both to construct the list of reference identifiers as is used both to construct the list of reference identifiers as
defined in [RFC9525], Section 6.1.2, and as the "source domain" field defined in [RFC9525], Section 6, and as the "source domain" field of
of that same section. that same section.
When performing server certificate validation, implementations MUST When performing server certificate validation, implementations MUST
also support the rules in [RFC5280] for validating certificates also support the rules in [RFC5280] for validating certificates
against a known trust anchor. In addition, implementations MUST against a known trust anchor. In addition, implementations MUST
support matching the realm portion of the peer's NAI against a support matching the realm portion of the peer's NAI against a
SubjectAltName of type dnsName within the server certificate. SubjectAltName of type dnsName within the server certificate.
However, in certain deployments, this comparison might not be However, in certain deployments, this comparison might not be
appropriate or enabled. appropriate or enabled.
In most situations, the EAP peer will have no network access during In most situations, the EAP peer will have no network access during
skipping to change at line 712 skipping to change at line 712
requests and responses encapsulated in TLV objects defined in requests and responses encapsulated in TLV objects defined in
Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV
exchange described in Section 4.2.13 and a protected termination exchange described in Section 4.2.13 and a protected termination
exchange described in Section 3.6.6. exchange described in Section 3.6.6.
If the peer is not authenticated in Phase 1, the TEAP peer SHOULD If the peer is not authenticated in Phase 1, the TEAP peer SHOULD
send one or more Identity-Hint TLVs (Section 4.2.20) as soon as the send one or more Identity-Hint TLVs (Section 4.2.20) as soon as the
TLS connection has been established. This information lets the TEAP TLS connection has been established. This information lets the TEAP
server choose an authentication type that is appropriate for that server choose an authentication type that is appropriate for that
identity. When the TEAP peer does not provide an Identity-Hint TLV, identity. When the TEAP peer does not provide an Identity-Hint TLV,
the TEAP server does not know which inner method is supported by the the TEAP server does not know which Inner Method is supported by the
peer. It must choose an inner method and propose it to the peer, peer. It must choose an Inner Method and propose it to the peer,
which may reject that inner method. As a result, the peer fails to which may reject that Inner Method. As a result, the peer fails to
authenticate and fails to obtain network access. authenticate and fails to obtain network access.
The TLV exchange includes the execution of zero or more inner methods The TLV exchange includes the execution of zero or more inner methods
within the protected tunnel as described in Sections 3.6.2 and 3.6.3. within the protected tunnel as described in Sections 3.6.2 and 3.6.3.
A server MAY proceed directly to the protected termination exchange A server MAY proceed directly to the protected termination exchange
without performing any inner authentication if it does not wish to without performing any inner authentication if it does not wish to
request further authentication from the peer. A server MAY request request further authentication from the peer. A server MAY request
one or more authentications within the protected tunnel. After one or more authentications within the protected tunnel. After
completion of each inner method, the server decides whether or not to completion of each Inner Method, the server decides whether or not to
begin another inner method or to send a Result TLV. begin another Inner Method or to send a Result TLV.
Implementations MUST support at least two sequential inner methods, Implementations MUST support at least two sequential Inner Methods,
which allows both machine and user authentication to be performed. which allows both machine and user authentication to be performed.
Implementations SHOULD also limit the number of sequential inner Implementations SHOULD also limit the number of sequential inner
authentications, as there is no reason to perform a large number of authentications, as there is no reason to perform a large number of
inner authentications in one TEAP conversation. inner authentications in one TEAP conversation.
Implementations wishing to use their own proprietary authentication Implementations wishing to use their own proprietary authentication
method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV
for the Vendor-Specific TLV, which carries another authentication for the Vendor-Specific TLV, which carries another authentication
method. Any vendor-specific authentication method MUST support method. Any vendor-specific authentication method MUST support
calculation of the Crypto-Binding TLV and MUST use Intermediate- calculation of the Crypto-Binding TLV and MUST use Intermediate-
Result TLV and Result TLV as is done with other authentication Result TLV and Result TLV as is done with other authentication
methods. methods.
3.6.1. Inner Method Ordering 3.6.1. Inner Method Ordering
Due to issues noted in Section 5, the order of inner methods has Due to issues noted in Section 5, the order of Inner Methods has
implications for both security and interoperability. implications for both security and interoperability.
Where the authentication is expected to use multiple inner methods, Where the authentication is expected to use multiple Inner Methods,
implementations SHOULD order the methods so that a method that implementations SHOULD order the methods so that a method that
derives an Extended Master Session Key (EMSK) is used first before derives an Extended Master Session Key (EMSK) is used first before
any other method. This ordering helps to securely tie the inner any other method. This ordering helps to securely tie the Inner
method to the TLS session and therefore can prevent attacks. Method to the TLS session and therefore can prevent attacks.
Implementations SHOULD support both EAP and basic password for inner Implementations SHOULD support both EAP and basic password
methods. Implementations that support multiple types of inner authentication for inner methods. Implementations that support
methods (User and Machine) MUST support all of those methods in any multiple types of Inner Methods (User and Machine) MUST support all
order or combination. That is, it is explicitly permitted to "mix of those methods in any order or combination. That is, it is
and match" inner methods. explicitly permitted to "mix and match" Inner Methods.
For example, a server can request user authentication from the peer For example, a server can request user authentication from the peer
and have the peer return machine authentication (or vice versa). If and have the peer return machine authentication (or vice versa). If
the server is configured to accept machine authentication, it MUST the server is configured to accept machine authentication, it MUST
accept that response. If that authentication succeeds, then accept that response. If that authentication succeeds, then
depending on local policy, the server SHOULD proceed with requesting depending on local policy, the server SHOULD proceed with requesting
user authentication again. user authentication again.
Similarly, a peer that is configured to support multiple types of Similarly, a peer that is configured to support multiple types of
inner methods (User and Machine) can return a method other than what Inner Methods (User and Machine) can return a method other than what
the server requested. This action is usually taken by the peer so the server requested. This action is usually taken by the peer so
that it orders inner methods for increased security. See that it orders Inner Methods for increased security. See
Section 6.2.3 for further discussion of this issue. Section 6.2.3 for further discussion of this issue.
However, the peer and server MUST NOT assume that either will skip However, the peer and server MUST NOT assume that either will skip
inner methods or other TLV exchanges, as the other peer might have a Inner Methods or other TLV exchanges, as the other peer might have a
different security policy. The peer may have roamed to a network different security policy. The peer may have roamed to a network
that requires conformance with a different authentication policy, or that requires conformance with a different authentication policy, or
the peer may request the server take additional action (e.g., channel the peer may request the server take additional action (e.g., channel
binding) through the use of the Request-Action TLV as defined in binding) through the use of the Request-Action TLV as defined in
Section 4.2.9. Section 4.2.9.
The completion of each inner method is signaled by an Intermediate- The completion of each Inner Method is signaled by an Intermediate-
Result TLV. Where the Intermediate-Result TLV indicates failure, an Result TLV. Where the Intermediate-Result TLV indicates failure, an
Error TLV SHOULD also be included using the most descriptive error Error TLV SHOULD also be included using the most descriptive error
code possible. The Intermediate-Result TLV may be accompanied by code possible. The Intermediate-Result TLV may be accompanied by
another TLV indicating that the server wishes to perform a subsequent another TLV indicating that the server wishes to perform a subsequent
authentication. When all inner methods have completed, the server authentication. When all Inner Methods have completed, the server
MUST send a Result TLV indicating success or failure instead of a TLV MUST send a Result TLV indicating success or failure instead of a TLV
that carries an inner method. that carries an Inner Method.
3.6.2. Inner EAP Authentication 3.6.2. Inner EAP Authentication
EAP [RFC3748] prohibits use of multiple authentication methods within EAP [RFC3748] prohibits use of multiple authentication methods within
a single EAP conversation in order to limit vulnerabilities to on- a single EAP conversation in order to limit vulnerabilities to on-
path attacks. TEAP addresses on-path attacks through support for path attacks. TEAP addresses on-path attacks through support for
cryptographic protection of the inner EAP exchange and cryptographic cryptographic protection of the inner EAP exchange and cryptographic
binding of the inner EAP method(s) to the protected tunnel. Inner binding of the inner EAP method(s) to the protected tunnel. Inner
methods are executed serially in a sequence. This version of TEAP Methods are executed serially in a sequence. This version of TEAP
does not support initiating multiple inner methods simultaneously in does not support initiating multiple Inner Methods simultaneously in
parallel. The inner methods need not be distinct. For example, EAP- parallel. The Inner Methods need not be distinct. For example, EAP-
TLS ([RFC5216] and [RFC9190]) could be run twice as an inner method, TLS ([RFC5216] and [RFC9190]) could be run twice as an inner method,
first using machine credentials, followed by a second instance using first using machine credentials, followed by a second instance using
user credentials. user credentials.
When EAP is used as an inner method, the EAP messages are carried When EAP is used as an Inner Method, the EAP messages are carried
within EAP-Payload TLVs defined in Section 4.2.10. Note that in this within EAP-Payload TLVs defined in Section 4.2.10. Note that in this
use case, TEAP is simply a carrier for EAP, much as RADIUS is a use case, TEAP is simply a carrier for EAP, much as RADIUS is a
carrier for EAP. The full EAP state machine runs as normal and is carrier for EAP. The full EAP state machine runs as normal and is
carried over the EAP-Payload TLV. Each distinct EAP authentication carried over the EAP-Payload TLV. Each distinct EAP authentication
MUST be managed as a separate EAP state machine. MUST be managed as a separate EAP state machine.
A TEAP server therefore MUST begin an EAP authentication with an EAP- A TEAP server therefore MUST begin an EAP authentication with an EAP-
Request/Identity (carried in an EAP-Payload TLV). However, a TEAP Request/Identity (carried in an EAP-Payload TLV). However, a TEAP
server MUST NOT finish the EAP conversation with an EAP Success or server MUST NOT finish the EAP conversation with an EAP Success or
EAP Failure packet; the Intermediate-Result TLV is used instead. EAP Failure packet; the Intermediate-Result TLV is used instead.
Upon completion of each EAP authentication in the tunnel, the server Upon completion of each EAP authentication in the tunnel, the server
MUST send an Intermediate-Result TLV indicating the result of that MUST send an Intermediate-Result TLV indicating the result of that
authentication. When the result indicates success, it MUST be authentication. When the result indicates success, it MUST be
accompanied by a Crypto-Binding TLV. The peer MUST respond to the accompanied by a Crypto-Binding TLV. The peer MUST respond to the
Intermediate-Result TLV indicating its own result and similarly on Intermediate-Result TLV indicating its own result. Similarly, upon
success MUST accompany the TLV with its own Crypto-Binding TLV. The success, the peer MUST accompany the TLV with its own Crypto-Binding
Crypto-Binding TLV is further discussed in Sections 4.2.13 and 6.3. TLV. The peer MUST respond to the Intermediate-Result TLV indicating
The Intermediate-Result TLVs can be included with other TLVs that its own result and similarly on success MUST accompany the TLV with
indicate a subsequent authentication or with the Result TLV used in its own Crypto-Binding TLV. The Crypto-Binding TLV is further
the protected termination exchange. discussed in Sections 4.2.13 and 6.3. The Intermediate-Result TLVs
can be included with other TLVs that indicate a subsequent
authentication or with the Result TLV used in the protected
termination exchange.
If both peer and server indicate success, then the authentication is If both peer and server indicate success, then the authentication is
considered successful. If either indicates failure, then the considered successful. If either indicates failure, then the
authentication is considered failed. The result of failure of an EAP authentication is considered failed. The result of failure of an EAP
authentication does not always imply a failure of the overall authentication does not always imply a failure of the overall
authentication. If one inner method fails, the server may attempt to authentication. If one Inner Method fails, the server may attempt to
authenticate the peer with a different method (EAP or password). authenticate the peer with a different method (EAP or password).
3.6.3. Inner Password Authentication 3.6.3. Inner Password Authentication
The authentication server (AS) initiates password authentication by The authentication server (AS) initiates password authentication by
sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If
the peer wishes to participate in password authentication, then it the peer wishes to participate in password authentication, then it
responds with a Basic-Password-Auth-Resp TLV that contains the responds with a Basic-Password-Auth-Resp TLV that contains the
username and password as defined in Section 4.2.15. If it does not username and password as defined in Section 4.2.15. If it does not
wish to perform password authentication, then it responds with a wish to perform password authentication, then it responds with a
skipping to change at line 867 skipping to change at line 870
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.
When the peer first receives a Basic-Password-Auth-Req TLV, it should When the peer first receives a Basic-Password-Auth-Req TLV, it should
allow the user to enter both a username and a password, which are allow the user to enter both a username and a password, which are
then placed in the Basic-Password-Auth-Resp TLV. If the peer then placed in the Basic-Password-Auth-Resp TLV. If the peer
receives subsequent Basic-Password-Auth-Req TLVs in the same receives subsequent Basic-Password-Auth-Req TLVs in the same
authentication session, it MUST NOT prompt for a username and instead authentication session, it MUST NOT prompt for a username and MUST
allow the user to enter only a password. The peer MUST copy the instead allow the user to enter only a password. The peer MUST copy
username used in the first Basic-Password-Auth-Resp TLV into all the username used in the first Basic-Password-Auth-Resp TLV into all
subsequent Basic-Password-Auth-Resp TLVs. subsequent Basic-Password-Auth-Resp TLVs.
Servers MUST track the username across multiple password rounds and Servers MUST track the username across multiple password rounds and
reject authentication if the identity changes from one Basic- reject authentication if the identity changes from one Basic-
Password-Auth-Resp TLV to the next. There is no reason for a user Password-Auth-Resp TLV to the next. There is no reason for a user
(or machine) to change identities in the middle of authentication. (or machine) to change identities in the middle of authentication.
Upon reception of a Basic-Password-Auth-Resp TLV in the tunnel, the Upon reception of a Basic-Password-Auth-Resp TLV in the tunnel, the
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
skipping to change at line 914 skipping to change at line 917
3.6.5. Limitations on Inner Methods 3.6.5. Limitations on Inner Methods
Implementations SHOULD limit the permitted inner EAP methods to a Implementations SHOULD limit the permitted inner EAP methods to a
small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP- small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-
MSCHAPv2. These EAP methods are the most commonly supported inner MSCHAPv2. These EAP methods are the most commonly supported inner
methods in TEAP and are known to be interoperable among multiple methods in TEAP and are known to be interoperable among multiple
implementations. implementations.
Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can
be used within a TEAP tunnel. Any EAP method that derives both MSK be used within a TEAP tunnel. Any EAP method that derives both MSK
and EMSK is likely to work as an inner method for TEAP, because EAP- and EMSK is likely to work as an Inner Method for TEAP, because EAP-
TLS has that behavior and it works. EAP methods that derive only MSK TLS has that behavior and it works. EAP methods that derive only MSK
should work, as EAP-FAST-MSCHAPv2 has that behavior, and it works. should work, as EAP-FAST-MSCHAPv2 has that behavior, and it works.
Other EAP methods are untested and may or may not work. Other EAP methods are untested and may or may not work.
Tunneled EAP methods such as PEAP [PEAP], EAP-TTLS [RFC5281], and Tunneled EAP methods such as PEAP [PEAP], EAP-TTLS [RFC5281], and
EAP-FAST [RFC4851] MUST NOT be used for inner EAP authentication. EAP-FAST [RFC4851] MUST NOT be used for inner EAP authentication.
There is no reason to have multiple layers of TLS in order to protect There is no reason to have multiple layers of TLS in order to protect
a password exchange. a password exchange.
The EAP methods defined in [RFC3748], Section 5, such as The EAP methods defined in [RFC3748], Section 5, such as
MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC), MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC),
do not derive an MSK or an EMSK and are vulnerable to on-path do not derive an MSK or an EMSK and are vulnerable to on-path
attacks. The construction of the OTP and GTC methods makes this attacks. The construction of the OTP and GTC methods makes this
attack less relevant, as the information being sent is generally a attack less relevant, as the information being sent is generally a
one-time token. However, EAP-OTP and EAP-GTC offer no benefit over one-time token. However, EAP-OTP and EAP-GTC offer no benefit over
the basic password authentication defined in Section 3.6.3, which the basic password authentication defined in Section 3.6.3, which
also does not perform crypto-binding of the inner method to the TLS also does not perform crypto-binding of the Inner Method to the TLS
session. These EAP methods are therefore not useful as Phase 2 session. These EAP methods are therefore not useful as Phase 2
methods within TEAP. methods within TEAP.
Other EAP methods are less widely used and highly likely to not work Other EAP methods are less widely used and highly likely to not work
as the inner EAP method for TEAP. as the inner EAP method for TEAP.
In order to protect from on-path attacks, TEAP implementations MUST In order to protect from on-path attacks, TEAP implementations MUST
NOT permit the use of inner EAP methods that fail to perform crypto- NOT permit the use of inner EAP methods that fail to perform crypto-
binding of the inner method to the TLS session. binding of the Inner Method to the TLS session.
Implementations MUST NOT permit resumption for the inner EAP methods Implementations MUST NOT permit resumption for the inner EAP methods
such as EAP-TLS. If the user or machine needs to be authenticated, such as EAP-TLS. If the user or machine needs to be authenticated,
it should use a method that provides full authentication. If the it should use a method that provides full authentication. If the
user or machine needs to do resumption, it can perform a full user or machine needs to do resumption, it can perform a full
authentication once and then rely on the outer TLS session for authentication once and then rely on the outer TLS session for
resumption. This restriction applies also to all TLS-based EAP resumption. This restriction applies also to all TLS-based EAP
methods that can tunnel other EAP methods. As a result, this methods that can tunnel other EAP methods. As a result, this
document updates [RFC9427]. document updates [RFC9427].
skipping to change at line 978 skipping to change at line 981
presented via EAP-TLS in Phase 2. presented via EAP-TLS in Phase 2.
For basic password authentication, it is RECOMMENDED that this method For basic password authentication, it is RECOMMENDED that this method
be only used for the exchange of one-time passwords. The existence be only used for the exchange of one-time passwords. The existence
of password-based EAP methods such as EAP-pwd ([RFC5931] and of password-based EAP methods such as EAP-pwd ([RFC5931] and
[RFC8146]) makes most cleartext password exchanges unnecessary. The [RFC8146]) makes most cleartext password exchanges unnecessary. The
updates to EAP-pwd in [RFC8146] permit it to be used with databases updates to EAP-pwd in [RFC8146] permit it to be used with databases
that store passwords in "salted" form, which greatly increases that store passwords in "salted" form, which greatly increases
security. security.
Where no inner method provides an EMSK, the Crypto-Binding TLV offers Where no Inner Method provides an EMSK, the Crypto-Binding TLV offers
little protection, as it cannot tie the inner EMSK to the TLS session little protection, as it cannot tie the inner EMSK to the TLS session
via the TLS-PRF. As a result, the TEAP session will be vulnerable to via the TLS-PRF. As a result, the TEAP session will be vulnerable to
on-path active attacks. Implementations and deployments SHOULD adopt on-path active attacks. Implementations and deployments SHOULD adopt
various mitigation strategies described in [RFC7029], Section 3.2. various mitigation strategies described in [RFC7029], Section 3.2.
Implementations also need to implement the inner method ordering Implementations also need to implement the Inner Method ordering
described in Section 6.1 in order to fully prevent on-path attacks. described in Section 6.1 in order to fully prevent on-path attacks.
3.6.6. Protected Termination and Acknowledged Result Indication 3.6.6. Protected Termination and Acknowledged Result Indication
A successful TEAP Phase 2 conversation MUST always end in a A successful TEAP Phase 2 conversation MUST always end in a
successful Crypto-Binding TLV and Result TLV exchange. A TEAP server successful Crypto-Binding TLV and Result TLV exchange. A TEAP server
may initiate the Crypto-Binding TLV and Result TLV exchange without may initiate the Crypto-Binding TLV and Result TLV exchange without
initiating any inner methods in TEAP Phase 2. After the final Result initiating any Inner Methods in TEAP Phase 2. After the final Result
TLV exchange, the TLS tunnel is terminated, and a cleartext EAP TLV exchange, the TLS tunnel is terminated, and a cleartext EAP
Success or EAP Failure is sent by the server. Peers implementing Success or EAP Failure is sent by the server. Peers implementing
TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior
to the peer and server reaching synchronized protected result to the peer and server reaching synchronized protected result
indication. indication.
The Crypto-Binding TLV exchange is used to prove that both the peer The Crypto-Binding TLV exchange is used to prove that both the peer
and server participated in the tunnel establishment and sequence of and server participated in the tunnel establishment and sequence of
authentications. It also provides verification of the TEAP type, authentications. It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment. Except as noted below, the Crypto-Binding TLV MUST be establishment. Except as noted below, the Crypto-Binding TLV MUST be
exchanged and verified before the final Result TLV exchange, exchanged and verified before the final Result TLV exchange,
regardless of whether or not there is an inner method. The Crypto- regardless of whether or not there is an Inner Method. The Crypto-
Binding TLV and Intermediate-Result TLV MUST be included to perform Binding TLV and Intermediate-Result TLV MUST be included to perform
cryptographic binding after each successful authentication in a cryptographic binding after each successful authentication in a
sequence of one or more inner methods. The server may send the final sequence of one or more Inner Methods. The server may send the final
Result TLV along with an Intermediate-Result TLV and a Crypto-Binding Result TLV along with an Intermediate-Result TLV and a Crypto-Binding
TLV to indicate its intention to end the conversation. If the peer TLV to indicate its intention to end the conversation. If the peer
requires nothing more from the server, it will respond with a Result requires nothing more from the server, it will respond with a Result
TLV indicating success accompanied by a Crypto-Binding TLV and TLV indicating success accompanied by a Crypto-Binding TLV and
Intermediate-Result TLV if necessary. The server then tears down the Intermediate-Result TLV if necessary. The server then tears down the
tunnel and sends a cleartext EAP Success or EAP Failure. tunnel and sends a cleartext EAP Success or EAP Failure.
If the peer receives a Result TLV indicating success from the server, If the peer receives a Result TLV indicating success from the server,
but its authentication policies are not satisfied (for example, it but its authentication policies are not satisfied (for example, it
requires a particular authentication mechanism to be run), it may requires a particular authentication mechanism to be run), it may
skipping to change at line 1101 skipping to change at line 1104
TEAP uses the error-handling rules summarized below: TEAP uses the error-handling rules summarized below:
1. Errors in the outer EAP packet layer are handled as defined in 1. Errors in the outer EAP packet layer are handled as defined in
Section 3.9.1. Section 3.9.1.
2. Errors in the TLS layer are communicated via TLS alert messages 2. Errors in the TLS layer are communicated via TLS alert messages
in both phases of TEAP. in both phases of TEAP.
3. The Intermediate-Result TLVs carry success or failure indications 3. The Intermediate-Result TLVs carry success or failure indications
of the individual inner methods in TEAP Phase 2. Errors within of the individual Inner Methods in TEAP Phase 2. Errors within
an EAP conversation in Phase 2 are expected to be handled by the an EAP conversation in Phase 2 are expected to be handled by the
individual EAP authentication methods. individual EAP authentication methods.
4. Violations of the Inner TLV rules are handled using Result TLVs 4. Violations of the Inner TLV rules are handled using Result TLVs
together with Error TLVs. together with Error TLVs.
5. Tunnel-compromised errors (errors caused by a failed or missing 5. Tunnel-compromised errors (errors caused by a failed or missing
Crypto-Binding) are handled using Result TLVs and Error TLVs. Crypto-Binding) are handled using Result TLVs and Error TLVs.
3.9.1. Outer-Layer Errors 3.9.1. Outer-Layer Errors
skipping to change at line 1181 skipping to change at line 1184
Fatal Error during TLV Exchanges: Fatal Error during TLV Exchanges:
For errors involving the processing of the sequence of exchanges, For errors involving the processing of the sequence of exchanges,
such as a violation of TLV rules (e.g., multiple EAP-Payload such as a violation of TLV rules (e.g., multiple EAP-Payload
TLVs), the error code is Unexpected TLVs Exchanged. TLVs), the error code is Unexpected TLVs Exchanged.
Fatal Error due to tunnel compromise: Fatal Error due to tunnel compromise:
For errors involving a tunnel compromise, such as when the Crypto- For errors involving a tunnel compromise, such as when the Crypto-
Binding TLV fails validation, the error code is Tunnel Compromise Binding TLV fails validation, the error code is Tunnel Compromise
Error. Error.
Non-Fatal Error due to inner method: Non-Fatal Error due to Inner Method:
If there is a non-fatal error while running the inner method, the If there is a non-fatal error while running the Inner Method, the
receiving side SHOULD NOT silently drop the inner method exchange. receiving side SHOULD NOT silently drop the Inner Method exchange.
Instead, it SHOULD reply with an Error TLV using the most Instead, it SHOULD reply with an Error TLV using the most
descriptive error code possible. descriptive error code possible.
If there is no error code that matches the particular issue, then If there is no error code that matches the particular issue, then
the value Inner Method Error (1001) SHOULD be used. This response the value Inner Method Error (1001) SHOULD be used. This response
is a positive indication that there was an error processing the is a positive indication that there was an error processing the
current inner method. The side receiving a non-fatal Error TLV current Inner Method. The side receiving a non-fatal Error TLV
MAY decide to start a new and different inner method instead or MAY decide to start a new and different Inner Method instead or
send back a Result TLV to terminate the TEAP authentication send back a Result TLV to terminate the TEAP authentication
session. session.
3.10. Fragmentation 3.10. Fragmentation
Fragmentation of EAP packets is discussed in [RFC5216], Fragmentation of EAP packets is discussed in [RFC5216],
Section 2.1.5. There is no special handling of fragments for TEAP. Section 2.1.5. There is no special handling of fragments for TEAP.
3.11. Services Requested by the Peer 3.11. Services Requested by the Peer
skipping to change at line 1215 skipping to change at line 1218
provided server certificate, then the server is authenticated. provided server certificate, then the server is authenticated.
Typically, this authentication process involves the peer validating Typically, this authentication process involves the peer validating
the certificate to a trust anchor by verifying that the server the certificate to a trust anchor by verifying that the server
presenting the certificate holds the private key and confirming that presenting the certificate holds the private key and confirming that
the entity named by the certificate is the intended server. Server the entity named by the certificate is the intended server. Server
authentication also occurs when the procedures in Section 3.2 are authentication also occurs when the procedures in Section 3.2 are
used to resume a session where the peer and server were previously used to resume a session where the peer and server were previously
mutually authenticated. Alternatively, the server is deemed to be mutually authenticated. Alternatively, the server is deemed to be
authenticated if an inner EAP method provides mutual authentication authenticated if an inner EAP method provides mutual authentication
along with an MSK and/or EMSK. The inner method MUST also provide along with an MSK and/or EMSK. The Inner Method MUST also provide
for cryptographic binding via the Compound Message Authentication for cryptographic binding via the Compound Message Authentication
Code (MAC), as discussed in Section 4.2.13. This issue is further Code (MAC), as discussed in Section 4.2.13. This issue is further
described in Section 3.11.3. described in Section 3.11.3.
TEAP peers MUST track whether or not server authentication has taken TEAP peers MUST track whether or not server authentication has taken
place. When the server cannot be authenticated, the peer MUST NOT place. When the server cannot be authenticated, the peer MUST NOT
request any services such as certificate provisioning request any services such as certificate provisioning
(Section 3.11.1) from it. (Section 3.11.1) from it.
Unless the peer requests server unauthenticated provisioning, it MUST Unless the peer requests server unauthenticated provisioning, it MUST
authenticate the server, and fail the current authentication session authenticate the server and fail the current authentication session.
fails if the server cannot be authenticated. The authentication session fails if the server cannot be
authenticated.
An additional complication arises when an inner method authenticates An additional complication arises when an Inner Method authenticates
multiple parties, such as authenticating both the peer machine and multiple parties, such as authenticating both the peer machine and
the peer user to the EAP server. Depending on how authentication is the peer user to the EAP server. Depending on how authentication is
achieved, only some of these parties may have confidence in it. For achieved, only some of these parties may have confidence in it. For
example, if a strong shared secret is used to mutually authenticate example, if a strong shared secret is used to mutually authenticate
the user and the EAP server, the machine may not have confidence that the user and the EAP server, the machine may not have confidence that
the EAP server is the authenticated party if the machine cannot trust the EAP server is the authenticated party if the machine cannot trust
the user not to disclose the shared secret to an attacker. In these the user not to disclose the shared secret to an attacker. In these
cases, the parties who participate in the authentication need to be cases, the parties who participate in the authentication need to be
considered when evaluating whether the peer should request these considered when evaluating whether the peer should request these
services or whether the server should provide them. services or whether the server should provide them.
skipping to change at line 1276 skipping to change at line 1280
authenticates and obtains new credentials via the standard authenticates and obtains new credentials via the standard
provisioning mechanisms. The only caveat is that the device SHOULD provisioning mechanisms. The only caveat is that the device SHOULD
NOT discard the old credentials unless either they are known to have NOT discard the old credentials unless either they are known to have
expired or the new credentials have been verified to work. expired or the new credentials have been verified to work.
3.11.1. Certificate Provisioning Within the Tunnel 3.11.1. Certificate Provisioning Within the Tunnel
Provisioning of a peer's certificate is supported in TEAP by Provisioning of a peer's certificate is supported in TEAP by
performing the Simple PKI Request/Response from [RFC5272] using performing the Simple PKI Request/Response from [RFC5272] using
PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI
Request using a PKCS#10 CertificateRequest [RFC2986] encoded into the Request using a PKCS#10 CertificationRequest [RFC2986] encoded into
body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server
Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e., issues a Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e.,
degenerate) "Certificates Only" message encoded into the body of a degenerate) "Certificates Only" message encoded into the body of a
PKCS#7 TLV (see Section 4.2.16) only after an inner method has run PKCS#7 TLV (see Section 4.2.16) only after an Inner Method has run
and provided an identity proof on the peer prior to a certificate is and provided an identity proof on the peer prior to a certificate is
being issued. being issued.
In order to provide linking identity and proof-of-possession by In order to provide linking identity and proof-of-possession by
including information specific to the current authenticated TLS including information specific to the current authenticated TLS
session within the signed certification request, the peer generating session within the signed certification request, the peer generating
the request SHOULD obtain the tls-unique value from the TLS subsystem the request SHOULD obtain the tls-unique value from the TLS subsystem
as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer
operations between obtaining the tls-unique value through generation operations between obtaining the tls-unique value through generation
of the Certification Signing Request (CSR) that contains the current of the Certification Signing Request (CSR) that contains the current
skipping to change at line 1345 skipping to change at line 1349
refuse a particular CSR to address these deficiencies for any refuse a particular CSR to address these deficiencies for any
reasons, including local site policy. We note that the "A" in "CA" reasons, including local site policy. We note that the "A" in "CA"
means for "Authority", while the "R" in "CSR" means "Request". There means for "Authority", while the "R" in "CSR" means "Request". There
is no requirement for a CA to sign any and all CSRs that are is no requirement for a CA to sign any and all CSRs that are
presented to it. presented to it.
Once an EAP peer receives the signed certificate, the peer could Once an EAP peer receives the signed certificate, the peer could
potentially be (ab)used for in TLS contexts other than TEAP. For potentially be (ab)used for in TLS contexts other than TEAP. For
example, the certificate could be used with EAP-TLS, or even with example, the certificate could be used with EAP-TLS, or even with
HTTPS. It is NOT RECOMMENDED to use certificates provisioned via HTTPS. It is NOT RECOMMENDED to use certificates provisioned via
TEAP for any non-TEAP protocol. One method of enforcing this TEAP for any non-TEAP. One method of enforcing this restriction is
restriction is to have different CAs (or different intermediate CAs) to have different CAs (or different intermediate CAs) that issue
that issue certificates for different uses. For example, TLS-based certificates for different uses. For example, TLS-based EAP methods
EAP methods could share one CA, and even use different intermediary could share one CA, and even use different intermediary CAs for
CAs for different TLS-based EAP methods. HTTPS servers could use an different TLS-based EAP methods. HTTPS servers could use an entirely
entirely different CA. The different protocols could then be different CA. The different protocols could then be configured to
configured to validate client certificates only from their preferred validate client certificates only from their preferred CA, which
CA, which would prevent peers from using certificates outside of the would prevent peers from using certificates outside of the intended
intended use case. use case.
Another method of limiting the uses of a certificate is to provision Another method of limiting the uses of a certificate is to provision
it with an appropriate value for the Extended Key Usage field it with an appropriate value for the Extended Key Purpose field
[RFC7299]. For example, the id-kp-eapOverLAN [RFC4334] value could [RFC7299]. For example, the id-kp-eapOverLAN [RFC4334] value could
be used to indicate that this certificate is intended for use only be used to indicate that this certificate is intended for use only
with EAP. with EAP.
It is difficult to give more detailed recommendations than the above. It is difficult to give more detailed recommendations than the above.
Each CA or organization may have its own local policy as to what is Each CA or organization may have its own local policy as to what is
permitted or forbidden in a certificate. All we can do in this permitted or forbidden in a certificate. All we can do in this
document is to highlight the issues and make the reader aware that document is to highlight the issues and make the reader aware that
they have to be addressed. they have to be addressed.
3.11.3. Server Unauthenticated Provisioning Mode 3.11.3. Server Unauthenticated Provisioning Mode
In Server Unauthenticated Provisioning Mode, an unauthenticated In Server Unauthenticated Provisioning Mode, an unauthenticated
tunnel is established in Phase 1, and the peer and server negotiate tunnel is established in Phase 1, and the peer and server negotiate
an inner method or methods in Phase 2. This inner method MUST an Inner Method or methods in Phase 2. This Inner Method MUST
support mutual authentication, provide key derivation, and be support mutual authentication, provide key derivation, and be
resistant to attacks such as on-path and dictionary attacks. In most resistant to attacks such as on-path and dictionary attacks. In most
cases, this inner method will be an EAP authentication method. cases, this Inner Method will be an EAP authentication method.
Example inner methods that satisfy these criteria include EAP-pwd Example Inner Methods that satisfy these criteria include EAP-pwd
[RFC5931] and EAP-EKE [RFC6124] but not EAP-FAST-MSCHAPv2. [RFC5931] and EAP-EKE [RFC6124] but not EAP-FAST-MSCHAPv2.
This provisioning mode enables the bootstrapping of peers when the This provisioning mode enables the bootstrapping of peers when the
peer lacks the ability to authenticate the server during Phase 1. peer lacks the ability to authenticate the server during Phase 1.
This includes both cases in which the cipher suite negotiated does This includes both cases in which the cipher suite negotiated does
not provide authentication and in which the cipher suite negotiated not provide authentication and in which the cipher suite negotiated
provides the authentication, but the peer is unable to validate the provides the authentication, but the peer is unable to validate the
identity of the server for some reason. identity of the server for some reason.
Upon successful completion of the inner method in Phase 2, the peer Upon successful completion of the Inner Method in Phase 2, the peer
and server exchange a Crypto-Binding TLV to bind the inner method and server exchange a Crypto-Binding TLV to bind the Inner Method
with the outer tunnel and ensure that an on-path attack has not been with the outer tunnel and ensure that an on-path attack has not been
attempted. attempted.
Support for the Server Unauthenticated Provisioning Mode is optional. Support for the Server Unauthenticated Provisioning Mode is optional.
The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when
using Server Unauthenticated Provisioning Mode, but other anonymous using Server Unauthenticated Provisioning Mode, but other anonymous
cipher suites MAY be supported as long as the TLS pre-master secret cipher suites MAY be supported as long as the TLS pre-master secret
is generated from contribution from both peers. is generated from contribution from both peers.
When a strong inner method is not used with Server Unauthenticated When a strong Inner Method is not used with Server Unauthenticated
Provisioning Mode, it is possible for an attacker to perform an on- Provisioning Mode, it is possible for an attacker to perform an on-
path attack. In effect, Server Unauthenticated Provisioning Mode has path attack. In effect, Server Unauthenticated Provisioning Mode has
similar security issues as just running the inner method in the open similar security issues as just running the Inner Method in the open
without the protection of TLS. All of the information in the tunnel without the protection of TLS. All of the information in the tunnel
should be assumed to be visible to, and modifiable by, an attacker. should be assumed to be visible to, and modifiable by, an attacker.
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 tunnel mode to set up a secure/authenticated tunnel and then use that tunnel
to perform any needed data exchange. 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
skipping to change at line 1540 skipping to change at line 1544
TLS Data TLS Data
When the TLS Data field is present, it consists of an encapsulated When the TLS Data field is present, it consists of an encapsulated
TLS packet in TLS record format. A TEAP packet with Flags and TLS packet in TLS record format. A TEAP packet with Flags and
Version fields, but with zero length TLS Data field, is used to Version fields, but with zero length TLS Data field, is used to
indicate TEAP acknowledgment for either a fragmented message, a indicate TEAP acknowledgment for either a fragmented message, a
TLS Alert message, or a TLS Finished message. TLS Alert message, or a TLS Finished message.
Outer TLVs Outer TLVs
The Outer TLVs consist of the optional data used to help establish The Outer TLVs consist of the optional data used to help establish
the TLS tunnel in TLV format. They are only allowed in the first the TLS tunnel in TLV format. They are only allowed in the first
two messages in the TEAP protocol. That is the first EAP-server- two messages in the TEAP. That is the first EAP-server-to-peer
to-peer message and first peer-to-EAP-server message. The start message and first peer-to-EAP-server message. The start of the
of the Outer TLVs can be derived from the EAP Length field and Outer TLVs can be derived from the EAP Length field and Outer TLV
Outer TLV Length field. Length field.
4.2. TEAP TLV Format and Support 4.2. TEAP TLV Format and Support
The TLVs defined here are TLV objects. The TLV objects could be used The TLVs defined here are TLV objects. The TLV objects could be used
to carry arbitrary parameters between an EAP peer and EAP server to carry arbitrary parameters between an EAP peer and EAP server
within the protected TLS tunnel. within the protected TLS tunnel.
The EAP peer may not necessarily implement all the TLVs supported by The EAP peer may not necessarily implement all the TLVs supported by
the EAP server. To allow for interoperability, TLVs are designed to the EAP server. To allow for interoperability, TLVs are designed to
allow an EAP server to discover if a TLV is supported by the EAP peer allow an EAP server to discover if a TLV is supported by the EAP peer
skipping to change at line 1750 skipping to change at line 1754
user authentication, or else only machine authentication. A server user authentication, or else only machine authentication. A server
could also use an Identity-Hint TLV sent in the response to permit could also use an Identity-Hint TLV sent in the response to permit
different types of authentication for different identities. A server different types of authentication for different identities. A server
could also permit or forbid different kinds of authentication based could also permit or forbid different kinds of authentication based
on other information, such an outer EAP Identity, fields in an outer on other information, such an outer EAP Identity, fields in an outer
EAP client certificate, or other fields received in a RADIUS or EAP client certificate, or other fields received in a RADIUS or
Diameter packet along with the TEAP session. There is no requirement Diameter packet along with the TEAP session. There is no requirement
that a server has to support both user and machine authentication for that a server has to support both user and machine authentication for
all TEAP sessions. all TEAP sessions.
The second condition ensures that if a particular inner method The second condition ensures that if a particular Inner Method
succeeds, the server does not attempt a subsequent inner method for succeeds, the server does not attempt a subsequent Inner Method for
the same Identity-Type. For example, if a user is authenticated via the same Identity-Type. For example, if a user is authenticated via
an inner method of EAP-TLS, there is no benefit to also requesting an Inner Method of EAP-TLS, there is no benefit to also requesting
additional authentication via a different inner method. Similarly, additional authentication via a different Inner Method. Similarly,
there is no benefit to repeating an authentication sessions for the there is no benefit to repeating an authentication sessions for the
same user; the result will not change. same user; the result will not change.
This second condition also forbids multiple rounds of challenge/ This second condition also forbids multiple rounds of challenge/
response authentication via the Basic-Password-Auth-Req TLV. TEAPv1 response authentication via the Basic-Password-Auth-Req TLV. TEAPv1
supports only one round of Basic-Password-Auth-Req followed by Basic- supports only one round of Basic-Password-Auth-Req followed by Basic-
Password-Auth-Resp. The result of that round MUST NOT be another Password-Auth-Resp. The result of that round MUST NOT be another
Basic-Password-Auth-Req TLV. Basic-Password-Auth-Req TLV.
This second condition also means that a server MUST NOT send an This second condition also means that a server MUST NOT send an
skipping to change at line 1807 skipping to change at line 1811
4.2.4. Result TLV 4.2.4. Result TLV
The Result TLV provides support for acknowledged success and failure The Result TLV provides support for acknowledged success and failure
messages for protected termination within TEAP. If the Status field messages for protected termination within TEAP. If the Status field
does not contain one of the known values, then the peer or EAP server does not contain one of the known values, then the peer or EAP server
MUST treat this as a fatal error of Unexpected TLVs Exchanged. The MUST treat this as a fatal error of Unexpected TLVs Exchanged. The
behavior of the Result TLV is further discussed in Sections 3.6.6 and behavior of the Result TLV is further discussed in Sections 3.6.6 and
3.9.3. 3.9.3.
A Result TLV indicating failure MUST NOT be accompanied by the A Result TLV indicating failure MUST NOT be accompanied by the
following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV. following TLVs: NAK, EAP-Payload, or Crypto-Binding.
A Result TLV indicating success MUST be accompanied by a Crypto- A Result TLV indicating success MUST be accompanied by a Crypto-
Binding TLV. Binding TLV.
The Result TLV is defined as follows: The Result 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 |
skipping to change at line 1901 skipping to change at line 1905
4.2.6. Error TLV 4.2.6. Error TLV
The Error TLV allows an EAP peer or server to indicate errors to the The Error TLV allows an EAP peer or server to indicate errors to the
other party. A TEAP packet can contain 0 or more Error TLVs. The other party. A TEAP packet can contain 0 or more Error TLVs. The
Error-Code field describes the type of error. Error codes 1-999 Error-Code field describes the type of error. Error codes 1-999
represent successful outcomes (informative messages), 1000-1999 represent successful outcomes (informative messages), 1000-1999
represent warnings, and 2000-2999 represent fatal errors. A fatal represent warnings, and 2000-2999 represent fatal errors. A fatal
Error TLV MUST be accompanied by a Result TLV indicating failure, and Error TLV MUST be accompanied by a Result TLV indicating failure, and
the conversation is terminated as described in Section 3.9.3. the conversation is terminated as described in Section 3.9.3.
Many of the error codes below refer to errors in inner method Many of the error codes below refer to errors in Inner Method
processing that may be retrieved if made available by the inner processing that may be retrieved if made available by the inner
method. Implementations MUST take care that error messages do not method. Implementations MUST take care that error messages do not
reveal too much information to an attacker. For example, the usage reveal too much information to an attacker. For example, the usage
of error message 1031 (User account credentials incorrect) is NOT of error message 1031 (User account credentials incorrect) is NOT
RECOMMENDED, because it allows an attacker to determine valid RECOMMENDED, because it allows an attacker to determine valid
usernames by differentiating this response from other responses. It usernames by differentiating this response from other responses. It
should only be used for troubleshooting purposes. should only be used for troubleshooting purposes.
The Error TLV is defined as follows: The Error TLV is defined as follows:
skipping to change at line 2002 skipping to change at line 2006
1023 Unsupported Extension In Certificate Signing Request 1023 Unsupported Extension In Certificate Signing Request
1024 Bad Identity In Certificate Signing Request 1024 Bad Identity In Certificate Signing Request
1025 Bad Certificate Signing Request 1025 Bad Certificate Signing Request
1026 Internal CA Error 1026 Internal CA Error
1027 General PKI Error 1027 General PKI Error
1028 Inner method's channel-binding data required but not 1028 Inner Method's channel-binding data required but not
supplied supplied
1029 Inner method's channel-binding data did not include required 1029 Inner Method's channel-binding data did not include required
information information
1030 Inner method's channel binding failed 1030 Inner Method's channel binding failed
1031 User account credentials incorrect [USAGE NOT RECOMMENDED] 1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
1032 Inner method not supported 1032 Inner Method not supported
2001 Tunnel Compromise Error 2001 Tunnel Compromise Error
2002 Unexpected TLVs Exchanged 2002 Unexpected TLVs Exchanged
2003 The Crypto-Binding TLV is invalid (Version, Received-Ver, or 2003 The Crypto-Binding TLV is invalid (Version, Received-Ver, or
Sub-Type) Sub-Type)
2004 The first inner method did not derive EMSK 2004 The first Inner Method did not derive EMSK
2005 The Crypto-Binding TLV did not include a required MSK 2005 The Crypto-Binding TLV did not include a required MSK
Compound-MAC Compound MAC
2006 The MSK Compound-MAC fails verification 2006 The MSK Compound MAC fails verification
2007 The Crypto-Binding TLV did not include a required EMSK 2007 The Crypto-Binding TLV did not include a required EMSK
Compound-MAC Compound MAC
2008 The EMSK Compound-MAC fails verification 2008 The EMSK Compound MAC fails verification
2009 The EMSK Compound-MAC exists, but the inner method did not 2009 The EMSK Compound MAC exists, but the Inner Method did not
derive EMSK derive EMSK
4.2.7. Channel-Binding TLV 4.2.7. Channel-Binding TLV
The Channel-Binding TLV provides a mechanism for carrying channel- The Channel-Binding TLV provides a mechanism for carrying channel-
binding data from the peer to the EAP server and a channel-binding binding data from the peer to the EAP server and a channel-binding
response from the EAP server to the peer as described in [RFC6677]. response from the EAP server to the peer as described in [RFC6677].
TEAPv1 implementations MAY support this TLV, which cannot be TEAPv1 implementations MAY support this TLV, which cannot be
responded to with a NAK TLV. If the Channel-Binding data field does responded to with a NAK TLV. If the Channel-Binding data field does
not contain one of the known values or if the EAP server does not not contain one of the known values or if the EAP server does not
skipping to change at line 2092 skipping to change at line 2096
defined. defined.
Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Vendor TLVs may be optional or mandatory. Vendor TLVs sent with
Result TLVs MUST be marked as optional. If the Vendor-Specific TLV Result TLVs MUST be marked as optional. If the Vendor-Specific TLV
is marked as mandatory, then it is expected that the receiving side is marked as mandatory, then it is expected that the receiving side
needs to recognize the vendor ID, parse all Vendor TLVs within, and needs to recognize the vendor ID, parse all Vendor TLVs within, and
deal with error handling within the Vendor-Specific TLV as defined by deal with error handling within the Vendor-Specific TLV as defined by
the vendor. the vendor.
Where a Vendor-Specific TLV carries an authentication protocol in the Where a Vendor-Specific TLV carries an authentication protocol in the
inner method, it MUST define values for MSK and EMSK. Where these Inner Method, it MUST define values for MSK and EMSK. Where these
values cannot be derived from cryptographic primitives, they MUST be values cannot be derived from cryptographic primitives, they MUST be
set to zero, as happens when Basic-Password-Auth-Req is used. set to zero, as happens when Basic-Password-Auth-Req is used.
The Vendor-Specific TLV is defined as follows: The Vendor-Specific 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2134 skipping to change at line 2138
Vendor in network byte order. Vendor in network byte order.
Vendor TLVs Vendor TLVs
This field is of indefinite length. It contains Vendor-Specific This field is of indefinite length. It contains Vendor-Specific
TLVs, in a format defined by the vendor. TLVs, in a format defined by the vendor.
4.2.9. Request-Action TLV 4.2.9. Request-Action TLV
The Request-Action TLV MAY be sent at any time. The Request-Action The Request-Action TLV MAY be sent at any time. The Request-Action
TLV allows the peer or server to request that the other side TLV allows the peer or server to request that the other side
negotiates additional inner methods or process TLVs that are passed negotiates additional Inner Methods or process TLVs that are passed
inside of the Request-Action TLV. inside of the Request-Action TLV.
The receiving side MUST process this TLV. The processing for the TLV The receiving side MUST process this TLV. The processing for the TLV
is as follows: is as follows:
The receiving entity MAY choose to process any of the TLVs that The receiving entity MAY choose to process any of the TLVs that
are included in the message. are included in the message.
If the receiving entity chooses NOT to process any TLV in the If the receiving entity chooses NOT to process any TLV in the
list, then it sends back a Result TLV with the same code in the list, then it sends back a Result TLV with the same code in the
skipping to change at line 2159 skipping to change at line 2163
processed. processed.
If multiple Request-Action TLVs are in the request and none of If multiple Request-Action TLVs are in the request and none of
them is processed, then the most fatal status should be used in them is processed, then the most fatal status should be used in
the Result TLV returned. If a status code in the Request-Action the Result TLV returned. If a status code in the Request-Action
TLV is not understood by the receiving entity, then it SHOULD be TLV is not understood by the receiving entity, then it SHOULD be
treated as a fatal error. Otherwise, the receiving entity MAY treated as a fatal error. Otherwise, the receiving entity MAY
send a Request-Action TLV containing an Error TLV of value 2002 send a Request-Action TLV containing an Error TLV of value 2002
(Unexpected TLVs Exchanged). (Unexpected TLVs Exchanged).
After processing the TLVs or inner method in the request, another After processing the TLVs or Inner Method in the request, another
round of Result TLV exchange MUST occur to synchronize the final round of Result TLV exchange MUST occur to synchronize the final
status on both sides. status on both sides.
The peer or the server MAY send multiple Request-Action TLVs to the The peer or the server MAY send multiple Request-Action TLVs to the
other side. Two Request-Action TLVs MUST NOT occur in the same TEAP other side. Two Request-Action TLVs MUST NOT occur in the same TEAP
packet if they have the same Status value. The order of processing packet if they have the same Status value. The order of processing
multiple Request-Action TLVs is implementation dependent. If the multiple Request-Action TLVs is implementation dependent. If the
receiving side processes the optional (non-fatal) items first, it is receiving side processes the optional (non-fatal) items first, it is
possible that the fatal items will disappear at a later time. If the possible that the fatal items will disappear at a later time. If the
receiving side processes the fatal items first, the communication receiving side processes the fatal items first, the communication
skipping to change at line 2267 skipping to change at line 2271
This (optional) field contains a list of TLVs associated with the This (optional) field contains a list of TLVs associated with the
EAP packet field. The TLVs MUST NOT have the mandatory bit set. EAP packet field. The TLVs MUST NOT have the mandatory bit set.
The total length of this field is equal to the Length field of the The total length of this field is equal to the Length field of the
EAP-Payload TLV, minus the Length field in the EAP header of the EAP-Payload TLV, minus the Length field in the EAP header of the
EAP packet field. EAP packet field.
4.2.11. Intermediate-Result TLV 4.2.11. Intermediate-Result TLV
The Intermediate-Result TLV signals intermediate Success and Failure The Intermediate-Result TLV signals intermediate Success and Failure
messages for all inner methods. The Intermediate-Result TLV MUST be messages for all inner methods. The Intermediate-Result TLV MUST be
used for all inner methods. used for all Inner Methods.
An Intermediate-Result TLV indicating success MUST be accompanied by An Intermediate-Result TLV indicating success MUST be accompanied by
a Crypto-Binding TLV. a Crypto-Binding TLV.
An Intermediate-Result TLV indicating failure SHOULD be accompanied An Intermediate-Result TLV indicating failure SHOULD be accompanied
by an Error TLV that indicates why the authentication failed. by an Error TLV that indicates why the authentication failed.
The optional TLVs associated with this TLV are provided for future The optional TLVs associated with this TLV are provided for future
extensibility to provide hints about the current result. The extensibility to provide hints about the current result. The
Intermediate-Result TLV is defined as follows: Intermediate-Result TLV is defined as follows:
skipping to change at line 2337 skipping to change at line 2341
participated in the tunnel establishment and sequence of participated in the tunnel establishment and sequence of
authentications. It also provides verification of the TEAP type, authentications. It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment. establishment.
A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV
indicating success. indicating success.
The Crypto-Binding TLV MUST be exchanged and validated before any The Crypto-Binding TLV MUST be exchanged and validated before any
Intermediate-Result or Result TLV value is examined, regardless of Intermediate-Result or Result TLV value is examined, regardless of
whether there is an inner method or not. It MUST be included with whether there is an Inner Method or not. It MUST be included with
the Intermediate-Result TLV to perform cryptographic binding after the Intermediate-Result TLV to perform cryptographic binding after
each successful inner method in a sequence of inner methods, before each successful Inner Method in a sequence of inner methods, before
proceeding with another inner method. If no MSK or EMSK has been proceeding with another Inner Method. If no MSK or EMSK has been
generated and a Crypto-Binding TLV is required, then the MSK generated and a Crypto-Binding TLV is required, then the MSK Compound
Compound-MAC field contains the MAC using keys generated according to MAC field contains the MAC using keys generated according to
Section 6.3. Section 6.3.
The Crypto-Binding TLV is valid only if the following checks pass on The Crypto-Binding TLV is valid only if the following checks pass on
its contents: its contents:
* The Version field contain a known value. * The Version field contain a known value.
* The Received-Ver field matches the TEAP version sent by the * The Received-Ver field matches the TEAP version sent by the
receiver during the EAP version negotiation. receiver during the EAP version negotiation.
* The Sub-Type field is set to the correct value for this exchange. * The Sub-Type field is set to the correct value for this exchange.
* The Flags field is set to a known value. * The Flags field is set to a known value.
* The Compound-MAC(s) verify correctly. * The Compound MAC(s) verify correctly.
If any of the above checks fails, then the TLV is invalid. An If any of the above checks fails, then the TLV is invalid. An
invalid Crypto-Binding TLV is a fatal error and is handled as invalid Crypto-Binding TLV is a fatal error and is handled as
described in Section 3.9.3 described in Section 3.9.3
See Section 6 for a more detailed discussion of how the Compound-MAC See Section 6 for a more detailed discussion of how the Compound MAC
fields are constructed and verified. fields are constructed and verified.
The Crypto-Binding TLV is defined as follows: The Crypto-Binding 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Version | Received-Ver.| Flags|Sub-Type| | Reserved | Version | Received-Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Nonce ~ ~ Nonce ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ EMSK Compound-MAC ~ ~ EMSK Compound MAC ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ MSK Compound-MAC ~ ~ MSK Compound MAC ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M M
Mandatory, set to one (1) Mandatory, set to one (1)
R R
Reserved, set to zero (0) Reserved, set to zero (0)
TLV Type TLV Type
skipping to change at line 2421 skipping to change at line 2425
TEAP version number received during version negotiation. Note TEAP version number received during version negotiation. Note
that this field only provides protection against downgrade that this field only provides protection against downgrade
attacks, where a version of EAP requiring support for this TLV is attacks, where a version of EAP requiring support for this TLV is
required on both sides. required on both sides.
For TEAPv1, this version number MUST be set to one (1). For TEAPv1, this version number MUST be set to one (1).
Flags Flags
The Flags field is four bits. Defined values include: The Flags field is four bits. Defined values include:
1 EMSK Compound-MAC is present 1 EMSK Compound MAC is present
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
All other values of the Flags field are invalid. All other values of the Flags field are invalid.
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
All other values of the Sub-Type field are invalid. All other values of the Sub-Type field are invalid.
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).
EMSK Compound-MAC EMSK Compound MAC
The EMSK Compound-MAC field is 20 octets. This can be the Server The EMSK Compound MAC field is 20 octets. This can be the Server
MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
MAC is described in Section 6.3. MAC is described in Section 6.3.
Note that this field is always 20 octets in length. Any larger Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be MAC is simply truncated. All validations or comparisons MUST be
done on the truncated value. done on the truncated value.
MSK Compound-MAC MSK Compound MAC
The MSK Compound-MAC field is 20 octets. This can be the Server The MSK Compound MAC field is 20 octets. This can be the Server
MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the
MAC is described in Section 6.3. MAC is described in Section 6.3.
Note that this field is always 20 octets in length. Any larger Note that this field is always 20 octets in length. Any larger
MAC is simply truncated. All validations or comparisons MUST be MAC is simply truncated. All validations or comparisons MUST be
done on the truncated value. done on the truncated value.
4.2.14. Basic-Password-Auth-Req TLV 4.2.14. Basic-Password-Auth-Req TLV
The Basic-Password-Auth-Req TLV is used by the authentication server The Basic-Password-Auth-Req TLV is used by the authentication server
skipping to change at line 2482 skipping to change at line 2486
The Basic-Password-Auth-Req TLV is defined as follows: The Basic-Password-Auth-Req 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prompt .... | Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Mandatory, set to one (1) M
Mandatory, set to one (1)
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 13 - Basic-Password-Auth-Req TLV TLV Type
13 - Basic-Password-Auth-Req TLV
Length variable Length
variable
Prompt optional user prompt message in UTF-8 [RFC3629] format Prompt
optional user prompt message in UTF-8 [RFC3629] format
4.2.15. Basic-Password-Auth-Resp TLV 4.2.15. Basic-Password-Auth-Resp TLV
The Basic-Password-Auth-Resp TLV is used by the peer to respond to a The Basic-Password-Auth-Resp TLV is used by the peer to respond to a
Basic-Password-Auth-Req TLV with a username and password. The TLV Basic-Password-Auth-Req TLV with a username and password. The TLV
contains a username and password. The username and password are in contains a username and password. The username and password are in
UTF-8 [RFC3629] format. UTF-8 [RFC3629] format.
The Basic-Password-Auth-Resp TLV is defined as follows: The Basic-Password-Auth-Resp TLV is defined as follows:
skipping to change at line 2515 skipping to change at line 2524
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Userlen | Username | Userlen | Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Username ... ... Username ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Passlen | Password | Passlen | Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... Password ... ... Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Mandatory, set to one (1) M
Mandatory, set to one (1)
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 14 - Basic-Password-Auth-Resp TLV TLV Type
14 - Basic-Password-Auth-Resp TLV
Length variable Length
variable
Userlen Length of Username field in octets. Userlen
Length of Username field in octets.
The value of Userlen MUST NOT be zero. The value of Userlen MUST NOT be zero.
Username Username in UTF-8 [RFC3629] format. Username
Username in UTF-8 [RFC3629] format.
The content of Username SHOULD follow the guidelines set in The content of Username SHOULD follow the guidelines set in
[RFC9427], Section 3.1. [RFC9427], Section 3.1.
Passlen Length of Password field in octets. Passlen
Length of Password field in octets.
The value of Passlen MUST NOT be zero. The value of Passlen MUST NOT be zero.
Password Password in UTF-8 [RFC3629] format. Password
Password in UTF-8 [RFC3629] format.
Note that there is no requirement that passwords be humanly Note that there is no requirement that passwords be humanly
readable. Octets in a passwords may have values less than 0x20, readable. Octets in a passwords may have values less than 0x20,
including 0x00. including 0x00.
4.2.16. PKCS#7 TLV 4.2.16. PKCS#7 TLV
The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to
the peer. The format consists of a certificate or certificate chain the peer. The format consists of a certificate or certificate chain
in binary DER encoding [X.690] in a degenerate Certificates Only in binary DER encoding [X.690] in a degenerate Certificates Only
skipping to change at line 2580 skipping to change at line 2597
The PKCS#7 TLV is defined as follows: The PKCS#7 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 Data... | PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV M
0 - Optional TLV
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 15 - PKCS#7 TLV TLV Type
15 - PKCS#7 TLV
Length The length of the PKCS#7 Data field. Length
The length of the PKCS#7 Data field.
PKCS#7 Data This field contains the DER-encoded X.509 certificate or PKCS#7 Data
This field contains the DER-encoded X.509 certificate or
certificate chain in a Certificates-Only PKCS#7 SignedData certificate chain in a Certificates-Only PKCS#7 SignedData
message. message.
4.2.17. PKCS#10 TLV 4.2.17. PKCS#10 TLV
The PKCS#10 TLV is used by the peer to initiate the "Simple PKI" The PKCS#10 TLV is used by the peer to initiate the "Simple PKI"
Request/Response from [RFC5272]. The format of the request is as Request/Response from [RFC5272]. The format of the request is as
specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always
marked as optional, which cannot be responded to with a NAK TLV. marked as optional, which cannot be responded to with a NAK TLV.
The PKCS#10 TLV is defined as follows: The PKCS#10 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#10 Data... | PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV M
0 - Optional TLV
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 16 - PKCS#10 TLV TLV Type
16 - PKCS#10 TLV
Length The length of the PKCS#10 Data field. Length
The length of the PKCS#10 Data field.
PKCS#10 Data This field contains the DER-encoded PKCS#10 certificate PKCS#10 Data
request. This field contains the DER-encoded PKCS#10 certificate request.
4.2.18. Trusted-Server-Root TLV 4.2.18. Trusted-Server-Root TLV
Trusted-Server-Root TLV facilitates the request and delivery of a Trusted-Server-Root TLV facilitates the request and delivery of a
trusted server root certificate. The Trusted-Server-Root TLV can be trusted server root certificate. The Trusted-Server-Root TLV can be
exchanged in regular TEAP authentication mode or provisioning mode. exchanged in regular TEAP authentication mode or provisioning mode.
The Trusted-Server-Root TLV is always marked as optional and cannot The Trusted-Server-Root TLV is always marked as optional and cannot
be responded to with a NAK TLV. The Trusted-Server-Root TLV MUST be responded to with a NAK TLV. The Trusted-Server-Root TLV MUST
only be sent as an Inner TLV (inside the protection of the tunnel). only be sent as an Inner TLV (inside the protection of the tunnel).
skipping to change at line 2661 skipping to change at line 2687
The Trusted-Server-Root TLV is defined as follows: The Trusted-Server-Root 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential-Format | Cred TLVs... | Credential-Format | Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV M
0 - Optional TLV
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 17 - Trusted-Server-Root TLV TLV Type
17 - Trusted-Server-Root TLV
Length >=2 octets Length
>=2 octets
Credential-Format The Credential-Format field is two octets. Values Credential-Format
include: The Credential-Format field is two octets. Values include:
1 - PKCS#7-Server-Certificate-Root 1 - PKCS#7-Server-Certificate-Root
Cred TLVs This field is of indefinite length. It contains TLVs Cred TLVs
associated with the credential format. The peer may leave this This field is of indefinite length. It contains TLVs associated
field empty when using this TLV to request server trust roots. with the credential format. The peer may leave this field empty
when using this TLV to request server trust roots.
4.2.19. CSR-Attributes TLV 4.2.19. CSR-Attributes TLV
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
skipping to change at line 2710 skipping to change at line 2741
The CSR-Attributes TLV is defined as follows: The CSR-Attributes 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DER Encoded CSR Attributes | | DER Encoded CSR Attributes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV M
0 - Optional TLV
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 18 - CSR-Attributes TLV Type
18 - CSR-Attributes
Length >=2 octets Length
>=2 octets
4.2.20. Identity-Hint TLV 4.2.20. Identity-Hint TLV
The Identity-Hint TLV is an optional TLV that can be sent by the peer The Identity-Hint TLV is an optional TLV that can be sent by the peer
to the server at the beginning of the Phase 2 TEAP conversation. The to the server at the beginning of the Phase 2 TEAP conversation. The
purpose of the TLV is to provide a "hint" as to the identity or purpose of the TLV is to provide a "hint" as to the identity or
identities that the peer will be using by subsequent inner methods. identities that the peer will be using by subsequent Inner Methods.
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 used, 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
that is appropriate for that identity. that is appropriate for that identity.
The peer SHOULD send an Identity-Hint TLV for each Identity-Type that The peer SHOULD send an Identity-Hint TLV for each Identity-Type that
is available to it. For example, if the peer can do both machine and is available to it. For example, if the peer can do both machine and
user authentication, it can send two Identity-Hint TLVs with values user authentication, it can send two Identity-Hint TLVs with values
"host/name.example.com" (for a machine with hostname "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").
The contents of the Identity-Hint TLV SHOULD be in the format of an The contents of the Identity-Hint TLV SHOULD be in the format of an
skipping to change at line 2758 skipping to change at line 2793
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 are entirely site the format and definition of these identities are entirely site
local. Robust implementations MUST support arbitrary data in the local. Robust implementations MUST support arbitrary data in the
content of this TLV, including binary octets. content of 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 when 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 that is used. hint(s) failing to match any subsequent identity that is used.
The Identity-Hint TLV MUST NOT be used for server unauthenticated The Identity-Hint TLV MUST NOT be used for server unauthenticated
provisioning. This TLV is only used as a hint for normal provisioning. This TLV is only used as a hint for normal
authentication. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M 0 - Optional TLV M
0 - Optional TLV
R Reserved, set to zero (0) R
Reserved, set to zero (0)
TLV Type 19 - Identity-Hint TLV Type
19 - Identity-Hint
Length >=2 octets Length
>=2 octets
4.3. TLV Rules 4.3. TLV Rules
To save round trips, multiple TLVs can be sent in a single TEAP To save round trips, multiple TLVs can be sent in a single TEAP
packet. However, multiple EAP Payload TLVs, multiple Basic Password packet. However, multiple EAP Payload TLVs, multiple Basic Password
Authentication TLVs, or an EAP Payload TLV with a Basic Password Authentication TLVs, or an EAP Payload TLV with a Basic Password
Authentication TLV within one single TEAP packet is not supported in Authentication TLV within one single TEAP packet is not supported in
this version and MUST NOT be sent. If the peer or EAP server this version and MUST NOT be sent. If the peer or EAP server
receives multiple EAP Payload TLVs, then it MUST terminate the receives multiple EAP Payload TLVs, then it MUST terminate the
connection with the Result TLV. The order in which TLVs are encoded connection with the Result TLV. The order in which TLVs are encoded
skipping to change at line 2811 skipping to change at line 2850
3. Result TLV or Request-Action TLV 3. Result TLV or Request-Action TLV
4. Identity-Type TLV 4. Identity-Type TLV
5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV 5. EAP-Payload TLV (Identity-Request) or Basic-Password-Auth-Req TLV
6. Other TLVs 6. Other TLVs
That is, cryptographic binding is checked before any result is used That is, cryptographic binding is checked before any result is used
and identities are checked before proposing an inner method, as the and identities are checked before proposing an Inner Method, as the
identity may influence the chosen inner method. identity may influence the chosen Inner Method.
The following define the meaning of the table entries in the sections The following define the meaning of the table entries in the sections
below: below:
0 This TLV MUST NOT be present in the message. 0 This TLV MUST NOT be present in the message.
0+ Zero or more instances of this TLV MAY be present in the message. 0+ Zero or more instances of this TLV MAY be present in the message.
0-1 Zero or one instance of this TLV MAY be present in the message. 0-1 Zero or one instance of this TLV MAY be present in the message.
1 Exactly one instance of this TLV MUST be present in the message. 1 Exactly one instance of this TLV MUST be present in the message.
4.3.1. Outer TLVs 4.3.1. Outer TLVs
The following table provides a guide to which TLVs may be included in The following table provides a guide to which TLVs may be included in
the TEAP packet outside the TLS channel, which kind of packets, and the TEAP packet outside the TLS channel, in which kind of packets,
in what quantity: and in what quantity:
+=========+==========+=========+=========+=================+ +=========+==========+=========+=========+=================+
| Request | Response | Success | Failure | TLVs | | Request | Response | Success | Failure | TLVs |
+=========+==========+=========+=========+=================+ +=========+==========+=========+=========+=================+
| 0-1 | 0 | 0 | 0 | Authority-ID | | 0-1 | 0 | 0 | 0 | Authority-ID |
+---------+----------+---------+---------+-----------------+ +---------+----------+---------+---------+-----------------+
| 0-1 | 0-1 | 0 | 0 | Identity-Type | | 0-1 | 0-1 | 0 | 0 | Identity-Type |
+---------+----------+---------+---------+-----------------+ +---------+----------+---------+---------+-----------------+
| 0+ | 0+ | 0 | 0 | Vendor-Specific | | 0+ | 0+ | 0 | 0 | Vendor-Specific |
+---------+----------+---------+---------+-----------------+ +---------+----------+---------+---------+-----------------+
skipping to change at line 2914 skipping to change at line 2953
this table. this table.
5. Limitations of TEAPv1 5. Limitations of TEAPv1
As noted in Section 1.1, TEAPv1 implementations are limited in As noted in Section 1.1, TEAPv1 implementations are limited in
functionality as compared to what the protocol is theoretically functionality as compared to what the protocol is theoretically
capable of. These limitations mean that only a small number of inner capable of. These limitations mean that only a small number of inner
methods are fully supported by existing TEAPv1 implementations. methods are fully supported by existing TEAPv1 implementations.
While Section 6 defines the cryptographic calculations used for key While Section 6 defines the cryptographic calculations used for key
derivation and crypto-binding, this section documents which inner derivation and crypto-binding, this section documents which Inner
methods are known to work and why those methods work. Other inner Methods are known to work and why those methods work. Other Inner
methods may work, but those results are likely to be implementation- Methods may work, but those results are likely to be implementation-
specific. specific.
We discuss the issues here without naming particular implementations We discuss the issues here without naming particular implementations
or making any negative inference about them. The implementations or making any negative inference about them. The implementations
work well enough together in limited situations. Any work well enough together in limited situations. Any
interoperability issues are due to the complexity and incompleteness interoperability issues are due to the complexity and incompleteness
of the definitions given in [RFC7170] and are not due to issues with of the definitions given in [RFC7170] and are not due to issues with
any particular implementation. any particular implementation.
The interoperability issues are limited to the use and derivation of The interoperability issues are limited to the use and derivation of
the Compound-MAC(s), which are derived from the inner MSK and EMSK. the Compound MAC(s), which are derived from the inner MSK and EMSK.
In short, implementations are known to derive different values for In short, implementations are known to derive different values for
the Compound-MAC(s) when more than one inner method provides an EMSK. the Compound MAC(s) when more than one Inner Method provides an EMSK.
5.1. Interoperable Inner Methods 5.1. Interoperable Inner Methods
The following inner methods are known to work. These methods work The following Inner Methods are known to work. These methods work
for both User and Machine credentials. for both User and Machine credentials.
* EAP-MSCHAPv2 * EAP-MSCHAPv2
* EAP-TLS * EAP-TLS
The following combinations of inner methods are known to work. These The following combinations of Inner Methods are known to work. These
methods work for any order of User and Machine credentials. methods work for any order of User and Machine credentials.
* EAP-MSCHAPv2 followed by EAP-MSCHAPv2 * EAP-MSCHAPv2 followed by EAP-MSCHAPv2
* EAP-TLS followed by EAP-MSCHAPv2 * EAP-TLS followed by EAP-MSCHAPv2
The following combinations of inner methods are known to work when The following combinations of Inner Methods are known to work when
both the supplicant and authenticator ignore the EMSK Compound-MAC both the supplicant and authenticator ignore the EMSK Compound MAC
field of the Crypto-Binding TLV. These methods work for any order of field of the Crypto-Binding TLV. These methods work for any order of
User and Machine credentials. User and Machine credentials.
* EAP-MSCHAPv2 followed by EAP-TLS * EAP-MSCHAPv2 followed by EAP-TLS
* EAP-TLS followed by EAP-TLS * EAP-TLS followed by EAP-TLS
5.2. Explanation and Background 5.2. Explanation and Background
The main reason for the limited set of inner methods is that the most The main reason for the limited set of Inner Methods is that the most
well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for well-known TEAP supplicant supports only EAP-MSCHAPv2 and EAP-TLS for
the inner methods. Further, this implementation does not encode the the Inner Methods. Further, this implementation does not encode the
EMSK Compound-MAC field in all of the Crypto-Binding TLVs that it EMSK Compound MAC field in all of the Crypto-Binding TLVs that it
sends and ignores that field in all of the Crypto-Binding TLVs that sends and ignores that field in all of the Crypto-Binding TLVs that
it receives. it receives.
The known authenticator implementations support this client, but any The known authenticator implementations support this client, but any
other combination of inner methods was not tested. The result is other combination of Inner Methods was not tested. As a result, each
that due to both the complexity of the cryptographic derivations and authenticator implemented entirely different derivations of the EMSK
the lack of interoperability testing, each authenticator implemented Compound MAC field of the Crypto-Binding TLV due to both the
entirely different derivations of the EMSK Compound-MAC field of the complexity of the cryptographic derivations and the lack of
Crypto-Binding TLV. This difference was discovered only after interoperability testing. This difference was discovered only after
multiple implementations had been shipping for years. multiple implementations had been shipping for years.
5.3. Next Steps 5.3. Next Steps
Any attempt to change TEAPv1 to address these issues would likely Any attempt to change TEAPv1 to address these issues would likely
result in one or more implementations being non-compliant with the result in one or more implementations being non-compliant with the
updated specification. Even worse, updates to this specification updated specification. Even worse, updates to this specification
would result in multiple incompatible versions of TEAPv1. would result in multiple incompatible versions of TEAPv1.
That approach is not acceptable. That approach is not acceptable.
In the interest of maintaining known interoperability, this In the interest of maintaining known interoperability, this
specification simply documents these issues rather than trying to specification simply documents these issues rather than trying to
correct the problem. Since the TEAP protocol and the Crypto-Binding correct the problem. Since the TEAP and the Crypto-Binding TLV both
TLV both contain a Version field, the better path forward is to contain a Version field, the better path forward is to publish this
publish this specification while documenting the large caveats for specification while documenting the large caveats for TEAPv1. Any
TEAPv1. Any changes to the TEAP protocol can then be done in a changes to the TEAP can then be done in a future TEAPv2
future TEAPv2 specification. specification.
6. Cryptographic Calculations 6. Cryptographic Calculations
The definitions given in this section are known to work with all The definitions given in this section are known to work with all
implementations but only for a few inner methods, as described above implementations but only for a few Inner Methods, as described above
in Section 5. In the interest of avoiding additional complexity in in Section 5. In the interest of avoiding additional complexity in
an already complex process, those definitions are given as if they an already complex process, those definitions are given as if they
work for all possible inner methods. work for all possible Inner Methods.
We note that some interoperable implementations have been written We note that some interoperable implementations have been written
based on these definitions, which support inner methods other than based on these definitions, which support Inner Methods other than
EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the EAP-MSCHAPv2 and EAP-TLS. It is therefore useful to document the
full operation of TEAPv1 despite the known issues. We only caution full operation of TEAPv1 despite the known issues. We only caution
implementors that inner methods that are not listed above in implementors that Inner Methods that are not listed above in
Section 5 are likely to work with only a subset of existing TEAPv1 Section 5 are likely to work with only a subset of existing TEAPv1
implementations. implementations.
For key derivation and crypto-binding, TEAP uses the Pseudorandom For key derivation and crypto-binding, TEAP uses the Pseudorandom
Function (PRF) and MAC algorithms negotiated in the underlying TLS Function (PRF) and MAC algorithms negotiated in the underlying TLS
session. Since these algorithms depend on the TLS version and cipher session. Since these algorithms depend on the TLS version and cipher
suite, TEAP implementations need a mechanism to determine the version suite, TEAP implementations need a mechanism to determine the version
and cipher suite in use for a particular session. The implementation and cipher suite in use for a particular session. The implementation
can then use this information to determine which PRF and MAC can then use this information to determine which PRF and MAC
algorithm to use. algorithm to use.
skipping to change at line 3029 skipping to change at line 3068
TEAPv1 makes use of the TLS Keying Material Exporters defined in TEAPv1 makes use of the TLS Keying Material Exporters defined in
[RFC5705] to derive the session_key_seed as follows: [RFC5705] to derive the session_key_seed as follows:
session_key_seed = TLS-Exporter( session_key_seed = TLS-Exporter(
"EXPORTER: teap session key seed",, 40) "EXPORTER: teap session key seed",, 40)
No context data is used in the export process. No context data is used in the export process.
The session_key_seed is used by the TEAP authentication Phase 2 The session_key_seed is used by the TEAP authentication Phase 2
conversation to both cryptographically bind the inner method(s) to conversation to both cryptographically bind the Inner Method(s) to
the tunnel as well as generate the resulting TEAP session keys. The the tunnel as well as generate the resulting TEAP session keys. The
other TLS keying materials are derived and used as defined in other TLS keying materials are derived and used as defined in
[RFC5246]. [RFC5246].
6.2. Intermediate Compound Key Derivations 6.2. Intermediate Compound Key Derivations
As TEAP can run multiple inner methods, there needs to be a way to As TEAP can run multiple Inner Methods, there needs to be a way to
cryptographically bind each inner method to the TLS tunnel and to cryptographically bind each Inner Method to the TLS tunnel and to
cryptographically bind each method to the previous one. This binding cryptographically bind each method to the previous one. This binding
is done by deriving a number of intermediate keys and exchanging that is done by deriving a number of intermediate keys and exchanging that
information in the Crypto-Binding TLV. information in the Crypto-Binding TLV.
The key derivation is complicated by a number of factors. An inner The key derivation is complicated by a number of factors. An inner
method can derive an MSK or (as with basic passwords) not derive an method can derive an MSK or (as with basic passwords) not derive an
MSK. An inner method can derive an EMSK or perhaps not derive an MSK. An Inner Method can derive an EMSK or perhaps not derive an
EMSK, or some EAP types may derive different EMSKs for the peer and EMSK, or some EAP types may derive different EMSKs for the peer and
the server. All of these cases must be accounted for and have the server. All of these cases must be accounted for and have
recommendations made for how peers and servers can interoperate. recommendations made for how peers and servers can interoperate.
There are a number of intermediate keys used to calculate the final There are a number of intermediate keys used to calculate the final
MSK and EMSK for TEAP. We give a brief overview here in order to MSK and EMSK for TEAP. We give a brief overview here in order to
clarify the detailed definitions and derivations given below. As clarify the detailed definitions and derivations given below. As
each inner method can derive an MSK (or not) and an EMSK (or not), each Inner Method can derive an MSK (or not) and an EMSK (or not),
there need to be separate intermediate key calculations for MSK and there need to be separate intermediate key calculations for MSK and
for EMSK. For the purposes of this overview, we just describe the for EMSK. For the purposes of this overview, we just describe the
derivations at a high level and state that the MSK/EMSK issue is derivations at a high level and state that the MSK/EMSK issue is
addressed in the more detailed text below. addressed in the more detailed text below.
For each inner method, we derive an IMSK. This key depends on the For each Inner Method, we derive an IMSK. This key depends on the
inner key (MSK or EMSK). This IMSK is then tied to the TLS session inner key (MSK or EMSK). This IMSK is then tied to the TLS session
via the TLS-PRF to derive an Inner Method Compound Key (IMCK). The via the TLS-PRF to derive an Inner Method Compound Key (IMCK). The
IMCK is used to generate a Compound-MAC key (CMK). The CMK is mixed IMCK is used to generate a Compound MAC key (CMK). The CMK is mixed
with various data from the TEAP negotiation to create Compound-MAC with various data from the TEAP negotiation to create Compound MAC
field of the Crypto-Binding attribute. This TLV cryptographically field of the Crypto-Binding attribute. This TLV cryptographically
binds the inner method to the protected tunnel and to the other binds the Inner Method to the protected tunnel and to the other
fields that have been negotiated. The cryptographic binding prevents fields that have been negotiated. The cryptographic binding prevents
on-path attacks. on-path attacks.
The IMCK for this inner method is then mixed with keys from previous The IMCK for this Inner Method is then mixed with keys from previous
inner methods, beginning with the TEAP Phase 2 session_key_seed Inner Methods, beginning with the TEAP Phase 2 session_key_seed
derived above, to yield a Secure IMCK (S-IMCK) for this round. The derived above, to yield a Secure IMCK (S-IMCK) for this round. The
S-IMCK from the final is then used to derive the MSK and EMSK for S-IMCK from the final is then used to derive the MSK and EMSK for
TEAP. TEAP.
We differentiate keys for inner methods by counting inner methods We differentiate keys for Inner Methods by counting Inner Methods
starting from 0 and use an index "j" to refer to an arbitrary inner starting from 0 and use an index "j" to refer to an arbitrary inner
method. For example, IMCK[0] is the IMCK for the first, or "0" inner method. For example, IMCK[0] is the IMCK for the first, or "0" Inner
method. While TEAPv1 is currently limited to one or two inner Method. While TEAPv1 is currently limited to one or two Inner
methods (j=0 or j=0,1), further updates could allow for more inner Methods (j=0 or j=0,1), further updates could allow for more Inner
method exchanges. Method exchanges.
6.2.1. Generating the Inner Method Session Key 6.2.1. Generating the Inner Method Session Key
Each inner method generates an IMSK that depends on the EMSK Each Inner Method generates an IMSK that depends on the EMSK
(preferred) or the MSK if it exists, or else it is all zeros. We (preferred) or the MSK if it exists, or else it is all zeros. We
refer to the IMSK for inner method "j" as IMSK[j]. refer to the IMSK for Inner Method "j" as IMSK[j].
If an inner method supports export of an EMSK, then the IMSK SHOULD If an Inner Method supports export of an EMSK, then the IMSK SHOULD
be derived from the EMSK, which is defined in [RFC5295]. The be derived from the EMSK, which is defined in [RFC5295]. The
optional data parameter is not used in the derivation. optional data parameter is not used in the derivation.
The above derivation is not a requirement, as some peer The above derivation is not a requirement, as some peer
implementations of TEAP are also known to not derive IMSK from EMSK implementations of TEAP are also known to not derive IMSK from EMSK
and to only derive IMSK from MSK. In order to be compatible with and to only derive IMSK from MSK. In order to be compatible with
those implementations, the use of EMSK here is not made mandatory. those implementations, the use of EMSK here is not made mandatory.
Some EAP methods may also have the peer and server derive different Some EAP methods may also have the peer and server derive different
EMSKs. Mandating an EMSK-based derivation there would prevent EMSKs. Mandating an EMSK-based derivation there would prevent
interoperability, as the Crypto-Binding TLV contents that depend on interoperability, as the Crypto-Binding TLV contents that depend on
EMSK could not then be validated by either side. Those methods EMSK could not then be validated by either side. Those methods
SHOULD NOT derive IMSK from EMSK unless the method has a way to SHOULD NOT derive IMSK from EMSK unless the method has a way to
negotiate how the EMSK is derived, along with a way to signal that negotiate how the EMSK is derived, along with a way to signal that
both the peer and server have derived the same EMSK. both the peer and server have derived the same EMSK.
It is RECOMMENDED that for those EAP methods, implementations take It is RECOMMENDED that for those EAP methods, implementations take
the simpler approach of ignoring EMSK and always derive IMSK from the simpler approach of ignoring EMSK and always derive IMSK from
MSK. This approach is less secure, as IMSK no longer MSK. This approach is less secure, as IMSK no longer
cryptographically binds the inner method to the TLS tunnel. A better cryptographically binds the Inner Method to the TLS tunnel. A better
solution is to suggest that deployments of TEAP SHOULD avoid such solution is to suggest that deployments of TEAP SHOULD avoid such
methods. methods.
The derivation of IMSK[j] from the j'th EMSK is given as follows: The derivation of IMSK[j] from the j'th EMSK is given as follows:
IMSK[j] = First 32 octets of TLS-PRF( IMSK[j] = First 32 octets of TLS-PRF(
EMSK[j], EMSK[j],
"TEAPbindkey@ietf.org", "TEAPbindkey@ietf.org",
0x00 | 0x00 | 0x40) 0x00 | 0x00 | 0x40)
Where: Where:
* "|" denotes concatenation * "|" denotes concatenation
* 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)
* The secret is the EMSK from the j'th inner method, the usage label * The secret is the EMSK from the j'th Inner Method, the usage label
used is "TEAPbindkey@ietf.org" consisting of the ASCII value for used is "TEAPbindkey@ietf.org" consisting of the ASCII value for
the label "TEAPbindkey@ietf.org" (without quotes), and the seed the label "TEAPbindkey@ietf.org" (without quotes), and the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length of 64 octets in network byte order (0x00 | 0x40) integer length of 64 octets in network byte order (0x00 | 0x40)
specified in [RFC5295]. specified in [RFC5295].
If an inner method does not support the export of EMSK but does If an Inner Method does not support the export of EMSK but does
export MSK, then the IMSK is copied from the MSK of the inner method. export MSK, then the IMSK is copied from the MSK of the Inner Method.
If the MSK is longer than 32 octets, the IMSK is copied from the If the MSK is longer than 32 octets, the IMSK is copied from the
first 32 octets and the rest of MSK is ignored. If the MSK is first 32 octets and the rest of MSK is ignored. If the MSK is
shorter than 32 octets, then the ISMK is copied from MSK and the shorter than 32 octets, then the ISMK is copied from MSK and the
remaining data in IMSK is padded with zeros to a length of 32 octets. remaining data in IMSK is padded with zeros to a length of 32 octets.
IMSK[j] is then this derived value. IMSK[j] is then this derived value.
If the inner method does not provide either MSK or EMSK, such as when If the Inner Method does not provide either MSK or EMSK, such as when
basic password authentication is used or when no inner method has basic password authentication is used or when no Inner Method has
been run, then both MSK and IMSK[j] are set to all zeroes (i.e., been run, then both MSK and IMSK[j] are set to all zeroes (i.e.,
IMSK[j] = MSK = 32 octets of 0x00s). IMSK[j] = MSK = 32 octets of 0x00s).
Note that using an MSK of all zeroes opens up TEAP to on-path attacks Note that using an MSK of all zeroes opens up TEAP to on-path attacks
as discussed in Section 8.3. It is therefore NOT RECOMMENDED to use as discussed in Section 8.3. It is therefore NOT RECOMMENDED to use
inner methods that fail to generate an MSK or EMSK. These methods Inner Methods that fail to generate an MSK or EMSK. These methods
should only be used in conjunction with another inner method that should only be used in conjunction with another Inner Method that
does provide for MSK or EMSK generation. does provide for MSK or EMSK generation.
It is also RECOMMENDED that TEAP peers order inner methods such that It is also RECOMMENDED that TEAP peers order Inner Methods such that
methods that generate EMSKs are performed before methods that do not methods that generate EMSKs are performed before methods that do not
generate EMSKs. Ordering inner methods in this manner ensures that generate EMSKs. Ordering Inner Methods in this manner ensures that
the first inner method detects any on-path attackers, and any the first Inner Method detects any on-path attackers, and any
subsequent inner method used is therefore secure. subsequent Inner Method used is therefore secure.
For example, Phase 2 could perform both machine authentication using For example, Phase 2 could perform both machine authentication using
EAP-TLS, followed by user authentication via the Basic Password EAP-TLS, followed by user authentication via the Basic Password
Authentication TLVs. In that case, the use of EAP-TLS would allow an Authentication TLVs. In that case, the use of EAP-TLS would allow an
attacker to be detected before the users' password was sent. attacker to be detected before the users' password was sent.
However, it is possible that the peer and server sides might not have However, it is possible that the peer and server sides might not have
the same capability to export EMSK. In order to maintain maximum the same capability to export EMSK. In order to maintain maximum
flexibility while prevent downgrading attack, the following mechanism flexibility while prevent downgrading attack, the following mechanism
is in place. is in place.
skipping to change at line 3186 skipping to change at line 3225
S-IMCK[0] = session_key_seed S-IMCK[0] = session_key_seed
For j = 1 to n-1 do For j = 1 to n-1 do
IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1], IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
"Inner Methods Compound Keys", "Inner Methods Compound Keys",
IMSK[j]) IMSK[j])
S-IMCK[j] = first 40 octets of IMCK[j] S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j] CMK[j] = last 20 octets of IMCK[j]
where TLS-PRF is the PRF (described above) negotiated as part of TLS where TLS-PRF is the PRF (described above) negotiated as part of TLS
handshake [RFC5246]. The value j refers to a corresponding inner handshake [RFC5246]. The value j refers to a corresponding Inner
method 1 through n. The special value of S-IMCK[0] is used to Method 1 through n. The special value of S-IMCK[0] is used to
bootstrap the calculations and can be done as soon as the TLS bootstrap the calculations and can be done as soon as the TLS
connection is established and before any inner methods are run. connection is established and before any inner methods are run.
In practice, the requirement to use either MSK or EMSK means that an In practice, the requirement to use either MSK or EMSK means that an
implement MUST track two independent derivations of IMCK[j], one that implementation MUST track two independent derivations of IMCK[j], one
depends on the MSK, and another that depends on EMSK. That is, we that depends on the MSK and another that depends on EMSK. That is,
have both values derived from MSK: we have both values derived from MSK:
* IMSK_MSK[j] * IMSK_MSK[j]
* S-IMCK_MSK[j] * S-IMCK_MSK[j]
* CMK_MSK[j] * CMK_MSK[j]
and then also values derived from EMSK: and then also values derived from EMSK:
* IMSK_EMSK[j] * IMSK_EMSK[j]
* S-IMCK_EMSK[j] * S-IMCK_EMSK[j]
* CMK_EMSK[j] * CMK_EMSK[j]
At the conclusion of a successful exchange of Crypto-Binding TLVs, a At the conclusion of a successful exchange of Crypto-Binding TLVs, a
single S-IMCK[j] is selected based on which Compound-MAC value was single S-IMCK[j] is selected based on which Compound MAC value was
included in the Crypto-Binding TLV from the client. If EMSK included in the Crypto-Binding TLV from the client. If EMSK Compound
Compound-MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise,
Otherwise, S-IMCK[j] is taken from S-IMCK_MSK[j]. S-IMCK[j] is taken from S-IMCK_MSK[j].
6.2.3. Choosing Inner Methods Securely 6.2.3. Choosing Inner Methods Securely
In order to further secure TEAP, implementations can take steps to In order to further secure TEAP, implementations can take steps to
increase their security by carefully ordering inner methods. Where increase their security by carefully ordering Inner Methods. Where
multiple inner methods are used, implementations SHOULD choose an multiple Inner Methods are used, implementations SHOULD choose an
ordering so that the first inner method used is one that derives ordering so that the first Inner Method used is one that derives
EMSK. EMSK.
For an EAP server, it can select the first inner method to be one For an EAP server, it can select the first Inner Method to be one
that derives EMSK. Since ordering of inner methods is not otherwise that derives EMSK. Since ordering of Inner Methods is not otherwise
important in EAP, any chosen order is supported by the peer that important in EAP, any chosen order is supported by the peer that
receives this request. receives this request.
For an EAP peer, it can choose its response to a server's request for For an EAP peer, it can choose its response to a server's request for
a particular type of authentication. The peer can ignore that a particular type of authentication. The peer can ignore that
request and return an inner method that derives EMSK. Again, since request and return an Inner Method that derives EMSK. Again, since
the ordering of inner methods is not otherwise important in EAP, any the ordering of Inner Methods is not otherwise important in EAP, any
chosen order is supported by the server that receives this response. chosen order is supported by the server that receives this response.
Once the more secure authentication has succeed, the server then Once the more secure authentication has succeed, the server then
requests the other type of authentication and the peer can respond requests the other type of authentication and the peer can respond
with the chosen type of authentication. with the chosen type of authentication.
Implementations can also provide configuration flags, policies, or Implementations can also provide configuration flags, policies, or
documented recommendations that control the type of inner methods documented recommendations that control the type of Inner Methods
used or verify their order. These configurations allow used or verify their order. These configurations allow
implementations and administrators to control their security exposure implementations and administrators to control their security exposure
to on-path attackers. to on-path attackers.
Implementations can permit administrators to configure TEAP so that Implementations can permit administrators to configure TEAP so that
the following security checks are enforced: the following security checks are enforced:
* Verifying that the first inner method used is one that derives * Verifying that the first Inner Method used is one that derives
EMSK. If this is not done, a fatal error can be returned. EMSK. If this is not done, a fatal error can be returned.
* Verifying that if any inner method derives EMSK, the received * Verifying that if any Inner Method derives EMSK, the received
Crypto-Binding TLV for that method contains an EMSK Compound-MAC. Crypto-Binding TLV for that method contains an EMSK Compound MAC.
If an EMSK has been derived and no EMSK Compound-MAC is seen, a If an EMSK has been derived and no EMSK Compound MAC is seen, a
fatal error can be returned. fatal error can be returned.
The goal of these suggestions is to enforce the use of the EMSK The goal of these suggestions is to enforce the use of the EMSK
Compound-MAC to protect the TEAP session from on-path attackers. If Compound MAC to protect the TEAP session from on-path attackers. If
these suggestions are not enforced, then the TEAP session is these suggestions are not enforced, then the TEAP session is
vulnerable. vulnerable.
Most of these suggestions are not normative, as some existing Most of these suggestions are not normative, as some existing
implementations are known to not follow them. Instead, these implementations are known to not follow them. Instead, these
suggestions are here to inform new implementors, along with suggestions are here to inform new implementors, along with
administrators, of the issues surrounding this subject. administrators, of the issues surrounding this subject.
6.2.4. Managing and Computing Crypto-Binding 6.2.4. Managing and Computing Crypto-Binding
After an inner method has been completed successfully and the inner After an Inner Method has been completed successfully and the inner
keys have been derived, the server sends a Crypto-Binding TLV to the keys have been derived, the server sends a Crypto-Binding TLV to the
peer. If the inner method has failed, the server does not send a peer. If the Inner Method has failed, the server does not send a
Crypto-Binding TLV. Crypto-Binding TLV.
The peer verifies the Crypto-Binding TLV by applying the rules The peer verifies the Crypto-Binding TLV by applying the rules
defined in Section 4.2.13. If verification passes, the peer responds defined in Section 4.2.13. If verification passes, the peer responds
with its own Crypto-Binding TLV, which the server in turn verifies. with its own Crypto-Binding TLV, which the server in turn verifies.
If at any point verification fails, the party that makes this If at any point verification fails, the party that makes this
determination terminates the session. determination terminates the session.
The Crypto-Binding TLV is normally sent in conjunction with other The Crypto-Binding TLV is normally sent in conjunction with other
TLVs that indicate intermediate or final results or that begin TLVs that indicate intermediate or final results or that begin
negotiation of a new inner method. This negotiation does not negotiation of a new Inner Method. This negotiation does not
otherwise affect the Crypto-Binding TLV. otherwise affect the Crypto-Binding TLV.
While Section 4.2.13 defines that the Compound-MAC fields exist in While Section 4.2.13 defines that the Compound MAC fields exist in
the Crypto-Binding TLV, it does not describe the derivation and the Crypto-Binding TLV, it does not describe the derivation and
management of those fields. This derivation is complex and is management of those fields. This derivation is complex and is
therefore located here along with the other key derivations. therefore located here along with the other key derivations.
The following text defines how the server and peer compute, send, and The following text defines how the server and peer compute, send, and
then verify the Compound-MAC fields Crypto-Binding TLV. Depending on then verify the Compound MAC fields Crypto-Binding TLV. Depending on
the inner method and site policy, the Crypto-Binding TLV can contain the Inner Method and site policy, the Crypto-Binding TLV can contain
only an MSK Compound-MAC (Flags=2), only the EMSK Compound-MAC only an MSK Compound MAC (Flags=2), only the EMSK Compound MAC
(Flags=2), or both Compound-MACs (Flags=3). Each party to the TEAP (Flags=2), or both Compound MACs (Flags=3). Each party to the TEAP
session follows its own set of procedures to compute and verify the session follows its own set of procedures to compute and verify the
Compound-MAC fields. Compound MAC fields.
The determination of the contents of the Crypto-Binding TLV is done The determination of the contents of the Crypto-Binding TLV is done
separately for each inner method. If at any point the verification separately for each Inner Method. If at any point the verification
of a Compound-MAC fails, the determining party returns a fatal error of a Compound MAC fails, the determining party returns a fatal error
as described in Section 3.9.3. as described in Section 3.9.3.
We presume that each peer and server have site policies that require We presume that each peer and server have site policies that may or
(or not) the use of the MSK Compound-MAC and/or the EMSK Compound- may not require the use of the MSK Compound MAC and/or the EMSK
MAC. These policies can be enforced globally for all inner methods, Compound MAC. These policies can be enforced globally for all Inner
or they can be enforced separately on each inner method. These Methods, or they can be enforced separately on each Inner Method.
policies could be enabled automatically when the EAP method is known These policies could be enabled automatically when the EAP method is
to always generate an EMSK and could otherwise be configurable. known to always generate an EMSK and could otherwise be configurable.
The server initiates crypto binding by determining which Compound- The server initiates crypto-binding by determining which Compound
MAC(s) to use, computing their value(s), placing the resulting MAC(s) to use, computing their value(s), placing the resulting
Compound-MAC(s) into the Crypto-Binding TLV, and then sending it to Compound MAC(s) into the Crypto-Binding TLV, and then sending it to
the peer. the peer.
Then, the steps taken by the server are as follows: Then, the steps taken by the server are as follows:
* If the inner method is known to generate only MSK, or if the * If the Inner Method is known to generate only MSK, or if the
server's policy is to not use EMSK Compound-MACs: server's policy is to not use EMSK Compound MACs:
- The server computes the MSK Compound-MAC using the MSK of the - The server computes the MSK Compound MAC using the MSK of the
inner method. The server does not use the EMSK Compound-MAC Inner Method. The server does not use the EMSK Compound MAC
field (Flags=2). field (Flags=2).
Otherwise, the EMSK is available. Otherwise, the EMSK is available.
* If the server's policy permits the use of the MSK Compound-MAC: * If the server's policy permits the use of the MSK Compound MAC:
- The sender computes the MSK Compound-MAC along with the EMSK - The sender computes the MSK Compound MAC along with the EMSK
Compound-MAC (Flags=3). Compound MAC (Flags=3).
Otherwise, the server's policy does not allow the use of the MSK Otherwise, the server's policy does not allow the use of the MSK
Compound-MAC: Compound MAC:
- The server computes only the EMSK Compound-MAC (Flags=1). - The server computes only the EMSK Compound MAC (Flags=1).
The peer verifies the Crypto-Binding TLV it receives from the server. The peer verifies the Crypto-Binding TLV it receives from the server.
It then replies with its own crypto binding response by determining It then replies with its own crypto-binding response by determining
which Compound-MAC(s) to use, computing their value(s), placing the which Compound MAC(s) to use, computing their value(s), placing the
resulting Compound-MAC(s) into the Crypto-Binding TLV, and then resulting Compound MAC(s) into the Crypto-Binding TLV, and then
sending it to the server. The result of this process is either a sending it to the server. The result of this process is either a
fatal error or one or more Compound-MACs that are placed in the fatal error or one or more Compound MACs that are placed in the
Crypto-Binding TLV and sent to the server. Crypto-Binding TLV and sent to the server.
Then, the steps taken by the peer are as follows: Then, the steps taken by the peer are as follows:
* If the peer site policy requires the use of the EMSK Compound-MAC: * If the peer site policy requires the use of the EMSK Compound MAC:
- The peer checks if the Flags field indicates the presence of - The peer checks if the Flags field indicates the presence of
the EMSK Compound MAC (Flags=1 or 3). If the Flags field has the EMSK Compound MAC (Flags=1 or 3). If the Flags field has
any other value, the peer returns a fatal error. any other value, the peer returns a fatal error.
- The peer checks if the inner method has derived an EMSK. If - The peer checks if the Inner Method has derived an EMSK. If
not, the peer returns a fatal error. not, the peer returns a fatal error.
Otherwise, the peer site policy does not require the use of the Otherwise, the peer site policy does not require the use of the
EMSK Compound-MAC and the EMSK may or may not exist. EMSK Compound MAC and the EMSK may or may not exist.
* If the inner method is known to generate only MSK and not EMSK: * If the Inner Method is known to generate only MSK and not EMSK:
- The peer checks if the Flags field indicates that only the MSK - The peer checks if the Flags field indicates that only the MSK
Compound-MAC exists (Flags=2). If the Flags field has any Compound MAC exists (Flags=2). If the Flags field has any
other value, the peer returns a fatal error. other value, the peer returns a fatal error.
Otherwise, the MSK exists, the EMSK may or may not exist, and the Otherwise, the MSK exists, the EMSK may or may not exist, and the
peer allows the use of the EMSK Compound-MAC. The peer may have peer allows the use of the EMSK Compound MAC. The peer may have
received one or two Compound-MACs (Flags=1,2,3). Any Compound-MAC received one or two Compound MACs (Flags=1,2,3). Any Compound MAC
that is present is verified. No futher action is taken by the that is present is verified. No futher action is taken by the
peer if a particular Compound-MAC is not present. No further peer if a particular Compound MAC is not present. No further
action is taken by the peer if an unexpected Compound-MAC is action is taken by the peer if an unexpected Compound MAC is
present. present.
Note that due to earlier validation of the Flags field Note that due to earlier validation of the Flags field
(Section 4.2.13), at least one Compound-MAC must now exist (Section 4.2.13), at least one Compound MAC must now exist
(Flags=1,2,3). (Flags=1,2,3).
* If the peer has received an MSK Compound-MAC, it verifies it and * If the peer has received an MSK Compound MAC, it verifies it and
returns a fatal error if verification fails. returns a fatal error if verification fails.
* If EMSK is available and the peer has received an EMSK Compound- * If EMSK is available and the peer has received an EMSK Compound
MAC, it verifies it and returns a fatal error if verification MAC, it verifies it and returns a fatal error if verification
fails. fails.
The peer creates a crypto binding response by determining which The peer creates a crypto-binding response by determining which
Compound-MAC(s) to use, computing their value(s), placing the Compound MAC(s) to use, computing their value(s), placing the
resulting Compound-MAC(s) into the Crypto-Binding TLV, and then resulting Compound MAC(s) into the Crypto-Binding TLV, and then
sending it to the server. sending it to the server.
The steps taken by the peer are then as follows. The steps taken by the peer are then as follows.
* If the peer received an MSK Compound-MAC from the server: * If the peer received an MSK Compound MAC from the server:
- Since the MSK always exists, this step is always possible. The - Since the MSK always exists, this step is always possible. The
peer computes the MSK Compound-MAC for the response (Flags=2). peer computes the MSK Compound MAC for the response (Flags=2).
* If the peer site policy requires the use of the EMSK Compound-MAC: * If the peer site policy requires the use of the EMSK Compound MAC:
- The preceding steps taken by the peer ensures that the EMSK - The preceding steps taken by the peer ensures that the EMSK
exists and the server had sent an EMSK Compound-MAC. The peer exists and the server had sent an EMSK Compound MAC. The peer
computes the EMSK Compound-MAC for the response. The Flags computes the EMSK Compound MAC for the response. The Flags
field is updated (Flags=1,3). field is updated (Flags=1,3).
Otherwise, if the EMSK exists: Otherwise, if the EMSK exists:
- The peer computes the EMSK Compound-MAC for the response. The - The peer computes the EMSK Compound MAC for the response. The
Flags field is updated (Flags=1,3). Flags field is updated (Flags=1,3).
The server processes the response from the peer via the following The server processes the response from the peer via the following
steps: steps:
* If the server site policy requires the use of the EMSK Compound- * If the server site policy requires the use of the EMSK Compound
MAC: MAC:
- The server checks if the Flags field indicates the presence of - The server checks if the Flags field indicates the presence of
the EMSK Compound MAC (Flags=1 or 3). If the Flags field has the EMSK Compound MAC (Flags=1 or 3). If the Flags field has
any other value, the server returns a fatal error. any other value, the server returns a fatal error.
- The server checks if the inner method has derived an EMSK. If - The server checks if the Inner Method has derived an EMSK. If
not, the server returns a fatal error. not, the server returns a fatal error.
* If the inner method is known to generate only MSK and not EMSK: * If the Inner Method is known to generate only MSK and not EMSK:
- The server checks if the Flags field indicates that only the - The server checks if the Flags field indicates that only the
MSK Compound-MAC exists (Flags=2). If the Flags field has any MSK Compound MAC exists (Flags=2). If the Flags field has any
other value, the server returns a fatal error. other value, the server returns a fatal error.
Otherwise, the MSK exists and the EMSK may or may not exist. The Otherwise, the MSK exists and the EMSK may or may not exist. The
server may have received one or two Compound-MACs (Flags=1,2,3). server may have received one or two Compound MACs (Flags=1,2,3).
Any Compound-MAC that is present is verified. No further action Any Compound MAC that is present is verified. No further action
is taken by the server if a particular Compound-MAC is not is taken by the server if a particular Compound MAC is not
present. No further action is taken by the server if an present. No further action is taken by the server if an
unexpected Compound-MAC is present. unexpected Compound MAC is present.
* If the server has received an MSK Compound-MAC, it verifies it and * If the server has received an MSK Compound MAC, it verifies it and
returns a fatal error if verification fails. returns a fatal error if verification fails.
* If EMSK is available and the server has received an EMSK Compound- * If EMSK is available and the server has received an EMSK Compound
MAC, it verifies it and returns a fatal error if verification MAC, it verifies it and returns a fatal error if verification
fails. fails.
Once the above steps have concluded, the server either continues Once the above steps have concluded, the server either continues
authentication with another inner method or it returns a Result TLV. authentication with another Inner Method or it returns a Result TLV.
6.2.5. Unintended Side Effects 6.2.5. Unintended Side Effects
In earlier drafts of this document, the descriptions of the key In earlier drafts of this document, the descriptions of the key
derivations had issues that were only discovered after TEAP had been derivations had issues that were only discovered after TEAP had been
widely implemented. These issues need to be documented in order to widely implemented. These issues need to be documented in order to
enable interoperable implementations. enable interoperable implementations.
As noted above, some inner EAP methods derive MSK but do not derive As noted above, some inner EAP methods derive MSK but do not derive
EMSK. When there is no EMSK, it is therefore not possible to derive EMSK. When there is no EMSK, it is therefore not possible to derive
skipping to change at line 3489 skipping to change at line 3528
EMSK. This result likely has negative effects on security, though EMSK. This result likely has negative effects on security, though
the full impact is unknown at the time of writing this document. the full impact is unknown at the time of writing this document.
These design flaws have nonetheless resulted in multiple These design flaws have nonetheless resulted in multiple
interoperable implementations. We note that these implementations interoperable implementations. We note that these implementations
seem to support only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of seem to support only EAP-TLS and the EAP-FAST-MSCHAPv2 variant of
EAP-MSCHAPv2. Other inner EAP methods may work by accident but are EAP-MSCHAPv2. Other inner EAP methods may work by accident but are
not likely to work by design. For this document, we can only ensure not likely to work by design. For this document, we can only ensure
that the behavior of TEAPv1 is fully documented, even if that that the behavior of TEAPv1 is fully documented, even if that
behavior was an unintended consequence of unclear text in earlier behavior was an unintended consequence of unclear text in earlier
versions of this document. versions of this specification.
We expect that these issues will be addressed in a future revision of We expect that these issues will be addressed in a future revision of
TEAP. TEAP.
6.3. Computing the Compound-MAC 6.3. Computing the Compound MAC
For inner methods that generate keying material, further protection For Inner Methods that generate keying material, further protection
against on-path attacks is provided through cryptographically binding against on-path attacks is provided through cryptographically binding
keying material established by both TEAP Phase 1 and TEAP Phase 2 keying material established by both TEAP Phase 1 and TEAP Phase 2
conversations. After each successful inner EAP authentication, EAP conversations. After each successful inner EAP authentication, EAP
EMSK and/or MSKs are cryptographically combined with key material EMSK and/or MSKs are cryptographically combined with key material
from TEAP Phase 1 to generate a Compound Session Key (CMK). The CMK from TEAP Phase 1 to generate a CMK. The CMK is used to calculate
is used to calculate the Compound-MAC as part of the Crypto-Binding the Compound MAC as part of the Crypto-Binding TLV described in
TLV described in Section 4.2.13, which helps provide assurance that Section 4.2.13, which helps provide assurance that the same entities
the same entities are involved in all communications in TEAP. During are involved in all communications in TEAP. During the calculation
the calculation of the Compound-MAC, the MAC field is filled with of the Compound MAC, the MAC field is filled with zeros.
zeros.
The Compound-MAC computation is as follows: The Compound MAC computation is as follows:
Compound-MAC = the first 20 octets of MAC( CMK[n], BUFFER ) Compound MAC = the first 20 octets of MAC( CMK[n], BUFFER )
where n is the number of the last successfully executed inner method, where n is the number of the last successfully executed inner method,
MAC is the MAC function negotiated in TLS (e.g., TLS 1.2 in MAC is the MAC function negotiated in TLS (e.g., TLS 1.2 in
[RFC5246]), and BUFFER is created after concatenating these fields in [RFC5246]), and BUFFER is created after concatenating these fields in
the following order: the following order:
1. The entire Crypto-Binding TLV attribute with both the EMSK and 1. The entire Crypto-Binding TLV attribute with both the EMSK and
MSK Compound-MAC fields zeroed out. MSK Compound MAC fields zeroed out.
2. The EAP Type sent by the other party in the first TEAP message, 2. The EAP Type sent by the other party in the first TEAP message,
which MUST be TEAP, encoded as one octet of 0x37. which MUST be TEAP, encoded as one octet of 0x37.
3. All the Outer TLVs from the first TEAP message sent by the EAP 3. All the Outer TLVs from the first TEAP message sent by the EAP
server to the peer. If a single TEAP message is fragmented into server to the peer. 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.
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.
If no inner method is run, then no MSK or EMSK will be generated. If If no Inner Method is run, then no MSK or EMSK will be generated. If
an IMSK needs to be generated, then the MSK and therefore the IMSK is 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). 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) Note that there is no boundary marker between the fields in steps (3)
and (4). However, the server calculates the compound MAC using the 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 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 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 TLVs it sent and the Outer TLVs it received from the server. As a
result, any modification in transit of the outer TLVs will be result, any modification in transit of the Outer TLVs will be
detected because the two sides will calculate different values for detected because the two sides will calculate different values for
the compound MAC. the compound MAC.
If no key-generating inner method is run, then no MSK or EMSK will be If no key-generating Inner Method is run, then no MSK or EMSK will be
generated. If an IMSK needs to be generated, then the MSK and 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 therefore the IMSK is set to all zeroes (i.e., IMSK = MSK = 32 octets
of 0x00s) of 0x00s)
6.4. EAP Master Session Key Generation 6.4. EAP Master Session Key Generation
TEAP authentication assures the MSK and EMSK output from running TEAP TEAP authentication assures the MSK and EMSK output from running TEAP
are the combined result of all inner methods by generating an IMCK. are the combined result of all Inner Methods by generating an IMCK.
The IMCK is mutually derived by the peer and the server as described The IMCK is mutually derived by the peer and the server as described
in Section 6.2 by combining the MSKs from inner methods with key in Section 6.2 by combining the MSKs from Inner Methods with key
material from TEAP Phase 1. The resulting MSK and EMSK are generated 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] key from the final ("n"th) Inner Method, as part of the IMCK[n] key
hierarchy via the following derivation: hierarchy via the following derivation:
MSK = the first 64 octets of TLS-PRF(S-IMCK[n], MSK = the first 64 octets of TLS-PRF(S-IMCK[n],
"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 secret is S-IMCK[n], where n is the number of the last generated The secret is S-IMCK[n], where n is the number of the last generated
S-IMCK[j] from Section 6.2. The label is the ASCII value for the S-IMCK[j] from Section 6.2. The label is the ASCII value for the
string without quotes. The seed is empty (0 length) and is omitted string without quotes. The seed is empty (0 length) and is omitted
from the derivation. 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 MSK or EMSK, the MSK and EMSK will If no Inner Method has created an MSK or EMSK, 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.
As we noted above, not all inner methods generate both MSK and EMSK, As we noted above, not all Inner Methods generate both MSK and EMSK,
so we have to maintain two independent derivations of S-IMCK[j], one so we have to maintain two independent derivations of S-IMCK[j], one
for each of MSK[j] and EMSK[j]. The final derivation using S-IMCK[n] for each of MSK[j] and EMSK[j]. The final derivation using S-IMCK[n]
must choose only one of these keys. must choose only one of these keys.
If the Crypto-Binding TLV contains an EMSK compound MAC, then the If the Crypto-Binding TLV contains an EMSK compound MAC, then the
derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken derivation is taken from the S-IMCK_EMSK[n]. Otherwise, it is taken
from the S-IMCK_MSK[n]. from the S-IMCK_MSK[n].
7. IANA Considerations 7. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TEAP Authority (IANA) regarding registration of values related to the TEAP
protocol in accordance with BCP 26 [RFC8126]. protocol in accordance with [BCP26].
Except as noted below, IANA has updated the "Tunnel Extensible Except as noted below, IANA has updated the "Tunnel Extensible
Authentication Protocol (TEAP) Parameters" registry to change the Authentication Protocol (TEAP) Parameters" registry to change the
Reference field in all tables from [RFC7170] to RFC 9930. Reference field in all tables from [RFC7170] to RFC 9930.
7.1. TEAP TLV Types 7.1. TEAP TLV Types
IANA has updated the references in the "TEAP TLV Types" registry from IANA has updated the references in the "TEAP TLV Types" registry from
[RFC7170] to RFC 9930 and added TLV 18 and TLV 19 to the registry. [RFC7170] to RFC 9930 and added TLV 18 and TLV 19 to the registry.
The Unassigned values then begin at 20 instead of at 18. The Unassigned values then begin at 20 instead of at 18.
skipping to change at line 3632 skipping to change at line 3670
| This registry has been closed. See RFC 9930. | This registry has been closed. See RFC 9930.
7.2. TEAP Error TLV (value 5) Error Codes 7.2. TEAP Error TLV (value 5) Error Codes
IANA has updated the "TEAP Error TLV (value 5) Error Codes" registry IANA has updated the "TEAP Error TLV (value 5) Error Codes" registry
to add the following entries: to add the following entries:
+=======+=========================================+===========+ +=======+=========================================+===========+
| Value | Description | Reference | | Value | Description | Reference |
+=======+=========================================+===========+ +=======+=========================================+===========+
| 1032 | Inner method not supported | RFC 9930 | | 1032 | Inner Method not supported | RFC 9930 |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2003 | The Crypto-Binding TLV is invalid | RFC 9930 | | 2003 | The Crypto-Binding TLV is invalid | RFC 9930 |
| | (Version, or Received-Ver, or Sub-Type) | | | | (Version, or Received-Ver, or Sub-Type) | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2004 | The first inner method did not derive | RFC 9930 | | 2004 | The first Inner Method did not derive | RFC 9930 |
| | EMSK | | | | EMSK | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2005 | The Crypto-Binding TLV did not include | RFC 9930 | | 2005 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required MSK Compound-MAC | | | | a required MSK Compound MAC | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2006 | The MSK Compound-MAC fails verification | RFC 9930 | | 2006 | The MSK Compound MAC fails verification | RFC 9930 |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2007 | The Crypto-Binding TLV did not include | RFC 9930 | | 2007 | The Crypto-Binding TLV did not include | RFC 9930 |
| | a required EMSK Compound-MAC | | | | a required EMSK Compound MAC | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2008 | The EMSK Compound-MAC fails | RFC 9930 | | 2008 | The EMSK Compound MAC fails | RFC 9930 |
| | verification | | | | verification | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
| 2009 | The EMSK Compound-MAC exists, but the | RFC 9930 | | 2009 | The EMSK Compound MAC exists, but the | RFC 9930 |
| | inner method did not derive EMSK | | | | Inner Method did not derive EMSK | |
+-------+-----------------------------------------+-----------+ +-------+-----------------------------------------+-----------+
Table 4 Table 4
7.3. TLS Exporter Labels 7.3. TLS Exporter Labels
IANA has updated the "TLS Exporter Labels" registry to change the IANA has updated the "TLS Exporter Labels" registry to change the
Reference field for Value "EXPORTER: teap session key seed" as Reference field for Value "EXPORTER: teap session key seed" as
follows: follows:
skipping to change at line 3717 skipping to change at line 3755
greater. The threat model used for the security evaluation of TEAP greater. The threat model used for the security evaluation of TEAP
is defined in EAP [RFC3748]. is defined in EAP [RFC3748].
8.1. Mutual Authentication and Integrity Protection 8.1. Mutual Authentication and Integrity Protection
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 Where server unauthenticated provisioning is performed, TEAP requires
that the inner provisioning method provide for both peer and server that the inner provisioning method provide for both peer and server
authentication. authentication.
8.2. Method Negotiation 8.2. Method Negotiation
As is true for any negotiated EAP protocol, EAP NAK messages used to As is true for any negotiated EAP, EAP NAK messages used to suggest
suggest an alternate EAP authentication method are sent unprotected an alternate EAP authentication method are sent unprotected and, as
and, as such, are subject to spoofing. During unprotected EAP method 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
negotiation resists attacks because it is protected by the mutually negotiation resists attacks because it is protected by the mutually
authenticated TLS tunnel established. Selection of TEAP as an authenticated TLS tunnel established. Selection of TEAP as an
authentication method does not limit the potential inner methods, so authentication method does not limit the potential inner methods, so
TEAP should be selected when available. TEAP should be selected when available.
An attacker cannot readily determine the inner method used, except An attacker cannot readily determine the Inner Method used, except
perhaps by traffic analysis. It is also important that peer perhaps by traffic analysis. It is also important that peer
implementations limit the use of credentials with an unauthenticated implementations limit the use of credentials with an unauthenticated
or unauthorized server. or unauthorized server.
8.3. Separation of Phase 1 and Phase 2 Servers 8.3. Separation of Phase 1 and Phase 2 Servers
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT
RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a
different server than the Phase 2 conversation can introduce different server than the Phase 2 conversation can introduce
vulnerabilities if there is not a proper trust relationship and vulnerabilities if there is not a proper trust relationship and
skipping to change at line 3772 skipping to change at line 3810
There may be cases where a trust relationship exists between the There may be cases where a trust relationship exists between the
Phase 1 and Phase 2 servers, such as on a campus or between two Phase 1 and Phase 2 servers, such as on a campus or between two
offices within the same company, where there is no danger in offices within the same company, where there is no danger in
revealing the inner identity and credentials of the peer to entities revealing the inner identity and credentials of the peer to entities
between the two servers. In these cases, using a proxy solution between the two servers. In these cases, using a proxy solution
without end-to-end protection of TEAP MAY be used. The TEAP without end-to-end protection of TEAP MAY be used. The TEAP
encrypting/decrypting gateway MUST, at a minimum, provide support for encrypting/decrypting gateway MUST, at a minimum, provide support for
IPsec, TLS, or similar protection in order to provide confidentiality IPsec, TLS, or similar protection in order to provide confidentiality
for the portion of the conversation between the gateway and the EAP for the portion of the conversation between the gateway and the EAP
server. In addition, separation of the TEAP servers and Inner server. In addition, separation of the TEAP servers and Inner
servers allows for crypto-binding based on the inner method MSK to be servers allows for crypto-binding based on the Inner Method MSK to be
thwarted as described in [RFC7029]. If the inner method derives an thwarted as described in [RFC7029]. If the Inner Method derives an
EMSK, then this threat is mitigated as TEAP uses the Crypto-Binding EMSK, then this threat is mitigated as TEAP uses the Crypto-Binding
TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as TLV to tie the inner EMSK to the TLS session via the TLS-PRF, as
described above in Section 6. described above in Section 6.
On the other hand, if the inner method is not deriving EMSK, as with On the other hand, if the Inner Method is not deriving EMSK, as with
password authentication or unauthenticated provisioning, then this password authentication or unauthenticated provisioning, then this
threat still exists. Implementations therefore need to limit the use threat still exists. Implementations therefore need to limit the use
of inner methods as discussed above in Section 3.6.5 of Inner Methods as discussed above in Section 3.6.5
8.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies 8.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies
TEAP addresses the known deficiencies and weaknesses in some EAP TEAP addresses the known deficiencies and weaknesses in some EAP
authentication methods. By employing a shared secret between the authentication methods. By employing a shared secret between the
peer and server to establish a secured tunnel, TEAP enables: peer and server to establish a secured tunnel, TEAP enables:
* Per-packet confidentiality and integrity protection * Per-packet confidentiality and integrity protection
* User identity protection * User identity protection
* Better support for notification messages * Better support for notification messages
* Protected inner method negotiation, including EAP method * Protected Inner Method negotiation, including EAP methods
* Sequencing of inner methods, including EAP methods * Sequencing of Inner Methods, including EAP methods
* Strong mutually derived MSKs * Strong mutually derived MSKs
* Acknowledged success/failure indication * Acknowledged success/failure indication
* Faster re-authentications through session resumption * Faster re-authentications through session resumption
* Mitigation of offline dictionary attacks * Mitigation of offline dictionary attacks
* Mitigation of on-path attacks * Mitigation of on-path attacks
* Mitigation of some denial-of-service attacks * Mitigation of some denial-of-service attacks
It should be noted that in TEAP, as in many other authentication It should be noted that in TEAP, as in many other authentication
protocols, a denial-of-service attack can be mounted by adversaries protocols, a denial-of-service attack can be mounted by adversaries
sending erroneous traffic to disrupt the protocol. This is a problem sending erroneous traffic to disrupt the protocol. This is a problem
in many authentication or key agreement protocols and is therefore in many authentication or key agreement protocols and is therefore
noted for TEAP as well. noted for TEAP as well.
TEAP was designed with a focus on protected inner methods that TEAP was designed with a focus on protected Inner Methods that
typically rely on weak credentials, such as password-based secrets. typically rely on weak credentials, such as password-based secrets.
To that extent, the TEAP authentication mitigates several To that extent, the TEAP authentication mitigates several
vulnerabilities, such as offline dictionary attacks, by protecting vulnerabilities, such as offline dictionary attacks, by protecting
the weak credential-based inner method. The protection is based on the weak credential-based Inner Method. The protection is based on
strong cryptographic algorithms in TLS to provide message strong cryptographic algorithms in TLS to provide message
confidentiality and integrity. The keys derived for the protection confidentiality and integrity. The keys derived for the protection
relies on strong random challenges provided by both peer and server relies on strong random challenges provided by both peer and server
as well as an established key with strong entropy. Implementations as well as an established key with strong entropy. Implementations
should follow the recommendation in [RFC4086] when generating random should follow the recommendation in [RFC4086] when generating random
numbers. numbers.
8.4.1. User Identity Protection and Verification 8.4.1. User Identity Protection and Verification
The initial identity request response exchange is sent in cleartext The initial identity request response exchange is sent in cleartext
skipping to change at line 3854 skipping to change at line 3892
Identities authenticated in Phase 2. Identities authenticated in Phase 2.
When the server is authenticated, identity request/response exchanges When the server is authenticated, identity request/response exchanges
sent after the TEAP tunnel is established are protected from sent after the TEAP tunnel is established are protected from
modification and eavesdropping by attackers. For server modification and eavesdropping by attackers. For server
unauthenticated provisioning, the outer TLS session provides little unauthenticated provisioning, the outer TLS session provides little
security, and the provisioning method must provide this protection security, and the provisioning method must provide this protection
instead. 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
Note that the Phase 2 data could simply be a Result TLV with value Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV. This Phase 2 data serves Success, along with a Crypto-Binding TLV. This Phase 2 data serves
as a protected success indication as discussed in [RFC9190], as a protected success indication as discussed in [RFC9190],
Section 2.1.1 Section 2.1.1
8.5. Dictionary Attack Resistance 8.5. Dictionary Attack Resistance
TEAP was designed with a focus on protected inner methods that TEAP was designed with a focus on protected Inner Methods that
typically rely on weak credentials, such as password-based secrets. typically rely on weak credentials, such as password-based secrets.
TEAP mitigates offline dictionary attacks by allowing the TEAP mitigates offline dictionary attacks by allowing the
establishment of a mutually authenticated encrypted TLS tunnel establishment of a mutually authenticated encrypted TLS tunnel
providing confidentiality and integrity to protect the weak providing confidentiality and integrity to protect the weak
credential-based inner method. credential-based Inner Method.
TEAP mitigates dictionary attacks by permitting inner methods, such TEAP mitigates dictionary attacks by permitting Inner Methods, such
as EAP-pwd, that are not vulnerable to dictionary attacks. as EAP-pwd, that are not vulnerable to dictionary attacks.
TEAP implementations can mitigate online "brute force" dictionary TEAP implementations can mitigate online "brute force" dictionary
attempts by limiting the number of failed authentication attempts for attempts by limiting the number of failed authentication attempts for
a particular identity. a particular identity.
8.5.1. Protection Against On-Path Attacks 8.5.1. Protection Against On-Path Attacks
TEAP provides protection from on-path attacks in a few ways: TEAP provides protection from on-path attacks in a few ways:
1. By using a certificates or a session ticket to mutually 1. By using a certificates or a session ticket to mutually
authenticate the peer and server during TEAP authentication Phase authenticate the peer and server during TEAP authentication Phase
1 establishment of a secure TLS tunnel. 1 establishment of a secure TLS tunnel.
2. When the TLS tunnel is not secured, by using the keys generated 2. When the TLS tunnel is not secured, by using the keys generated
by the inner method (if the inner methods are key generating) in by the Inner Method (if the Inner Methods are key generating) in
the crypto-binding exchange and in the generation of the key the crypto-binding exchange and in the generation of the key
material exported by the inner method described in Section 6. material exported by the Inner Method described in Section 6.
TEAP crypto binding does not guarantee protection from on-path TEAP crypto-binding does not guarantee protection from on-path
attacks if the client allows a connection to an untrusted server, attacks if the client allows a connection to an untrusted server,
such as in the case where the client does not properly validate the such as in the case where the client does not properly validate the
server's certificate. If the TLS cipher suite derives the master server's certificate. If the TLS cipher suite derives the master
secret solely from the contribution of secret data from one side of secret solely from the contribution of secret data from one side of
the conversation (such as cipher suites based on RSA key transport), the conversation (such as cipher suites based on RSA key transport),
then an attacker who can convince the client to connect and engage in then an attacker who can convince the client to connect and engage in
authentication can impersonate the client to another server even if a authentication can impersonate the client to another server even if a
strong inner method is executed within the tunnel. If the TLS cipher strong Inner Method is executed within the tunnel. If the TLS cipher
suite derives the master secret from the contribution of secrets from suite derives the master secret from the contribution of secrets from
both sides of the conversation (such as in cipher suites based on both sides of the conversation (such as in cipher suites based on
Diffie-Hellman), then crypto binding can detect an attacker in the Diffie-Hellman), then crypto-binding can detect an attacker in the
conversation if a strong inner method is used. conversation if a strong Inner Method is used.
TEAP crypto binding does not guarantee protection from on-path TEAP crypto-binding does not guarantee protection from on-path
attacks when the client does not verify the server, and the inner attacks when the client does not verify the server, and the Inner
method does not produce an EMSK. The only way to close this Method does not produce an EMSK. The only way to close this
vulnerability is to define TEAPv2, which would then have different vulnerability is to define TEAPv2, which would then have different
crypto binding derivations. crypto-binding derivations.
8.6. Protecting Against Forged Cleartext EAP Packets 8.6. Protecting Against Forged Cleartext EAP Packets
EAP Success and EAP Failure packets are, in general, sent in EAP Success and EAP Failure packets are, in general, sent in
cleartext and may be forged by an attacker without detection. Forged cleartext and may be forged by an attacker without detection. Forged
EAP Failure packets can be used to attempt to convince an EAP peer to EAP Failure packets can be used to attempt to convince an EAP peer to
disconnect. Forged EAP Success packets may be used to attempt to disconnect. Forged EAP Success packets may be used to attempt to
convince a peer that authentication has succeeded, even though the convince a peer that authentication has succeeded, even though the
authenticator has not authenticated itself to the peer. authenticator has not authenticated itself to the peer.
skipping to change at line 3982 skipping to change at line 4020
The issues discussed in Section 6.2.5 could have security impacts, The issues discussed in Section 6.2.5 could have security impacts,
but no analysis has been performed. The choice of using a special but no analysis has been performed. The choice of using a special
"all zero" IMSK in Section 6.2 was made for simplicity but could also "all zero" IMSK in Section 6.2 was made for simplicity but could also
have negative security impacts. have negative security impacts.
The definition of the Crypto-Binding TLV means that the final Crypto- The definition of the Crypto-Binding TLV means that the final Crypto-
Binding TLV values might not depend on all previous values of MSK and Binding TLV values might not depend on all previous values of MSK and
EMSK. This limitation could have negative security impacts, but EMSK. This limitation could have negative security impacts, but
again, no analysis has been performed. again, no analysis has been performed.
We suggest that the TEAP protocol be revised to TEAP version 2, which We suggest that the TEAP be revised to TEAP version 2, which could
could address these issues. There are proposals at this time to address these issues. There are proposals at this time to better
better derive the various keying materials and cryptographic binding derive the various keying materials and cryptographic binding
derivations. However, in the interest of documenting running code, derivations. However, in the interest of documenting running code,
we are publishing this document with the acknowledgment that there we are publishing this document with the acknowledgment that there
are improvements to be made. are improvements to be made.
8.9. Implicit Challenge 8.9. Implicit Challenge
Certain authentication protocols that use a challenge/response Certain authentication protocols that use a challenge/response
mechanism rely on challenge material that is not generated by the mechanism rely on challenge material that is not generated by the
authentication server; therefore, the material may require special authentication server; therefore, the material may require special
handling. For EAP-TTLS, these challenges are defined in [RFC5281], handling. For EAP-TTLS, these challenges are defined in [RFC5281],
skipping to change at line 4050 skipping to change at line 4088
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. [BCP86] offers advice on appropriate key sizes. The
The National Institute for Standards and Technology (NIST) also National Institute for Standards and Technology (NIST) also offers
offers advice on appropriate key sizes in [NIST-SP-800-57]. advice on appropriate key sizes in [NIST-SP-800-57]. [RFC3766],
[RFC3766], Section 6 advises use of the following required RSA or Section 6 advises use of the following required RSA or Diffie-
Diffie-Hellman (DH) module and Digital Signature Algorithm (DSA) Hellman (DH) module and Digital Signature Algorithm (DSA) subgroup
subgroup size in bits for a given level of attack resistance in size in bits for a given level of attack resistance in bits.
bits. Based on the table below, a 2048-bit RSA key is required to Based on the table below, a 2048-bit RSA key is required to
provide 112-bit equivalent key strength: provide 112-bit equivalent key strength:
+==========================+===================+==============+ +==========================+===================+==============+
| Attack Resistance (bits) | RSA or DH Modulus | DSA subgroup | | Attack Resistance (bits) | RSA or DH Modulus | DSA subgroup |
| | size (bits) | size (bits) | | | size (bits) | size (bits) |
+==========================+===================+==============+ +==========================+===================+==============+
| 70 | 947 | 129 | | 70 | 947 | 129 |
+--------------------------+-------------------+--------------+ +--------------------------+-------------------+--------------+
| 80 | 1228 | 148 | | 80 | 1228 | 148 |
+--------------------------+-------------------+--------------+ +--------------------------+-------------------+--------------+
skipping to change at line 4081 skipping to change at line 4119
| 150 | 4575 | 284 | | 150 | 4575 | 284 |
+--------------------------+-------------------+--------------+ +--------------------------+-------------------+--------------+
| 200 | 8719 | 383 | | 200 | 8719 | 383 |
+--------------------------+-------------------+--------------+ +--------------------------+-------------------+--------------+
| 250 | 14596 | 482 | | 250 | 14596 | 482 |
+--------------------------+-------------------+--------------+ +--------------------------+-------------------+--------------+
Table 8 Table 8
* Note 2. TEAP protects against offline dictionary attacks when * Note 2. TEAP protects against offline dictionary attacks when
secure inner methods are used. TEAP protects against online secure Inner Methods are used. TEAP protects against online
dictionary attacks by limiting the number of failed dictionary attacks by limiting the number of failed
authentications for a particular identity. authentications for a particular identity.
9. Changes from RFC 7170 9. References
Alan DeKok was added as an editor.
The document was converted to Markdown from the [RFC7170] text
output.
Any formatting changes mostly result from differences between using
Markdown versus XML for source.
The IANA Considerations section was replaced with a note to change
the IANA registry references to this document.
A new section was added to explain that the inner EAP-MSCHAPv2
derivation follows EAP-FAST. This is the largest technical change
from the previous revision of this document and follows existing
implementations.
Many small changes have been made throughout the document to correct
inconsistencies and to address mistakes. At a high level:
* All open errata have been addressed.
* A new term "inner method" has been defined.
* The definitions and derivation of IMSK, S-IMCK, etc. have been
corrected and clarified.
* The diagrams in Appendix C have been updated to match the TEAP
state machine.
All uses of the PAC were removed. It had not been implemented, and
there were no plans by implementors to use it.
Text was added on recommendations for inner and outer identities.
Section 6.2.5 was added late in the document life cycle in order to
document accidental behavior that could result in interoperability
issues.
10. References
10.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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/info/rfc2985>. <https://www.rfc-editor.org/info/rfc2985>.
skipping to change at line 4224 skipping to change at line 4222
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS", [RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023, RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>. <https://www.rfc-editor.org/info/rfc9525>.
[RFC9908] Richardson, M., Ed., Friel, O., von Oheimb, D., and D. [RFC9908] Richardson, M., Ed., Friel, O., von Oheimb, D., and D.
Harkins, "Clarification and Enhancement of the CSR Harkins, "Clarification and Enhancement of the CSR
Attributes Definition in RFC 7030", RFC 9908, Attributes Definition in RFC 7030", RFC 9908,
DOI 10.17487/RFC9908, January 2026, DOI 10.17487/RFC9908, January 2026,
<https://www.rfc-editor.org/info/rfc9908>. <https://www.rfc-editor.org/info/rfc9908>.
10.2. Informative References 9.2. Informative References
[BCP26] Best Current Practice 26,
<https://www.rfc-editor.org/info/bcp26>.
At the time of writing, this BCP comprises the following:
Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[BCP86] Best Current Practice 86,
<https://www.rfc-editor.org/info/bcp86>.
At the time of writing, this BCP comprises the following:
Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>.
[IEEE.802-1X.2020] [IEEE.802-1X.2020]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks--Port-Based Network Access Control", IEEE Std Networks--Port-Based Network Access Control", IEEE Std
802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>. 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP [KAMATH] Kamath, V. and A. Palekar, "Microsoft EAP CHAP
Extensions", Work in Progress, Internet-Draft, draft- Extensions", Work in Progress, Internet-Draft, draft-
kamath-pppext-eap-mschapv2-02, 19 June 2007, kamath-pppext-eap-mschapv2-02, 19 June 2007,
skipping to change at line 4269 skipping to change at line 4285
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, Authentication Protocol (EAP)", RFC 3579,
DOI 10.17487/RFC3579, September 2003, DOI 10.17487/RFC3579, September 2003,
<https://www.rfc-editor.org/info/rfc3579>. <https://www.rfc-editor.org/info/rfc3579>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, DOI 10.17487/RFC3766, April 2004,
<https://www.rfc-editor.org/info/rfc3766>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March
2005, <https://www.rfc-editor.org/info/rfc4017>. 2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter [RFC4072] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application", Extensible Authentication Protocol (EAP) Application",
RFC 4072, DOI 10.17487/RFC4072, August 2005, RFC 4072, DOI 10.17487/RFC4072, August 2005,
<https://www.rfc-editor.org/info/rfc4072>. <https://www.rfc-editor.org/info/rfc4072>.
skipping to change at line 4410 skipping to change at line 4421
<https://www.rfc-editor.org/info/rfc7170>. <https://www.rfc-editor.org/info/rfc7170>.
[RFC7299] Housley, R., "Object Identifier Registry for the PKIX [RFC7299] Housley, R., "Object Identifier Registry for the PKIX
Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014, Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
<https://www.rfc-editor.org/info/rfc7299>. <https://www.rfc-editor.org/info/rfc7299>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015, DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>. <https://www.rfc-editor.org/info/rfc7542>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8146] Harkins, D., "Adding Support for Salted Password Databases [RFC8146] Harkins, D., "Adding Support for Salted Password Databases
to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017, to EAP-pwd", RFC 8146, DOI 10.17487/RFC8146, April 2017,
<https://www.rfc-editor.org/info/rfc8146>. <https://www.rfc-editor.org/info/rfc8146>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
skipping to change at line 4480 skipping to change at line 4486
A.7. Requirement 4.2.1.3: TLS Extensions A.7. Requirement 4.2.1.3: TLS Extensions
TEAPv1 meets this requirement by allowing TLS extensions, such as TLS TEAPv1 meets this requirement by allowing TLS extensions, such as TLS
Certificate Status Request extension [RFC6066] and SessionTicket Certificate Status Request extension [RFC6066] and SessionTicket
extension [RFC5077], to be used during TLS tunnel establishment. extension [RFC5077], to be used during TLS tunnel establishment.
A.8. Requirement 4.2.1.4: Peer Identity Privacy A.8. Requirement 4.2.1.4: Peer Identity Privacy
TEAPv1 meets this requirement by establishment of the TLS tunnel and TEAPv1 meets this requirement by establishment of the TLS tunnel and
protection identities specific to the inner method. In addition, the protection identities specific to the Inner Method. In addition, the
peer certificate can be sent confidentially (i.e., encrypted). peer certificate can be sent confidentially (i.e., encrypted).
A.9. Requirement 4.2.1.5: Session Resumption A.9. Requirement 4.2.1.5: Session Resumption
TEAPv1 meets this requirement by mandating support of TLS session TEAPv1 meets this requirement by mandating support of TLS session
resumption as defined in Section 3.5.1 and TLS session resumption resumption as defined in Section 3.5.1 and TLS session resumption
using the methods defined in [RFC9190]. using the methods defined in [RFC9190].
A.10. Requirement 4.2.2: Fragmentation A.10. Requirement 4.2.2: Fragmentation
skipping to change at line 5058 skipping to change at line 5064
EAP-Payload TLV EAP-Payload TLV
[EAP-Response/EAP-Type=X]-> [EAP-Response/EAP-Type=X]->
<- Intermediate Result TLV (Success), <- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Identity-Type TLV, Identity-Type TLV,
EAP-Payload TLV[ EAP-Payload TLV[
EAP-Request/Identity]) EAP-Request/Identity])
// Compound-MAC calculated using keys generated from // Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel. EAP method X and the TLS tunnel.
// Next EAP conversation started (with EAP-Request/Identity) // Next EAP conversation started (with EAP-Request/Identity)
after successful completion of previous method X. The after successful completion of previous method X. The
Intermediate-Result and Crypto-Binding TLVs are sent in Intermediate-Result and Crypto-Binding TLVs are sent in
the next packet to minimize round trips. the next packet to minimize round trips.
Intermediate Result TLV (Success), Intermediate Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
EAP-Payload TLV [EAP-Response/Identity (MyID2)] -> EAP-Payload TLV [EAP-Response/Identity (MyID2)] ->
skipping to change at line 5086 skipping to change at line 5092
[EAP-Type=Y] -> [EAP-Type=Y] ->
<- Intermediate-Result TLV (Success), <- Intermediate-Result TLV (Success),
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Result TLV (Success) Result TLV (Success)
Intermediate-Result TLV (Success), Intermediate-Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Result TLV (Success) -> Result TLV (Success) ->
// Compound-MAC calculated using keys generated from EAP // Compound MAC calculated using keys generated from EAP
methods X and Y and the TLS tunnel. Compound keys are methods X and Y and the TLS tunnel. Compound keys are
generated using keys generated from EAP methods X and Y generated using keys generated from EAP methods X and Y
and the TLS tunnel. and the TLS tunnel.
// TLS channel torn down (messages sent in cleartext) // TLS channel torn down (messages sent in cleartext)
<- EAP-Success <- EAP-Success
C.7. Failed Crypto-Binding C.7. Failed Crypto-Binding
skipping to change at line 5235 skipping to change at line 5241
<- Intermediate Result TLV (Success), <- Intermediate Result TLV (Success),
Crypto-Binding TLV (Request), Crypto-Binding TLV (Request),
Vendor-Specific TLV, Vendor-Specific TLV,
// Vendor-Specific TLV exchange started after successful // Vendor-Specific TLV exchange started after successful
completion of previous method X. The Intermediate-Result completion of previous method X. The Intermediate-Result
and Crypto-Binding TLVs are sent with Vendor-Specific TLV and Crypto-Binding TLVs are sent with Vendor-Specific TLV
in next packet to minimize round trips. in next packet to minimize round trips.
// Compound-MAC calculated using keys generated from // Compound MAC calculated using keys generated from
EAP method X and the TLS tunnel. EAP method X and the TLS tunnel.
Intermediate Result TLV (Success), Intermediate Result TLV (Success),
Crypto-Binding TLV (Response), Crypto-Binding TLV (Response),
Vendor-Specific TLV -> Vendor-Specific TLV ->
// Optional additional Vendor-Specific TLV exchanges... // Optional additional Vendor-Specific TLV exchanges...
<- Vendor-Specific TLV <- Vendor-Specific TLV
skipping to change at line 5259 skipping to change at line 5265
Result TLV (Success) -> Result TLV (Success) ->
// TLS channel torn down (messages sent in cleartext) // TLS channel torn down (messages sent in cleartext)
<- EAP-Success <- EAP-Success
C.9. Peer Requests Inner Method After Server Sends Result TLV C.9. Peer Requests Inner Method After Server Sends Result TLV
In the case where the peer is authenticated during Phase 1 and the In the case where the peer is authenticated during Phase 1 and the
server sends back a Result TLV but the peer wants to request another server sends back a Result TLV but the peer wants to request another
inner method, the conversation will appear as follows: Inner Method, the conversation will appear as follows:
Authenticating Peer Authenticator Authenticating Peer Authenticator
------------------- ------------- ------------------- -------------
<- EAP-Request/Identity <- EAP-Request/Identity
EAP-Response/ EAP-Response/
Identity (MyID1) -> Identity (MyID1) ->
// Identity sent in the clear. May be a hint to help route // Identity sent in the clear. May be a hint to help route
the authentication request to EAP server, instead of the the authentication request to EAP server, instead of the
full user identity. TLS client certificate is also sent. full user identity. TLS client certificate is also sent.
skipping to change at line 5556 skipping to change at line 5562
| Result TLV(Success) | | Result TLV(Success) |
| <- - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - -
| | | |
| Crypto-Binding TLV(Response), | | Crypto-Binding TLV(Response), |
| Result TLV(Success) | | Result TLV(Success) |
| - - - - - - - - - - - - - - - - - - - - -> | - - - - - - - - - - - - - - - - - - - - ->
| | | |
| EAP Success | | EAP Success |
| <- - - - - - - - - - - - - - - - - - - - - | <- - - - - - - - - - - - - - - - - - - - -
Appendix D. Changes from RFC 7170
Alan DeKok was added as an editor.
The document was converted to Markdown from the [RFC7170] text
output.
Any formatting changes from [RFC7170] may have resulted from changing
from XML to Markdown as the source file when editing the draft.
The IANA Considerations section was replaced with a note to change
the IANA registry references to this document.
A new section was added to explain that the inner EAP-MSCHAPv2
derivation follows EAP-FAST. This is the largest technical change
from the previous revision of this document and follows existing
implementations.
Many small changes have been made throughout the document to correct
inconsistencies and to address mistakes. At a high level:
* All open errata have been addressed.
* A new term "Inner Method" has been defined.
* The definitions and derivation of IMSK, S-IMCK, etc. have been
corrected and clarified.
* The diagrams in Appendix C have been updated to match the TEAP
state machine.
All uses of the PAC were removed. It had not been implemented, and
there were no plans by implementors to use it.
Text was added on recommendations for inner and outer identities.
Section 6.2.5 was added late in the document life cycle in order to
document accidental behavior that could result in interoperability
issues.
Acknowledgments Acknowledgments
Nearly all of the text in this document was taken directly from Nearly all of the text in this document was taken directly from
[RFC7170]. We are grateful to the original authors and reviewers for [RFC7170]. We are grateful to the original authors and reviewers for
that document. The acknowledgments given here are only for the that document. The acknowledgments given here are only for the
changes that resulted in this document. changes that resulted in this document.
Alexander Clouter provided substantial and detailed technical Alexander Clouter provided substantial and detailed technical
feedback on nearly every aspect of the specification. The feedback on nearly every aspect of the specification. The
corrections in this document are based on his work. corrections in this document are based on his work.
 End of changes. 276 change blocks. 
456 lines changed or deleted 502 lines changed or added

This html diff was produced by rfcdiff 1.48.