EAP-FAST's T-PRF function (RFC 4851 Section 5.5) is not used for TLS 1.3; it is replaced by the TLS 1.3 TLS-Exporter function. Similarly, EAP-FAST's PAC is deprecated in TLS 1.3 because TLS 1.3 session tickets are functionally equivalent.

tls, crypto, security

TEAP's Protected Access Credential (PAC) is deprecated for TLS 1.3 because TLS 1.3 session tickets are functionally equivalent, containing a PSK along with other data. PAC provisioning (RFC 7170 Section 3.8.1) is likewise removed from TEAP when TLS 1.3 is used.

tls, security

The outer identity SHOULD use an anonymous NAI realm (RFC 7542 Section 2.4) to preserve user privacy and enable AAA routing, while the inner identity carries the real credentials inside the TLS tunnel. Mixing inner and outer identities from different organizations is NOT RECOMMENDED as it creates management fragility and potential credential harvesting.

tls, privacy, security

The unified key derivation uses the same EAP-TLS exporter labels for all TLS-based EAP types, changing only the Type parameter to make derivation method-specific. This eliminates the need for different labels per EAP type as was done in earlier specifications.

tls, crypto, security

PEAP's crypto binding still uses HMAC-SHA1 (per [PEAP-MPPE]) for interoperability. This derivation is retained unchanged in TLS 1.3 because there are no known security issues with HMAC-SHA1 in this context, and the derived data is only visible to already-authenticated users inside the TLS tunnel.

tls, crypto, security

During resumption, the EAP server MUST send the protected success result indication (one octet of 0x00) inside the TLS tunnel. The EAP peer MUST check for this octet and fail authentication if it is not received. All EAP servers and peers MUST support resumption for all TLS-based EAP methods.

tls, security

EAP servers MUST NOT resume sessions across different EAP Types, and EAP servers MUST reject resumptions where the EAP Type value differs from the original authentication. Cross-type resumption (e.g., authenticate with EAP-TLS then resume with EAP-TTLS) is forbidden.

tls, security

For EAP-TTLS with PAP, CHAP, or MS-CHAPv1 as inner methods and TLS session tickets disabled, the EAP server MUST respond with either EAP-Success or EAP-Failure (which are unprotected and can be forged). EAP peers MUST continue running their EAP state machine until they receive one of these.

tls, security

For PEAP with TLS 1.3, the PEAP Tunnel Key (TK) MUST NOT be derived using the TLS-PRF-128 method defined in [PEAP-TK]; instead, TK MUST be derived from Key_Material as defined in Section 2.1 of this document.

tls, crypto, security

For TEAP and EAP-FAST with TLS 1.3, if a client certificate is accepted, the EAP peer MUST proceed with additional Phase 2 authentication; if there is no Phase 2 data, the EAP server MUST reject the session. Authenticating via client certificate alone in Phase 1 is forbidden.

tls, security, pkix

Implementations MUST check for application data once the TLS session is established, and this check MUST be performed before another round trip of TLS negotiation. Application data MUST NOT be sent or processed while the underlying TLS connection is still performing negotiation.

tls, security

Implementations of EAP methods that wish to use TLS 1.3 MUST follow the guidelines in RFC 9190, unless otherwise required by this document. The main difference is that other EAP method types use their own Type value instead of the EAP-TLS Type value (0x0D) in key derivation calculations.

tls, security, crypto

New TLS-based EAP methods MUST provide protected success and failure indications inside the TLS tunnel. Implementations SHOULD use EAP-GTC instead of PAP, EAP-MD5 instead of CHAP, and MS-CHAPv2/EAP-MSCHAPv2 instead of MS-CHAPv1 to gain protected result indications.

tls, security

The EAP server MUST NOT permit any session ticket to successfully resume authentication unless the inner tunnel authentication has completed successfully. Session tickets for sessions terminating in EAP Failure MUST be either invalidated or discarded.

tls, security

The inner identity MUST NOT use an anonymous NAI realm. EAP servers MUST cause authentication to fail if an EAP peer uses an anonymous inner identity. Implementations SHOULD NOT use inner identities that contain an NAI realm when a single-realm organization is sufficient.

tls, security, privacy

Unlike TLS 1.2, the TLS-Exporter function in TLS 1.3 depends on the length passed to it; implementations MUST pass the correct length instead of passing a large length and truncating the output, as truncated output will differ from correctly-length output.

tls, crypto

When a TEAP client certificate is sent outside the TLS tunnel, it MUST include Identity-Type as an outer TLV to signal whether the certificate identifies a User (1) or Machine (2), as TLS 1.3 no longer sends client certificates in the clear.

tls, security, pkix

When the inner authentication protocol indicates failure, implementations MUST fail authentication for the entire session and MUST invalidate or discard any associated session tickets. The EAP server MUST send a final EAP-Failure or EAP-Success message per the full EAP state machine.

tls, security

For EAP-TTLS with TLS 1.3, the implicit challenge for CHAP, MS-CHAP, and MS-CHAPv2 inner methods is derived as EAP-TTLS_challenge = TLS-Exporter("ttls challenge",, n), where n is 17 octets for CHAP/MS-CHAPv2 and 9 octets for MS-CHAP, with no context value.

tls, crypto, security

For TEAP with TLS 1.3, the Compound MAC is computed as MAC(CMK[n], BUFFER) using the HMAC algorithm negotiated for HKDF in the TLS key schedule (per RFC 8446 Section 7.1), replacing the earlier TLS-PRF-based computation.

tls, crypto

For TEAP with TLS 1.3, the outer MSK and EMSK are both derived with length 64 using TLS-Exporter labels "EXPORTER: Session Key Generating Function" and "EXPORTER: Extended Session Key Generating Function", respectively, with S-IMCK[n] as context.

tls, crypto, security

For TEAP with TLS 1.3, the session_key_seed is derived as TLS-Exporter("EXPORTER: teap session key seed", Type, 40), and IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", S-IMCK[j-1] || IMSK[j], 60), where S-IMCK[j] = first 40 octets and CMK[j] = last 20 octets of IMCK[j].

tls, crypto, security

Key derivation for all TLS-based EAP types uses TLS-Exporter with unified labels: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type, 128); Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Type, 64); Session-Id = Type || Method-Id; MSK = Key_Material(0,63); EMSK = Key_Material(64,127).

tls, crypto, security

The logical Type for key derivation is one octet for values less than 254. For Expanded EAP Types, it is the concatenation: Type (0xFE) || Vendor-Id (network byte order) || Vendor-Type (network byte order), as defined in RFC 3748 Section 5.7.

tls, security, crypto

This document adds five TLS Exporter Labels to the IANA "TLS Exporter Label" registry (RFC 5705): "EXPORTER: teap session key seed", "EXPORTER: Inner Methods Compound Keys", "EXPORTER: Session Key Generating Function", "EXPORTER: Extended Session Key Generating Function", and "TEAPbindkey@ietf.org". All are marked DTLS-OK=N and Recommended=Y.

tls, registry, crypto

EAP servers SHOULD track successful inner authentication completion and associate that status with issued session tickets. Where the server cannot determine authentication status from a session ticket, it MUST assume inner authentication has not completed and MUST run inner authentication before granting access.

tls, security

For full authentication, non-EAP-TLS methods do not provide protected success/failure indications at the outer TLS layer; only unprotected EAP-Success or EAP-Failure are sent. Inner methods such as EAP-TTLS with PAP/CHAP/MS-CHAPv1 have no mechanism to signal success or failure inside the tunnel.

tls, security

TLS 1.3 permits the server to send NewSessionTicket before inner authentication completes. A malicious client can obtain a ticket, abort, and attempt to resume—bypassing inner authentication. EAP servers MUST NOT assume a user is authenticated simply because a TLS session is being resumed.

tls, security