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