Authentication, Authorization, and Accounting (AAA)

Authentication, authorization, and accounting have become so important that the IETF has started a separate working group (www.ietf.org/html.charters/aaa-charter.html ) that is focusing on a general AAA architecture for the Internet in order to “create a set of base protocols applicable to a number of specific AAA applications.” The applications include IP telephony and access server AAA. Note that the IETF does not get involved in the issues of business models or billing; the first two As were standardized as part of Remote Authentication Dial-In User Service (RADIUS), defined in RFC 2138, while the accounting part is published in the informational RFC 2139. RADIUS has been implemented and deployed in remote access servers ; the aaa working group was created as a follow-up to RADIUS.

Authentication of an entity can be done via a Password Authentication Protocol (PAP), which sends the request for password and then verifies the response, or a Challenge Handshake Authentication Protocol (CHAP), which “challenges” the entity to be authenticated by sending it a random string S.

The entity uses a function f (identified by a secret key, which may otherwise be known only to the authenticator) to compute f(S). The computed value is sent to the authenticator, who computes the same function on the same string, checks the response, and confirms or fails the entity depending on whether the computed and received values are equal. In a communication session, this process can repeat at random intervals.

PPP CHAP is standardized in RFC 1994, which, among other things, provides a thorough review of its advantages and disadvantages (there are some) as well as some practical considerations. RFC 1994 specifies four messages: Challenge, Response, Success, and Failure. Challenge is sent during the authentication phase (but it may be sent at other times, too); it is sent again and again until a satisfactory Response message is received (or an optional counter exceeds a specified value). The Failure message is sent if the Response value is unsatisfactory; otherwise, naturally, the Success message is sent.

Although authentication is performed in only one direction, the processes on the both ends of the PPP link can use it to authenticate each other. RFC 1994 effectively requires that Message Digest Algorithm Five (MD5) (RFC 1321) be supported for hashing with CHAP. In practice, either specialized hardware (typically, a card) or software is employed to compute the challenge. Although we don’t cover cryptography in detail, it is worth at least explaining why the words message digest are used in the name of the algorithm. This happens because the algorithm, which takes a message M of any length as an input, produces as the output a string MD5(M), whose length is fixed. Computing this string is much faster than encrypting the whole message. For more information on cryptography, see Tanenbaum (1996).

RFC 2138 defines RADIUS as a client-server protocol. One client of the RADIUS server is the Network Access Server (NAS), which can perform the LAC or LNS function (or both). In turn, a RADIUS server may also act as a proxy client to other RADIUS or (non-RADIUS) authenticating servers. When a user requests a connection, the NAS makes a corresponding request to an appropriate RADIUS server, which then attempts to authenticate the users. If the authentication is successful, the RADIUS server sends to the NAS the configuration information pertinent to the user in order to establish the requested connection and otherwise provide all services that the user is entitled to. Specifically, RADIUS server queries the user database, whose entries include lists of requirements (such as password verification) to be met in order to establish the connection. The user database entries may contain specific resources (for example, servers) that a particular user may access as well as specific port numbers.

All transactions between the client and server are authenticated through the use of the shared secret, which is never sent over the network. (The users’ passwords, however, are sent to RADIUS servers over the network, but they are always encrypted before they are sent.) The shared secret is put through the MD5 algorithm to create a 16-octet-long digest value used to authenticate messages between the RADIUS client and RADIUS server. Before we continue our discussion of the RADIUS messages, note that ultimately it is the NAS that is responsible for authenticating the end user (with or without RADIUS). Thus the NAS is the first entity to receive the user’s password. (This is done by either prompting the user or employing the information that arrived in the PPP authentication packets.)

Once the NAS has the password, it may submit it to a RADIUS server in the Access-Request message, whose attributes include the user’s ID and password (hidden using the MD5 algorithm). The RADIUS server considers such a request valid only if it shares a secret with the client. All invalid Access-Request messages are discarded; every valid Access-Request message is responded to (after a lookup in the user database) with one of the following three messages:

§  Access-Reject. This message is issued if the requirements pertinent to the user requesting access are not met.

§  Access-Accept. This message is issued if such requirements are met.

§  Access-Challenge. This message is issued if the user is to be authenticated via the challenge mechanism.

The latter message may include the text (typically obtained from an external server) to be displayed to the user (for example, Challenge 90778976. Please respond at the prompt =>). The NAS issues the request to the user, collects the response, encrypts it, and sends it back to the RADIUS server in the password field of yet another Access-Request message. The RADIUS server may then issue another challenge or reply with either Access-Reject or Access-Accept, depending on whether the user’s response to the challenge matches the expected response.

For the cases where PAP and CHAP are employed by the NAS, RFC 2138 specifies interworking with these protocols, which in most cases amounts to one-to-one mapping of respective attributes. In some cases, however, the RADIUS server may be unable to perform the requested CHAP-compliant authentication. In the example given in RFC 2138, the user password may be unknown to the RADIUS server in cleartext. Since CHAP needs the cleartext password value in order to encrypt the CHAP challenge, RADIUS cannot perform the authentication. RFC 2138 leaves no ambiguity, however, by requesting that the RADIUS server send Access-Reject when it cannot go through with authentication.

The remaining RADIUS messages are:

§  Accounting Request and Accounting Response. Described in the informational RADIUS RFC (2139), although their codes are assigned by RFC 2138.

§  Status-Server and Status-Client. Designated experimental by RFC 2138.

All the RADIUS messages are assigned codes specified in RFC 2138. In addition, one RADIUS message code is reserved for the future.

RFC 2138 has deliberately chosen UDP as the transport layer for RADIUS messages. Four reasons for doing so include:

1.  Presence of alternative servers.

2.  Timing requirements.

3.  Stateless nature of the protocol.

4.  Simplification of server implementation.

Simple Telecom : Security

Security management of a network involves identity validation (authentication), service authorization, and information privacy protection. Authentication processes identifies the device or person that is requesting the use of the telecommunications device or network services. Authorization is the process of determining what services devices are customers are permitted to use. Privacy or encryption services are used to help ensure that the information transmitted or received is not available to unauthorized recipients.

Authentication
Authentication is a process during where information is exchanged between a communications device (typically a user device such as a mobile phone) and a communications network that allows the carrier or network operator to confirm the true identity of the user (or device). Validation of the authenticity of the user or device allows a service provider to deny service to users that cannot be identified. Thus, authentication inhibits fraudulent use of a communication device that does not contain the proper identification information.

Authorization
Authorization is the enabling of services to a device or customer that requests services. Authorization is often part of the billing and customer care (BCC) system and is maintained in a customer database service profile. Services are initially enabled in a network as a result of provisioning. Provisioning is a process within a company that allows for establishment of new accounts, activation, termination of features, and coordinating and dispatching the resources necessary to fill those service orders. Provisioning is usually part of customer care systems.

Networks sometimes use mediation devices to help manage provisioning and authorizing services to customers. A mediation device is device in a telecommunications network that receives, processes, reformats, and sends information to other formats between network elements. Mediation devices are can take non-standard proprietary information (such as proprietary digital call detail records) from switches and other network equipment and reformat them into messages billing systems can understand.

Information Privacy
Information privacy is a process of protecting transmitted or received information from being understood by unauthorized recipients. Information privacy typically involves encrypting of the voice signal with a shared secret key so only authorized users with the correct key and decryption program can listen to the communication information.

Encryption is a process of a protecting voice or data information from being obtained by unauthorized users. Encryption involves the use of a data processing algorithm (formula program) that uses one or more secret keys that both the sender and receiver of the information use to encrypt and decrypt the information. Without the encryption algorithm and key(s), unauthorized listeners cannot decode the message.