PPP EAP TLS Authentication Protocol
RFC 2716

Type RFC - Experimental (October 1999; No errata)
Obsoleted by RFC 5216
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
WG state (None)
Document shepherd No shepherd assigned
IESG state RFC 2716 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                            B. Aboba
Requests for Commments: 2716                                     D. Simon
Category: Experimental                                          Microsoft
                                                             October 1999

                  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 Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

1.  Abstract

   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.

2.  Introduction

   The Extensible Authentication Protocol (EAP), described in [5],
   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 [6] 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 [9] and [10] 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 [12].

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 [11].

3.  Protocol overview

3.1.  Overview of the EAP-TLS conversation

   As described in [5], 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]
Show full document text