Internet DRAFT - draft-aboba-radius-eap
draft-aboba-radius-eap
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 22:25:07 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 17 Jan 1997 15:18:00 GMT
ETag: "3dde65-4e3c-32df9828"
Accept-Ranges: bytes
Content-Length: 20028
Connection: close
Content-Type: text/plain
Network Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
<draft-aboba-radius-eap-00.txt> Glen Zorn
17 January 1997 Microsoft Corporation
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-
aboba-radius-eap-00.txt>, and expires July 1, 1997. Please send com-
ments to the authors.
2. Abstract
The Enhanced Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
Currently, the RADIUS protocol only supports conventional PPP authen-
tication methods such as PAP and CHAP. This document describes two new
attributes, EAP-Authentication-Type and EAP-Authentication-Server-End-
point, and how they 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. However, the RADIUS protocol, described
in [4], currently only supports CHAP and PAP authentication. This doc-
ument describes two new attributes, EAP-Authentication-Type, and EAP-
Authentication-Server-Endpoint, and how they may be used for providing
EAP support within RADIUS.
Aboba & Zorn [Page 1]
INTERNET-DRAFT 17 January 1997
The scheme described here differs from that proposed in [2], in that
rather than shuttling RADIUS-encapsulated EAP Packets between the NAS
and a backend security server, the RADIUS server instead returns the
type of EAP authentication desired, and the address and port of the
backend authentication server to be contacted. The NAS device then
uses this information to contact the backend security server directly.
Due to the 253 octet limitation in the size of a RADIUS attribute, the
scheme described in [2] could not be easily implemented on existing
RADIUS servers, and was dependent on deployment of an expanded version
of the RADIUS protocol. Since the scheme described here does not
encapsulate EAP packets in RADIUS, it may be implemented within RADIUS
as described in [3] and [4].
While the conversation between the NAS and backend security server
will typically occur using a proprietary protocol developed by the
backend security server vendor, it is also possible to encapsulate EAP
in UDP or TCP. This has the advantage of allowing the NAS to support
EAP without the need for authentication-specific code, which can
instead reside on a backend security server.
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, if the NAS is set up for RADIUS authentication, it will initi-
ate an EAP-identity request. While use of the identity request is not
required by EAP, without knowledge of the identity, RADIUS would not
be capable of returning user-specific connection setup attributes, or
accounting for resource usage. Since these are the main benefits of
the RADIUS protocol, if an identity request were not required, the NAS
should be set up to operate with a local profile rather than using
RADIUS.
Since the purpose of EAP is to authenticate the user, prior to sending
the Access-Request the RADIUS client has obtained the user's identity,
but no authentication can be assumed to have taken place. Therefore
with EAP it is typically not possible to include a conventional User-
Password or CHAP-Password attribute within the Access-Request.
Instead, after obtaining the user's identity, the RADIUS client gener-
ates an Access-request containing the following attributes: User-Name
(filled in with the identity), EAP-Authentication-Server-Endpoint
(with an address of 0.0.0.0, and port of 0x0000), EAP-Authentication-
Type (with type 0) and a User-Password attribute which contains an MD5
hash of the Access-Request concatenated with the shared secret (i.e.
User-Password=MD5(Code+ID+Length+RequestAuth+Attributes+Secret)). This
amounts to a null password, but authenticates that the request came
from a known NAS. The user's connection is only set up by the NAS
should the EAP authentication succeed.
It is also possible for the NAS to carry out an MD5 authentication
prior to sending the Access-Request. In this case, the NAS will
Aboba & Zorn [Page 2]
INTERNET-DRAFT 17 January 1997
include a CHAP-Password attribute in the Access-Request, along with
the null EAP-Authentication-Server-Endpoint and EAP-Authentication-
Type attributes, and as a result, the RADIUS server is able to verify
the user password. However, use of multiple authentications may not be
desirable in many applications.
On receiving the Access-Request, the RADIUS server checks the validity
of the User-Password or CHAP-Password attributes, and if this check is
successful, the RADIUS server returns connection-related attributes in
the Access-Reply, along with the EAP-Authentication-Type and EAP-
Authentication-Server-Endpoint attributes. Although use of multiple
EAP authentications is typically not desirable, it is possible for the
RADIUS server to return more than one set of EAP-Authentication-Type
and EAP-Authentication-Server-Endpoint attributes; in this case the
NAS will carry out the authentications in the indicated order.
If the authenticating peer is successful in completing the EAP authen-
tication, then the NAS grants access to the network, and sends a
RADIUS Accounting-Request/START packet to the RADIUS server, including
the EAP-Authentication-Type and EAP-Authentication-Server-Endpoint
attributes. The RADIUS server replies with an Accounting-Reply packet.
Similarly, when the connection is terminated, the NAS sends a RADIUS
Accounting-Request/STOP packet to the RADIUS server, including the
EAP-Authentication-Type and EAP-Authentication-Server-Endpoint
attributes, and the RADIUS server replies with an Accounting-Reply
packet.
The conversation between the authenticating peer, NAS, and RADIUS
server is summarized below:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- LCP EAP-Request
LCP EAP ACK ->
<- PPP EAP-Request/Identity
PPP EAP-Response/Identity
(MyID) ->
RADIUS Access-Request
Username (MyID),
User-Password,
EAP-Authentication-Type(0)
EAP-Authentication-Server-
Endpoint (0) ->
<-RADIUS Access-Accept
(Referral)
EAP-Authentication-Type:S-Key,
EAP-Authentication-Server-Endpoint,
(Other attributes)
<- PPP EAP-Request/S-Key
S-Key Challenge
PPP EAP-Response/S-Key,
S-Keypw ->
EAP-Request/S-Key
S-Keypw (to security server)
Aboba & Zorn [Page 3]
INTERNET-DRAFT 17 January 1997
EAP-Success
(from security server)
<- PPP EAP-Success
IPCP phase starts
IPCP phase completes
RADIUS Accounting-Request
with Acct-Status-Type=Start,
EAP-Authentication-Server-Endpoint
EAP-Authentication-Type ->
<- RADIUS Accounting-Reply
RADIUS Accounting-Request
with Acct-Status-Type=Stop,
EAP-Authentication-Server-Endpoint
EAP-Authentication-Type ->
<- RADIUS Accounting-Reply
4.1. Backward compatibility
It is conceivable that the RADIUS server to which the initial Access-
Reqest is directed will not support EAP. In this case, the User-Pass-
word attribute will not match, and the RADIUS server will respond with
a RADIUS Access-Reject. The NAS will then NAK the Authenticating Peer,
and will request CHAP or PAP authentication.
5. Attributes
5.1. EAP-Authentication-Type
Description
When included in an Access-Request message, this attribute MUST
contain a value of 0, used to indicate a request for an EAP authen-
tication type.
When returned in an Access-Accept message, this attribute indicates
the authentication protocol to be used. A NAS is not required to
implement all of these authentication types, and MUST treat unknown
or unsupported EAP-Authentication-Types as though an Access-Reject
had been received instead.
A summary of the EAP-Authentication-Type Attribute format is shown
below. The fields are transmitted from left to right.
0 1 2
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
Aboba & Zorn [Page 4]
INTERNET-DRAFT 17 January 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
69 for EAP-Authentication-Type
Length
3
Value
The Value field is a single octet.
0 Request for EAP redirection (Access-Request only)
1 Identity
2 Notification
3 Nak (Response only)
4 MD5-Challenge
5 S/Key (RFC 1760)
6 Generic Token Card
5.2. EAP-Authentication-Server-Endpoint
Description
When included in an Access-Request message, this attribute MUST
contain a value of 0, used to indicate a request for an EAP authen-
tication server endpoint address and port. If this attribute is not
included in the Access-Request, it When returned in an Access-
Reply/Accept message, this Attribute indicates the address of the
backend security server.
A summary of the Authentication-Server-Endpoint Attribute format is
shown below. The fields are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
70 for EAP-Authentication-Server-Endpoint.
Length
=8 for IPv4, 20 for IPv6
String
Aboba & Zorn [Page 5]
INTERNET-DRAFT 17 January 1997
The structure of the string field is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Address ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The string field consists of a two-octet port field, as well as an
address field. The length of the address depends on whether we are
using IPv4 or IPv6. In IPv4, the attribute is 8 octets in length,
and in IPv6, it is 20 octets in length. length.
6. Security Issues
This specification raises two major security issues: the use of a mod-
ified User-Password attribute in the Access-Request, and the use of an
EAP encapsulation over the Internet.
In a conventional RADIUS conversation, user attributes are sent by the
RADIUS server to the NAS only after the user password has been veri-
fied. In the protocol specified in this document, the attributes are
sent on verification of the secret shared between the NAS and the
RADIUS server. While the User-Password scheme described here protects
against modification of the Access-Request message, which standard
RADIUS does not, it makes it more likely that an attacker obtaining
the shared secret would then also be able to obtain user attribute
information. The most important such information is the knowledge that
an account exists for a given userID, although other attributes (such
as the user's IP address or framing) may also be of interest.
While this risk can be mitigated by requiring an MD5 authentication
prior to release of the connection setup information, and including
the CHAP-Password attribute in the Access-Request, use of multiple
authentications may not be desirable in many applications.
The scheme described in this document results in the NAS entering to a
direct conversation with a backend security server, while in the
scheme described in [2], the RADIUS server shuttles EAP packets back
and forth between the NAS and the backend security server. In the sit-
uation where the RADIUS server is located close to the backend secu-
rity server, the conversation between the NAS and RADIUS server or
backend security server will typically occur over the Internet, while
a conversation between a RADIUS server and backend security server
will typically occur over a local LAN or other private network.
Since the security of an EAP authentication is only as good as the
weakest link, it is worthwhile to examine the security aspects of
these conversations. In the conversation between the NAS and the back-
end security server or RADIUS server, it is desirable for mutual
Aboba & Zorn [Page 6]
INTERNET-DRAFT 17 January 1997
authentication to be provided. However, typically encryption of the
EAP conversation is not required, since EAP authentication protocols
have already taken the possibility of snooping into account.
In the scheme described here, the conversation between the NAS and
backend security server can either occur via a proprietary protocol,
or via an EAP encapsulation. Assuming that the EAP encapsulation is
secured (via SSL or IP Sec), then mutual authentication can be pro-
vided, as well as encryption. As described earlier, the use of a modi-
fied User-Password attribute provides assurance to the RADIUS server
that the Access-Request comes from a legitimate NAS device, and the
Authenticator provided in the Access-Reply provides assurance to the
RADIUS client that the reply comes from a legitimate RADIUS server.
The scheme described in [2] provides for mutual authentication between
the NAS and RADIUS server. This is handled via a message integrity
check (MIC) included within the Access-Request. As a result, expanded
RADIUS provides assurance of the authenticity and integrity of both
EAP requests and responses.
While [2] does not describe the communication mechanisms between the
RADIUS server and backend security server, it can be assumed that this
also occurs either via a proprietary protocol, or via an EAP encapsu-
lation. However, since the conversation between the RADIUS server and
backend security server is likely to occur over a LAN or private net-
work, security concerns are typically not as severe.
7. Acknowledgements
Thanks to Gurdeep Singh Pall, Peter Ford, and Narendra 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,
Inc., June, 1996.
[2] A. Rubens, P.R. Calhoun. "Enhanced Remote Authentication Dial In
User Service (RADIUS) Extensible Authentication Protocol Support."
draft-calhoun-enh-radius-eap-00.txt, Merit Network, Inc., US Robotics
Access Crop., June, 1996.
[3] C. Rigney, A. Rubens, W. A. Simpson, S. Willens. "Remote Authen-
tication Dial In User Service (RADIUS)." draft-ietf-radius-
radius-05.txt, Livingston, Merit, Daydreamer, July 1996.
[4] C. Rigney. "RADIUS Accounting." draft-ietf-radius-account-
ing-05.txt, Livingston, July 1996.
Aboba & Zorn [Page 7]
INTERNET-DRAFT 17 January 1997
9. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-936-6605
EMail: bernarda@microsoft.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 206-703-1559
EMail: glennz@microsoft.com
Aboba & Zorn [Page 8]
