ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Best Current Practice John R. Vollbrecht
<draft-ietf-roamops-auth-03.txt> Merit Networks, Inc.
8 September 1997 Glen Zorn
Microsoft
Guidelines for the 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-03.txt>, and expires March 1, 1998. Please send
comments to the authors.
2. Abstract
Today, while RADIUS proxy chaining is widely deployed for the purposes
of providing roaming services, interoperation between roaming systems
is difficult. This document provides guidelines for the operation of
RADIUS proxies within roaming systems.
3. 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].
Aboba, Vollbrecht & Zorn [Page 1]
INTERNET-DRAFT 8 September 1997
RADIUS proxy
In order to provide for the routing of RADIUS authentication
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.
4. Requirements language
This specification uses the same words as [8] 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
Aboba, Vollbrecht & Zorn [Page 2]
INTERNET-DRAFT 8 September 1997
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 "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. 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 opera-
tion of such systems.
An example of a proxy chaining system is shown below.
(request) (request) (request)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS
(reply) (reply) (reply) Server
<--------- <--------- <---------
In the above diagram, the NAS generates a RADIUS request and sends it
to Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards
the request to the Home Server. The Home Server generates a reply and
sends it to Proxy2. Proxy2 receives the reply, matches it with the
request it had sent, and forwards a reply to Proxy1. Proxy1 matches
the reply with the request it sent earlier and forwards a reply to the
NAS. This model applies to all RADIUS requests, including Access
Requests and Accounting Requests. Except where policy is being imple-
mented (described below), a proxy server such as Proxy2 in the diagram
below SHOULD NOT send a Reply packet to Proxy1 without first having
received a Reply packet initiated by the home RADIUS server.
While the RADIUS protocol described in [3] does not provide for
authentication of Access-Requests, such authentication is possible
using the Signature attribute described in [5]. Proxies SHOULD include
the Signature attribute in Access-Requests. Since the RADIUS protocol,
described in [3], does support authentication of Access-Reply packets,
the Signature attribute is not required in an Access-Reply.
Aboba, Vollbrecht & Zorn [Page 3]
INTERNET-DRAFT 8 September 1997
5.1. Route determination
In RADIUS proxy chaining, the forwarding function is carried out based
on the realm portion of the Network Access Identifier (NAI), defined
in [9]. While the mechanism by which the path is selected is implemen-
tation dependent, existing implementations typically use static for-
warding tables set in their configuration files.
If source routing is desired, a local proxy may use the Route
attribute described in [10] to define a loose or strict source route.
Intermediate proxies that cannot honor the loose or strict source
route request SHOULD send an Access-Reject to the upstream proxy or
NAS and an Accounting message with Acct-Status-Type=Proxy-Stop to the
Home Server.
If a traceroute is desired, a local proxy may use the Route attribute
described in [10] to request a traceroute be performed. Through use of
multiple Route attributes, a traceroute may be performed along with a
loose source route request.
Note that in forwarding an Access-Request, a proxy may choose to route
a request through an alternate realm if the proxies for a downstream
realm are not available. In the case where alternate routes may be
chosen, a traceroute request SHOULD be included within the Access-
Request. On receiving an Access-Request containing a traceroute, the
home server SHOULD respond with an Access-Reply containing a strict
source-route request, with the strict source-route set to the route
contained in the traceroute. This ensures that the Access-Reply is
sent back over the same path travelled by the Access-Request. On
receiving an Access-Accept containing a traceroute or source-route,
the local proxy SHOULD include a source-route request within the
Accounting-request for that session. This will ensure that the
Accounting-request will follow the same realm path as did the Access-
Request and Access-Accept.
5.2. Policy implementation
RADIUS proxies are frequently used to implement policy in roaming sit-
uations. RADIUS proxies implementing policy MAY reply directly to
Access-Requests without forwarding the request. When replying directly
to an Access-Request, the proxy MUST reply either with an Access-
Reject or an Access-Challenge packet. A RADIUS proxy MUST NOT reply
directly with an Access-Accept. An example of this would be when the
proxy refuses all connections from a particular realm during prime
time. In this case the home server will never receive the Access-
Request. This situation is shown below:
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home RADIUS
(reply) (reply) Server
<--------- <---------
Aboba, Vollbrecht & Zorn [Page 4]
INTERNET-DRAFT 8 September 1997
A proxy MAY also decide to Reject a Request that has been accepted by
the home server. This could be based on the set of attributes
returned by the home server. In this case the Proxy SHOULD send an
Access-Reject to the NAS and an Accounting message with Acct-Status-
Type=Proxy-Stop to the home server. This lets the Home Server know
that the session it approved has been denied downstream by the Proxy.
However, a proxy MUST NOT send an Access-Accept after receiving an
Access-Reject from a proxy or from the home server.
(Access-Req) (Access-Req) (Access-Req)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS
(Access-Reject) (Access-Accept) (Access-Accept) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
5.3. Accounting behavior
As described above, a proxy MUST NOT reply directly with an Access-
Accept, and MUST NOT reply with an Access-Accept when it has received
an Access-Reject from another proxy or Home Server. As a result, in
all cases where an accounting record is to be generated (accepted ses-
sions), no direct replies have occurred, and the Access-Request and
Access-Accept have passed through the same set of systems.
In order to allow proxies to match incoming Accounting-Requests with
previously handled Access-Requests and Access-Accepts, a proxy SHOULD
route the Accounting-Request along the same realm path travelled in
authentication/authorization. Note that this does not imply that
accounting packets will necessarily travel the identical path as did
authentication/authorization packets, machine by machine. This is
because it is conceivable that a RADIUS proxy may have gone down, and
as a result the Accounting-request may need to be forwarded to an
alternate server. It is also conceivable that authentication/autho-
rization and accounting may be handled by different servers within a
realm.
The Class attribute can be used to match accounting requests with
prior access requests. It can also be used to match session log
records between the home Server, proxies, and NAS. This matching can
be accomplished either in real-time (in the case that authentication
and accounting packets follow the same path, machine by machine), or
after the fact.
Home servers SHOULD insert a unique session identifier in the Class
attribute in an Access-Accept and Access-Challenge. Proxies and NASes
MUST forward the Class attribute. The NAS MUST include the Class
attribute in subsequent requests, in particular for Accounting-
Requests. The sequence of events is shown below:
Authentication/Authorization
Aboba, Vollbrecht & Zorn [Page 5]
INTERNET-DRAFT 8 September 1997
--------> --------> --------->
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
Accounting
(Accounting-req) (Accounting-req) (Accounting-req)
w/class w/class w/class
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS
(Accounting-reply) (Accounting-reply)(Accounting-reply) Server
<--------- <--------- <---------
Since there is no need to implement policy in RADIUS accounting, a
proxy SHOULD NOT reply directly to Accounting-Requests, and a proxy
server such as Proxy2 in the diagram below SHOULD NOT send an Account-
ing-Reply packet to Proxy1 without first having received an Account-
ing-Reply packet initiated by the home RADIUS server. This ensures
when a NAS receives an Accounting-Reply the Accounting-Request will
have been received by all systems along the authentication/authoriza-
tion path.
Note that there are cases where a proxy may need to forward an
Accounting packet to more than one system. For example, in order to
allow for proper accounting in the case of a NAS that is shutting
down, the proxy may need to send an Accounting-Request with Acct-Sta-
tus-Type=Accounting-Off to all realms that it forwards to. In turn,
these proxies will also flood the packet to their connected realms.
6. Allowable editing behavior
One of the biggest obstacles to interoperation of proxies today
results from editing behavior. As roaming grows in popularity,
attribute editing problems are becoming common.
Today 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. In order to prevent inappropriate modification of RADIUS
attributes this document describes what attributes may be added,
edited, deleted, or processed by authentication and accounting prox-
ies.
A local proxy (a proxy downstream from a NAS) MAY edit or delete
attributes within Access-Requests, as described in the table below. An
intermediate proxy (a proxy downstream from another proxy) SHOULD NOT
edit or delete attributes when forwarding Access-Requests.
Local proxies MAY edit or delete attributes in an Access-Reply, if the
downstream server is a NAS which is not able to interpret some
attributes, and if the attributes are marked with edit or delete per-
mission in the table below. If edit or delete permission is not indi-
cated, then if a NAS is not able to interpret these attributes, then
Aboba, Vollbrecht & Zorn [Page 6]
INTERNET-DRAFT 8 September 1997
the proxy SHOULD send an Access-Reject to the NAS and an Accounting
message with Acct-Status-Type=Proxy-Stop to the home server. Interme-
diate proxies SHOULD NOT edit or delete attributes in an Access-Reply.
A local Proxy may need to translate some attributes in the Access-
Accept to support a particular service. For example, translation could
be done to support a common set of IP filters on NASs from different
vendors. However, translation should be done only to support a common
service. Intermediate proxies SHOULD NOT translate attributes.
Local or intermediate proxies MAY interpret attributes they receive
and MAY add attributes to Access-Request, Access-Reply, Access-Chal-
lenge, and Accounting-Request messages, as noted in the table below. A
Proxy that adds attributes MUST precede the additional attributes with
a "Proxy-State" attribute containing as its leading string the IP-
Address of the Proxy. This permits downstream proxies to understand
what attributes have been added and aids in debugging. Proxies MUST
maintain attribute order when forwarding.
An intermediate proxy SHOULD NOT edit or delete attributes within
Accounting-Requests. A local proxy MAY edit or delete attributes
within Accounting-Requests, as described in the table below. However,
since proxies will already have had the opportunity to edit the
attributes while forwarding authentication/authorization packets, the
attributes sent in the Accounting-Request reflect the actual parame-
ters in effect for the session. As a result, the intermediate proxy or
the home server MAY wish to match the attributes sent in the Access-
Request, Access-Challenge, or Access-Accept against those in the
Accounting-Request in order to generate an audit trail or aid in
debugging. In order to support the auditing and debugging process, the
scope for editing or deletion of attributes in Accounting-Requests is
reduced.
AUTHENTICATION
Request Accept Reject Challenge # Attribute
E A 1 User-Name [note 1]
PD 2 User-Password [note 2]
A 3 CHAP-Password [note 2]
AED 4 NAS-IP-Address [note 4]
AE 5 NAS-Port
AE AE 6 Service-Type
AE AE 7 Framed-Protocol
AE AE 8 Framed-IP-Address
AE AE 9 Framed-IP-Netmask
AED 10 Framed-Routing
AE 11 Filter-Id [note 5]
AE 12 Framed-MTU
AE AE 13 Framed-Compression
AE AE 14 Login-IP-Host
AE 15 Login-Service
AE 16 Login-TCP-Port
AE AE AE 18 Reply-Message
AE AE 19 Callback-Number [note 3]
Aboba, Vollbrecht & Zorn [Page 7]
INTERNET-DRAFT 8 September 1997
A 20 Callback-Id
AED 22 Framed-Route
AED 23 Framed-IPX-Network
AE AE AE 24 State
AE 25 Class
AED AED AED 26 Vendor-Specific
AE AE 27 Session-Timeout
AE AE 28 Idle-Timeout
AE 29 Termination-Action
AE 30 Called-Station-Id [note 3]
AE 31 Calling-Station-Id [note 3]
AE 32 NAS-Identifier [note 4]
AP AP AP AP 33 Proxy-State
AE AE 34 Login-LAT-Service
AE AE 35 Login-LAT-Node
AE AE 36 Login-LAT-Group
AE 37 Framed-AppleTalk-Link
AED 38 Framed-AppleTalk-Network
AED 39 Framed-AppleTalk-Zone
60 CHAP-Challenge
AE 61 NAS-Port-Type
AE AE 62 Port-Limit
AE AE 63 Login-LAT-Port
64 Tunnel-Type
65 Tunnel-Medium-Type
67 Tunnel-Server-Endpoint
P 69 Tunnel-Password
AP 70 ARAP-Password
AE AE 71 ARAP-Features
AE 72 ARAP-Zone-Access
A A 73 ARAP-Security
A A 74 ARAP-Security-Data
ED 75 Password-Retry
AE 76 Prompt
77 Connect-Info
AED 78 Configuration-Token
79 EAP-Message
AP 80 Signature
P P P P ? Route
ED ? Acct-Interim-Interval
Request Accept Reject Challenge # Attribute
The following table defines the meaning of the entries above.
A This attribute MAY be added
E This attribute MAY be edited. Editing is defined as a change
beyond that required in hop-by-hop processing as described
in [3]-[5].
D This attribute MAY be deleted.
P This attribute MUST be processed as described in [3]-[5].
Notes
1. A proxy may strip the realm from the User-Name, so as to provide
Aboba, Vollbrecht & Zorn [Page 8]
INTERNET-DRAFT 8 September 1997
compatibility with proxies that cannot handle this.
2. Use of PAP is considered undesirable in roaming, since each RADIUS
proxy handling the Access-Request will have access to the cleartext
password. As a result, if the user uses PAP to authenticate with the
NAS, and the NAS sends the User-Password to the proxy (secure network)
the proxy MAY convert it to CHAP before sending it to the home server
(insecure network). In some situations this would be desirable (fewer
proxies would have access to the password), and in others it would be
undesirable (the home NAS has no way to know that it was only PAP that
was done).
3. A proxy may edit these attributes in order to make them more spe-
cific. For example, the proxy might need to change Callback-Number =
"7771111" to Callback-Number = "5107771111".
4. A local proxy may replace the NAS-IP-Address attribute with a NAS-
Identifier attribute in order to releave other proxies or servers of
the need to understand the underlying network topology, making it eas-
ier for those proxies to make a decision whether to permit the Access-
Request. For example, a local proxy might replace a NAS-IP-Address of
128.10.13.1 with a NAS-Identifier of "BIG ISP NAS 1."
5. Editing of the Filter-Id attribute may be undertaken only by a
local proxy, in order to provide a common filter service between NASes
of different types.
ACCOUNTING
Request Reply # Attribute
1 User-Name
2 User-Password
3 CHAP-Password
AED 4 NAS-IP-Address
AE 5 NAS-Port
A 6 Service-Type
A 7 Framed-Protocol
A 8 Framed-IP-Address
A 9 Framed-IP-Netmask
A 10 Framed-Routing
A 11 Filter-Id
A 12 Framed-MTU
A 13 Framed-Compression
A 14 Login-IP-Host
A 15 Login-Service
A 16 Login-TCP-Port
18 Reply-Message
AE 19 Callback-Number [note 3]
A 20 Callback-Id
A 22 Framed-Route
A 23 Framed-IPX-Network
24 State
A 25 Class
A 26 Vendor-Specific
Aboba, Vollbrecht & Zorn [Page 9]
INTERNET-DRAFT 8 September 1997
A 27 Session-Timeout
A 28 Idle-Timeout
A 29 Termination-Action
AE 30 Called-Station-Id [note 3]
AE 31 Calling-Station-Id [note 3]
AED 32 NAS-Identifier
AP 33 Proxy-State
A 34 Login-LAT-Service
A 35 Login-LAT-Node
A 36 Login-LAT-Group
A 37 Framed-AppleTalk-Link
A 38 Framed-AppleTalk-Network
A 39 Framed-AppleTalk-Zone
40 Acct-Status-Type
41 Acct-Delay-Time [note 1]
42 Acct-Input-Octets
43 Acct-Output-Octets
E 44 Acct-Session-Id [note 2]
45 Acct-Authentic
46 Acct-Session-Time
47 Acct-Input-Packets
48 Acct-Output-Packets
49 Acct-Terminate-Cause
E 50 Acct-Multi-Session-Id [note 2]
51 Acct-Link-Count
60 CHAP-Challenge
A 61 NAS-Port-Type
A 62 Port-Limit
A 63 Login-LAT-Port
64 Tunnel-Type
65 Tunnel-Medium-Type
66 Acct-Tunnel-Client-Endpoint
67 Tunnel-Server-Endpoint
68 Acct-Tunnel-Connection-ID
69 Tunnel-Password
70 ARAP-Password
A 71 ARAP-Features
A 72 ARAP-Zone-Access
A 73 ARAP-Security
A 74 ARAP-Security-Data
75 Password-Retry
76 Prompt
77 Connect-Info
78 Configuration-Token
79 EAP-Message
80 Signature
P P ? Route
A ? Acct-Interim-Interval
Accounting Accounting
Request Reply # Attribute
1. If the proxy can calculate the additional delay it is introducing,
it should increment this.
Aboba, Vollbrecht & Zorn [Page 10]
INTERNET-DRAFT 8 September 1997
2. The proxy may need to modify the NAS identification to hide private
network information. In that case, it may forward packets with itself
as the NAS, and will need to construct an Acct-Session-Id that is
guaranteed to be unique. For example, if the proxy gets packets from
16 NASs, session '3478617' on the 11th NAS might be given the new ses-
sion ID 'A3478617'.
3. A proxy may edit these attributes in order to make them more spe-
cific. For example, the proxy might need to change Callback-Number =
"7771111" to Callback-Number = "5107771111".
7. 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:
Rogue proxies
Theft of passwords
Theft of accounting data
Replay attacks
Attribute editing
Connection hijacking
Authentication routing attacks
Fraudulent accounting
7.1. Rogue proxies
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.
Aboba, Vollbrecht & Zorn [Page 11]
INTERNET-DRAFT 8 September 1997
Through use of the Route attribute described above, it is possible for
a RADIUS proxy or server to decide whether it wishes to trust a packet
arriving via a particular route. Since it is the receiving proxy that
adds the previous hop to the route, without collusion a rogue proxy
cannot avoid having itself listed in the route, although it can add,
delete, or alter prior entries.
A proxy or server may decide not to trust any route including a par-
ticular system or set of systems as an intermediate proxy, or as an
originating or terminating system.
7.2. 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.
7.3. Theft of accounting data
Since RADIUS accounting does not provide for encryption of accounting
data, when real-time accounting is used, it is possible for an inter-
mediate system to gain access to accounting information passing over
the wire. Such access may or may not be possible when session record
accounting is used, depending on whether encryption is used in the
accounting record transfer.
7.4. 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.
CHAP replay attacks can be defeated by means of an end-to-end chal-
lenge-response exchange. For example, if the home RADIUS server
Aboba, Vollbrecht & Zorn [Page 12]
INTERNET-DRAFT 8 September 1997
returns an Access-Challenge packet containing a CHAP-Challenge
attribute and maintains state with respect to outstanding challenges,
replay attacks will not work.
However, it should also be noted that end-to-end challenges (as prac-
ticed within the EAP MD5 authentication method, or in the CHAP-Chal-
lenge method described above) are subject to attacks by rogue RADIUS
proxies. In such an attack a RADIUS proxy substitutes a static chal-
lenge for the challenge sent by the home RADIUS server, and on receiv-
ing the response, checks it against a databases of hashes applied
against a dictionary.
Use of the CHAP and PAP authentication methods may be avoided entirely
by instructing the PPP authenticating peer to refuse these authentica-
tion methods if offered.
7.5. Attribute editing
In this attack, a RADIUS proxy modifies an Access-Accept sent by 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 provided to
the client.
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 message for the session. Similarly, home RADIUS servers SHOULD
log the contents of RADIUS Access-Replies sent, and SHOULD periodi-
cally check for discrepancies between attributes sent in RADIUS
Access-Replies, and attributes received by local proxies.
Proxy Servers that modify or add attributes in any RADIUS Request MUST
log the Request as received and as modified in order to make it possi-
ble to audit requests in both directions.
In order to allow for detection of modification of accounting packets
by intermediate proxies, roaming consortia may implement both real-
time and session record accounting. In this case, session records
SHOULD NOT travel the same path taken by RADIUS accounting packets.
Instead, session records SHOULD be sent directly between the local
proxy and the systems requiring copies of the session records.
Aboba, Vollbrecht & Zorn [Page 13]
INTERNET-DRAFT 8 September 1997
7.6. 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 roam-
ing systems also MUST include a Signature attribute in all forwarded
Access-Request packets.
7.7. 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
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.
Aboba, Vollbrecht & Zorn [Page 14]
INTERNET-DRAFT 8 September 1997
7.8. Fraudulent accounting
In this form of attack, a local RADIUS proxy transmits fraudulent
accounting packets or session records in an effort to collect fees to
which they are not entitled. This includes submission of packets or
session records for non-existent sessions, or submission of exagger-
ated session times for actual sessions. Such behavior will only be
easily detectable in the event that roaming users are making use of
voluntary or compulsory tunneling, in which case the tunnel server
(presumed to exist at BIGCO) will generate its own accounting record,
which may be compared to that generated by the local ISP. However,
tunneling is expected to represent only a small percentage of roaming
use.
In order to detect submission of fraudulent accounting packets or ses-
sion records, the the accounting gateway SHOULD send copies of session
records to all parties with a financial interest in the session. Par-
ties receiving copies of these session records SHOULD reconcile them
with logs of proxied authentications.
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 log.
In order to be able to match accounting logs 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.
8. Acknowledgments
Thanks to Pat Calhoun of 3COM, Mark Beadles of CompuServe, Aydin
Edguer of Morningstar, and Steven P. Crain of Shore.Net for useful
discussions of this problem space.
9. 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 2138, Livingston, Merit,
Daydreamer, April, 1997.
Aboba, Vollbrecht & Zorn [Page 15]
INTERNET-DRAFT 8 September 1997
[4] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April,
1997.
[5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work
in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997.
[6] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC
2068, UC Irvine, 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] B. Aboba. "The Network Access Identifier." Internet draft (work
in progress), draft-ietf-roamops-nai-06.txt, Microsoft, July 1997.
[10] B. Aboba and J.R. Vollbrecht. "RADIUS Extensions for Roaming."
Internet draft (work in progress), draft-ietf-roamops-radius-00.txt,
Microsoft, Merit Networks, September 1997.
10. Authors' Addresses
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-936-6605
EMail: bernarda@microsoft.com
John R. Vollbrecht
Merit Network, Inc.
4251 Plymouth Rd.
Ann Arbor, MI 48105-2785
Phone: 313-763-1206
EMail: jrv@merit.edu
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: 425-703-1559
EMail: glennz@microsoft.com
Aboba, Vollbrecht & Zorn [Page 16]
Datatracker
draft-ietf-roamops-auth-03
This is an older version of an Internet-Draft that was ultimately published as RFC 2607.
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2607.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |