RFC 9930: Tunnel Extensible Authentication Protocol (TEAP) Version 1

3.4.1. Client Certificates Sent During Phase 1

Note that since TLS client certificates are sent in the clear with TLS 1.2, if identity protection is required, then it is possible for the TLS authentication to be renegotiated after the first server authentication. To accomplish this, the server will typically not request a certificate in the server_hello; then, after the server_finished message is sent and before TEAP Phase 2, the server MAY send a TLS hello_request. This allows the peer to perform client authentication by sending a client_hello if it wants to or sending a no_renegotiation alert to the server indicating that it wants to continue with TEAP Phase 2 instead. Assuming that the peer permits renegotiation by sending a client_hello, then the server will respond with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages. Since this renegotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using EAP (for example, EAP-TLS) within the TLS session in TEAP Phase 2 instead of using TLS handshake renegotiation.¶

When TLS 1.3 or later is used, it is RECOMMENDED that client certificates are sent in Phase 1 instead of via Phase 2 and EAP-TLS. Doing so will reduce the number of round trips. Further discussion of this issue is given below in Section 3.6.5¶

3.5.1. TLS Session Resumption Using Server State

TEAP session resumption is achieved in the same manner TLS achieves session resumption. To support session resumption, the server and peer cache the Session ID, master secret, and cipher suite. The peer attempts to resume a session by including a valid Session ID from a previous TLS handshake in its ClientHello message. If the server finds a match for the Session ID and is willing to establish a new connection using the specified session state, the server will respond with the same Session ID and proceed with the TEAP Phase 1 tunnel establishment based on a TLS abbreviated handshake.¶

3.5.2. TLS Session Resumption Using Client State

TEAP supports the resumption of sessions based on the state being stored on the client side using the TLS SessionTicket extension techniques described in [RFC5077] and [RFC9190].¶

3.6.1. Inner Method Ordering

Due to issues noted in Section 5, the order of Inner Methods has implications for both security and interoperability.¶

Where the authentication is expected to use multiple Inner Methods, implementations SHOULD order the methods so that a method that derives an Extended Master Session Key (EMSK) is used first before any other method. This ordering helps to securely tie the Inner Method to the TLS session and therefore can prevent attacks.¶

Implementations SHOULD support both EAP and basic password authentication for inner methods. Implementations that support multiple types of Inner Methods (User and Machine) MUST support all of those methods in any order or combination. That is, it is explicitly permitted to "mix and match" Inner Methods.¶

For example, a server can request user authentication from the peer and have the peer return machine authentication (or vice versa). If the server is configured to accept machine authentication, it MUST accept that response. If that authentication succeeds, then depending on local policy, the server SHOULD proceed with requesting user authentication again.¶

Similarly, a peer that is configured to support multiple types of Inner Methods (User and Machine) can return a method other than what the server requested. This action is usually taken by the peer so that it orders Inner Methods for increased security. See Section 6.2.3 for further discussion of this issue.¶

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 different security policy. The peer may have roamed to a network that requires conformance with a different authentication policy, or the peer may request the server take additional action (e.g., channel binding) through the use of the Request-Action TLV as defined in Section 4.2.9.¶

The completion of each Inner Method is signaled by an Intermediate-Result TLV. Where the Intermediate-Result TLV indicates failure, an Error TLV SHOULD also be included using the most descriptive error code possible. The Intermediate-Result TLV may be accompanied by another TLV indicating that the server wishes to perform a subsequent authentication. When all Inner Methods have completed, the server MUST send a Result TLV indicating success or failure instead of a TLV that carries an Inner Method.¶

3.6.2. Inner EAP Authentication

EAP [RFC3748] prohibits use of multiple authentication methods within a single EAP conversation in order to limit vulnerabilities to on-path attacks. TEAP addresses on-path attacks through support for cryptographic protection of the inner EAP exchange and cryptographic binding of the inner EAP method(s) to the protected tunnel. Inner Methods are executed serially in a sequence. This version of TEAP does not support initiating multiple Inner Methods simultaneously in parallel. The Inner Methods need not be distinct. For example, EAP-TLS ([RFC5216] and [RFC9190]) could be run twice as an inner method, first using machine credentials, followed by a second instance using user credentials.¶

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 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 carried over the EAP-Payload TLV. Each distinct EAP authentication MUST be managed as a separate EAP state machine.¶

A TEAP server therefore MUST begin an EAP authentication with an EAP-Request/Identity (carried in an EAP-Payload TLV). However, a TEAP server MUST NOT finish the EAP conversation with an EAP Success or EAP Failure packet; the Intermediate-Result TLV is used instead.¶

Upon completion of each EAP authentication in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result of that authentication. When the result indicates success, it MUST be accompanied by a Crypto-Binding TLV. The peer MUST respond to the Intermediate-Result TLV indicating its own result. Similarly, upon success, the peer MUST accompany the TLV with its own Crypto-Binding TLV. The peer MUST respond to the Intermediate-Result TLV indicating its own result and similarly on success MUST accompany the TLV with its own Crypto-Binding TLV. The Crypto-Binding TLV is further 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 considered successful. If either indicates failure, then the authentication is considered failed. The result of failure of an EAP authentication does not always imply a failure of the overall authentication. If one Inner Method fails, the server may attempt to authenticate the peer with a different method (EAP or password).¶

3.6.3. Inner Password Authentication

The authentication server (AS) initiates password authentication by sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If the peer wishes to participate in password authentication, then it responds with a Basic-Password-Auth-Resp TLV that contains the username and password as defined in Section 4.2.15. If it does not wish to perform password authentication, then it responds with a Negative Acknowledgment (NAK) TLV indicating the rejection of the Basic-Password-Auth-Req TLV.¶

The basic password authentication defined here is similar in functionality to that used by EAP-TTLS [RFC5281] with inner password authentication. It shares a similar security and risk analysis.¶

Multiple round trips of password authentication requests and responses MAY be used to support some "housekeeping" functions such as a password or pin change before a user is considered to be authenticated. Multiple rounds MAY also be used to communicate a user's password and, separately, a one-time password such as Time-Based One-Time Passwords (TOTPs) [RFC6238].¶

Implementations MUST limit the number of round trips for password authentication. It is reasonable to use one or two round trips. Further round trips are likely to be problematic and SHOULD be avoided.¶

The first Basic-Password-Auth-Req TLV received in a session MUST include a prompt, which the peer displays to the user. Subsequent authentication rounds SHOULD include a prompt, but it is not always necessary.¶

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 then placed in the Basic-Password-Auth-Resp TLV. If the peer receives subsequent Basic-Password-Auth-Req TLVs in the same authentication session, it MUST NOT prompt for a username and MUST instead allow the user to enter only a password. The peer MUST copy the username used in the first Basic-Password-Auth-Resp TLV into all subsequent Basic-Password-Auth-Resp TLVs.¶

Servers MUST track the username across multiple password rounds and reject authentication if the identity changes from one Basic-Password-Auth-Resp TLV to the next. There is no reason for a user (or machine) to change identities in the middle of authentication.¶

Upon reception of a Basic-Password-Auth-Resp TLV in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result. The peer MUST respond to the Intermediate-Result TLV indicating its result. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV is further 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.¶

The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in [RFC3748]. Implementations should instead make use of the password authentication TLVs defined in this specification.¶

3.6.4. EAP-MSCHAPv2

If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST-MSCHAPv2 variant defined in [RFC5422], Section 3.2.3 MUST be used instead of the derivation defined in [MSCHAP].¶

The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the first and the second 16 octets of the EAP-MSCHAPv2 Master Session Key (MSK) are swapped when it is used as the Inner Method Session Keys (IMSKs) for TEAP.¶

3.6.5. Limitations on Inner Methods

Implementations SHOULD limit the permitted inner EAP methods to a small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-MSCHAPv2. These EAP methods are the most commonly supported inner methods in TEAP and are known to be interoperable among multiple implementations.¶

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 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 should work, as EAP-FAST-MSCHAPv2 has that behavior, and it works. Other EAP methods are untested and may or may not work.¶

Tunneled EAP methods such as PEAP [PEAP], EAP-TTLS [RFC5281], and 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 a password exchange.¶

The EAP methods defined in [RFC3748], Section 5, such as 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 attacks. The construction of the OTP and GTC methods makes this attack less relevant, as the information being sent is generally a one-time token. However, EAP-OTP and EAP-GTC offer no benefit over the basic password authentication defined in Section 3.6.3, which also does not perform crypto-binding of the Inner Method to the TLS session. These EAP methods are therefore not useful as Phase 2 methods within TEAP.¶

Other EAP methods are less widely used and highly likely to not work as the inner EAP method for TEAP.¶

In order to protect from on-path attacks, TEAP implementations MUST NOT permit the use of inner EAP methods that fail to perform crypto-binding of the Inner Method to the TLS session.¶

Implementations MUST NOT permit resumption for the inner EAP methods such as EAP-TLS. If the user or machine needs to be authenticated, it should use a method that provides full authentication. If the user or machine needs to do resumption, it can perform a full authentication once and then rely on the outer TLS session for resumption. This restriction applies also to all TLS-based EAP methods that can tunnel other EAP methods. As a result, this document updates [RFC9427].¶

In general, the reason to use a non-TLS-based EAP method inside of a TLS-based EAP method such as TEAP is for privacy. Many previous EAP methods may leak information about user identity, and those leaks are prevented by running the method inside of a protected TLS tunnel.¶

EAP-TLS is permitted in Phase 2 for two use cases. The first use case is when TLS 1.2 is used, as the client certificate is not protected as with TLS 1.3. It is therefore RECOMMENDED that when TLS 1.3 is used for the outer TEAP exchange, the client certificate is sent in Phase 1 instead of doing EAP-TLS in Phase 2. This behavior will simplify the authentication exchange and use fewer round trips than doing EAP-TLS inside of TEAP.¶

The second use case for EAP-TLS in Phase 2 is where both the user and machine use client certificates for authentication. Since TLS permits only one client certificate to be presented, only one certificate can be used in Phase 1. The second certificate is then presented via EAP-TLS in Phase 2.¶

For basic password authentication, it is RECOMMENDED that this method be only used for the exchange of one-time passwords. The existence of password-based EAP methods such as EAP-pwd ([RFC5931] and [RFC8146]) makes most cleartext password exchanges unnecessary. The updates to EAP-pwd in [RFC8146] permit it to be used with databases that store passwords in "salted" form, which greatly increases security.¶

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 via the TLS-PRF. As a result, the TEAP session will be vulnerable to on-path active attacks. Implementations and deployments SHOULD adopt various mitigation strategies described in [RFC7029], Section 3.2. Implementations also need to implement the Inner Method ordering described in Section 6.1 in order to fully prevent on-path attacks.¶

3.6.6. Protected Termination and Acknowledged Result Indication

A successful TEAP Phase 2 conversation MUST always end in a successful Crypto-Binding TLV and Result TLV exchange. A TEAP server may initiate the Crypto-Binding TLV and Result TLV exchange without initiating any Inner Methods in TEAP Phase 2. After the final Result TLV exchange, the TLS tunnel is terminated, and a cleartext EAP Success or EAP Failure is sent by the server. Peers implementing TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior to the peer and server reaching synchronized protected result indication.¶

The Crypto-Binding TLV exchange is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment. Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an Inner Method. The Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform cryptographic binding after each successful authentication in a 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 TLV to indicate its intention to end the conversation. If the peer requires nothing more from the server, it will respond with a Result TLV indicating success accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if necessary. The server then tears down the tunnel and sends a cleartext EAP Success or EAP Failure.¶

If the peer receives a Result TLV indicating success from the server, but its authentication policies are not satisfied (for example, it requires a particular authentication mechanism to be run), it may request further action from the server using the Request-Action TLV. The Request-Action TLV is sent with a Status field indicating what EAP Success/Failure result the peer would expect if the requested action is not granted. The value of the Action field indicates what the peer would like to do next. The format and values for the Request-Action TLV are defined in Section 4.2.9.¶

Upon receiving the Request-Action TLV, the server may process the request or ignore it, based on its policy. If the server ignores the request, it proceeds with termination of the tunnel and sends the cleartext EAP Success or Failure message based on the Status field of the peer's Request-Action TLV. If the server honors and processes the request, it continues with the requested action. The conversation completes with a Result TLV exchange. The Result TLV may be included with the TLV that completes the requested action.¶

Error handling for Phase 2 is discussed in Section 3.9.3.¶

3.9.1. Outer-Layer Errors

Errors on the TEAP outer-packet layer are handled in the following ways:¶

3.9.2. TLS Layer Errors

If the TEAP server detects an error at any point in the TLS handshake or the TLS layer, the server SHOULD send a TEAP request encapsulating a TLS record containing the appropriate TLS alert message rather than immediately terminating the TEAP exchange so as to allow the peer to inform the user of the cause of the failure. The TEAP peer MUST send a TEAP response to an alert message. The EAP-Response packet sent by the peer SHOULD contain a TEAP response with a zero-length message. The server MUST terminate the TEAP exchange with an EAP Failure packet no matter what the client says.¶

If the TEAP peer detects an error at any point in the TLS layer, the TEAP peer SHOULD send a TEAP response encapsulating a TLS record containing the appropriate TLS alert message, which contains a zero-length message. The server then MUST terminate the conversation with an EAP failure as discussed in the previous paragraph.¶

While TLS 1.3 [RFC8446] allows for the TLS conversation to be restarted, it is not clear when that would be useful (or used) for TEAP. Fatal TLS errors will cause the TLS conversation to fail. Non-fatal TLS errors can likely be ignored entirely. As a result, TEAP implementations MUST NOT permit TLS restarts.¶

3.9.3. Phase 2 Errors

There are a large number of situations where errors can occur during Phase 2 processing. This section describes both errors and the recommended processing of them.¶

When the server receives a Result TLV with a fatal Error TLV from the peer, it MUST terminate the TLS tunnel and reply with an EAP Failure.¶

When the peer receives a Result TLV with a fatal Error TLV from the server, it MUST respond with a Result TLV indicating failure. The server MUST discard any data it receives from the peer and reply with an EAP Failure. The final message from the peer is required by the EAP state machine and serves only to allow the server to reply to the peer with the EAP Failure.¶

The following items describe specific errors and processing in more detail.¶

Fatal Error processing a TLV:

Any time the peer or the server finds a fatal error outside of the TLS layer during Phase 2 TLV processing, it MUST send a Result TLV of failure and an Error TLV using the most descriptive error code possible.¶

Fatal Error during TLV Exchanges:

For errors involving the processing of the sequence of exchanges, such as a violation of TLV rules (e.g., multiple EAP-Payload TLVs), the error code is Unexpected TLVs Exchanged.¶

Fatal Error due to tunnel compromise:

For errors involving a tunnel compromise, such as when the Crypto-Binding TLV fails validation, the error code is Tunnel Compromise Error.¶

Non-Fatal Error due to Inner Method:

If there is a non-fatal error while running the Inner Method, the receiving side SHOULD NOT silently drop the Inner Method exchange. Instead, it SHOULD reply with an Error TLV using the most descriptive error code possible.¶

If there is no error code that matches the particular issue, then the value Inner Method Error (1001) SHOULD be used. This response is a positive indication that there was an error processing the current Inner Method. The side receiving a non-fatal Error TLV MAY decide to start a new and different Inner Method instead or send back a Result TLV to terminate the TEAP authentication session.¶

3.11.1. Certificate Provisioning Within the Tunnel

Provisioning of a peer's certificate is supported in TEAP by performing the Simple PKI Request/Response from [RFC5272] using PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI Request using a PKCS#10 CertificationRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e., 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 and provided an identity proof on the peer prior to a certificate is being issued.¶

In order to provide linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request, the peer generating the request SHOULD obtain the tls-unique value from the TLS subsystem as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer operations between obtaining the tls-unique value through generation of the Certification Signing Request (CSR) that contains the current tls-unique value and the subsequent verification of this value by the TEAP server are the "phases of the application protocol during which application-layer authentication occurs" that are protected by the synchronization interoperability mechanism described in the interoperability note in "Channel Bindings for TLS" ([RFC5929], Section 3.1). When performing renegotiation, TLS "secure_renegotiation" [RFC5746] MUST be used.¶

The tls-unique value is base-64-encoded as specified in Section 4 of [RFC4648], and the resulting string is placed in the certification request challengePassword field ([RFC2985], Section 5.4.1). The challengePassword field is limited to 255 octets (Section 7.4.9 of [RFC5246] indicates that no existing cipher suite would result in an issue with this limitation). If tls-unique information is not embedded within the certification request, the challengePassword field MUST be empty to indicate that the peer did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information).¶

The server SHOULD verify the tls-unique information. This ensures that the signed certificate request is being presented by an authenticated TEAP peer that is in possession of the private key.¶

The Simple PKI Request/Response generation and processing rules of [RFC5272] SHALL apply to TEAP, with the exception of error conditions. In the event of an error, the TEAP server SHOULD respond with an Error TLV using the most descriptive error code possible; it MAY ignore the PKCS#10 request that generated the error.¶

3.11.2. Certificate Content and Uses

It is not enough to verify that the CSR provided by the peer to the authenticator is from an authenticated user. The CSR itself should also be examined by the authenticator or CA before any certificate is issued.¶

The format of a CSR is complex and contains a substantial amount of information. That information could be incorrect, such as a user claiming a wrong physical address, email address, etc. It is RECOMMENDED that systems provisioning these certificates validate that the CSR contains the expected data and that it does not contain unexpected data. For example, a CA could refuse to issue the certificate if the CSR contained unknown fields or if a known field contained an unexpected or invalid value. The CA can modify or refuse a particular CSR to address these deficiencies for any reasons, including local site policy. We note that the "A" in "CA" 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 presented to it.¶

Once an EAP peer receives the signed certificate, the peer could potentially be (ab)used for in TLS contexts other than TEAP. For example, the certificate could be used with EAP-TLS, or even with HTTPS. It is NOT RECOMMENDED to use certificates provisioned via TEAP for any non-TEAP. One method of enforcing this restriction is to have different CAs (or different intermediate CAs) that issue certificates for different uses. For example, TLS-based EAP methods could share one CA, and even use different intermediary CAs for different TLS-based EAP methods. HTTPS servers could use an entirely different CA. The different protocols could then be configured to validate client certificates only from their preferred CA, which would prevent peers from using certificates outside of the intended use case.¶

Another method of limiting the uses of a certificate is to provision it with an appropriate value for the Extended Key Purpose field [RFC7299]. For example, the id-kp-eapOverLAN [RFC4334] value could be used to indicate that this certificate is intended for use only with EAP.¶

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 permitted or forbidden in a certificate. All we can do in this document is to highlight the issues and make the reader aware that they have to be addressed.¶

3.11.3. Server Unauthenticated Provisioning Mode

In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in Phase 1, and the peer and server negotiate an Inner Method or methods in Phase 2. This Inner Method MUST support mutual authentication, provide key derivation, and be resistant to attacks such as on-path and dictionary attacks. In most cases, this Inner Method will be an EAP authentication method. Example Inner Methods that satisfy these criteria include EAP-pwd [RFC5931] and EAP-EKE [RFC6124] but not EAP-FAST-MSCHAPv2.¶

This provisioning mode enables the bootstrapping of peers when the peer lacks the ability to authenticate the server during Phase 1. This includes both cases in which the cipher suite negotiated does not provide authentication and in which the cipher suite negotiated provides the authentication, but the peer is unable to validate the identity of the server for some reason.¶

Upon successful completion of the Inner Method in Phase 2, the peer and server exchange a Crypto-Binding TLV to bind the Inner Method with the outer tunnel and ensure that an on-path attack has not been attempted.¶

Support for the Server Unauthenticated Provisioning Mode is optional. The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when using Server Unauthenticated Provisioning Mode, but other anonymous cipher suites MAY be supported as long as the TLS pre-master secret is generated from contribution from both peers.¶

When a strong Inner Method is not used with Server Unauthenticated Provisioning Mode, it is possible for an attacker to perform an on-path attack. In effect, Server Unauthenticated Provisioning Mode has similar security issues as just running the Inner Method in the open without the protection of TLS. All of the information in the tunnel should be assumed to be visible to, and modifiable by, an attacker.¶

Implementations SHOULD exchange minimal data in Server Unauthenticated Provisioning Mode. Instead, they should use that mode to set up a secure/authenticated tunnel and then use that tunnel to perform any needed data exchange.¶

It is RECOMMENDED that client implementations and deployments authenticate TEAP servers if at all possible. Authenticating the server means that a client can be provisioned securely with no chance of an attacker eaves-dropping on the connection.¶

Note that server unauthenticated provisioning can only use anonymous cipher suites in TLS 1.2 and earlier. These cipher suites have been deprecated in TLS 1.3 ([RFC8446], Appendix C.5). For TLS 1.3, the server MUST provide a certificate, and the peer performs server unauthenticated provisioning by not validating the certificate chain or any of its contents.¶

3.11.4. Channel Binding

[RFC6677] defines channel bindings for EAP that solve the "lying NAS" and the "lying provider" problems, using a process in which the EAP peer gives information about the characteristics of the service provided by the authenticator to the Authentication, Authorization, and Accounting (AAA) server protected within the EAP authentication method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator.¶

TEAP supports EAP channel binding using the Channel-Binding TLV defined in Section 4.2.7. If the TEAP server wants to request the channel-binding information from the peer, it sends an empty Channel-Binding TLV to indicate the request. The peer responds to the request by sending a Channel-Binding TLV containing a channel-binding message as defined in [RFC6677]. The server validates the channel-binding message and sends back a Channel-Binding TLV with a result code. If the server did not initiate the channel-binding request and the peer still wants to send the channel-binding information to the server, it can do that by using the Request-Action TLV along with the Channel-Binding TLV. The peer MUST only send channel-binding information after it has successfully authenticated the server and established the protected tunnel.¶

4.2.1. General TLV Format

TLVs are defined as described below. The fields are transmitted from left to right.¶

If a peer or server receives a TLV that is not of the correct format, the TLV MUST be discarded. It is generally useful to log an error or debugging message that indicates which TLV had an issue and what the problem is. However, TLVs that are malformed are invalid and cannot be used.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|            TLV Type       |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0

Optional TLV¶

1

Mandatory TLV¶

R

Reserved, set to zero (0)¶

TLV Type

A 14-bit field, denoting the TLV type. Allocated types include:¶

0

Unassigned¶

1

Authority-ID TLV (Section 4.2.2)¶

2

Identity-Type TLV (Section 4.2.3)¶

3

Result TLV (Section 4.2.4)¶

4

NAK TLV (Section 4.2.5)¶

5

Error TLV (Section 4.2.6)¶

6

Channel-Binding TLV (Section 4.2.7)¶

7

Vendor-Specific TLV (Section 4.2.8)¶

8

Request-Action TLV (Section 4.2.9)¶

9

EAP-Payload TLV (Section 4.2.10)¶

10

Intermediate-Result TLV (Section 4.2.11)¶

11

PAC TLV (DEPRECATED)¶

12

Crypto-Binding TLV (Section 4.2.13)¶

13

Basic-Password-Auth-Req TLV (Section 4.2.14)¶

14

Basic-Password-Auth-Resp TLV (Section 4.2.15)¶

15

PKCS#7 TLV (Section 4.2.16)¶

16

PKCS#10 TLV (Section 4.2.17)¶

17

Trusted-Server-Root TLV (Section 4.2.18)¶

18

CSR-Attributes TLV (Section 4.2.19)¶

19

Identity-Hint TLV (Section 4.2.20)¶

Length

The length of the Value field in octets.¶

Value

The value of the TLV.¶

4.2.2. Authority-ID TLV

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ID...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

1 - Authority-ID¶

Length

The Length field is two octets and contains the length of the ID field in octets.¶

ID

Hint of the identity of the server to help the peer to match the credentials available for the server. It should be unique across the deployment.¶

4.2.3. Identity-Type TLV

The Identity-Type TLV allows an EAP server to send a hint to help the EAP peer select the right type of identity, for example, user or machine. TEAPv1 implementations MUST support this TLV. Only one Identity-Type TLV SHOULD be present in the TEAP request or response packet.¶

A server sending the Identity-Type TLV MUST also include an EAP-Payload TLV or a Basic-Password-Auth-Resp TLV. A peer sending an Identity-Type TLV MUST also include EAP-Payload TLV or a Basic-Password-Auth-Resp TLV.¶

An EAP peer receiving an Identity-Type request SHOULD respond with an Identity-Type TLV with the requested type. If the Identity-Type field does not contain one of the known values, or if the EAP peer does not have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the one of available identity types.¶

A server receiving an Identity-Type in the response MUST check if the value of the Identity-Type in the response matches the value of the Identity-Type that was sent in the request. A match means that the server can proceed with authentication.¶

However, if the values do not match, the server can proceed with authentication if and only if the following two conditions match. If either of the following two conditions does not match, the server MUST respond with a Result TLV of Failure.¶

The first condition allows a server to be configured to permit only user authentication, or else only machine authentication. A server could also use an Identity-Hint TLV sent in the response to permit different types of authentication for different identities. A server could also permit or forbid different kinds of authentication based on other information, such an outer EAP Identity, fields in an outer EAP client certificate, or other fields received in a RADIUS or Diameter packet along with the TEAP session. There is no requirement that a server has to support both user and machine authentication for all TEAP sessions.¶

The second condition ensures that if a particular Inner Method succeeds, the server does not attempt a subsequent Inner Method for 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 additional authentication via a different Inner Method. Similarly, there is no benefit to repeating an authentication sessions for the same user; the result will not change.¶

This second condition also forbids multiple rounds of challenge/response authentication via the Basic-Password-Auth-Req TLV. TEAPv1 supports only one round of Basic-Password-Auth-Req followed by Basic-Password-Auth-Resp. The result of that round MUST NOT be another Basic-Password-Auth-Req TLV.¶

This second condition also means that a server MUST NOT send an Identity-Hint TLV that has the same value as was previously used for a successful authentication.¶

The Identity-Type TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identity-Type         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

2 - Identity-Type TLV¶

Length

2¶

Identity-Type

The Identity-Type field is two octets. Values include:¶

1

User¶

2

Machine¶

4.2.4. Result TLV

The Result TLV provides support for acknowledged success and failure messages for protected termination within TEAP. If the Status field does not contain one of the known values, then the peer or EAP server MUST treat this as a fatal error of Unexpected TLVs Exchanged. The behavior of the Result TLV is further discussed in Sections 3.6.6 and 3.9.3.¶

A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload, or Crypto-Binding.¶

A Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV.¶

The Result TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Status            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

3 - Result TLV¶

Length

2¶

Status

The Status field is two octets. Values include:¶

1

Success¶

2

Failure¶

4.2.5. NAK TLV

The NAK TLV allows a peer to detect TLVs that are not supported by the other peer. A TEAP packet can contain 0 or more NAK TLVs. A NAK TLV should not be accompanied by other TLVs. A NAK TLV MUST NOT be sent in response to a message containing a Result TLV, instead a Result TLV of failure should be sent indicating failure and an Error TLV of Unexpected TLVs Exchanged. The NAK TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            NAK-Type           |           TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

4 - NAK TLV¶

Length

>=6¶

Vendor-Id

The Vendor-Id field is four octets and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0, and the low-order three octets are the Structure of Management Information (SMI) Network Management Private Enterprise Number of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.¶

NAK-Type

The NAK-Type field is two octets. The field contains the type of the TLV that was not supported. A TLV of this type MUST have been included in the previous packet.¶

TLVs

This field contains a list of zero or more TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs are for future extensibility to communicate why the offending TLV was determined to be unsupported.¶

4.2.6. Error TLV

The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure, and the conversation is terminated as described in Section 3.9.3.¶

Many of the error codes below refer to errors in Inner Method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes.¶

The Error TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Error-Code                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

5 - Error TLV¶

Length

4¶

Error-Code

The Error-Code field is four octets. Currently defined values for Error-Code include:¶

1

User account expires soon¶

2

User account credential expires soon¶

3

User account authorizations change soon¶

4

Clock skew detected¶

5

Contact administrator¶

6

User account credentials change required¶

1001

Inner Method Error¶

1002

Unspecified authentication infrastructure problem¶

1003

Unspecified authentication failure¶

1004

Unspecified authorization failure¶

1005

User account credentials unavailable¶

1006

User account expired¶

1007

User account locked: try again later¶

1008

User account locked: admin intervention required¶

1009

Authentication infrastructure unavailable¶

1010

Authentication infrastructure not trusted¶

1011

Clock skew too great¶

1012

Invalid inner realm¶

1013

Token out of sync: administrator intervention required¶

1014

Token out of sync: PIN change required¶

1015

Token revoked¶

1016

Tokens exhausted¶

1017

Challenge expired¶

1018

Challenge algorithm mismatch¶

1019

Client certificate not supplied¶

1020

Client certificate rejected¶

1021

Realm mismatch between inner and outer identity¶

1022

Unsupported Algorithm In Certificate Signing Request¶

1023

Unsupported Extension In Certificate Signing Request¶

1024

Bad Identity In Certificate Signing Request¶

1025

Bad Certificate Signing Request¶

1026

Internal CA Error¶

1027

General PKI Error¶

1028

Inner Method's channel-binding data required but not supplied¶

1029

Inner Method's channel-binding data did not include required information¶

1030

Inner Method's channel binding failed¶

1031

User account credentials incorrect [USAGE NOT RECOMMENDED]¶

1032

Inner Method not supported¶

2001

Tunnel Compromise Error¶

2002

Unexpected TLVs Exchanged¶

2003

The Crypto-Binding TLV is invalid (Version, Received-Ver, or Sub-Type)¶

2004

The first Inner Method did not derive EMSK¶

2005

The Crypto-Binding TLV did not include a required MSK Compound MAC¶

2006

The MSK Compound MAC fails verification¶

2007

The Crypto-Binding TLV did not include a required EMSK Compound MAC¶

2008

The EMSK Compound MAC fails verification¶

2009

The EMSK Compound MAC exists, but the Inner Method did not derive EMSK¶

4.2.7. Channel-Binding TLV

The Channel-Binding TLV provides a mechanism for carrying channel-binding data from the peer to the EAP server and a channel-binding response from the EAP server to the peer as described in [RFC6677]. TEAPv1 implementations MAY support this TLV, which cannot be responded to with a NAK TLV. If the Channel-Binding data field does not contain one of the known values or if the EAP server does not support this TLV, then the server MUST ignore the value. The Channel-Binding TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

6 - Channel-Binding TLV¶

Length

variable¶

Data

The data field contains a channel-binding message as defined in Section 5.3 of [RFC6677].¶

4.2.8. Vendor-Specific TLV

The Vendor-Specific TLV is available to allow vendors to support their own extended attributes not suitable for general usage. A Vendor-Specific TLV attribute can contain one or more TLVs, referred to as Vendor TLVs. The TLV type of a particular Vendor TLV is defined by the vendor. All the Vendor TLVs inside a single Vendor-Specific TLV belong to the same vendor. There can be multiple Vendor-Specific TLVs from different vendors in the same message. Error handling in the Vendor TLV could use the vendor's own specific error-handling mechanism or use the standard TEAP error codes defined.¶

Vendor TLVs may be optional or mandatory. Vendor TLVs sent with Result TLVs MUST be marked as optional. If the Vendor-Specific TLV is marked as mandatory, then it is expected that the receiving side needs to recognize the vendor ID, parse all Vendor TLVs within, and deal with error handling within the Vendor-Specific TLV as defined by the vendor.¶

Where a Vendor-Specific TLV carries an authentication protocol in the Inner Method, it MUST define values for MSK and EMSK. Where these values cannot be derived from cryptographic primitives, they MUST be set to zero, as happens when Basic-Password-Auth-Req is used.¶

The Vendor-Specific TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Vendor-Id                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Vendor TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

0 or 1¶

R

Reserved, set to zero (0)¶

TLV Type

7 - Vendor-Specific TLV¶

Length

4 + cumulative length of all included Vendor TLVs¶

Vendor-Id

The Vendor-Id field is four octets and contains the Vendor-Id of the TLV. The high-order octet is 0, and the low-order 3 octets are the SMI Network Management Private Enterprise Number of the Vendor in network byte order.¶

Vendor TLVs

This field is of indefinite length. It contains Vendor-Specific TLVs, in a format defined by the vendor.¶

4.2.9. Request-Action TLV

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 negotiates additional Inner Methods or process TLVs that are passed inside of the Request-Action TLV.¶

The receiving side MUST process this TLV. The processing for the TLV is as follows:¶

The receiving entity MAY choose to process any of the TLVs that are included in the message.¶

If the receiving entity chooses NOT to process any TLV in the list, then it sends back a Result TLV with the same code in the Status field of the Request-Action TLV.¶

If multiple Request-Action TLVs are in the request, the session can continue if any of the TLVs in any Request-Action TLV are processed.¶

If multiple Request-Action TLVs are in the request and none of them is processed, then the most fatal status should be used in the Result TLV returned. If a status code in the Request-Action TLV is not understood by the receiving entity, then it SHOULD be treated as a fatal error. Otherwise, the receiving entity MAY send a Request-Action TLV containing an Error TLV of value 2002 (Unexpected TLVs Exchanged).¶

After processing the TLVs or Inner Method in the request, another round of Result TLV exchange MUST occur to synchronize the final status on both sides.¶

The peer or the server MAY send multiple Request-Action TLVs to the other side. Two Request-Action TLVs MUST NOT occur in the same TEAP packet if they have the same Status value. The order of processing multiple Request-Action TLVs is implementation dependent. If the receiving side processes the optional (non-fatal) items first, it is possible that the fatal items will disappear at a later time. If the receiving side processes the fatal items first, the communication time will be shorter.¶

The peer or the server MAY return a new set of Request-Action TLVs after one or more of the requested items have been processed and the other side has signaled it wants to end the EAP conversation.¶

The Request-Action TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Status   |      Action    |                TLVs....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

8 - Request-Action TLV¶

Length

2 + cumulative length of all included TLVs¶

Status

The Status field is one octet. This indicates the result if the party who receives this TLV does not process the action. Values include:¶

1

Success¶

2

Failure¶

Action

The Action field is one octet. Values include:¶

1

Process-TLV¶

2

Negotiate-EAP¶

TLVs

This field is of indefinite length. It contains TLVs that the peer wants the server to process.¶

4.2.10. EAP-Payload TLV

To allow coalescing an EAP request or response with other TLVs, the EAP-Payload TLV is defined, which includes an encapsulated EAP packet and a list of optional TLVs. The optional TLVs are provided for future extensibility to provide hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. The EAP-Payload TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          EAP packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

9 - EAP-Payload TLV¶

Length

length of embedded EAP packet + cumulative length of additional TLVs¶

EAP packet

This field contains a complete EAP packet, including the EAP header (Code, Identifier, Length, Type) fields. The length of this field is determined by the Length field of the encapsulated EAP packet.¶

TLVs

This (optional) field contains a list of TLVs associated with the EAP packet field. The TLVs MUST NOT have the mandatory bit set. The total length of this field is equal to the Length field of the EAP-Payload TLV, minus the Length field in the EAP header of the EAP packet field.¶

4.2.11. Intermediate-Result TLV

The Intermediate-Result TLV signals intermediate Success and Failure messages for all inner methods. The Intermediate-Result TLV MUST be used for all Inner Methods.¶

An Intermediate-Result TLV indicating success MUST be accompanied by a Crypto-Binding TLV.¶

An Intermediate-Result TLV indicating failure SHOULD be accompanied by an Error TLV that indicates why the authentication failed.¶

The optional TLVs associated with this TLV are provided for future extensibility to provide hints about the current result. The Intermediate-Result TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Status            |        TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

10 - Intermediate-Result TLV¶

Length

2 + cumulative length of the embedded associated TLVs¶

Status

The Status field is two octets. Values include:¶

1

Success¶

2

Failure¶

TLVs

This field is of indeterminate length and contains zero or more of the TLVs associated with the Intermediate Result TLV. The TLVs in this field MUST NOT have the mandatory bit set.¶

4.2.12. PAC TLV

[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-FAST [RFC4851]. However, implementation experience and analysis determined that the PAC was not necessary. Instead, TEAP performs session resumption using the NewSessionTicket message as defined in Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC TLV has been deprecated.¶

As the PAC TLV is deprecated, an entity receiving it SHOULD send a Result TLV indicating failure and an Error TLV of Unexpected TLVs Exchanged.¶

4.2.13. Crypto-Binding TLV

The Crypto-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment.¶

A Crypto-Binding MUST be accompanied by an Intermediate-Result TLV indicating success.¶

The Crypto-Binding TLV MUST be exchanged and validated before any Intermediate-Result or Result TLV value is examined, regardless of whether there is an Inner Method or not. It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful Inner Method in a sequence of inner methods, before proceeding with another Inner Method. If no MSK or EMSK has been generated and a Crypto-Binding TLV is required, then the MSK Compound MAC field contains the MAC using keys generated according to Section 6.3.¶

The Crypto-Binding TLV is valid only if the following checks pass on its contents:¶

If any of the above checks fails, then the TLV is invalid. An invalid Crypto-Binding TLV is a fatal error and is handled as described in Section 3.9.3¶

See Section 6 for a more detailed discussion of how the Compound MAC fields are constructed and verified.¶

The Crypto-Binding TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Reserved   |    Version    |  Received-Ver.| Flags|Sub-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Nonce                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   EMSK Compound MAC                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    MSK Compound MAC                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

12 - Crypto-Binding TLV¶

Length

76¶

Reserved

Reserved, set to zero (0)¶

Version

The Version field is a single octet, which is set to the version of Crypto-Binding TLV the TEAP method is using. For an implementation compliant with TEAPv1, the version number MUST be set to one (1).¶

Received-Ver

The Received-Ver field is a single octet and MUST be set to the TEAP version number received during version negotiation. Note that this field only provides protection against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides.¶

For TEAPv1, this version number MUST be set to one (1).¶

Flags

The Flags field is four bits. Defined values include:¶

1

EMSK Compound MAC is present¶

2

MSK Compound MAC is present¶

3

Both EMSK and MSK Compound MAC are present¶

All other values of the Flags field are invalid.¶

Sub-Type

The Sub-Type field is four bits. Defined values include:¶

0

Binding Request¶

1

Binding Response¶

All other values of the Sub-Type field are invalid.¶

Nonce

The Nonce field is 32 octets. It contains a 256-bit nonce that is temporally unique, used for Compound MAC key derivation at each end. The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1).¶

EMSK Compound MAC

The EMSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.¶

Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value.¶

MSK Compound MAC

The MSK Compound MAC field is 20 octets. This can be the Server MAC (B1_MAC) or the Client MAC (B2_MAC). The computation of the MAC is described in Section 6.3.¶

Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value.¶

4.2.14. Basic-Password-Auth-Req TLV

The Basic-Password-Auth-Req TLV is used by the authentication server to request a username and password from the peer. It contains an optional user prompt message for the request. The peer is expected to obtain the username and password and send them in a Basic-Password-Auth-Resp TLV.¶

The Basic-Password-Auth-Req TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prompt ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

13 - Basic-Password-Auth-Req TLV¶

Length

variable¶

Prompt

optional user prompt message in UTF-8 [RFC3629] format¶

4.2.15. Basic-Password-Auth-Resp TLV

The Basic-Password-Auth-Resp TLV is used by the peer to respond to a Basic-Password-Auth-Req TLV with a username and password. The TLV contains a username and password. The username and password are in UTF-8 [RFC3629] format.¶

The Basic-Password-Auth-Resp TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Userlen     |             Username
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...     Username    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Passlen     |             Password
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ...     Password    ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

M

Mandatory, set to one (1)¶

R

Reserved, set to zero (0)¶

TLV Type

14 - Basic-Password-Auth-Resp TLV¶

Length

variable¶

Userlen

Length of Username field in octets.¶

The value of Userlen MUST NOT be zero.¶

Username

Username in UTF-8 [RFC3629] format.¶

The content of Username SHOULD follow the guidelines set in [RFC9427], Section 3.1.¶

Passlen

Length of Password field in octets.¶

The value of Passlen MUST NOT be zero.¶

Password

Password in UTF-8 [RFC3629] format.¶

Note that there is no requirement that passwords be humanly readable. Octets in a passwords may have values less than 0x20, including 0x00.¶

4.2.16. PKCS#7 TLV

The PKCS#7 TLV is used by the EAP server to deliver certificate(s) to the peer. The format consists of a certificate or certificate chain in binary DER encoding [X.690] in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652].¶

When used in response to a Trusted-Server-Root TLV request from the peer, the EAP server MUST send the PKCS#7 TLV inside a Trusted-Server-Root TLV. When used in response to a PKCS#10 certificate enrollment request from the peer, the EAP server MUST send the PKCS#7 TLV without a Trusted-Server-Root TLV. The PKCS#7 TLV is always marked as optional, which cannot be responded to with a NAK TLV. TEAP implementations that support the Trusted-Server-Root TLV or the PKCS#10 TLV MUST support this TLV. Peers MUST NOT assume that the certificates in a PKCS#7 TLV are in any order.¶

TEAP servers MAY return self-signed certificates. Peers that handle self-signed certificates or trust anchors MUST NOT implicitly trust these certificates merely due to their presence in the certificate bag. Note: Peers are advised to take great care in deciding whether to use a received certificate as a trust anchor. The authenticated nature of the tunnel in which a PKCS#7 bag is received can provide a level of authenticity to the certificates contained therein. Peers are advised to take into account the implied authority of the EAP server and to constrain the trust it can achieve through the trust anchor received in a PKCS#7 TLV.¶

The PKCS#7 TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           PKCS#7 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

15 - PKCS#7 TLV¶

Length

The length of the PKCS#7 Data field.¶

PKCS#7 Data

This field contains the DER-encoded X.509 certificate or certificate chain in a Certificates-Only PKCS#7 SignedData message.¶

4.2.17. PKCS#10 TLV

The PKCS#10 TLV is used by the peer to initiate the "Simple PKI" Request/Response from [RFC5272]. The format of the request is as specified in Section 6.4 of [RFC4945]. The PKCS#10 TLV is always marked as optional, which cannot be responded to with a NAK TLV.¶

The PKCS#10 TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           PKCS#10 Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

16 - PKCS#10 TLV¶

Length

The length of the PKCS#10 Data field.¶

PKCS#10 Data

This field contains the DER-encoded PKCS#10 certificate request.¶

4.2.18. Trusted-Server-Root TLV

Trusted-Server-Root TLV facilitates the request and delivery of a trusted server root certificate. The Trusted-Server-Root TLV can be exchanged in regular TEAP authentication mode or provisioning mode. The Trusted-Server-Root TLV is always marked as optional and cannot be responded to with a NAK TLV. The Trusted-Server-Root TLV MUST only be sent as an Inner TLV (inside the protection of the tunnel).¶

After the peer has determined that it has successfully authenticated the EAP server and validated the Crypto-Binding TLV, it MAY send one or more Trusted-Server-Root TLVs (marked as optional) to request the trusted server root certificates from the EAP server. The EAP server MAY send one or more root certificates with a Public Key Cryptographic System #7 (PKCS#7) TLV inside the Trusted-Server-Root TLV. The EAP server MAY also choose not to honor the request.¶

The Trusted-Server-Root TLV allows the peer to send a request to the EAP server for a list of trusted roots. The server may respond with one or more root certificates in PKCS#7 [RFC2315] format.¶

If the EAP server sets the credential format to PKCS#7-Server-Certificate-Root, then the Trusted-Server-Root TLV should contain the root of the certificate chain of the certificate issued to the EAP server packaged in a PKCS#7 TLV. If the server certificate is a self-signed certificate, then the root is the self-signed certificate.¶

If the Trusted-Server-Root TLV credential format contains a value unknown to the peer, then the EAP peer should ignore the TLV.¶

The Trusted-Server-Root TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Credential-Format   |     Cred TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

17 - Trusted-Server-Root TLV¶

Length

>=2 octets¶

Credential-Format

The Credential-Format field is two octets. Values include:¶

1 - PKCS#7-Server-Certificate-Root¶

Cred TLVs

This field is of indefinite length. It contains TLVs associated with the credential format. The peer may leave this field empty when using this TLV to request server trust roots.¶

4.2.19. CSR-Attributes TLV

The CSR-Attributes TLV provides information from the server to the peer on how certificate signing requests should be formed. The purpose of CSR attributes is described in Section 4.5 of [RFC7030]. Servers MAY send the CSR-Attributes TLV directly after the TLS 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 indication to the peer that the server would like the peer to renew its certificate using the parameters provided in this TLV. Servers shall construct the contents of the CSR-Attributes TLV as specified in [RFC7030], Section 4.5.2 with the exception that the DER encoding MUST NOT be encoded in base64. The base64 encoding is used in [RFC7030] because the transport protocol used there requires textual encoding. In contrast, TEAP attributes can transport arbitrary binary data.¶

Servers and peers MUST follow the guidance provided in [RFC9908] when creating the CSR-Attributes TLV. Peers MAY ignore the contents of the TLV if they are unable to do so, but then servers may not process PKCS#10 certificate requests for this or any other reason.¶

The CSR-Attributes TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                DER Encoded CSR Attributes                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

18 - CSR-Attributes¶

Length

>=2 octets¶

4.2.20. Identity-Hint TLV

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 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.¶

The purpose of this TLV is to solve the "bootstrapping" problem for the server. In order to perform authentication, the server must choose an Inner Method. However, the server has no knowledge of what methods are supported by the peer. Without an identity hint, the server needs to propose a method and then have the peer return a response indicating that the requested method is not available. This negotiation increases the number of round trips required for TEAP to conclude with no additional benefit.¶

When the Identity-Hint is used, the peer can signal which identities it has available, which enables the server to choose an Inner Method that is appropriate for that identity.¶

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 user authentication, it can send two Identity-Hint TLVs with values "host/name.example.com" (for a machine with hostname "name.example.com") and "user@example.com" (for a person with identity "user@example.com").¶

The contents of the Identity-Hint TLV SHOULD be in the format of an NAI [RFC7542], but we note that as given in the example above, Machine identities might not follow that format. As these identities are never used for AAA routing as discussed in [RFC7542], Section 3, the format and definition of these identities are entirely site local. Robust implementations MUST support arbitrary data in the content of this TLV, including binary octets.¶

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 policies.¶

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 be used for any other purpose. Specifically, server implementations MUST NOT compare the identities given this TLV to later identities given as part of the Inner Methods. There is no issue with the hint(s) failing to match any subsequent identity that is used.¶

The Identity-Hint TLV MUST NOT be used for server unauthenticated provisioning. This TLV is only used as a hint for normal authentication.¶

The Identity-Hint TLV is defined as follows:¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R|         TLV Type          |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Identity Hint                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

M

0 - Optional TLV¶

R

Reserved, set to zero (0)¶

TLV Type

19 - Identity-Hint¶

Length

>=2 octets¶

4.3.1. Outer TLVs

The following table provides a guide to which TLVs may be included in the TEAP packet outside the TLS channel, in which kind of packets, and in what quantity:¶

Outer TLVs MUST be marked as optional. Vendor TLVs inside of a Vendor-Specific TLV MUST be marked as optional when included in Outer TLVs. Outer TLVs MUST NOT be included in messages after the first two TEAP messages sent by peer and EAP-server, respectively. That is, the first EAP-server-to-peer message and first peer-to-EAP-server message. If the message is fragmented, the whole set of messages is counted as one message. If Outer TLVs are included in messages after the first two TEAP messages, they MUST be ignored.¶

4.3.2. Inner TLVs

The following table provides a guide to which Inner TLVs may be encapsulated in TLS in TEAP Phase 2, in which kind of packets, and in what quantity. The messages are as follows: Request is a TEAP Request, Response is a TEAP Response, Success is a message containing a successful Result TLV, and Failure is a message containing a failed Result TLV.¶

NOTE: Vendor TLVs (included in Vendor-Specific TLVs) sent with a Result TLV MUST be marked as optional. Also, the CSR-Attributes TLV is never transmitted by the peer, and so is treated as a request in this table.¶

6.2.1. Generating the Inner Method Session Key

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 refer to the IMSK for Inner Method "j" as IMSK[j].¶

If an Inner Method supports export of an EMSK, then the IMSK SHOULD be derived from the EMSK, which is defined in [RFC5295]. The optional data parameter is not used in the derivation.¶

The above derivation is not a requirement, as some peer 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 those implementations, the use of EMSK here is not made mandatory.¶

Some EAP methods may also have the peer and server derive different EMSKs. Mandating an EMSK-based derivation there would prevent interoperability, as the Crypto-Binding TLV contents that depend on EMSK could not then be validated by either side. Those methods 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 both the peer and server have derived the same EMSK.¶

It is RECOMMENDED that for those EAP methods, implementations take the simpler approach of ignoring EMSK and always derive IMSK from MSK. This approach is less secure, as IMSK no longer cryptographically binds the Inner Method to the TLS tunnel. A better solution is to suggest that deployments of TEAP SHOULD avoid such methods.¶

The derivation of IMSK[j] from the j'th EMSK is given as follows:¶

   IMSK[j] = First 32 octets of TLS-PRF(
          EMSK[j],
          "TEAPbindkey@ietf.org",
          0x00 | 0x00 | 0x40)

Where:¶

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. 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 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. IMSK[j] is then this derived value.¶

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 been run, then both MSK and IMSK[j] are set to all zeroes (i.e., IMSK[j] = MSK = 32 octets of 0x00s).¶

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 Inner Methods that fail to generate an MSK or EMSK. These methods should only be used in conjunction with another Inner Method that does provide for MSK or EMSK generation.¶

It is also RECOMMENDED that TEAP peers order Inner Methods such that methods that generate EMSKs are performed before methods that do not generate EMSKs. Ordering Inner Methods in this manner ensures that the first Inner Method detects any on-path attackers, and any subsequent Inner Method used is therefore secure.¶

For example, Phase 2 could perform both machine authentication using EAP-TLS, followed by user authentication via the Basic Password Authentication TLVs. In that case, the use of EAP-TLS would allow an attacker to be detected before the users' password was sent.¶

However, it is possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place.¶

6.2.2. Generating S-IMCK

Once IMSK[j] has been determined, it is mixed via the TLS-PRF with the key S-IMCK[j-1] from a previous round. That mixing derives a new key IMCK[j]. This key is then used to derive both S-IMCK[j] for this round and CMK[j] for this round.¶

The derivation of S-IMCK is as follows:¶

   S-IMCK[0] = session_key_seed
   For j = 1 to n-1 do
        IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
             "Inner Methods Compound Keys",
             IMSK[j])
        S-IMCK[j] = first 40 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 handshake [RFC5246]. The value j refers to a corresponding Inner 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 connection is established and before any inner methods are run.¶

In practice, the requirement to use either MSK or EMSK means that an implementation MUST track two independent derivations of IMCK[j], one that depends on the MSK and another that depends on EMSK. That is, we have both values derived from MSK:¶

and then also values derived from EMSK:¶

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 included in the Crypto-Binding TLV from the client. If EMSK Compound MAC was included, S-IMCK[j] is taken from S-IMCK_EMSK[j]. Otherwise, S-IMCK[j] is taken from S-IMCK_MSK[j].¶

6.2.3. Choosing Inner Methods Securely

In order to further secure TEAP, implementations can take steps to increase their security by carefully ordering Inner Methods. Where multiple Inner Methods are used, implementations SHOULD choose an ordering so that the first Inner Method used is one that derives EMSK.¶

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 important in EAP, any chosen order is supported by the peer that receives this request.¶

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 request and return an Inner Method that derives EMSK. Again, since the ordering of Inner Methods is not otherwise important in EAP, any chosen order is supported by the server that receives this response. Once the more secure authentication has succeed, the server then requests the other type of authentication and the peer can respond with the chosen type of authentication.¶

Implementations can also provide configuration flags, policies, or documented recommendations that control the type of Inner Methods used or verify their order. These configurations allow implementations and administrators to control their security exposure to on-path attackers.¶

Implementations can permit administrators to configure TEAP so that the following security checks are enforced:¶

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 these suggestions are not enforced, then the TEAP session is vulnerable.¶

Most of these suggestions are not normative, as some existing implementations are known to not follow them. Instead, these suggestions are here to inform new implementors, along with administrators, of the issues surrounding this subject.¶

6.2.4. Managing and Computing Crypto-Binding

After an Inner Method has been completed successfully and the inner 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 Crypto-Binding TLV.¶

The peer verifies the Crypto-Binding TLV by applying the rules defined in Section 4.2.13. If verification passes, the peer responds with its own Crypto-Binding TLV, which the server in turn verifies. If at any point verification fails, the party that makes this determination terminates the session.¶

The Crypto-Binding TLV is normally sent in conjunction with other TLVs that indicate intermediate or final results or that begin negotiation of a new Inner Method. This negotiation does not otherwise affect the Crypto-Binding TLV.¶

While Section 4.2.13 defines that the Compound MAC fields exist in the Crypto-Binding TLV, it does not describe the derivation and management of those fields. This derivation is complex and is therefore located here along with the other key derivations.¶

The following text defines how the server and peer compute, send, and then verify the Compound MAC fields Crypto-Binding TLV. Depending on the Inner Method and site policy, the Crypto-Binding TLV can contain 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 session follows its own set of procedures to compute and verify the Compound MAC fields.¶

The determination of the contents of the Crypto-Binding TLV is done separately for each Inner Method. If at any point the verification of a Compound MAC fails, the determining party returns a fatal error as described in Section 3.9.3.¶

We presume that each peer and server have site policies that may or may not require the use of the MSK Compound MAC and/or the EMSK Compound MAC. These policies can be enforced globally for all Inner Methods, or they can be enforced separately on each Inner Method. These policies could be enabled automatically when the EAP method is known to always generate an EMSK and could otherwise be configurable.¶

The server initiates crypto-binding by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then sending it to the peer.¶

Then, the steps taken by the server are as follows:¶

The peer verifies the Crypto-Binding TLV it receives from the server. It then replies with its own crypto-binding response by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then 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 Crypto-Binding TLV and sent to the server.¶

Then, the steps taken by the peer are as follows:¶

The peer creates a crypto-binding response by determining which Compound MAC(s) to use, computing their value(s), placing the resulting Compound MAC(s) into the Crypto-Binding TLV, and then sending it to the server.¶

The steps taken by the peer are then as follows.¶

The server processes the response from the peer via the following steps:¶

Once the above steps have concluded, the server either continues authentication with another Inner Method or it returns a Result TLV.¶

6.2.5. Unintended Side Effects

In earlier drafts of this document, the descriptions of the key derivations had issues that were only discovered after TEAP had been widely implemented. These issues need to be documented in order to enable interoperable implementations.¶

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 IMCK_EMSK[j] from it. The choice of multiple implementations was then to simply define:¶

    IMCK_EMSK[j] = IMCK_EMSK[j - 1]

This definition can be trivially implemented by simply keeping a cached copy of IMCK_EMSK in a data structure. If EMSK is available, IMCK_EMCK is updated from it via the TLS-PRF function as defined above. If EMSK is not available, then the IMCK_EMSK value is unmodified.¶

This behavior was not explicitly anticipated by earlier drafts of this document. It instead appears to be an accidental outcome of implementing the derivations above with the limitation of a missing EMSK. This behavior is explicitly called out here in the interest of fully documenting TEAP.¶

Another unintended consequence is in the calculation of the Crypto-Binding TLV. That TLV includes compound MACs that depend on the MSK and EMSK of the current authentication method. Where the current method does not provide an EMSK, the Crypto-Binding TLV does not include a compound MAC that depends on the EMSK. Where the current method does not provide an MSK, the Crypto-Binding TLV includes a compound MAC that depends on a special "all zero" IMSK as discussed earlier.¶

The result of this definition is that the final Crypto-Binding TLV in an inner TEAP exchange may not include a compound MAC that depends on EMSK, even if earlier EAP methods in the Phase 2 exchange provided an EMSK. This result likely has negative effects on security, though the full impact is unknown at the time of writing this document.¶

These design flaws have nonetheless resulted in multiple interoperable implementations. We note that these implementations 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 not likely to work by design. For this document, we can only ensure that the behavior of TEAPv1 is fully documented, even if that behavior was an unintended consequence of unclear text in earlier versions of this specification.¶

We expect that these issues will be addressed in a future revision of TEAP.¶

8.4.1. User Identity Protection and Verification

The initial identity request response exchange is sent in cleartext outside the protection of TEAP. Typically, the NAI [RFC7542] in the identity response is useful only for the realm of information that is used to route the authentication requests to the right EAP server. This means that the identity response may contain an anonymous identity and just contain realm information. In other cases, the identity exchange may be eliminated altogether if there are other means for establishing the destination realm of the request. In no case should an intermediary place any trust in the identity information in the identity response since it is unauthenticated and may not have any relevance to the authenticated identity. TEAP implementations should not attempt to compare any identity disclosed in the initial cleartext EAP Identity response packet with those Identities authenticated in Phase 2.¶

When the server is authenticated, identity request/response exchanges sent after the TEAP tunnel is established are protected from modification and eavesdropping by attackers. For server unauthenticated provisioning, the outer TLS session provides little security, and the provisioning method must provide this protection instead.¶

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 signal the type of identity which that client certificate is for. 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, then the EAP server MUST reject the session.¶

Issues related to confidentiality of a client certificate are discussed above in Section 3.4.1¶

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 as a protected success indication as discussed in [RFC9190], Section 2.1.1¶

8.5.1. Protection Against On-Path Attacks

TEAP provides protection from on-path attacks in a few ways:¶

TEAP crypto-binding does not guarantee protection from on-path attacks if the client allows a connection to an untrusted server, such as in the case where the client does not properly validate the server's certificate. If the TLS cipher suite derives the master secret solely from the contribution of secret data from one side of the conversation (such as cipher suites based on RSA key transport), then an attacker who can convince the client to connect and engage in authentication can impersonate the client to another server even if a strong Inner Method is executed within the tunnel. If the TLS cipher suite derives the master secret from the contribution of secrets from both sides of the conversation (such as in cipher suites based on Diffie-Hellman), then crypto-binding can detect an attacker in the conversation if a strong Inner Method is used.¶

TEAP crypto-binding does not guarantee protection from on-path attacks when the client does not verify the server, and the Inner Method does not produce an EMSK. The only way to close this vulnerability is to define TEAPv2, which would then have different crypto-binding derivations.¶