Mobility support in RADIUS and Diameter

Transcription

1 Mobility support in RADIUS and Diameter Päivi Savola Helsinki University of Technology May 28, 2003 Abstract This paper focuses on describing some of the possible implementations of authentication, authorization and accounting (AAA) using RADIUS and Diameter protocols in the context of user mobility and roaming. The focus is on established TCP/IP-based networks and the protocol support for mobility in RADIUS and Diameter. The extensibility of both protocols allows for several different approaches, and enables transferring a wide variety of information. This allows communicating different kinds of network access data, including configuring voluntary or mandatory tunnels to the home network, Mobile IP and IPv6 network access. Request forwarding by proxies and proxy chaining mechanisms in both protocols are examined. The establishment of request forwarding relationships is not covered by the RADIUS protocol, and some proposed solutions are presented. In addition to more sophisticated request forwarding procedures, Diameter also has mechanisms for discovering new Diameter servers. 1 Introduction Just a decade ago most users had a static connection to Internet using a certain computer and Internet Service Provider (ISP). The number of mobile users has grown in the last decade. These users have a need to access resources in their home networks and the Internet from multiple different locations possibly outside their home domain using the same piece of connection equipment. This user mobility from one network to another without separate service agreements with each temporary domain s ISP is called roaming. [23] This paper focuses on the possible implementations of authentication, authorization and accounting (AAA) and user roaming and mobility in established TCP/IP-based networks. The basic concepts of authentication, authorization and accounting are explained in in D. Comer s book "Internetworking with TCP/IP" [1]. The examined protocols are Remote Authentication Dial-In User Service (later RADIUS) which was originally described by C. Rigney, S. Willens, A. Rubens and W. Simpson in Request For Comments (RFC) 2058 [5]. The protocol has later been updated in other RFCs [6, 17]. The other protocol described is Diameter, which was chosen as a successor for RADIUS. The Diameter protocol specification is still a work in progress. The current status of the Diameter project can be seen in the Internet pages of the Internet Engineering Task Force s (IETF) AAA Working Group [28]. 1

2 For the purposes of this paper it is assumed that the user has a means of connecting to the local network and communicating with the local hosts. If the local network is not the user s home network, it is called foreign network. The mediation of AAA information requires trust between the participating parties. Because of space constraints the problem of trust, certificate and key management between the foreign and home domains has been left out of this paper, and the possible architectures are touched only briefly when the description of the protocol functionality requires it. 2 Base protocol support for mobility In this chapter the basic characteristics of the RADIUS and Diameter protocols are briefly described. The basic protocol definitions of RADIUS, and especially Diameter provide some mechanisms that can be utilized for mobility. The most notable of these is request forwarding. 2.1 RADIUS protocol The RADIUS [17] protocol as originally specified was intended to serve the purposes of dial-in access to networks. In dial-in network access the user calls a Network Access Server (NAS) with a modem thorough PSTN phone lines. As the number of users grew, configuring each user to the correspondingly growing number of NASes made necessary a centralized user authentication, authorization and accounting management. In the basic RADIUS protocol model the user connects to the NAS, who forwards the user identification data to a centralized RADIUS server. The server maintains a database of users and the details of the services to be delivered to each user. The RADIUS server will then send the NAS a reply telling it to either accept or reject the user s connection request, and configuration information about the kind of service to be delivered to the user. Alternately, if extra security is desired, the RADIUS server may send a numeric challenge thorough NAS to the user, and only grant network access upon a satisfactory answer to the challenge. In addition to these authentication and authorization requests NAS may also originate accounting requests, to which it will receive replies. Because of this client-server protocol arrangement, NAS is often referred to as the client or RADIUS client. Fig. 1 illustrates this consept. RADIUS protocol packets are carried inside UDP datagram payload. The RADIUS protocol uses UDP for several reasons of which the most important is the possibility to control packet resending mechanism at the application level. [17] This permits server-specific timeouts, and using backup or different servers whenever necessary. The communication between RADIUS client and server is protected by a shared secret, which is used to authenticate the messages sent by each party. User passwords are encrypted with the RSA Message Digest Algorithm MD5. [3] A RADIUS message has a header containing information about the message type, length, authentication information and an identifier, which allows requests ant their replies to be related together. The rest of the message consists of attribute 3-tuples of attribute code 2

3 Figure 1: NAS acting as a client for RADIUS server identifying the attribute name, a length field and attribute value. The attributes can be categorized into four groups: RADIUS protocol mangement attributes, user identification and authentication attributes, authorization attributes which detail the type of service to be delivered to the user and accounting attributes which tell about service usage. Accounting attributes are described in more detail in [18]. The type of RADIUS message and the particular RADIUS implementation define, what attributes are sent. [17] In addition to the basic set, several additional attributes and their usage have been defined in RADIUS protocol extensions. Examples of Radius extensions include attribute sets for supporting Extensible Authentication Protocol (EAP) and Tunnel Protocol support [21, 20]. This extensibility of the protocol by adding new attributes has proved to be a powerful tool. All possible data or connection types does not have to be known in advance, since given NAS support, even large amounts of configuration data can be communicated over the network and new attribute triples can be added without disturbing the existing implementations. This extensibility allows an useful functionality for mobility: request forwarding. If necessary the RADIUS server may act as a proxy. The server, upon receiving an access-request it cannot answer, may forward the request by acting as a client to another RADIUS server, which is sometimes called the remote server. The response the server receives from the remote server is then forwarded to the client. Essentially this allows RADIUS authentication requests to be directed to a certain RADIUS server from several network access points within the same domain and within certain limitations, even between domains. The RADIUS protocol itself is essentially stateless, so this requires the RADIUS server implementation to maintain internal transaction state. [17] The problems with this approach include the need for shared secret between all the RA- DIUS servers in the forwarding network, and the difficulty of configuring the server a request is to be forwarded to. End-to-end security is also impossible because of the need for each of the servers to modify some of the protocol attributes over which the MD5 checksum is calculated. Some RADIUS implementations propose to solve the RADIUS server discovery problem by adding a separate database of AAA servers or information about the AAA servers in the 3

4 DNS system. [9, 23] This does not however, solve inter-domain security problems since a shared secret and trust relationship between organizations is still required, especially since RADIUS does not possess auditing features. Additionally, not all RADIUS implementations are compatible, and therefore a forwarding arrangement between organizations can be difficult to arrange. 2.2 Diameter protocol As the number of users, points of access, offered services and their complexity grew, it became clear RADIUS could not meet all the AAA protocol requirements in an orderly fashion. The Diameter protocol was chosen as the successor of RADIUS, and is still a work in progress. Significant changes include specified failover mechanisms in cases of server outage and transport reliability, better security features and explicit support for agents and request forwarding. [29] Instead of UDP Diameter runs on top of TCP or SCTP, and has features to support structured connection set-up and closing, including heartbeat and error messages. The connections can also be encrypted using IPsec architecture [1] or TLS [10] Both of these features are particularly important for accounting messages. Backward compatibility with RADIUS has been maintained to some extent, and Diameter messages are similar in structure to RADIUS messages. Diameter protocol specifies a short header with message type, length, and application, hop-by-hop and end-to-end identifiers. The header is followed by a number of attribute-value pairs (AVP). The included AVPs depend on the type of message. Some AVPs are used by the protocol itself and others are used to carry different kinds of AAA data. Diameter protocol is extended similarly to RADIUS by adding new AVPs. [29] Unlike RADIUS, Diameter is a peer-to-peer protocol. There are 6 different kinds of roles a Diameter node can take. Diameter clients perform network access control by sending Diameter requests to Diameter servers, who perform authentication, authorization and accounting tasks for a domain. Proxy Agents forward request and response messages based on their Diameter routing table and routing-specific AVPs in a Diameter message. They may also do domain specific policy decisions and therefore sometimes have to modify message AVPs. Proxy Agent may also originate Diameter messages if it has needed to change a Diameter server s decision. Relay Agents forward requests and responses, but do not make policy decisions and therefore do not change non-routing specific AVPs. Redirect Agents do not forward messages between clients and servers, but instead reply with routing information about a suitable server in order to allow for a more direct communication. Lastly, Translation Agents perform protocol translation between Diameter nodes and RADIUS (or other AAA protocol) servers which are located in the same network. [29] In RADIUS protocol the support for forwarding requests to other RADIUS servers was mostly implicit, which posed several problems for mobility support. Diameter solves many of these problems with explicit protocol support for Proxy, Relay and Redirect Agents. In Diameter there are several alternative mechanisms for determining the correct recipient of an AAA request. Proxy and Relay Agents can be chained as in RADIUS, but the explicit support for chaining results in more resilient architecture in case of errors. A Diameter 4

5 node can also query a Redirect Agent for the correct recipient of a an AAA request for a user of certain domain. The ability of Proxy Agents to modify request and response messages takes into consideration the consequences of incomplete trust between two different administrative domains, and allows for determining the amount of possible risk. In addition to static, manually configured Diameter routing table entries, Diameter protocol also contains a dynamic peer discovery mechanism. Diameter servers are encouraged to maintain at least two (primary and secondary) connections to Diameter servers in each administrative domain. If a route to a suitable server cannot be found other techniques can also be employed. The possible methods include a Service Location Protocol version 2 (SLPv2) query [8] and NAPTR [22] and predefined guessed name queries to the Domain Name System (DNS) by using the user s Network Access Identifier s (NAI) [13] domain part as the lookup key. The identities and authorization of thus discovered Diameter nodes should be checked, before the Diameter node tries to establish a connection. Valid entries can be added to the Diameter routing table using a suitable record time to live. When two Diameter nodes establish a connection, a capability negotiation is performed in order to determine the peer s protocol version numbers, supported extensions and security mechanisms. The information is cached for future use. [29] From mobility point of view the dynamic peer discovery mechanism and capability negotiation can enable user roaming between domains without a separate agreement and NAS configuration between each Service Provider pair. This eases roaming management, while Proxy Agents can be employed in the structure to regulate the amount of trust between domains. 3 Mobility extensions The base protocol in both RADIUS and Diameter has some support for roaming, but there are also attribute set extensions to both that have special features to aid mobility and roaming. We examine two important extensions: tunnelling and mobile IP. 3.1 Tunnelling extensions The simplest arrangement of mobility using RADIUS is to dial in to the Service Provider NAS over PSTN phone lines. Phones are quite widespread, and the approach has an added advantage of making home domain configuration simpler. This solution is workable, if the required data speeds and connection prices are fairly low. It will, however, curtail the possibilities of accessing local resources, as all communication will go thorough the home network. As an alternative a tunnelling service may be used. The user connects to the Internet in some foreign network, but uses tunnelling protocols to create a virtual private line to the home network. Examples of tunnelling protocols are PPTP, L2F, L2TP and IPSEC. 5

6 Figure 2: Tunnelling setup procedure in RADIUS If suitable security measures are observed, the result is a Virtual Private Network (VPN) allowing a secure access to home network resources. [9] In a tunnelling arrangement the user connects to a local NAS, which authenticates the user with the user s home RADIUS server either by querying it or by the RADIUS proxy chaining mechanism. The necessary configuration information for tunnelling is usually contained in the response packet. The extensions used for tunnelling are contained in RFC 2868, "RADIUS Attributes for Tunnel Protocol Support" [20]. Fig. 2 illustrates the tunnel creation procedure. RADIUS can be used to define tunnelling mandatory, an example extension using L2TP is presented in by B. Adoba and G. Zorn in RFC 2194 [16]. In the case of a mandatory tunnel, the system functionality resembles a dial-in access to the home network except that the connection media is Internet instead of PSTN phone line. This way the local ISP does not have to dedicate special resources to tunnelling users to a certain network. Instead a connection is dynamically created to a tunnel server whenever needed. The attributes needed for carrying tunnelling accounting data are defined in [19]. Diameter has no tunnelling extensions defined at this point of time. [28] 3.2 RADIUS and IPv4 (Mobile IP) The Internet address basic routing scheme is hierarchical and fairly static, and therefore does not easily lend itself to quick topology changes. Mobile IP [27] establishes a way for a user to move from their home network to other foreign networks while still maintaining their network identity. The basic method employed is IP in IP tunnelling. When the user away from the home network, the Mobile IP the user, called also Mobile Node (MN) has two network identities: the static home address, and a temporary care-of address related 6

7 Figure 3: Mobile IP communication without reverse tunnelling to the foreign network the node currently inhabits. The node provides a host called Home Agent (HA) in its home network information about its current local network. The HA then receives the packets destined to the Mobile Node s home address and tunnels them to the foreign network to a host called Foreign Agent (FA) which delivers them to the Mobile Node. FA can also act as a default router for the local network s registered mobile nodes. The packet forwarding procedure can be seen in Fig. 3. The packets sent by the mobile node can also be tunnelled back to the home network and then sent to their destination by the HA. This arrangement is called reverse tunnelling. [25] One scenario requiring reverse tunnelling is the use of Network Address Translation (NAT) in user s home network. Since only the router/firewall implementing NAT at the edge of home network is aware of the address mapping, all communication between inside and outside hosts must flow thorough the router/firewall. Reverse tunnelling can also be mandated by the home domain s security policies, if all connections to hosts outside the home network must be supervised by the home network s firewall. Examples of this kind of supervision include restrictions on the allowed protocols and ports, and the requirement of initiating all connections from inside the home network. A third circumstance needing reverse tunnelling is if the foreign network routes and possibly filters packets based on the source address. This is fairly commonly done to prevent different kinds of spoofing and resource-stealing attacks, and in pheripheral networks many routers and firewalls silently drop packets where the source address and source network do not match. Reverse tunnelling allows topologically correct source IP addresses. While the Mobile IP defines a way for the mobile node to authenticate itself to the FA (the Mobile-Foreign Authentication extension), RADIUS also has an extension [24] specifically to allow for various authentication mechanisms and provide extra security in particu- 7

8 lar by making challenges possible. Connecting to Internet thorough a foreign domain requires co-operation of both the home and local service provider, as the user will be using the local provider s network resources, but will authenticate itself to the home provider. These problems are proposed to be solved by an AAA infrastructure, which will enable inter-domain authentication, authorization and accounting. The AAA requirements for Mobile IP have been defined by S. Glass, T. Hiller, S. Jacobs and C. Perkins in RFC 2977, "Mobile IP Authentication, Authorization and Accounting Requirements". [23] In the most basic model, the mobile node connects to the provider of the required service, called attendant. In the case of Mobile IP the Foreign Agent takes usually the role of attendant. Because usage of resources is usually controlled, the attendant will act in the traditional role of NAS in connecting to the local AAA server (AAAL). The AAAL in turn will contact a server in the mobile node s home domain (AAAH) for authentication of the mobile node s credentials, and for authorization information. When accounting records are generated in the foreign network, they are similarly forwarded to the user s home accounting authority. In case of commercial networks, the scale of resources granted reflects the amount of trust between the two administrative domains. The standardized method of identifying a user (especially in tunnelling or roaming contexts) is Network Access Identifier (NAI). [13] NAI is of the form user@domain, where user identifies the mobile node, and domain the node s home network or administrative realm. When the mobile node connects to the local network, NAI can be used to determine where the local RADIUS server can send the authentication and authentication requests and later accounting data. In fact it is possible for a mobile node to connect to foreign network without a home IP address, as it can be provided in the attributes of the authentication reply and other configuration data from the home network AAAH. The extensions for this are described by P. Calhoun and C. Perkins in RFC [15] RADIUS does not provide for mechanisms of establishing trust between two different domains. Agreements between service providers are certainly possible but are not scalable in the long run without a proxy architecture. [14] In a proxy architecture the number of needed shared keys and bilateral agreements is reduced by a hierarchical arrangement of RADIUS proxies, whose purpose is to route AAA traffic from one network to another. In addition policy management can be implemented in proxies by modifying the RADIUS messages if needed. Broker architectures, where each trusts a third party broker server have also been proposed. [23] Some implementations add entries for AAA hosts in the DNS system. [9, 23] All these approaches present their own set of security problems, which are outside the scope of this document. 3.3 RADIUS and IPv6 In IPv6 [11] the routing scheme is different from Mobile IP. Each host has a more or less static home address. When the host roams thorough foreign networks it acquires a list 8

9 Figure 4: In IPv6 the traffic is directed to the care-of address of care-of addresses thorough a stateless autoconfiguration or a stateful procedure such as DHCPv6. [12] When the care-of address changes, the mobile host informs Home Agent in the home network and its communication partners about the current address. Home Agent tunnels the packets sent to the mobile hosts home address, which then performs a binding update operation, so that the sender will send the next packets inside a timeout to the careof address. [2] One course of events leading to a binding update operation is shown in Fig. 4. In the figure a user is roaming outside home network, while another host in a third network wishes to initiate communication with the roaming user. In full IPv6 networks The Foreign Agents are not employed, and therefore there may not be an obvious candidate to take on the role of attendant. If dial-in access is not employed, the role of NAS can be filled for example by the local router or DHCP server. [26] In some cases the NAS may not always know whether a user will be using IPv4, IPv6 or both with IPv6 transmitted inside IPv4, and therefore using both attribute sets at the same time is permissible. If tunnelling is required, the related tunnel attributes should be used. [20] 3.4 Diameter mobility extensions Diameter can be used in authenticating, authorizing a Mobile Node and accounting for services provided. The DIAMMIP application defines the necessary AVPs and their usage. [30] Unlike in RADIUS, there is no need to separately define a way for building an AAA infrastructure because of the intra-domain capabilities of Diameter protocol. The basic model of communication is similar to RADIUS. When a Mobile Node (MN) arrives at a foreign network, it will contact a Foreign Agent (FA) to be able to contact the network. FA in turn will request authentication and authorization from the foreign 9

10 Figure 5: AAA relationship initiation in Diameter when using Mobile IP (IPv4) AAA authority, AAAF. Foreign AAAF, a Diameter node, will then determine the Mobile Node s home Diameter server and forward the credentials to the home Diameter server, also called home AAA authority (AAAH). If the AAAF is not capable of determining the home Diameter server, it will forward the request to the closest probable hop towards it, provided the security policy of the local domain allows it. If the request does not ask for a particular Home Agent, the home Diameter server will allocate one according to its internal policy, and send the information back with the request response. Other configuration information like for example home address can also be sent in the response. NAI [13] is used for user identification. Fig. 5 shows forwarding the access request to the home Diameter server and the allocation of a home agent. In some cases it is also possible to allocate the Home Agent in a foreign network. This is negotiated between the home and foreign Diameter servers. [30] When the number of networks grow, the amount of security associations (SA) between domains becomes large, and shared secrets between Home and Foreign Agents are no longer practical. The problem has been proposed to be solved with Key Distribution Centre (KDC) structure in the Diameter servers. The necessary session keys are created in the Diameter server in the network that the Home Agent resides in after the authorization phase. The keys for Home and Foreign Agents are propagated in Diameter protocol messages, while Mobile Node has its own procedure where the key is created from a nonce by cryptography by the MN and home Diameter server using HMAC-MD5. [4] 10

11 4 Conclusion In this paper we have examined the features that support for user mobility and roaming in RADIUS and Diameter AAA protocols. RADIUS support for mobility is based on the implicit possibility of forwarding requests. Correspondingly, in RADIUS the different mobility architectures rely on building a network of other trusted RADIUS servers by proxy chains. The specifications of each implementation are covered in different extensions. Diameter has more sophisticated support for mobility, including a way to discover new Diameter nodes, and a more sophisticated forwarding system. Mobile IP is also supported. In large scale networks Diameter is much preferable to RADIUS because of several new features including peer discovery, end-to-end security and protocol error messages which make the protocol more extensible, interoperable and reliable. The strengths of Diameter lie especially in roaming user authentication and authorization and providing accounting records. AAA using Diameter also requires a more limited amount of trust between the participating operators. However, the Diameter protocol is considerably more complex than RADIUS, and therefore may not gain popularity in systems where processing and memory resources are scarce, for example in embedded systems. References [1] Comer E. Douglas, "Internetworking with TCP/IP, Principles, protocols and architecture", Prentice Hall 2000 [2] Gai S., "Internetworking IPv6 with Cisco Routers" (network edition), [3] S. Dusse and R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April [4] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- Hashing for Message Authentication. RFC 2104, February [5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997 [6] Rigney, C., Rubens, A., Simpson, W. and Willens S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April [7] Rigney, C., "RADIUS Accounting", RFC 2139, April [8] Veizades J., Guttman E., Perkins C. and Kaplan S., "Service Location Protocol", RFC 2165, June 1997 [9] Aboba B., Lu J., Alsop J., Ding J. and Wang W., "Review of Roaming Implementations", RFC 2194, September 1997 [10] Dierks T. and Allen C., "The TLS Protocol Version 1.0", RFC 2246, January

12 [11] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December [12] T. Narten and Thomson, S., "IPv6 Stateless Address Autoconfiguration", RFC 2462, December [13] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January [14] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June [15] Calhoun, P. and C. Perkins, "Mobile IP Network Address Identifier Extension, RFC 2794, March [16] Aboba B. and Zorn G., "Implementation of L2TP Compulsory Tunneling via RA- DIUS", RFC 2809, April 2000 [17] Rigney, C., Rubens, A., Simpson, W. and Willens S., "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June [18] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000 [19] Zorn, G. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June [20] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June [21] Rigney, C., Willats W. and Calhoun P., "RADIUS Extensions", RFC 2869, June 2000 [22] Mealling M. and Daniel R., "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000 [23] Glass S., Hiller T., Jacobs S. and Perkins C., "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000 [24] Calhoun, P. and C. Perkins, "Mobile IP Foreign Agent Challenge/Response Extension", RFC 3012, December [25] Montenegro, G., "Reverse Tunneling for Mobile IP (revised)", RFC 3024, January [26] Aboba B., Zorn G. and Mitton D., "RADIUS and IPv6", RFC 3162, August 2001 [27] Perkins C., "IP Mobility Support for IPv4", RFC 3344, August 2002 [28] IETF Authentication, Authorization and Accounting (aaa) working group home page, [29] Calhoun P., Loughney J., Guttman E., Zorn G. and Arkko J., "Diameter Base Protocol", December 2002, Work in progress [30] Calhoun P., Perkins C. and Johansson T., "Diameter Mobile IPv4 Application", October 2002, Work in progress 12