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.
Add a Note HereAuthentication 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.
Add a Note HereThe 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.
Add a Note HerePPP 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.
Add a Note HereAlthough 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).
Add a Note HereRFC 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.
Add a Note HereAll 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.)
Add a Note HereOnce 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:

§  Add a Note HereAccess-Reject. This message is issued if the requirements pertinent to the user requesting access are not met.
§  Add a Note HereAccess-Accept. This message is issued if such requirements are met.
§  Add a Note HereAccess-Challenge. This message is issued if the user is to be authenticated via the challenge mechanism.
Add a Note HereThe 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.
Add a Note HereFor 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.
Add a Note HereThe remaining RADIUS messages are:
§  Add a Note HereAccounting Request and Accounting Response. Described in the informational RADIUS RFC (2139), although their codes are assigned by RFC 2138.
§  Add a Note HereStatus-Server and Status-Client. Designated experimental by RFC 2138.
Add a Note HereAll the RADIUS messages are assigned codes specified in RFC 2138. In addition, one RADIUS message code is reserved for the future.
Add a Note HereRFC 2138 has deliberately chosen UDP as the transport layer for RADIUS messages. Four reasons for doing so include:
1.  Add a Note HerePresence of alternative servers.
2.  Add a Note HereTiming requirements.
3.  Add a Note HereStateless nature of the protocol.
4.  Add a Note HereSimplification of server implementation.

1 comment:

Unknown said...

Nice post very helpful

dbakings

Telecom Made Simple

Related Posts with Thumbnails