INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-authent-08.txt William Bulley Date: October 1999 Merit Network, Inc. DIAMETER Dial-Up (ROAMOPS) Extensions Status of this Memo This document is an individual contribution for consideration by the AAA Working Group of the Internet Engineering Task Force. Comments should be submitted to the diameter@ipass.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract This document describes the DIAMETER Dial-up User Authentication Extension that is used for ROAMOPS [4] purposes. This specification was carefully designed to ease the burden of servers that must act as RADIUS/DIAMETER gateways, by re-using the same address space that RADIUS has defined [1]. Further, by re-using the same address space, it allows a single server to read the same dictiionary for both Calhoun, Bulley expires April 2000 [Page 1]
INTERNET DRAFT October 1999 DIAMETER and RADIUS. This backward compatibility will hopefully facilitate deployment of DIAMETER. Calhoun, Bulley expires April 2000 [Page 2]
INTERNET DRAFT October 1999 Table of Contents 1.0 Introduction 1.1 Copyright Statement 1.2 Requirements language 1.3 Changes in version -06 1.4 Changes in version -07 2.0 Command Codes 2.1 AA-Request (AAR) 2.2 AA-Answer (AAA) 2.3 AA-Challenge-Ind (ACI) 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 Idle-Timeout 3.22 Called-Station-Id 3.23 Calling-Station-Id 3.24 Login-LAT-Service 3.25 Login-LAT-Node 3.26 Login-LAT-Group 3.27 Framed-AppleTalk-Link 3.28 Framed-AppleTalk-Network 3.29 Framed-AppleTalk-Zone 3.30 CHAP-Challenge 3.31 NAS-Port-Type 3.32 Port-Limit 3.33 Login-LAT-Port 3.34 Tunnel-Type 3.35 Tunnel-Medium-Type 3.36 Tunnel-Client-Endpoint Calhoun, Bulley expires April 2000 [Page 3]
INTERNET DRAFT October 1999 3.37 Tunnel-Server-Endpoint 3.38 Tunnel-Password 3.39 Tunnel-Private-Group-ID 3.40 Tunnel-Assignment-ID 3.41 Tunnel-Preference 3.42 Tunnel-Client-Auth-ID 3.43 Tunnel-Server-Auth-ID 3.44 Filter-Rule 3.46 Table of AVPs 4.0 Protocol Definition 4.1 Feature Advertisement/Discovery 4.2 Authorization Procedure 4.3 Integration with Resource-Management 5.0 References 6.0 Acknowledgements 7.0 Authors' Addresses 8.0 Full Copyright Statement 1.0 Introduction This document describes the DIAMETER Dial-up User Authentication Extension that is used for ROAMOPS [4] purposes. This specification was carefully designed to ease the burden of servers that must act as RADIUS/DIAMETER gateways, by re-using the same address space that RADIUS has defined [1]. Further, by re-using the same address space, it allows a single server to read the same dictiionary for both DIAMETER and RADIUS. This backward compatibility will hopefully facilitate deployment of DIAMETER. The Extension number for this draft is one (1). This value is used in the Extension-Id AVP as defined in [2]. 1.1 Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 1.2 Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [12]. 1.3 Changes in version -06 Calhoun, Bulley expires April 2000 [Page 4]
INTERNET DRAFT October 1999 The following changes have been made to version 06: - Changes to AVP Header Flags - Change to the document title - Changed the Command-Specific AVP Flags in all command codes defined. - Added a reference to RFC 1994 (CHAP) 1.4 Changes in version -07 The following changes have been made to version 07: - Changed the Filter-Rule AVP from 280 to 300 - Changed the Framed-Password-Policy AVP from 280 to 301 1.5 Changes in version -08 The following changes have been mde to version 08: - Removed the Framed-Password-Policy AVP since it is no longer needed with the removal of the DDR/DDA commands. - Fixed up the text in most of all AVPs where the statement introducing the AVP format was present prior to the header. - Added the various AVPs necessary to support Tunneling. 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 ----------------------------------- AA-Request 263 AA-Answer 264 AA-Challenge-Ind 265 2.1 AA-Request (AAR) Calhoun, Bulley expires April 2000 [Page 5]
INTERNET DRAFT October 1999 Description The AA-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 user is both authenticated and authorized, neither flag is set. The AA-Request message MUST include a unique Session-Id AVP. If The AA-Request is a result of a successful AA-Challenge-Ind the Session-Id MUST be identical to the one provided in the initial AA-Request. Message Format Section 3.46 contains a complete list of all valid AVPs for this message. <AA-Request> ::= <DIAMETER Header> <AA-Request Command AVP> <Session-Id AVP> <Host-IP-Address AVP> [<Host-Name AVP>] [<Proxy-State AVP>] [<Class AVP>] [<State AVP>] {<User-Name AVP> || <Called-Station-Id AVP } <Miscellaneous AVPs> <Timestamp AVP> <Nonce AVP> {<Integrity-Check-Vector AVP> || <Digital-Signature AVP } The length of the DIAMETER Command AVP must be 12 when the Command Code is set to 263 (AA-Request). Calhoun, Bulley expires April 2000 [Page 6]
INTERNET DRAFT October 1999 The following Command-specific bits may be set in the AA-Request's Command Flag field of the AVP Header: The 'C' (Authentication-only) bit may be set to indicate that only authentication of the user is required, and that no authorization should be performed. Additionally, no authorization information is expected in the AA-Response command. The 'Z' (Authorization-Only) bit may be set to indicate that only authorization of the user is requested and that no authentication is required. When this bit is set, no user authentication AVPs (i.e. User-Password, etc.) will be present in the request. 2.2 AA-Answer (AAA) Description The AA-Answer message is used in order to indicate that Authentication and/or authorization was successful. If authorization was requested a list of AVPs with the authorization information MUST be attached to the message (see section 3.36). The AA-Answer message MUST include the Session-Id AVP that was present in the AA-Request. The AA-Answer MUST also include the Host-Name AVP and the Result-Code AVP to indicate the status of the session. The following error codes are defined for this message: DIAMETER_ERROR_UNKNOWN_DOMAIN 1 This error code is used to indicate to the initiator of the request that the requested domain is unknown and cannot be resolved. DIAMETER_ERROR_USER_UNKNOWN 2 This error code is used to indicate to the initiator that the username request is not valid. DIAMETER_ERROR_BAD_PASSWORD 3 This error code indicates that the password provided is invalid. DIAMETER_ERROR_CANNOT_AUTHORIZE 4 This error code is used to indicate that the user cannot be authorized due to the fact that the user has expended the servers local resources. This could be a result that the server believes that the user already has an active session, or that the user has already spent the number of credits in Calhoun, Bulley expires April 2000 [Page 7]
INTERNET DRAFT October 1999 his/her account, etc. Note that the flag field MUST be set to the same value that was found in the AA-Request message. Message Format Section 3.46 contains a complete list of all valid AVPs for this message. <AA-Answer> ::= <DIAMETER Header> <AA-Answer Command AVP> <Session-Id AVP> <Result-Code AVP> [<Error-Code AVP>] <Host-IP-Address AVP> [<Host-Name AVP>] [<Session-Timeout AVP>] [<Proxy-State AVP>] [<Class AVP>] [<State AVP>] <Miscellaneous AVPs> <Timestamp AVP> <Nonce AVP> {<Integrity-Check-Vector AVP> || <Digital-Signature AVP } The length of the DIAMETER Command AVP must be 12 when the Command Code is set to 264 (AA-Answer). The following Command-specific bits may be set in the AA-Request's Command Flag field of the AVP Header: The 'C' (Authentication-only) bit may be set to indicate that only authentication of the user is required, and that no authorization should be performed. Additionally, no authorization information is expected in the AA-Response command. The 'Z' (Authorization-Only) bit may be set to indicate that only authorization of the user is requested and that no authentication is required. When this bit is set, no user authentication AVPs (i.e. User-Password, etc.) will be present in the request. 2.3 AA-Challenge-Ind (AACI) Description Calhoun, Bulley expires April 2000 [Page 8]
INTERNET DRAFT October 1999 If the DIAMETER server desires to send the user a challenge requiring a response, then the DIAMETER server MUST respond to the AA-Request by transmitting a message with the Code field set to 265 (AA-Challenge-Ind). 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 AA- Challenge-Ind other than the Integrity-Check-Vector or Digital- Signature AVP as defined in [2]. On receipt of an AA-Challenge-Ind, the Identifier field is matched with a pending AA-Request. Invalid messages are silently discarded. The receipt of a valid AA-Challenge-Ind indicates that a new AA- 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 Acess-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 AA-Challenge-Ind, if any. Only zero or one instances of the State Attribute can be present in an AA-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 AA-Challenge-Ind as though it had received an AA-Answer with a Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. It is preferable to use EAP [5] instead of the AA-Challenge-Ind, yet it has been maintained for backward compatibility. The AA-Challenge-Ind message MUST include the Session-Id AVP that was present in the AA-Request and MUST include the same flag value that was found in the AA-Request. Section 3.46 contains a complete list of all valid AVPs for this message. Calhoun, Bulley expires April 2000 [Page 9]
INTERNET DRAFT October 1999 AA-Challenge-Ind ::= <DIAMETER Header> <AA-Challenge-Ind Command AVP> <Session-Id AVP> <Result-Code AVP> [<Error-Code AVP>] <Host-IP-Address AVP> [<Host-Name AVP>] [<Proxy-State AVP>] [<Class AVP>] [<State AVP>] <Reply-Message AVPs> <Timestamp AVP> <Nonce AVP> {<Integrity-Check-Vector AVP> || <Digital-Signature AVP } The length of the DIAMETER Command AVP must be 12 when the Command Code is set to 265 (AA-Challenge-Ind). The following Command-specific bits may be set in the AA-Request's Command Flag field of the AVP Header: The 'C' (Authentication-only) bit may be set to indicate that only authentication of the user is required, and that no authorization should be performed. Additionally, no authorization information is expected in the AA-Response command. The 'Z' (Authorization-Only) bit may be set to indicate that only authorization of the user is requested and that no authentication is required. When this bit is set, no user authentication AVPs (i.e. User-Password, etc.) will be present in the request. 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 Definition in Section ------------------------------------------------------------ User-Name 1 3.1 User-Password 2 3.2 CHAP-Password 3 3.3 NAS-Port 5 3.4 Service-Type 6 3.5 Framed-Protocol 7 3.6 Framed-IP-Address 8 3.7 Calhoun, Bulley expires April 2000 [Page 10]
INTERNET DRAFT October 1999 Framed-IP-Netmask 9 3.8 Framed-Routing 10 3.9 Filter-Id 11 3.10 Framed-MTU 12 3.11 Framed-Compression 13 3.12 Login-IP-Host 14 3.13 Login-Service 15 3.14 Login-TCP-Port 16 3.15 Reply-Message 18 3.16 Callback-Number 19 3.17 Callback-Id 20 3.18 Framed-Route 22 3.19 Framed-IPX-Network 23 3.20 Idle-Timeout 28 3.21 Called-Station-Id 30 3.22 Calling-Station-Id 31 3.23 Login-LAT-Service 34 3.24 Login-LAT-Node 35 3.25 Login-LAT-Group 36 3.26 Framed-AppleTalk-Link 37 3.27 Framed-AppleTalk-Network 38 3.28 Framed-AppleTalk-Zone 39 3.29 CHAP-Challenge 60 3.30 NAS-Port-Type 61 3.31 Port-Limit 62 3.32 Login-LAT-Port 63 3.33 Tunnel-Type 64 3.34 Tunnel-Medium-Type 65 3.35 Tunnel-Client-Endpoint 66 3.36 Tunnel-Server-Endpoint 67 3.37 Tunnel-Password 69 3.38 Tunnel-Private-Group-ID 81 3.39 Tunnel-Assignment-ID 82 3.40 Tunnel-Preference 83 3.41 Tunnel-Client-Auth-ID 90 3.42 Tunnel-Server-Auth-ID 91 3.43 Filter-Rule 300 3.44 3.1 User-Name Description This AVP indicates the name of the user to be authenticated. It is normally used in AA-Request messages, but MAY be present in the AA-Answer message. AVP Format Calhoun, Bulley expires April 2000 [Page 11]
INTERNET DRAFT October 1999 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 Header (AVP Code = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' MAY be set, but the 'E' bit MUST NOT be set since proxy servers would have no knowledge of the user's domain. The 'V', 'T' and the 'P' bits MUST NOT be set. 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 [3]. 3.2 User-Password Description This AVP indicates the password of the user to be authenticated, or the user's input following an AA-Challenge. It is only used in AA-Request messages. 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. AVP Format 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 Header (AVP Code = 2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Length Calhoun, Bulley expires April 2000 [Page 12]
INTERNET DRAFT October 1999 The length of this attribute MUST be at least 24 and MUST be no larger than 136. AVP Flags The 'M' bit MUST be set. Either the 'H' or the 'E' bit MUST be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. The AVP Flags field MUST have bit one (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 AVP indicates the response value provided by a PPP Challenge-Handshake Authentication Protocol (CHAP) user in response to the challenge. It is only used in AA-Request messages. If the CHAP-Password AVP is found in a message, the CHAP-Challenge AVP (60) MUST be present as well. AVP Format 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 Header (AVP Code = 3) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHAP Ident | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Length The length of this attribute MUST be 25. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Calhoun, Bulley expires April 2000 [Page 13]
INTERNET DRAFT October 1999 CHAP Ident This field is one octet, and contains the CHAP Identifier from the user's CHAP Response. Data The Data field is 16 octets, and contains the CHAP Response from the user. The actual computation of the CHAP challenge can be found in [6]. 3.4 NAS-Port Description This AVP indicates the physical port number of the NAS which is authenticating the user. It is normally only used in AA-Request messages (see section 2.2 for more info). 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 AA-Request message, if the NAS differentiates among its ports. AVP Format 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 Header (AVP Code = 5) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 The Integer32 field is four octets. 3.5 Service-Type Description Calhoun, Bulley expires April 2000 [Page 14]
INTERNET DRAFT October 1999 This AVP indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both AA- Request and AA-Answer messages. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an AA-Answer with a Result-Code other than DIAMETER-SUCCESS had been received instead. AVP Format 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 Header (AVP Code = 6) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. 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 AA-Answer. When used in an AA-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 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. Calhoun, Bulley expires April 2000 [Page 15]
INTERNET DRAFT October 1999 Callback Login The user should be disconnected and calledback, 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 AA-Answer (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 AVP indicates the framing to be used for framed access. It MAY be used in both AA-Request and AA-Answer messages. AVP Format Calhoun, Bulley expires April 2000 [Page 16]
INTERNET DRAFT October 1999 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 Header (AVP Code = 7) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 AVP indicates the address to be configured for the user. It MAY be used in AA-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. AVP Format 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 Header (AVP Code = 8) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits Calhoun, Bulley expires April 2000 [Page 17]
INTERNET DRAFT October 1999 MUST NOT be 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 AVP indicates the IP netmask to be configured for the user when the user is a router to a network. It MUST be used in AA- Answer messages if the Framed-IP-Address AVP was returned with a value other than 0xFFFFFFFF. It MAY be used in an AA-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. AVP Format 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 Header (AVP Code = 9) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Address The Address field is four octets specifying the IP netmask of the user. 3.9 Framed-Routing Calhoun, Bulley expires April 2000 [Page 18]
INTERNET DRAFT October 1999 Description This AVP indicates the routing method for the user, when the user is a router to a network. It is only used in AA-Answer messages. AVP Format 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 Header (AVP Code = 10) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. 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 AVP indicates the name of the filter list for this user. Zero or more Filter-Id attributes MAY be sent in an AA-Answer 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 differs from one service provider to another. It is strongly encouraged to support the Filter-Rule AVP instead. AVP Format Calhoun, Bulley expires April 2000 [Page 19]
INTERNET DRAFT October 1999 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 Header (AVP Code = 11) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 32 through 126 decimal. 3.11 Framed-MTU Description This AVP 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 AA-Answer messages. AVP Format 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 Header (AVP Code = 12) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 Calhoun, Bulley expires April 2000 [Page 20]
INTERNET DRAFT October 1999 The Integer32 field is four octets. Despite the size of the field, values range from 64 to 65535. 3.12 Framed-Compression Description This AVP indicates a compression protocol to be used for the link. It MAY be used in AA-Answer messages. It MAY be used in an AA- Request message 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 AVP MAY be sent. It is the responsibility of the NAS to apply the proper compression protocol to appropriate link traffic. AVP Format 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 Header (AVP Code = 13) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 The Integer32 field is four octets. 0 None 1 VJ TCP/IP header compression [7] 2 IPX header compression 3.13 Login-IP-Host Description This AVP indicates the system with which to connect the user, when Calhoun, Bulley expires April 2000 [Page 21]
INTERNET DRAFT October 1999 the Login-Service AVP is included. It MAY be used in AA-Answer messages. It MAY be used in an AA-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. AVP Format 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 Header (AVP Code = 14) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 zero 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 AVP indicates the service which should be used to connect the user to the login host. It is only used in AA-Answer messages. AVP Format 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 Header (AVP Code = 15) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags Calhoun, Bulley expires April 2000 [Page 22]
INTERNET DRAFT October 1999 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 AVP indicates the TCP port with which the user is to be connected, when the Login-Service AVP is also present. It is only used in AA-Answer messages. AVP Format 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 Header (AVP Code = 16) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from zero to 65535. 3.16 Reply-Message Description Calhoun, Bulley expires April 2000 [Page 23]
INTERNET DRAFT October 1999 This AVP indicates text which MAY be displayed to the user. When used in an AA-Answer message with a successful Result-Code AVP it indicates the success message. When found in the same message with a Result-Code other than DIAMETER-SUCCESS it contains the failure message. It MAY indicate a dialog message to prompt the user before another AA-Request attempt. When used in an AA-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 message. AVP Format 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 Header (AVP Code = 18) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 Calhoun, Bulley expires April 2000 [Page 24]
INTERNET DRAFT October 1999 This AVP indicates a dialing string to be used for callback. It MAY be used in AA-Answer messages. It MAY be used in an AA-Request message as a hint to the server that a Callback service is desired, but the server is not required to honor the hint. AVP Format 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 Header (AVP Code = 19) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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 AVP indicates the name of a place to be called, to be interpreted by the NAS. It MAY be used in AA-Answer messages. This AVP is not roaming friendly since it assumes that the Callback-Id is configured on the NAS. It is therefore preferable to use the Callback-Number AVP instead. AVP Format Calhoun, Bulley expires April 2000 [Page 25]
INTERNET DRAFT October 1999 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 Header (AVP Code = 20) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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-IP-Route Description This AVP provides routing information to be configured for the user on the NAS. It is used in the AA-Answer message and can appear multiple times. AVP Format 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 Header (AVP Code = 22) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. String Calhoun, Bulley expires April 2000 [Page 26]
INTERNET DRAFT October 1999 It MUST 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". 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 AVP indicates the IPX Network number to be configured for the user. It is used in AA-Answer messages. AVP Format 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 Header (AVP Code = 23) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. 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. Calhoun, Bulley expires April 2000 [Page 27]
INTERNET DRAFT October 1999 3.21 Idle-Timeout Description This AVP sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. This AVP is available to be sent by the server to the client in an AA-Answer or AA-Challenge. AVP Format 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 Header (AVP Code = 28) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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.22 Called-Station-Id Description This AVP allows the NAS to send in the AA-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 AA-Request messages. 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. Calhoun, Bulley expires April 2000 [Page 28]
INTERNET DRAFT October 1999 AVP Format 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 Header (AVP Code = 30) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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.23 Calling-Station-Id Description This AVP allows the NAS to send in the AA-Request message the phone number that the call came from, using Automatic Number Identification (ANI) or similar technology. It is only used in AA-Request messages. 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. AVP Format Calhoun, Bulley expires April 2000 [Page 29]
INTERNET DRAFT October 1999 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 Header (AVP Code = 31) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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. 3.24 Login-LAT-Service Description This AVP indicates the system with which the user is to be connected by LAT. It MAY be used in AA-Answer messages, but only when LAT is specified as the Login-Service. It MAY be used in an AA-Request message 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 Calhoun, Bulley expires April 2000 [Page 30]
INTERNET DRAFT October 1999 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). AVP Format 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 Header (AVP Code = 34) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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), numerics, upper and lower case alphabetics, and the ISO Latin-1 character set extension [8]. All LAT string comparisons are case insensitive. 3.25 Login-LAT-Node Description This AVP indicates the Node with which the user is to be automatically connected by LAT. It MAY be used in AA-Answer messages, but only when LAT is specified as the Login-Service. It MAY be used in an AA-Request message as a hint to the server, but the server is not required to honor the hint. AVP Format Calhoun, Bulley expires April 2000 [Page 31]
INTERNET DRAFT October 1999 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 Header (AVP Code = 35) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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. 3.26 Login-LAT-Group Description This AVP contains a string identifying the LAT group codes which this user is authorized to use. It MAY be used in AA-Answer messages, but only when LAT is specified as the Login-Service. It MAY be used in an AA-Request message 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. AVP Format Calhoun, Bulley expires April 2000 [Page 32]
INTERNET DRAFT October 1999 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 Header (AVP Code = 36) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Length The length of this attribute MUST be 40. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Data The Data field is a 32 octet bit map, most significant octet first. 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.27 Framed-AppleTalk-Link Description This AVP 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 AA-Answer messages. It is never used when the user is not another router. AVP Format 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 Header (AVP Code = 37) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags Calhoun, Bulley expires April 2000 [Page 33]
INTERNET DRAFT October 1999 The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from zero to 65535. The special value of zero indicates that this is an unnumbered serial link. A value of one to 65535 means that the serial line between the NAS and the user should be assigned that value as an AppleTalk network number. 3.28 Framed-AppleTalk-Network Description This AVP indicates the AppleTalk Network number which the NAS should probe to allocate an AppleTalk node for the user. It is only used in AA-Answer messages. It is never used when the user is another router. Multiple instances of this AVP indicate that the NAS may probe using any of the network numbers specified. AVP Format 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 Header (AVP Code = 38) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Integer32 The Integer32 field is four octets. Despite the size of the field, values range from zero to 65535. The special value zero indicates that the NAS should assign a network for the user, using its default cable range. A value between one and 65535 (inclusive) indicates the AppleTalk Network the NAS should probe to find an address for the user. Calhoun, Bulley expires April 2000 [Page 34]
INTERNET DRAFT October 1999 3.29 Framed-AppleTalk-Zone Description This AVP indicates the AppleTalk Default Zone to be used for this user. It is only used in AA-Answer messages. Multiple instances of this attribute in the same message are not allowed. AVP Format 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 Header (AVP Code = 39) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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.30 CHAP-Challenge Description This AVP contains the CHAP Challenge sent by the NAS to a PPP Challenge-Handshake Authentication Protocol (CHAP) user. It is only used in AA-Request messages. AVP Format Calhoun, Bulley expires April 2000 [Page 35]
INTERNET DRAFT October 1999 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 Header (AVP Code = 60) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Length The length of this attribute MUST be at least 24. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Data The Data field contains the CHAP Challenge. 3.31 NAS-Port-Type Description This AVP 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 AA- Request messages. Either NAS-Port (5) or NAS-Port-Type or both SHOULD be present in an AA-Request message, if the NAS differentiates among its ports. AVP Format 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 Header (AVP Code = 61) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits Calhoun, Bulley expires April 2000 [Page 36]
INTERNET DRAFT October 1999 MUST NOT be 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 AA- Request might include NAS-Port-Type = Virtual as a hint to the DIAMETER 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.32 Port-Limit Description This AVP sets the maximum number of ports to be provided to the user by the NAS. This AVP MAY be sent by the server to the client in an AA-Answer message. It is intended for use in conjunction with Multilink PPP [9] 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. AVP Format 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 Header (AVP Code = 62) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Calhoun, Bulley expires April 2000 [Page 37]
INTERNET DRAFT October 1999 Integer32 The Integer32 field is four 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.33 Login-LAT-Port Description This AVP indicates the Port with which the user is to be connected by LAT. It MAY be used in AA-Answer messages, but only when LAT is specified as the Login-Service. It MAY be used in an AA-Request message as a hint to the server, but the server is not required to honor the hint. AVP Format 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 Header (AVP Code = 63) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be 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.34 Tunnel-Type Description This AVP indicates the tunneling protocol(s) to be used (in the case Calhoun, Bulley expires April 2000 [Page 38]
INTERNET DRAFT October 1999 of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in both AA-Request and AA-Answer. The Tunnel-Type SHOULD also be present in the corresponding ADIF Record within the Accounting-Request. If the Tunnel-Type AVP is present in an AA-Request message sent from a tunnel initiator, it SHOULD be taken as a hint to the DIAMETER server as to the tunnelling protocols supported by the tunnel end-point; the DIAMETER server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an AA-Answer message which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an AA-Answer with a failure Result-Code had been received instead. If the Tunnel-Type AVP is present in an AA-Request message sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the DIAMETER server determines that the use of the communicated protocol is not authorized, it MAY return an AA-Answer with a failure Result-Code message. If a tunnel terminator receives an AA-Answer message which contains one or more Tunnel-Type AVPs, none of which represent the tunneling protocol in use, the tunnel terminator SHOULD behave as though an AA-Answer with a failure Result-Code had been received instead. AVP Format 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 Header (AVP Code = 64) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', and 'P' bits MUST NOT be set. Integer32 The Value field is three octets and contains one of the following values, indicating the type of tunnel to be started. 1 Point-to-Point Tunneling Protocol (PPTP) [14] 2 Layer Two Forwarding (L2F) [15] 3 Layer Two Tunneling Protocol (L2TP) [16] 4 Ascend Tunnel Management Calhoun, Bulley expires April 2000 [Page 39]
INTERNET DRAFT October 1999 Protocol (ATMP) [17] 5 Virtual Tunneling Protocol (VTP) 6 IP Authentication Header in the Tunnel-mode (AH) [18] 7 IP-in-IP Encapsulation (IP-IP) [19] 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [21] 10 Generic Route Encapsulation (GRE) [22] 11 Bay Dial Virtual Services (DVS) 12 IP-in-IP Tunneling [23] 3.35 Tunnel-Medium-Type Description The Tunnel-Medium-Type AVP indicates which transport medium to use when creating a tunnel for those protocols (such as L2TP) that can operate over multiple transports. It MAY be included in both AA- Request and AA-Answer messages; if it is present in an AA-Request message, it SHOULD be taken as a hint to the DIAMETER server as to the tunnel media supported by the tunnel end- point. The DIAMETER server MAY ignore the hint, however. AVP Format 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 Header (AVP Code = 65) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', and 'P' bits MUST NOT be set. Integer32 The Value field is three octets and contains one of the values listed under "Address Family Numbers" in [24]. For the sake of convenience, a relevant excerpt of this list is reproduced below. 1 IPv4 (IP version 4) 2 IPv6 (IP version 6) 3 NSAP 4 HDLC (8-bit multidrop) 5 BBN 1822 6 802 (includes all 802 media plus Ethernet "canonical format") 7 E.163 (POTS) 8 E.164 (SMDS, Frame Calhoun, Bulley expires April 2000 [Page 40]
INTERNET DRAFT October 1999 Relay, ATM) 9 F.69 (Telex) 10 X.121 (X.25, Frame Relay) 11 IPX 12 Appletalk 13 Decnet IV 14 Banyan Vines 15 E.164 with NSAP format subaddress 3.36 Tunnel-Client-Endpoint Description This AVP contains the address of the initiator end of the tunnel. It MAY be included in both AA-Request and AA-Answer messages to indicate the address from which a new tunnel is to be initiated. If the Tunnel-Client-Endpoint AVP is included in an AA-Request message, the DIAMETER server should take the value as a hint; the server is not obligated to honor the hint, however. This AVP SHOULD be included in the ADIF Record of the corresponding Accounting-Request messages, in which case it indicates the address from which the tunnel was initiated. This AVP, along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-ID AVP, may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. AVP Format 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 Header (AVP Code = 66) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. Calhoun, Bulley expires April 2000 [Page 41]
INTERNET DRAFT October 1999 If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [25]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag referring to configuration data local to the DIAMETER client that describes the interface and medium-specific address to use. 3.37 Tunnel-Server-Endpoint Description This AVP indicates the address of the server end of the tunnel. The Tunnel-Server-Endpoint AVP MAY be included (as a hint to the DIAMETER server) in the AA-Request message and MUST be included in the successful AA-Response message if the initiation of a tunnel is desired. It SHOULD be included in the corresponding ADIF- Record in the subsequent Accounting-Request messages. This AVP, along with the Tunnel-Client-Endpoint and Session-Id AVP [2], may be used to provide a globally unique means to identify a tunnel for accounting and auditing purposes. AVP Format 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 Header (AVP Code = 67) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. Calhoun, Bulley expires April 2000 [Page 42]
INTERNET DRAFT October 1999 If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. Conformant implementations MUST support the dotted-decimal format and SHOULD support the FQDN format for IP addresses. If Tunnel-Medium-Type is IPv6 (2), then this string is either the FQDN of the tunnel client machine, or it is a text representation of the address in either the preferred or alternate form [25]. Conformant implementations MUST support the preferred form and SHOULD support both the alternate text form and the FQDN format for IPv6 addresses. If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag referring to configuration data local to the DIAMETER client that describes the interface and medium-specific address to use. 3.38 Tunnel-Password Description This AVP may contain a password to be used to authenticate to a remote server. It may only be included in an AA-Answer message. AVP Format 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 Header (AVP Code = 69) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. Either the 'H' and 'E' MUST be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String The String field contains the encrypted version of the Tunnel Password. Calhoun, Bulley expires April 2000 [Page 43]
INTERNET DRAFT October 1999 3.39 Tunnel-Private-Group-ID Description This AVP indicates the group ID for a particular tunneled session. The Tunnel-Private-Group-ID AVP MAY be included in the AA-Request message if the tunnel initiator can pre- determine the group resulting from a particular connection and SHOULD be included in the AA-Answer message if this tunnel session is to be treated as belonging to a particular private group. Private groups may be used to associate a tunneled session with a particular group of users. For example, it may be used to facilitate routing of unregistered IP addresses through a particular interface. This value SHOULD be included the corresponding ADIF-Record in the Accounting-Request which pertain to a tunneled session. AVP Format 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 Header (AVP Code = 81) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String This field must be present. The group is represented by the String field. There is no restriction on the format of group IDs. 3.40 Tunnel-Assignment-ID Description This AVP is used to indicate to the tunnel initiator the particular tunnel to which a session is to be assigned. Some tunneling protocols, such as PPTP and L2TP, allow for sessions between the same two tunnel endpoints to be multiplexed over the same tunnel and also for a given session to utilize its own Calhoun, Bulley expires April 2000 [Page 44]
INTERNET DRAFT October 1999 dedicated tunnel. This attribute provides a mechanism for DIAMETER to be used to inform the tunnel initiator (e.g. PAC, LAC) whether to assign the session to a multiplexed tunnel or to a separate tunnel. Furthermore, it allows for sessions sharing multiplexed tunnels to be assigned to different multiplexed tunnels. A particular tunneling implementation may assign differing characteristics to particular tunnels. For example, different tunnels may be assigned different QOS parameters. Such tunnels may be used to carry either individual or multiple sessions. The Tunnel-Assignment-ID attribute thus allows the DIAMETER server to indicate that a particular session is to be assigned to a tunnel that provides an appropriate level of service. It is expected that any QOS-related DIAMETER tunneling attributes defined in the future that accompany this attribute will be associated by the tunnel initiator with the ID given by this attribute. In the meantime, any semantic given to a particular ID string is a matter left to local configuration in the tunnel initiator. The Tunnel-Assignment-ID AVP is of significance only to DIAMETER and the tunnel initiator. The ID it specifies is intended to be of only local use to DIAMETER and the tunnel initiator. The ID assigned by the tunnel initiator is not conveyed to the tunnel peer. This attribute MAY be included in the AA-Answer. The tunnel initiator receiving this attribute MAY choose to ignore it and assign the session to an arbitrary multiplexed or non-multiplexed tunnel between the desired endpoints. This attribute SHOULD also be included in the corresponding ADIF-Record in the Accounting- Request messages which pertain to a tunneled session. If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it should assign a session to a tunnel in the following manner: If this AVP is present and a tunnel exists between the specified endpoints with the specified ID, then the session should be assigned to that tunnel. If this AVP is present and no tunnel exists between the specified endpoints with the specified ID, then a new tunnel should be established for the session and the specified ID should be associated with the new tunnel. If this AVP is not present, then the session is assigned to an unnamed tunnel. If an unnamed tunnel does not yet exist between the specified endpoints then it is established and used Calhoun, Bulley expires April 2000 [Page 45]
INTERNET DRAFT October 1999 for this and subsequent sessions established without the Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT assign a session for which a Tunnel-Assignment-ID AVP was not specified to a named tunnel (i.e. one that was initiated by a session specifying this AVP). Note that the same ID may be used to name different tunnels if such tunnels are between different endpoints. AVP Format 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 Header (AVP Code = 82) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String This field must be present. The tunnel ID is represented by the String field. There is no restriction on the format of the ID. 3.41 Tunnel-Preference Description If more than one set of tunneling attributes is returned by the DIAMETER server to the tunnel initiator, this AVP SHOULD be included in each set to indicate the relative preference assigned to each tunnel. For example, suppose that AVPs describing two tunnels are returned by the server, one with a Tunnel-Type of PPTP and the other with a Tunnel-Type of L2TP. If the tunnel initiator supports only one of the Tunnel-Types returned, it will initiate a tunnel of that type. If, however, it supports both tunnel protocols, it SHOULD use the value of the Tunnel-Preference AVP to decide which tunnel should be started. The tunnel having the numerically lowest value in the Value field of this AVP SHOULD be given the highest preference. The values assigned to two or more Calhoun, Bulley expires April 2000 [Page 46]
INTERNET DRAFT October 1999 instances of the Tunnel-Preference AVP within a given AA-Answer message MAY be identical. In this case, the tunnel initiator SHOULD use locally configured metrics to decide which set of AVPs to use. This AVP MAY be included (as a hint to the server) in AA-Request messages, but the DIAMETER server is not required to honor this hint. AVP Format 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 Header (AVP Code = 83) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', and 'P' bits MUST NOT be set. Integer32 The Value field is three octets in length and indicates the preference to be given to the tunnel to which it refers; higher preference is given to lower values, with 0x000000 being most preferred and 0xFFFFFF least preferred. 3.42 Tunnel-Client-Auth-ID Description This AVP specifies the name used by the tunnel initiator during the authentication phase of tunnel establishment. The Tunnel- Client-Auth-ID AVP MAY be included (as a hint to the DIAMETER server) in the AA-Request message, and MUST be included in the AA-Request message if an authentication name other than the default is desired. This AVP SHOULD be included in the corresponding ADIF-Record of the Accounting-Request messages which pertain to a tunneled session. AVP Format Calhoun, Bulley expires April 2000 [Page 47]
INTERNET DRAFT October 1999 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 Header (AVP Code = 90) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits MUST NOT be set. String This field must be present. The String field contains the authentication name of the tunnel initiator. The authentication name SHOULD be represented in the UTF-8 charset. 3.43 Tunnel-Server-Auth-ID Description This AVP specifies the name used by the tunnel terminator during the authentication phase of tunnel establishment. The Tunnel- Client-Auth-ID AVP MAY be included (as a hint to the DIAMETER server) in the AA-Request message, and MUST be included in the AA-Request message if an authentication name other than the default is desired. This AVP SHOULD be included in the corresponding ADIF-Record of the Accounting-Request messages which pertain to a tunneled session. AVP Format 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 Header (AVP Code = 91) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' and 'T' bits MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V' and 'P' bits Calhoun, Bulley expires April 2000 [Page 48]
INTERNET DRAFT October 1999 MUST NOT be set. String This field must be present. The String field contains the authentication name of the tunnel terminator. The authentication name SHOULD be represented in the UTF-8 charset. 3.44 Filter-Rule Description This AVP provides filter rules that need to be configured on the NAS for the user. It is used in the AA-Answer message and can appear multiple times. AVP Format 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 Header (AVP Code = 300) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+ AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. String The String field MUST contain a filter rule in the following format: "permit (offset=value AND offset=value) OR offset=value" or "deny (offset=value AND offset=value) OR offset=value". The keyword "permit" means that the filter will allow any traffic that matches the rule, while deny will not allow the traffic to be routed. The filter rules can also use the keywords "AND" and "OR", for which no additional explanation is necessary. The braces "(" and ")" can be used to setup grouping of expressions. 3.45 Table of AVPs Calhoun, Bulley expires April 2000 [Page 49]
INTERNET DRAFT October 1999 The following table provides a guide to which attributes may be found in which kinds of messages, and in what quantity. Success Failed AA-Chal # AVP AA-Req AA-Answ AA-Answ Req 0-1 0-1 0 0 1 User-Name 0-1 0 0 0 2 User-Password [*1] 0-1 0 0 0 3 CHAP-Password [*1] 0-1 0 0 0 5 NAS-Port 0-1 0-1 0 0 6 Service-Type 0-1 0-1 0 0 7 Framed-Protocol 0-1 0-1 0 0 8 Framed-IP-Address 0-1 0-1 0 0 9 Framed-IP-Netmask 0 0-1 0 0 10 Framed-Routing 0 0+ 0 0 11 Filter-Id 0 0-1 0 0 12 Framed-MTU 0+ 0+ 0 0 13 Framed-Compression 0+ 0+ 0 0 14 Login-IP-Host 0 0-1 0 0 15 Login-Service 0 0-1 0 0 16 Login-TCP-Port 0 0+ 0+ 0+ 18 Reply-Message 0-1 0-1 0 0 19 Callback-Number 0 0-1 0 0 20 Callback-Id 0 0+ 0 0 22 Framed-Route 0 0-1 0 0 23 Framed-IPX-Network 0 0-1 0 0-1 28 Idle-Timeout 0-1 0 0 0 30 Called-Station-Id 0-1 0 0 0 31 Calling-Station-Id 0-1 0-1 0 0 34 Login-LAT-Service 0-1 0-1 0 0 35 Login-LAT-Node 0-1 0-1 0 0 36 Login-LAT-Group 0 0-1 0 0 37 Framed-AppleTalk-Link 0 0+ 0 0 38 Framed-AppleTalk-Net. 0 0-1 0 0 39 Framed-AppleTalk-Zone 0-1 0 0 0 60 CHAP-Challenge 0-1 0 0 0 61 NAS-Port-Type 0-1 0-1 0 0 62 Port-Limit 0-1 0-1 0 0 63 Login-LAT-Port 0+ 0+ 0 0 64 Tunnel-Type 0+ 0+ 0 0 65 Tunnel-Medium-Type 0+ 0+ 0 0 66 Tunnel-Client-Endpoint 0+ 0+ 0 0 67 Tunnel-Server-Endpoint 0+ 0+ 0 0 69 Tunnel-Password 0+ 0+ 0 0 81 Tunnel-Private-Group-ID 0+ 0+ 0 0 82 Tunnel-Assignment-ID 0+ 0+ 0 0 83 Tunnel-Preference 0+ 0+ 0 0 90 Tunnel-Client-Auth-ID 0+ 0+ 0 0 91 Tunnel-Server-Auth-ID Calhoun, Bulley expires April 2000 [Page 50]
INTERNET DRAFT October 1999 0 0+ 0 0 280 Filter-Rule Success Failed AA-Chal # AVP AA-Req AA-Answ AA-Answ Req [*1] An AA-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 message. 0+ Zero or more instances of this attribute MAY be present in message. 0-1 Zero or one instance of this attribute MAY be present in message. 1 Exactly one instance of this attribute MUST be present in message. 4.0 Protocol Definition This section will outline how the DIAMETER Authentication Extension can be used. 4.1 Feature Advertisement/Discovery As defined in [2], the Reboot-Ind and Device-Feature-Query messages can be used to inform a peer about locally supported DIAMETER Extensions. In order to advertise support of this extension, the Extension-Id AVP must be transmitted with a value of one (1). 4.2 Authorization Procedure This specification allows two different types of Authorization procedures. The first method is identical to the way RADIUS works today and requires the AA-Request to contain the UserName as well as either the Password or the CHAP-Password AVPs. The second method is used by NASes that send AA-Request whenever they receive an incoming call and want to get authorization from the DIAMETER Server to answer the call. In this case the AA-Request contains the NAS-IP-Address, the Calling-Station-Id and the Called- Station-Id AVPs. In this case the DIAMETER Server can lookup the combination of the Calhoun, Bulley expires April 2000 [Page 51]
INTERNET DRAFT October 1999 Calling-Station-Id and the Called-Station-Id in order to ensure that the pair are authorized as per the local policy. 4.3 Integration with Resource-Management Document [10] specifies the Resource-Token AVP that is used to carry information required for a DIAMETER server to rebuild its state information in the event of a crash or some other event that would cause the server to loose its state information. When creating the Resource-Token AVP, the following AVPs MUST be present, in addition to the AVPs listed in [10]; the UserName AVP, the NAS-IP- Address, the NAS-Port. Any additional AVP MAY be included if the AVP is a resource that is being managed (i.e. Framed-IP- Address in the case where the DIAMETER Server is allocating IP Addresses out of a centrally managed address pool). 5.0 References [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 [2] Calhoun, Rubens, "DIAMETER Base Protocol", draft-calhoun-diameter-08.txt, Work in Progress, August 1999. [3] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [5] Calhoun, Rubens, Aboba, "DIAMETER Extensible Authentication Protocol Extensions", draft-calhoun-diameter-eap-03.txt, Work in Progress, August 1999. [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996. [7] Jacobson, "Compressing TCP/IP headers for low-speed serial links", RFC 1144, February 1990. [8] ISO 8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. <URL:http://www.iso.ch/cate/d16338.html> [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol (MP)", RFC 1717, November 1994. [10] Calhoun, Greene, "DIAMETER Resource Management Extension", draft-calhoun-diameter-res-mgmt-02.txt, Work in Progress, February 1999. [11] Calhoun, Zorn, Pan, "DIAMETER Framework", draft-calhoun-diameter-framework-02.txt, Work in Progress, December 1998. Calhoun, Bulley expires April 2000 [Page 52]
INTERNET DRAFT October 1999 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [13] P. Calhoun, W. Bulley, "DIAMETER Proxy Server Extensions", draft-calhoun-diameter-proxy-02.txt, Work in Progress, August 1999. [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., Palter, B., "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, August 1999 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, February 1997 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 1996 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, August 1995 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 [24] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, October 1994 [17] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", RFC 2373, July 1998 6.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: Nancy Greene, Ryan Moats 7.0 Authors' Addresses Questions about this memo can be directed to: Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Calhoun, Bulley expires April 2000 [Page 53]
INTERNET DRAFT October 1999 Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com William Bulley Merit Network, Inc. 4251 Plymouth Road, Suite C Ann Arbor, Michigan, 48105-2785 USA Phone: 1-734-764-9993 Fax: 1-734-647-3185 E-mail: web@merit.edu 8.0 Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Calhoun, Bulley expires April 2000 [Page 54]