Network Working Group B. Aboba
Requests for Commments: 2716 D. Simon
Category: Experimental Microsoft
PPP EAP TLS Authentication Protocol
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society (1999). All Rights Reserved.
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
also defines an extensible Link Control Protocol (LCP), which can be
used to negotiate authentication methods, as well as an Encryption
Control Protocol (ECP), used to negotiate data encryption over PPP
links, and a Compression Control Protocol (CCP), used to negotiate
compression methods. The Extensible Authentication Protocol (EAP) is
a PPP extension that provides support for additional authentication
methods within PPP.
Transport Level Security (TLS) provides for mutual authentication,
integrity-protected ciphersuite negotiation and key exchange between
two endpoints. This document describes how EAP-TLS, which includes
support for fragmentation and reassembly, provides for these TLS
mechanisms within EAP.
The Extensible Authentication Protocol (EAP), described in ,
provides a standard mechanism for support of additional
authentication methods within PPP. Through the use of EAP, support
for a number of authentication schemes may be added, including smart
cards, Kerberos, Public Key, One Time Passwords, and others. To date
however, EAP methods such as  have focussed on authenticating a
client to a server.
Aboba & Simon Experimental [Page 1]RFC 2716 PPP EAP TLS Authentication Protocol October 1999
However, it may be desirable to support mutual authentication, and
since PPP encryption protocols such as  and  assume existence
of a session key, it is useful to have a mechanism for session key
establishment. Since design of secure key management protocols is
non-trivial, it is desirable to avoid creating new mechanisms for
this. The EAP protocol described in this document allows a PPP peer
to take advantage of the protected ciphersuite negotiation, mutual
authentication and key management capabilities of the TLS protocol,
described in .
2.1. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in .
3. Protocol overview3.1. Overview of the EAP-TLS conversation
As described in , the EAP-TLS conversation will typically begin
with the authenticator and the peer negotiating EAP. The
authenticator will then typically send an EAP-Request/Identity packet
to the peer, and the peer will respond with an EAP-Response/Identity
packet to the authenticator, containing the peer's userId.
From this point forward, while nominally the EAP conversation occurs
between the PPP authenticator and the peer, the authenticator MAY act
as a passthrough device, with the EAP packets received from the peer
being encapsulated for transmission to a RADIUS server or backend
security server. In the discussion that follows, we will use the term
"EAP server" to denote the ultimate endpoint conversing with the
Once having received the peer's Identity, the EAP server MUST respond
with an EAP-TLS/Start packet, which is an EAP-Request packet with
EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS
conversation will then begin, with the peer sending an EAP-Response
packet with EAP-Type=EAP-TLS. The data field of that packet will
encapsulate one or more TLS records in TLS record layer format,
containing a TLS client_hello handshake message. The current cipher
spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null
compression. This current cipher spec remains the same until the
change_cipher_spec message signals that subsequent records will have
the negotiated attributes for the remainder of the handshake.
Aboba & Simon Experimental [Page 2]