ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation
Category: Standards Track John R. Vollbrecht
<draft-ietf-roamops-auth-02.txt > Merit Networks, Inc.
21 July 1997 Glen Zorn
Microsoft
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-02.txt>, and expires February 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].
Aboba, Vollbrecht & Zorn [Page 1]
INTERNET-DRAFT 21 July 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.
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.
(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
returns 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.
RADIUS proxies implementing policy MAY send a reply without forwarding
the request. An example of this would be when the proxy refuses all
connections from a particular realm during prime time. In this case
Aboba, Vollbrecht & Zorn [Page 2]
INTERNET-DRAFT 21 July 1997
the home server will never receive the Access-Request. This situation
is shown below:
(request) (request)
NAS ----------> Proxy1 ----------> Proxy2 Home RADIUS
(reply) (reply) Server
<--------- <---------
The proxy SHOULD reply directly only to Access-Requests and SHOULD NOT
reply directly to Accounting-Requests. 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.
A proxy forwarding a request SHOULD NOT send a reply to a request
until it has received a reply from the server or proxy to which it
sent the corresponding request. The effect of this is that the NAS
will never see a reply which was not initiated by the home server. A
less pleasant consequence is that the delay between request and reply
at the NAS will be longer than if the reply were "faked" by a proxy.
A proxy MAY 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
the home server.
(AccReq) (AccReq) (AccReq)
NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS
(AccRejct) (AccAccpt) (AccAccpt) Server
<--------- <--------- <---------
(AcctPxStop) (AcctPxStop)
----------> ---------->
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 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.
The sequence of events is shown below:
--------> --------> --------->
Aboba, Vollbrecht & Zorn [Page 3]
INTERNET-DRAFT 21 July 1997
NAS Proxy1 Proxy2 Home (add class)
<-class-- <-class- <-class--
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.
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 MUST include
the Signature attribute in all Access-Requests. Since the RADIUS pro-
tocol, described in [3], does support authentication of Access-Reply
packets, the Signature attribute is not required in an Access-Reply.
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
Aboba, Vollbrecht & Zorn [Page 4]
INTERNET-DRAFT 21 July 1997
Fraudulent accounting records
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.
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.
CHAP replay attacks can be defeated by means of an end-to-end chal-
lenge-response exchange. For example, if the home RADIUS server
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.
Aboba, Vollbrecht & Zorn [Page 5]
INTERNET-DRAFT 21 July 1997
5.3. 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.
In order to prevent inappropriate modification of RADIUS attributes
the table in Appendix A describe what attributes may be added, edited,
deleted, or processed by authentication and accounting proxies.
Inappropriate attribute editing need not occur du 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 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. 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
Aboba, Vollbrecht & Zorn [Page 6]
INTERNET-DRAFT 21 July 1997
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.
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
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
Aboba, Vollbrecht & Zorn [Page 7]
INTERNET-DRAFT 21 July 1997
session. Parties 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 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
Aboba, Vollbrecht & Zorn [Page 8]
INTERNET-DRAFT 21 July 1997
attribute:
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
|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 domain 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 route.
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 relevant 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, Vollbrecht & Zorn [Page 9]
INTERNET-DRAFT 21 July 1997
7. Appendix A: Allowable Proxy Behavior
Proxies MAY interpret attributes they receive and MAY add attributes
to Access-Request, Access-Reply, Access-Challenge, and Accounting-
Request messages, as described below. Proxies MUST maintain attribute
order when forwarding. 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.
A Proxy may need to translate some attributes to support a particular
service. Translation should be done only to support a common service,
and only at the Proxy closest to the NAS. Translation could be done
to support a common set of IP filters on NASs from different vendors.
A local proxy (a proxy downstream from a NAS) MAY edit or delete
attributes within Access-Requests, as provided 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, as provided below, if
the downstream server is a NAS which is not able to interpret some
attributes. Intermediate proxies SHOULD NOT edit or delete attributes
in an Access-Reply.
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
AED 5 NAS-Port
AE AE 6 Service-Type
AE AE 7 Framed-Protocol
AED AED 8 Framed-IP-Address
AED AED 9 Framed-IP-Netmask
AED 10 Framed-Routing
AE 11 Filter-Id
AED 12 Framed-MTU
AED AED 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]
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]
Aboba, Vollbrecht & Zorn [Page 10]
INTERNET-DRAFT 21 July 1997
AED 31 Calling-Station-Id [note 4]
AED 32 NAS-Identifier
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
Request Accept Reject Challenge # Attribute
1. A proxy may strip the realm from the User-Name, so as to provide
compatibiltiy 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 proxy may wish to delete the Calling-Station-ID so as to protect
the privacy of the caller. As with note 2 above, this attribute may be
edited to make it more specific.
ACCOUNTING
Aboba, Vollbrecht & Zorn [Page 11]
INTERNET-DRAFT 21 July 1997
Request Reply # Attribute
1 User-Name
2 User-Password
3 CHAP-Password
AE 4 NAS-IP-Address
AE 5 NAS-Port
AE 6 Service-Type
AE 7 Framed-Protocol
AED 8 Framed-IP-Address
AED 9 Framed-IP-Netmask
AED 10 Framed-Routing
AE 11 Filter-Id
AED 12 Framed-MTU
AED 13 Framed-Compression
AE 14 Login-IP-Host
AE 15 Login-Service
AE 16 Login-TCP-Port
18 Reply-Message
A 19 Callback-Number
A 20 Callback-Id
AED 22 Framed-Route
AED 23 Framed-IPX-Network
24 State
AE 25 Class
AED 26 Vendor-Specific
AE 27 Session-Timeout
AE 28 Idle-Timeout
AE 29 Termination-Action
AED 30 Called-Station-Id
AED 31 Calling-Station-Id
AED 32 NAS-Identifier
AP 33 Proxy-State
AE 34 Login-LAT-Service
AE 35 Login-LAT-Node
AE 36 Login-LAT-Group
AE 37 Framed-AppleTalk-Link
AED 38 Framed-AppleTalk-Network
AED 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
AE 61 NAS-Port-Type
AE 62 Port-Limit
AE 63 Login-LAT-Port
Aboba, Vollbrecht & Zorn [Page 12]
INTERNET-DRAFT 21 July 1997
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
AE 71 ARAP-Features
AE 72 ARAP-Zone-Access
A 73 ARAP-Security
A 74 ARAP-Security-Data
ED 75 Password-Retry
76 Prompt
77 Connect-Info
78 Configuration-Token
79 EAP-Message
80 Signature
Accounting Accounting
Request Reply # Attribute
1. If the proxy can calculate the additional delay it is introducing,
it should increment this.
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'.
The following table defines the meaning of the above table entries.
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].
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,
Aboba, Vollbrecht & Zorn [Page 13]
INTERNET-DRAFT 21 July 1997
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] 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. 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
Aboba, Vollbrecht & Zorn [Page 14]
INTERNET-DRAFT 21 July 1997
EMail: glennz@microsoft.com
Aboba, Vollbrecht & Zorn [Page 15]
