Submitted to AAA Working Group Ronnie Ekstein
INTERNET DRAFT Yves T'Joens
Marc De Vries
<draft-tjoens-aaa-radius-comp-00.txt> Alcatel
May 2000
Expires November, 2000
Comparison of RADIUS Against AAA Network Access Requirements
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This document compares the current RADIUS protocol to the
Network Access AAA Evaluation Criteria, and illustrates where and how
RADIUS can be improved to become unconditionally compliant to these
requirements. This document is provided to the AAA Working Group as
Tjoens, et al. Expires November, 2000 [Page 1]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
an official submission for an AAA protocol.
1.0 Introduction
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This document compares the current RADIUS protocol to the
Network Access AAA Evaluation Criteria, and illustrates where and how
RADIUS can be improved to become unconditionally compliant to these
requirements.
The main point the authors want to make is that the Network Access
AAA requirements can be met by completing the definition of the
RADIUS protocol, which ensures real backwards compatibility with a
huge installed base (classic network access AAA services) without
requiring each administrative domain to deploy RADIUS/non-RADIUS
gateways, and without requiring the diverse platforms hosting AAA
client or server applications to support an additional (even untried)
transport layer protocol on top of IP.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [1].
Please note that the requirements specified in this document are to
be used in evaluating AAA protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional. For example, requiring that a protocol
support confidentiality is NOT the same thing as requiring that all
protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that
it implements. A protocol submission that satisfies all the MUST,
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
requirements for its protocols is said to be "conditionally
compliant."
2.0 Requirements Summary
This section contains the same four sections as found in the AAA
Network Access requirements. Each section contains a new column,
Tjoens, et al. Expires November, 2000 [Page 2]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
named RADIUS. For each requirement, it is noted whether the RADIUS
protocol meets (T), Partially meets (P), or does not meet (F) the
stated requirement. Furthermore, each requirement has a footnote,
which contains additional justification.
Tjoens, et al. Expires November, 2000 [Page 3]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.1 General requirements
These requirements apply to all aspects of AAA and thus are
considered general requirements.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| General | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Scalability | M | M | M | P |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Failover | M | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mutual auth | M | | M | T |
| AAA client/server | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Transmission level | | M | S | P |
| security | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | S | F |
| Confidentiality | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | M | F |
| Integrity | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Certificate transport | M | | S | F |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tjoens, et al. Expires November, 2000 [Page 4]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reliable AAA transport | M | | M | P |
| mechanism | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv4 | M | M | M | T |
| | | | | i |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv6 | M | | S | P |
| | | | | j |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support Proxy and | M | | M | P |
| Routing Brokers | | | | k |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Auditability | S | | | F |
| | | | | l |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Shared secret not | S | O | O/M | T |
| required | | | | m |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Ability to carry | M | | S | T |
| service-specific attr. | | | | n |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Tjoens, et al. Expires November, 2000 [Page 5]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Clarifications
[a] The RADIUS protocol supports the scalability requirements, with
the exception of tens of thousands of simultaneous requests
between two communicating devices, as only up to 256 requests
can be outstanding at any given time. This restriction can be
worked around, for example, by increasing the number of tran-
sport addresses (IP address + UDP port) on either of the commun-
icating devices. There are existing implementations using this
technique. Other implementations have extended the request-to-
reply mapping using a RADIUS attribute that MUST be returned
unmodified by the server to the client, thereby extending the
possible outstanding requests to 256 x 2^32 if both client and
server support this extention.
[b] RADIUS allows for failover, failback and retransmission to be
implemented on clients, by providing a means for clients to
detect non-acknowledgement of requests and by providing a means
for servers to detect retransmission. Additionally, the RADIUS
message set could easily be extended to include alive checks,
failover notification or server controlled failover and failback
if required. Note that implementations exist that allow for
RADIUS servers to send requests to RADIUS clients on a well-
known UDP port of the client.
[c] RADIUS supports authentication of server to client during
authentication (using a request and response authenticator with
shared secret), and supports mutual client-server authentication
during accounting (again using authenticators with shared
secret). Stronger mutual authentication between client and
server can be accomplished for example by an underlying security
service (like IPSec) or by support of the Message Authenticator
as defined in [7].
[d] RADIUS supports hop-by-hop authentication and integrity for
authentication responses and accounting requests and responses.
Hop-by-hop confidentiality is currently provided for password
attributes in authentication requests and responses. The hop-
by-hop integrity of authentication requests can be provided by
including an integrity check vector attribute. Stronger security
can be accomplished by an underlying security service like
IPSec.
[e] RADIUS does not yet support end-to-end confidentiality at the
attribute level. It is however possible to extend the RADIUS
protocol to allow data objects (attribute groups) to be encapsu-
lated and encrypted for this purpose.
Tjoens, et al. Expires November, 2000 [Page 6]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[f] RADIUS does not yet support end-to-end authentication and
integrity at the attribute level. It is however possible to
extend the RADIUS protocol to allow data objects (attribute
groups) to be encapsulated and marked with an end-to-end authen-
ticated integrity check vector.
[g] RADIUS does not yet support certificate transport. This can
however be provided by defining new messages and/or attributes
for out-of-band and/or in-band certificate exchange.
[h] The RADIUS protocol uses UDP/IP for transport of messages.
1. Hop-by-hop retransmission and failover is supported, under
control of the application (e.g. requires stateful proxies
and tuned retransmission timers).
2. The retransmission mechanism is entirely controlled by the
application, not the underlying transport.
3. For authentication requests, receipt is not acknowledged
until the response is available. For authentication and
accounting responses, receipt is not acknowledged (although
some implementations use an Accounting-Request/Start message
as acknowledgement for Access-Accept). Accounting-Request
messages are explicitly acknowledged. Message independent
acknowledgement can be provided in RADIUS by introducing an
explicit acknowledge message.
4. (item not listed in Evaluation Requirements)
5. Piggy-backing of acknowledgments can be provided in the
explicit acknowledge message to be defined. Piggy-backing on
actual AAA messages would require windowing support which is
difficult to introduce in RADIUS.
6. Timely delivery of responses is controlled by the applica-
tion.
[i] RADIUS messages can be transported over IPv4. The RADIUS proto-
col depends on the underlying IP version since certain attri-
butes can have an 'address' data type which is defined as an
IPv4 address. IPv4 is supported.
[j] RADIUS messages can be transported over IPv6. The RADIUS proto-
col depends on the underlying IP version since certain attri-
butes can have an 'address' data type which is defined as an
IPv4 address. An IPv6 address data type can be defined to sup-
port IPv6 address values.
Tjoens, et al. Expires November, 2000 [Page 7]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[k] RADIUS supports proxy and transparent brokers, as explicitly
clarified in [5]. The RADIUS protocol does not by itself support
a means for routing brokers to provide the client with a new
server address. This can be accomplished by extending the RADIUS
message set with routing messages or redirection attributes
within the existing message set.
[l] RADIUS does not yet support tracing of the end-to-end message
path nor the changes made to attributes along that path. This
information may be logged for off-line auditing purposes at each
hop.
[m] The RADIUS protocol currently requires shared secrets between
communicating devices to match. In case an underlying security
service (e.g. IPSec) is used, it is possible to configure the
communicating devices with empty shared secret values.
[n] The RADIUS protocol currently defines attributes and messages
for AAA services, out of a message and attribute number space of
size 255 each. Within the common attribute number space, a sin-
gle attribute type is used to encapsulate Vendor-Specific attri-
butes. The same mechanism can be used to encapsulate standard
attributes defined as extensions for other services.
Tjoens, et al. Expires November, 2000 [Page 8]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.2 Authentication Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| NAI Support | M | M | S | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| CHAP Support | M | M | O | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP Support | M | S | O | T |
| | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| PAP/Clear-Text Support | M | B | O | P |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-authentication | M | | S | T |
| on demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization Only | M | | O | F |
| without Authentication | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
Tjoens, et al. Expires November, 2000 [Page 9]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
F = Does Not Meet Requirement
Clarifications
[a] The RADIUS protocol defines a User-Name attribute for authenti-
cation and accounting, supporting the NAI format [5][13] and
allowing for message forwarding based on e.g. realm identifica-
tion prefixes or suffixes.
[b] The RADIUS protocol supports authentication of a PPP user using
the CHAP authentication mechanism by passing the CHAP challenge
and challenge response in attributes to the home AAA server for
verification.
[c] The RADIUS protocol has been extended in [7] to support PPP
users using the EAP authentication mechanism, supporting attri-
butes to carry EAP messages.
[d] The RADIUS protocol supports authentication of a PPP user using
the PAP authentication mechanism as well as terminal access
users using clear-text passwords. The passwords are transmitted
in a confidential manner for hop-by-hop communication. End-to-
end confidentiality of password attributes is not yet sup-
ported. It is, however, possible to extend the RADIUS protocol
to allow data objects (attribute groups) to be encapsulated and
encrypted for this purpose.
[e] The RADIUS protocol supports re-authentication. In case re-
authentication is initiated by the user or AAA client, the AAA
client can send a new authentication request. Re-authentication
can be initiated from the visited or home AAA server by sending
a challenge message to the AAA client.
[f] The RADIUS protocol does not yet explicitly support non-
authenticated authorisation. This can easily be supported by
defining a new request message type or a new end-to-end secured
attribute.
Tjoens, et al. Expires November, 2000 [Page 10]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.3 Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | | |
| IPv4/6 Address Assign. | M | M | M | P |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| RADIUS gateway | M | M | O | T |
| capability | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reject | M | M | M | T |
| capability | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Precludes layer 2 | N | N | | T |
| tunneling | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-Authorization on | M | | S | P |
| demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support for Access Rules,| M | | O | P |
| Restrictions, Filters | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| State Reconciliation | M | | | P |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unsolicited Disconnect | M | | | F |
| | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tjoens, et al. Expires November, 2000 [Page 11]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] RADIUS allows for both static and dynamic address assignement.
Currently only an IPv4 address data type is defined. An IPv6
address data type can be defined to support IPv6 address values.
The Address field of the transported Framed-IP-Address or NAS-
IP-Address attributes can be extended to 16 octets [5].
[b] This is always true when RADIUS is used as base protocol. More-
over, by completing RADIUS within the new scope of the AAA Work-
ing Group, not only can backwards compatibility with user pro-
file databases be guaranteed, it can also guarantee protocol and
application level compatibility for the installed base
RADIUS/AAA applications. Therefore this approach does not even
require a gateway application.
[c] RADIUS supports proxy and transparent brokers [5]. RADIUS allows
brokers to reject authentication requests before or after con-
tacting the home AAA server. This behaviour is entirely under
control of the application (e.g based on the requested Service-
Type, or based on the authorisation attributes included in the
response).
[d] [10] defines a set of RADIUS attributes designed to support the
provision of compulsory tunneling in dial-up networks. [11]
defines the necessary new RADIUS accounting Attributes and new
values for the existing Acct-Status-Type Attribute.
[e] The RADIUS protocol has defined the Session-Timeout attribute
[5] to set the maximum number of seconds of service to be pro-
vided to the user before termination of the session or prompt.
In order to renew a session, a re-authorization MUST be submit-
ted. Re-authorization without re-authentication is not
currently supported in RADIUS, but can be provided by defining a
new message type or attribute. Active termination of a session
from a RADIUS server or broker is not currently supported, but
existing implementations have proven that RADIUS can be extended
Tjoens, et al. Expires November, 2000 [Page 12]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
to support this as a Disconnect-Request from server to client
[9].
[f]
[1][2][3]Time/day,port location and dialed/dialling number res-
trictions are typically applied at the AAA home or
broker servers.
[4] Concurrent login restriction is supported (per AAA client)
by the Port-Limit attribute. Global concurrent login res-
triction can be implemented by stateful brokers and home
AAA servers.
[5] RADIUS provides for a Session-Timeout attribute to aid
enforcement of the time/day restriction and session dura-
tion restriction on the AAA client. RADIUS also defines an
Idle-Timeout attribute to force termination of idle ses-
sions on the AAA client.
[6] RADIUS specifies the Filter-Id attribute [5], which indi-
cates the name of the filter list for this user. Zero or
more Filter-Id attributes MAY be sent in an Access-Accept
packet. Identifying a filter list by name allows the filter
to be used on different NASes without regard to filter-list
implementation details. Existing implementations are known
to use the Vendor-Specific attribute defined in RADIUS to
implement an attribute that contains the filter rule in a
vendor-specifc format.
[7] Static routes can be enforced via zero or more occurences
of the RADIUS attribute Framed-Route. Existing implementa-
tions are known to support new attributes to enforce other
types of forced access paths (e.g. fixed uplink PVC,
bypassing the AAA client's routing function).
[8] QOS parameters are not currently defined in RADIUS, but can
easily be provided by defining the corresponding attri-
butes. Existing implementations are known to use Vendor-
Specific attributes to provide QoS (e.g. TOS bit masks, VPN
IDs) parameters to the AAA client.
[g] The AAA network access requirements describe State Reconcilia-
tion as requiring:
[1] Re-authorization capabilities - The RADIUS protocol pro-
vides the Session-Timeout attribute [5], which indicates
the number of seconds of service to be provided to the user
before termination of the session or prompt. The AAA client
Tjoens, et al. Expires November, 2000 [Page 13]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
may re-authorise in order to retrieve this value if lost on
the client. However RADIUS currently forces re-
authorisation to include re-authentication as well.
[2] Session disconnect message - RADIUS does not yet support a
session disconnect message. This can, however, be provided
by defining a Disconnect-Request message and by requiring
the Acct-Session-Id attribute to be included in all
session-related messages. Examples of existing RADIUS
implementations using this technique are provided in [9].
[3] Transport and application-layer reliability - RADIUS relies
on UDP for the delivery/transport of information
between client and server, the protocol handles the
loss of request by implementing a time-out and retransmis-
sion strategy. However, the protocol specification
failed to define a standard retransmission and timeout
scheme. It is in fact the application layer that takes care
of retransmission, fail-over and timely delivery of
responses. RADIUS does not take care of acknowledgements
and windowing. RADIUS can, however, be extended to optimise
delivery reliability as described under the General
Requirements section above.
[4] An interim message - RADIUS allows to include in the
Accounting Request the "Interim-Update" value in a Acct-
Status-Type attribute [6]. RADIUS provides the possibility
for a server that wishes to receive interim accounting mes-
sages for the given user to include the Acct-Interim-
Interval RADIUS attribute in the authentication response
message, which indicates the interval in seconds between
interim messages [7].
[5] A mechanism for the AAA server to retrieve state informa-
tion from the NAS. This mechanism will provide timely
information although a complete state dump may not be
immediately available. - RADIUS as originally defined did
not require AAA servers to keep state. The documents [5]
and [6] include clarifications on using RADIUS with state-
ful brokers or proxy servers. Existing implementations of
RADIUS brokers/proxies are capable of providing resource
management (concurrent session limitation, port wholesale,
centralised IP pools, ...). Although RADIUS allows for
stateful implementations, it does not yet support state
retrieval between AAA client and AAA server. Existing
implemenations are known to support this today using exten-
tions to RADIUS (new messages and attributes).
Tjoens, et al. Expires November, 2000 [Page 14]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[6] A NAS reboot message - RADIUS supports the Accounting
On/Off messages which may imply an AAA client reboot
(before and after). An extra attribute can be defined to
explicitly state the reason for the Accounting On/Off mes-
sages.
[7] Accounting On/Off messages - The RADIUS protocol has
defined the Accounting-Status-Type attribute to indicate
whether an Accounting-Request marks the beginning of the
user service (Start) or the end (Stop). [7] has defined
additional values to support the Accounting On/Off mes-
sages.
[h] Session disconnect message - RADIUS does not yet support a ses-
sion disconnect message. This can, however, be provided by
defining a new Disconnect-Request message, a correspondant
disconnect reason value in the Acct-Terminate-Cause attribute
[6], and the requirement to include the Acct-Session-Id attri-
bute in all session-related messages.
Tjoens, et al. Expires November, 2000 [Page 15]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.4 Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Real-time accounting | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mandatory Compact | | M | M | T |
| Encoding | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Record | M | M | M | T |
| Extensibility | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Batch Accounting | S | | | F |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Guaranteed Delivery | M | | M | T |
| | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Time Stamps | M | | S | T |
| | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Dynamic Accounting | M | | S | P |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
Tjoens, et al. Expires November, 2000 [Page 16]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The RADIUS implementation, based on the extensions as defined in
[7] allows for indicating an accounting interval time at which
cumulative accounting information should be sent to the Account-
ing Server.
[b] The present set of attributes defined in [6] and [7] represents
a compact representation of accounting data. If it would be
required to transport entire accounting records, RADIUS could be
extended with an attribute along the ADIF definition [14].
[c] By definition of new attributes for accounting data, the
accounting information transported can be easily extended. If it
would be required to transport entire accounting records, RADIUS
could be extended with an attribute along the ADIF definition,
which allows for easy extension.
[d] RADIUS does not yet support batch accounting. It is, however,
possible to extend the attribute space of RADIUS with an
accounting batch attribute.
[e] RADIUS prescribes every Accounting-Request message to be ack-
nowledged by an Accounting-Response message indicating suc-
cessfull delivery. A retransmission scheme allows for repeated
attempts for delivery.
[f] The RADIUS extensions specification [7] defines the Event-
Timestamp Attribute as an extension to the Accounting-Request
message.
[g] RADIUS does not yet support dynamic authorization. It is, how-
ever, possible to extend the message set of RADIUS (or semantic
interpretation of the existing message set) to include dynamic
(re-)authorization. RADIUS allows for interim updates of
accounting information, as defined in [7].
Tjoens, et al. Expires November, 2000 [Page 17]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.5 Unique Mobile IP requirements
In addition Mobile IP also has the following requirements:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | RADIUS |
| requirements | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Encoding of Mobile IP | | | M | F |
| registration messages | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Firewall friendly | | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Allocation of local Home | | | S/M | F |
| agent | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] RADIUS does not yet support Mobile IP registration messages. It
is, however, possible to extend the attribute space of RADIUS to
include the registration information.
[b] RADIUS is known to be operational in environments where
firewalls acting as a proxy are active.
[c] RADIUS does not yet support allocation of local Home agents. It
is, however, possible to extend the attribute space of RADIUS to
Tjoens, et al. Expires November, 2000 [Page 18]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
allocate the local home agent.
3.0 Conclusion
The RADIUS protocol, and its associated extensions [7], is presently
not fully compliant with the AAA Network Access requirements [2].
However, as is indicated at the relevant places in this document it
is possible with a small effort to extend present procedures to meet
the requirements as listed in [2], while maintaining a high level of
interoperability with the wide deployment and installed base of
RADIUS clients and servers.
4.0 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work in
progress, draft-ietf-aaa-na-reqts-02.txt, March 2000.
[3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authenti-
cation Dial In User Service (RADIUS)", RFC 2138, April 1997
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997
[5] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authen-
tication Dial In User Service (RADIUS)", Internet-Draft, draft-
ietf-radius-radius-v2-06.txt, February 2000.
[6] Rigney, C., "RADIUS Accounting", draft-ietf-radius-accounting-v2-
05.txt, February 2000.
[7] Rigney C., Willats W., Calhoun P., "RADIUS Extensions", draft-
ietf-radius-ext-07.txt, Internet Draft, February 2000.
[8] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC
2477 (Informational), January 1998
[9] Mitton, D.,"Network Access Servers Requirements: Extended RADIUS
Practices", draft-ietf-nasreq-ext-radiuspract-03.txt, Internet
Draft, May 2000.
[10] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I.
Goyret, "RADIUS Attributes for Tunnel Protocol Support", draft-
ietf-radius-tunnel-auth-09.txt, Internet Draft (work in progress),
August 1999 (Expired)
Tjoens, et al. Expires November, 2000 [Page 19]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[11] Zorn, G., Mitton, D., "RADIUS Accounting Modifications for Tunnel
Protocol Support", draft-ietf-radius-tunnel-acct-05.txt, Internet
Draft (work in progress), October 1999 (Expired)
[12] B. Aboba, G. Zorn, "Implementation of L2TP Compulsory Tunneling via
RADIUS", draft-ietf-radius-tunnel-imp-05.txt, Internet Draft (work
in progress), 20 August 1999, (Expired)
[13] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486,
January 1999.
[14] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
(ADIF)", IETF Work in Progress, draft-ietf-roamops-actng-07.txt,
September 1999.
[15] N. Brownlee, A. Blount, "Accounting Attributes and Record Formats",
IETF Work in Progress, draft-ietf-aaa-accounting-attributes-02.txt,
March 2000.
5.0 Security Considerations
This document, being a protocol evaluation document, does not have
any security concerns. The security requirements on protocols to be
evaluated using this document are described in the referenced docu-
ments.
6.0 IANA Considerations
This draft does not create any new number spaces for IANA administra-
tion.
7.0 Acknowledgements
8.0 Authors Addresses
Ronnie Ekstein
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 241 5958
E-mail : ronnie.ekstein@alcatel.be
Tjoens, et al. Expires November, 2000 [Page 20]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Yves T'Joens
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 7890
E-mail : yves.tjoens@alcatel.be
Marc De Vries
Alcatel Carrier Internetworking Division
De Villermontstraat 38, 2550 Kontich, Belgium
E-mail : marc.de_vries@alcatel.be
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
toothers, and derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be fol-
lowed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Tjoens, et al. Expires November, 2000 [Page 21]
Submitted to AAA Working Group Ronnie Ekstein
INTERNET DRAFT Yves T'Joens
Marc De Vries
<draft-tjoens-aaa-radius-comp-00.txt> Alcatel
May 2000
Expires November, 2000
Comparison of RADIUS Against AAA Network Access Requirements
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This document compares the current RADIUS protocol to the
Network Access AAA Evaluation Criteria, and illustrates where and how
RADIUS can be improved to become unconditionally compliant to these
requirements. This document is provided to the AAA Working Group as
Tjoens, et al. Expires November, 2000 [Page 1]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
an official submission for an AAA protocol.
1.0 Introduction
The AAA Working Group has completed a document that itemizes their
requirements for Network Access Applications (NASREQ, Mobile IP, and
ROAMOPS). This document compares the current RADIUS protocol to the
Network Access AAA Evaluation Criteria, and illustrates where and how
RADIUS can be improved to become unconditionally compliant to these
requirements.
The main point the authors want to make is that the Network Access
AAA requirements can be met by completing the definition of the
RADIUS protocol, which ensures real backwards compatibility with a
huge installed base (classic network access AAA services) without
requiring each administrative domain to deploy RADIUS/non-RADIUS
gateways, and without requiring the diverse platforms hosting AAA
client or server applications to support an additional (even untried)
transport layer protocol on top of IP.
1.1 Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT",
"optional", "recommended", "SHOULD", and "SHOULD NOT", are to be
interpreted as described in [1].
Please note that the requirements specified in this document are to
be used in evaluating AAA protocol submissions. As such, the
requirements language refers to capabilities of these protocols; the
protocol documents will specify whether these features are required,
recommended, or optional. For example, requiring that a protocol
support confidentiality is NOT the same thing as requiring that all
protocol traffic be encrypted.
A protocol submission is not compliant if it fails to satisfy one or
more of the MUST or MUST NOT requirements for the capabilities that
it implements. A protocol submission that satisfies all the MUST,
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is
said to be "unconditionally compliant"; one that satisfies all the
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT
requirements for its protocols is said to be "conditionally
compliant."
2.0 Requirements Summary
This section contains the same four sections as found in the AAA
Network Access requirements. Each section contains a new column,
Tjoens, et al. Expires November, 2000 [Page 2]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
named RADIUS. For each requirement, it is noted whether the RADIUS
protocol meets (T), Partially meets (P), or does not meet (F) the
stated requirement. Furthermore, each requirement has a footnote,
which contains additional justification.
Tjoens, et al. Expires November, 2000 [Page 3]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.1 General requirements
These requirements apply to all aspects of AAA and thus are
considered general requirements.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| General | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Scalability | M | M | M | P |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Failover | M | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mutual auth | M | | M | T |
| AAA client/server | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Transmission level | | M | S | P |
| security | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | S | F |
| Confidentiality | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Data object | M | M | M | F |
| Integrity | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Certificate transport | M | | S | F |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tjoens, et al. Expires November, 2000 [Page 4]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reliable AAA transport | M | | M | P |
| mechanism | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv4 | M | M | M | T |
| | | | | i |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Run Over IPv6 | M | | S | P |
| | | | | j |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support Proxy and | M | | M | P |
| Routing Brokers | | | | k |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Auditability | S | | | F |
| | | | | l |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Shared secret not | S | O | O/M | T |
| required | | | | m |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Ability to carry | M | | S | T |
| service-specific attr. | | | | n |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Tjoens, et al. Expires November, 2000 [Page 5]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Clarifications
[a] The RADIUS protocol supports the scalability requirements, with
the exception of tens of thousands of simultaneous requests
between two communicating devices, as only up to 256 requests
can be outstanding at any given time. This restriction can be
worked around, for example, by increasing the number of tran-
sport addresses (IP address + UDP port) on either of the commun-
icating devices. There are existing implementations using this
technique. Other implementations have extended the request-to-
reply mapping using a RADIUS attribute that MUST be returned
unmodified by the server to the client, thereby extending the
possible outstanding requests to 256 x 2^32 if both client and
server support this extention.
[b] RADIUS allows for failover, failback and retransmission to be
implemented on clients, by providing a means for clients to
detect non-acknowledgement of requests and by providing a means
for servers to detect retransmission. Additionally, the RADIUS
message set could easily be extended to include alive checks,
failover notification or server controlled failover and failback
if required. Note that implementations exist that allow for
RADIUS servers to send requests to RADIUS clients on a well-
known UDP port of the client.
[c] RADIUS supports authentication of server to client during
authentication (using a request and response authenticator with
shared secret), and supports mutual client-server authentication
during accounting (again using authenticators with shared
secret). Stronger mutual authentication between client and
server can be accomplished for example by an underlying security
service (like IPSec) or by support of the Message Authenticator
as defined in [7].
[d] RADIUS supports hop-by-hop authentication and integrity for
authentication responses and accounting requests and responses.
Hop-by-hop confidentiality is currently provided for password
attributes in authentication requests and responses. The hop-
by-hop integrity of authentication requests can be provided by
including an integrity check vector attribute. Stronger security
can be accomplished by an underlying security service like
IPSec.
[e] RADIUS does not yet support end-to-end confidentiality at the
attribute level. It is however possible to extend the RADIUS
protocol to allow data objects (attribute groups) to be encapsu-
lated and encrypted for this purpose.
Tjoens, et al. Expires November, 2000 [Page 6]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[f] RADIUS does not yet support end-to-end authentication and
integrity at the attribute level. It is however possible to
extend the RADIUS protocol to allow data objects (attribute
groups) to be encapsulated and marked with an end-to-end authen-
ticated integrity check vector.
[g] RADIUS does not yet support certificate transport. This can
however be provided by defining new messages and/or attributes
for out-of-band and/or in-band certificate exchange.
[h] The RADIUS protocol uses UDP/IP for transport of messages.
1. Hop-by-hop retransmission and failover is supported, under
control of the application (e.g. requires stateful proxies
and tuned retransmission timers).
2. The retransmission mechanism is entirely controlled by the
application, not the underlying transport.
3. For authentication requests, receipt is not acknowledged
until the response is available. For authentication and
accounting responses, receipt is not acknowledged (although
some implementations use an Accounting-Request/Start message
as acknowledgement for Access-Accept). Accounting-Request
messages are explicitly acknowledged. Message independent
acknowledgement can be provided in RADIUS by introducing an
explicit acknowledge message.
4. (item not listed in Evaluation Requirements)
5. Piggy-backing of acknowledgments can be provided in the
explicit acknowledge message to be defined. Piggy-backing on
actual AAA messages would require windowing support which is
difficult to introduce in RADIUS.
6. Timely delivery of responses is controlled by the applica-
tion.
[i] RADIUS messages can be transported over IPv4. The RADIUS proto-
col depends on the underlying IP version since certain attri-
butes can have an 'address' data type which is defined as an
IPv4 address. IPv4 is supported.
[j] RADIUS messages can be transported over IPv6. The RADIUS proto-
col depends on the underlying IP version since certain attri-
butes can have an 'address' data type which is defined as an
IPv4 address. An IPv6 address data type can be defined to sup-
port IPv6 address values.
Tjoens, et al. Expires November, 2000 [Page 7]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[k] RADIUS supports proxy and transparent brokers, as explicitly
clarified in [5]. The RADIUS protocol does not by itself support
a means for routing brokers to provide the client with a new
server address. This can be accomplished by extending the RADIUS
message set with routing messages or redirection attributes
within the existing message set.
[l] RADIUS does not yet support tracing of the end-to-end message
path nor the changes made to attributes along that path. This
information may be logged for off-line auditing purposes at each
hop.
[m] The RADIUS protocol currently requires shared secrets between
communicating devices to match. In case an underlying security
service (e.g. IPSec) is used, it is possible to configure the
communicating devices with empty shared secret values.
[n] The RADIUS protocol currently defines attributes and messages
for AAA services, out of a message and attribute number space of
size 255 each. Within the common attribute number space, a sin-
gle attribute type is used to encapsulate Vendor-Specific attri-
butes. The same mechanism can be used to encapsulate standard
attributes defined as extensions for other services.
Tjoens, et al. Expires November, 2000 [Page 8]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.2 Authentication Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authentication | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| NAI Support | M | M | S | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| CHAP Support | M | M | O | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP Support | M | S | O | T |
| | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| PAP/Clear-Text Support | M | B | O | P |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-authentication | M | | S | T |
| on demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization Only | M | | O | F |
| without Authentication | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
Tjoens, et al. Expires November, 2000 [Page 9]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
F = Does Not Meet Requirement
Clarifications
[a] The RADIUS protocol defines a User-Name attribute for authenti-
cation and accounting, supporting the NAI format [5][13] and
allowing for message forwarding based on e.g. realm identifica-
tion prefixes or suffixes.
[b] The RADIUS protocol supports authentication of a PPP user using
the CHAP authentication mechanism by passing the CHAP challenge
and challenge response in attributes to the home AAA server for
verification.
[c] The RADIUS protocol has been extended in [7] to support PPP
users using the EAP authentication mechanism, supporting attri-
butes to carry EAP messages.
[d] The RADIUS protocol supports authentication of a PPP user using
the PAP authentication mechanism as well as terminal access
users using clear-text passwords. The passwords are transmitted
in a confidential manner for hop-by-hop communication. End-to-
end confidentiality of password attributes is not yet sup-
ported. It is, however, possible to extend the RADIUS protocol
to allow data objects (attribute groups) to be encapsulated and
encrypted for this purpose.
[e] The RADIUS protocol supports re-authentication. In case re-
authentication is initiated by the user or AAA client, the AAA
client can send a new authentication request. Re-authentication
can be initiated from the visited or home AAA server by sending
a challenge message to the AAA client.
[f] The RADIUS protocol does not yet explicitly support non-
authenticated authorisation. This can easily be supported by
defining a new request message type or a new end-to-end secured
attribute.
Tjoens, et al. Expires November, 2000 [Page 10]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.3 Authorization Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Authorization | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Static and Dynamic | | | | |
| IPv4/6 Address Assign. | M | M | M | P |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| RADIUS gateway | M | M | O | T |
| capability | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Reject | M | M | M | T |
| capability | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Precludes layer 2 | N | N | | T |
| tunneling | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Re-Authorization on | M | | S | P |
| demand | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Support for Access Rules,| M | | O | P |
| Restrictions, Filters | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| State Reconciliation | M | | | P |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unsolicited Disconnect | M | | | F |
| | | | | h |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tjoens, et al. Expires November, 2000 [Page 11]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] RADIUS allows for both static and dynamic address assignement.
Currently only an IPv4 address data type is defined. An IPv6
address data type can be defined to support IPv6 address values.
The Address field of the transported Framed-IP-Address or NAS-
IP-Address attributes can be extended to 16 octets [5].
[b] This is always true when RADIUS is used as base protocol. More-
over, by completing RADIUS within the new scope of the AAA Work-
ing Group, not only can backwards compatibility with user pro-
file databases be guaranteed, it can also guarantee protocol and
application level compatibility for the installed base
RADIUS/AAA applications. Therefore this approach does not even
require a gateway application.
[c] RADIUS supports proxy and transparent brokers [5]. RADIUS allows
brokers to reject authentication requests before or after con-
tacting the home AAA server. This behaviour is entirely under
control of the application (e.g based on the requested Service-
Type, or based on the authorisation attributes included in the
response).
[d] [10] defines a set of RADIUS attributes designed to support the
provision of compulsory tunneling in dial-up networks. [11]
defines the necessary new RADIUS accounting Attributes and new
values for the existing Acct-Status-Type Attribute.
[e] The RADIUS protocol has defined the Session-Timeout attribute
[5] to set the maximum number of seconds of service to be pro-
vided to the user before termination of the session or prompt.
In order to renew a session, a re-authorization MUST be submit-
ted. Re-authorization without re-authentication is not
currently supported in RADIUS, but can be provided by defining a
new message type or attribute. Active termination of a session
from a RADIUS server or broker is not currently supported, but
existing implementations have proven that RADIUS can be extended
Tjoens, et al. Expires November, 2000 [Page 12]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
to support this as a Disconnect-Request from server to client
[9].
[f]
[1][2][3]Time/day,port location and dialed/dialling number res-
trictions are typically applied at the AAA home or
broker servers.
[4] Concurrent login restriction is supported (per AAA client)
by the Port-Limit attribute. Global concurrent login res-
triction can be implemented by stateful brokers and home
AAA servers.
[5] RADIUS provides for a Session-Timeout attribute to aid
enforcement of the time/day restriction and session dura-
tion restriction on the AAA client. RADIUS also defines an
Idle-Timeout attribute to force termination of idle ses-
sions on the AAA client.
[6] RADIUS specifies the Filter-Id attribute [5], which indi-
cates the name of the filter list for this user. Zero or
more Filter-Id attributes MAY be sent in an Access-Accept
packet. Identifying a filter list by name allows the filter
to be used on different NASes without regard to filter-list
implementation details. Existing implementations are known
to use the Vendor-Specific attribute defined in RADIUS to
implement an attribute that contains the filter rule in a
vendor-specifc format.
[7] Static routes can be enforced via zero or more occurences
of the RADIUS attribute Framed-Route. Existing implementa-
tions are known to support new attributes to enforce other
types of forced access paths (e.g. fixed uplink PVC,
bypassing the AAA client's routing function).
[8] QOS parameters are not currently defined in RADIUS, but can
easily be provided by defining the corresponding attri-
butes. Existing implementations are known to use Vendor-
Specific attributes to provide QoS (e.g. TOS bit masks, VPN
IDs) parameters to the AAA client.
[g] The AAA network access requirements describe State Reconcilia-
tion as requiring:
[1] Re-authorization capabilities - The RADIUS protocol pro-
vides the Session-Timeout attribute [5], which indicates
the number of seconds of service to be provided to the user
before termination of the session or prompt. The AAA client
Tjoens, et al. Expires November, 2000 [Page 13]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
may re-authorise in order to retrieve this value if lost on
the client. However RADIUS currently forces re-
authorisation to include re-authentication as well.
[2] Session disconnect message - RADIUS does not yet support a
session disconnect message. This can, however, be provided
by defining a Disconnect-Request message and by requiring
the Acct-Session-Id attribute to be included in all
session-related messages. Examples of existing RADIUS
implementations using this technique are provided in [9].
[3] Transport and application-layer reliability - RADIUS relies
on UDP for the delivery/transport of information
between client and server, the protocol handles the
loss of request by implementing a time-out and retransmis-
sion strategy. However, the protocol specification
failed to define a standard retransmission and timeout
scheme. It is in fact the application layer that takes care
of retransmission, fail-over and timely delivery of
responses. RADIUS does not take care of acknowledgements
and windowing. RADIUS can, however, be extended to optimise
delivery reliability as described under the General
Requirements section above.
[4] An interim message - RADIUS allows to include in the
Accounting Request the "Interim-Update" value in a Acct-
Status-Type attribute [6]. RADIUS provides the possibility
for a server that wishes to receive interim accounting mes-
sages for the given user to include the Acct-Interim-
Interval RADIUS attribute in the authentication response
message, which indicates the interval in seconds between
interim messages [7].
[5] A mechanism for the AAA server to retrieve state informa-
tion from the NAS. This mechanism will provide timely
information although a complete state dump may not be
immediately available. - RADIUS as originally defined did
not require AAA servers to keep state. The documents [5]
and [6] include clarifications on using RADIUS with state-
ful brokers or proxy servers. Existing implementations of
RADIUS brokers/proxies are capable of providing resource
management (concurrent session limitation, port wholesale,
centralised IP pools, ...). Although RADIUS allows for
stateful implementations, it does not yet support state
retrieval between AAA client and AAA server. Existing
implemenations are known to support this today using exten-
tions to RADIUS (new messages and attributes).
Tjoens, et al. Expires November, 2000 [Page 14]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[6] A NAS reboot message - RADIUS supports the Accounting
On/Off messages which may imply an AAA client reboot
(before and after). An extra attribute can be defined to
explicitly state the reason for the Accounting On/Off mes-
sages.
[7] Accounting On/Off messages - The RADIUS protocol has
defined the Accounting-Status-Type attribute to indicate
whether an Accounting-Request marks the beginning of the
user service (Start) or the end (Stop). [7] has defined
additional values to support the Accounting On/Off mes-
sages.
[h] Session disconnect message - RADIUS does not yet support a ses-
sion disconnect message. This can, however, be provided by
defining a new Disconnect-Request message, a correspondant
disconnect reason value in the Acct-Terminate-Cause attribute
[6], and the requirement to include the Acct-Session-Id attri-
bute in all session-related messages.
Tjoens, et al. Expires November, 2000 [Page 15]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.4 Accounting Requirements
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting | NASREQ | ROAMOPS | MOBILE | RADIUS |
| Reqts. | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Real-time accounting | M | M | M | T |
| | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Mandatory Compact | | M | M | T |
| Encoding | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Record | M | M | M | T |
| Extensibility | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Batch Accounting | S | | | F |
| | | | | d |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Guaranteed Delivery | M | | M | T |
| | | | | e |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Accounting Time Stamps | M | | S | T |
| | | | | f |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Dynamic Accounting | M | | S | P |
| | | | | g |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
Tjoens, et al. Expires November, 2000 [Page 16]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] The RADIUS implementation, based on the extensions as defined in
[7] allows for indicating an accounting interval time at which
cumulative accounting information should be sent to the Account-
ing Server.
[b] The present set of attributes defined in [6] and [7] represents
a compact representation of accounting data. If it would be
required to transport entire accounting records, RADIUS could be
extended with an attribute along the ADIF definition [14].
[c] By definition of new attributes for accounting data, the
accounting information transported can be easily extended. If it
would be required to transport entire accounting records, RADIUS
could be extended with an attribute along the ADIF definition,
which allows for easy extension.
[d] RADIUS does not yet support batch accounting. It is, however,
possible to extend the attribute space of RADIUS with an
accounting batch attribute.
[e] RADIUS prescribes every Accounting-Request message to be ack-
nowledged by an Accounting-Response message indicating suc-
cessfull delivery. A retransmission scheme allows for repeated
attempts for delivery.
[f] The RADIUS extensions specification [7] defines the Event-
Timestamp Attribute as an extension to the Accounting-Request
message.
[g] RADIUS does not yet support dynamic authorization. It is, how-
ever, possible to extend the message set of RADIUS (or semantic
interpretation of the existing message set) to include dynamic
(re-)authorization. RADIUS allows for interim updates of
accounting information, as defined in [7].
Tjoens, et al. Expires November, 2000 [Page 17]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
2.5 Unique Mobile IP requirements
In addition Mobile IP also has the following requirements:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | RADIUS |
| requirements | | | IP | |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Encoding of Mobile IP | | | M | F |
| registration messages | | | | a |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Firewall friendly | | | M | T |
| | | | | b |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| Allocation of local Home | | | S/M | F |
| agent | | | | c |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key
M = MUST
S = SHOULD
O = MAY
N = MUST NOT
B = SHOULD NOT
T = Meets Requirement
P = Partly Meets Requirement
F = Does Not Meet Requirement
Clarifications
[a] RADIUS does not yet support Mobile IP registration messages. It
is, however, possible to extend the attribute space of RADIUS to
include the registration information.
[b] RADIUS is known to be operational in environments where
firewalls acting as a proxy are active.
[c] RADIUS does not yet support allocation of local Home agents. It
is, however, possible to extend the attribute space of RADIUS to
Tjoens, et al. Expires November, 2000 [Page 18]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
allocate the local home agent.
3.0 Conclusion
The RADIUS protocol, and its associated extensions [7], is presently
not fully compliant with the AAA Network Access requirements [2].
However, as is indicated at the relevant places in this document it
is possible with a small effort to extend present procedures to meet
the requirements as listed in [2], while maintaining a high level of
interoperability with the wide deployment and installed base of
RADIUS clients and servers.
4.0 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work in
progress, draft-ietf-aaa-na-reqts-02.txt, March 2000.
[3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authenti-
cation Dial In User Service (RADIUS)", RFC 2138, April 1997
[4] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997
[5] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote Authen-
tication Dial In User Service (RADIUS)", Internet-Draft, draft-
ietf-radius-radius-v2-06.txt, February 2000.
[6] Rigney, C., "RADIUS Accounting", draft-ietf-radius-accounting-v2-
05.txt, February 2000.
[7] Rigney C., Willats W., Calhoun P., "RADIUS Extensions", draft-
ietf-radius-ext-07.txt, Internet Draft, February 2000.
[8] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC
2477 (Informational), January 1998
[9] Mitton, D.,"Network Access Servers Requirements: Extended RADIUS
Practices", draft-ietf-nasreq-ext-radiuspract-03.txt, Internet
Draft, May 2000.
[10] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I.
Goyret, "RADIUS Attributes for Tunnel Protocol Support", draft-
ietf-radius-tunnel-auth-09.txt, Internet Draft (work in progress),
August 1999 (Expired)
Tjoens, et al. Expires November, 2000 [Page 19]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
[11] Zorn, G., Mitton, D., "RADIUS Accounting Modifications for Tunnel
Protocol Support", draft-ietf-radius-tunnel-acct-05.txt, Internet
Draft (work in progress), October 1999 (Expired)
[12] B. Aboba, G. Zorn, "Implementation of L2TP Compulsory Tunneling via
RADIUS", draft-ietf-radius-tunnel-imp-05.txt, Internet Draft (work
in progress), 20 August 1999, (Expired)
[13] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486,
January 1999.
[14] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format
(ADIF)", IETF Work in Progress, draft-ietf-roamops-actng-07.txt,
September 1999.
[15] N. Brownlee, A. Blount, "Accounting Attributes and Record Formats",
IETF Work in Progress, draft-ietf-aaa-accounting-attributes-02.txt,
March 2000.
5.0 Security Considerations
This document, being a protocol evaluation document, does not have
any security concerns. The security requirements on protocols to be
evaluated using this document are described in the referenced docu-
ments.
6.0 IANA Considerations
This draft does not create any new number spaces for IANA administra-
tion.
7.0 Acknowledgements
8.0 Authors Addresses
Ronnie Ekstein
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 241 5958
E-mail : ronnie.ekstein@alcatel.be
Tjoens, et al. Expires November, 2000 [Page 20]
INTERNET DRAFT draft-tjoens-aaa-radius-comp-00.txt May 2000
Yves T'Joens
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 7890
E-mail : yves.tjoens@alcatel.be
Marc De Vries
Alcatel Carrier Internetworking Division
De Villermontstraat 38, 2550 Kontich, Belgium
E-mail : marc.de_vries@alcatel.be
9.0 Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished
toothers, and derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the procedures
for copyrights defined in the Internet Standards process must be fol-
lowed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Tjoens, et al. Expires November, 2000 [Page 21]