PPP Extensible Authentication Protocol (EAP)
RFC 2284
Document | Type |
RFC - Proposed Standard
(March 1998; No errata)
Obsoleted by RFC 3748
Updated by RFC 2484
|
|
---|---|---|---|
Authors | John Vollbrecht , Larry Blunk | ||
Last updated | 2013-03-02 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2284 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group L. Blunk Request for Comments: 2284 J. Vollbrecht Category: Standards Track Merit Network, Inc. March 1998 PPP Extensible Authentication Protocol (EAP) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol, which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. This document defines the PPP Extensible Authentication Protocol. Table of Contents 1. Introduction .......................................... 2 1.1 Specification of Requirements ................... 2 1.2 Terminology ..................................... 2 2. PPP Extensible Authentication Protocol (EAP) .......... 3 2.1 Configuration Option Format ..................... 4 2.2 Packet Format ................................... 6 2.2.1 Request and Response ............................ 6 2.2.2 Success and Failure ............................. 7 3. Initial EAP Request/Response Types .................... 8 3.1 Identity ........................................ 9 3.2 Notification .................................... 10 3.3 Nak ............................................. 10 Blunk & Vollbrecht Standards Track [Page 1] RFC 2284 EAP March 1998 3.4 MD5-Challenge ................................... 11 3.5 One-Time Password (OTP) ......................... 11 3.6 Generic Token Card .............................. 12 REFERENCES ................................................... 13 ACKNOWLEDGEMENTS ............................................. 14 CHAIR'S ADDRESS .............................................. 14 AUTHORS' ADDRESSES ........................................... 14 Full Copyright Statement ..................................... 15 1. Introduction In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure the data link during Link Establishment phase. After the link has been established, PPP provides for an optional Authentication phase before proceeding to the Network-Layer Protocol phase. By default, authentication is not mandatory. If authentication of the link is desired, an implementation MUST specify the Authentication-Protocol Configuration Option during Link Establishment phase. These authentication protocols are intended for use primarily by hosts and routers that connect to a PPP network server via switched circuits or dial-up lines, but might be applied to dedicated links as well. The server can use the identification of the connecting host or router in the selection of options for network layer negotiations. This document defines the PPP Extensible Authentication Protocol (EAP). The Link Establishment and Authentication phases, and the Authentication-Protocol Configuration Option, are defined in The Point-to-Point Protocol (PPP) [1]. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. 1.2. Terminology This document frequently uses the following terms: Blunk & Vollbrecht Standards Track [Page 2] RFC 2284 EAP March 1998 authenticator The end of the link requiring the authentication. The authenticator specifies the authentication protocol to be used in the Configure-Request during Link Establishment phase. peer The other end of the point-to-point link; the end which is being authenticated by the authenticator.Show full document text