Chapter 6 - AAA on the Internet ppt

Network Access 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 particu

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 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

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 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 reports to the AAA server, so that the network operator can appropriately bill the user

Network Access

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 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 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

Diameter is specified 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 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 between 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 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 defines 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

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 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 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.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

Application-ID

AVP 1

Version

Hop-by-Hop Identifier End-to-End Identifier

AVP 2

AVP n

[ ]

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-Length field 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;

• 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, 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

AVP Code

Vendor-ID (optional)

Data

Figure 6.4: Structure of an AVP

The AVP Code, in conjunction with the Vendor-ID field, if present, uniquely identifies the attribute The 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

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, and Grouped Most of

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+" )

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 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 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

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

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.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 first Diameter messages that two Diameter nodes exchange, once the transport con-nection is established, are the 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 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 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 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)

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) 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 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 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 Identifier (NAI) specified 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 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 AVP

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 used

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 AVP value Section 6.3.1 describes the concept of session in the context of Diameter