RADIUS Working Group Pat Calhoun
INTERNET-DRAFT Sun Microsystems
Updates: RFC 2138 Allan C. Rubens
Category: Standards Track Merit Network, Inc.
<draft-ietf-radius-eap-05.txt> Bernard Aboba
8 May 1998 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 view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
The distribution of this memo is unlimited. It is filed as <draft-
ietf-radius-eap-05.txt>, and expires November 1, 1998. 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. Changes from -04 draft
Updated section on retransmission
Added section on fragmentation
Added EAP-Timeout attribute
Updated references.
4. 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
Calhoun, Rubens & Aboba [Page 1]
INTERNET-DRAFT 8 May 1998
authentication schemes may be added, including smart cards, Kerberos,
Public Key, One Time Passwords, and others. In order to provide for
support of EAP within RADIUS, two new attributes, EAP-Message and Sig-
nature, were introduced as RADIUS extensions in [4]. This document
describes how these new attributes may be used for providing EAP sup-
port within RADIUS.
In the proposed scheme, 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 typically occur using a proprietary pro-
tocol developed by the backend security server vendor, it is also pos-
sible 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.
4.1. Requirements language
This specification uses the same words as [6] 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 "", 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 interoperate
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 implementation
Calhoun, Rubens & Aboba [Page 2]
INTERNET-DRAFT 8 May 1998
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 "uncondition-
ally compliant"; one that satisfies all the must and must not require-
ments but not all the should or should not requirements for its proto-
cols is said to be "conditionally compliant."
5. Protocol overview
The EAP conversation between the authenticating peer (dial-in user)
and the NAS begins with the negotiation of EAP within LCP. Once EAP
has been negotiated, the NAS MUST send an EAP-Request/Identity message
to the authenticating peer, unless identity is determined via some
other means such as Called-Station-Id or Calling-Station-Id. The peer
will then respond with an EAP-Response/Identity which the the NAS will
then forward to the RADIUS server in the EAP-Message attribute of a
RADIUS Access-Request packet. The RADIUS Server will typically use the
EAP-Response/Identity to determine which EAP type is to be applied to
the user.
In order to permit non-EAP aware RADIUS proxies to forward the Access-
Request packet, if the NAS sends the EAP-Request/Identity, the NAS
MUST copy the contents of the EAP-Response/Identity into the User-Name
attribute and MUST include the EAP-Response/Identity in the User-Name
attribute in every subsequent Access-Request. NAS-Port SHOULD be
included in the attributes issued by the NAS in the Access-Request
packet, and either NAS-Identifier or NAS-IP-Address MUST be included.
In order to permit forwarding of the Access-Reply by EAP-unaware prox-
ies, if a User-Name attribute was included in an Access-Request, the
RADIUS Server MUST include the User-Name attribute in subsequent
Access-Challenge and Access-Accept packets. Without the User-Name
attribute, accounting and billing becomes very difficult to manage.
If identity is determined via another means such as Called-Station-Id
or Calling-Station-Id, the NAS MUST include these identifying
attributes in every Access-Request, and the RADIUS Server MUST include
them in every Access-Challenge and Access-Accept.
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 Called-Station-Id or Calling-Station-Id), and therefore an
EAP-Request/Identity packet may not necessarily be issued by the NAS
to the authenticating peer. In cases where an EAP-Request/Identity
packet will not be sent, the NAS will send to the RADIUS server a
RADIUS Access-Request packet containing an EAP-Message attribute sig-
nifying EAP-Start. EAP-Start is indicated by sending an EAP-Message
attribute with a length of 2 (no data). However, it should be noted
that since no User-Name attribute is included in the Access-Request,
Calhoun, Rubens & Aboba [Page 3]
INTERNET-DRAFT 8 May 1998
this approach is not compatible with RADIUS as specified in [2], nor
can it easily be applied in situations where proxies are deployed,
such as roaming or shared use networks.
If the RADIUS server supports EAP, it MUST respond with an Access-
Challenge packet containing an EAP-Message attribute. If the RADIUS
server does not support EAP, it MUST respond with an Access-Reject.
The EAP-Message attribute includes an encapsulated EAP packet which is
then passed on to the authenticating peer. In the case where the NAS
does not initially send an EAP-Request/Identity message to the peer,
the Access-Challenge typically will contain an EAP-Message attribute
encapsulating an EAP-Request/Identity message, requesting the dial-in
user to identify themself. The NAS will then respond with a RADIUS
Access-Request packet containing an EAP-Message attribute encapsulat-
ing an EAP-Response. The conversation continues until either a RADIUS
Access-Reject or Access-Accept packet is received.
Reception of a RADIUS Access-Reject packet, with or without an EAP-
Message attribute encapsulating EAP-Failure, MUST result in the NAS
issuing an LCP Terminate Request to the authenticating peer. A RADIUS
Access-Accept packet with an EAP-Message attribute encapsulating EAP-
Success successfully ends the authentication phase. 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.
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.
For proxied RADIUS requests there are two methods of processing. If
the domain is determined based on the Called-Station-Id, the RADIUS
Server may proxy the initial RADIUS Access-Request/EAP-Start. If the
domain is determined 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. On receiving an Access-Reject,
the NAS MUST send an LCP Terminate Request to the authenticating peer,
and disconnect.
5.1. Retransmission
As noted in [1], the EAP authenticator (NAS) is responsible for
retransmission of packets between the authenticating peer and the NAS.
Thus if an EAP packet is lost in transit between the authenticating
peer and the NAS (or vice versa), the NAS will retransmit. As in
RADIUS [2], the RADIUS client is responsible for retransmission of
packets between the RADIUS client and the RADIUS server.
Calhoun, Rubens & Aboba [Page 4]
INTERNET-DRAFT 8 May 1998
Note that it may be necessary to adjust retransmission strategies and
authentication timeouts in certain cases. For example, when a token
card is used additional time may be required to allow the user to find
the card and enter the token. Since the NAS will typically not have
knowledge of the required parameters, these need to be provided by the
RADIUS server. This can be accomplished by inclusion of EAP-Timeout
and Password-Retry attributes within the Access-Challenge packet.
5.2. Fragmentation
Using the EAP-Message attribute, it is possible for the RADIUS server
to encapsulate an EAP packet that is larger than the MTU on the link
between the NAS and the peer. Since it is not possible for the RADIUS
server to use MTU discovery to ascertain the link MTU, the Framed-MTU
attribute may be included in an Access-Request packet containing an
EAP-Message attribute so as to provide the RADIUS server with this
information.
5.3. Examples
The example below shows the conversation between the authenticating
peer, NAS, and RADIUS server, for the case of a One Time Password
(OTP) authentication. OTP is used only for illustrative purposes;
other authentication protocols could also have been used, although
they might show somewhat different behavior.
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Calhoun, Rubens & Aboba [Page 5]
INTERNET-DRAFT 8 May 1998
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
In the case where the NAS first sends an EAP-Start packet to the
RADIUS server, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Accept/
EAP-Message/EAP-Success
Calhoun, Rubens & Aboba [Page 6]
INTERNET-DRAFT 8 May 1998
(other attributes)
<- PPP EAP-Success
PPP Authentication
Phase complete,
NCP Phase starts
In the case where the client fails EAP authentication, the conversa-
tion would appear as follows:
Autheticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
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
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- 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:
Calhoun, Rubens & Aboba [Page 7]
INTERNET-DRAFT 8 May 1998
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
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:
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
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 Terminate
(User Disconnected)
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
------------------- --- -------------
Calhoun, Rubens & Aboba [Page 8]
INTERNET-DRAFT 8 May 1998
<- PPP LCP Request-EAP
auth
PPP LCP NAK-EAP
auth ->
<- PPP LCP Request-CHAP
auth
PPP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
In the case where the NAS 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 Request-CHAP
auth
PP LCP ACK-CHAP
auth ->
<- PPP CHAP Challenge
PPP CHAP Response ->
RADIUS
Access-Request/
User-Name,
CHAP-Password ->
<- RADIUS
Access-Reject
<- PPP LCP Terminate
(User Disconnected)
6. Alternative uses
Currently the conversation between the backend security server and the
RADIUS server is proprietary because of lack of standardization. In
order to increase standardization and provide interoperability between
Radius vendors and backend security vendors, it is recommended that
RADIUS-encapsulated EAP be used for this conversation.
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.
Calhoun, Rubens & Aboba [Page 9]
INTERNET-DRAFT 8 May 1998
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 MUST add these
attributes prior to sending an Access-Accept/EAP-Success message to
the NAS.
7. Attributes
7.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. If multiple EAP-
Messages are contained within an Access-Request or Access-Challenge
packet, they MUST be in order and they MUST be consecutive
attributes in the Access-Request or Access-Challenge packet.
Access-Accept and Access-Reject packets SHOULD only have ONE EAP-
Message attribute in them, containing EAP-Success or EAP-Failure.
It is expected that EAP will be used to implement a variety of
authentication methods, including methods involving strong cryptog-
raphy. In order to prevent attackers from subverting EAP by attack-
ing RADIUS/EAP, (for example, by modifying the EAP-Success o EAP-
Failure packets) it is necessary that RADIUS/EAP provide integrity
protection at least as strong as those used in the EAP methods
themselves.
The Signature attribute specified in [4] MUST be used to protect
all Access-Request, Access-Challenge, Access-Accept, and Access-
Reject packets containing an EAP-Message attribute. For Access-
Accepts the Signature is calculated as specified in [4]. For
Access-Challenge, Access-Accept, and Access-Reject packets, the
Signature is calculated as follows:
Signature = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
The Signature attribute is zeroed for the purposes of the calcula-
tion and the shared secret is used as the key for the HMAC-MD5
hash. The Signature is calculated and inserted in the packet
before the Authenticator is calculated.
Access-Request packets 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
Calhoun, Rubens & Aboba [Page 10]
INTERNET-DRAFT 8 May 1998
correct value of the Signature and silently discard the packet if
it does not match the value sent. A RADIUS Server not supporting
EAP-Message MUST return an Access-Reject if it receives an Access-
Request containing an EAP-Message attribute. A RADIUS Server
receiving an EAP-Message attribute that it does not understand MUST
return an Access-Reject.
Access-Challenge, Access-Accept, or Access-Reject packets including
an EAP-Message attribute without a Signature attribute SHOULD be
silently discarded by the NAS. A NAS 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 summary of the EAP-Message attribute 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
79 for EAP-Message
Length
>=3 (EAP packet enclosed)
=2 (EAP-Start message)
String
The String field includes EAP packets, as defined in [1]. If mul-
tiple EAP-Message attributes are present in a packet their values
should be concatenated; this allows EAP packets longer than 253
octets to be passed by RADIUS.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ /
/ Data /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.2. EAP-Timeout
Description
This attribute is used only in Access-Challenge packets and
Calhoun, Rubens & Aboba [Page 11]
INTERNET-DRAFT 8 May 1998
provides the NAS with the timeout interval to apply during EAP
authentication.
A summary of the EAP-Timeout attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for EAP-Timeout
Length
6
Value
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of seconds the NAS should wait for an EAP-
Response before retransmitting.
8. Security considerations
Since the purpose of EAP is to provide enhanced security for PPP
authentication, it is critical that RADIUS support for EAP be secure.
In particular, the following issues must be addressed:
Separation of the EAP server and PPP authenticator
Connection hijacking
Man in the middle attacks
Multiple databases
Negotiation attacks
8.1. Separation of the EAP server and PPP authenticator
As described in [8] and [9], it is possible for the EAP endpoints to
mutually authenticate, negotiate a ciphersuite, and derive a session
key for subsequent use in PPP encryption.
This does not present an issue on the peer, since the peer and EAP
client reside on the same machine; all that is required is for the EAP
client module to pass the session key to the PPP encryption module.
The situation may be more complex when EAP/RADIUS is used, since the
PPP authenticator will typically not reside on the same machine as the
Calhoun, Rubens & Aboba [Page 12]
INTERNET-DRAFT 8 May 1998
EAP server. For example, the EAP server may be a backend security
server, or a module residing on the RADIUS server.
In the case where the EAP server and PPP authenticator reside on dif-
ferent machines, there are several implications for security.
Firstly, mutual authentication will occur between the peer and the EAP
server, not between the peer and the authenticator. This means that it
is not possible for the peer to validate the identity of the NAS or
tunnel server that it is speaking to.
As described earlier, when EAP/RADIUS is used to encapsulate EAP pack-
ets, the Signature attribute is required in EAP/RADIUS Access-Requests
sent from the NAS or tunnel server to the RADIUS server. Since the
Signature attribute involves a HMAC-MD5 hash, it is possible for the
RADIUS server to verify the integrity of the Access-Request as well as
the NAS or tunnel server's identity. Similarly, Access-Challenge pack-
ets sent from the RADIUS server to the NAS are also authenticated and
integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel
server to determine the integrity of the packet and verify the iden-
tity of the RADIUS server. Morever, EAP packets sent via the methods
described in [8] and [9] contain their own integrity protection, so
that they cannot be successfully modified by a rogue NAS or tunnel
server.
The second issue that arises in the case of an EAP server and PPP
authenticator residing on different machines is that the session key
negotiated between the peer and EAP server will need to be transmitted
to the authenticator. Therefore a mechanism needs to be provided to
transmit the session key from the EAP server to the authenticator or
tunnel server that needs to use the key. The specification of this
transit mechanism is outside the scope of this document.
8.2. Connection hijacking
In this form of attack, the attacker attempts to inject packets into
the conversation between the NAS and the RADIUS server, or between the
RADIUS server and the backend security server. RADIUS does not support
encryption, and as described in [2], only Access-Reply and Access-
Challenge packets are integrity protected. Moreover, the integrity
protection mechanism described in [2] is weaker than that likely to be
used by some EAP methods, making it possible to subvert those methods
by attacking EAP/RADIUS.
In order to provide for authentication of all packets in the EAP
exchange, all EAP/RADIUS packets MUST be authenticated using the Sig-
nature attribute, as described previously.
8.3. Man in the middle attacks
Since RADIUS security is based on shared secrets, end-to-end security
is not provided in the case where authentication or accounting packets
are forwarded along a proxy chain. As a result, attackers gaining
Calhoun, Rubens & Aboba [Page 13]
INTERNET-DRAFT 8 May 1998
control of a RADIUS proxy will be able to modify EAP packets in tran-
sit without fear of detection.
This represents a weakness of RADIUS which cannot be remedied without
providing end-to-end data object security.
8.4. Multiple databases
In many cases a backend security server will be deployed along with a
RADIUS server in order to provide EAP services. Unless the backend
security server also functions as a RADIUS server, two separate user
databases will exist, each containing information about the security
requirements for the user. This represents a weakness, since security
may be compromised by a successful attack on either of the servers, or
their backend databases. With multiple user databases, adding a new
user may require multiple operations, increasing the chances for
error. The problems are further magnified in the case where user
information is also being kept in an LDAP server. In this case, three
stores of user information may exist.
In order to address these threats, consolidation of databases is rec-
ommended. This can be achieved by having both the RADIUS server and
backend security server store information in the same backend
database; by having the backend security server provide a full RADIUS
implementation; or by consolidating both the backend security server
and the RADIUS server onto the same machine.
8.5. Negotiation attacks
In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or
RADIUS server causes the authenticating peer to choose a less secure
authentication method so as to make it easier to obtain the user's
password. For example, a session that would normally be authenticated
with EAP would instead authenticated via CHAP or PAP; alternatively, a
connection that would normally be authenticated via one EAP type
occurs via a less secure EAP type, such as MD5. The threat posed by
rogue devices, once thought to be remote, has gained currency given
compromises of telephone company switching systems, such as those
described in [7].
Protection against negotiation attacks requires the elimination of
downward negotiations. This can be achieved via implementation of per-
connection policy on the part of the authenticating peer, and per-user
policy on the part of the RADIUS server.
For the authenticating peer, authentication policy should be set on a
per-connection basis. Per-connection policy allows an authenticating
peer to negotiate EAP when calling one service, while negotiating CHAP
for another service, even if both services are accessible via the same
phone number.
Calhoun, Rubens & Aboba [Page 14]
INTERNET-DRAFT 8 May 1998
With per-connection policy, an authenticating peer will only attempt
to negotiate EAP for a session in which EAP support is expected. As a
result, there is a presumption that an authenticating peer selecting
EAP requires that level of security. If it cannot be provided, it is
likely that there is some kind of misconfiguration, or even that the
authenticating peer is contacting the wrong server. Should the NAS not
be able to negotiate EAP, or should the EAP-Request sent by the NAS be
of a different EAP type than what is expected, the authenticating peer
MUST disconnect. An authenticating peer expecting EAP to be negotiated
for a session MUST NOT negotiate CHAP or PAP.
For a NAS, it may not be possible to determine whether a user is
required to authenticate with EAP until the user's identity is known.
For example, for shared-uses NASes it is possible for one reseller to
implement EAP while another does not. In such cases, if any users of
the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for
every call. This avoids forcing an EAP-capable client to do more than
one authentication, which weakens security.
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Pass-
word 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, if CHAP has been negotiated but EAP is required, the RADIUS
server MUST respond with an Access-Reject, rather than an Access-Chal-
lenge/EAP-Message/EAP-Request packet. The authenticating peer MUST
refuse to renegotiate authentication, even if the renegotiation is
from CHAP to EAP.
If EAP is negotiated but is not supported by the RADIUS proxy or
server, then the server or proxy MUST respond with an Access-Reject.
In these cases, the NAS MUST send an LCP-Terminate and disconnect the
user. This is the correct behavior since the authenticating peer is
expecting EAP to be negotiated, and that expectation cannot be ful-
filled. An EAP-capable authenticating peer MUST refuse to renegotiate
the authentication protocol if EAP had initially been negotiated.
Note that problems with a non-EAP capable RADIUS proxy could prove
difficult to diagnose, since a user dialing in from one location (with
an EAP-capable proxy) might be able to successfully authenticate via
EAP, while the same user dialing into another location (and encounter-
ing an EAP-incapable proxy) might be consistently disconnected.
9. 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.
10. References
[1] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Protocol
(EAP)." RFC 2284, Merit Network, Inc., March 1998.
Calhoun, Rubens & Aboba [Page 15]
INTERNET-DRAFT 8 May 1998
[2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti-
cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
[3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April
1997.
[4] C. Rigney, W. Willats. "RADIUS Extensions." Work in progress,
draft-ietf-radius-ext-01.txt, Livingston, June, 1997.
[5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm." RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[6] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 1997.
[7] M. Slatalla, J. Quittner. "Masters of Deception." HarperCollins,
New York, 1995.
[8] B. Aboba, D. Simon. "PPP EAP TLS Authentication Protocol." Work
in progress, draft-ietf-pppext-eaptls-03.txt, Microsoft, April 1998.
[9] G. Carter. "PPP EAP ISAKMP Authentication Protocol." Work in
progress, draft-ietf-pppext-eapisakmp-00.txt, Entrust, November 1997.
11. Authors' Addresses
Pat R. Calhoun
Technology Development
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025
Phone: 847-548-0926
Fax: 650-786-6445
EMail: pcalhoun@toast.net
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: 425-936-6605
Calhoun, Rubens & Aboba [Page 16]
INTERNET-DRAFT 8 May 1998
EMail: bernarda@microsoft.com
r
Calhoun, Rubens & Aboba [Page 17]