Submitted to NASREQ Working Group Ronnie Ekstein INTERNET DRAFT Yves T'Joens Bernard Sales 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]