Submitted to AAA Working Group Yves T'Joens INTERNET DRAFT Ronnie Ekstein Category : Standards Track Marc De Vries Alcatel Olivier Paridaens 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]