Submitted to AAA Working Group Ronnie Ekstein INTERNET DRAFT Yves T'Joens Bernard Sales Alcatel Olivier Paridaens ULB April 2000 Expires October, 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 Directories on 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 purpose of this draft is to provide an extensive comparison between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic Authentication, Authorization and Accounting (AAA) protocols. The protocols will further be verified on their compliance to the NAS requirements described in [TBA] and roaming requirements described in RFC 2477. Ekstein, et al. Expires October 2000 [Page 1] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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 Backward and Version Extension Compatibility 2.7.1 Capability Adjustement and Mandatory Bit 2.8 Security 2.8.1 Overview of Security Threats 2.8.1.1 Denial of Service 2.8.1.2 Replay 2.8.1.3 Masquerade 2.8.1.4 Man-in-the-Middle Attack 2.8.1.5 Eavesdropping 2.8.1.6 Traffic Flow Analysis 2.8.1.7 Unauthorised Access 2.8.1.8 Information Loss 2.8.1.9 Information Corruption 2.8.1.10 Information Forgery 2.8.1.11 Repudiation 2.8.2 Security Services 2.8.2.1 Denial of Service Prevention 2.8.2.1.1 Overview 2.8.2.1.2 RADIUS 2.8.2.1.3 DIAMETER 2.8.2.1.4 COPS 2.8.2.2 Replay Prevention 2.8.2.2.1 Overview 2.8.2.2.2 RADIUS 2.8.2.2.3 DIAMETER 2.8.2.2.4 COPS 2.8.2.3 Data Integrity Check 2.8.2.3.1 Overview 2.8.2.3.2 RADIUS 2.8.2.3.3 DIAMETER 2.8.2.3.4 COPS 2.8.2.4 Entity Authentication 2.8.2.4.1 Overview 2.8.2.4.2 RADIUS Ekstein, et al. Expires October 2000 [Page 2] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 2.8.2.4.2.1 Native Authentication 2.8.2.4.2.2 Signature Attribute 2.8.2.4.3 DIAMETER 2.8.2.4.3.1 Hop-by-hop Authentication 2.8.2.4.3.2 End-to-end Authentication 2.8.2.4.4 COPS 2.8.2.5 Data Authentication 2.8.2.5.1 Overview 2.8.2.5.2 RADIUS 2.8.2.5.3 DIAMETER 2.8.2.5.4 COPS 2.8.2.6 Data Confidentiality 2.8.2.6.1 Overview 2.8.2.6.2 RADIUS 2.8.2.6.3 DIAMETER 2.8.2.6.3.1 Hop-by-hop Encryption 2.8.2.6.3.2 End-to-end Encryption 2.8.2.6.4 COPS 2.8.3 IPsec 2.8.3.1 RADIUS 2.8.3.2 DIAMETER 2.8.3.3 COPS 2.8.4 TLS 2.8.4.1 COPS 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 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 Ekstein, et al. Expires October 2000 [Page 3] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 functionality or applicability of the protocol. Comparison is based upon : - 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 backward and version extension compatibility - 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. The comparison to the nasreq requirements will be added when stable. 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. Information on RADIUS can be obtained from RFC 2138 [1] (RADIUS base protocol) and RFC 2139 [2] (RADIUS accounting extensions), although many extensions beyond these base specifications can be found in the Ekstein, et al. Expires October 2000 [Page 4] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 wide industry today e.g. RADIUS Extensions [18]. Information on security issues can be 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 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-05.txt [7], while the base protocol is defined in draft-calhoun-diameter-12.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..13]. 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 has been originally specified to allow authorization of RSVP resource requests in Intserv supporting networks. 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 an all purpose AAA protocol, therefor it is compared to both RADIUS and DIAMETER within this document. Draft-ietf-rap-framework-03.txt [14] describes the framework for policy based admission control, draft-ietf-rap-cops-08.txt [15] describes the basic COPS protocol, while draft-ietf-rap-cops- rsvp-05.txt [16] describes COPS usage for RSVP. [ed. note: waiting on the RFC queue today] 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 Ekstein, et al. Expires October 2000 [Page 5] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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. 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 Ekstein, et al. Expires October 2000 [Page 6] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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. 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 Ekstein, et al. Expires October 2000 [Page 7] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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. 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. Ekstein, et al. Expires October 2000 [Page 8] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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. 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 [15]. 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. Ekstein, et al. Expires October 2000 [Page 9] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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 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 Backward and Version Extension Compatibility 2.7.1 Capability Adjustement and Mandatory Bit. Due to the fact that AAA protocols in general, and the in this draft discussed protocols specifically, will see extensions defined to them on a continu basis, it is quite possible that a protocol client and server are currently (on the moment of the message exchange) not updated with the same official and standardized version of the protocol. This might have as result that a server will get a message with a standardized attribute/AVP extension that is unknown by its implementation (this applies even more for proprietary Vendor Specific extensions). There are various methods to handle this version/extension incompatibility between communicating parties. The simplest and most obvious solution is to require all communicating parties to be upgraded to the new version/feature set at the same time. While this might still be regarded feasible for single administration/single vendor configuration, the task gets more difficult in a single administration/multi vendor configuration, and hardly practical in a multi administration/ multi vendor configuration. The second most trivial solution would be manual configuration of Ekstein, et al. Expires October 2000 [Page 10] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 the supported protocol version on a peer to peer communication basis, but this too is obviously not scalable, when different administrative entities are involved. A further possiblity is to work with 'automated capability negotiation', which means that at start-up an entity will communicate what protocol features/extensions it supports, such as the version number of the protocol (if sequentially upgraded) and/or a bitmap of the supported AVPs. This forces both communicating parties to settle for the shared set of extensions they support. Another solution is to provide some added information in the attribute/message itself by means of e.g., the mandatory bit. For the latter, depending on the bit setting the action to be taken by an entity receiving an unknown attribute/message is either to silently discard it and proceed or to interrupt the session associated with the sending of this attribute/message. It can further send back an error message (with a certain level of error reporting). While the above solutions are capable of handling inconsistencies in version/features between directly communicating parties, the picture gets more complex in proxy situations. As a matter of fact, for a PROXY getting an unknown attribute/message, there is an additional possible action, namely forward the attribute/message unmodified to the next hop. Note that capability negotiation here is not applicable because therefor one will need communication with the entity at the other end. Let's now have a look at the considered protocols and how they handle version inconsistency between the communicating parties. In the RADIUS protocol specification, it is indicated that a message arriving with an unknown code should be silently discarded and that A RADIUS server/client MAY ignore Attributes with an unknown Type. While for operation this might be satisfying, it gives little benefit when broken communications need to be debugged. In DIAMETER, use is made of the mandatory bit, while further more, error reporting is more expanded. I-D [8] specifies the actions that should be taken in the case that an unknown message or AVP for which the mandatory bit has been enabled is received. That is to say, the non-understanding party should send back a Message- Reject-Ind message together with the appropriate Result-Code AVP and a Failed-AVP AVP. Ekstein, et al. Expires October 2000 [Page 11] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 For either DIAMETER or RADIUS, this does not solve the problem of the case where the protocol versions in the PROXY case are not the same. The proxy will break any communication for which the extension is not known to it, whether or not the proxy's understanding is necessary for the end-to-end communication. The dropping of non-known attributes/messages might have a further consequence. In RADIUS care should be taken that the Signature attribute defined in the extensions draft [] should be calculated over all signed attributes, understood or not. In DIAMETER a Digital Signature attribute can be used to provide for authentication, integrity and non-repudiation of AVPs, even in the end-to-end scenario. These AVPs will be indicated by having their 'P' bit set. It is indicated in the specifications [11] that a proxy server MUST NOT remove, add, or change any AVP that has the 'P' bit set, having unknown attributes removed from the message as indicated in [11] will brake the validity of the total end signature. In order to make this proxy operation work, all the intermediate proxies should at least support the version of the originating entity, which again may be a limiting requirement. In COPS, the Error Object and/or the Reason Object can be used to indicate that a Object's C-Num or C-Type is unknown. This will usually have the deletion of a state/-request as consequence. Note here that since the proxy operation for COPS is unclear, no assumptions are further made within this draft. 2.8 Security This section discusses the security mechanisms embedded within the three AAA protocols. We first present the various generic types of security threats which such a AAA protocol can be faced with. We then identify various types of security measures which can be applied to counter those threats. For each of those security services, we discuss the case for each AAA protocol. 2.8.1 Overview of Security Threats 2.8.1.1 Denial of Service This type of attack consists in flooding the target equipment (a host, router or any other type of equipment) with bogus traffic. The target equipment must spend some resource on processing each received Protocol Data Unit (PDU) (whether IP, UDP, TCP or any other type of PDU) before discovering that it is a bogus packet which can be discarded. A more subtle form of this attack is to let the target Ekstein, et al. Expires October 2000 [Page 12] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 equipment believe that it must react in a normal way to the bogus packet. The target may then return packets to some other equipment or may start waiting for some additional information which will never arrive. At some level of such bogus traffic, the target will be submerged and will have no more internal resources to process valid traffic. 2.8.1.2 Replay This type of attack consists in replaying valid PDUs from the sender to the responder. Whether this type of attack is meaningful depends on the protocol concerned. Replaying individual IP packets containing TCP data does not really make sense because each packet usually contains only part of a more complete data and the target equipment will detect duplicates. However, there are contexts where this can be serious. In particular, a complete dialogue could be replayed at a later time by the attacker, which can have serious consequences if the data carried can be validly interpreted twice by the responder. 2.8.1.3 Masquerade Masquerading consists in an attacker which masquerades as another valid entity. This can be the basis for unauthorised access to some resources on the target equipment (for example, for some management task). This can simply be used to create fake "messages" which falsely appear to come from a given source. At the IP level, this typically consists in the attacker using a fake source IP address. This however requires that the attacker can capture responses from the target, which are sent to the fake IP address. 2.8.1.4 Man-in-the-Middle Attack This type of attack consists in the attacker trying to take advantage that it is placed between both valid partners exchanging information and can therefore intercept all the exchanged information and try to take part in the dialogue itself so as to replace one of the participants for example. This is therefore an active attack. For some protocols (especially in cryptographic-oriented protocols such as key exchange or authentication protocols), it is very important to counter such attacks. For conventional protocols, the man-in-the- middle attack is actually the basis for other attacks such as eavesdropping, replay and masquerading since these are usually realised by an entity located "between" both parties. 2.8.1.5 Eavesdropping This threat consists in having an authorised third-party "reading" Ekstein, et al. Expires October 2000 [Page 13] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 the data exchanged between two (or more) entities. Depending on the situation, this can be of no importance or can be problematic if the data is sensitive to some degree (typically such as configuration or management information). To the contrary of what happens with the man-in-the-middle attack, this attack is more passive. 2.8.1.6 Traffic Flow Analysis This threat is a variant of the previous one in which the unauthorised third-party cannot "read" the data but can still see when the entities are exchanging data. It can also sometimes deduce which parties are exchanging data and which protocols are used (which is also information by itself). 2.8.1.7 Unauthorised Access This consists in an unauthorised entity which gains access to some resource (equipment, program, ). This is usually consecutive to the attacker being able to masquerade as another authorised entity. This can also be due to a lack of access control mechanism on the target resource. 2.8.1.8 Information Loss This type of threat is most of the time unintentional and due to the network unreliability for datagram connection-less protocols. An attacker can still intentionally drop packets before they reach their target. In any case, the entities must be able to detect such losses and resend the lost packets. 2.8.1.9 Information Corruption With this type of threat, the data exchanged between the entities is modified, either intentionally or not. A mechanism is therefore necessary to detect (and if possible correct) erroneous data. 2.8.1.10 Information Forgery In this type of attack, an attacker creates fake PDUs and later claims that it was sent to or received from another entity. 2.8.1.11 Repudiation This consists in an entity which, having sent or received some information, later denies having actually sent or received it. We can define various variants of repudiation such as emission repudiation, reception repudiation, according to which type of action is being denied. Ekstein, et al. Expires October 2000 [Page 14] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 2.8.2 Security Services 2.8.2.1 Denial of Service Prevention 2.8.2.1.1 Overview This type of security service covers denial of service attacks. These are actually virtually impossible to completely counter. Whatever mechanism is added to a protocol to try and detect bogus traffic, a minimum of processing must always be done on the received PDU before deciding whether it can further proceed or must be rejected. It is still therefore possible to flood the implementation in such a way that it will be unable to fully process valid requests. To prevent denial of service attacks to a maximum extent possible, protocols must build a mechanism by which each party can easily identify valid PDUs before fully processing them. This can for example be achieved by the use of tokens which clearly identify the entities in the exchange. Such tokens must be easily checkable so that not too much time is wasted in validating the received PDU. 2.8.2.1.2 RADIUS No mechanism is defined within RADIUS itself to prevent denial of service attacks. An attacker can easily flood a RADIUS server with bogus RADIUS Access-Request messages. Because the RADIUS server only determines valid messages on the basis of the IP datagram's source IP address, an attacker can easily generate spoofed packets in order to have the RADIUS server starting processing the fake request. The RADIUS server will normally eventually end up rejecting the message because the RADIUS or peer user's authentication will fail (see section 2.8.2.4.2 for further details). On the RADIUS client's side, no specific mechanism is provided either. When receiving a RADIUS Access-Accept, Access-Reject or Access-Challenge message from the server, the client must use the IP datagram's source IP address and the Identifier field in the RADIUS message to determine which server the response is coming from. Based on that, the client will have to check the Response Authenticator field of the message in order to ensure this is no fake response. A technology such as IPsec can easily be used to prevent such attacks, as described in section 2.8.3.1. Note that because the RADIUS server is normally located within the boundaries of the network infrastructure, access to it should be protected with some form of firewalling. This should reduce the risk of attacks such as this one. 2.8.2.1.3 DIAMETER DIAMETER contains no native mechanism to prevent denial of service attacks. A DIAMETER entity can be flooded with bogus messages which Ekstein, et al. Expires October 2000 [Page 15] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 the entity will try and process before eventually discarding them. Initial identification of a received message is indeed based on the source IP address in the IP datagram header, which can easily be faked. DIAMETER attributes such as host-IP-address, host-name, session-id can also be used to determine and validate the host from which the message is coming. These can however also be faked if not protected with some form of data integrity mechanism. Mechanisms considered in 2.8.2.4.3 and 2.8.3.2 can be used to help in countering denial of service attacks, as they can protect the information items mentioned here above. Note that when the DIAMETER dialogue takes place within a single controlled environment (ie. no third-party proxying is used), the risk of denial of service is less important since the DIAMETER server is normally protected by a firewall. 2.8.2.1.4 COPS Because the PDP indicates the the PEP which policy to follow, it can be the target of attacks which will prevent it from further responding to valid requests from the PEP. This would eventually prevent the PEP from getting accurate policy information and leave the PEP on its own for making decisions. The PEP could then make local decisions or simply stop working in absence of a PDP. The PEP itself can be subject to denial of service attacks in order to isolate it from any PDP server from which to obtain decisions. This would even probably prevent the PEP from working normally under the processing or network flood. Two main categories of attacks can be mounted for this purpose. First, the PEP or PDP can be flooded with void TCP connections (since COPS lies over TCP) or with bogus COPS messages in the context of an existing TCP connection. Second, the TCP connection between both entities can be cut off so as to prevent any COPS dialogue. COPS does not contain any embedded protection against this type of threat but recommends the use of IPsec as discussed in section 2.8.3.3. Since COPS lies over TCP, TLS could also be used as discussed in section 2.8.4. 2.8.2.2 Replay Prevention 2.8.2.2.1 Overview Anti-replay mechanisms cover replay attacks and are usually based on the use of monotonically incremented counters. As each PDU is uniquely identified with a counter value, duplicates are easily detected and rejected. An anti-replay mechanism is usually managed with a sliding window which helps keeping track of which PDUs have been so far received and which "advances" as more PDUs are received. Clearly, over a reliable connection-oriented network, such a sliding window can be reduced to a size of 1 because we are ensured to receive successive PDUs in the same order they were sent. Duplicates Ekstein, et al. Expires October 2000 [Page 16] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 are detected because they come out of order of the normal succession of PDUs (each identified by a monotonically increasing number). The sliding window is particularly important for non-reliable connectionless networks in which PDUs can arrive in any order. Obviously, the sequence number inserted into each PDU should be protected against modifications (using an integrity check mechanism for example). 2.8.2.2.2 RADIUS We identify two different contexts within which replay attacks could occur. First, an attacker can try and mount a replay attack in an environment where there is a single RADIUS connection (i.e. no RADIUS proxies involved). Normally, the system which requests authentication from the remote user and which eventually lets the user go through, also runs the RADIUS client. Such a system can typically be a NAS or a firewall. What a malicious remote user would typically want to do is to imitate the RADIUS server and return an Access-Accept message to the RADIUS client when this latter is trying to authenticate the attacker. The remote user must therefore be able to act simultaneously at the front of the NAS or firewall and behind it (where the RADIUS protocol takes place). Such a simultaneous access is somewhat problematic in itself. Section 2.8.2.4.2 describes RADIUS internal mechanisms which, when used, prevent RADIUS message replays. When IPsec is used below the RADIUS protocol, it also provides anti-replay services between adjacent RADIUS entities. Second, an attacker can try and mount a replay attack in an environment where the RADIUS messages are being proxied by intermediate RADIUS entities. Such attacks can be easier to mount considering that a RADIUS proxy is under the control of some other organization. Even more, the organization running the initial RADIUS client and server are typically out of control of the organization where authentication really takes place (normally the remote user's home organization). Any intermediate RADIUS proxy can therefore be subverted so as to return fake Access-Accept messages to positively authenticate a malicious remote user. Depending on the user authentication method being used (one for which a different challenge is not sent by the RADIUS authentication server every time), the initial RADIUS client can initiate replayed Access-Request messages in order to get access authorization. Section 2.8.2.4.2 discusses RADIUS internal mechanisms which, when used, can help in preventing such replay attacks. 2.8.2.2.3 DIAMETER Similar considerations as those described above for RADIUS apply in the context of DIAMETER. Section 2.8.2.4.3 discusses DIAMETER internal mechanisms which prevent DIAMETER message replays in proxy Ekstein, et al. Expires October 2000 [Page 17] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 and non-proxy environments. When IPsec is used below the DIAMETER protocol, it also provides anti-replay services between adjacent DIAMETER entities. 2.8.2.2.4 COPS By replaying COPS messages previously exchanged between a PEP and a PDP, an attacker, having access to the TCP connection path between both entities and requiring some form of control by the PEP, can try and get privileges linked to the policy information previously exchanged. This malicious intermediary can indeed intercept requests from the PEP and replay "interesting" responses from the PDP. Replaying "old" COPS messages can also be used to delete or reenforce old policies from the PDP to the PEP. COPS contains an internal mechanism to prevent replays as discussed in 2.8.2.5.4. IPsec (see 2.8.3.3) or TLS (see 2.8.4) can also be used. 2.8.2.3 Data Integrity Check 2.8.2.3.1 Overview This type of security service covers information corruption. To detect such modifications (i.e. data corruptions) on PDUs, each PDU must contain some special field which contains an integrity check on the remaining (or well chosen) fields of the PDU. Data integrity is normally provided with some form of authentication. 2.8.2.3.2 RADIUS We can again identify two different contexts for discussing data integrity. In a context where no RADIUS proxy is involved, message contents can be modified by intermediate routers located between the client and the server. Both methods discussed in section 2.8.2.4.2 protect against such modifications in a non-proxy environment (although the first one is only valid when the User-Password attribute is present). In a context where intermediate RADIUS proxies are involved, message contents can be modified by these and by routers on the path. There is no mechanism embedded within RADIUS to protect the message integrity at proxy points because the mechanisms described in section 2.8.2.4.2 apply between two direct client and server. 2.8.2.3.3 DIAMETER Similar considerations as those described above for RADIUS apply in the context of DIAMETER. Section 2.8.2.4.3.1 discusses DIAMETER internal mechanisms which protect against such modifications in non- proxy environments. When IPsec is used below the DIAMETER protocol, Ekstein, et al. Expires October 2000 [Page 18] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 it also provides data integrity check between adjacent DIAMETER entities. Section 2.8.2.4.3.2 discusses DIAMETER internal mechanisms which protect against such modifications in proxy environments, hence providing end-to-end integrity protection. 2.8.2.3.4 COPS An intermediate malicious entity located on the TCP connection path can modify the contents of the COPS messages in order to disrupt the policy which will eventually be enforced by the PEP. Because there can be no third-party entity involved in COPS exchanges between the PEP and the PDP (to the contrary of RADIUS and DIAMETER), data integrity must "merely" be maintained between the PEP and the PDP over their TCP connection. There is no need to differentiate between hop-by-hop and end-to-end concepts. COPS contains an internal mechanism to provide data integrity as discussed in 2.8.2.5.4. IPsec (see 2.8.3.3) or TLS (see 2.8.4) can also be used. 2.8.2.4 Entity Authentication 2.8.2.4.1 Overview This service enables to counter attacks based on masquerading, man- in-the-middle, unauthorized access, information forgery and denial of service. This consists in ensuring the identities of the partners involved in establishing the communication. This step is normally achieved at the beginning of the dialogue and is therefore usually applicable to connection-oriented protocols. 2.8.2.4.2 RADIUS Entity authentication consists in identifying the client and the server. In the context where RADIUS proxies are in use, entity authentication applies between two adjacent RADIUS entities (an acting client and its server). Both mechanisms described below enable adjacent peer (hence hop-by-hop) authentication. No mechanism within RADIUS provides end-to-end entity authentication. 2.8.2.4.2.1 Native Authentication This is the authentication mechanism natively designed in RADIUS and which is therefore commonly deployed and used. Since this method depends on the presence of the User-Password attribute, it provides entity authentication and data integrity in some cases but not all. For Access-Request messages, client authentication is achieved through the mechanism used to encrypt the User-Password attribute as described in section 2.8.3.8 above. The use of the shared secret in encrypting the password indeed authenticates the client to the Ekstein, et al. Expires October 2000 [Page 19] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 server. The Access-Request message is clearly not sufficiently protected. There is no integrity protection on the entire message as the only protected item is the User-Password attribute. Authentication is only provided when the User-Password attribute is present, which is not necessarily always the case. When CHAP is being used for example, there is no integrity nor authentication provided at the RADIUS level. For other RADIUS messages (from server to client), server authentication is provided in the Authenticator field, which contains a MD5 hash value calculated over the whole RADIUS message (in which the Authenticator field is set to the value present in the corresponding Access-Request message for the purpose of MD5 processing) concatenated with the shared secret. 2.8.2.4.2.2 Signature Attribute The main purpose of this attribute is that it enables authentication of the Access-Request message, whether or not the User-Password attribute is present. It must also be used when remote user's authentication is making use of EAP (with a new attribute EAP-Message to carry EAP data within RADIUS). This attribute is used to carry a MAC calculated over the RADIUS message. It can be used in any message and is obtained by applying the HMAC-MD5 function over the RADIUS message and the secret shared between both adjacent entities. The actual calculation of the Authenticator field value in response messages (Access-Accept, Access-Reject, Access-Challenge) as discussed in 2.8.2.4.2.1 above takes place after the Signature attribute has been created. 2.8.2.4.3 DIAMETER Section 2.8.2.4.3.1 below describes a mechanism to provide entity authentication between adjacent DIAMETER entities. When entities are indirectly interconnected through proxies, end-to-end entity authentication can also be applied but this can be assimilated to data authentication. Section 2.8.2.4.3.2 below considers a mechanism to provide end-to-end entity authentication. 2.8.2.4.3.1 Hop-by-hop Authentication Hop-by-hop authentication is provided thanks to the use of 3 specific attributes which must be placed into the DIAMETER message. The Timestamp attribute is used to carry the time at which the message has been generated. The timestamp value must come from an NTP server. This attribute must appear before the Integrity-Check-Vector attribute in the sequence of attributes in the DIAMETER message. The Nonce attribute is used to carry a 16-bytes random value, different for each message. This attribute must appear before the Integrity- Check-Vector attribute in the sequence of attributes in the DIAMETER Ekstein, et al. Expires October 2000 [Page 20] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 message. The Integrity-Check-Vector attribute is used to carry the authentication value itself. This attribute also identifies the algorithm (HMAC-MD5) used to calculate the authentication value, which is based on a secret value shared between both DIAMETER entities. The timestamp value is used to provide anti-replay in the authentication value calculation. Time synchronization between both entities requires the use of NTP. In order to ensure that the message is actually relayed between intended parties, the Next-Hop attribute has been defined. It contains the IP address of the next DIAMETER entity to which this message is relayed and is protected by the digital signature. On reception, a DIAMETER entity checks that the last occurrence of the Next-Hop attribute matches its IP address. If they do not, there is a security break and the message is rejected. No mechanism is provided for the exchange of the shared secret value. Solutions based on SNMP (in secure mode) or IKE could be envisaged for securely distributing the shared secret. When retransmitting an authenticated message in which the Ns and Nr fields are being used (ie. the reliable DIAMETER transport mechanism is being used), the Nr field value may have changed. This requires a recalculation of the authentication value. To avoid this, the sender is allowed to leave the Nr field unchanged but this slows down the traffic in the incoming direction. 2.8.2.4.3.2 End-to-end Authentication End-to-end authentication, whether in proxy environments or because non-repudiation is required, makes use of a specific attribute, CMS- Data. This attribute "merely" contains a CMS (Cryptographic Message Syntax) object used to carry signature(s), certificate(s) and Certificate Revocation List(s). Support of this attribute therefore requires some S/MIMEv3 capability. Any intermediate DIAMETER entity (and in particular the final one) can verify the digital signature and the hop-by-hop authentication value if present (this latter being then removed before relaying). Such a proxy server can countersign the signed attribute(s) by adding its own signature within the CMS- Data attribute. A proxy server can also add new attributes (eg. the Proxy-State attribute) and append a new signature within a new CMS- Data attribute. Rules on how to proceed when two CMS-Data attributes are present are unclear. For example, it is not clear whether the last CMS-Data attribute covers all attributes with their P-bit set or only those between this and the previous CMS-Data attribute. Using end-to-end authentication does not preclude the use of hop-by-hop authentication. Hence, the mechanism described in 2.8.2.4.3.1 above can also be used and appended after the CMS-Data attribute to provide authentication between successive hops. Generation of public key- based digital signatures and generation/processing of CMS objects can be cumbersome for some network devices (eg. lightweight NAS devices). In such situations, the first next DIAMETER entity may generate the Ekstein, et al. Expires October 2000 [Page 21] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 signature on its behalf but this does not provide the same security model. Because some attributes may need to be modified or removed on the way by some intermediate proxy, not all attributes are protected by the digital signature (those being protected by the signature within the CMS-Data attribute have their P-bit set). There are therefore some doors left open to malicious modifications by intermediate entities for attributes values of which are not under strict control. 2.8.2.4.4 COPS It is important to ensure the identity of the PEP or PDP entity with which the COPS connection (ie TCP) is being established in order to avoid masquerading by malicious intermediate entities. The mechanism discussed in 2.8.2.5.4 enables both parties to authenticate. IPsec (see 2.8.3.3) or TLS (see 2.8.4) can also be used. 2.8.2.5 Data Authentication 2.8.2.5.1 Overview This service enables to counter attacks based on masquerading, man- in-the-middle, unauthorized access, information forgery and denial of service. This consists in authenticating each PDU individually, whether or not entities have previously been authenticated. A specific field carries data which authenticates the sender of the PDU. 2.8.2.5.2 RADIUS Data authentication consists in identifying the originator of data in RADIUS messages. It is indeed important to be able to ensure that attribute values within requests and responses have been created by the valid RADIUS entities. In non-proxy environments, this is equivalent to entity authentication and section 2.8.2.4.2 above describe two applicable mechanisms. In proxy environments, data authentication must apply end-to-end. RADIUS contains no provision for end-to-end data authentication in such proxy environments. 2.8.2.5.3 DIAMETER Data authentication consists in identifying the originator of data in DIAMETER messages. It is indeed important to be able to ensure that attribute values within requests and responses have been created by the valid DIAMETER entities. Section 2.8.2.4.3 above discusses two mechanisms to achieve data authentication in non-proxy and proxy environments respectively. Ekstein, et al. Expires October 2000 [Page 22] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 2.8.2.5.4 COPS Because COPS is connection-oriented, distinction must be made between entity and data authentication. Once the connection has been set up and entities authenticated, it is still important to ensure identity of the originator of each COPS message being exchanged. If the TCP connection is not protected, any intermediate entity could easily inject fake COPS messages with a particular intent to disrupt the service or gain some form of privilege. In addition to the mechanism described below, IPsec (see section 2.8.3.3) and TLS (see section 2.8.4) can also be used to provide data authentication. A specific object, Message Integrity, enables to authenticate each COPS message (thereby also providing antireplay, data integrity, entity/data authentication). This object is put at the tail of the COPS message and the authentication value is calculated over the whole COPS message. Each message contains a sequence number in order to provide antireplay. It is not clear that this mechanism really protects against replays over successive TCP connections. It seems possible for an attacker to replay old COPS messages (including their Message Integrity object) from one TCP connection to another. This would be based on the fact that the sequence numbers apply in the context of a single TCP connection. Because the authentication schemes are based on shared secrets, a mechanism is required for securely distributing the secret between the PEP and the PDP. Solutions based on IKE or SNMP (in secure mode) could be used for this. This solution does not provide a basis for non-repudiation since it does not use digital signatures. 2.8.2.6 Data Confidentiality 2.8.2.6.1 Overview This service covers aspects linked to eavesdropping and traffic flow analysis. This is achieved by encrypting the messages (or at least part of these) exchanged. 2.8.2.6.2 RADIUS Although confidentiality might not be considered so important when using RADIUS within a single well-controlled and protected environment, this is not necessarily the case when proxying is used for roaming. Messages can indeed cross untrusted networks. However, because intermediate RADIUS proxies must be able to examine and possibly modify the messages, confidentiality seems to be applicable only on a RADIUS hop-by-hop basis, leaving the possibility for an intermediate proxy to see information it should not necessarily see. Even more, in case of roaming, the home organization may want to hide username and other information about its users, so that the remote Ekstein, et al. Expires October 2000 [Page 23] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 organization cannot determine who is connecting. Unfortunately, such a requirement seems difficult to achieve with RADIUS. The first obstacle is the fact that the dial-up protocol itself (such as PPP) between the remote user and the NAS normally carries this information in the clear. Secondly, the intermediate RADIUS entities (and a fortiori the initial ones) must be able to determine to which other server to relay the message (which is at least based on the User-Name attribute value) and even to modify the contents of the message according to their local policy. Thirdly, there are even authentication schemes (such as CHAP) where the NAS generates a challenge for the remote user. The NAS is therefore somewhat involved in the remote user's authentication. End-to-end confidentiality between the remote user and the authenticating RADIUS server located in the user's home organization cannot therefore be provided in roaming environments. There is no encryption per se within RADIUS. The only pseudo-encryption mechanism present is used to hide the password value in the User-password attribute sent in Access-Request messages as described in section 2.8.2.4.2.1 above. This mechanism is not used when the remote user is being authentified using CHAP or EAP. With this pseudo-encryption algorithm, the user password is basically hidden by applying a MD5 hashing function with a secret value shared between the RADIUS client and the server. This encryption mechanism only applies between adjacent client and server. The mechanism used to set up the shared secret between the client and the server is left unspecified. A management protocol such as SNMP (in secure mode) could be used to configure the RADIUS entities with the correct shared secret. IPsec can also be used to encrypt the whole RADIUS messages between two adjacent RADIUS entities (see section 2.8.3.1). 2.8.2.6.3 DIAMETER Similar considerations apply when using DIAMETER as those described above for RADIUS. Both mechanisms discussed below provide (partial) encryption in a hop-by-hop and end-to-end scheme respectively. Full hop-by-hop encryption can be obtained by using IPsec between adjacent DIAMETER entities (see section 2.8.3.2). 2.8.2.6.3.1 Hop-by-hop Encryption With this method, DIAMETER provides encryption of individual attributes. To achieve this, a specific attribute Encrypted-Payload is used to carry encrypted attributes. The concatenated sequence of attributes is input into the encryption function and the result makes the data of the Encrypted-Payload attribute. A Nonce attribute must be present in the DIAMETER message so that its nonce value is input into the encryption process and hence avoids replays. DIAMETER specifies which attributes are allowed to be encrypted and those Ekstein, et al. Expires October 2000 [Page 24] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 which are not. The DIAMETER message is therefore not entirely encrypted but only some attributes. Moreover, the use of confidentiality on some attributes is not negotiated but is left to the decision of the DIAMETER entity. There is no negotiation of an encryption algorithm. A simple MD5-based hiding mechanism is always used, which makes use of the shared secret and the nonce value as keys for "encryption". The same shared secret is used for encryption and hop-by-hop authentication between both adjacent DIAMETER entities. 2.8.2.6.3.2 End-to-end Encryption End-to-end encryption makes use of the same CMS-Data attribute as described in section 2.8.2.4.3.2 above. In this case, the CMS object contains encrypted data which results from encrypting one or more attributes. The originating DIAMETER entity must know which final entity will process the message since it must use its public key. The final server's certificate must therefore be obtained a priori (either within some previously received CMS-Data attribute from that final server or from a broker). A broker server can also be used to discover the final server identity so as to directly connect to it (the certificate being obtained from the broker). Handling of CMS and S/MIMEv3 can be too cumbersome for lighweight network devices. In such situations, the device can use hop-by-hop encryption with its first next DIAMETER entity, which in turn will reencrypt the attribute value on its behalf but this does not provide the same security model. 2.8.2.6.4 COPS Depending on the type of policy information being exchanged within COPS, confidentiality may be required. This can also be necessry when the PEP and PDP are linked over an untrusted network which is not under the control of the same administration. In this case, there may be a legitimate requirement to merely avoid divulgating the details of the policy being enforced on the remote PEP's. COPS contains no internal provision for data confidentiality and solely relies on external mechanisms for this. IPsec (see 2.8.3.3) or TLS (see 2.8.4) can also be used. 2.8.3 IPsec 2.8.3.1 RADIUS IPsec AH can certainly be used to protect the communication between the RADIUS client and its associated server against denial of service, replay and (RADIUS entity) masquerading attacks. Moreover, this could be combined with IPsec ESP to encrypt the whole dialogue. Ekstein, et al. Expires October 2000 [Page 25] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 Unfortunately, this does not solve the problem with RADIUS proxies. When relaying a RADIUS message, a RADIUS proxy acts both as a server and a client for two sequential RADIUS "links". Protecting the RADIUS messages with IPsec does not therefore prevent a malicious intermediate RADIUS entity from corrupting relayed messages, since the initial IPsec protection ends at the intermediate entity itself. There is also a problem with intermediate RADIUS entities which may add new attributes to the message (e.g. Proxy-State) or remove others and which must therefore be able to access and modify the contents of the message. Setting up end-to-end IPsec ESP protection would require that the initial RADIUS client sets up an ISAKMP transaction with the final RADIUS server, meaning that both are aware of the proxying agreement (and hence bypass the proxy entities). In many cases, the RADIUS client will not be aware that the remote user's authentication is actually achieved by some indirect RADIUS server. 2.8.3.2 DIAMETER Similar considerations as those described above for RADIUS apply when using DIAMETER over IPsec. 2.8.3.3 COPS IPsec AH in transport mode can be used to fulfill all above requirements except confidentiality. IPsec ESP in transport mode will additionally provide confidentiality. The PEP and the PDP entities can use IKE in order to set up the IPsec agreement and then use IPsec (AH or ESP). Because COPS is not used in proxy environments, IPsec would be sufficient to provide end-to-end security. 2.8.4 TLS 2.8.4.1 COPS As an alternative to IPsec, TLS can be used over TCP to provide data/entity authentication, data integrity, anti-replay, data confidentiality and denial of service countermeasures. Because COPS is not used in proxy environments, TLS would be sufficient to provide end-to-end security. An additional requirement that is not met when using IPsec or TLS could be that a given COPS operation is digitally signed by its originator. IPsec and TLS authentication mechanisms indeed do not provide non-repudiation on authenticated "objects". A PEP or a PDP might require that the message received be digitally signed by its peer in order to avoid later denial of having ever sent this message. In order to provide such a type of service, the message or interesting part thereof must be digitally signed. This could be provided by defining new specific objects in COPS. Ekstein, et al. Expires October 2000 [Page 26] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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 [16], 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 [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 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. Ekstein, et al. Expires October 2000 [Page 27] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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 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 Ekstein, et al. Expires October 2000 [Page 28] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 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-05.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-05.txt, Work in Progress, October 1999 [8] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft- calhoun-diameter-12.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-10.txt) [10] P. Calhoun, N. green, "DIAMETER Resource Management Extensions", draft-calhoun-diameter-res-mgmt-03.txt, Internet Draft, February 1999 [11] Calhoun P. et al., "DIAMETER Strong Security Extension", Internet-Draft, draft-calhoun-diameter-strong-crypto-01.txt, December 1999. [12] Calhoun P. et al., "DIAMETER NASREQ Extensions", Internet-Draft, draft-calhoun-diameter-nasreq-01.txt, December 1999. [13] P. R. Calhoun, "DIAMETER Mobile-IP Extension", draft-calhoun- diameter-mobileip-05.txt, October 1999. [14] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy- Based Admission Control", draft-ietf-rap-framework-03.txt, April 1999. [15] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "The COPS (Common Open Policy Service) Protocol", draft-ietf-rap- cops-08.txt, Work in progress, November 1999 Ekstein, et al. Expires October 2000 [Page 29] Internet Draft draft-ekstein-aaa-protcomp-00.txt April 2000 [16] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, A. Sastry, "COPS usage for RSVP", draft-ietf-rap-cops-rsvp-05.txt, Work in Progress, June 1999 [17] Rigney et al., "Remote Authentication Dial In User Service (RADIUS)", Internet-Draft, draft-ietf-radius-radius-v2-02.txt, December 1999. [18] Rigney at al., "RADIUS Extensions", Internet-Draft, draft-ietf- radius-ext-05.txt, December 1999. 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 Olivier Paridaens Universite Libre de Bruxelles Service Telematique et Communication Bd du Triomphe, CP 230 B-1050 Brussels, Belgium Tel. +32 2 6505703 Fax. +32 2 6505088, +32 2 6293816 X.400 : S=paridaens;O=helios;P=iihe;A=rtt;C=be RFC-822 : paridaens@helios.iihe.ac.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 October 2000 [Page 30]