Rechnernetze

EAP

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.

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.

silently discard

This means the implementation discards the packet without

further processing. The implementation SHOULD provide the

capability of logging the error, including the contents of

the silently discarded packet, and SHOULD record the event

in a statistics counter.

displayable message

This is interpreted to be a human readable string of

characters, and MUST NOT affect operation of the protocol.

The message encoding MUST follow the UTF-8 transformation

format [5].

2. PPP Extensible Authentication Protocol (EAP)

The PPP Extensible Authentication Protocol (EAP) is a general

protocol for PPP authentication which supports multiple

authentication mechanisms. EAP does not select a specific

authentication mechanism at Link Control Phase, but rather postpones

this until the Authentication Phase. This allows the authenticator

to request more information before determining the specific

authentication mechanism. This also permits the use of a "back-end"

server which actually implements the various mechanisms while the PPP

authenticator merely passes through the authentication exchange.

1. After the Link Establishment phase is complete, the authenticator

sends one or more Requests to authenticate the peer. The Request

has a type field to indicate what is being requested. Examples of

Request types include Identity, MD5-challenge, One-Time

Passwords, Generic Token Card, etc. The MD5-challenge type

corresponds closely to the CHAP authentication protocol.

Typically, the authenticator will send an initial Identity Request

followed by one or more Requests for authentication information.

However, an initial Identity Request is not required, and MAY be

bypassed in cases where the identity is presumed (leased lines,

dedicated dial-ups, etc.).

Blunk & Vollbrecht Standards Track [Page 3]

RFC 2284 EAP March 1998

2. The peer sends a Response packet in reply to each Request. As

with the Request packet, the Response packet contains a type field

which corresponds to the type field of the Request.

3. The authenticator ends the authentication phase with a Success or

Failure packet.

Advantages

The EAP protocol can support multiple authentication mechanisms

without having to pre-negotiate a particular one during LCP Phase.

Certain devices (e.g. a NAS) do not necessarily have to understand

each request type and may be able to simply act as a passthrough

agent for a "back-end" server on a host. The device only need look

for the success/failure code to terminate the authentication phase.

Disadvantages

EAP does require the addition of a new authentication type to LCP and

thus PPP implementations will need to be modified to use it. It also

strays from the previous PPP authentication model of negotiating a

specific authentication mechanism during LCP.

2.1. Configuration Option Format

A summary of the Authentication-Protocol Configuration Option format

to negotiate the EAP Authentication Protocol is shown below. The

fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Length | Authentication-Protocol |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Length

Authentication-Protocol

C227 (Hex) for PPP Extensible Authentication Protocol (EAP)

Blunk & Vollbrecht Standards Track [Page 4]

RFC 2284 EAP March 1998

2.2. Packet Format

Exactly one PPP EAP packet is encapsulated in the Information field

of a PPP Data Link Layer frame where the protocol field indicates

type hex C227 (PPP EAP). A summary of the EAP packet format is shown

below. The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code | Identifier | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Data ...

+-+-+-+-+

Code

The Code field is one octet and identifies the type of EAP packet.

EAP Codes are assigned as follows:

1 Request

2 Response

3 Success

4 Failure

Identifier

The Identifier field is one octet and aids in matching

responses with requests.

Length

The Length field is two octets and indicates the length of the

EAP packet including the Code, Identifier, Length and Data

fields. Octets outside the range of the Length field should

be treated as Data Link Layer padding and should be ignored on

reception.

Data

The Data field is zero or more octets. The format of the Data

field is determined by the Code field.

Blunk & Vollbrecht Standards Track [Page 5]

RFC 2284 EAP March 1998

2.2.1. Request and Response

Description

The Request packet is sent by the authenticator to the peer. Each

Request has a type field which serves to indicate what is being

requested. The authenticator MUST transmit an EAP packet with the

Code field set to 1 (Request). Additional Request packets MUST be

sent until a valid Response packet is received, or an optional

retry counter expires. Retransmitted Requests MUST be sent with

the same Identifier value in order to distinguish them from new

Requests. The contents of the data field is dependent on the

Request type. The peer MUST send a Response packet in reply to a

Request packet. Responses MUST only be sent in reply to a

received Request and never retransmitted on a timer. The

Identifier field of the Response MUST match that of the Request.

Implementation Note: Because the authentication process will

often involve user input, some care must be taken when deciding

upon retransmission strategies and authentication timeouts. It

is suggested a retransmission timer of 6 seconds with a maximum

of 10 retransmissions be used as default. One may wish to make

these timeouts longer in certain cases (e.g. where Token Cards

are involved). Additionally, the peer must be prepared to

silently discard received retransmissions while waiting for

user input.

A summary of the Request and Response packet format is shown below.

The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code | Identifier | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Type | Type-Data ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

1 for Request;

2 for Response.

Blunk & Vollbrecht Standards Track [Page 6]

RFC 2284 EAP March 1998

Identifier

The Identifier field is one octet. The Identifier field MUST be

the same if a Request packet is retransmitted due to a timeout

while waiting for a Response. Any new (non-retransmission)

Requests MUST modify the Identifier field. If a peer recieves a

duplicate Request for which it has already sent a Response, it

MUST resend it's Response. If a peer receives a duplicate Request

before it has sent a Response to the initial Request (i.e. it's

waiting for user input), it MUST silently discard the duplicate

Request.

Length

The Length field is two octets and indicates the length of the EAP

packet including the Code, Identifier, Length, Type, and Type-Data

fields. Octets outside the range of the Length field should be

treated as Data Link Layer padding and should be ignored on

reception.

Type

The Type field is one octet. This field indicates the Type of

Request or Response. Only one Type MUST be specified per EAP

Request or Response. Normally, the Type field of the Response

will be the same as the Type of the Request. However, there is

also a Nak Response Type for indicating that a Request type is

unacceptable to the peer. When sending a Nak in response to a

Request, the peer MAY indicate an alternative desired

authentication Type which it supports. An initial specification of

Types follows in a later section of this document.

Type-Data

The Type-Data field varies with the Type of Request and the

associated Response.

2.2.2. Success and Failure

Description

The Success packet is sent by the authenticator to the peer to

acknowledge successful authentication. The authenticator MUST

transmit an EAP packet with the Code field set to 3 (Success).

If the authenticator cannot authenticate the peer (unacceptable

Responses to one or more Requests) then the implementation MUST

transmit an EAP packet with the Code field set to 4 (Failure). An

Blunk & Vollbrecht Standards Track [Page 7]

RFC 2284 EAP March 1998

authenticator MAY wish to issue multiple Requests before sending a

Failure response in order to allow for human typing mistakes.

Implementation Note: Because the Success and Failure packets

are not acknowledged, they may be potentially lost. A peer

MUST allow for this circumstance. The peer can use a Network

Protocol packet as an alternative indication of Success.

Likewise, the receipt of a LCP Terminate-Request can be taken

as a Failure.

A summary of the Success and Failure packet format is shown below.

The fields are transmitted from left to right.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Code | Identifier | Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

3 for Success;

4 for Failure.

Identifier

The Identifier field is one octet and aids in matching replies to

Responses. The Identifier field MUST match the Indentifier field

of the Response packet that it is sent in response to.

Length

3. Initial EAP Request/Response Types

This section defines the initial set of EAP Types used in

Request/Response exchanges. More Types may be defined in follow-on

documents. The Type field is one octet and identifies the structure

of an EAP Request or Response packet. The first 3 Types are

considered special case Types. The remaining Types define

authentication exchanges. The Nak Type is valid only for Response

packets, it MUST NOT be sent in a Request. The Nak Type MUST only be

Blunk & Vollbrecht Standards Track [Page 8]

RFC 2284 EAP March 1998

sent in repsonse to a Request which uses an authentication Type code.

All EAP implementatins MUST support Types 1-4. These Types, as well

as types 5 and 6, are defined in this document. Follow-on RFCs will

define additional EAP Types.

1 Identity

2 Notification

3 Nak (Response only)

4 MD5-Challenge

5 One-Time Password (OTP) (RFC 1938)

6 Generic Token Card

3.1. Identity

Description

The Identity Type is used to query the identity of the peer.

Generally, the authenticator will issue this as the initial

Request. An optional displayable message MAY be included to

prompt the peer in the case where there expectation of interaction

with a user. A Response MUST be sent to this Request with a Type

of 1 (Identity).

Implementation Note: The peer MAY obtain the Identity via user

input. It is suggested that the authenticator retry the

Indentity Request in the case of an invalid Identity or

authentication failure to allow for potential typos on the part

of the user. It is suggested that the Identity Request be

retried a minimum of 3 times before terminating the

authentication phase with a Failure reply. The Notification

Request MAY be used to indicate an invalid authentication

attempt prior to transmitting a new Identity Request

(optionally, the failure MAY be indicated within the message of

the new Identity Request itself).

Type

Type-Data

This field MAY contain a displayable message in the Request. The

Response uses this field to return the Identity. If the Identity

is unknown, this field should be zero bytes in length. The field

MUST NOT be null terminated. The length of this field is derived

from the Length field of the Request/Response packet and hence a

null is not required.

Blunk & Vollbrecht Standards Track [Page 9]

RFC 2284 EAP March 1998

3.2. Notification

Description

The Notification Type is optionally used to convey a displayable

message from the authenticator to the peer. The peer SHOULD

display this message to the user or log it if it cannot be

displayed. It is intended to provide an acknowledged notification

of some imperative nature. Examples include a password with an

expiration time that is about to expire, an OTP sequence integer

which is nearing 0, an authentication failure warning, etc. In

most circumstances, notification should not be required.

Type

Type-Data

The Type-Data field in the Request contains a displayable message

greater than zero octets in length. The length of the message is

determined by Length field of the Request packet. The message

MUST not be null terminated. A Response MUST be sent in reply to

the Request with a Type field of 2 (Notification). The Type-Data

field of the Response is zero octets in length. The Response

should be sent immediately (independent of how the message is

displayed or logged).

3.3. Nak

Description

The Nak Type is valid only in Response messages. It is sent in

reply to a Request where the desired authentication Type is

unacceptable. Authentication Types are numbered 4 and above.

The Response contains the authentication Type desired by the peer.

Type

Type-Data

This field MUST contain a single octet indicating the desired

authentication type.

Blunk & Vollbrecht Standards Track [Page 10]

RFC 2284 EAP March 1998

3.4. MD5-Challenge

Description

The MD5-Challenge Type is analagous to the PPP CHAP protocol [3]

(with MD5 as the specified algorithm). The PPP Challenge

Handshake Authentication Protocol RFC [3] should be referred to

for further implementation specifics. The Request contains a

"challenge" message to the peer. A Repsonse MUST be sent in reply

to the Request. The Response MAY be either of Type 4 (MD5-

Challenge) or Type 3 (Nak). The Nak reply indicates the peer's

desired authentication mechanism Type. All EAP implementations

MUST support the MD5-Challenge mechanism.

Type

Type-Data

The contents of the Type-Data field is summarized below. For

reference on the use of this fields see the PPP Challenge

Handshake Authentication Protocol [3].

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Value-Size | Value ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Name ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

3.5. One-Time Password (OTP)

Description

The One-Time Password system is defined in "A One-Time Password

System" [4]. The Request contains a displayable message

containing an OTP challenge. A Repsonse MUST be sent in reply to

the Request. The Response MUST be of Type 5 (OTP) or Type 3

(Nak). The Nak reply indicates the peer's desired authentication

mechanism Type.

Type

Blunk & Vollbrecht Standards Track [Page 11]

RFC 2284 EAP March 1998

Type-Data

The Type-Data field contains the OTP "challenge" as a displayable

message in the Request. In the Response, this field is used for

the 6 words from the OTP dictionary [4]. The messages MUST not be

null terminated. The length of the field is derived from the

Length field of the Request/Reply packet.

3.6. Generic Token Card

Description

The Generic Token Card Type is defined for use with various Token

Card implementations which require user input. The Request

contains an ASCII text message and the Reply contains the Token

Card information necessary for authentication. Typically, this

would be information read by a user from the Token card device and

entered as ASCII text.

Type

Type-Data

The Type-Data field in the Request contains a displayable message

greater than zero octets in length. The length of the message is

determined by Length field of the Request packet. The message

MUST not be null terminated. A Response MUST be sent in reply to

the Request with a Type field of 6 (Generic Token Card). The

Response contains data from the Token Card required for

authentication. The length is of the data is determined by the

Length field of the Response packet.

Security Considerations

Security issues are the primary topic of this RFC.

The interaction of the authentication protocols within PPP are highly

implementation dependent.

For example, upon failure of authentication, some implementations do

not terminate the link. Instead, the implementation limits the kind

of traffic in the Network-Layer Protocols to a filtered subset, which

in turn allows the user opportunity to update secrets or send mail to

the network administrator indicating a problem.

Blunk & Vollbrecht Standards Track [Page 12]

RFC 2284 EAP March 1998

There is no provision for retries of failed authentication. However,

the LCP state machine can renegotiate the authentication protocol at

any time, thus allowing a new attempt. It is recommended that any

counters used for authentication failure not be reset until after

successful authentication, or subsequent termination of the failed

link.

There is no requirement that authentication be full duplex or that

the same protocol be used in both directions. It is perfectly

acceptable for different protocols to be used in each direction.

This will, of course, depend on the specific protocols negotiated.

In practice, within or associated with each PPP server, it is not

anticipated that a particular named user would be authenticated by

multiple methods. This would make the user vulnerable to attacks

which negotiate the least secure method from among a set (such as PAP

rather than EAP). Instead, for each named user there should be an

indication of exactly one method used to authenticate that user name.

If a user needs to make use of different authentication methods under

different circumstances, then distinct identities SHOULD be employed,

each of which identifies exactly one authentication method.

References

[1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,

RFC 1661, July 1994.

[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,

RFC 1700, October 1994.

[3] Simpson, W., "PPP Challenge Handshake Authentication Protocol

(CHAP)", RFC 1994, August 1996.

[4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938,

May 1996.

[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO

10646", RFC 2044, October 1996.

[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement

Levels", RFC 2119, March 1997.

Blunk & Vollbrecht Standards Track [Page 13]

RFC 2284 EAP March 1998

Acknowledgments

This protocol derives much of its inspiration from Dave Carrel's AHA

draft as well as the PPP CHAP protocol [3]. Bill Simpson provided

much of the boilerplate used throughout this document. Al Rubens

(Merit) also provided valuable feedback.

Chair's Address

The working group can be contacted via the current chair:

Karl F. Fox

Ascend Communications, Inc.

655 Metro Place South, Suite 370

Dublin, Ohio 43017

EMail: karl@ascend.com

Phone: +1 614 760 4041

Fax: +1 614 760 4050

Authors' Addresses

Larry J. Blunk

Merit Network, Inc.

4251 Plymouth Rd., Suite C

Ann Arbor, MI 48105

EMail: ljb@merit.edu

Phone: 734-763-6056

FAX: 734-647-3185

John R. Vollbrecht

Merit Network, Inc.

4251 Plymouth Rd., Suite C

Ann Arbor, MI 48105

EMail: jrv@merit.edu

Phone: +1-313-763-1206

FAX: +1-734-647-3185

Blunk & Vollbrecht Standards Track [Page 14]

RFC 2284 EAP March 1998

Full Copyright Statement

This document and translations of it may be copied and furnished to

others, and derivative works that comment on or otherwise explain it

or assist in its implementation may be prepared, copied, published

and distributed, in whole or in part, without restriction of any

kind, provided that the above copyright notice and this paragraph are

included on all such copies and derivative works. However, this

document itself may not be modified in any way, such as by removing

the copyright notice or references to the Internet Society or other

Internet organizations, except as needed for the purpose of

developing Internet standards in which case the procedures for

copyrights defined in the Internet Standards process must be

followed, or as required to translate it into languages other than

English.

The limited permissions granted above are perpetual and will not be

revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an

"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Blunk & Vollbrecht Standards Track [Page 15]