Chapter 6 AAA on the Internet 6.1 Authentication, Authorization, and Accounting The term AAA has been traditionally used to refer to Authentication, Authorization, and Accounting activities. All of those activities are of crucial importance for the operation of an IP network, although typically they are not so visible to the end user. The importance of AAA functions lies in the fact that they provide the required protection and control in accessing a network. As a consequence, the administrator of the n etwork can bill the end user for services used. By services we are referring to any type of services related to the access of the network, such as high bandwidth, provision of routing services, gateway services, etc. Before we proceed with this chapter, let us agree on a common terminology. Authentication. This is the act of verifying the identity of an entity (subject). Authorization. This is th e act of determining whether a requesting entity (subject) will be allowed access to a resource (object) (e.g., network access, certain amount of bandwidth, etc.). Accounting. This is the act of collecting information on resource usage for the purposes of capacity planning, auditing, billing, or cost allocation. All of these concepts are intimately linked. For instance, it is not feasible to record the usage of a resource when the en tity ( su bject) making usage of the resource (object) is not yet known. Therefore, in order to account for the usage of a resource the entity has to be authenticated. Once the subject is authenticated, it can be authorized to access the resource. Here, we are speaking generically. A resource could be access to a network, a radio resource, or access to a conference bridge. The rest of this chapter describes the Internet architecture needed to provide the network functions of AAA. We will learn about the protocols that the IETF has developed to provide the mentioned functions. 6.2 AAA Framework on the Internet At the beginning of 1997 the IETF defined the Remote Authentication Dial In User Service (RADIUS, RFC 2058 [260]) as the protocol to perform AAA functions on the Internet. ´ıa- M ar t´ın The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A. Garc © 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1 216 CHAPTER 6. AAA ON THE INTERNET The IETF revised the protocol in mid-1997 in RFC 2138 [261] and again in 2000 in RFC 2865 [262]. RADIUS offers a Network Access Server (NAS) the possibility of requesting authenti- cation and authorization to a centralized RADIUS server. A typical example of the usage of RADIUS is shown in Figure 6.1. A user has established an agreement to access the Internet with an operator that provides a collection of d ial-up access servers. A computer equipped with a modem dials up a Network Access Server. A circuit-switched connection is established between the computer (actually, the modem in the computer) and the Network Access Server. The Network Access Server does not contain a list of users who can access the network, since there may be a large collection of servers that are g eographically widely spread and it would not be feasible to manage the list in all access servers. Instead, the Network Access Server is configured to request authentication and authorization from an AAA server, using an AAA protocol like RADIUS. The AAA server contains all the data needed to authenticate and then authorize the user (e.g., a password). Once the user is authenticated and authorized the user can get access to the network. The Network Access Server will be providing accounting information repo rts to the AAA server, so that the networ k operator can appropriately bill the user. Network Access Server AAA Server Circuit-switched Connection AAA data Exchange IP Network Computer Figure 6.1: AAA functions in a dial-up scenario The RADIUS protocol performs relatively well in small-scale configurations and for the particular application that it was designed for, that is, a user dials into a dial-up server and the dial-up server requests authentication and authorization from an AAA server. RADIUS offers problems in large environments where congestion and lost data can occur. RADIUS runs over UDP and, therefore, lacks congestion control. RADIUS lacks some functionality that is require d in certain applications or networks, such as the ability of th e AAA server to send an unsolicited message to the access server. For all of these reasons the IETF has come up with an improved version of RADIUS named Diameter (the IETF specified the Diameter base protocol in RFC 3588 [96] at the end of 2003). The IMS has selected the modern Diameter as the protocol to perform AAA functions. As the IMS relies on Diameter rather than RADIUS, we will focus in this chapter on Diameter. 6.3. THE DIAMETER PROTOCOL 217 6.3 The Diameter Protocol Diameter is specified as a base protocol and a set of Diame ter applications that complement the base protocol fu nctionality. The base protocol contains the basic functionality and is implemented in all Diameter nodes, independently of any specific application. Applications are extensions to the basic functionality that are tailored for a particular usage of Diameter in a particular environment. For instance, there is an application tailored for Network Access Server configurations, another for Mobile IPv4, another for Credit Control, and even one for SIP. Applications are developed as extensions, so new applications are developed when needed. Figure 6.2 depicts the relation b etween the Diameter base protocol and a few applications. Diameter Base Protocol Network Access Server Application Mobile IPv4 Application Credit Control Application SIP Application Figure 6.2: Diameter base protocol and applications Diameter runs over a reliable transport that offers congestion control (e.g., TCP, SCTP). In p articular, Diameter do es not run over UDP. Unlike RADIUS, lost Diameter messages are retransmitted at each hop. Diameter provides an application-level heartbeat message that monitors the status of the connection and allows recovery in failur e situations. Diameter also allows accounting messages to be routed to a different server from authentica- tion/authorization messages (this is actually the case in the IMS). The Diameter base protocol defines different functional entities for the purpose of performing AAA functions. These are as follows. Diameter client. This is a func tional entity, typically lo cated at the edge of the network, which performs access control. Examples of Diameter clients are Network Access Servers and, in Mobile IP, mobility agents (Foreign Agents). Diameter server. This is a fun c tional entity that handles authentication, au thorization, and accounting requests for a particular realm. Realm. This is an administrative domain. Proxy. This is a functional entity that, in addition to forwarding Diameter messages, makes policy decisions relating to resource usage and provisioning. A proxy may modify messages to implement policy decisions, su ch as controlling resource usage, providing admission control, and provisioning. 218 CHAPTER 6. AAA ON THE INTERNET Relay. This is a functional entity that forwards Diameter messages, based on routing-related information and realm-routing table entries. A relay is typically transparent. It can modify Diameter messages only by inserting or removing routing-related data, but cannot modify other data. Redirect agent. This is a f unctional entity that r efers clients to servers and allows them to communicate directly. Translation agent. This is a functiona l entity that performs protocol translation between Diameter and other AAA protocols, such as RADIUS. Diameter node. This is a function al entity that implements the Diameter protocol and acts either as a Diameter client, Diameter server, proxy, r elay, redirect agent, or translation agent. Diameter is a peer-to-peer protocol, rather th a n the common client/ser ver protocol. This means that, unlike in protocols that follow the client/server model, in Diameter any of the peers can asynchronously send a request to the other peer. Note that, unlike in client/server protocols, a Diameter client is not the functional entity that sends a request and a Diameter server is not the f unctional entity that sends an answer to the request. Instead, a Diameter client is a fun ctional entity that perfo rms access control, whereas a Diameter server is the functional entity that performs authentication and authorization . In Diameter, both a Diameter client and a Diameter server can send or receive requests and responses. Diameter messages are either requests or a nswers. A request is answered by a single answer. Except for rare occasions, Diameter requests are always answered, so the sender of the request always gets accurate information about the fate of the request and, in the case of error, the sender can recover easily. Diameter is a binary-encoded protocol. 6.3.1 Diameter Sessions Weareusedtousingthetermsession in the context of SIP/SDP and with the meaning of multimedia session. According to SDP (RFC 2327 [160]), a multimedia session is: “a set of m ultimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session.” Typically, a multimedia session in SIP is delimited by INVITE and BYE transaction s. Diameter also introduces the same term with a broader meaning, and care must be taken to avoid confusion between both terms. According to the Diameter base protocol (RFC 3588 [96]), a Diameter session is: “a related progression of events devoted to a particular activity.” For instance, in the context of a user dialing up a Network Access Server, the session is composed of all the Diameter messages exchanged between the Network Access Server and the Diameter server from the moment the user dials until the connection is dropped. In the case of the IMS a Diameter session might be composed of all the messages exchanged between the S-CSCF (acting as a Diameter client) and the HSS (acting as a Diameter server) from the time the user registers in the IMS until the user is no longer registered. Whenever we use the term session in the context of Diameter, we refer to a Diameter session, unless it is explicitly referred to as a multimedia session. 6.3. THE DIAMETER PROTOCOL 219 6.3.2 The Format of a Diameter Message Figure 6.3 shows the format of a Diameter message. A Diameter message consists of a 20-octet header and a number of Attribute-Value Pairs (AVPs). The length of the header is fixed; it is always present in any Diameter message. The number of AVPs is variable, as it depends on the actual Diameter message. An AVP is a container of data (typically authentication, authorization, or accounting data). Message Length Command-Flags Command-Code Application-ID AVP 1 Version Hop-by-Hop Identifier End-to-End Identifier AVP 2 AVP n 015 31 [ ] Figure 6.3: Format of a Diameter message The Diameter header is split into fields. According to Figure 6 .3 a Diameter header starts with the Version field. For the time being, there is only Version 1. A Message-Lengthfield containing the length of the Diameter message including all the headers and AVPs follows in the Diameter header. The Command-Flags field indicate: • whether the message is a request or an answer; • whether the message is proxiable or not; 220 CHAPTER 6. AAA ON THE INTERNET • whether the message contains a protocol error according to the format of a Diameter message; • whether the message is a potentially retransmitted message. The Command-Code field identifies the actual command (i.e., the actual request or answer). Requests and answers share the same Command-Code address space. A flag present in the Command-Flags field indicates whether the message is a request or an answer. The Application-ID field identifies the Diameter application that is sending the message. For instance, the Application-ID field can identify the application as the Diameter base protocol, a Network Access Server application, a Mobile IPv4 application, or any other Diameter application. The Hop-by-Hop Identifier field contains a value that each hop sets when sending a request. The answer has the same Hop-by-Hop Identifier, so a Diameter node can easily correlate the answer with the corresponding request. Each Diameter node that treats a Diameter request changes the value of the Hop-by-Hop Identifier. The sender of the request sets the value of the End-to-End Identifier field, wh ich is a static value that does not change when Diameter nodes proxy the request. Together with the origin’s host identity, the End-to-End Identifier is used to detect duplicate requests. The Diameter node that generates an answer keeps the same value as was found in the request. 6.3.3 Attribute-Value Pairs Diameter messages, like RADIUS messages, transport a collection of Attribute-Value Pairs (AVPs). An AVP is a container of data. Figure 6.4 depicts the structure of an AVP. Each AVP contains an AVP Code, Flags,anAVP Length, an optional Vendor-ID,andData. AVP Code Flags AVP Length Vendor-ID (optional) Data 015 31 Figure 6.4: Structure of an AVP The AVP Code, in conjunction with the Vendor-ID field, if present, u niquely identifies the attribute. Th e absence of a Vendor-ID field or a Vendor-ID field with a value set to zero indicates a standard AVP specified in an IETF specification. AVP code numbers ranging from 1 to 255 identify attributes imported from or already defined by RADIUS. AVP numbers 256 and higher identify Diameter-specific attributes. 6.3. THE DIAMETER PROTOCOL 221 The Flags field indicates: • the need for encryption to guarantee end-to-end security; • whether support for the AVP is mandatory or optional; if the sender indicates that support for the AVP is mandatory and the receiver does not understand the AVP, the Diameter request is rejected; • whether the optional Vendor-ID field is present or not. The AVP Length indicates the length of the AVP, including the AVP Code, AVP Length, Flags, Vendor-ID (if present), and the Data field. The Data field contains some data specific to the attribute. The field has a length of zero or more octets. The length of the data is derived from the AVP Length field. The Diameter base protocol specifies a number of formats of the Data field: OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64,andGrouped.Mostof them are self-explanatory. A Grouped AVP is an AVP whose Data field is, in turn, a sequence of other AVPs. Diameter allows applications to derive AVP data formats. The base protocol already defines a few derived AVPs, the most important ones being the following: • Address to convey an IPv4 or IPv6 address; • Time to represent the date and time; • UTF8String to represent a UTF-8 encoded string; • DiameterIdentity to convey the fully qualified domain name of a Diameter node; • DiameterURI to convey an AAA or AAAS URI; • Enumerated, a numerical value that represents some semantics. 6.3.4 The AAA and AAAS URIs AAA protocols are able to use an aaa or an aaas URI to identify AAA resources. The aaas URI indicates that transport security must be used. The syntax of these URIs is "aaa://" FQDN [ port ] [ transport ] [ protocol ] "aaas://" FQDN [ port ] [ transport ] [ protocol ] port = ":" 1*DIGIT transport = ";transport=" transport-protocol protocol = ";protocol=" aaa-protocol transport-protocol = ( "tcp" / "sctp" / "udp" ) aaa-protocol = ( "diameter" / "radius" / "tacacs+" ) 222 CHAPTER 6. AAA ON THE INTERNET where FQDN is a Fully Qualified Domain Name. The URIs might be appended by an optional port number, an optional transport protocol, or an optional protocol to access the AAA resource. If the port number is not present, the default Diameter port number (3868) is assumed. If the transport parameter is not present, then the default SCTP protocol is assumed. If the protocol parameter is not present, Diameter is assumed. The reader should note that the aaa and aaas URIs are able to accommodate Diameter, RADIUS, and other protocols. Examples of aaa or aaas URIs include aaa://server.home1.net aaas://server.home1.net aaa://server.home1.net:8868 aaa://server.home1.net;transport=tcp;protocol=diameter 6.3.5 Diameter Base Protocol Commands We have seen that Diameter messages are either requests or answers. A request and its corresponding answer are identified by a common Command-Code in the Diam eter header. The Command-Code is a number that indicates the action the Diameter server needs to take. As a request and its corresponding answer share the same Command-Code address space, we need to refer to the Command-Flags to find out if the command is a request or an answer. The Diameter base protocol (RFC 3588 [96]) specifies an initial number of command codes. An application is able to extend these basic commands and add new application- specific ones. Table 6.1 shows the initial set of requests and answers defined in the Diameter base protocol. Table 6.1: Diameter base commands Command-Name Abbreviation Command-Code Abort-Session-Request ASR 274 Abort-Session-Answer ASA 274 Accounting-Request ACR 271 Accounting-Answer ACA 271 Capabilities-Exchange-Request CER 275 Capabilities-Exchange-Answer CEA 275 Device-Watchdog-Request DWR 280 Device-Watchdog-Answer DWA 280 Disconnect-Peer-Request DPR 282 Disconnect-Peer-Answer DPA 282 Re-Auth-Request RAR 258 Re-Auth-Answer RAA 258 Session-Termination-Request STR 275 Session-Termination-Answer STA 275 Typically, every message is abbreviated by its initials. For instance, the Abort-Session - Request message is typically referred to as the ASR message. Let us take a look at the semantics of the main Diameter messages. 6.3. THE DIAMETER PROTOCOL 223 6.3.5.1 Abort Session Request and Answer (ASR, ASA) It might be necessary for a Diameter server to stop the service provided to the user (e.g., network access) because, say, there ar e new reasons that were not anticipated when the session was authorized. Among others, lack of credit, security reasons, or just an administrative order may be reasons to abort an ongoing Diameter session. When a Diameter server decides to instruct the Diameter client to stop providing a service, the Diameter server sends an Abort-Session-Request (ASR) message to the Diameter client. The Diameter client reports the execution of the command in an Abort-Session- Answer (ASA). 6.3.5.2 Accounting Request and Answer (ACR, ACA) A Diameter node may need to report accounting events to a Diameter server that provides accounting services. Diameter provides the Accounting-Request (ACR) command, whereby a Diameter client reports usages of the service to a Diameter server. The co mmand includes information that helps the Diameter server to record the one-tim e event that generated the command or the beginning or end of a service (e.g., access to a network). 6.3.5.3 Capabilities Exchange Request and Answer (CER, CEA) The first Diameter messages that two Diameter nodes exchange, once the transport con- nection is established, are the Capabilities-Exchange-Request (CER) and the Capabilities- Exchange-Answer (CEA). The messages carry the node’s identity and its capabilities (protocol version, the supported Diameter applications, the supported security mechanisms, etc.). 6.3.5.4 Device Watchdog Request and Answer (DWR, DWA) It is essential for Diameter to de tect transpor t- an d application-layer failures as soon as possible, in order to take corrective action. The mechanism that Diameter provides to detect these failures is based on an application-layer watchdog. During periods of traffic between two Diameter nodes, if a node sends a request and no answer is received within a certain time period, that is enough to detect a failure either at the transport or application layer. However, in the absence of regular traffic it is not p ossible to detect such a potential failure. Diameter solves the problem by probing the transport and application layer by means of a Diameter node sending a DWR message. The absence of the receipt of a DWA message is enough for it to be concluded that a failure has occurred. 6.3.5.5 Disconnect Peer Request and Answer (DPR, DPA) A Diameter node that has established a transport connection with a peer Diameter node may want to close the transport connection, (e.g., if it does not foresee more traffic toward the peer node). In this case the Diameter node sends a Disconnect-Peer-Request (DPR) to the peer node to indicate the imminent disconnection of the transport protocol. The DPR message also conveys the semantics of requesting the peer not to re-establish the connection unless it is essential (e.g., to forward a message). 224 CHAPTER 6. AAA ON THE INTERNET 6.3.5.6 Re-Authentication Request and Answer (RAR, RAA) At any time, but especially in sessions that last a long time, the Diameter server may request a re-authentication of the user, just to confirm that there is no possible fraud. A Diameter server that wants to re-authenticate a user sends a Re-Auth-Request message to a Diameter client. The client responds with a Re-Auth-Answer message. 6.3.5.7 Session Termination Request and Answer (STR, STA) A Diameter client reports to the Diameter server that a user is no longer making use of the service by sending a Session-Termination-Request (STR) message. The Diameter server answers with a Session-Termination-Answer (STA ) m essage. For instance, if the dial-up server reports that the dial-up connection has dropped, then the Diameter client sends the STR message to the Diameter server. 6.3.6 Diameter Base Protocol AVPs Each request and answer defines which Attribute-Value Pairs (AVPs) are present in the message. Some AVPs may be optional in a particular request or answer; others may be mandatory. The presence or absence of standard defined AVPs are dependent on the actual request or response. For instance, the Authorization-Lifetime AVP indicates the period of time for which the authorization o f a user is valid. Once the authorization lifetime is reached, the Diameter client will re-authenticate the user. This AVP is only present in authorization answer messages. The list of Diameter base protocol AVPs is quite large; we refer the reader to RFC 3588 [96] to get the complete list. We describe in the following paragraphs a few important AVPs that are very often found in Diameter messages. The User-Name AVP indicates the username under which the user is known in the realm. The User-Name AVP follows the format of the Network Access Identifier (NAI) specified in RFC 2486 [72]. An NAI has either the format of username or username@realm.IntheIMS the User-Name AVP carries the Private User Identity. Every Diameter answer message carries a Result-Code AVP. The value of the Result- Code AVP indicates whether the request was successfully completed or not and it gives a list of possible values of the AVP that depend on the actual request and answer. The Origin-Host AVP conveys the fully qualified domain name of the Diameter node that generates the request. The node also includes the realm of the Diameter node in the Origin-Realm AV P. The Destination-Host AVP indicates the fully qualified domain name of the Diameter server where the username is defined. Sometimes the user does not know the actual host name of the server, but does know the administrative domain where the username is valid. In that case the Destination-Realm AVP is us e d. Diameter request messages can be proxiable or non-proxiable. There is a flag in the Diameter header that indicates whether the message is proxiable or not. Proxiable messages can be routed through proxies toward the destination realm. Therefore, a proxiable request always contains a Destination-Realm AVP. Non-proxiable messages are just routed to the next hop and are never forwarded. Another interesting AVP is the Session-ID AVP. It contains a global identifier of the session. All messages pertaining to the same session contain the same Session-ID AV P value. Section 6.3.1 describes the concept of session in the context of Diameter. [...].. .6. 3 THE DIAMETER PROTOCOL 225 The Vendor-Specific-Application-Id is a grouped AVP that conveys the identity of a Diameter application that is vendor-specific (e.g., not standardized in the IETF) The Vendor-Specific-Application-Id contains either an Auth-Application-Id or an Acct-Application-id AVP, although only one of them can be present at the same time The former identifies the authentication and... and authorization portion of the application, whereas the latter identifies the accounting portion of the application The Vendor-SpecificApplication-Id AVP can also contain a Vendor-Id AVP that identifies the vendor The Auth-Session-State AVP indicates whether the Diameter client wants to maintain a state for a particular Diameter session The Diameter client uses this AVP as a request, and the Diameter... with the same AVP in the answer The Proxy-Info is a grouped AVP that contains a Proxy-Host and a Proxy-State AVP; it may also contain any other AVP It allows stateless Diameter nodes to include a state in a request The corresponding answer will contain the same AVP, so the stateless Diameter node can retrieve the state information and proceed with the Diameter session The Proxy-Host AVP contains the. .. of the proxy that inserted the information The Proxy-State AVP contains the opaque data that are written and then read by the proxy itself A relay or proxy agent appends a Route-Record AVP to all the requests The Route-Record AVP contains the identity of the Diameter node the request was received from This allows the detection of loops It also allows the Diameter server to verify and authorize the . Wiley & Sons, Ltd. ISBN: 97 8- 0- 47 0- 5 166 2- 1 2 16 CHAPTER 6. AAA ON THE INTERNET The IETF revised the protocol in mid-1997 in RFC 2138 [ 261 ] and again in 2000 in RFC 2 865 [ 262 ]. RADIUS offers. The Vendor-Specific-Application-Id contains either an Auth-Application-Id or an Acct-Application-id AVP, although only one of them can be present at the same time. The former identifies the authentication and authorization. identifier of the session. All messages pertaining to the same session contain the same Session-ID AV P value. Section 6. 3.1 describes the concept of session in the context of Diameter. 6. 3. THE DIAMETER