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 send a no_renegotiation alert to the server indicating that it wants to continue with TEAP Phase 2 instead. Assuming that the peer permits renegotiation by sending a client_hello, then the server will respond with server_hello, certificate, and certificate_request messages. The peer replies with certificate, client_key_exchange, and certificate_verify messages. Since this renegotiation occurs within the encrypted TLS channel, it does not reveal client certificate details. It is possible to perform certificate authentication using 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.4¶

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 state being stored on the client side using the TLS SessionTicket extension techniques described in [RFC5077] and [RFC9190].¶

3.6.1. 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 is run 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 and similarly on success MUST accompany the TLV with it's own Crypto-Binding TLV. The Crypto-Binding TLV is further discussed in Section 4.2.13 and Section 5.3. The Intermediate-Result TLVs can be included with other TLVs which 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).¶

If a particular inner method succeeds, the server MUST 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.¶

3.6.2. Inner Password Authentication

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

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 users password, and separately a one-time password such as Time-Based One-Time Passwords (TOTP) [RFC6238].¶

Implementations MUST limit the number of rounds 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 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 Section 4.2.13 and Section 5.3.¶

The Intermediate-Result TLVs can be included with other TLVs which 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.3. EAP-MSCHAPv2

If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST-MSCHAPv2 variant defined in Section 3.2.3 of [RFC5422] MUST be used, 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 EAP-MSCHAPv2 MSK are swapped when it is used as the Inner Method Session Keys (IMSK) for TEAP.¶

3.6.4. Limitations on inner methods

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 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 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 a one-time token. However, MD5-Challenge has no such safety, and TEAP implementations MUST NOT permit the use of MD5-Challenge or other inner methods which fail to perform crypto-binding of the inner method to the TLS session.¶

Similarly, EAP-OTP and EAP-GTC MUST NOT be used for inner EAP authentication. They offer no benefit over the basic password authentication defined in Section 3.6.2.¶

Implementations SHOULD limit the permitted inner EAP methods to a small set such as EAP-TLS, EAP-MSCHAPv2, and perhaps EAP-pwd. There are few reasons for allowing all possible EAP methods to be used in Phase 2.¶

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 which 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 which can tunnel other EAP methods. As a result, this document updates [RFC9427].¶

EAP-TLS is permitted in Phase 2 for two use-cases. The first 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, the client certificate is sent in Phase 1, instead of doing EAP-TLS in Phase 2.¶

The second use-case for EAP-TLS in Phase 2 is where both the user and machine use client certificates for authentication. Since TLS only permits 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 clear-text password exchanges unnecessary. The updates to EAP-pwd in [RFC8146] permit it to be used with databases which store passwords in "salted" form, which greatly increases security.¶

Where the inner method does not provide an MSK or 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.¶

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

1. If Outer TLVs are invalid or contain unknown values, they will be ignored.¶
2. The entire TEAP packet will be ignored if other fields (version, length, flags, etc.) are inconsistent with this specification.¶

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, and 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 use 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 those 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 containing using the most descriptive error code possible.¶

  If there is no error code which 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 inner method instead or to 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 CertificateRequest [RFC2986] encoded into the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a Simple PKI Response using a PKCS#7 [RFC2315] degenerate (i.e. unsigned) "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 authenticated TEAP peer is in possession of the private key used to sign the certification request.¶

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 Certification Authority (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. Alternatively, the supplied information could contain private data which should not be sent over a TLS 1.2 connection where that data would be exposed.¶

It is RECOMMENDED that systems provisioning these certificates validate that the CSR both contains the expected data, and also that is does not contain unexpected data. For example, a CA could refuse to issue the certificate if the CSR contained unknown fields, or a known field contained an unexpected value.¶

We note that there is no requirement for a CA to sign any and all CSRs which are presented to it. The CA can refuse a particular CSR for any reasons, including local site policy.¶

Once an EAP peer receives the signed certificate, that certificate could potentially be 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 with any other protocol which uses TLS. One method of enforcing this restriction is to have different CAs (or different intermediate CAs) which issue certificates for different uses. For example, TLS-based EAP methods could share one CA, and HTTPS servers could use a different CA. The different protocols could therefore be configured to validate client certificates only from their preferred CA.¶

Another method of limiting the uses of a certificate is to provision it with an appropriate value for the Extended Key Usage 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 which 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] Section 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 which 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 didn't initiate the channel-binding request and the peer still wants to send the channel-binding information to the server, it can do that by using the Request-Action TLV along with the Channel-Binding TLV. The peer MUST only send channel-binding information after it has successfully authenticated the server and established the protected tunnel.¶

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 which is not of the correct format, the TLV MUST be discarded. It is generally useful to log an error or debugging message which indicates which TLV had an issue, and what the problem is. However, TLVs which 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. The Identity-Type TLV request MUST come with an EAP-Payload TLV or Basic-Password-Auth-Req TLV. If the EAP peer does have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the requested type. If the Identity-Type field does not contain one of the known values or if the EAP peer does not have an identity corresponding to the identity type requested, then the peer SHOULD respond with an Identity-Type TLV with the one of available identity types. If the server receives an identity type in the response that does not match the requested type, then the peer does not possess the requested credential type, and the server SHOULD proceed with authentication for the credential type proposed by the peer, proceed with requesting another credential type, or simply apply the network policy based on the configured policy, e.g., sending Result TLV with Failure.¶

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 Section 3.6.5 and Section 3.9.3 A Result TLV indicating failure MUST NOT be accompanied by the following TLVs: NAK, EAP-Payload TLV, or Crypto-Binding TLV. The Result TLV is defined as follows:¶

 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¶

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 other side negotiates additional inner methods or process TLVs which 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.¶

  After processing the TLVs or inner method in the request, another round of Result TLV exchange would 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 has 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 piggybacking an EAP request or response with other TLVs, the EAP-Payload TLV is defined, which includes an encapsulated EAP packet and a list of optional TLVs. The optional TLVs are provided for future extensibility to provide hints about the current EAP authentication. Only one EAP-Payload TLV is allowed in a message. The EAP-Payload TLV is defined as follows:¶

 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 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 which 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 [RFC9190] Section 2.1.2 and Section 2.1.3. As such, the PAC TLV has been deprecated.¶

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

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

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

• The Crypto-Binding TLV version is supported.¶
• The MAC verifies correctly.¶
• The received version in the Crypto-Binding TLV matches the version sent by the receiver during the EAP version negotiation.¶
• The subtype is set to the correct value.¶

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¶

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 this version of TEAP, 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.¶

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¶

Sub-Type¶

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

  • 0 Binding Request¶

    1 Binding Response¶

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 5.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 5.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 Negative Acknowledgment (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 [I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes TLV. Peers MAY ignore the contents of the TLV if they are unable to 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 which can 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 which 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 which is appropriate for that identity.¶

The peer SHOULD send an Identity-Hint TLV for each Identity-Type which is available to it. For example, if the peer can do both 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 is 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 which is used.¶

The Identity-Hint TLV MUST NOT be used for Server Unauthenticated Provisioning. This TLV is only used as a hint for normal authentication.¶

The Identity-Hint TLV is defined as follows:¶

 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, which kind of packets, and in what quantity:¶

Request  Response    Success   Failure   TLVs
0-1      0           0         0         Authority-ID
0-1      0-1         0         0         Identity-Type
0+       0+          0         0         Vendor-Specific

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

Request  Response    Success   Failure   TLVs
0-1      0-1         0         0         Identity-Type
0-1      0-1         1         1         Result
0+       0+          0         0         NAK
0+       0+          0+        0+        Error
0-1      0-1         0         0         Channel-Binding
0+       0+          0+        0+        Vendor-Specific
0+       0+          0+        0+        Request-Action
0-1      0-1         0         0         EAP-Payload
0-1      0-1         0-1       0-1       Intermediate-Result
0-1      0-1         0-1       0-1       Crypto-Binding
0-1      0           0         0         Basic-Password-Auth-Req
0        0-1         0         0         Basic-Password-Auth-Resp
0-1      0           0-1       0         PKCS#7
0        0-1         0         0         PKCS#10
0-1      0-1         0-1       0         Trusted-Server-Root
0-1      0           0         0         CSR-Attributes TLV
0        0+          0         0         Identity-Hint 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.¶

7.4.1. User Identity Protection and Verification

The initial identity request response exchange is sent in cleartext outside the protection of TEAP. Typically, the Network Access Identifier (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 necessarily 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¶

7.5.1. Protection against On-Path Attacks

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

1. By using a certificates or a session ticket to mutually authenticate the peer and server during TEAP authentication Phase 1 establishment of a secure TLS tunnel.¶
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 the crypto-binding exchange and in the generation of the key material exported by the inner method described in Section 5.¶

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