Internet Draft Allan Rubens
Category: Experimental Merit Network, Incorporated
expires in six months Pat R. Calhoun
US Robotics Access Corp.
June 1996
Enhanced Remote Authentication Dial In User Service (RADIUS)
Extensible Authentication Protocol Support
<draft-calhoun-enh-radius-eap-00.txt>
Status of this Memo
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working 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
material 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).
Abstract
The RADIUS Protocol allows for authentication using existing
PPP authentication protocols such as PAP and CHAP. This
document describes how the Enhanced RADIUS Protocol could
also include the PPP Extensible Authentication Protocol, EAP.
Rubens [Page 1]
DRAFT Extensible Authentication Protocol Support June 1996
1. Introduction
The PPP extensions WG is considering a new authentication protocol
for PPP called EAP - PPP Extensible Authentication Protocol. EAP is
described in [2].
EAP is intended to provide support for authentication protocols which
do not fit into the PAP or CHAP model using a standard mechanism. The
protocols include varieties of smart cards, S/key, Public Key and
Kerberos. EAP is designed to allow a RADIUS style helper to handle
all authentication protocol support where the NAS acts as a transit
mechanism for EAP packets.
The following diagram gives an example of how an EAP authentication
using S/key might be accomplished with Enhanced RADIUS. This example
may be extended to other EAP protocols easily, but this concrete
example serves to make it a easier to understand the basic concept:
PPP-Client NAS (RADIUS-client) RADIUS-server
---------- ------------------- -------------
1) <-- LCP EAP-Request
2) LCP EAP ACK -->
3) Start-EAP -->
4) <-- EAP/identity
5) <-- EAP/identity
6) EAP-resp/myid -->
7) EAP-resp/myid -->
8) <-- EAP/S-key:S-key challenge
9) <-- EAP/S-key:S-key challenge
10) EAP-resp/myid:S-keypw -->
11) EAP/myid:S-keypw -->
12) <-- EAP/Success
13) <-- EAP/Success
Rubens [Page 2]
DRAFT Extensible Authentication Protocol Support June 1996
The following describes one way to make this work with RADIUS:
a) Upon receiving an EAP-Response as the authentication protocol,
the NAS sends a RADIUS-EAP-Request to the RADIUS-server. The
absence of an EAP-Packet attribute in this request indicates that
this is a Start-EAP indication.
b) The RADIUS-server responds by sending a RADIUS-EAP-ACK with an
EAP-Packet attribute specifying the EAP packet to be issued to the
NAS. The EAP type of this packet will normally be "Identity", but
it could be any other valid EAP type if the server does not need to
know the user identity before beginning authentication. The NAS
forwards the EAP packet on to the PPP client.
c) The PPP client responds by sending an EAP-Response packet, which
the NAS forwards to the RADIUS-server in the EAP-Packet attribute
of a RADIUS-EAP-Request.
d) Based on the user's identity, the RADIUS-server determines if it
is able to authenticate the user locally, otherwise it may proxy
the request to a remote RADIUS server.
e) The RADIUS-server decides whether the response is okay and sends
a RADIUS-EAP-Ack or RADIUS-EAP-Reject with the appropriate EAP
success/failure packet inside an EAP-MSG attribute. The NAS
forwards the EAP packet to the PPP client, and accepts or rejects
the connection.
The above scenario creates a situation in which the NAS never needs to
touch an EAP packet. An alternative which may be used by NAS vendors
wanting to simplify things would be for the NAS to, 1) always send an
EAP Identity request message to the client, and 2) to forward the
response to the RADIUS-server in the EAP-Packet attribute of a
RADIUS-EAP-Request.
Unless the NAS interprets the EAP-Packet field of
RADIUS-EAP-Requests, it will not see the user id supplied by the
client. Rather than doing this interpretation, it is suggested that a
simple mechanism be defined for the RADIUS server to set the userid in
the NAS with a special attribute. It is important to have a userid
for logging and accounting purposes.
In the case where the RADIUS Server does not support the EAP
Extension, the following scenario would occur:
Rubens [Page 3]
DRAFT Extensible Authentication Protocol Support June 1996
PPP-Client NAS (RADIUS-client) RADIUS-server
---------- ------------------- -------------
1) <-- LCP EAP-Request
2) LCP EAP ACK -->
3) Start-EAP -->
4) <-- Command Unrecognized
5) <-- LCP CHAP Request
In the case where the local RADIUS-server does support EAP, but the
remote RADIUS-server does not, the following would occur:
PPP-Client NAS (RADIUS-client) RADIUS-server RADIUS-Server
---------- ------------------- ------------- -------------
1) <-- LCP EAP-Request
2) LCP EAP ACK -->
3) Start-EAP -->
4) <-- EAP/identity
5) <-- EAP/identity
6) EAP-resp/myid -->
7) EAP-resp/myid -->
8) EAP-resp/myid -->
9) <-- Command Unrecognized
10) <-- Command Unrecognized
11) <-- LCP CHAP Request
Rubens [Page 4]
DRAFT Extensible Authentication Protocol Support June 1996
2. Command Name and Command Code
Command Name: RADIUS-EAP-Request
Command Code: 300
Command Name: RADIUS-EAP-Response
Command Code: 301
Command Name: RADIUS-EAP-Ack
Command Code: 302
Command Name: RADIUS-EAP-Reject
Command Code: 303
3. Command Meanings
3.1 RADIUS-EAP-Request
Description
RADIUS-EAP-Request packets are sent by the Radius Client to the
Radius Server, and convey EAP-Responses from the client through the
NAS and on to the Radius server. RADIUS-EAP-Requests will normally
include a single EAP-Packet attribute which contains the EAP packet.
A RADIUS-EAP-Request sent from the NAS to the RADIUS server that
does not contain an EAP-Packet attribute signals to the RADIUS
server that it is to initiate EAP authentication with the client.
Upon receipt of a RADIUS-EAP-Request, A RADIUS Server MUST
issue a reply. The reply may be either: 1) a RADIUS-EAP-Response
containing an EAP-Request in a single EAP-Packet attribute, 2) a
RADIUS-EAP-Ack containing an EAP-Packet of type "success", or 3) a
RADIUS-EAP-Reject containing an EAP-Packet of type "failure". A
Command-Unrecognized packet is returned if the server does not
support EAP.
A summary of the RADIUS-EAP-Request packet format is shown
below. The fields are transmitted from left to right.
Rubens [Page 5]
DRAFT Extensible Authentication Protocol Support June 1996
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 | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for Enhanced RADIUS.
Flags
The Flag field is used as defined in [1].
Version
MUST be set to 2
Command
300 for RADIUS-EAP-Request
Identifier
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MAY remain unchanged.
Rubens [Page 6]
DRAFT Extensible Authentication Protocol Support June 1996
Length
The total length of the message, including this header.
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field is variable in length, and contains a list of
zero or more Attributes. It MAY contain zero or one EAP-Packet
attributes. If it does not contain an EAP-Packet attribute, it is
an indication to the server that server that EAP should be
initiated by the server. If it contains one EAP-Packet attribute,
this attribute contains the reply to the last EAP-Request issued by
the server (or the reply to the EAP-Identity that can be issued by
the NAS). The remainder of the attributes are those normally sent
on an Access-Request by the NAS.
3.2 RADIUS-EAP-Response
Description
RADIUS-EAP-Response packets are sent by the RADIUS-Server to the
NAS. They contain the next EAP-Request packet to be passed to the
client.
The RADIUS-EAP-Response MUST contain a single EAP-Packet
attribute.
After issuing the included EAP-Request to the client, the NAS
remains in a state where it awaits further EAP-Responses from the
client.
A summary of the RADIUS-EAP-Request packet format is shown
below. The fields are transmitted from left to right.
Rubens [Page 7]
DRAFT Extensible Authentication Protocol Support June 1996
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 | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for Enhanced RADIUS.
Flags
The Flag field is used as defined in [1].
Version
MUST be set to 2
Command
301 for RADIUS-EAP-Response
Identifier
The Identifier field is a copy of the Identifier field of the
RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent.
Length
The total length of the message, including this header.
Rubens [Page 8]
DRAFT Extensible Authentication Protocol Support June 1996
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field MUST contains only a single EAP-Packet
attribute which contains an EAP-Request packet.
3.3 RADIUS-EAP-Ack
Description
RADIUS-EAP-Ack packets are sent by the RADIUS server to the NAS.
They contain the next EAP-Request or EAP-Success packet to be
passed to the client.
The RADIUS-EAP-Ack packet MUST contain a single EAP-Packet
attribute.
After issuing the included EAP-Success packet to the client, the
NAS should end the authentication phase with a positive response.
A summary of the RADIUS-EAP-Ack packet format is shown below. The
fields are transmitted from left to right.
Rubens [Page 9]
DRAFT Extensible Authentication Protocol Support June 1996
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 | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for Enhanced RADIUS.
Flags
The Flag field is used as defined in [1].
Version
MUST be set to 2
Command
302 for RADIUS-EAP-Ack
Identifier
The Identifier field is a copy of the Identifier field of the
RADIUS-EAP-Request which caused this RADIUS-EAP-Ack to be sent.
Length
The total length of the message, including this header.
Rubens [Page 10]
DRAFT Extensible Authentication Protocol Support June 1996
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field contains only a single EAP-Packet attribute
which contains an EAP-Request packet.
3.4 RADIUS-EAP-Reject
Description
RADIUS-EAP-Reject packets are sent by the RADIUS server to the NAS.
They are sent in response to a RADIUS-EAP-Request that results in
an authentication failure. RADIUS-EAP-Reject packets contain a
single EAP-Packet attribute containing an EAP failure packet.
After issuing the included EAP failure packet to the client, the
NAS should end the authentication phase with a negative result.
A summary of the RADIUS-EAP-Reject packet format is shown below.
The fields are transmitted from left to right.
Rubens [Page 11]
DRAFT Extensible Authentication Protocol Support June 1996
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 | Flags | Ver | Command |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Integrity Code |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
254 for Enhanced RADIUS.
Flags
The Flag field is used as defined in [1].
Version
MUST be set to 2
Command
303 for RADIUS-EAP-Reject
Identifier
The Identifier field is a copy of the Identifier field of the
RADIUS-EAP-Request which caused this RADIUS-EAP-Reject to be sent.
Length
The total length of the message, including this header.
Rubens [Page 12]
DRAFT Extensible Authentication Protocol Support June 1996
Authenticator
The Authenticator field is a random 16 octet value. If the
Timestamp option is supported, the first four octets contain a
timestamp of when the packet was sent from the peer.
Message Integrity Code
This field contains an MD5 hash of the following:
MD5( packet | Shared Secret )
Attributes
The Attribute field contains only a single EAP-Packet attribute
which contains an EAP-Request packet. Other attributes valid
on an Access-Reject message may also be present.
4. Attribute Name and Attribute Code
Attribute Name: EAP-Packet
Attribute Code: 300
5. Attribute Meanings
5.1 EAP-Packet
Description
This attribute is used to contain the actual EAP-Requests to be
sent from the Radius server to the client (RADIUS-EAP-Ack and
RADIUS-EAP-Reject) and the EAP-Responses to be sent from the client
to the Radius server (RADIUS-EAP-Requests). These EAP-Requests and
Responses are exactly as defined in [2].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | String ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rubens [Page 13]
DRAFT Extensible Authentication Protocol Support June 1996
Type
300 for EAP-Packet
Length
>= 6
Flags
The Flags field MUST be set to 1 (The attribute MUST be supported
by the receiving device). Of course, the attribute would only be
supported if the implementation supported EAP.
String
The String field is the exact EAP packet data to be transported
from client to server or server to client. It is not Null
terminated and may contain arbitrary binary values.
6. Motivation
The motivation for this extension to Enhanced RADIUS is to allow
RADIUS, which is the most common Authentication protocol deployed
today, to keep up with the new authentication protocols currently
being worked on by the PPP Extensions WG.
This extension allows the NAS' to support a variety of
authentication protocols by delegating the task to the
Authentication server. The NAS needs to simply forward packets from
the PPP client to the local RADIUS Server. Note, however, that the
same RADIUS Server must be used throughout the whole transaction
process (see section 7 on dealing with proxy'ed requests). If the
local RADIUS server becomes unavailable at any time during the
authentication phase, the NAS will have to begin LCP negotiations
again with the PPP client.
Since the EAP messages are simply forwarded from/to the NAS and the
RADIUS Server, the support of the Message Integrity Check in the
Enhanced RADIUS header allows both parties to authenticate
themselves.
Rubens [Page 14]
DRAFT Extensible Authentication Protocol Support June 1996
7. Description (or Implementation Rules)
Upon negotiating LCP EAP with the PPP client, the NAS must send a
EAP Start message to the local RADIUS Server (note this should only
be done if the NAS is aware that its local RADIUS Server is capable
of the Enhanced RADIUS protocol [1]). The EAP-Start message is an
EAP-Request with no EAP-Packet attribute present.
If the RADIUS Server does not support this extension, a
Command-Unrecognized message will be returned to the NAS. Upon
receipt of this packet, the NAS will NAK the PPP client and request
PAP or CHAP as the authentication protocol.
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 EAP-Start request. In the case that the domain is
determined based on the user id, the local RADIUS-server must
issue the EAP-identity request. The response from the PPP user
must be proxied to the final authentication server.
If the RADIUS Server does support this extension, an EAP-Identity
message is returned to the NAS. Upon receipt of this packet, the
NAS will complete the LCP negotiation phase and will enter the EAP
authentication phase. The NAS will then forward the packet which
was contained in the EAP-Packet attribute of the EAP-Request-Ack to
the PPP client.
For proxied RADIUS requests, a Command-Unrecognized message may be
received following the EAP-Identity response. This would occur
if the messages was proxied to a RADIUS-server which does not
support the EAP extension.
Note that if at any point an EAP-Request-Reject message is received
from the RADIUS Server, the NAS SHOULD issue an LCP Terminate
Request to the PPP Client.
At this point, the PPP Client will exchange a series of
request/response messages with the RADIUS Server. This is done
until either an EAP-Request-Reject is received (which will
disconnect the user), or an EAP-Request-Success is received which
the NAS would then successfully end the authentication phase.
The RADIUS-server will always include the CLASS attribute in all
messages to the NAS. The NAS MUST include this same attribute in
the subsequent message to the RADIUS-server which includes the
response from the PPP client. The CLASS attribute which is
Rubens [Page 15]
DRAFT Extensible Authentication Protocol Support June 1996
associated with the EAP-Request-Success message from the
RADIUS-server is the one which should be used by the NAS in
all accounting messages for the authenticated user.
The RADIUS-EAP-Ack issued by the server to the NAS will contain all
of the attributes which are contained in an Access-Accept in
addition to the EAP-Packet attribute.
The Port number and NAS Identifier are included in the attributes
issued by the NAS in the original RADIUS-EAP-Request message.
The NAS is not responsible for the retransmission of any EAP
messages. The PPP client and the RADIUS-server are responsible for
for any retransmissions.
References
[1] Calhoun, Rubens, "Enhanced RADIUS", Internet-Draft,
draft-rfced-exp-calhoun-radius-enhanced-00.txt,
US Robotics Access Corp., June 1996.
[2] Blunk, Volbretch, "PPP Extensible Authentication Protocol",
Internet-Draft, draft-ietf-pppext-eap-auth-01.txt.,
Merit Networks Inc., July 1995.
Rubens [Page 16]