INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-authent-02.txt Date: March 1998 DIAMETER User Authentication Extensions <draft-calhoun-diameter-authent-02.txt> Status of this Memo 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract DIAMETER is a Policy and AAA protocol which can be used for a variety of services. This document defines DIAMETER messages that are used for the authentication, authorization and accounting of users. A considerable amount of effort was put into the design of this protocol to ensure that an implementation could support both DIAMETER and RADIUS concurrently. Calhoun expires September 1998 [Page 1]
INTERNET DRAFT March 1998 Table of Contents 1.0 Introduction 1.1 Specification of Requirements 2.0 Command Codes 2.1 Domain-Discovery-Request 2.2 Domain-Discovery-Response 2.3 Authentication-Request 2.4 Authentication-Success 2.5 Authentication-Failure 2.6 Authentication-Challenge 3.0 DIAMETER AVPs 3.1 User-Name 3.2 User-Password 3.3 CHAP-Password 3.4 NAS-Port 3.5 Service-Type 3.6 Framed-Protocol 3.7 Framed-IP-Address 3.8 Framed-IP-Netmask 3.9 Framed-Routing 3.10 Filter-Id 3.11 Framed-MTU 3.12 Framed-Compression 3.13 Login-IP-Host 3.14 Login-Service 3.15 Login-TCP-Port 3.16 Reply-Message 3.17 Callback-Number 3.18 Callback-Id 3.19 Framed-Route 3.20 Framed-IPX-Network 3.21 State 3.22 Class 3.23 Vendor-Specific 3.24 Session-Timeout 3.25 Idle-Timeout 3.26 Termination-Action 3.27 Called-Station-Id 3.28 Calling-Station-Id 3.29 Proxy-State 3.30 Login-LAT-Service 3.31 Login-LAT-Node 3.32 Login-LAT-Group 3.33 Framed-AppleTalk-Link 3.34 Framed-AppleTalk-Network 3.35 Framed-AppleTalk-Zone 3.36 CHAP-Challenge 3.37 NAS-Port-Type 3.38 Port-Limit Calhoun expires September 1998 [Page 2]
INTERNET DRAFT March 1998 3.39 Login-LAT-Port 3.40 Framed-Password-Policy 3.41. Table of Attributes 5.0 Protocol Definition 5.1 RADIUS Proxies 5.2 DIAMETER Proxies 5.2 Domain Discovery 6.0 Acknowledgements 7.0 References 8.0 Authors' Addresses 1.0 Introduction This document describes the DIAMETER User Authentication Extensions that can be used for a variety of services including Dial-up users via NAS', Web User Authentication, Firewall User Authentication[5][6]. This document describes Authentication/Authorization messages as well as a set of messages which allow DIAMETER hosts to bypass proxies. Since Most of the AVPs found in this document was copied from the RADIUS protocol[1], it is possible to have both RADIUS and DIAMETER servers read the same dictionary and users files. The backward compatibility that DIAMETER offers is intended to facilitate deployment. The Extension number for this draft is 1. This value is used in the Supported-Extension AVP as defined in [2]. 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 Calhoun expires September 1998 [Page 3]
INTERNET DRAFT March 1998 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. 2.0 Command Codes This document defines the following DIAMETER Commands. All DIAMETER implementations supporting this extension MUST support all of the following commands: Command Name Command Code ----------------------------------- Domain-Discovery-Request 261 Domain-Discovery-Response 262 Authentication-Request 263 Authentication-Success 264 Authentication-Failure 265 Authentication-Challenge 266 2.1 Domain-Discovery-Request Description The Domain-Discovery-Request message is used by a DIAMETER device wishing to get contact information about a domain's home authentication server as well as to receive password policy information. This message MUST contain the User-Name attribute in order to pass along the user's domain information. The X509-Certificate or the X509-Certificate-URL [2] MUST be present in this message in order to inform the home authentication server of the issuing host's certificate. A summary of the Domain-Discovery-Request packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code Calhoun expires September 1998 [Page 4]
INTERNET DRAFT March 1998 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 261 (Domain-Discovery- Request). 2.2 Domain-Discovery-Response Description The Domain-Discovery-Response message is sent in response to the Domain-Discovery-Request message by the domain's Home authentication server. The message MUST contain either the Host- Name or Host-IP-Address and either the X509-Certificate or the X509-Certificate-URL attribute and SHOULD contain at least one Framed-Password-Policy AVP. The absence of any Framed-Password-Policy AVPs means that the issuer will only accept CHAP and PAP. A summary of the Domain-Discovery-Response packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. Calhoun expires September 1998 [Page 5]
INTERNET DRAFT March 1998 AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Command Type The Command Type field MUST be set to 262 (Domain-Discovery- Response). 2.3 Authentication-Request Description The Authentication-Request message is used in order to request authentication and authorization for a given user. If Authentication is requested the User-Name attribute MUST be present. If only Authorization is required it is possible to authorize based on DNIS and ANI instead. However, it is not possible to authenticate using a User-Name AVP and later requesting authorization based on DNIS using the same Session-Id (although the inverse is legal). Note that the flag field MAY be used in this command in order to indicate that either Authentication-Only or Authorization-Only is required for the request. If the Authentication-Only bit is set the response MUST NOT include any authorization information. Both the Authenticate and Authorize bits MUST NOT be set at the same time. To ensure that a command is both authenticated and authorized, neither flag is set. A summary of the Authentication-Request packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command AVP Length Calhoun expires September 1998 [Page 6]
INTERNET DRAFT March 1998 The length of this attribute MUST be 7. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. In addition, the following bits may be used (note these bits are mutually exclusive): Authenticate-Only 32 The Authentication-Only bit is set to indicate that only authentication of the user is requested and that no authorization information should be returned in the response. Authorize-Only 64 The Authorization-Only bit is set to indicate that only authorization of the user is requested and that no authentication is required. Command Type The Command Type field MUST be set to 263 (Authentication-Request). 2.4 Authentication-Success Description The Authentication-Success message is used in order to indicate that Authentication (or authorization) was successful. If authorization was requested a list of AVPs with the authorization information MUST be attached to the message (see section 4.40). Note that the flag field MUST be set to the same value that was found in the Authentication-Request message. A summary of the Authentication-Success packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code Calhoun expires September 1998 [Page 7]
INTERNET DRAFT March 1998 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. In addition, the following bits may be used (note these bits are mutually exclusive): Authenticate-Only 32 The Authentication-Only bit is set to indicate that only authentication of the user is requested and that no authorization information should be returned in the response. Authorize-Only 64 The Authorization-Only bit is set to indicate that only authorization of the user is requested and that no authentication is required. Command Type The Command Type field MUST be set to 264 (Authentication-Success). 2.5 Authentication-Failure Description The Authentication-Failure message is used in order to indicate that Authentication (or authorization) was unsuccessful. The list of AVPs that may be attached to this message can be found in section 4.40. Note that the flag field MUST be set to the same value that was found in the Authentication-Request message. A summary of the Authentication-Failure packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | Calhoun expires September 1998 [Page 8]
INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. In addition, the following bits may be used (note these bits are mutually exclusive): Authenticate-Only 32 The Authentication-Only bit is set to indicate that only authentication of the user is requested and that no authorization information should be returned in the response. Authorize-Only 64 The Authorization-Only bit is set to indicate that only authorization of the user is requested and that no authentication is required. Command Type The Command Type field MUST be set to 265 (Authentication-Failure). 2.6 Authentication-Challenge Description If the DIAMETER server desires to send the user a challenge requiring a response, then the DIAMETER server MUST respond to the Authentication-Request by transmitting a packet with the Code field set to 266 (Authentication-Challenge). The message MAY have one or more Reply-Message AVP, and MAY have a single State AVP, or none. No other AVPs are permitted in an Authentication-Challenge other than the Integrity-Check-Vector or Digital-Signature AVP as defined in [2]. On receipt of an Authentication-Challenge, the Identifier field is matched with a pending Authentication-Request. Invalid packets are silently discarded. The receipt of a valid Authentication-Challenge indicates that a Calhoun expires September 1998 [Page 9]
INTERNET DRAFT March 1998 new Authentication-Request SHOULD be sent. The NAS MAY display the text message, if any, to the user, and then prompt the user for a response. It then sends its original Authentication-Request with a new request ID, with the User-Password AVP replaced by the user's response (encrypted), and including the State AVP from the Authentication-Challenge, if any. Only 0 or 1 instances of the State Attribute can be present in an Authentication-Request. A NAS which supports PAP MAY forward the Reply-Message to the dialin client and accept a PAP response which it can use as though the user had entered the response. If the NAS cannot do so, it should treat the Authentication-Challenge as though it had received an Authentication-Failure instead. It is preferable to use EAP [5] instead of the Authentication- Challenge, yet it has been maintained for backward compatibility. The Authentication-Failure message is used in order to indicate that Authentication (or authorization) was unsuccessful. The list of AVPs that may be attached to this message can be found in section 4.40. Note that the flag field MUST be set to the same value that was found in the Authentication-Request message. A summary of the Authentication-Failure packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code 256 DIAMETER Command AVP Length The length of this attribute MUST be 10. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. In addition, following bits may be used (note these bits are mutually Calhoun expires September 1998 [Page 10]
INTERNET DRAFT March 1998 exclusive): Authenticate-Only 32 The Authentication-Only bit is set to indicate that only authentication of the user is requested and that no authorization information should be returned in the response. Authorize-Only 64 The Authorization-Only bit is set to indicate that only authorization of the user is requested and that no authentication is required. Command Type The Command Type field MUST be set to 266 (Authentication-Failure). 3.0 DIAMETER AVPs This section will define the mandatory AVPs which MUST be supported by all DIAMETER implementations supporting this extension. The following AVPs are defined in this document: Attribute Name Attribute Code ----------------------------------- User-Name 1 User-Password 2 CHAP-Password 3 NAS-IP-Address 4 NAS-Port 5 Service-Type 6 Framed-Protocol 7 Framed-IP-Address 8 Framed-IP-Netmask 9 Framed-Routing 10 Filter-Id 11 Framed-MTU 12 Framed-Compression 13 Login-IP-Host 14 Login-Service 15 Login-TCP-Port 16 Reply-Message 18 Callback-Number 19 Callback-Id 20 Framed-Route 22 Framed-IPX-Network 23 State 24 Class 25 Vendor-Specific 26 Session-Timeout 27 Calhoun expires September 1998 [Page 11]
INTERNET DRAFT March 1998 Idle-Timeout 28 Termination-Action 29 Called-Station-Id 30 Calling-Station-Id 31 NAS-Identifier 32 Proxy-State 33 Login-LAT-Service 34 Login-LAT-Node 35 Login-LAT-Group 36 Framed-AppleTalk-Link 37 Framed-AppleTalk-Network 38 Framed-AppleTalk-Zone 39 CHAP-Challenge 60 NAS-Port-Type 61 Port-Limit 62 Login-LAT-Port 63 Framed-Password-Policy 268 3.1. User-Name Description This Attribute indicates the name of the user to be authenticated. It is normally used in Authentication-Request packets, but MAY be present in the Authentication-Success message. A summary of the User-Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 1 for User-Name. AVP Length The length of this attribute MUST be at least 9. AVP Flagss Calhoun expires September 1998 [Page 12]
INTERNET DRAFT March 1998 The AVP Flags field MUST have bit 1 (Mandatory Support) set. The SS-Encrypted-Data bit SHOULD be set if a shared secret exists. The PK-Encrypted-data bit SHOULD NOT be set since intermediate DIAMETER servers will require this information in order to determine the home DIAMETER server. String The String field is one or more octets. All DIAMETER systems SHOULD support User-Name lengths of at least 63 octets. The format of the User-Name SHOULD follow the format defined in [7]. 3.2. User-Password Description This Attribute indicates the password of the user to be authenticated, or the user's input following an Authentication- Challenge. It is only used in Authentication-Request packets. This AVP MUST be encrypted using one of the methods described in [2]. The use of this AVP with shared secret encryption is strongly discouraged by the author due to the security implications in a proxy environment, yet the support of this attribute has been retained for RADIUS backward compability. A summary of the User-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 2 for User-Password. AVP Length The length of this attribute MUST be at least 24 and no larger than 136. AVP Flagss Calhoun expires September 1998 [Page 13]
INTERNET DRAFT March 1998 The AVP Flags field MUST have bit 1 (Mandatory Support) set. One of the AVP Encryption bits MUST be set. Data The Data field is between 16 and 128 octets long, inclusive. 3.3. CHAP-Password Description This Attribute indicates the response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in Authenticate-Request packets. If the CHAP-Password Attribute is found in a message, the CHAP- Challenge Attribute (60) MUST be present as well. A summary of the CHAP-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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHAP Ident | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 for CHAP-Password. AVP Length The length of this attribute MUST be 25. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. CHAP Ident This field is one octet, and contains the CHAP Identifier from the user's CHAP Response. Data Calhoun expires September 1998 [Page 14]
INTERNET DRAFT March 1998 The Data field is 16 octets, and contains the CHAP Response from the user. 3.4. NAS-Port Description This Attribute indicates the physical port number of the NAS which is authenticating the user. It is only used in Authetication- Request messages. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD be present in an Authentication-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 for NAS-Port. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. 3.5. Service-Type Description Calhoun expires September 1998 [Page 15]
INTERNET DRAFT March 1998 This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Authentication-Request and Authentication-Success messages. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Authentication-Failure had been received instead. A summary of the Service-Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 6 for Service-Type. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. AVP Length The length of this attribute MUST be 12. Integer32 The Integer32 field is four octets. 1 Login 2 Framed 3 Callback Login 4 Callback Framed 5 Outbound 6 Administrative 7 NAS Prompt 8 Authenticate Only 9 Callback NAS Prompt The service types are defined as follows when used in an Authetication-Success. When used in an Authentication-Request, they should be considered to be a hint to the DIAMETER server that the NAS has reason to believe the user would prefer the kind of service Calhoun expires September 1998 [Page 16]
INTERNET DRAFT March 1998 indicated, but the server is not required to honor the hint. Login The user should be connected to a host. Framed A Framed Protocol should be started for the User, such as PPP or SLIP. Callback Login The user should be disconnected and called back, then connected to a host. Callback Framed The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. Outbound The user should be granted access to outgoing devices. Administrative The user should be granted access to the administrative interface to the NAS from which privileged commands can be executed. NAS Prompt The user should be provided a command prompt on the NAS from which non-privileged commands can be executed. Authenticate Only Only Authentication is requested, and no authorization information needs to be returned in the Authentication-Success (typically used by proxy servers rather than the NAS itself). This SHOULD NOT be used in DIAMETER, yet it is maintained for backward compatibility. Callback NAS Prompt The user should be disconnected and called back, then provided a command prompt on the NAS from which non-privileged commands can be executed. 3.6. Framed-Protocol Description This Attribute indicates the framing to be used for framed access. It MAY be used in both Authentication-Request and Authentication- Success messages. A summary of the Framed-Protocol Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 Calhoun expires September 1998 [Page 17]
INTERNET DRAFT March 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 7 for Framed-Protocol. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. 1 PPP 2 SLIP 3 AppleTalk Remote Access Protocol (ARAP) 4 Gandalf proprietary SingleLink/MultiLink protocol 5 Xylogics proprietary IPX/SLIP 3.7. Framed-IP-Address Description This Attribute indicates the address to be configured for the user. It MAY be used in Authentication-Request messages as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint. A summary of the Framed-IP-Address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | Calhoun expires September 1998 [Page 18]
INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 for Framed-IP-Address. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. 3.8. Framed-IP-Netmask Description This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MUST be used in Authentication-Success messages if the Framed-IP-Address AVP was returned with a value other than 0xFFFFFFFF. It MAY be used in an Authentication-Request message as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint. A summary of the Framed-IP-Netmask 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun expires September 1998 [Page 19]
INTERNET DRAFT March 1998 Type 9 for Framed-IP-Netmask. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Address The Address field is four octets specifying the IP netmask of the user. 3.9. Framed-Routing Description This Attribute indicates the routing method for the user, when the user is a router to a network. It is only used in Authentication- Success messages. A summary of the Framed-Routing 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 10 for Framed-Routing. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Calhoun expires September 1998 [Page 20]
INTERNET DRAFT March 1998 Integer32 The Integer32 field is four octets. 0 None 1 Send routing packets 2 Listen for routing packets 3 Send and Listen 3.10. Filter-Id Description This Attribute indicates the name of the filter list for this user. Zero or more Filter-Id attributes MAY be sent in an Authentication- Success message. Identifying a filter list by name allows the filter to be used on different NASes without regard to filter-list implementation details. However, this AVP is not roaming friendly since filter naming differ from one service provider to another. It is strongly encouraged to support the Filter-Rule AVP instead. A summary of the Filter-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 11 for Filter-Id. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Calhoun expires September 1998 [Page 21]
INTERNET DRAFT March 1998 String The String field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain displayable ASCII characters from the range 32 through 126 decimal. 3.11. Framed-MTU Description This Attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It is only used in Authentication-Success messages. A summary of the Framed-MTU 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 12 for Framed-MTU. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from 64 to 65535. 3.12. Framed-Compression Calhoun expires September 1998 [Page 22]
INTERNET DRAFT March 1998 Description This Attribute indicates a compression protocol to be used for the link. It MAY be used in Authentication-Success packets. It MAY be used in an Authentication-Request packet as a hint to the server that the NAS would prefer to use that compression, but the server is not required to honor the hint. More than one compression protocol Attribute MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic. A summary of the Framed-Compression 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 13 for Framed-Compression. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. 0 None 1 VJ TCP/IP header compression [5] 2 IPX header compression 3.13. Login-IP-Host Description Calhoun expires September 1998 [Page 23]
INTERNET DRAFT March 1998 This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Authentication-Success messages. It MAY be used in an Authentication-Request message as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint. A summary of the Login-IP-Host 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 for Login-IP-Host. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to. 3.14. Login-Service Description This Attribute indicates the service which should be used to connect the user to the login host. It is only used in Authentication-Success messages. A summary of the Login-Service Attribute format is shown below. The Calhoun expires September 1998 [Page 24]
INTERNET DRAFT March 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 15 for Login-Service. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. 0 Telnet 1 Rlogin 2 TCP Clear 3 PortMaster (proprietary) 4 LAT 3.15. Login-TCP-Port Description This Attribute indicates the TCP port with which the user is to be connected, when the Login-Service Attribute is also present. It is only used in Authentication-Success packets. A summary of the Login-TCP-Port 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | Calhoun expires September 1998 [Page 25]
INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 for Login-TCP-Port. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from 0 to 65535. 3.16. Reply-Message Description This Attribute indicates text which MAY be displayed to the user. When used in an Authentication-Success, it is the success message. When used in an Authentication-Failure, it is the failure message. It MAY indicate a dialog message to prompt the user before another Authentication-Request attempt. When used in an Authentication-Challenge, it MAY indicate a dialog message to prompt the user for a response. Multiple Reply-Message's MAY be included and if any are displayed, they MUST be displayed in the same order as they appear in the packet. A summary of the Reply-Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | Calhoun expires September 1998 [Page 26]
INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 18 for Reply-Message. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain displayable ASCII characters from the range 10, 13, and 32 through 126 decimal. Mechanisms for extension to other character sets are beyond the scope of this specification. 3.17. Callback-Number Description This Attribute indicates a dialing string to be used for callback. It MAY be used in Authentication-Success packets. It MAY be used in an Authentication-Request packet as a hint to the server that a Callback service is desired, but the server is not required to honor the hint. A summary of the Callback-Number 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Calhoun expires September 1998 [Page 27]
INTERNET DRAFT March 1998 Type 19 for Callback-Number. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. 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. 3.18. Callback-Id Description This Attribute indicates the name of a place to be called, to be interpreted by the NAS. It MAY be used in Authentication-Success messages. A summary of the Callback-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 20 for Callback-Id. AVP Length The length of this attribute MUST be at least 9. Calhoun expires September 1998 [Page 28]
INTERNET DRAFT March 1998 AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. 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. 3.19. Framed-Route Description This Attribute provides routing information to be configured for the user on the NAS. It is used in the Authentication-Success message and can appear multiple times. A summary of the Framed-Route 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 22 for Framed-Route. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and Calhoun expires September 1998 [Page 29]
INTERNET DRAFT March 1998 MUST NOT affect operation of the protocol. It is recommended that the message contain displayable ASCII characters from the range 32 through 126 decimal. For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix should be used. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted in which case it should default to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address. 3.20. Framed-IPX-Network Description This Attribute indicates the IPX Network number to be configured for the user. It is used in Authentication-Success messages. A summary of the Framed-IPX-Network 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 23 for Framed-IPX-Network. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Calhoun expires September 1998 [Page 30]
INTERNET DRAFT March 1998 Integer32 The Integer32 field is four octets. The value 0xFFFFFFFF indicates that the NAS should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. assigned from a pool of one or more IPX networks kept by the NAS) Other values should be used as the IPX network for the link to the user. 3.21. State Description This Attribute is available to be sent by the server to the client in an Authentication-Challenge and MUST be sent unmodified from the client to the server in the new Authentication-Request reply to that challenge, if any. In either usage, no interpretation by the client should be made. A packet may have only one State Attribute. Usage of the State Attribute is implementation dependent. A summary of the State 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 24 for State. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets. The actual format of the Calhoun expires September 1998 [Page 31]
INTERNET DRAFT March 1998 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. 3.22. Class Description This Attribute is available to be sent by the server to the client in an Authentication-Success and should be sent unmodified by the client to the accounting server as part of the Accounting-Request message if accounting is supported. No interpretation by the client should be made. A summary of the Class 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 25 for Class. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. 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. Calhoun expires September 1998 [Page 32]
INTERNET DRAFT March 1998 3.23. Vendor-Specific Description This AVP is not supported in DIAMETER. Vendor Specific Attributes are used by enabling the Vendor-Specific bit in the AVP header. 3.24. Session-Timeout Description This Attribute sets the maximum number of seconds of service to be provided to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Authentication-Success or Authentication-Challenge. A summary of the Session-Timeout 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 27 for Session-Timeout. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is 4 octets, containing a 32-bit unsigned integer with the maximum number of seconds this user should be allowed to remain connected by the NAS. 3.25. Idle-Timeout Calhoun expires September 1998 [Page 33]
INTERNET DRAFT March 1998 Description This Attribute sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Authentication-Success or Authentication-Challenge. A summary of the Idle-Timeout 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 28 for Idle-Timeout. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is 4 octets, containing a 32-bit unsigned integer with the maximum number of consecutive seconds of idle time this user should be permitted before being disconnected by the NAS. 3.26. Termination-Action Description This Attribute is not supported in DIAMETER. 3.27. Called-Station-Id Description Calhoun expires September 1998 [Page 34]
INTERNET DRAFT March 1998 This Attribute allows the NAS to send in the Authentication-Request message the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Authentication-Request packets. If the Authorization-Only flag is set in the message and the User- Name AVP is absent, the DIAMETER Server MUST perform authorization based on this field. This can be used by a NAS to request whether a call should be answered based on the DNIS. A summary of the Called-Station-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 30 for Called-Station-Id. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, containing the phone number that the user's call came in on. The actual format of the information is site or application specific. Printable ASCII is recommended, but 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. 3.28. Calling-Station-Id Calhoun expires September 1998 [Page 35]
INTERNET DRAFT March 1998 Description This Attribute allows the NAS to send in the Authentication-Request packet the phone number that the call came from, using Automatic Number Identification (ANI) or similar technology. It is only used in Authentication-Request packets. If the Authorization-Only flag is set in the message and the User- Name AVP is absent, the DIAMETER Server must perform authorization based on this field. This can be used by a NAS to request whether a call should be answered based on the ANI. A summary of the Calling-Station-Id 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 31 for Calling-Station-Id. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, containing the phone number that the user placed the call from. The actual format of the information is site or application specific. Printable ASCII is recommended, but 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. Calhoun expires September 1998 [Page 36]
INTERNET DRAFT March 1998 3.29. Proxy-State Description This Attribute is available to be sent by a proxy server to another server when forwarding an Authentication-Request and MUST be returned unmodified in the Authentication-Success, Authentication- Failure or Authentication-Challenge. This attribute should be removed by the proxy server before the response is forwarded to the NAS. A summary of the Proxy-State 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 33 for Proxy-State. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. 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. 3.30. Login-LAT-Service Description Calhoun expires September 1998 [Page 37]
INTERNET DRAFT March 1998 This Attribute indicates the system with which the user is to be connected by LAT. It MAY be used in Authentication-Success packets, but only when LAT is specified as the Login-Service. It MAY be used in an Authentication-Request packet as a hint to the server, but the server is not required to honor the hint. Administrators use the service attribute when dealing with clustered systems, such as a VAX or Alpha cluster. In such an environment several different time sharing hosts share the same resources (disks, printers, etc.), and administrators often configure each to offer access (service) to each of the shared resources. In this case, each host in the cluster advertises its services through LAT broadcasts. Sophisticated users often know which service providers (machines) are faster and tend to use a node name when initiating a LAT connection. Alternately, some administrators want particular users to use certain machines as a primitive form of load balancing (although LAT knows how to do load balancing itself). A summary of the Login-LAT-Service 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 34 for Login-LAT-Service. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and contains the identity of the LAT service to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), Calhoun expires September 1998 [Page 38]
INTERNET DRAFT March 1998 numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension [6]. All LAT string comparisons are case insensitive. 3.31. Login-LAT-Node Description This Attribute indicates the Node with which the user is to be automatically connected by LAT. It MAY be used in Authentication- Success packets, but only when LAT is specified as the Login- Service. It MAY be used in an Authentication-Request packet as a hint to the server, but the server is not required to honor the hint. A summary of the Login-LAT-Node 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 35 for Login-LAT-Node. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and contains the identity of the LAT Node to connect the user to. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive. Calhoun expires September 1998 [Page 39]
INTERNET DRAFT March 1998 3.32. Login-LAT-Group Description This Attribute contains a string identifying the LAT group codes which this user is authorized to use. It MAY be used in Authentication-Success packets, but only when LAT is specified as the Login-Service. It MAY be used in an Authentication-Request packet as a hint to the server, but the server is not required to honor the hint. LAT supports 256 different group codes, which LAT uses as a form of access rights. LAT encodes the group codes as a 256 bit bitmap. Administrators can assign one or more of the group code bits at the LAT service provider; it will only accept LAT connections that have these group codes set in the bit map. The administrators assign a bitmap of authorized group codes to each user; LAT gets these from the operating system, and uses these in its requests to the service providers. A summary of the Login-LAT-Group 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 36 for Login-LAT-Group. AVP Length The length of this attribute MUST be 40. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Data The Data field is a 32 octet bit map, most significant octet first. A robust implementation SHOULD support the field as undistinguished Calhoun expires September 1998 [Page 40]
INTERNET DRAFT March 1998 octets. The codification of the range of allowed usage of this field is outside the scope of this specification. 3.33. Framed-AppleTalk-Link Description This Attribute indicates the AppleTalk network number which should be used for the serial link to the user, which is another AppleTalk router. It is only used in Authentication-Success packets. It is never used when the user is not another router. A summary of the Framed-AppleTalk-Link 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 37 for Framed-AppleTalk-Link. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from 0 to 65535. The special value of 0 indicates that this is an unnumbered serial link. A value of 1-65535 means that the serial line between the NAS and the user should be assigned that value as an AppleTalk network number. 3.34. Framed-AppleTalk-Network Calhoun expires September 1998 [Page 41]
INTERNET DRAFT March 1998 Description This Attribute indicates the AppleTalk Network number which the NAS should probe to allocate an AppleTalk node for the user. It is only used in Authentication-Success packets. It is never used when the user is another router. Multiple instances of this Attribute indicate that the NAS may probe using any of the network numbers specified. A summary of the Framed-AppleTalk-Network 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 38 for Framed-AppleTalk-Network. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from 0 to 65535. The special value 0 indicates that the NAS should assign a network for the user, using its default cable range. A value between 1 and 65535 (inclusive) indicates the AppleTalk Network the NAS should probe to find an address for the user. 3.35. Framed-AppleTalk-Zone Description This Attribute indicates the AppleTalk Default Zone to be used for this user. It is only used in Authentication-Success packets. Calhoun expires September 1998 [Page 42]
INTERNET DRAFT March 1998 Multiple instances of this attribute in the same packet are not allowed. A summary of the Framed-AppleTalk-Zone 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 39 for Framed-AppleTalk-Zone. AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The name of the Default AppleTalk Zone to be used for this user. 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. 3.36. CHAP-Challenge Description This Attribute contains the CHAP Challenge sent by the NAS to a PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is only used in Authentication-Request packets. A summary of the CHAP-Challenge Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 Calhoun expires September 1998 [Page 43]
INTERNET DRAFT March 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Type 60 for CHAP-Challenge. AVP Length The length of this attribute MUST be at least 24. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Data The Data field contains the CHAP Challenge. 3.37. NAS-Port-Type Description This Attribute indicates the type of the physical port of the NAS which is authenticating the user. It can be used instead of or in addition to the NAS-Port (5) attribute. It is only used in Authentication-Request packets. Either NAS-Port (5) or NAS-Port- Type or both SHOULD be present in an Authentication-Request packet, if the NAS differentiates among its ports. A summary of the NAS-Port-Type 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun expires September 1998 [Page 44]
INTERNET DRAFT March 1998 Type 61 for NAS-Port-Type. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is four octets. "Virtual" refers to a connection to the NAS via some transport protocol, instead of through a physical port. For example, if a user telnetted into a NAS to authenticate himself as an Outbound-User, the Authentication-Request might include NAS-Port-Type = Virtual as a hint to the RADIUS server that the user was not on a physical port. 0 Async 1 Sync 2 ISDN Sync 3 ISDN Async V.120 4 ISDN Async V.110 5 Virtual 3.38. Port-Limit Description This Attribute sets the maximum number of ports to be provided to the user by the NAS. This Attribute MAY be sent by the server to the client in an Authentication-Success packet. It is intended for use in conjunction with Multilink PPP [7] or similar uses. It MAY also be sent by the NAS to the server as a hint that that many ports are desired for use, but the server is not required to honor the hint. A summary of the Port-Limit 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | Calhoun expires September 1998 [Page 45]
INTERNET DRAFT March 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 62 for Port-Limit. AVP Length The length of this attribute MUST be 12. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field is 4 octets, containing a 32-bit unsigned integer with the maximum number of ports this user should be allowed to connect to on the NAS. 3.39. Login-LAT-Port Description This Attribute indicates the Port with which the user is to be connected by LAT. It MAY be used in Authentication-Success packets, but only when LAT is specified as the Login-Service. It MAY be used in an Authentication-Request packet as a hint to the server, but the server is not required to honor the hint. A summary of the Login-LAT-Port 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ Type 63 for Login-LAT-Port. Calhoun expires September 1998 [Page 46]
INTERNET DRAFT March 1998 AVP Length The length of this attribute MUST be at least 9. AVP Flagss The AVP Flags field MUST have bit 1 (Mandatory Support) set. String The String field is one or more octets, and contains the identity of the LAT port to use. The LAT Architecture allows this string to contain $ (dollar), - (hyphen), . (period), _ (underscore), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension. All LAT string comparisons are case insensitive. 3.40. Framed-Password-Policy Description This Attribute is used to indicate to a peer what types of authentication are supported by the issuing DIAMETER peer. More than one Framed-Password-Policy AVP MAY be present in the Domain- Discovery-Response message. A summary of the User-Name 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | AVP Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 268 for Framed-Password-Policy. AVP Length The length of this attribute MUST be 12. AVP Flagss Calhoun expires September 1998 [Page 47]
INTERNET DRAFT March 1998 The AVP Flags field MUST have bit 1 (Mandatory Support) set. Integer32 The Integer32 field contains the supported authentication schemes supported. The following values are supported: PAP 1 CHAP 2 MS-CHAP 3 EAP 4 SPAP 5 3.41. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute 0-1 0-1 0 0 1 0-1 1 User-Name 0-1 0 0 0 0 0 2 User-Password [*1] 0-1 0 0 0 0 0 3 CHAP-Password [*1] 0-1 0 0 0 0 0 4 NAS-IP-Address 0-1 0 0 0 0 0 5 NAS-Port 0-1 0-1 0 0 0 0 6 Service-Type 0-1 0-1 0 0 0 0 7 Framed-Protocol 0-1 0-1 0 0 0 0 8 Framed-IP-Address 0-1 0-1 0 0 0 0 9 Framed-IP-Netmask 0 0-1 0 0 0 0 10 Framed-Routing 0 0+ 0 0 0 0 11 Filter-Id 0 0-1 0 0 0 0 12 Framed-MTU 0+ 0+ 0 0 0 0 13 Framed-Compression 0+ 0+ 0 0 0 0 14 Login-IP-Host 0 0-1 0 0 0 0 15 Login-Service 0 0-1 0 0 0 0 16 Login-TCP-Port 0 0+ 0+ 0+ 0 0 18 Reply-Message 0-1 0-1 0 0 0 0 19 Callback-Number 0 0-1 0 0 0 0 20 Callback-Id 0 0+ 0 0 0 0 22 Framed-Route 0 0-1 0 0 0 0 23 Framed-IPX-Network 0-1 0-1 0 0-1 0 0 24 State 0 0+ 0 0 0 0 25 Class 0+ 0+ 0 0+ 0+ 0+ 26 Vendor-Specific 0 0-1 0 0-1 0-1 0-1 27 Session-Timeout 0 0-1 0 0-1 0-1 0-1 28 Idle-Timeout 0 0-1 0 0 0 0 29 Termination-Action 0-1 0 0 0 0 0 30 Called-Station-Id 0-1 0 0 0 0 0 31 Calling-Station-Id 0-1 0 0 0 0 0 32 NAS-Identifier Calhoun expires September 1998 [Page 48]
INTERNET DRAFT March 1998 0+ 0+ 0+ 0+ 0+ 0+ 33 Proxy-State 0-1 0-1 0 0 0 0 34 Login-LAT-Service 0-1 0-1 0 0 0 0 35 Login-LAT-Node 0-1 0-1 0 0 0 0 36 Login-LAT-Group 0 0-1 0 0 0 0 37 Framed-AppleTalk-Link 0 0+ 0 0 0 0 38 Framed-AppleTalk-Net. 0 0-1 0 0 0 0 39 Framed-AppleTalk-Zone 0-1 0 0 0 0 0 60 CHAP-Challenge 0-1 0 0 0 0 0 61 NAS-Port-Type 0-1 0-1 0 0 0 0 62 Port-Limit 0-1 0-1 0 0 0 0 63 Login-LAT-Port 0-1 0-1 0 0 0 0+ 268 Framed-Password-Pol. Req Succ Fail Chal Disc-Req Disc-Rsp # Attribute [*1] An Authentication-Request MUST NOT contain both a User- Password and a CHAP-Password AVP. The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet. 4.0 Protocol Definition This section will outline how the DIAMETER Authentication Extension can be used. 4.1 RADIUS Proxies In today's dial up networks the RADIUS protocol is used to authentication, authorize and perform accounting for dial-up users. However, it has become common practice to make use of RADIUS Servers known as proxies. The use of proxies has become widespread especially with the popularity of Internet Roaming[4]. In this example a user has a single user account with a local service provider. When this user roams outside of his ISPs service area, it is possible for the user to connect to another service provider (see [4] for more details). In this scenario, the new service provider (ISPB) provides internet access for the user through a NAS (NASB). ISPB owns an authentication server (RADB), which proxies the authentication request to the user's original provider's authentication server (RADA). Calhoun expires September 1998 [Page 49]
INTERNET DRAFT March 1998 (Access-Request) (Access-Request) +------+ -----> +------+ ------> +------+ | | | | | | | NASB +--------------------+ RADB +--------------------+ RADA + | | | | | | +------+ <----- +------+ <------ +------+ (Access-Accept) (Access-Accept) The example shown above NASB generates an authentication request on behalf of the dial-in user to the RADB Authentication server. In this case, the user's identity would include a domain identifier [3] that would enable RADB to identify the authentication server (i.e. user@ISPA.com). The RADB server then forwards the request to RADA which authenticates the user based on information found within the request. If successfully authentication the RADA server returns a successful response along with authorization information. If the user authentication fails RADA replies with a failed response. In the past this model has caused much concern over it's security implication. The model is much worse in the model where there exists an intermediate provider between ISPB and ISPA (say ISPC). The following diagram depicts such an example where RADB must forward any requests for RADA through RADC. (Accounting-Request) (Accounting-Request) +------+ -----> +------+ ------> +------+ | | | | | | | RADB +--------------------+ RADC +--------------------+ RADA + | | | | | | +------+ <----- +------+ <------ +------+ (Accounting-Response) (Accounting-Response) The problem with the above scenario is that complete trust is placed in RADC (and hence ISPC) since it is very simple to modify any attributes found within the request or the response. The example shows an accounting request sent from RADB to RADA through RADC. The following is a list of a few attacks which can be generated by a malicious proxy: - Generating Accounting Records by replaying old authentication/accounting records. In this example it is very simple for RADC to simple retain old packets and replay then at a later date. This will cause RADA to "pay" for services which were never rendered. - Modify Attributes within the request or response. In this case RADC can modify attributes, such as the length of the call, that would fool RADA into believing the call was longer than in reality. Calhoun expires September 1998 [Page 50]
INTERNET DRAFT March 1998 - Stealing PAP Passwords is another problem with today's proxies. In the current model PAP passwords are encrypted using a shared secret which is shared between each hop in the proxy chain. In this case each hop has the opportunity to decrypt, and possibly save for future use, the user's password. Given the problems identified above with the current proxy model it is necessary to create a mechanism which allows for non-repudiation, end- to-end data integrity as well as end-to-end encryption. Given the current encryption technology this can only be achieved with the use of asymetric encryption and digital signatures. 4.2 DIAMETER Proxies The DIAMETER protocol also makes use of proxies in order to keep the existing arrangements while migrating from RADIUS to DIAMETER. However since DIAMETER makes use of asymetric encryption and digital signatures it solves many of the problems shown above. (Authentication-Request) (Authentication-Request) +------+ -----> +------+ ------> +------+ | | | | | | | NASB +--------------------+ DIA2 +--------------------+ DIA1 + | | | | | | +------+ <----- +------+ <------ +------+ (Authentication-Response) (Authentication-Response) In this example NASB generates an Authentication-Request that is forwarded to DIA2. The Authentication-Request contains a digital signature AVP which "protects" all mandatory (or non-editable) AVPs within the request. All AVPs which may be modified, or removed appear after the digital signature AVP. Once DIA2 receives the request, it MAY authenticate the request to ensure that it was originated by NASB (verifying the signature is not necessary if the link between NASB and DIA2 is secured using IPSEC). The DIA2 Server may then add new attributes to the request. All mandatory AVPs MUST be present prior to the non mandatory AVPs and MUST be preceeded by a Digital Signature AVP (using DIA2's private key). Note that all non-mandatory AVPs added to the packet by NASB must appear after DIA2's digital signature AVP. The message is then forwarded towards the DIA1 server. Since all packets between NASB and DIA1 must flow through DIA2, it is not possible to use IPSEC between both hosts. Therefore DIA1 MUST validate NASB's digital signature AVP. However it is not necessary to validate DIA2's digital signature if the link between DIA2 and DIA1 is secured using IPSEC. Calhoun expires September 1998 [Page 51]
INTERNET DRAFT March 1998 This mechanism now provides a method for DIA1 to prove that NASB was the initiator of the request (note that DIAMETER also includes a timestap to prevent replay attacks). It also provides a method of ensuring that DIA2 cannot modify any "non-editable" attributes (such as length of call, etc). In addition, this same mechanism can be used for end to end encryption of AVPs. In the case where NASB needs to encrypt an AVP it is done using asymetric encryption using DIA1's public key. This ensures that only DIA1 can decrypt the AVP. An attack has been identified in this proposal which allows a malicous man in the middle attack as shown in the following diagram. (Auth-Request) (Auth-Request) (Auth-Request) +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 + | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Auth-Response) (Auth-Response) (Auth-Response) In this example, DIA3 traps packets generated from DIA2 towards DIA1, removes the AVPs added by DIA2 and inserts its own AVPs (posibly by trying to convince DIA1 to pay DIA3 for the services). This attack can be prevented by supporting a new Next-Hop AVP. In this case when NASB prepares a request it inserts a non-editable Next-Hop AVP which contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 as the next hop. This mechanism ensures that a man in the middle cannot alter the packet by overriding the previous hop's additions and signature. DIA1 could easily validate the packet's path with the use of the Next-Hop AVPs. 4.3 Domain Discovery The Domain Discovery message set is very useful in determining the Home authentication server, the password policies for the domain, as a mechanism to retrieve a certificate (or a pointer to a certificate). The following example shows a case where DIA1 needs to communicate with DIA3. In this example it is necessary to use DIA2 as a proxy in order for both ISPs to communicate. Although this MAY be desireable in some business models, there are cases where it is beneficial to remove the proxy altogether and allow both DIA3 and DIA1 to communicate in a secure fashion. (DD-Request) (DD-Request) Calhoun expires September 1998 [Page 52]
INTERNET DRAFT March 1998 +------+ -----> +------+ ------> +------+ | | | | | | | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 + | | | | | | +------+ <----- +------+ <------ +------+ (DD-Response) (DD-Response) The way the Domain Discovery works is that prior to sending out an authentication request DIA1 would issue a Domain Discovery message towards DIA2. This message is protected with the digital signature as well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 including the Next-Hop and the digital signature AVP. When DIA3 receives the request, it MUST save the certificate (or the pointer to the certificate) and respond back including the local password policy, DIA3's certificate, it's contact information (i.e. IP address) and protect the response with the digital signature. Note that in all cases the TimeStamp AVP is also present to ensure no reply packets are accepted. When DIA2 receives the packet, it must add the Next-Hop AVP as well as the digital signature AVP. When DIA1 receives the packet it then knows a direct route to communicate with DIA3 since the contact information is present in the response. The fact that both DIA1 and DIA3 can now communicate directly allows both peers to use IPSEC to protect the message exchange (note that it MAY be desirable to also use the digital signature in order to keep the information in the DIAMETER logs). (Authentication-Request) +------+ -----> +------+ | | | | | DIA1 +--------------------+ DIA3 + | | | | +------+ <----- +------+ (Authentication-Response) In addition, the password policy is also present which can indicate whether DIA3 is willing to accept CHAP, PAP or EAP authentication. Note that the Domain-Request/Response MAY include the Supported- Extension AVPs [2]. 5.0 Acknowledgements The Author wishes to thank Carl Rigney since much of the text in the document was shamefully copied from [1] as well as the following people for their help in the development of this protocol: Calhoun expires September 1998 [Page 53]
INTERNET DRAFT March 1998 Nancy Greene, Ryan Moats 6.0 References [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-00.txt, February 1998. [3] B. Aboba. "The Network Access Identifier." Internet-Draft, August 1997. [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, July 1997. [5] P. Calhoun, A. Rubens, B. Aboba, "DIAMETER Extensible Authentication Protocol Extensions", draft-calhoun-diameter-eap-01.txt, March 1998. [6] P. Calhoun, J. Haag, G. Zorn, "EAP Authentication for SOCKS Version 5", draft-ietf-aft-socks-eap-00.txt, March 1998. [7] B. Aboba, M. Beadles, "Network Address Identifier", draft-ietf-roamops-nai-10.txt, February 1998. 7.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-847-548-9587 Fax: 1-650-786-6445 E-mail: pcalhoun@toast.net Calhoun expires September 1998 [Page 54]