PPP Extensible Authentication Protocol (EAP)
RFC 2284
| Document | Type |
RFC - Proposed Standard
(March 1998; No errata)
Obsoleted by RFC 3748
Updated by RFC 2484
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text pdf html 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
Show full document text