Chapter 6 - AAA on the Internet

Chia sẻ: Nguyễn Văn Chiến | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST

Báo xấu

65
lượt xem 6
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

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 network can bill the end user for services used.

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Chapter 6 - AAA on the Internet

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 network 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 the 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 entity (subject) 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 deﬁned the Remote Authentication Dial In User Service (RADIUS, RFC 2058 [260]) as the protocol to perform AAA functions on the Internet. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition Gonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı © 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1
CHAPTER 6. AAA ON THE INTERNET 216 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 dial-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 geographically widely spread and it would not be feasible to manage the list in all access servers. Instead, the Network Access Server is conﬁgured 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 reports to the AAA server, so that the network operator can appropriately bill the user. IP Network Exchange Network Access AAA Server Computer Server Circuit-switched Connection AAA data Figure 6.1: AAA functions in a dial-up scenario The RADIUS protocol performs relatively well in small-scale conﬁgurations 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 required in certain applications or networks, such as the ability of the 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 speciﬁed 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 speciﬁed as a base protocol and a set of Diameter applications that complement the base protocol functionality. The base protocol contains the basic functionality and is implemented in all Diameter nodes, independently of any speciﬁc 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 conﬁgurations, 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 between the Diameter base protocol and a few applications. Network Access Credit Control Mobile IPv4 SIP Server Application Application Application Application Diameter Base Protocol Figure 6.2: Diameter base protocol and applications Diameter runs over a reliable transport that offers congestion control (e.g., TCP, SCTP). In particular, Diameter does 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 failure 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 deﬁnes different functional entities for the purpose of performing AAA functions. These are as follows. Diameter client. This is a functional entity, typically located 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 functional entity that handles authentication, authorization, 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, such as controlling resource usage, providing admission control, and provisioning.
CHAPTER 6. AAA ON THE INTERNET 218 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 functional entity that refers clients to servers and allows them to communicate directly. Translation agent. This is a functional entity that performs protocol translation between Diameter and other AAA protocols, such as RADIUS. Diameter node. This is a functional entity that implements the Diameter protocol and acts either as a Diameter client, Diameter server, proxy, relay, redirect agent, or translation agent. Diameter is a peer-to-peer protocol, rather than the common client/server 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 functional entity that sends an answer to the request. Instead, a Diameter client is a functional entity that performs 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 answers. 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 We are used to using the term session 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 multimedia senders and receivers and the data streams ﬂowing 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 transactions. 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 ﬁxed; 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). 0 15 31 Version Message Length Command-Flags Command-Code Application-ID Hop-by-Hop Identifier End-to-End Identifier AVP 1 AVP 2 [...] AVP n Figure 6.3: Format of a Diameter message The Diameter header is split into ﬁelds. According to Figure 6.3 a Diameter header starts with the Version ﬁeld. For the time being, there is only Version 1. A Message-Length ﬁeld containing the length of the Diameter message including all the headers and AVPs follows in the Diameter header. The Command-Flags ﬁeld indicate: • whether the message is a request or an answer; • whether the message is proxiable or not;
CHAPTER 6. AAA ON THE INTERNET 220 • 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 ﬁeld identiﬁes the actual command (i.e., the actual request or answer). Requests and answers share the same Command-Code address space. A ﬂag present in the Command-Flags ﬁeld indicates whether the message is a request or an answer. The Application-ID ﬁeld identiﬁes the Diameter application that is sending the message. For instance, the Application-ID ﬁeld 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 ﬁeld 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 ﬁeld, which 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, an AVP Length, an optional Vendor-ID, and Data. 0 15 31 AVP Code Flags AVP Length Vendor-ID (optional) Data Figure 6.4: Structure of an AVP The AVP Code, in conjunction with the Vendor-ID ﬁeld, if present, uniquely identiﬁes the attribute. The absence of a Vendor-ID ﬁeld or a Vendor-ID ﬁeld with a value set to zero indicates a standard AVP speciﬁed in an IETF speciﬁcation. AVP code numbers ranging from 1 to 255 identify attributes imported from or already deﬁned by RADIUS. AVP numbers 256 and higher identify Diameter-speciﬁc attributes.
6.3. THE DIAMETER PROTOCOL 221 The Flags ﬁeld 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 ﬁeld 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 ﬁeld. The Data ﬁeld contains some data speciﬁc to the attribute. The ﬁeld has a length of zero or more octets. The length of the data is derived from the AVP Length ﬁeld. The Diameter base protocol speciﬁes a number of formats of the Data ﬁeld: OctetString, Integer32, Integer64, Unsigned32, Unsigned64, Float32, Float64, and Grouped. Most of them are self-explanatory. A Grouped AVP is an AVP whose Data ﬁeld is, in turn, a sequence of other AVPs. Diameter allows applications to derive AVP data formats. The base protocol already deﬁnes 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 qualiﬁed 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+" )
CHAPTER 6. AAA ON THE INTERNET 222 where FQDN is a Fully Qualiﬁed 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 identiﬁed by a common Command-Code in the Diameter 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 ﬁnd out if the command is a request or an answer. The Diameter base protocol (RFC 3588 [96]) speciﬁes an initial number of command codes. An application is able to extend these basic commands and add new application- speciﬁc ones. Table 6.1 shows the initial set of requests and answers deﬁned 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 are 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 command includes information that helps the Diameter server to record the one-time 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 ﬁrst 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 detect transport- and 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 trafﬁc 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 trafﬁc it is not possible 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 trafﬁc 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).
CHAPTER 6. AAA ON THE INTERNET 224 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 conﬁrm 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) message. 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 deﬁnes 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 deﬁned AVPs are dependent on the actual request or response. For instance, the Authorization-Lifetime AVP indicates the period of time for which the authorization of 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 Identiﬁer (NAI) speciﬁed in RFC 2486 [72]. An NAI has either the format of username or username@realm. In the IMS 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 qualiﬁed domain name of the Diameter node that generates the request. The node also includes the realm of the Diameter node in the Origin-Realm AVP. The Destination-Host AVP indicates the fully qualiﬁed domain name of the Diameter server where the username is deﬁned. 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 used. Diameter request messages can be proxiable or non-proxiable. There is a ﬂag 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 identiﬁer of the session. All messages pertaining to the same session contain the same Session-ID AVP 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-speciﬁc (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 identiﬁes the authentication and authorization portion of the application, whereas the latter identiﬁes the accounting portion of the application. The Vendor-Specific- Application-Id AVP can also contain a Vendor-Id AVP that identiﬁes 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 server replies 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 host name 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 path a request took.