UpdatedINFORMATIONALIETF stream

RFC 5281: Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)

Still current, but amended. Parts of this document are changed or extended by RFC 8996, RFC 9427. Read both.

In plain English — editorial summary, not part of the RFC

EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community.

Document record

Document ID
RFC5281
Published
August 2008
Authors
P. Funk; S. Blake-Wilson
Status
INFORMATIONAL
Stream
IETF
Area
Pages
51
Also known as
Updated by:
RFC 8996, RFC 9427

Topics

Referenced by

2 later RFCs formally update or obsolete part of this document.

Related documents

Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.

Also filed under

About this page

The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.

Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.

Data sources · Editorial policy · Report a correction · What is an RFC?

canonical URL: /rfc/5281-extensible-authentication-protocol-tunneled-transport-layer-security-authenticat