ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track Glen Zorn
<draft-ietf-roamops-auth-01.txt > Microsoft
17 June 1997
Guidelines for the Secure Operation of RADIUS Proxies in Roaming
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-roamops-auth-01.txt>, and expires January 1, 1998. Please send
comments to the authors.
2. Abstract
Today, RADIUS proxy chaining is widely deployed for the purposes of
providing roaming services. This document provides guidelines for the
secure operation of RADIUS proxies within roaming systems.
2.1. Terminology
This document frequently uses the following terms:
Network Access Server
The Network Access Server (NAS) is the device that clients
contact in order to get access to the network.
RADIUS server
This is a server which provides for authentication/autho-
rization via the protocol described in [3], and for account-
ing as described in [4].
RADIUS proxy
In order to provide for the routing of RADIUS authentication
Aboba & Zorn [Page 1]
INTERNET-DRAFT 17 June 1997
and accounting requests, a RADIUS proxy can be employed. To
the NAS, the RADIUS proxy appears to act as a RADIUS server,
and to the RADIUS server, the proxy appears to act as a
RADIUS client.
Network Access Identifier
In order to provide for the routing of RADIUS authentication
and accounting requests, the userID field used in PPP (known
as the Network Access Identifier or NAI) and in the subse-
quent RADIUS authentication and accounting requests, can
contain structure. This structure provides a means by which
the RADIUS proxy will locate the RADIUS server that is to
receive the request.
Roaming relationships
Roaming relationships include relationships between compa-
nies and ISPs, relationships among peer ISPs within a roam-
ing association, and relationships between an ISP and a
roaming consortia. Together, the set of relationships form-
ing a path between a local ISP's authentication proxy and
the home authentication server is known as the roaming rela-
tionship path.
3. Introduction
Today, as described in [1], RADIUS proxy chaining is widely deployed
for the purposes of providing roaming services. In such systems,
RADIUS authentication and accounting packets are routed between a NAS
device and a home RADIUS server through a series of RADIUS proxies.
The purpose of this document is to provide guidelines for the secure
operation of such systems.
An example of such a proxy chaining system is shown below. In the
example, BIGCO has contracted with ISPA to provide roaming services.
In turn ISPA has joined a roaming consortia ISPGROUP. User Fred then
travels to another part of the world and dials into a NAS device oper-
ated by ISPB, who has also joined roaming consortia ISPGROUP. Fred
attempts to authenticate to the NAS device as fred@bigco.com, using
the PPP protocol and an authentication protocol such as PAP, CHAP, or
EAP.
+------------+ +------------+ +------------+
| | | | | |
| ISPB | | BIGCO | | ISPA |
| Router | | RADIUS |<---------| RADIUS |
| | | Server | | Proxy |
| | | | | |
+------------+ +------------+ +------------+
| ^
| |
RADIUS | |
Protocol | Inter-organizational |
| RADIUS Events |
Aboba & Zorn [Page 2]
INTERNET-DRAFT 17 June 1997
| |
| |
V V
+------------+ +------------+
| | | |
| ISPB | Inter-organizational | ISPGROUP |
| RADIUS |<----------------------------->| RADIUS |
| Proxy |\ RADIUS Events | Proxy |
| | \ | |
| | \ | |
+------------+ \ +------------+
^ \
| \ Intra-organizational
RADIUS | \ RADIUS Events
Protocol | \
| \
| \
| \
| \
+------------+ +------------+
| | | |
| ISPB | | ISPB |
| NAS | | RADIUS |
| | | Server |
| | | |
+------------+ +------------+
^
|
PPP |
Protocol |
|
V
+------------+
| |
| |
| Fred |
| |
| |
+------------+
In the system shown above, Fred connects to the NAS of ISPB, and
authenticates using PPP. ISPB's NAS then sends a RADIUS Access-Request
packet to ISBP's RADIUS proxy, which routes the authentication based
on the domain included in the user name fred@bigco.com.
Either via use of configuration files or some other method, ISPB will
forward the RADIUS Access-Request to the ISPGROUP RADIUS proxy, which
will in turn forward it to the ISPA proxy, who will forward it on to
BIGCO's RADIUS server. While the RADIUS protocol, described in [3]
does not provide even hop-by-hop authentication of Access-Requests,
such authentication is possible using the Signature attribute
described in [6].
Aboba & Zorn [Page 3]
INTERNET-DRAFT 17 June 1997
BIGCO's RADIUS server will then respond with a RADIUS Access-Reply,
which will in turn be forwarded to the ISPA proxy, who will forward it
to the ISPGROUP proxy, where it will be forwarded to ISPB's proxy who
will pass it on to the NAS. The RADIUS protocol, described in [3],
does provide for authentication of Access-Replies, and thus it is not
required to add a Signature attribute to Access-Reply packets.
If RADIUS accounting is used, a similar sequence of events will occur,
with a RADIUS Accounting-Request being forwarded from the NAS to the
BIGCO RADIUS serer, and an Accounting-Reply being forwarded from
BIGCO's RADIUS server to the NAS.
4. Trust models
In conventional ISP application, the NAS, RADIUS proxy, and RADIUS
server typically exist within a single administrative entity. As a
result, the RADUS proxy and RADIUS server may be considered to be
trusted components.
However, in a roaming system implemented with proxy chaining, the NAS,
RADIUS proxies, and RADIUS server may be managed by different adminis-
trative entities. Through the use of shared secrets it is possible for
RADIUS proxies operating in different domains to establish a trust
relationship. However, since RADIUS packets are only authenticated on
a hop-by-hop basis, proxy chaining systems deployed in roaming operate
without end-to-end authentication. This means that in such systems
security is only as strong as the weakest link in the proxy chain.
Among other things, this implies that it is advisable to keep the
chain as short as possible. To date, as described in [1], existing
roaming implementations have been limited in scale, forwarding RADIUS
packets over a maximum of two hops, or implementing star configura-
tions with all systems connecting to a single trusted entity. Such
configurations minimize trust issues.
5. Security issues
Since current roaming implementations operate in more than 150 coun-
tries and service millions of users, it is critical that RADIUS proxy
chaining implementations be secure. In particular, protection must be
provided against the following attacks:
Theft of passwords
Replay attacks
Attribute editing
Connection hijacking
Authentication routing attacks
Fraudulent accounting records
Aboba & Zorn [Page 4]
INTERNET-DRAFT 17 June 1997
5.1. Theft of passwords
In the case where clients authenticate using PAP, each RADIUS proxy
along the path between the local NAS and the home RADIUS server will
have access to the cleartext password. In many circumstances, this
represents an unacceptable security risk, and as a result, it is rec-
ommended that PAP SHOULD NOT be used in roaming. A possible exception
to this recommendation occurs in situations where PAP is used in order
to pass a one time password or token.
It should also be noted that the EAP MD5 authentication method is also
subject to attacks by rogue RADIUS proxies. In such an attack a RADIUS
proxy substitutes a static challenge for the EAP MD5 challenge sent by
the RADIUS server, and on receiving the EAP Response, checks it
against a databases of hashes applied against a dictionary. As a
result, it is recommended that the EAP MD5 authentication method
SHOULD NOT be used in roaming.
Use of EAP MD5 and PAP authentication methods can be avoided by
instrucing the PPP authenticating peer to refuse these authentication
methods if offered.
5.2. Replay attacks
In this attack, a man in the middle or rogue RADIUS proxy collects
CHAP-Challenge and CHAP-Response attributes, and later replays them.
If this attack is performed in collaboration with an unscrupulous ISP,
it can be used to subsequently submit fraudulent accounting records to
the accounting agent for payment. The system performing the replay
need not necessarily be the one that initially captured the CHAP Chal-
lenge/Response pair.
While such an attack has always been possible, without roaming the
threat is restricted to RADIUS proxies operating in the home server's
domain. With roaming, such an attack can be mounted by any RADIUS
proxy capable of reaching the home RADIUS server.
In order to detect replay attacks, RADIUS servers used in roaming
SHOULD keep a log of CHAP challenges, so as to allow the log to be
checked for replays.
5.3. Attribute editing
In this attack, a RADIUS proxy modifies RADIUS Access-Accepts coming
back from the RADIUS server so as to lessen the security obtained by
the client. For example, EAP attributes might be removed or modified
so as to cause a client to authenticate with EAP MD5 or PAP, instead
of a stronger authentication method. Alternatively, tunnel attributes
might be removed or modified so as to remove encryption, redirect the
tunnel to a rogue tunnel server, or otherwise lessen the security pro-
vided to the client.
Aboba & Zorn [Page 5]
INTERNET-DRAFT 17 June 1997
In order to prevent inappropriate modification of RADIUS attributes in
transit, intermediate RADIUS proxies MUST NOT edit, add, or delete
attributes, except to provide the functions required in this document
e.g. hop-by-hop authentication using the Signature attribute, or trace
route functionality provided via the Route attribute.
Editing of Access-Accepts MAY be performed by the local RADIUS proxy.
However, the local RADIUS proxy MUST NOT edit attributes relating to
EAP or tunneling. In addition, RADIUS proxies MUST NOT change the
fundamental meaning of a RADIUS message, i.e. substitute a RADIUS
Access-Accept for a RADIUS Access-Reject.
Inappropriate attribute editing need not occur due to acts of malice.
The vast majority of such problems are likely to result from miscon-
figuration of RADIUS proxies. In fact, it is expected that as roaming
grows in popularity, attribute editing problems will become
widespread. This is likely since several proxy implementations remove
attributes that they do not understand, or can be set up to replace
attribute sets sent in the Access-Accept with sets of attributes
appropriate for a particular network.
Since RADIUS only provides for hop-by-hop authentication, it is not
possible to provide end-to-end integrity checks within proxy chaining
systems. However, in order to provide for detection of inappropriate
attribute editing, local RADIUS proxies and home RADIUS servers SHOULD
implement auditing functionality.
For example, the local RADIUS proxy SHOULD include RADIUS attributes
received in the Access-Accept within the session record or Accounting-
Start meesage for the session. Similarly, operators of home RADIUS
servers SHOULD log the contents of RADIUS Access-Replies sent, and
SHOULD periodically check for discrepancies between attributes sent in
RADIUS Access-Replies, and attributes received by local proxies. In
order to prevent intermediate proxies from modifying accounting
records, accounting records SHOULD NOT travel the same path taken by
RADIUS authentication. Instead, accounting records SHOULD be sent
directly between the local proxy and the systems requiring copies of
the accounting records.
5.4. Connection hijacking
In this form of attack, the attacker attempts to inject packets into
the conversation between the NAS and the home RADIUS server. RADIUS as
described in [3] is vulnerable to such attacks since only Access-Reply
and Access-Challenge packets are authenticated.
In order to provide for authentication of Access-Request packets,
RADIUS proxies operating in roaming systems MUST support the Signature
attribute, as decribed in [9]. RADIUS proxies used in roaming imple-
mentations MUST check for the presence of the Signature attribute in
Access-Requests forwarded to them from other proxies, and MUST
silently discard Access-Request packets missing the Signature
attribute or failing authentication. RADIUS proxies operating in
Aboba & Zorn [Page 6]
INTERNET-DRAFT 17 June 1997
roaming systems also MUST include a Signature attribute in all for-
warded Access-Request packets.
5.5. Authentication routing attacks
In roaming, one of the functions of the RADIUS proxy is to route
authentications between domains. Authentication routing attacks
affect the core of a roaming system by modifying authentication rout-
ing information, thus disabling the system or causing RADIUS packets
to be routed inappropriately.
Since to date roaming has been implemented on a relatively small
scale, existing implementations perform authentication routing based
on local knowledge expressed in proxy configuration files. To date
implementations have not found a need for dynamic routing protocols,
or propagation of global routing information.
Since authentication routing information is fundamental to the opera-
tional of a roaming system, routing information SHOULD be propagated
using an transfer method supporting mutual authentication, such as
such as Kerberized rcp, SSH or TLS.
Since all RADIUS packets used in roaming are secured by a shared
secret, such attacks will not rsult in more than a denial of service,
as long as the attacker did not also obtain the shared secrets.
As with attribute editing, it is expected that most problems of this
type will result from misconfiguration of RADIUS proxies. In order to
detect such misconfigurations, RADIUS proxies participating in roaming
MUST implement the Route attribute described below. The Route
attribute provides trace route and/or source route capabilities. This
allows a local RADIUS proxy to specify a route through which an
Access-Request must travel, or for a home RADIUS server to determine
whether to authorize Access-Requests routed on a given roaming rela-
tionship path.
A RADIUS proxy receiving a Route attribute with the Trace option set
MUST append the domain of the system from which it received the packet
to the end of the Route attribute prior to forwarding it.
5.6. Fraudulent accounting records
In this form of attack, a local RADIUS proxy transmits fraudulent
accounting packets or session records to the accounting agent in an
effort to collect fees to which they are not entitled.
In order to detect submission of fraudulent accounting records by an
unscrupulous ISP, the the accounting gateway SHOULD send copies of
session records to all parties with a financial interest in the ses-
sion. Parties receiving copies of these session records SHOULD recon-
cile them with logs of proxied authentications.
Aboba & Zorn [Page 7]
INTERNET-DRAFT 17 June 1997
In order to make it easier to match RADIUS authentication logs with
accounting records, RADIUS servers involved in roaming SHOULD include
a Class attribute in the Access-Accept. The Class attribute should
uniquely identify a session, so as to allow an authentication log
entry to be matched with a corresponding accounting record.
In order to be able to match accounting records with logs of proxied
RADIUS authentications, accounting agents SHOULD require that they act
as an authentication proxy for all sessions for which an accounting
record will subsequently be submitted.
6. Proposed RADIUS attributes for use in roaming
6.1. Route
Description
In a roaming implementation based on proxy chaining, RADIUS packets
are routed between the NAS and RADIUS server through a series of
RADIUS proxies. This attribute allows for the authentication route
taken by a RADIUS Access-Request, Access-Challenge, or Access-Reply
packet to be recorded within the packet, or alternatively, for a
source-route to be specified. RADIUS proxies receiving an Access-
Request message with a Source-Route attribute MUST either honor the
attribute or return an Access-Reject.
A summary of the Route 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 | Flags | String
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
? for Route
Length
>=3
Flags
The Flags field indicates the intended purpose of the Route
attribute:
0
0 1 2 3 4 5 6 7 8
Aboba & Zorn [Page 8]
INTERNET-DRAFT 17 June 1997
+-+-+-+-+-+-+-+-+
|T S L D R R R R|
+-+-+-+-+-+-+-+-+
T = Trace. If T=1, then the string represents a trace route request,
and
a RADIUS proxy receiving a Route option set MUST append the doma
in of
system from which it received the packet to the end of the Route
prior to forwarding it.
S = Source route. If S=1 then the string field represents a source r
oute.
L = Loose. If L=1 and S=1, then the string field represents a loose
source route. If L=0 and S=1, then the route represents a strict
source
route. The combinations S=0, L=1 and T=1, S=1 are not permitted.
R = Reserved.
D = Direction. If D=1, the Route attribute is relevant to an Access-
Request or
Accounting-Request packet; if D=0, the Route attribute is releva
nt to an
Access-Reply, Access-Challenge or Accounting-Reply packet.
String
The String field includes the route, which is represented as a
series of domains separated by the "/" character. For example, a
valid source route is ispb.com/ispgroup.com/ispa.com/bigco.com/.
If trace routing is used, then a RADIUS proxy receiving a packet
from another proxy MUST append the domain of the sender onto the
end of the Route attribute, prior to forwarding it. Note that
the Route attribute is represented as a domain path, NOT a path
comprised of the IP addresses or fully qualified domain names of
the RADIUS proxies themselves. Thus, it is expected that RADIUS
proxies implementing the Route attribute will be able to trans-
late the IP address of the sending proxy into the appropriate
domain for use in the Route attribute. This is typically accom-
plished through proxy configuration files.
Since a single RADIUS attribute may only be 253 octets in
length, if the Route attribute is larger than this, it may be
necessary to split the contents across multiple Route
attributes. In order to permit Route attributes to exceed 253
octets, Route attributes with identical values of the Flags
field are to be concatenated prior to interpretation.
However, Route attributes with different values of the Flags
field MUST NOT be concatenated, since it is possible for multi-
ple Route attributes to be required within a packet. For exam-
ple, it is possible for a packet to contain one Route attribute
with T=1,S=0 indicating a trace request, and another Route
attribute with T=0, S=1, L=1, indicating the presence of a Loose
Source route. In this case, a Loose Source Route is presented at
the same time that it is requested that the actual route be
recorded and returned.
Aboba & Zorn [Page 9]
INTERNET-DRAFT 17 June 1997
7. Acknowledgments
Thanks to Pat Calhoun of USR for useful discussions of this problem
space.
8. References
[1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming
Implementations." Internet draft (work in progress), draft-ietf-
roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo,
Merit, June, 1997.
[2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet
draft (work in progress), draft-ietf-roamops-roamreq-04.txt,
Microsoft, June, 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] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC
2068, UC Irvine, January, 1997.
[6] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work
in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
[7] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC
1321, MIT Laboratory for Computer Science, RSA Data Security Inc.,
April 1992.
[8] S. Bradner. "Key words for use in RFCs to Indicate Requirement
Levels." RFC 2119, Harvard University, March, 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
Aboba & Zorn [Page 10]
INTERNET-DRAFT 17 June 1997
EMail: glennz@microsoft.com
Aboba & Zorn [Page 11]
