Submitted to NASREQ Working Group Ronnie Ekstein
INTERNET DRAFT Yves T'Joens
Bernard Sales
Alcatel
Olivier Paridaens
<draft-ekstein-nasreq-protcomp-01.txt> ULB
January 2000
Expires June, 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 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 June 2000 [Page 1]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 2]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 3]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 4]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 5]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 6]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 7]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 8]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 9]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 10]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 11]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 12]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 13]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 14]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 15]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 16]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 17]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 18]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 19]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 20]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 21]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 22]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 23]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 24]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 25]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 26]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 27]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 28]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 29]
Internet Draft draft-ekstein-nasreq-protcomp-01.txt January 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 June 2000 [Page 30]