One document matched: draft-ekstein-nasreq-protcomp-00.txt
Submitted to NASREQ Working Group Ronnie Ekstein
INTERNET DRAFT Yves T'Joens
Bernard Sales
<draft-ekstein-nasreq-protcomp-00.txt> Alcatel
October 1999
Expires April, 2000
AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.
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.
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directorieson ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
The main purpose of this draft is to provide an extensive comparison
between the RADIUS, DIAMETER and COPS protocols and to verify their
compliance to the roaming requirements described in RFC 2477.
Ekstein, et al. Expires April 2000 [Page 1]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
Table Of Contents
1. Introduction
2. Protocol Comparison
2.1 Introduction to RADIUS, DIAMETER and COPS.
2.1.1 RADIUS
2.1.2 DIAMETER
2.1.3 COPS
2.2 Support of Authentication, Authorization, Accounting and
Autoconfiguration
2.3 Extensibility
2.4 Support of unsolicited messages
2.5 Reliability
2.6 Scalability
2.7 Security
2.7.1 Hop-by-hop
2.7.2 End-to-end
2.7.3 Conclusions
3. Compliance to RFC 2477
3.1 Roaming Authentication Requirements
3.1.1 Connection Management
3.1.2 Identification
3.1.3 Verification and Identity
3.1.4 NAS configuration/authorization
3.1.5 Address assignement/routing
3.1.6 Security
3.2 Roaming Accounting Requirements
4. Conclusions
5. Acknowledgments
6. References
7. Contacts
[ed. note : some of the references need a check, the security
sections needs a review, so all comments are gladly accepted.]
1. Introduction
Although RADIUS, DIAMETER and COPS all serve the purpose of
distributing (some subfunctions of) the AAA service, there are many
differences among these protocols.
In chapter 2, these differences (based on the protocol operation) are
briefly compared with their possible implications on the
functionality or applicability of the protocol.
Comparison is based upon :
Ekstein, et al. Expires April 2000 [Page 2]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
- the relative support of authentication, authorization, accounting
and transport of configuration information
- the extensibility in terms of messages and attributes
- the support of unsolicited messages
- the reliability in operation
- the scalability
- the way they provide security, both on a hop-by-hop and end-to-end
basis (in proxy situations)
Chapter 3 discusses the compliance of the RADIUS, DIAMETER and COPS
protocols to the requirements for the provisioning of "roaming
capability" for dialup Internet users outlined in RFC 2477.
2. Protocol Comparison
This section compares the basic capabilities of the RADIUS, DIAMETER
and COPS protocols.
2.1 Introduction
2.1.1 RADIUS
The RADIUS (Remote Authentication Dial In User Service) protocol has
been designed for carrying authentication, authorization and
configuration information between a NAS (Network Access Server) and a
centralized RADIUS server. Although the RADIUS protocol has been
defined to support dial-up SLIP and PPP as well as terminal server
services, today it is being used for many more applications.
RADIUS operates in a pure client server paradigm, where the NAS acts
as client to the RADIUS server. The RADIUS server itself can act as a
client to other RADIUS servers, denoted as PROXY operation.
The information on RADIUS has been obtained from RFC 2138 [1] (RADIUS
base protocol) and RFC 2139 [2] (RADIUS accounting extensions).
Information on security issues have been obtained from RFC2607 [5]
(Proxy Chaining).
2.1.2 DIAMETER
In its original concept, DIAMETER has been designed as an "enhanced
RADIUS". It is envisioned that DIAMETER will initially be deployed as
the AAA protocol between ISPs and corporate networks, but it may take
Ekstein, et al. Expires April 2000 [Page 3]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
some time before edge devices support the new protocol. For that
reason, the DIAMETER protocol was designed in such a way that makes
it easy for an DIAMETER implementation to both interwork directly
with RADIUS clients, and to act as a protocol bridge.
The DIAMETER framework and architecture are defined in draft-
calhoun-diameter-framework-02.txt [7], while the base protocol is
defined in draft-calhoun-diameter-08.txt [8]. The base protocol
defines header formats and security extensions as well as a number of
mandatory commands and AVPs (Attribute Value Pairs). There are
several additional application specific DIAMETER extension documents
available, such as [8..14].
2.1.3 COPS
The COPS (Common Open Policy Service) protocol is a simple query and
response protocol in a client/server model, that is used to exchange
policy information between a policy server (Policy Decision Point
(PDP)), and its clients (Policy Enforcement Points (PEPs)). COPS is
under development within the RAP (Resource Allocation Protocol)
group, with the specific purpose to allow authorization of RSVP
resource requests. However, the protocol has been written to be
applicable in a much larger context to authorize access to generic
'resources' in the network (e.g., diffserv).
Although dial-in is presently not under definition in the rap group,
COPS is sometimes referred to as all purpose AAA protocol, therefor
it is compared to both RADIUS and DIAMETER within this document.
Draft-ietf-rap-framework-03.txt [15] describes the framework for
policy based admission control, draft-ietf-rap-cops-06.txt [16]
describes the basic COPS protocol, while draft-ietf-rap-cops-rsvp-
05.txt [17] describes COPS usage for RSVP. [ed. note: exact status
of the docs need to be checked]
2.2 Support of Authentication, Authorization, Accounting and
Autoconfiguration
The support of authentication, authorization, accounting and
autoconfiguration for RADIUS, DIAMETER and COPS is summarized in
Table 1.
Authentication can apply to two different levels: user and client
authentication. Client authentication refers to the authentication
process between peer entities of the protocol, e.g., RADIUS client
and RADIUS server. User authentication refers to the authentication
of the user (session) with the server.
Ekstein, et al. Expires April 2000 [Page 4]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
Authorization applies to the decision by the policy decision server
as to the users access to the resources.
Accounting is the process of gathering resource consumption
information for statistical and/or charging/billing purposes.
(Auto-)configuration relates to the possibility to exchange
information necessary by the policy enforcement point (NAS) to
provide services to the user.
+-------------------------------------------------------------------+
| |Authentication|Authorization| Accounting | Autoconfig |
+-------------------------------------------------------------------+
|RADIUS | OK | OK | OK | OK |
+-------------------------------------------------------------------+
|DIAMETER | OK | OK | OK | OK |
+-------------------------------------------------------------------+
|COPS | Client auth. | OK |Not explicitly| OK |
| | OK | | described | |
| | User auth. | | | |
| | possible | | | |
+-------------------------------------------------------------------+
Table 1 : Support of authentication, authorization, accounting and
autoconfiguration.
2.3 Extensibility
New attributes
RADIUS has a limited command and attribute address space (maximum
256 attributes), and is therefore considered not very extensible.
DIAMETER resolves this limitation by defining a base protocol that
can largely be extended with new attributes (AVP address space of
32 bit).
In COPS, the attributes/objects space is divided into two parts (2
times 8 bit identifier space). The C-Num field identifies the
class of information and the C-Type field identifies a subtype or
version of information contained in the object.
Support of Vendor Specific extensions
Any new service can extend DIAMETER by extending the base protocol
to support new functionality. When the Vendor-Specific bit is set,
the Vendor-ID field carries the identity of the vendor.
Ekstein, et al. Expires April 2000 [Page 5]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
RADIUS also supports Vendor Specific extensibility. The difference
with DIAMETER is that the attribute space is limited to 256 per
Vendor and that DIAMETER also allows for vendor specific messages.
COPS allows for vendor extensibility in the sense that enterprise
specific client types can be assigned.
Attribute data types and structures
COPS allows for delivery of self-identifying, opaque objects of
variable length. The protocol does not have to be changed every
time a new object has to be exchanged. RADIUS and DIAMETER both
have a few predefined data types. The list is more extended in
DIAMETER but in both cases do not allow for self-identifying
opaque objects.
DIAMETER provides the possibility for tagging attributes, allowing
the construction of more complex data structures within the
message. This is not supported by RADIUS nor by COPS.
2.4 Support of unsolicited messages
Unsolicited messages are messages which are not a reply to an
explicit request. This feature is imperatively needed for the support
of services where session/configuration information needs to be
changed during a session (e.g. dynamic policy, credit limited
operation).
Unsolicited messages are not supported by RADIUS, which is a pure
client/server protocol that requires a client to initiate a request.
DIAMETER supports unsolicited messages, that is to say a "server" can
send unsolicited messages (i.e. ) to a "client".
COPS allows for 2-way data exchanges, initiated by both a PEP or a
PDP. A PEP must in fact be able to initiate requests for policy
decisions, re-negotiate them and exchange policy information. A PEP
must be able to report monitoring information and policy state
changes to the PDP at any time. COPS also supports asynchronous
notifications in order to allow both the policy server and client to
notify each other in case of an asynchronous change of state.
2.5 Reliability
Reliability of operation is concerned with the detection of failure
of delivery of information between the peers of the protocol, and the
fail-over to backup servers when communication with the original
server would no longer be possible.
Ekstein, et al. Expires April 2000 [Page 6]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
Reliable delivery of information
RADIUS relies on UDP for the delivery of information between
client and server, the protocol handles the loss of request by
implenting a time-out and retransmission strategy. However, the
protocol specification failed to define a standard retransmission
and timeout scheme, resulting in many different implementations
and interworking problems.
DIAMETER is defined to operate over UDP, and provides some
explicit extensions to add reliability over the connectionless
transport. DIAMETER makes use of UDP rather then TCP in that the
protocol requires a more fine-tuned retransmission and timeout
policy than most TCP stacks currently provide.
Furthermore, in the world of AAA, it is very important that fail-
over to backup servers occurs quickly, and this cannot be achieved
when TCP is used. However, there is currently some work under way
in the IETF to design a new transport that would provide similar
services that DIAMETER has defined.
For COPS, the sensitivity of policy control information also
necessitates reliable operation. Undetected loss of policy queries
or responses may lead to inconsistent network operation and are
clearly unacceptable for actions such as billing and accounting.
COPS relies entirely on TCP.
Flow Control
RADIUS uses UDP without explicit flow control.
DIAMETER provides flow control over UDP. For that purpose, a
sliding window mechanism is used that allows dynamic
reconfiguration of the window size. The value of the window size
is specified by the Receive-Window AVP in the Device-Reboot-Ind
message.
COPS runs over TCP and therefor implicitly relies on the inherent
TCP flow control.
Survivability to peer outage and resynchronization
In case of server failure, the RADIUS client will try to contact a
backup RADIUS server. Due to the stateless nature of communication
of RADIUS peers and the usage of UDP as transport protocol,
subsequent resynchronization between client and server is not
necessary.
Ekstein, et al. Expires April 2000 [Page 7]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
DIAMETER uses the Device-Reboot-Ind (detailed in [7]) message,
which is used to indicate an imminent reboot together with the
Device-Watchdog-Ind message to provide peer failure recovery and a
keepalive mechanism.
In COPS resynchronization after failure is provided by the SSQ and
SSC messages, as described in [16].
2.6 Scalability
Scalability is very important for the case where many users perform
AAA functionalities or open sessions simultaneously at the same
server. Scalability limitations arise mainly from the requirement to
keep and/or synchronize a huge amount of states among network
elements.
Implementation Specific Issue
RADIUS messages are byte alligned while DIAMETER and COPS messages
are 32-bit alligned. The latter increases the number of
transactions/sec that a server can handle.
State on the transport layer
For all communication protocols, the scalability on the transport
layer is proportional to the amount of client/server relationships
and not with the amount of users.
RADIUS runs on UDP and requires state only to be maintained for a
request/reply interaction at the client side.
When DIAMETER relies on the enhanced UDP procedures, state should
be maintained related to the sliding windows mechanism.
COPS relies on TCP and therefore states are maintained and timers
are used.
In general, UDP operation can be considered somehow more scalable
than TCP operation.
State on the session level
The state maintenance per user session on the client/server has a
more profound effect on the scalability.
RADIUS does not maintain any session states in real time. (Note
however, that off-line, 'state' should be maintained for
accounting purposes, such that accounting starts can be associated
Ekstein, et al. Expires April 2000 [Page 8]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
to accounting stops.)
COPS defines states (handles) to be maintained for each session
that is currently in progress. That means that there will be a
limit of the amount of concurrent handles manageable by a PEP or
PDP.
DIAMETER defines the concept of session state in the context of
resource management extensions [7]. Thereby DIAMETER experiences
the same scalability constraints as encountered in COPS.
2.7 Security
In its most generic representation, a policy enforcement point at the
edge of the network has to contact a policy decision point in order
to perform authentication, authorization and/or accounting actions.
However, in some situations, the policy decision can not be obtained
from the contacted server, and the action is deferred to a subsequent
policy server, in which case the original policy decision point acts
as a proxy server.
The use of proxy chaining is pertinent in the case of roaming
operations, and has been extensively reviewed in RFC 2607 [5].
The single operation of roaming requires interdomain trust
relationships, and opens the door to a number of security attacks.
This section will give a high level view of the security breaches
involved in roaming operations. Both hop-by-hop (client/server) and
end-to-end (proxy chaining) security is dealt with in the various
protocols under consideration.
[this section still needs some further work. A number of drafts that
serve as input to this section are in an unclear state.]
2.7.1 Hop-by-hop
The following attacks can be launched on the hop-by-hop client/server
communication
o Denial of Service : flooding the target equipment with bogus
traffic.
o Masquerade : acting as another valid entity, thereby gaining
unauthorised access to some resources.
o Replay attack : replaying valid PDUs (or entire conversations) from
Ekstein, et al. Expires April 2000 [Page 9]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
the sender to the responder.
o Man-in-the-middle : taking undetected part of the communication
between sender and responder thereby having the capability to change
protocol data.
o Eavesdropping : Gaining access to information in the communication
between sender and responder
o Repudiation : denying having received some information from the
sender by the recipient.
Denial of Service
Denial of service attacks by means of flooding the server can
usually not be dealt with by means of protocol extensions, but
should be handled by implementation specific measures at the
network element. Authentication of the sending party could provide
a first level of protection against denial of service attacks (see
further).
Replay attack
RADIUS does not provide for protection against replay attacks.
COPS relies on IPSEC for its hop-by-hop protection. replay ??
time-stamp, counter ? [ed. note :to be checked again in line with
the recent decision on integrity check vector]
DIAMETER.. [ed. note : replay of individual messages hop-by-hop ,
to be added for all in next version]
Masquerading
A RADIUS client and server maintain between them a shared secret.
A RADIUS server can authenticate the clients request only if the
shared secret has been used in the context of password hiding. A
User-Password attribute is the plain-text user password encoded
with the MD5 digest of the octet stream consisting of the shared
secret and the Authenticator. If the User-Password attribute is
not available, no other explicit authentication information is
available within the request. Some means for client authentication
is proposed in [4] by introducing the Signature Attribute in the
Access Request messages.
The RADIUS client can check the identity of the server by checking
the reply authenticator field that has been constructed based upon
the original request message and the shared secret.
Ekstein, et al. Expires April 2000 [Page 10]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
COPS relies explicitly on IPSEC. Both IPSEC-AH and ESP provide
authentication of the communicating parties
DIAMETER relies on the integrity check vector for authenticating
the remote party while checking the integrity of the
communication. The correct integrity check vector can only be
produced by the party having access to the shared secret, thereby
sender identity is checked.
Man-in-the-middle attacks
RADIUS relies on the implicit integrity check of the client/server
communication within the reply message to avoid any change of data
from the man in the middle. The Server has no means to detect any
changes in requests issued by the client. However, it has been
proposed [4] to add a Signature attribute to RADIUS to overcome
the security weakness in checking sender identity and content
integrity of Access-Request packets. The content of the attribute
is an MD-5 digest of the shared secret followed by the entire
Access-Request packet, including the Code, ID, Length and
Authenticator. The Signature attribute must be used in any
Access-Request packet sent across administrative boundaries. This
attribute should be used even when the packet contains a User-
Password attribute.
DIAMETER relies on the integrity check vector to identify changed
message contents.
COPS relies on IPSEC. Recently, an integrity check vector
mechanism has been added to the COPS specification. This would
allow COPS to provide for simple authentication and integrity
checking at the application layer without the usage of lower layer
IPSEC.
Eavesdropping
RADIUS only provides for hiding of the User-Password attribute.
Other attributes are send in cleartext.
COPS can rely on IPSEC ESP if the communication privacy needs to
be guaranteed.
DIAMETER allows individual attributes to be hidden within the
message, but also IPSec is specified as an alternative to the
Integrity-Check-Vector and for privacy. If IPSec is not used, the
protocol provides it's own. Both are for hop-by-hop, of course.
Repudiation
Ekstein, et al. Expires April 2000 [Page 11]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
not discussed within this version of the draft
2.7.2 End-to-end security
As stated before, there are cases in which a AAA server can act as
a PROXY. In dial roaming for instance, to authenticate a user,
message exchanges are not limited to one client and server. At
least 1 PROXY AAA Server is involved between the NAS and the home
AAA authentication server containing the user database. In the
case of a roaming situation, it is sometimes required that user
authentication messages be exchanged among facilities
administrated by different service providers.
Figure 1 shows an example of a roaming network, where a user
(tom@isp1.net) wishes to get Internet Access from a third party
(midisp.net). More complicated operation models involve two or
more cascading AAA PROXY servers or one AAA PDU branched out to
two or more AAA servers. AAA PDU packets are transported over the
public network beyond the control of the distributed AAA server
operators. Security risks increase because authentication and
accounting packets have much higher chance than in a single
operator environment to be intercepted, modified and injected by
adversaries.
+---------------------------+ +----------------+
| PROXY Server | | Home Server |
+-------+ | +-------+ +--------+ | Inet | +--------+ |
| PPP |-----| NAS |----| AAA |-------------| AAA | |
+-------+ | +-------+ +--------+ | | +--------+ |
Tom@isp1.net| | | |
| Mid ISP's Network | | ISP1's Network |
+---------------------------+ +----------------+
Figure 1 : Example of a roaming network operating with RADIUS.
Some of the hop-by-hop vs. end-to-end dilemmas arise from the fact
that the AAA protocol is used not only for authentication but also
for resource authorization purposes and that the intermediate AAA
servers in a proxy chain often play roles in resource
authorization rather than to simply relay messages.
The proxy chaining operation is particularly susceptible to the
following security attacks (as taken from RFC 2607 [5]).
o Message editing : An untrusted proxy is capable of modifying the
message [ed. note : however, this can also occur due to normal
operation, so ???]
o Attribute editing : An untrusted proxy is capable of modifying
Ekstein, et al. Expires April 2000 [Page 12]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
individual attributes. Since this can be part of normal operation,
the sender should be able to indicate which attributes should not
be changed. Therefore attribute level integrity should be
available.
o Theft of passwords : Proxies can record cleartext passwords
while they are forwarded.
o Theft and modification of accounting data : Proxies can modify
accounting packets or session records.
o Replay attacks : replaying valid PDUs (or entire conversations)
from the sender to the responder.
o Connection hijacking : inserting packets into the conversation
between endpoints of the communication
o Fraudulent accounting : a proxy transmits fraudulent accounting
packets or session records in an effort to collect fees to which
they are not entitled.
Message and Attribute editing
RADIUS does not provide any support for end-to-end security on the
message and attribute level.
DIAMETER allows for attribute level security, by using the 'H' and
'E' bits as special AVP flags, which specify respectively for a
certain attribute (AVP) that end-to-end or hop-by-hop security is
used.
The COPS architecture presently does not discuss proxy chaining
security.
Theft of passwords
The RADIUS protocol has no attribute information hiding capability
except on authentication credential attributes such as User-
Password. Since in CHAP, the password does not travel on the wire,
CHAP is not prone to this kind of attack. Password hiding in a
User-Password attribute is limited considering the intermediate
RADIUS components not involved in user authentication can decode
the password. User password checking is usually the role of the
home RADIUS server. No intermediate RADIUS servers should have any
business in the User-Password attribute, but unfortunately they
all can decode and even edit the user password.
DIAMETER provides for end-to-end attribute level hiding algorithm,
Ekstein, et al. Expires April 2000 [Page 13]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
and as such, passwords can be hidden from intermediary proxies.
The COPS architecture presently does not discuss proxy chaining
security.
Theft and modification of accounting data and Fraudulent accounting
RADIUS does not provide for end-to-end security services,
including integrity protection or confidentiality. Without end-
to-end integrity protection, it is possible for proxies to modify
accounting packets or session records. Without end-to-end
confidentiality, accounting data will be accessible to proxies.
Diameter presently does not describe accounting as such, but
provides for end-to-end security services, thereby alleviating any
theft and modification of (future defined) accounting data.
Replay attacks
A man in the middle (rogue proxy) can collect CHAP challenge and
CHAP response attributes and later replay them. This can be used
by an unscrupulous ISP, to subsequently submit fraudulent
accounting records. RADIUS does not provide for any protection
against this attack.
DIAMETER provides the ability for the home server to generate the
challenge to the user. This is supported for both CHAP and EAP.
This enables the home to control the challenge presented to the
user, thereby effectively eliminating the possibility for replay
of authentication attacks.
Connection hijacking
In RADIUS, the attacker can inject packets in the NAS - home
server conversation, since only Access-Reply and Access-Challenge
packets are authenticated.
Diameter provides against this attack by authenticating each
message.
2.7.3 Conclusions
Many have suggested using IPSEC to overcome the security problems
with AAA protocols. This may help in packet integrity and sender
identity checking, preventing replay attacks and, to some extent,
data confidentiality. However, as a lower layer measure, IPSEC
cannot solve the hop-by-hop vs. end-to-end dilemma in the upper
Ekstein, et al. Expires April 2000 [Page 14]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
layer and prevent a PROXY server from tampering with attributes
beyond its intended scope.
The ultimate solution to the hop-by-hop vs. end-to-end dilemma and
the data confidentiality problem lies with attribute level
security, with which an attribute can be inspected and edited only
by the specified AAA servers in the proxy chain. Without attribute
level security, the length of a proxy chain and the complexity of
a roaming relation are limited by trust, and PROXY servers should
not be used only for packet relay without any other benefit.
3. Compliance to RFC 2477
RFC 2477 provides an architectural framework for the provisioning
of roaming capabilities, as well as describing the requirements
that must be met by elements of the architecture.
For the compliance verification of RADIUS, DIAMETER and COPS
protocols with the requirements outlined in RFC 2477, only
Authentication and Accounting subsystems are relevant. The Phone
book subsystem is not considered.
Since presently there is not documented support of cops for PPP
dial-in, a number of the following requirements may seem to be
irrelevant to the consideration of COPS as 'roaming' protocol.
3.1 Roaming Authentication Requirements
3.1.1 Connection Management
RADIUS and DIAMETER provide support for PPP. Presently, no COPS
extensions for supporting PPP have been defined.
3.1.2 Identification
RADIUS and DIAMETER provide a standardized format for the userID
and realm. In COPS, the PEPs are being identified at the PDPs and
user identification is also possible [17], where the information
will be taken from the initiating message (e.g. RSVP path/resv).
3.1.3 Verification of Identity
CHAP and EAP are supported by RADIUS [1][3] and DIAMETER [13][12].
In COPS no direct user identification exists. PAP for both RADIUS
and DIAMETER is NOT a requirement, it can be omitted by using CHAP
or EAP.
Support of RADIUS is a requirement. DIAMETER is backwards
Ekstein, et al. Expires April 2000 [Page 15]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
compatible with RADIUS. This is not relevant for COPS.
3.1.4 NAS configuration/authorization
Attribute editing is provided by both RADIUS and DIAMETER. Also in
COPS each PDP can edit the passing information.
3.1.5 Address assignment/routing
RADIUS supports dynamic address assignment, but also static
address assignment with support of layer 2 and layer 3 tunneling
protocols.
DIAMETER also supports static and dynamic address assignment, as
described in [12].
This is not relevant for COPS, as it has not been designed for
dial-in purposes.
3.1.6 Security
RADIUS and DIAMETER include a security analysis. For RADIUS only
hop-by-hop security and no integrity checking is provided whereas
for DIAMETER end-to-end security, integrity checking and also
attribute level security is provided.
COPS provides only for hop-by-hop security by means of IPSEC and
the recently defined integrity check vector object.
3.2 Roaming Accounting Requirements
[to be done]
4. Conclusions
This draft gives a comparison between RADIUS, DIAMETER and COPS,
which all seem to serve the same purpose of AAA-protocol. Note
that these protocols are still under development and are subject
to changes.
Today, RADIUS and DIAMETER are aiming at dial-in and thus typical
login-type services while COPS aims at resource administration
policy.
DIAMETER has the widest set of protocol features and allows
explicitly for interdomain proxy operation, and thereby seems to
be able to become the platform for the AAA evolution. However, its
specification is not complete and should be integrated with the
Ekstein, et al. Expires April 2000 [Page 16]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
support for QoS resource policy enforcement provided today by
COPS.
5. Acknowledgements
The authors would like to thank Pat Calhoun (Sun Microsystems) and
Marc Vandenhoute (Alcatel) for the review of prior versions of
this draft. We would also like to thank some of the authors of
the references hereunder for text that might have been explicitly
used in this draft.
6. References
[1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997
[2] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997
[3] P. Calhoun, A. Rubens, B. Aboba, "Extensible Authentication
Protocol Support in RADIUS", draft-ietf-radius-eap-05.txt, Work in
Progress, May 1998
[4] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions",
draft-ietf-radius-ext-04.txt, Internet Draft, May 1999.
[5] B. Aboba, J. R. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607 (Informational), June 1999
[6] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming
Protocols", RFC 2477 (Informational), January 1998
[7] Calhoun, Zorn, Pan, "DIAMETER Framework", draft-calhoun-
diameter-framework-03.txt, Work in Progress, October 1999
[8] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-
calhoun-diameter-09.txt, Work in Progress, October 1999
[9] P. Calhoun, A. Rubens, "DIAMETER Reliable Transport
Extensions", draft-calhoun-diameter-reliable-01.txt, IETF Work in
Progress, February 1999 (Now chapter 3 in draft-calhoun-diameter-
09.txt)
[10] P. Calhoun, N. green, "DIAMETER Resource Management
Extensions", draft-calhoun-diameter-res-mgmt-03.txt, Internet
Draft, February 1999
[11] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions",
Ekstein, et al. Expires April 2000 [Page 17]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt October 1999
draft-calhoun-diameter-proxy-03.txt, Work in Progress, October
1999.
[12] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication
Protocol Extensions", draft-calhoun-diameter-eap-03.txt, Work in
Progress, August 1999
[13] P. R. Calhoun, "DIAMETER Authentication Extension", draft-
calhoun-diameter-authent-07.txt, October 1999.
[14] P. R. Calhoun, "DIAMETER Mobile-IP Extension", draft-
calhoun-diameter-mobileip-02.txt, August 1999.
[15] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for
Policy-Based Admission COntrol", draft-ietf-rap-framework-03.txt,
April 1999.
[16] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A.
Sastry, "The COPS (Common Open Policy Service) Protocol"
Internet-Draft, draft-ietf-rap-cops-07.txt, August 1999
[17]S. Yadav, R. Pabbati, P. Ford, S. Herzog, "User Identity
Representation for RSVP", draft-ietf-rap-user-identity-
00.txt,Internet Draft, March 1998 (Expired)
7. Contacts
Ronnie Ekstein
Alcatel Corporate Research Center
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 241 5958
E-mail : ronnie.ekstein@alcatel.be
Yves T'joens
Alcatel Access Systems Division
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 7890
E-mail : yves.tjoens@alcatel.be
Bernard Sales
Alcatel Corporate Research Center
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 9574
E-mail : bernard.sales@btmaa.bel.alcatel.be
Ekstein, et al. Expires April 2000 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-22 14:07:00 |