[ Team LiB ] Previous Section Next Section

9.2 The Apple Remote Access Protocol

The Apple Remote Access Protocol (ARAP) sends traffic based on the AppleTalk protocol across PPP links and ISDN switched-circuit networks. ARAP is still pervasive in the Apple market, although the company is attempting to transition into an Apple-specific TCP stack for use over a PPP link. ARAP support is typically found in most RADIUS client gear, and RADIUS now supports authenticating based on the ARAP protocol.

ARAP authentication typically takes one to two steps, as follows:

  1. The first step is basically a mutual authentication with an exchange of random numbers signed with a key, which happens to be the user's password. The RADIUS client challenges and authenticates the dial-in client, and the dial-in client challenges and authenticates the RADIUS client challenges. First, the RADIUS client sends random numbers of 32 bits to the dial-in client inside an ARAP msg_auth_challenge packet. Then, the dial-in client uses his password to encrypt the two random numbers sent by the RADIUS client with DES. The dial-in client sends the result back in a msg_auth_request packet. Finally, the RADIUS client unencrypts the message based on the password it has on record for the user and verifies the random numbers are intact. If so, it encrypts the challenge from the dial-in client and sends it back in a msg_auth_response packet.

  2. The RADIUS client may initiate a second phase of authentication using optional add-in security modules, which are small pieces of code that are run on both ends of the connection and provide read and write access across the link. Some security token vendors use these add-ins to perform their own proprietary authentication.

There are some caveats to integrating ARAP and RADIUS based on the way ARAP is designed. Namely, ARAP transmits more security profile information after the first phase completes but before the second phase of authentication begins. The profile information is contained within a single attribute and is a series of numeric characters relating to passwords. Even so, challenge responses and this new profile information must exist at times that may seem a bit non-standard. But it is the standard.

To allow an ARAP-based client access to the resources the RADIUS server is protecting, an Access-Request packet must be issued on behalf of the ARAP client. This process takes place as one would imagine: the RADIUS client with the ARAP protocol generates a challenge based on a random number and, in response from the end-user client, receives the challenge and the username. The relevant data is then forwarded to the RADIUS server inside a standard RADIUS Access-Request packet. The data that is transplanted is as follows: User-Name, Framed-Protocol with a value of 3 for ARAP, ARAP-Password, and any other pertinent information like Service-Type, NAS-IP-Address, NAS-Id, NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, and others. Note that only one of the User-Password, CHAP-Password, or ARAP-Password attributes needs to be present in the Access-Request packet. Any EAP-Messages attributes supercede any of those attributes' presence in a packet.

The authentication then takes place. If the RADIUS server doesn't support ARAP, it should return an Access-Reject message. If it does, then in order to authenticate the user it should verify the user response using the challenge, found in the first eight octets of the request authenticator, and the associated response, found in the first eight octets of the ARAP-Password attribute. The resulting Access-Accept message, if this information is verified and the user is indeed successfully authenticated, should be formatted in the following manner:

  • The ID and Response Authenticator fields should be included as per the normal RADIUS standard.

  • The Service-Type attribute should be Framed-Protocol.

  • The Framed-Protocol attribute should be set to a value of 3, signifying ARAP.

  • The Session-Timeout attribute should be set to the maximum connect time. It can also be set for unlimited time by either setting the value to -1 or not including the attribute in the packet. All machines party to the transaction will consider the absence of attribute to mean the user is allowed unlimited connect time.

  • The ARAP-Challenge-Response attribute should be set to a value of eight octets of the response to the challenge. The RADIUS server forms this by finding the challenge from the last eight octets of the ARAP-Password attributes and performing DES encryption using the password of the user as the key.

  • The ARAP-Features attribute contains information that the RADIUS client should encapsulate in a feature flags packet in the ARAP protocol.

  • A single Reply-Message of up to 253 text characters can be included.

  • Framed-AppleTalk-Network may be included.

  • Framed-AppleTalk-Zone, of up to 32 characters, may also be included.

Zones are an interesting concept that deserve some commentary. The ARAP protocol maps this concept of zones, which designate access privileges a user may have that correspond with an area or a set of resources. A Zone Access Flag is defined along with a list of configured zones; this access flag specifies how the user is allowed to access the zones in the list. For example, the user might be able to use only the default zone's resources, or he may be allowed to use only the zones in an accompanying list, or he may be allowed to see all zones except those in his list. The RADIUS client gear handles zones by using configured filters with the same names as the ARAP zones. It uses the ARAP-Zone-Access attribute, which contains an integer similar to the zone access flag. The name of the zone is then transplanted by the RADIUS client into pertinent RADIUS packets using the standard RADIUS Filter-ID attribute.
    [ Team LiB ] Previous Section Next Section