RADIUS Working Group Pat Calhoun
INTERNET-DRAFT US Robotics Access Corp.
<draft-ietf-radius-eap-00.txt> Allan C. Rubens
19 February 1997 Merit Network, Inc.
Bernard Aboba
Microsoft
Extensible Authentication Protocol Support in RADIUS
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute work-
ing documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-radius-eap-00.txt>, and expires September 1, 1997. Please send
comments to the authors.
2. Abstract
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how the EAP-Message and Signature attributes
may be used for providing EAP support within RADIUS.
3. Introduction
The Extensible Authentication Protocol (EAP), described in [1], pro-
vides 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 token cards, Kerberos,
Public Key, S/Key, and others. In order to provide for support of EAP
within RADIUS, two new attributes, EAP-Message and Signature, were
introduced as RADIUS extensions in [5]. This document describes how
these new attributes may be used for providing EAP support within
RADIUS.
Calhoun, Rubens & Aboba [Page 1]
INTERNET-DRAFT 19 February 1997
The scheme described here is similar to that proposed in [2], in that
the RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets
between the NAS and a backend security server. While the conversation
between the RADIUS server and the backend security server will typi-
cally occur using a proprietary protocol developed by the backend
security server vendor, it is also possible to use RADIUS-encapsulated
EAP via the EAP-Message attribute. This has the advantage of allowing
the RADIUS server to support EAP without the need for authentication-
specific code, which can instead reside on a backend security server.
3.1. Requirements language
This specification uses the same words as [7] for defining the signif-
icance of each particular requirement. These words are:
MUST This word, or the adjectives "REQUIRED" or "SHALL", means
that the definition is an absolute requirement of the speci-
fication.
MUST NOT This phrase, or the phrase "SHALL NOT", means that the defi-
nition is an absolute prohibition of the specification.
SHOULD This word, or the adjective "RECOMMENDED", means that there
may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
SHOULD NOT
This phrase means that there may exist valid reasons in par-
ticular circumstances when the particular behavior is
acceptable or even useful, but the full implications should
be understood and the case carefully weighed before imple-
menting any behavior described with this label.
MAY This word, or the adjective "OPTIONAL", means that an item
is truly optional. One vendor may choose to include the
item because a particular marketplace requires it or because
the vendor feels that it enhances the product while another
vendor may omit the same item. An implementation which does
not include a particular option MUST be prepared to interop-
erate with another implementation which does include the
option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular
option MUST be prepared to interoperate with another imple-
mentation which does not include the option.(except, of
course, for the feature the option provides)
An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and
should not requirements for its protocols is said to be
Calhoun, Rubens & Aboba [Page 2]
INTERNET-DRAFT 19 February 1997
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements for
its protocols is said to be "conditionally compliant."
4. Protocol overview
The EAP conversation between the authenticating peer and the NAS
begins with the negotiation of EAP within LCP. Once EAP has been nego-
tiated, the NAS will typically send to the RADIUS server a RADIUS
Access-Request packet containing an EAP-Message attribute signifying
EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute
with a length of 2 (no data). The Port number and NAS Identifier are
included in the attributes issued by the NAS in the Access-Request
packet.
If the RADIUS server supports EAP, it MUST respond with an Access-
Challenge packet containing an EAP-Message attribute. The EAP-Message
attribute includes an encapsulated EAP packet which is then passed on
to the authenticating peer. The Access-Challenge typically will con-
tain an EAP-Message attribute encapsulating an EAP-Request/Identity
message, requesting the authenticating peer to identify itself. The
NAS will then respond with a RADIUS Access-Request packet containing
an EAP-Message attribute encapsulating an EAP-Response, etc. The con-
versation continues until either a RADIUS Access-Reject packet is
received (with an EAP-Message attribute encapsulating EAP-Failure)
which results in the NAS disconnecting the user, or a RADIUS Access-
Accept packet is received (with an EAP-Message attribute encapsulating
EAP-Success) successfully ending the authentication phase. Note that
if a RADIUS Access-Reject packet with an EAP-Message attribute encap-
sulating EAP-Failure is received from the RADIUS Server, the NAS
SHOULD issue an LCP Terminate Request to the authenticating peer.
The above scenario creates a situation in which the NAS never needs to
manipulate an EAP packet. An alternative may be used in situations
where an EAP-Request/Identity message will always be sent by the NAS
to the authenticating peer. This involves having the NAS send an EAP-
Request/Identity message to the authenticating peer, and forwarding
the EAP-Response/Identity packet to the RADIUS server in the EAP-Mes-
sage attribute of a RADIUS Access-Request packet. While this approach
will save a round-trip, it cannot be universally employed. There are
circumstances in which the user's identity may not be needed (such as
when authentication and accounting is handled based on the calling or
called phone number), and therefore an EAP-Request/Identity packet may
not necessarily be issued by the NAS to the authenticating peer.
Unless the NAS interprets the EAP-Response/Identity packet returned by
the authenticating peer, it will not have access to the user's iden-
tity. Therefore, it is suggested that the RADIUS Server return the
user's identity by inserting it in the User-Name attribute of subse-
quent Access-Challenge and Access-Accept packets. Without the user's
identity, accounting and billing becomes very difficult to manage.
Calhoun, Rubens & Aboba [Page 3]
INTERNET-DRAFT 19 February 1997
In cases where a backup RADIUS servers is available, were the primary
server to fail at any time during the EAP conversation, it would be
desirable for the NAS to be able to redirect the conversation to an
alternate RADIUS server. However, for the backup server to be able to
pick up the conversation, it must be provided with the state of the
EAP conversation prior to the interruption.
This can be accomplished by having the RADIUS Access-Request include
the series of EAP-Message attributes representing the previous history
of the EAP conversation. Similarly, the RADIUS Challenge returned by
the RADIUS server must also include all previous EAP-Message
attributes. The sequence number field in the EAP-Message attribute
MUST be used in order to determine which attribute is to be processed.
The attribute with the highest sequence number is the most recent
attribute.
The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain
all of the expected attributes which are currently returned in an
Access-Accept packet.
For proxied RADIUS requests there are two methods of processing. If
the domain is determined based on the DNIS the RADIUS Server may proxy
the initial RADIUS Access-Request/EAP-Start. If the domain is deter-
mined based on the user's identity, the local RADIUS Server MUST
respond with a RADIUS Access-Challenge/EAP-Identity packet. The
response from the authenticating peer MUST be proxied to the final
authentication server.
For proxied RADIUS requests, the NAS may receive an Access-Reject
packet in response to its Access-Request/EAP-Identity packet. This
would occur if the message was proxied to a RADIUS Server which does
not support the EAP-Message extension. At this point, the NAS MUST
re-open LCP with the authenticating peer and request either CHAP or
PAP as the authentication protocol. Again, such an Access-Reject
packet indicating lack of EAP capability will not contain an EAP-Mes-
sage attribute.
If the NAS is unable to negotiate EAP with the authenticating peer,
what happens next is a matter of policy. In circumstances where EAP is
required of all users accessing the NAS, the NAS MUST disconnect the
user. However, in circumstances where EAP is mandatory for some users,
and optional or not required for others, the decision cannot be made
until the user's identity is ascertained. In this case, the NAS will
negotiate another authentication method, such as CHAP, and will pass
the User-Name and CHAP-Password attributes to the RADIUS Server in an
Access-Request packet. If the user is not required to use EAP, then
the RADIUS Server will respond with an Access-Accept or Access-Reject
packet as appropriate. However, should the user require EAP, then the
RADIUS Server will respond with an Access-Challenge packet containing
an EAP-Message attribute. The EAP-Message attribute will either encap-
sulate an EAP-Request/Identity packet, or if the RADIUS Server makes
use of the User-Name attribute in the Access-Request, it may encapsu-
late an EAP challenge. On receiving the EAP-Message attribute, the NAS
will either attempt to negotiate EAP if it had not done so previously,
Calhoun, Rubens & Aboba [Page 4]
INTERNET-DRAFT 19 February 1997
or if negotiation had previously been attempted and failed, it MUST
disconnect the user.
The NAS is not responsible for the retransmission of any EAP messages.
The authenticating peer and the RADIUS Server are responsible for any
retransmissions.
The example below shows the conversation between the authenticating
peer, NAS, and RADIUS server, for the case of an S/Key authentication.
S/Key is used only for illustrative purposes; other authentication
protocols could also have been used, although they would show somewhat
different behavior.
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP ACK ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
S-Key/S-Key Challenge
<- PPP EAP-Request/
S-Key/
S-Key Challenge
PPP EAP-Response/
S-Key, S-Keypw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
S-Key, S-Keypw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
IPCP phase starts
Calhoun, Rubens & Aboba [Page 5]
INTERNET-DRAFT 19 February 1997
In the case where the NAS sends the authenticating peer an EAP-
Request/Identity packet without first sending an EAP-Start packet to
the RADIUS server, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP ACK ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
S-Key/S-Key Challenge
<- PPP EAP-Request/
S-Key/
S-Key Challenge
PPP EAP-Response/
S-Key, S-Keypw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
S-Key, S-Keypw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
IPCP phase starts
In the case where the client fails EAP authentication, the conversa-
tion would appear as follows:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP ACK ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Calhoun, Rubens & Aboba [Page 6]
INTERNET-DRAFT 19 February 1997
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
S-Key/S-Key Challenge
<- PPP EAP-Request/
S-Key/
S-Key Challenge
PPP EAP-Response/
S-Key, S-Keypw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
S-Key, S-Keypw ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- PPP EAP-Failure
(client disconnected)
In the case that the RADIUS server or proxy does not support EAP-Mes-
sage, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP ACK ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
<- PPP LCP
CHAP-Request
PPP LCP
CHAP-Response->
RADIUS
Access-Request->
<- RADIUS
Access-Accept
In the case where the local RADIUS Server does support EAP-Message,
but the remote RADIUS Server does not, the conversation would appear
as follows:
Calhoun, Rubens & Aboba [Page 7]
INTERNET-DRAFT 19 February 1997
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP ACK ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity
(MyID) ->
RADIUS
Access-Request/
EAP-Message/EAP-Response/
(MyID) ->
<- RADIUS
Access-Reject
(proxied from remote
RADIUS Server)
<- PPP LCP
CHAP-Request
PPP LCP
CHAP-Response->
RADIUS
Access-Request->
<- RADIUS
Access-Accept
(proxied from remote
RADIUS Server)
In the case where the authenticating peer does not support EAP, but
where EAP is required for that user, the conversation would appear as
follows:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP EAP-Request
PPP LCP EAP NACK ->
<- PPP LCP CHAP-Request
PPP LCP
CHAP-Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Challenge/
EAP-Message
Calhoun, Rubens & Aboba [Page 8]
INTERNET-DRAFT 19 February 1997
(User Disconnected)
5. Alternative uses
While the conversation between the RADIUS server and the backend
security server will typically occur using a proprietary protocol
developed by the backend security server vendor, it is also possible
to use RADIUS-encapsulated EAP via the EAP-Message and Signature
attributes. This has the advantage of allowing the RADIUS server to
support EAP without the need for authentication-specific code within
the RADIUS server. Authentication-specific code can then reside on a
backend security server instead.
In the case where RADIUS-encapsulated EAP is used in a conversation
between a RADIUS server and a backend security server, the Security
Server will typically return an Access-Accept/EAP-Success message
without inclusion of the expected attributes currently returned in an
Access-Accept. This means that the RADIUS server will need to add
these attributes prior to sending an Access-Accept/EAP-Success message
to the NAS.
6. Attributes
6.1. EAP-Message
Description
This attribute encapsulates Extensible Authentication Protocol [1]
packets so as to allow the NAS to authenticate dial-in users via
EAP without having to understand the protocol.
The NAS places EAP messages received from the authenticating peer
into one or more EAP-Message attributes and forwards them to the
RADIUS Server within an Access-Request message. The RADIUS Server
may then return EAP message in Access-Challenge, Access-Accept and
Access-Reject packets.
Access-Request packets including one or more EAP-Message attributes
MUST also contain a Signature attribute, described in [5], in order
to provide for authentication of the shuttled EAP packets. Access-
Requests including an EAP-Message attribute without a Signature
attribute SHOULD be silently discarded by the RADIUS server. A
RADIUS Server supporting EAP-Message MUST calculate the correct
value of the Signature and silently discard the packet if it does
not match the value sent. A RADIUS Server not supporting EAP-Mes-
sage MUST return an Access-Reject. A RADIUS Server receiving EAP
messages that it does not understand SHOULD return an Access-
Reject.
A summary of the EAP-Message attribute format is shown below. The
fields are transmitted from left to right.
Calhoun, Rubens & Aboba [Page 9]
INTERNET-DRAFT 19 February 1997
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sequence No. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
67 for EAP-Message
Length
>=5 (EAP packet enclosed)
=2 (EAP start message)
Sequence Number
The Sequence Number field, which is two octets in length, is used
in order to build a "history" of the transaction. The EAP-Message
attribute with the highest identifier represents the current packet
to process. The history is passed along in each Access-
request/Access-Challenge in order to support the concept of RADIUS
backup servers, as described earlier.
EAP-Message attributes with the same sequence number are to be con-
catenated, in order to allow an EAP packet to be larger than the
253 octet limit for a RADIUS attribute.
String
The String field includes EAP packets, as defined in [1]:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7. Acknowledgments
Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Naren-
dra Gidwani of Microsoft for useful discussions of this problem space.
8. References
[1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication
Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network,
Calhoun, Rubens & Aboba [Page 10]
INTERNET-DRAFT 19 February 1997
Inc., June, 1996.
[2] A. Rubens, P.R. Calhoun. "DIAMETER Extensible Authentication Pro-
tocol Support." draft-calhoun-diameter-eap-00.txt, Merit Network,
Inc., US Robotics Access Corp., February, 1997.
[3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit,
Daydreamer, January, 1997.
[4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January,
1997.
[5] C. Rigney, W. Willats. "RADIUS Extensions." draft-ietf-radius-
ext-00.txt, Livingston, January, 1997.
[6] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[7] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." draft-bradner-key-words-02.txt, Harvard University, August,
1996.
9. Authors' Addresses
Pat R. Calhoun
US Robotics Access Corp.
8100 N. McCormick Blvd.
Skokie, IL 60076-2999
Phone: 847-342-6898
EMail: pcalhoun@usr.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: 313-647-0417
EMail: acr@merit.edu
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Calhoun, Rubens & Aboba [Page 11]
INTERNET-DRAFT 19 February 1997
Calhoun, Rubens & Aboba [Page 12]
