Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-radius-ext-00.txt < prev next >

Wrap

Text File | 1997-01-22 | 43KB | 1,288 lines

RADIUS Working Group C Rigney INTERNET-DRAFT Livingston W Willats Cyno Technologies expires in six months January 1997 RADIUS Extensions draft-ietf-radius-ext-00.txt Status of this Memo This document is a submission to the RADIUS Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-radius@livingston.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2058 and RFC 2059. Rigney, et al. expires in six months [Page i] DRAFT RADIUS Extensions January 1997 Table of Contents 1. Introduction .......................................... 1 1.1 Specification of Requirements ................... 1 1.2 Terminology ..................................... 1 2. Operation ............................................. 2 2.1 RADIUS support for Apple Remote Access .......... 2 3. Packet Format ......................................... 8 4. Packet Types .......................................... 8 5. Attributes ............................................ 8 5.1 Prompt .......................................... 10 5.2 Connect-Info .................................... 10 5.3 Signature ....................................... 11 5.4 EAP-Message ..................................... 12 5.5 Configuration-Token ............................. 13 5.6 Password-Retry .................................. 14 5.7 ARAP-Password ................................... 15 5.8 ARAP-Features ................................... 16 5.9 ARAP-Zone-Access ................................ 17 5.10 ARAP-Security ................................... 18 5.11 ARAP-Security-Data .............................. 18 5.12 Table of Attributes ............................. 19 Security Considerations ...................................... 20 References ................................................... 20 Acknowledgements ............................................. 20 Chair's Address .............................................. 21 Author's Addresses ........................................... 21 Rigney, et al. expires in six months [Page ii] DRAFT RADIUS Extensions January 1997 1. Introduction RFC 2058 [1] describes the RADIUS Protocol as it is implemented and deployed today, and RFC 2059 [2] describes how Accounting can be performed with RADIUS. This Internet-Draft suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental. All attributes are comprised of variable length Type-Length-Value 3-tuples. New attribute values can be added without disturbing existing implementations of the protocol. 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.2. Terminology This document uses the following terms: service The NAS provides a service to the dial-in user, such as PPP or Telnet. session Each service provided by the NAS to a dial-in user Rigney, et al. expires in six months [Page 1] DRAFT RADIUS Extensions January 1997 constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record. silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. 2. Operation Operation is identical to that defined in RFC 2058 and 2059. 2.1. RADIUS support for Apple Remote Access The RADIUS (Remote Authentication Dial-In User Service) protocol provides a method that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication database. The Apple Remote Access Protocol (ARAP) provides a method for sending AppleTalk network traffic over point-to-point links, typically, but not exclusively, asynchronous and ISDN switched-circuit connections. Though Apple is moving toward ATCP on PPP for future remote access services, ARAP is still a common way for the installed base of Macintosh users to make remote network connections, and is likely to remain so for some time. ARAP is supported by several NAS vendors who also support PPP, IPX and other protocols in the same NAS. ARAP connections in these multi-protocol devices are often not authenticated with RADIUS, or if they are, each vendor creates an individual solution to the problem. This section describes the use of additional RADIUS attributes to support ARAP. RADIUS client and server implementations that implement this specification should be able to authenticate ARAP connections in an interoperable manner. This section assumes prior knowledge of RADIUS, and will go into some detail on the operation of ARAP before entering a detailed discussion of the proposed ARAP RADIUS attributes. There are two features of ARAP this document does not address: Rigney, et al. expires in six months [Page 2] DRAFT RADIUS Extensions January 1997 1. User initiated password changing. This is not part of RADIUS, but can be implemented through a software process other than RADIUS. 2. Out-of-Band messages. At any time, the NAS can send messages to an ARA client which appear in a dialog box on the dial-in user's screen. These are not part of authentication and do not belong here. However, we note that a Reply-Message attribute in an Access-Accept may be sent down to the user as a sign-on message of the day string using the out-of-band channel. We have tried to respect the spirit of the existing RADIUS protocol as much as possible, making design decisions compatible with prior art. Further, we have tried to strike a balance between flooding the RADIUS world with new attributes, and hiding all of ARAP operation within a single multiplexed ARAP attribute string or within Extended Authentication Protocol (EAP) [4] machinery. However, we feel ARAP is enough of a departure from PPP to warrant a small set of similarly named attributes of its own. We have assumed that an ARAP-aware RADIUS server will be able to do DES encryption and generate security module challenges. This is in keeping with the general RADIUS goal of smart server / simple NAS. ARAP authenticates a connection in two phases. The first is a "Two- Way DES" random number exchange, using the user's password as a key. We say "Two-Way" because the ARAP NAS challenges the dial-in client to authenticate itself, and the dial-in client challenges the ARAP NAS to authenticate itself. Specifically, ARAP does the following: 1. The NAS sends two 32-bit random numbers to the dial-in client in an ARAP msg_auth_challenge packet. 2. The dial-in client uses the user's password to DES encrypt the two random numbers sent to it by the NAS. The dial-in client then sends this result, the user's name and two 32-bit random numbers of its own back to the NAS in an ARAP msg_auth_request packet. 3. The NAS verifies the encrypted random numbers sent by the dial-in client are what it expected. If so, it encrypts the dial- in client's challenge using the password and sends it back to the dial-in client in an ARAP msg_auth_response packet. Note that if the dial-in client's response was wrong, meaning the user has the wrong password, the server can initiate a retry sequence Rigney, et al. expires in six months [Page 3] DRAFT RADIUS Extensions January 1997 up to the maximum amount of retries allowed by the NAS. In this case, when the dial-in client receives the ARAP msg_auth_response packet it will acknowledge it with an ARAP msg_auth_again packet. After this first "DES Phase" the ARAP NAS MAY initiate a secondary authentication phase using what Apple calls "Add-In Security Modules." Security Modules are small pieces of code which run on both the client and server and are allowed to read and write arbitrary data across the communications link to perform additional authentication functions. Various security token vendors use this mechanism to authenticate ARA callers. Although ARAP allows security modules to read and write anything they like, all existing security modules use simple challenge and response cycles, with perhaps some overall control information. This document assumes all existing security modules can be supported with one or more challenge/response cycles. To complicate RADIUS and ARAP integration, ARAP sends down some profile information after the DES Phase and before the Security Module phase. This means that besides the responses to challenges, this profile information must also be present, at somewhat unusual times. Fortunately the information is only a few pieces of numeric data related to passwords, which this document packs into a single new attribute. Presenting an Access-Request to RADIUS on behalf of an ARAP connection is straightforward. The ARAP NAS generates the random number challenge, and then receives the dial-in client's response, the dial-in client's challenge, and the user's name. Assuming the user is not a guest, the following information is forwarded in an Access-Request packet: User-Name (up to 31 characters long), Framed- Protocol (set to 3, ARAP), ARAP-Password, and any additional attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc. The Request Authenticator is a NAS-generated 16 octet random number. The low-order 8 octets of this number are sent to the dial-in user as the two 4 octet random numbers required in the ARAP msg_auth_challenge packet. Octets 0-3 are the first random number and Octets 4-7 are the second random number. [Probably needs to make ordering clearer.] The ARAP-Password in the Access-Request contains a 16 octet random number field, and is used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high- order octets contain the dial-in user's challenge to the NAS (2 32- bit numbers, 8 octets) and the low-order octets contain the dial-in Rigney, et al. expires in six months [Page 4] DRAFT RADIUS Extensions January 1997 user's response to the NAS challenge (2 32-bit numbers, 8 octets). Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS. If the RADIUS server does support ARAP, it should verify the user's response using the Challenge (from the lower order 8 octets of the Request Authenticator) and the user's response (from the low order 8 octets of the ARAP-Password). If that authentication fails, the RADIUS server should return an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Messages attributes. The presence of Password-Retry indicates the ARAP NAS MAY choose to initiate another challenge-response cycle, up to a total number of times equal to the integer value of the Password-Retry attribute. If the user is authenticated, the RADIUS server should return an Access-Accept packet (Code 2) to the NAS, with ID and Response Authenticator as usual, and attributes as follows: Service-Type of Framed-Protocol. Framed-Protocol of ARAP (3). Session-Timeout with the maximum connect time for the user in seconds. If the user is to be given unlimited time, Session- Timeout should not be included in the Access-Accept packet, and ARAP will treat that as an unlimited timeout (-1). ARAP-Challenge-Response, containing 8 octets with the response to the dial-in client's challenge (the high-order 8 octets of the ARAP-Password). ARAP-Features, containing information that the NAS should send to the user in an ARAP "feature flags" packet. Octet 0: If zero, user cannot change their password. If non- zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.) Octet 1: Minimum acceptable password length (0-8). Octet 2-5: Password creation date in Macintosh format, defined Rigney, et al. expires in six months [Page 5] DRAFT RADIUS Extensions January 1997 as 32 bits unsigned representing seconds since Midnight GMT January 1, 1904. Octet 6-9 Password Expiration Delta from create date in seconds. Octet 10-13: Current RADIUS time in Macintosh format Optionally, a single Reply-Message with a string up to 253 characters long which MAY be sent down to the user to be displayed in a sign-on/message of the day dialog. Framed-AppleTalk-Network may be included. Framed-AppleTalk-Zone, up to 32 characters in length, may be included. ARAP defines the notion of a list of zones for a user. Along with a list of zone names, a Zone Access Flag is defined (and used by the NAS) which says how to use the list of zone names. That is, the dial-in user may only be allowed to see the Default Zone, or only the zones in the zone list (inclusive) or any zone except those in the zone list (exclusive). The ARAP NAS handles this by having a named filter which contains (at least) zone names. This solves the problem where a single RADIUS server is managing disparate NAS clients who may not be able to "see" all of the zone names in a user zone list. Zone names only have meaning "at the NAS." The disadvantage of this approach is that zone filters must be set up on the NAS somehow, then referenced by the RADIUS Filter-Id. ARAP-Zone-Access contains an integer which specifies how the "zone list" for this user should be used. If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to. The inclusion of a Callback-Number or Callback-Id attribute in the Access-Accept MAY cause the ARAP NAS to disconnect after sending the Feature Flags to begin callback processing in an ARAP specific way. Other attributes may be present in the Access-Accept packet as well. An ARAP NAS will need other information to finish bringing up the connection to the dial in client, but this information can be provided by the ARAP NAS without any help from RADIUS, either through configuration by SNMP, a NAS administration program, or deduced by Rigney, et al. expires in six months [Page 6] DRAFT RADIUS Extensions January 1997 the AppleTalk stack in the NAS. Specifically: 1. AppearAsNet and AppearAsNode values, sent to the client to tell it what network and node numbers it should use in its datagram packets. AppearAsNet can be taken from the Framed-AppleTalk- Network attribute or from the configuration or AppleTalk stack on the NAS. 2. The "default" zone - that is the name of the AppleTalk zone in which the dial-in client will appear. (Or can be specified with the Framed-AppleTalk-Zone attribute.) 3. Other very NAS specific stuff such as the name of the NAS, and smartbuffering information. (Smartbuffering is an ARAP mechanism for replacing common AppleTalk datagrams with small tokens, to improve slow link performance in a few common traffic situations.) 4. "Zone List" information for this user. The ARAP specification defines a "zone count" field which is actually unused. RADIUS supports ARAP Security Modules in the following manner. After DES authentication has been completed, the RADIUS server may instruct the ARAP NAS to run one or more security modules for the dial-in user. Although the underlying protocol supports executing multiple security modules in series, in practice all current implementations only allow executing one. Through the use of multiple Access-Challenge requests, multiple modules can be supported, but this facility will probably never be used. We also assume that, even though ARAP allows a free-form dialog between security modules on each end of the point-to-point link, in actual practice all security modules can be reduced to a simple challenge/response cycle. If the RADIUS server wishes to instruct the ARAP NAS to run a security module, it should send an Access-Challenge packet to the NAS with (optionally) the State attribute, plus the ARAP-Challenge- Response, ARAP-Features, and two more attributes: ARAP-Security: a four octet security module signature, containing a Macintosh OSType. ARAP-Security-Data, a string to carry the actual security module challenge and response. When the security module finishes executing, the security module response is passed in an ARAP-Security-Data attribute from the NAS Rigney, et al. expires in six months [Page 7] DRAFT RADIUS Extensions January 1997 to the RADIUS server in a second Access-Request, also including the State from the Access-Challenge. The authenticator field contains no special information in this case, and this can be discerned by the presence of the State attribute. 3. Packet Format Packet Format is identical to that defined in RFC 2058 and 2059. 4. Packet Types Packet types are identical to those defined in RFC 2058 and 2059. See "Table of Attributes" below to determine which types of packets can contain which attributes defined here. 5. Attributes RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response. Some attributes MAY be included more than once. The effect of this is attribute specific, and is specified in each attribute description. The order of attributes of the same type SHOULD be preserved. The order of attributes of different types is not required to be preserved. The end of the list of attributes is indicated by the Length of the RADIUS packet. A summary of the attribute format is the same as in RFC 2058 but is included here for ease of reference. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [2]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. This specification concerns Rigney, et al. expires in six months [Page 8] DRAFT RADIUS Extensions January 1997 the following values: 1-39 (refer to RFC 2058, "RADIUS") 40-51 (refer to RFC 2059, "RADIUS Accounting") 52-59 Unused 60-63 (refer to RFC 2058, "RADIUS") 64 Prompt 65 Connect-Info 66 Signature 67 EAP-Message 68 Configuration-Token 69 Password-Retry 70 ARAP-Password 71 ARAP-Features 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75-191 Unused Length The Length field is one octet, and indicates the length of this attribute including the Type, Length and Value fields. If an attribute is received in a packet with an invalid Length, the entire request should be silently discarded. Value The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is determined by the Type and Length fields. The format of the value field is one of four data types. string 0-253 octets address 32 bit value, most significant octet first. integer 32 bit value, most significant octet first. time 32 bit value, most significant octet first -- seconds since 00:00:00 GMT, January 1, 1970. The standard Attributes do not use this data type. Rigney, et al. expires in six months [Page 9] DRAFT RADIUS Extensions January 1997 5.1. Prompt Description This attribute is used only in Access-Challenge packets, and indicates to the NAS whether it should echo the user's response as it is entered, or not echo it. A summary of the Prompt attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Prompt. Length 6 Value The Value field is four octets. 0 No Echo 1 Echo 5.2. Connect-Info Description This attribute is sent from the NAS to indicate the nature of the user's connection. The NAS MAY send this attribute in an Access-Request or Accounting-Request to indicate the nature of the user's Rigney, et al. expires in six months [Page 10] DRAFT RADIUS Extensions January 1997 connection. A summary of the Connect-Info attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 for Connect-Info. Length >= 3 String The String field is encoded as a ASCII characters with the connection speed at the beginning of the string. For example, "28800 V42BIS/LAPM" 5.3. Signature Description This attribute MAY be used to sign Access-Requests to prevent dictionary attacks on CHAP, ARAP or EAP authentication methods. It MAY be used in any Access-Request. A RADIUS Server receiving an Access-Request with a Signature Attribute present SHOULD calculate the correct value of the Signature and silently discard the packet if it does not match the value sent. A summary of the Signature attribute format is shown below. The fields are transmitted from left to right. Rigney, et al. expires in six months [Page 11] DRAFT RADIUS Extensions January 1997 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 66 for Signature. Length 18 String Signature is an MD-5 [3] checksum of the shared secret followed by the entire Access-Request packet, including Type, ID, Length and authenticator. When the checksum is calculated the signature string should be considered to be sixteen octets of zero. This attribute is not needed if the User-Password attribute is present, but is useful for preventing dictionary attacks on other types of authentication. IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure. 5.4. EAP-Message Description This attribute opaquely encodes Extended Access Protocol [4] information to allow dial-in users to use EAP to authenticate without having to implement EAP on the NAS. The NAS places any EAP messages received from the user into one or more EAP attributes and forwards them to the RADIUS Server as part of the Access-Request, which can return EAP messages in Access- Challenge, Access-Accept and Access-Reject packets. A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access-Reject. A summary of the EAP-Message attribute format is shown below. The Rigney, et al. expires in six months [Page 12] DRAFT RADIUS Extensions January 1997 fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 67 for EAP-Message. Length >= 3. String The String field contains undifferentiated octets. If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be passed by RADIUS. 5.5. Configuration-Token Description This attribute is for use in large distributed authentication networks based on proxy. It is sent from a RADIUS Proxy Server to a RADIUS Proxy Client in an Access-Request to indicate a type of user profile to be used. It should not be sent to a NAS. A summary of the Configuration-Token attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 68 for Configuration-Token. Rigney, et al. expires in six months [Page 13] DRAFT RADIUS Extensions January 1997 Length >= 3 String The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. The codification of the range of allowed usage of this field is outside the scope of this specification. 5.6. Password-Retry Description This attribute MAY be included in an Access-Reject to indicate how many authentication attempts a user may be allowed to attempt before being disconnected. It is primarily intended for use with ARAP authentication. A summary of the Password-Retry attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 69 for Password-Retry. Length 6 Value The Value field is four octets, containing an integer specifying Rigney, et al. expires in six months [Page 14] DRAFT RADIUS Extensions January 1997 the number of password retry attempts to permit the user. 5.7. ARAP-Password Description This attribute is only present in an Access-Request packet containing a Framed-Protocol of ARAP. Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages. A summary of the ARAP-Password attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 70 for ARAP-Password. Length 18 Value This attribute contains a 16 octet string, used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets (Value1 and Value2) contain the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets) and the low-order octets (Value3 and Value4) contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets). Rigney, et al. expires in six months [Page 15] DRAFT RADIUS Extensions January 1997 5.8. ARAP-Features Description This attribute is sent in an Access-Accept packet with Framed- Protocol of ARAP, and includes password information that the NAS should sent to the user in an ARAP "feature flags" packet. A summary of the ARAP-Features attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value1 | Value2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 71 for ARAP-Features. Length 16 Value The Value field is a compound string containing information the NAS should send to the user in the ARAP "feature flags" packet. Value1: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.) Value2: Minimum acceptable password length, from 0 to 8. Value3: Password creation date in Macintosh format, defined as Rigney, et al. expires in six months [Page 16] DRAFT RADIUS Extensions January 1997 32 unsigned bits representing seconds since Midnight GMT January 1, 1904. Value4: Password Expiration Delta from create date in seconds. Value5: Current RADIUS time in Macintosh format. 5.9. ARAP-Zone-Access Description This attribute is included in an Access-Accept packet with Framed-Protocol of ARAP to indicate how the ARAP zone list for the user should be used. A summary of the ARAP-Zone-Access attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 72 for ARAP-Zone-Access. Length 6 Value The Value field is four octets encoding an integer with one of the following values: 1 Only allow access to default zone 2 Use zone filter inclusively 4 Use zone filter exclusively The value 3 is skipped, not because these are bit flags, but Rigney, et al. expires in six months [Page 17] DRAFT RADIUS Extensions January 1997 because 3 in some ARAP implementations means "all zones" which is the same as not specifying a list at all under RADIUS. If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to. 5.10. ARAP-Security Description This attribute identifies the ARAP Security Module to be used in an Access-Challenge packet. A summary of the ARAP-Security attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 73 for ARAP-Security. Length 6 Value The Value field is four octets, containing an integer specifying the security module signature, which is a Macintosh OSType. (Macintosh OSTypes are 4 ascii characters cast as a 32-bit integer) 5.11. ARAP-Security-Data Description Rigney, et al. expires in six months [Page 18] DRAFT RADIUS Extensions January 1997 This attribute contains the actual security module challenge or response, and can be found in Access-Challenge and Access-Request packets. A summary of the ARAP-Security-Data attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 74 for ARAP-Security-Data. Length >=3 String The String field contains the security module challenge or response associated with the ARAP Security Module specified in ARAP-Security. 5.12. Table of Attributes The following table provides a guide to which attributes may be found in which kind of packets. Connect-Info may have 0-1 instances in an Accounting-Request packet, the other attributes added in this document must not be present in an Accounting-Request. Request Accept Reject Challenge # Attribute 0 0 0 0-1 64 Prompt 0-1 0 0 0 65 Connect-Info 0-1 0 0 0 66 Signature 0+ 0+ 0+ 0+ 67 EAP-Message [Note 1] 0 0+ 0 0 68 Configuration-Token 0 0 0-1 0 69 Password-Retry 0-1 0 0 0 70 ARAP-Password [Note 1] 0 0-1 0 0-1 71 ARAP-Features 0 0-1 0 0 72 ARAP-Zone-Access Rigney, et al. expires in six months [Page 19] DRAFT RADIUS Extensions January 1997 0-1 0 0 0-1 73 ARAP-Security 0+ 0 0 0+ 73 ARAP-Security-Data Request Accept Reject Challenge # Attribute [Note 1] An Access-Request MUST contain either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Messages, and MUST NOT contain more than one type of those four attributes. The following table defines the above table entries. 0 This attribute MUST NOT be present 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. Security Considerations Security issues are the primary topic of this document. References [1] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997. [2] Rigney, C., "RADIUS Accounting", RFC 2059, January 1997. [3] Rivest, R., and Dusse, S., "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [4] Blunk, L., and Vollbrecht, J., "PPP Extensible Authentication Protocol (EAP)", draft-ietf-pppext-eap-auth-02.txt, June 1996. Acknowledgments RADIUS and RADIUS Accounting were originally developed by Livingston Enterprises for their PortMaster series of Network Access Servers. The section on ARAP is adopted with permission from "Using RADIUS to Authenticate Apple Remote Access Connections" by Ward Willats of Cyno Technologies (ward@cyno.com). Rigney, et al. expires in six months [Page 20] DRAFT RADIUS Extensions January 1997 Chair's Address The RADIUS working group can be contacted via the current chair: Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588 Phone: +1 510 426 0770 E-Mail: cdr@livingston.com Author's Addresses Questions about this memo can also be directed to: Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94566 E-Mail: cdr@livingston.com Questions on ARAP and RADIUS may be directed to: Ward Willats Cyno Technologies 1082 Glen Echo Ave San Jose, CA 95125 Phone: +1 408 297 7766 Email: ward@cyno.com Rigney, et al. expires in six months [Page 21]