Diameter NASREQ Application. Status of this Memo. This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026.

Transcription

1 AAA Working Group Pat R. Calhoun Internet-Draft Black Storm Networks Category: Standards Track William Bulley <draft-ietf-aaa-diameter-nasreq-09.txt> Merit Network, Inc. Allan C. Rubens Tut Systems, Inc. Jeff Haag Glen Zorn Cisco Systems, Inc. David Spence Interlink Networks, Inc. March 2002 Diameter NASREQ Application Status of this Memo This document is an Internet-Draft and is subject to 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: The list of Internet-Draft Shadow Directories can be accessed at: This memo describes work in progress within the AAA Working Group. Comments are welcome and should be submitted to aaa-wg@merit.edu. Distribution of this memo is unlimited. Copyright (C) The Internet Society All Rights Reserved. Calhoun et al. expires September 2002 [Page 1]

2 Abstract This document describes the Diameter application that is used for AAA in a PPP/SLIP Dial-Up and Terminal Server Access environment. This application, combined with the base protocol, satisfies the requirements defined in the NASREQ AAA criteria specification and the ROAMOPS AAA Criteria specification. Given that it is expected that initial deployments of the Diameter protocol in a dial-up environment will include legacy systems, this application was carefully designed to ease the burden of servers that must perform protocol conversion between RADIUS and Diameter. This is achieved by re-using the RADIUS address space, eliminating the need to perform attribute lookups. Table of Contents 1.0 Introduction 1.1 Requirements language 1.2 Advertising application support 2.0 Supported AVPs 2.1 Diameter AVPs NAS-Filter-Rule AVP NAS-Session-Key AVP NAS-Key-Direction AVP NAS-Key-Type AVP NAS-Key-Data AVP NAS-Key-Binding AVP NAS-Key-Lifetime AVP NAS-IV AVP 2.2 Legacy RADIUS Attributes NAS-IP-Address AVP NAS-Identifier AVP State AVP 3.0 Legacy RADIUS Authentication Support 3.1 Command-Codes Values AA-Request (AAR) Command User-Password AVP CHAP-Auth AVP CHAP-Ident AVP CHAP-Algorithm AVP CHAP-Response AVP CHAP-Challenge AVP ARAP-Password AVP AA-Answer (AAA) Command ARAP-Challenge-Response AVP Password-Retry AVP Calhoun et al. expires September 2002 [Page 2]

3 Prompt AVP 3.2 Reply-Message AVP 4.0 Extensible Authentication Protocol Support 4.1 Alternative Uses 4.2 Command-Codes Values Diameter-EAP-Request (DER) Command Diameter-EAP-Answer (DEA) Command 4.3 EAP-Payload AVP 5.0 Diameter Session Termination 6.0 Call and Session Information 6.1 NAS-Port AVP 6.2 Filter-Id AVP 6.3 Callback-Number AVP 6.4 Callback-Id AVP 6.5 Idle-Timeout AVP 6.6 Called-Station-Id AVP 6.7 Calling-Station-Id AVP 6.8 NAS-Port-Type AVP 6.9 Port-Limit AVP 6.10 Connect-Info AVP 7.0 Service Specific Authorization AVPs 7.1 Service-Type AVP 7.2 Framed Access Authorization AVPs Framed-Protocol AVP Framed-Routing AVP Framed-MTU AVP Framed-Compression AVP IP Access Framed-IP-Address AVP Framed-IP-Netmask AVP Framed-IP-Route AVP Framed-Interface-Id AVP Framed-IPv6-Prefix AVP Framed-IPv6-Route AVP Framed-IPv6-Pool AVP IPX Access Framed-IPX-Network AVP Appletalk Access Framed-AppleTalk-Link AVP Framed-AppleTalk-Network AVP Framed-AppleTalk-Zone AVP ARAP Access ARAP-Features AVP ARAP-Zone-Access AVP ARAP-Security AVP ARAP-Security-Data AVP 7.3 Non-Framed Access Authorization AVPs Login-IP-Host AVP Calhoun et al. expires September 2002 [Page 3]

4 7.3.2 Login-Service AVP TCP Services Login-TCP-Port AVP LAT Services Login-LAT-Service AVP Login-LAT-Node AVP Login-LAT-Group AVP Login-LAT-Port AVP 7.4 Tunneling AVPs Tunnel-Type AVP Tunnel-Medium-Type AVP Tunnel-Client-Endpoint AVP Tunnel-Server-Endpoint AVP Tunnel-Password AVP Tunnel-Private-Group-ID AVP Tunnel-Assignment-ID AVP Tunnel-Preference AVP Tunnel-Client-Auth-ID AVP Tunnel-Server-Auth-ID AVP 8.0 Accounting Considerations 8.1 Accounting-Input-Octets AVP 8.2 Accounting-Output-Octets AVP 8.3 Acct-Session-Time AVP 8.4 Accounting-Input-Packets AVP 8.5 Accounting-Output-Packets AVP 8.6 Accounting-Authentication-Type AVP 8.7 Acct-Tunnel-Connection AVP 8.8 Acct-Tunnel-Packets-Lost AVP 8.9 Accounting-EAP-Auth-Method AVP 9.0 RADIUS/Diameter Protocol Interactions 9.1 RADIUS request forwarded as Diameter request 9.2 Diameter request forwarded as RADIUS request 10.0 AVP Occurrence Table 10.1 NASREQ Command AVP Table 10.2 Accounting AVP Table Framed Access Non-Framed Access 11.0 IANA Considerations 11.1 Command Codes 11.2 AVP Codes 11.3 Application Identifier 11.4 NAS-Key-Binding AVP Values 11.5 NAS-Key-Direction AVP Values 11.6 NAS-Key-Type AVP Values 11.7 CHAP-Algorithm AVP Values 12.0 Security Considerations 13.0 References 14.0 Acknowledgements Calhoun et al. expires September 2002 [Page 4]

5 15.0 Authors Addresses 16.0 Full Copyright Statement 1.0 Introduction This document describes the Diameter application that is used for AAA in a PPP/SLIP Dial-Up and Terminal Server Access environment. This application, combined with the base protocol [2], satisfies the requirements defined in the NASREQ AAA criteria specification [24] and the ROAMOPS AAA Criteria specification [4]. This document is divided into three main sections. The first section defines the Diameter Command-Codes and AVPs that are needed to support legacy authentication protocols, those that are typically supported by RADIUS [1] servers. The second section defines the Command-Codes and AVPs necessary for a Diameter node to support PPP s Extensible Authentication Protocol (EAP) [25]. The third section contains the Authorization AVPs that are needed for the various services offered by a NAS, such as PPP dial-in, terminal server and tunneling applications, such as L2TP [16]. Given that it is expected that initial deployments of the Diameter protocol in a dial-up environment will include legacy systems, this application was carefully designed to ease the burden of servers that must perform protocol conversion between RADIUS and Diameter. This is achieved by re-using the RADIUS address space, eliminating the need to perform attribute lookups. 1.1 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.2 Advertising application support Diameter nodes conforming to this specification MAY advertise support by including the value of one (1) in the Auth-Application-Id or the Acct-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [2]. 2.0 Supported AVPs This section lists all of the Diameter AVPs and the legacy RADIUS Calhoun et al. expires September 2002 [Page 5]

6 attributes supported by this application. 2.1 Diameter AVPs This section will define all of the AVPs that are not backward compatible with the RADIUS protocol [1]. A Diameter message that includes one of these AVPs MAY cause interoperability issues should the request traverse a AAA node that only supports the RADIUS protocol. However, the Diameter protocol should not be hampered from future developments due to the existing installed base. The following table describes the Diameter AVPs defined in the NASREQ application, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. Due to space constraints, the short form IPFiltrRule is used to represent IPFilterRule. Calhoun et al. expires September 2002 [Page 6]

7 AVP Flag rules AVP Section SHLD MUST MAY Attribute Name Code Defined Value Type MUST MAY NOT NOT Encr Accounting Unsigned64 M P V Y Input-Octets Accounting Unsigned64 M P V Y Input-Packets Accounting Unsigned64 M P V Y Output-Octets Accounting Unsigned64 M P V Y Output-Packets Accounting-EAP Enumerated M P V Y Auth-Method CHAP-Auth Grouped M P V Y CHAP-Algorithm Enumerated M P V Y CHAP-Ident OctetString M P V Y CHAP-Response OctetString M P V Y EAP-Payload OctetString M P V Y NAS-Filter-Rule IPFiltrRule M P V Y NAS-Key-Binding Enumerated M P V Y NAS-Key-Data OctetString M P V N NAS-Key Enumerated M P V N Direction NAS-Key-Type Enumerated M P V N NAS-Key-Lifetime Unsigned32 M P V N NAS-IV OctetString M P V N NAS-Session-Key Grouped M P V Y Tunneling Grouped M P V N NAS-Filter-Rule AVP The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule, and provides filter rules that need to be configured on the NAS for the user. One or more such AVPs MAY be present in an authorization response NAS-Session-Key AVP The NAS-Session-Key AVP (AVP Code 408) is of type Grouped, and contains a session key distributed from Diameter servers to clients. The keys MAY be used for integrity and/or confidentiality protection between the NAS and the user. The keys MAY be distributed to the user as part of an EAP authentication exchange. Its Data field has the Calhoun et al. expires September 2002 [Page 7]

8 following ABNF grammar: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key } { NAS-Key-Data } { NAS-Key-Binding } [ NAS-Key-Lifetime ] [ NAS-IV ] * [ AVP ] If strong authentication and confidentiality of the session keys is required, it is recommended that the CMS security application [13] be used to protect the NAS-Session-Key AVP. The NAS-Session-Key AVP MAY appear zero or more times in the AAA and DEA messages. When more than one NAS-Session-Key AVP is present in a message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST have different values. Otherwise, the AVPs would conflict with each other. If the optional NAS-Key-Lifetime AVP (see section 2.1.7, below) is not present, then the lifetime of the NAS-Session-Key AVP is found in the Authorization-Lifetime AVP. If a re-authorization request is received prior to the expiration of the lifetime, new keys will need to be established NAS-Key-Direction AVP The NAS-Key-Direction AVP (AVP Code 406) is of type Enumerated, and specifies the direction that the traffic is to be protected with the key. The following values are supported: BIDIRECTIONAL 1 The key is used in both directions UPLINK 2 The key is used for traffic from the user DOWNLINK 3 The key is used for traffic sent to user NAS-Key-Type AVP The NAS-Key-Type AVP (AVP Code 407) is of type Enumerated, and Calhoun et al. expires September 2002 [Page 8]

9 specifies how the key is to be used. The following values are supported: CIPHER_KEY 1 The key is used to encrypt data INTEGRITY_KEY 2 The key is used to authenticate the data MASTER_CIPHER_KEY 3 The master cipher is used to derive further cipher keys MASTER_INTEGRITY_KEY 4 The master integrity is used to derive further integrity keys MASTER_KEY 5 The master can be used to derive any type of keys, but is not guaranteed to be useful for any particular crypto system. Additional processing will be required, and is not specified in this document NAS-Key-Data AVP The NAS-Key-Data AVP (AVP Code 405) is of type OctetString and contains the session key to be used between the user and the access device NAS-Key-Binding AVP The NAS-Key-Binding AVP (AVP Code 404) is of type Enumerated, and specifies the purpose for the key. A Diameter client MAY include this AVP in a request to specify to the Diameter server the type of key it desires. Responses that include the NAS-Session-Key AVP MUST include this AVP which is used to specify the type of key found in the MAS- Key-Data AVP. The following values are supported: DES 1 The key created is used to secure links using DES 3DES 2 The key created is used to secure links using Triple DES RC The key created is used to secure links using RC4 using 40-bit keys Calhoun et al. expires September 2002 [Page 9]

10 RC The key created is used to secure links using RC4 with 128-bit keys NAS-Key-Lifetime AVP The NAS-Key-Lifetime AVP (AVP Code 413) is of type Unsigned32 and represents the period of time (in seconds) for which the session key is valid. The session key MUST NOT be used if the lifetime has expired; if the key lifetime expires while the session to which it applies is still active, either the session key MUST be changed or the or the session MUST be terminated NAS-IV AVP The NAS-IV AVP (AVP Code 414) is of type OctetString. Its contents MAY be used as an initialization vector (IV) by cryptographic algorithms (e.g., block ciphers). 2.2 Legacy RADIUS Attributes The Diameter protocol reserves the AVP Codes for "legacy RADIUS" support. The following table contains the RADIUS attributes supported by this Diameter application, their AVP code values, types, possible flag values and whether the AVP MAY be encrypted. RADIUS attributes not listed are not supported by the Diameter protocol. Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity. Calhoun et al. expires September 2002 [Page 10]

11 AVP Flag rules AVP Section SHLD MUST MAY Attribute Name Code Defined Value Type MUST MAY NOT NOT Encr Accounting Unsigned32 M P V Y Authentication-Type Acct-Session-Time Unsigned32 M P V Y Acct-Tunnel OctetString M P V Y Connection Acct-Tunnel Unsigned32 M P V Y Packets-Lost ARAP-Challenge OctetString M P V Y Response ARAP-Features OctetString M P V Y ARAP-Password OctetString M P V Y ARAP-Security Unsigned32 M P V Y ARAP-Security OctetString M P V Y Data ARAP-Zone-Access Enumerated M P V Y Callback-Id UTF8String M P V Y Callback-Number UTF8String M P V Y Called-Station-Id UTF8String M P V Y Calling-Station UTF8String M P V Y Id CHAP-Challenge OctetString M P V Y Connect-Info UTF8String M P V Y Filter-Id UTF8String M P V Y Framed-Appletalk Unsigned32 M P V Y Link Framed-Appletalk Unsigned32 M P V Y Network Framed-Appletalk OctetString M P V Y Zone Framed Enumerated M P V Y Compression Framed Unsigned64 M P V Y Interface-Id Framed-IPv6-Pool UTF8String M P V Y Framed-IPv IPAddress M P V Y Prefix Framed-IPv UTF8String M P V Y Route Framed-IP-Address IPAddress M P V Y Framed-IP-Netmask IPAddress M P V Y Framed-IP-Route UTF8String M P V Y Calhoun et al. expires September 2002 [Page 11]

12 AVP Flag rules AVP Section SHLD MUST MAY Attribute Name Code Defined Value Type MUST MAY NOT NOT Encr Framed-IPX UTF8String M P V Y Network Framed-MTU Unsigned32 M P V Y Framed-Protocol Enumerated M P V Y Framed-Routing Enumerated M P V Y Idle-Timeout Unsigned32 M P V Y Login-IP-Host IPAddress M P V Y Login-LAT-Group OctetString M P V Y Login-LAT-Node OctetString M P V Y Login-LAT-Port OctetString M P V Y Login-LAT-Service OctetString M P V Y Login-Service Enumerated M P V Y Login-TCP-Port Unsigned32 M P V Y NAS-Identifier UTF8String M P V Y NAS-IP-Address IPAddress M P V Y NAS-Port Unsigned32 M P V Y NAS-Port-Type Unsigned32 M P V Y Password-Retry Unsigned32 M P V Y Port-Limit Unsigned32 M P V Y Prompt Enumerated M P V Y Reply-Message UTF8String M P V Y Service-Type Enumerated M P V Y State OctetString M P V Y Tunnel OctetString M P V Y Assignment-Id Tunnel-Client Unsigned32 M P V Y Auth-ID Tunnel-Client UTF8String M P V Y Endpoint Tunnel-Medium Enumerated M P V Y Type Tunnel-Password OctetString M P V Y Tunnel-Preference Unsigned32 M P V Y Tunnel-Private UTF8String M P V Y Group-ID Tunnel-Server OctetString M P V Y Auth-ID Tunnel-Server UTF8String M P V Y Endpoint Tunnel-Type Enumerated M P V Y User-Password OctetString M P V Y Calhoun et al. expires September 2002 [Page 12]

13 The AVPs defined in this section SHOULD only used when a Diameter/RADIUS gateway function is invoked, and are not used in the Diameter protocol NAS-IP-Address AVP The NAS-IP-Address AVP (AVP Code 4) [1] is of type IPAddress, and contains the IP Address of the NAS providing service to the user. When this AVP is present, the Origin-Host AVP DOES NOT represent the NAS providing service to the user. Note that this AVP SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 9.0) NAS-Identifier AVP The NAS-Identifier AVP (AVP Code 32) [1] is of type UTF8String and contains the identity of the NAS providing service to the user. When this AVP is present, the Origin-Host AVP DOES NOT represent the NAS providing service to the user. Note that this AVP SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 9.0). This AVP may only be used in AAR and DER messages State AVP The State AVP (AVP Code 24) is of type OctetString and is used to transmit the contents of the RADIUS State attribute, and no interpretation of the contents should be made. Note that this AVP SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 9.0). 3.0 Legacy RADIUS Authentication Support This section defines the new Command-Code [2] values required to support the legacy authentication protocols (i.e. PAP, CHAP), as well as the AVPs that are necessary to carry the authentication information in the Diameter protocol. The functionality defined here provides a RADIUS-like AAA service, over a more reliable and secure transport, as defined in the base protocol [2]. Unlike the RADIUS protocol [1], the Diameter protocol does not require authentication information to be contained in a request from the client. Therefore, it is possible to send a request for authorization only. The type of service depends upon the Auth- Request-Type AVP. This difference MAY cause operational issues in environments that need RADIUS interoperability, and it MAY be Calhoun et al. expires September 2002 [Page 13]

14 necessary that protocol conversion gateways add some authentication information when transmitting to a RADIUS server. The Diameter protocol allows for users to be periodically reauthenticated and/or re-authorized. In such instances, the Session-Id AVP in the AAR message MUST be the same as the one present in the original authentication/authorization message. A Diameter server informs the NAS of the maximum time allowed before re-authentication or re-authorization via the Authorization-Lifetime AVP [1]. Note, however, that the Authorization-Lifetime AVP SHOULD NOT be used if the AAR or DER message contained a NAS-IP-Address or NAS-Identifier AVP since this would mean that the NAS is using RADIUS which does not support re-authentication or re-authorization. A NAS MUST re-authenticate and/or authorize after the period provided by the server. Furthermore, it is possible for Diameter servers to issue an unsolicited re-authentication and/or re-authorization by issuing an Re-Auth-Request message to the NAS. Upon receipt of such a message, the NAS is instructed to issue a request to re-authenticate and/or re-authorize the client. 3.1 Command-Codes Values This section defines new Command-Code [2] values that MUST be supported by all Diameter implementations that conform to this specification. The following Command Codes are defined in this section: Command-Name Abbrev. Code Reference AA-Answer AAA AA-Request AAR AA-Request (AAR) Command The AA-Request message (AAR), indicated by the Command-Code field set to 265 and the R bit set in the Command Flags field, is used in order to request authentication and/or authorization for a given PPP user. The type of request is identified through the Auth-Request-Type AVP, and the default mode is both authentication and authorization. If Authentication is requested the User-Name attribute SHOULD be present, as well as any additional authentication AVPs that would carry the password information. A request for authorization only SHOULD include the information from which the authorization will be performed, such as the User-Name, Called-Station-Id, or Calling- Calhoun et al. expires September 2002 [Page 14]

15 Station-Id AVPs. Certain networks MAY use different AVPs for authorization purposes. A request for authorization will include some AVPs defined in sections 2.0, 6.0 and 7.0. It is possible for a single session to be authorized first, then followed by an authentication request. However, the inverse SHOULD NOT be permitted. This AA-Request message MAY be the result of a multi-round authentication exchange, which occurs when the AAA is received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent AAR message SHOULD be sent, with the User-Password AVP that includes the user s response to the prompt, and MUST include any State AVPs that were present in the AAA. Message Format <AA-Request> ::= < Diameter Header: 265, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } [ NAS-Port ] [ Origin-State-Id ] [ Destination-Host ] [ NAS-IP-Address ] [ NAS-Identifier ] [ NAS-Port-Type ] [ Port-Limit ] [ User-Name ] [ User-Password ] [ Service-Type ] [ Idle-Timeout ] [ State ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Session-Timeout ] [ NAS-Key-Binding ] [ Callback-Number ] [ Called-Station-Id ] [ Calling-Station-Id ] [ Connect-Info ] [ CHAP-Auth ] [ CHAP-Challenge ] * [ Framed-Compression ] Calhoun et al. expires September 2002 [Page 15]

16 [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] [ Framed-MTU ] [ Framed-Protocol ] [ ARAP-Password ] [ ARAP-Security ] * [ ARAP-Security-Data ] * [ Login-IP-Host ] [ Login-LAT-Group ] [ Login-LAT-Node ] [ Login-LAT-Port ] [ Login-LAT-Service ] * [ Tunneling ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] User-Password AVP The User-Password AVP (AVP Code 2) is of type OctetString and contains the password of the user to be authenticated, or the user s input in a multi-round authentication exchange. The User-Password AVP MUST be encrypted using the methods described in [13], or where [13] isn t applied, the whole DIAMETER message flow MUST be encrypted using IPsec and/or TLS as described in [2]. Unless this AVP is used for one-time passwords, the User-Password AVP SHOULD NOT be used in non-trusted proxy environments. The clear-text password (prior to encryption) MUST NOT be longer than 128 bytes in length CHAP-Auth AVP The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains the information necessary to authenticate a user using the PPP Challenge- Handshake Authentication Protocol (CHAP) [6]. If the CHAP-Auth AVP is found in a message, the CHAP-Challenge AVP (see section ) MUST be present as well. The AVP containing the CHAP response depends upon the value of the CHAP-Algorithm AVP (see section for more info). Its Data field has the following ABNF grammar: CHAP-Auth ::= < AVP Header: 409 > { CHAP-Algorithm } Calhoun et al. expires September 2002 [Page 16]

17 { CHAP-Ident } [ CHAP-Response ] * [ AVP ] CHAP-Ident AVP The CHAP-Ident AVP (AVP Code 410) is of type OctetString and contains the one octet CHAP Identifier used in the computation of the CHAP response [6] CHAP-Algorithm AVP The CHAP-Algorithm AVP (AVP Code 412) is of type Enumerated and contains the algorithm identifier used in the computation of the CHAP response [6]. The following values are currently supported: CHAP with MD5 5 The CHAP response is computed using the procedure described in [6]. The CHAP-Response AVP MUST be present in the CHAP-Auth AVP CHAP-Response AVP The CHAP-Response AVP (AVP Code 411) is of type OctetString and contains the 16 octet authentication data provided by the user in response to the CHAP challenge [16]. The actual computation of the CHAP response can be found in [6] CHAP-Challenge AVP The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and contains the CHAP Challenge sent by the NAS to a PPP Challenge- Handshake Authentication Protocol (CHAP) [6] user ARAP-Password AVP The ARAP-Password AVP (AVP Code 70) is of type OctetString and is only present when the Framed-Protocol AVP (see Section 7.2.1) is included in the message and is set to ARAP. This AVP MUST NOT be present if either the User-Password or the CHAP-Auth AVP is present. See [32] for more information on the contents of this AVP. Calhoun et al. expires September 2002 [Page 17]

18 3.1.2 AA-Answer (AAA) Command The AA-Answer (AAA) message, indicated by the Command-Code field set to 265 and the R bit cleared in the Command Flags field, is sent in response to the AA-Request message. If authorization was requested, a successful response will include the authorization AVPs appropriate for the service being provided, as defined in section 2.0, 6.0 and 7.0 For authentication exchanges that require more than a single round trip, the server MUST set the Result-Code AVP to DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY include one or more Reply-Message and MAY include zero or one State AVPs. When possible, authentication mechanisms that include more than a single authentication round trip SHOULD use EAP (see section 4.0) If the Reply-Message AVP was present, the access device SHOULD display the text message to the user, and MUST prompt the user for a response. If the access device is unable to prompt the user for a new response, which could be achieved via PAP, it MUST treat this answer as an error, and deny access. Message Format <AA-Answer> ::= < Diameter Header: 265, PXY > < Session-Id > { Auth-Application-Id } { Auth-Request-Type } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Service-Type ] [ Error-Message ] [ Error-Reporting-Host ] [ Idle-Timeout ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Re-Auth-Request-Type ] [ Session-Timeout ] [ State ] * [ Reply-Message ] [ Origin-State-Id ] * [ Filter-Id ] * [ NAS-Session-Key ] [ Password-Retry ] Calhoun et al. expires September 2002 [Page 18]

19 [ Port-Limit ] [ Prompt ] [ ARAP-Challenge-Response ] [ ARAP-Features ] [ ARAP-Security ] * [ ARAP-Security-Data ] [ ARAP-Zone-Access ] [ Callback-Id ] [ Callback-Number ] [ Framed-Appletalk-Link ] * [ Framed-Appletalk-Network ] [ Framed-Appletalk-Zone ] * [ Framed-Compression ] [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IPv6-Pool ] * [ Framed-IPv6-Route ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] * [ Framed-IP-Route ] [ Framed-IPX-Network ] [ Framed-MTU ] [ Framed-Protocol ] [ Framed-Routing ] * [ Login-IP-Host ] [ Login-LAT-Group ] [ Login-LAT-Node ] [ Login-LAT-Port ] [ Login-LAT-Service ] [ Login-Service ] [ Login-TCP-Port ] * [ NAS-Filter-Rule ] * [ Tunneling ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ AVP ] ARAP-Challenge-Response AVP The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString and is only present when the Framed-Protocol AVP (see Section 7.2.1) is included in the message and is set to ARAP. This AVP contains an 8 octet response to the dial-in client s challenge. The RADIUS server calculates this value by taking the dial-in client s challenge from the high order 8 octets of the ARAP-Password AVP and performing DES Calhoun et al. expires September 2002 [Page 19]

20 encryption on this value with the authenticating user s password as the key. If the user s password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key Password-Retry AVP The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be included in the AA-Answer if the Result-Code indicates an authentication failure. The value of this AVP indicates how many authentication attempts a user may be permitted before being disconnected. This AVP is primarily intended for use when the Framed- Protocol AVP (see Section 7.2.1) is set to ARAP Prompt AVP The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be present in the AA-Answer message. When present, it is used by the NAS to determine whether the user s response, when entered, should be echoed. The supported values are listed in [33]. 3.2 Reply-Message AVP The Reply-Message AVP (AVP Code 18) is of type UTF8String, and contains 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. The Reply-Message AVP MAY indicate a dialog message to prompt the user before another AA-Request attempt. When used in an AA-Answer, 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. 4.0 Extensible Authentication Protocol Support The Extensible Authentication Protocol (EAP), described in [25], provides a standard mechanism for support of extensible authentication methods. Through the use of EAP, support for a number Calhoun et al. expires September 2002 [Page 20]

21 of authentication schemes may be added, including smart and token cards, Kerberos, Public Key, One Time Passwords, and others. This section describes the Command-Codes values and AVPs that are required for an EAP payload to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides for mutual (bi-directional) authentication, which is not possible with PAP and CHAP in a roaming PPP environment. The EAP conversation between the authenticating peer and the access device begins with the initiation of EAP within a link layer, such as PPP or 802.1x. Once EAP has been initiated, the access device will typically send to the Diameter server a Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number and the identity of the access device (e.g. Origin-Host or NAS- Identifier) MUST be included in the Diameter-EAP-Request message. If the Diameter home server supports EAP, it MUST respond with a Diameter-EAP-Answer message containing an EAP-Payload AVP that includes an encapsulated EAP payload [25], and the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent request is expected. The EAP payload is forwarded by the access device to the EAP client. The initial Diameter-EAP-Answer in a multi-round exchange normally includes an EAP-Request/Identity, requesting the EAP client to identify itself. Upon receipt of the EAP client s EAP-Response [25], the access device will then issue a second Diameter-EAP-Request message, with the client s EAP payload encapsulated within the EAP- Payload AVP. A preferred approach is for the access device to issue the EAP- Request/Identity message to the EAP client, and forward the EAP- Response/Identity packet, encapsulated within the EAP-Payload AVP, as a Diameter-EAP-Request to the Diameter server. This alternative reduces the number of Diameter message round trips, and is compatible with roaming environments, since the Destination-Realm is needed by Diameter agents for routing purposes. Note that this alternative cannot be universally employed, as there are circumstances where a user s identity is not needed (such as when authorization occurs based on a calling or called phone number). The conversation continues until the Diameter server sends a Diameter-EAP-Answer with a Result-Code AVP indicating success or failure, and an optional EAP-Payload. The Result-Code AVP is used by Calhoun et al. expires September 2002 [Page 21]

22 the access device to determine whether service is to be provided to the EAP client. The access device MUST NOT rely on the contents of the optional EAP-Payload to determine whether service is to be provided. A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- Success or EAP-Failure MUST NOT have the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. If authorization was requested, a successful Diameter-EAP-Answer MUST also include the appropriate authorization AVPs required for the service requested (see sections 2.0, 6.0 and 7.0). Diameter-EAP- Answer messages whose Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user s identity. Therefore, the Diameter Server SHOULD return the user s identity by inserting it in the User-Name attribute of subsequent Diameter-EAP-Answer packets. Without the user s identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this MAY be very difficult to manage. A home Diameter server MAY request EAP re-authentication by issuing the Re-Auth-Request [2] message to the Diameter client. Should an EAP authentication session be interrupted due to a home server failure, the session MAY be directed to an alternate server, but the authentication session will have to be restarted from the beginning. If a response is received with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the Diameter server in the home realm does not support EAP. If possible, the access device MAY attempt to negotiate another authentication protocol, such as PAP or CHAP. An access device SHOULD be cautious when determining whether a less secure authentication protocol will be used, since this could be a result of a bidding down attack. 4.1 Alternative uses Currently the conversation between the backend authentication server and the Diameter server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Diameter vendors and backend security vendors, it is recommended that Diameter-encapsulated EAP be used for this conversation. Calhoun et al. expires September 2002 [Page 22]

23 This has the advantage of allowing the Diameter server to support EAP without the need for authentication-specific code within the Diameter server. Authentication-specific code can then reside on a backend authentication server instead. In the case where Diameter-encapsulated EAP is used in a conversation between a Diameter server and a backend authentication server, the latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- Success message without inclusion of the expected authorization AVPs required in a successful response. This means that the Diameter server MUST add these attributes prior to sending an Diameter-EAP- Answer/EAP-Payload/EAP-Success message to the access device. 4.2 Command-Codes Values This section defines new Command-Code [2] values that MUST be supported by all Diameter implementations conforming to this specification. The following Command Codes are defined in this section: Command-Name Abbrev. Code Reference Diameter-EAP-Answer DEA Diameter-EAP-Request DER Diameter-EAP-Request (DER) Command The Diameter-EAP-Request (DER) command, indicated by the Command-Code field set to 268 and the R bit set in the Command Flags field, is sent by a Diameter client to a Diameter server and conveys an EAP- Response [25] from the EAP client. The Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains the actual EAP payload. An EAP-Payload AVP with no data MAY be sent to the Diameter server to initiate an EAP authentication session. The DER message MAY be the result of a multi-round authentication exchange, which occurs when the DEA is received with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST include any State AVPs that were present in the DEA. For reauthentication, it is recommended that the Identity request be skipped in order to reduce the number of authentication round trips. This is only possible when the user s identity is already known by the home Diameter server. Calhoun et al. expires September 2002 [Page 23]

24 Message Format <Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY > < Session-Id > { Auth-Application-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Request-Type } { EAP-Payload } [ NAS-Port ] [ Destination-Host ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Session-Timeout ] [ User-Name ] [ Service-Type ] [ Idle-Timeout ] [ NAS-IP-Address ] [ NAS-Identifier ] [ NAS-Port-Type ] [ Port-Limit ] [ State ] [ Origin-State-Id ] [ NAS-Key-Binding ] [ Callback-Number ] [ Called-Station-Id ] [ Calling-Station-Id ] [ Connect-Info ] * [ Framed-Compression ] [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] [ Framed-MTU ] [ Framed-Protocol ] * [ Tunneling ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] Diameter-EAP-Answer (DEA) Command The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code field set to 268 and the R bit cleared in the Command Flags field, is sent by the Diameter server to the client for one of the following Calhoun et al. expires September 2002 [Page 24]

25 reasons: 1) The message is part of a multi-round authentication exchange, and the server is expecting a subsequent Diameter-EAP-Request. This is indicated by setting the Result-Code to DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State AVPs. 2) the EAP client has been successfully authenticated and authorized, in which case the message MUST include the Result- Code AVP indicating success, and SHOULD include an EAP-Payload of type EAP-Success. This event MUST cause the access device to provide service to the EAP client. 3) The EAP client has not been successfully authenticated and/or authorized, and the Result-Code AVP is set to indicate failure. This message SHOULD include an EAP-Payload, but this AVP is not used to determine whether service is to be provided. If the message from the Diameter client included a request for authorization, a successful response MUST include the authorization AVPs that are relevant to the service being provided. Message Format <Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY > < Session-Id > { Auth-Application-Id } { Result-Code } { Origin-Host } { Origin-Realm } { Auth-Request-Type } [ Error-Reporting-Host ] [ EAP-Payload ] [ User-Name ] [ Service-Type ] [ Idle-Timeout ] [ Authorization-Lifetime ] [ Auth-Grace-Period ] [ Auth-Session-State ] [ Re-Auth-Request-Type ] [ Session-Timeout ] [ State ] [ Origin-State-Id ] * [ Filter-ID ] * [ NAS-Session-Key ] [ Callback-Id ] [ Callback-Number ] [ Framed-Appletalk-Link ] * [ Framed-Appletalk-Network ] Calhoun et al. expires September 2002 [Page 25]

26 [ Framed-Appletalk-Zone ] * [ Framed-Compression ] [ Framed-Interface-Id ] * [ Framed-IPv6-Prefix ] [ Framed-IPv6-Pool ] * [ Framed-IPv6-Route ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] * [ Framed-IP-Route ] [ Framed-IPX-Network ] [ Framed-MTU ] [ Framed-Protocol ] [ Framed-Routing ] * [ NAS-Filter-Rule ] * [ Tunneling ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] [ Port-Limit ] * [ Proxy-Info ] * [ AVP ] 4.3 EAP-Payload AVP The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used to encapsulate the actual EAP payload [25] that is being exchanged between the EAP client and the home Diameter server. 5.0 Diameter Session Termination When a Network Access Server (NAS) receives an indication that a user s session is being disconnected (e.g. LCP Terminate is received), the NAS MUST issue a Session-Termination-Request (STR) [2] to its Diameter Server. This will ensure that any resources maintained on the servers is freed appropriately. Further, a NAS that receives a Abort-Session-Request (ASR) [2] MUST issue an STR if the session requested is active, and disconnect the PPP (or tunneling) session. 6.0 Call and Session Information This section contains the authorization AVPs that are needed to identify call and session information, and allows the server to set constraints on a session. Calhoun et al. expires September 2002 [Page 26]

27 6.1 NAS-Port AVP The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the physical port number of the NAS which is authenticating the user, and is normally only present in an authentication and/or authorization request. 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 (AVP Code 61) or both SHOULD be present in the request, if the NAS differentiates among its ports. 6.2 Filter-Id AVP The Filter-Id AVP (AVP Code 11) is of type UTF8String, and contains the name of the filter list for this user. Zero or more Filter-Id AVPs MAY be sent in an authorization answer. 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. In non-radius environments, it is RECOMMENDED that the NAS-Filter- Rule AVP be used instead. 6.3 Callback-Number AVP The Callback-Number AVP (AVP Code 19) is of type UTF8String, and contains a dialing string to be used for callback. It MAY be used in an authentication and/or authorization request as a hint to the server that a Callback service is desired, but the server is not required to honor the hint in the corresponding response. The codification of the range of allowed usage of this field is outside the scope of this specification. 6.4 Callback-Id AVP The Callback-Id AVP (AVP Code 20) is of type UTF8String, and contains the name of a place to be called, to be interpreted by the NAS. This AVP MAY be present in an authentication and/or authorization response. 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. Calhoun et al. expires September 2002 [Page 27]

28 6.5 Idle-Timeout AVP The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. It MAY be used in an authentication and/or authorization request (or challenge) as a hint to the server that an idle timeout is desired, but the server is not required to honor the hint in the corresponding response. 6.6 Called-Station-Id AVP The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and allows the NAS to send in the request the phone number that the user called, using Dialed Number Identification (DNIS) or a similar technology. Note that this may be different from the phone number the call comes in on. It SHOULD only be present in authentication and/or authorization requests. If the Auth-Request-Type AVP is set to authorization-only and the User-Name AVP is absent, the Diameter Server MAY 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. The codification of the range of allowed usage of this field is outside the scope of this specification. 6.7 Calling-Station-Id AVP The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and allows the NAS to send in the request the phone number that the call came from, using Automatic Number Identification (ANI) or a similar technology. It SHOULD only be present in authentication and/or authorization requests. If the Auth-Request-Type AVP is set to authorization-only and the User-Name AVP is absent, the Diameter Server MAY 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. The codification of the range of allowed usage of this field is outside the scope of this specification. 6.8 NAS-Port-Type AVP Calhoun et al. expires September 2002 [Page 28]

29 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and contains 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) AVP. This AVP SHOULD only be used in authentication and/or authorization requests. This AVP MAY be combined with the NAS- Port AVP to assist in differentiating its ports. The supported values are defined in [33]. 6.9 Port-Limit AVP The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the maximum number of ports to be provided to the user by the NAS. It MAY be used in an authentication and/or authorization request as a hint to the server that multilink PPP [9] service is desired, but the server is not required to honor the hint in the corresponding response Connect-Info AVP The Connect-Info AVP (AVP Code 77) is of type UTF8String, and is sent in the AA-Request message, and indicates the nature of the user s connection. The connection speed SHOULD be included at the beginning of the first Connect-Info AVP in the message. If the transmit and receive connection speeds differ, they may both be included in the first AVP with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information. 7.0 Service Specific Authorization AVPs This section contains the RADIUS authorization AVPs that are supported in the Diameter protocol. The Service-Type AVP SHOULD be present in all messages, and based on the value of the Service-Type AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be present. 7.1 Service-Type AVP The Service-Type AVP (AVP Code 6) is of type Enumerated and contains the type of service the user has requested, or the type of service to be provided. One such AVP MAY be present in an authentication and/or authorization request or response. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Calhoun et al. expires September 2002 [Page 29]

30 Service-Types as though a response with a Result-Code other than Diameter-SUCCESS had been received instead. When used in a request, the Service-Type AVP SHOULD be considered to be a hint to the 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. The following values have been defined for the Service-Type AVP: The complete list of defined values can be found in [1] and [33]. The following values are extracted from [1], and are listed here since they are further qualified: Login 1 The user should be connected to a host. The message MAY include additional AVPs defined in section 7.3. Framed 2 A Framed Protocol should be started for the User, such as PPP or SLIP. The message MAY include additional AVPs defined in section 7.2, or 7.4 for tunneling services. Callback Login 3 The user should be disconnected and called back, then connected to a host. The message MAY include additional AVPs defined in section 7.3. Callback Framed 4 The user should be disconnected and called back, then a Framed Protocol should be started for the User, such as PPP or SLIP. The message MAY include additional AVPs defined in section 7.2, or 7.4 for tunneling services. 7.2 Framed Access Authorization AVPs This section contains the authorization AVPs that are necessary to support framed access, such as PPP, SLIP, etc. AVPs defined in this section MAY be present in a message if the Service-Type AVP was set to "Framed" or "Callback Framed" Framed-Protocol AVP The Framed-Protocol AVP (AVP Code 7) is of type Enumerated and contains the framing to be used for framed access. This AVP MAY be present in both requests and responses. The supported values are listed in [33]. Calhoun et al. expires September 2002 [Page 30]

31 7.2.2 Framed-Routing AVP The Framed-Routing AVP (AVP Code 10) is of type Enumerated and contains the routing method for the user, when the user is a router to a network. This AVP SHOULD only be present in authorization responses. The supported values are listed in [33] Framed-MTU AVP The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). This AVP SHOULD only be present in authorization responses. The MTU value MUST be between the range of 64 and Framed-Compression AVP The Framed-Compression AVP (AVP Code 13) is of type Enumerated and contains the compression protocol to be used for the link. It MAY be used in an authorization request as a hint to the server that a specific compression type is desired, but the server is not required to honor the hint in the corresponding response. 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. The supported values are listed in [33] IP Access The AVPs defined in this section are used when the user requests, or is being granted, access to IP. They are only present if the Framed- Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf proprietarysinglelink/multilink protocol, or X.75 Synchronous Framed-IP-Address AVP The Framed-IP-Address AVP (AVP Code 8) is of type IPAddress and contains the address to be configured for the user. It MAY be used in an authorization request as a hint to the server that a specific address is desired, but the server is not required to honor the hint in the corresponding response. Calhoun et al. expires September 2002 [Page 31]