Submitted to AAA Working Group Yves T'Joens
INTERNET DRAFT Ronnie Ekstein
Category : Standards Track Marc De Vries
Alcatel
Olivier Paridaens
<draft-tjoens-aaa-radius-00.txt> ULB
June 2000
Expires December, 2000
Framework for the extension of the RADIUS(v2) protocol
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
This document is a submission to the AAA Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the aaa-wg@merit.edu mailing list.
Distribution of this memo is unlimited.
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "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.
Abstract
This document describes a framework that allows for the extension of
the RADIUS (v2) [1] protocol according to the following major design
goals :
o backward compatibility with the installed base of (proxy) RADIUS
implementations
Tjoens, et al. Expires December, 2000 [Page 1]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
o offering a transition path to improved procedures and a structural
follow up of the RADIUS protocol
o meeting the requirements imposed by [2] and allow for a flexible
upgrading to future extensions necessary in any AAA related
application
Table Of Contents
1.0 Introduction
1.1 Requirements Language
1.2 About backward compatibility
1.3 Terminology
2.0 How to upgrade from RADIUSv2 to RADIUS++
2.1 Detecting if extensions are understood by the peer
2.2 Communication over a legacy RADIUS implementation, acting as proxy
2.3 From Client-Server to Peer-Peer
3.0 Extending RADIUS message and attribute space
3.1 Extending the message space
3.2 Extending the attribute definition
3.2.1 8+8 bit type, 8 bit length attribute
3.2.2 8+8 bit type, 12 bit length attribute
3.2.3 16 bit type, 16 bit length, tagged
3.2.4 Inverse TLV multiplexing
4.0 Protocol procedures
4.1 Reliable transmission
4.2 Session management
4.3 Security
4.3.1 Hop-by-Hop security
4.3.1.1 RADIUS Native authentication
4.3.1.2 Message Authenticator
4.3.1.3 Use of IPsec
4.3.2 End-to-End Security
4.3.2.1 Data Integrity/Authentication
4.3.2.2 Data Confidentiality
4.3.2.3 Usage of Certificates
4.3.3 AAA NAS Requirements
4.3.3.1 Mutual Authentication AAA Client/Server
4.3.3.2 Transmission Level Security
4.3.3.3 Data Object Confidentiality
4.3.3.4 Data Object Integrity/Authentication
4.3.3.5 Certificate Transport
4.3.3.6 Shared Secret Not Required
4.4 Server failover
Tjoens, et al. Expires December, 2000 [Page 2]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
5.0 IANA considerations
6.0 Security Considerations
7.0 Acknowledgements
8.0 Authors' Addresses
9.0 References
1.0 Introduction
This document describes a framework that allows for the extension of
the RADIUS (v2) [1] protocol according to the following major design
goals
o backward compatibility with the installed base of (proxy) RADIUS
implementations
o offering a transition path to improved procedures and a structural
follow up of the RADIUS protocol
o meeting the requirements imposed by [2] and allow for a flexible
upgrading to future extensions necessary in any AAA related
application
While the first two points are handled within this framework, the
latter isn't yet, since
a) it requires a wide concensus on the need to provide for the
backward compatibility as described within this document
b) it requires choosing amongst the different methodologies that
exist to update the RADIUS protocol
c) it requires more than a few days time to define and discuss the
detailed procedures and the definition of TLV syntax and semantics.
1.1 Requirement Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [x]. These key
words mean the same thing whether capitalized or not.
An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and
Tjoens, et al. Expires December, 2000 [Page 3]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
should not requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements
for its protocols is said to be "conditionally compliant."
1.2 About backward compatibility
Backward compatibility means :
- "easy" upgrade of software on these devices that need to be
extended with specific functionality
- detection if extensions are understood by the peer, and controlled
interworking with non capable implementations
- method to work through a (concatenation of) legacy RADIUS proxy
implementations
For clarity, we have denoted any change from existing RADIUS(v2)
implementations as RADIUS++ implementations, this name of course is
purely for description purposes.
1.3 Terminology
Within this draft, peer to peer communication, rather than a client
server paradigm is adopted for communication between two parties
adopting the RADIUS++ protocol. In such a sense, there is always a
party that originates the session, potentially one or more proxies
(e.g., a local AAA server and broker), and a terminating RADIUS++
implementation (e.g., the home AAA server). Within the context of
this draft, the originating RADIUS++ implementation is denoted as
RADIUS client.
2.0 How to upgrade from RADIUSv2 to RADIUS++
2.1 Detecting if extensions are understood by the peer
Any communication between two RADIUS implementations is by definition
adopted in this description as originated by the RADIUS client. The
Client can be made aware of the capabilities of the remote peer by
either
o explicit configuration
The support of the extensions on a peer by peer basis can be
configured prior to communication. While this may be handy to
Tjoens, et al. Expires December, 2000 [Page 4]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
configure the local and known peers, it is expected that in a
network where servers get redirected to each other on an frequent
basis, an automated procedure is worthwhile investigating.
o capability negotiation with the remote peer
In order to check for the capabilities of the peer, two possible
procedures can be defined
procedure A : Include a new TLV in the known message, expecting
some specific TLV back
Example : The first Access_Request message send by the RADIUS
client to the RADIUS server could include an extended_radius TLV.
The RADIUS server should, if supported, return the extended_radius
TLV in the next message back to the sender. Upon successful
detection of extended radius support, the RADIUS client can safely
assume support of any extended procedure. The procedure can be
used for both hop-by-hop support of procedures and end to end on
the basis of e.g. two different TLVs.
procedure B : define a new message exchange for the initialization
of the communication
Example : An Open-Request message is send by the RADIUS client to
the RADIUS server to test the support of the RADIUS++ extensions.
Any supporting RADIUS++ implementation MUST acknowledge the
receipt of an Open-Request message with an Open-Accept message.
This procedure allows mainly for hop by hop detection of
capabilities.
Procedure B has the benefit, that the message sequence can be used
to configure some retransmission, congestion control,
failover/failback and server load balancing parameter information.
It can also be used as an escape sequence to an extended RADIUS++
protocol specification, making use of e.g. a 16 bit TLV space (see
further), or even DIAMETER communication (sic).
2.2 Communication over a legacy RADIUS implementation, acting as proxy
A RADIUS client that discovers that its communicating peer does not
support the extensions as defined within this draft can
a) fall back to RADIUS v2 support, however with a limited
functionality
b) use an inverse TLV multiplexing scheme as defined further
c) refrain from communication and report this to local management
Tjoens, et al. Expires December, 2000 [Page 5]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
Many proxy implementations today are provisioned to allow a scalable
communication between a large set of distributed NASses and a central
AAA server. In this situation, many of the AAA functionality itself
involves only originating and terminating RADIUS implementation,
while the proxy implementation typically concentrates and routes AAA
requests and responses. In order to allow for backward compatibility
of the AAA solution with this widely deployed base of proxy
implementations, one could build upon the pass through capability of
many existing proxy implementations. That is to say, configure the
proxy implementation as such that a selected set of TLVs are passed
unchanged over the legacy RADIUS(v2) proxy, the latter can be used
for the extensions described in section 3.0.
2.3 From Client-Server to Peer-Peer
Many new extensions today require unsolicited messages to be sent by
the server to the client. With the procedures described above, a
RADIUS client can find out from its peer if it supports a set of
extensions, this can obviously include peer to peer communication as
replacement for the client server paradigm.
Communication over a legacy proxy implementation on the other hand
will by definition always be limited to client server interaction,
due to the fact that presently no unsolicited message handling is
covered within RADIUS(v2). This however is also a certainty for any
protocol working through a RADIUS/X gateway.
3.0 Extending RADIUS message and attribute space
RADIUS as defined today, provides only for a limited extensibility in
terms of messages (255 PCC codes) and attributes (255 Type codes),
furthermore, the length of each attribute in [1] is limited to a 253
byte payload. This encoding of the TLV is further in the text
referred to as 8 bit TLV. There are multiple ways of going beyond a
simple 8 bit TLV within RADIUS.
3.1 Extending the message space
Extending the message space is as easy as defining a new TLV that
carries the message type, e.g., as the command code AVP in DIAMETER.
3.2 Extending the attribute definition
Multiple ways exist to extend the attribute definition.
Tjoens, et al. Expires December, 2000 [Page 6]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
The most obvious method is to just go on and consume the remaining
TLV space and PCC space within RADIUS. This however will likely be
far from future proof, so not considered within this draft.
3.2.1 8+8 bit type, 8 bit length attribute
Any (not yet assigned) TLV can further host sub TLVs, thereby
extending the TLV space. Minor point there is that the maximum lenght
of any individual attribute is decreased to 251. One such TLV could
host multiple sub TLVs (such as the vendor specific TLV today).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Type" | Length" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-
3.2.2 8+8 bit type, 12 bit length attribute
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Type" | tag | seqno |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-
Any (not yet assigned) TLV can further be decomposed as above. Here,
the Type + Type" gives the type code of the attribute, thereby
creating a type space of (unassigned TLV values)*256 type codes.
The Length field gives the length of the TLV, while the seqno allows
for logically concatenating a number of TLVs, providing a virtual
payload of 251*16 bytes.
The Tag indicates a value of an instance of the overall attribute,
thereby allowing for 16 instances of the same (Type,Type") attribute.
3.2.3 16 bit type, 16 bit length attribute, tagged
Tjoens, et al. Expires December, 2000 [Page 7]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |U|F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
N bit : Nested TLV bit, indicates that the payload of the TLV itself
should be considered a set of TLVs.
Type : 15 bit, allows for 32k attributes types of simple nature and
32k structures of (sub)TLVs.
Flag field
U : unknown bit, if set, the implementation should return an error
message.
F : forward bit, if set, an unknown TLV should be forwarded
unmodified, if not set, the TLV can safely be discarded.
This provides a nicely 32 bit aligned TLV definition. The exact
coding of this TLV remains largely for further study.
3.2.4 Inverse TLV multiplexing
Note that the change from 8 bit TLV to 16 or higher bit TLV can
safely be assumed when the communicating peers have gone through a
capability exchange, as described in section 2.1.
However, when such capability negotiation fails, or when it is
configured that communication takes place over a legacy proxy
implementation, one can still try to "tunnel" the non-8 bit TLV
scheme through the legacy proxy implementation making use of the
following inverse TLV multiplexing scheme.
For that purpose, this document defines the multiplexing TLV, that
allows to create a virtual container within the RADIUS message.
Tjoens, et al. Expires December, 2000 [Page 8]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | counter | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
type tbd.
Length
variable
Counter
8 bit numeric counter field. This field allows for reassembling out
of order TLVs as received by a TLV multiplexing supporting
application within the proxy chain. The counter field allows for the
sending of 255 consecutive TLVs of 252 bytes. Thereby a container is
created of 64200 bytes. This container is filled with the extended
TLVs as defined in section 3.2.3. [Note that if assumed that proxy
RADIUS implementations do not change any sequence of TLVs, one can
safely omit the counter field]
By extending the basic 8-bit TLV (type tbd) with a counter value, a
virtual container (64200 bytes) is constructed that allows for
transport of extended TLVs through a set of 8-bit TLV proxy servers.
In order to test the receipt of the container by the terminating
RADIUS++ implementation, the originating application should include
in the extended TLVs within the message also the e2e-session-ID TLV
(in the new TLV space) (e2e : end-to-end). The destination
implementation should return the e2e-session-ID TLV within the return
message. The latter allows the originator to safely identify the
support of the extended TLVs by the end application.
If the e2e-session-ID TLV is not to be found in the return message,
the implementation can safely assume the end to end communication to
be broken, and can
a) fall back to RADIUS v2 support, however with a limited
functionality
b) refrain from communication and report this to local management.
Support of the non 8 bit TLV scheme is established on a hop by hop
basis, as described above. Any proxy in the chain that finds out the
next hop to be non 8-bit aware SHOULD convert to non 8 bit TLV
Tjoens, et al. Expires December, 2000 [Page 9]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
operation. [this makes certain that after a transition period, all
implementations are upgraded to non 8 bit]
4.0 Protocol procedures
This section is given for information purposes. Given the extremely
short timeframe for specification, and the open nature of a number of
protocol design decisions, this section would require further work in
the context of further development in the AAA workgroup.
4.1 Reliable transmission
The RADIUS++ extension can potentially make use of the reliable
communication scheme developped in the context of the L2TP [3]
(control) protocol specification. That is to say, the negotiation of
a transmission window, and the use of Nr and Ns fields (in an extra
TLV).
4.2 Session management
Any transaction between RADIUS++ nodes carries an end-to-end session
id. Although strictly not necessary, an end-to-end session id that
would be globally and timely unique could help accounting and
debugging purposes.
4.3 Security
This section aims at proposing security mechanisms to make RADIUS
compliant with the AAA NAS requirements set forth in [2]. We first
specify how to secure RADIUS traffic in a hop-by-hop context and over
a chain of proxies, using existing or new mechanisms. We then
explain how these mechanisms cover the AAA security requirements.
4.3.1 Hop-by-Hop Security
Hop-by-hop security takes place between adjacent RADIUS nodes
(typically a client and its server). Security services to be
considered within such a situation include anti-replay, data
integrity, entity authentication (both sides) and data
confidentiality. Following the discussions of the respective merits
of the various solutions described below, we suggest that the
mechanism to be used for providing hop-by-hop security be the use of
IPsec. Every RADIUS message should be protected using IPsec with AH
or ESP depending on the exact security requirements. Such a solution
also has the advantage of not requiring any change to the RADIUS
protocol since security services are provided by the underlying
network layer (obviously IPsec code and perhaps also IKE must be
added to the RADIUS platform).
Tjoens, et al. Expires December, 2000 [Page 10]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
4.3.1.1 RADIUS Native Authentication
This is the authentication mechanism natively designed within RADIUS.
It makes use of the MD5 hashing function and requires a shared secret
between both RADIUS entities. It only provides entity authentication
and data integrity in some cases but not all. For Access-Request
messages, it only provides client authentication when the User-
Password attribute is present (the User-Password attribute is also
encrypted). No data integrity/authentication nor confidentiality is
provided on other attributes or message header fields. Anti-replay
is not provided either. For other RADIUS messages (from server to
client), server entity authentication is provided together with data
integrity. Confidentiality and anti-replay are not provided.
4.3.1.2 Message Authenticator
This attribute (defined in [4]) provides entity (client and server)
authentication and data integrity/authentication over a whole RADIUS
message, whether or not the User-Password attribute is present in the
Access-Request. 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 4.3.1.1 above takes place after the Signature attribute
has been created.
4.3.1.3 Use of IPsec
IPsec can be used between adjacent RADIUS entities to provide anti-
replay, entity authentication, data integrity/authentication and data
confidentiality. The shared secret material needed can be pre-
configured manually or even be set up with a live protocol such as
IKE.
4.3.2 End-to-End Security
To provide end-to-end security services, a new attribute is defined,
CMS-Data, which carries a CMS (Cryptographic Message Syntax) object
as described in RFC 2630. This attribute basically enables to
provide end-to-end entity authentication, data
integrity/authentication, data confidentiality and anti-replay
services. It also provides transport of certificates. Intermediate
RADIUS proxies can also countersign RADIUS messages being relayed.
We describe below the use of the CMS-Data attribute when providing
Tjoens, et al. Expires December, 2000 [Page 11]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
basic end-to-end security services.
4.3.2.1 Data Integrity/Authentication
When a RADIUS entity wants to provide end-to-end integrity on RADIUS
attributes present in the message, it makes use of the CMS-Data
RADIUS attribute which is appended to the list of RADIUS attributes.
The CMS ASN.1 object is of type signed-data and therefore provides
both integrity and authentication since the message actually carries
a signature (together with anti-replay of the signature). The
process of building the signed-data CMS ASN.1 object is basically as
described in RFC 2630 with the following precisions. The initial
input is the concatenation of the code field, identifier field and
the list of RADIUS attributes (in their TLV format) over which the
signature must be generated. The eContent field is omitted so that
an external signature is actually generated. This means that the
CMS-Data RADIUS attribute does not contain itself the RADIUS
attributes being signed. Anti-replay is provided through the use of
the CMS signing-time signed attribute. This however request time
synchronization or that the receiving RADIUS entity keeps track of
the last timestamp used by the signing RADIUS entity. Because some
RADIUS attributes may be left out of the signature process (those
which are subject to modifications or removal by intermediate
proxies), it is necessary to keep information on which RADIUS
attributes have been taken into account in the signature. To achieve
this, a new CMS signed attribute is defined, radius-attributes-
coverage.
Its ASN.1 definition is as follows :
RADIUS-attributes-coverage ::= SEQUENCE OF INTEGER
Each element of the ordered list identifies a RADIUS attribute
present in the RADIUS message and which is covered in the signature
process. The identification is made with the RADIUS attribute type
value. The order respects the order of the RADIUS attributes in the
RADIUS message. If a signed RADIUS attribute is removed from the
RADIUS message, this will be detected because the sequence in the
radius-attributes-coverage will not correspond any more to the list
of RADIUS attributes in the received message. If a signed RADIUS
attribute is modified, this will obviously be detected at signature
verification process. Replacing a signed RADIUS attribute by another
one (even of the same type) is equivalent to a modification and is
therefore detected on reception. If hop-by-hop
integrity/authentication must also be provided using the native
RADIUS method, this is achieved after the CMS-Data RADIUS attribute
has been appended. If the Signature RADIUS attribute is used, it is
appended after the CMS-Data RADIUS attribute.
4.3.2.2 Data Confidentiality
Tjoens, et al. Expires December, 2000 [Page 12]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
Provision of RADIUS attributes confidentiality is achieved with the
use of the CMS-Data RADIUS attribute containing a CMS object of type
envelopped-data. The process of building the envelopped-data CMS
ASN.1 object is basically as described in RFC 2630 with the following
precisions. Since RADIUS communication is point-to-point, there is a
single RecipientInfo field instance, enabling the final RADIUS
destination to recover the content encryption key. The input to the
encryption process is made of the concatenation of the RADIUS
attributes which the entity wishes to conceal from proxies and other
intermediaries. These attributes obviously do not appear at the
RADIUS message level. The contentType field in the
encryptedContentInfo is set to id-data. If hop-by-hop
integrity/authentication must be provided using the native RADIUS
method, this is achieved after the CMS-Data RADIUS attribte has been
appended. If the Signature RADIUS attribute is used, it is appended
after the CMS-Data RADIUS attribute. If data
integrity/authentication and/or anti-replay must be provided in
addition to data confidentiality, another CMS-Data RADIUS attribute
of type signed-data can be appended to cover the envelopped-data
CMS-Data RADIUS attribute.
4.3.2.3 Usage of Certificates
When a RADIUS entity makes use of another entity's certificate (to
verify a signature or to encrypt a content encryption key), it is
important to ensure that the certificate is actually associated with
that other entity. RFC 2459 contains provision for such procedures.
In particular, the Subject of the certificate must contain
information which clearly identifies the owner of the public-private
key pair, which is the RADIUS entity. The Subject Alternative Name
of the certificate must hence contain the FQDN and/or IP address of
the RADIUS entity. When a RADIUS message is received and a signature
must be verified, it is however impossible to associate the
certificate with the signing RADIUS entity since this latter's IP
address is not carried over the chain of proxies. Trust must
therefore be placed in the fact that the certificate itself is valid
(following certificate path validation procedures) and that the list
of RADIUS partners is usually known. When a RADIUS message must be
sent with a CMS-data RADIUS attribute of type envelopped-data. The
RADIUS entity must retrieve the certificate corresponding to the
final RADIUS entity destination. Since the RADIUS entity must
already contain a list of all the RADIUS entities with which it
interacts (in terms of end-to-end interactions). Their certificates
can be retrieved from that same database or via any other means such
as LDAP. The RADIUS entity's FQDN or IP address can be used to find
and retrieve the right certificate. When a RADIUS message containing
a CMS-data RADIUS attribute of type envelopped-data is received, the
receiving entity can identify the certificate to use in the rid field
Tjoens, et al. Expires December, 2000 [Page 13]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
of the CMS object.
4.3.3 AAA NAS Requirements
4.3.3.1 Mutual Authentication AAA client/server
For hop-by-hop communications, the use of IPsec provides mutual
authentication of the traffic between both RADIUS entities. In a
proxy situation, the client can authenticate to the final (and
intermediary) server by using the CMS-Data RADIUS attribute with a
signed-data CMS object. Reversely, the server can authenticate its
response similarly.
4.3.3.2 Transmission Level Security
The use of IPsec provides all the necessary security services for
hop-by-hop communications.
4.3.3.3 Data Object Confidentiality
The CMS-Data RADIUS attribute enables to encrypt one or more RADIUS
attributes within the enveloped-data CMS object. Only the final
RADIUS destination is able to decrypt and recover the information.
4.3.3.4 Data Object Integrity/Authentication
The CMS-Data RADIUS attribute enables to protect the integrity of
RADIUS attributes present in the message with the use of the signed-
data CMS object in "external signature" mode. The mechanism defined
enables to specify which RADIUS attributes are covered by the
signature. The use of public key cryptography for the signature
enables any proxy to verify the signature on the way. An
intermediate proxy can also add its own signature, either by
countersigning within an existing CMS-Data RADIUS attribute or by
appending a new CMS-Data RADIUS attribute to the message covering
some or all of the previous RADIUS attributes. Countersigning is
achieved by adding a new SignerInfo field to the list of signers
within the last CMS-Data RADIUS attribute. It is possible for the
proxy to sign different attributes than those which were signed
originally since the SignerInfo field contains its own list of signed
attributes.
4.3.3.5 Certificate Transport
Certificates can be transported from one end to another within a
CMS-Data RADIUS attribute. The signed-data and envelopped-data CMS
objects can indeed carry certificates and CRL's.
Tjoens, et al. Expires December, 2000 [Page 14]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
4.3.3.6 Shared Secret Not Required
Usage of the CMS-Data RADIUS attribute requires no pre-shared secret
for end-to-end security services. Usage of IPsec to protect hop-by-
hop communications does not necessarily require pre-shared secrets
either although this is the most common (and easy) way to set up
IPsec channels.
4.4 Server failover
The Open-Accept message may indicate a number of other servers that
can take over from this server if declared dead. The server can be
declared dead, after a number Nf of unsuccessful transmissions. The
client should then establish the connection with the next IP address
in the Server alternatives TLV.
5.0 IANA considerations
Dependent on the adopted extension scheme.
6.0 Security considerations
See section 4.3.
7.0 Acknowledgements
The suggestion to make use of CMS for end-to-end security (section
4.3) was taken from the draft on DIAMETER Strong Security Extension.
In general, many of the suggestions made within the context of the
definition of the DIAMETER protocol would easily fit within the
context of an extended RADIUS definition.
8.0 Authors' Addresses
Yves T'Joens
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 240 7890
E-mail : yves.tjoens@alcatel.be
Ronnie Ekstein
Alcatel Network Strategy Group
Francis Wellesplein 1, 2018 Antwerp, Belgium
Phone : +32 3 241 5958
E-mail : ronnie.ekstein@alcatel.be
Tjoens, et al. Expires December, 2000 [Page 15]
INTERNET DRAFT draft-tjoens-aaa-radius++-00.txt June 2000
Marc De Vries
Alcatel Carrier Internetworking Division
De Villermontstraat 38, 2550 Kontich, Belgium
E-mail : marc.de_vries@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
9.0 References
[1] C Rigney, A Rubens, W A Simpson, S Willens, "Remote Authentica-
tion Dial In User Service (RADIUS)", draft-ietf-radius-radius-v2-
06.txt, Work in progress
[2]"Criteria for Evaluating AAA Protocols for Network Access",
draft-ietf-aaa-na-reqts-05.txt, work in progress
[3] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter,
"Layer Two Tunneling Protocol (L2TP)", RFC2661, August 1999
[4] C Rigney, W Willats, P Calhoun, "RADIUS Extensions", draft-ietf-
radius-ext-07.txt, Work in progress
Tjoens, et al. Expires December, 2000 [Page 16]