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.
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.
No comments:
Post a Comment