idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 59 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 60 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 30 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 543 has weird spacing: '... of the conte...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 2421, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2433, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2446, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2459, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2466, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2469, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2472, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2474, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2477, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2480, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2483, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 2491, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 2494, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2497, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 2500, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2503, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2507, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2521, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2523, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2526, but no explicit reference was found in the text == Unused Reference: '39' is defined on line 2532, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-08 ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') ** Obsolete normative reference: RFC 2373 (ref. '5') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '11') == Outdated reference: A later version (-04) exists of draft-ietf-aaa-diameter-cms-sec-03 -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '17') ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') ** Downref: Normative reference to an Informational RFC: RFC 3169 (ref. '24') ** Obsolete normative reference: RFC 2284 (ref. '25') (Obsoleted by RFC 3748) ** Downref: Normative reference to an Informational RFC: RFC 3078 (ref. '26') ** Obsolete normative reference: RFC 2434 (ref. '27') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2867, mentioned in '28', was also mentioned in '11'. ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '28') ** Obsolete normative reference: RFC 2279 (ref. '29') (Obsoleted by RFC 3629) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-08 ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '31') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '32') -- Duplicate reference: RFC2868, mentioned in '33', was also mentioned in '31'. ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '33') -- Possible downref: Non-RFC (?) normative reference: ref. '34' ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '35') ** Obsolete normative reference: RFC 2402 (ref. '37') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. '39' Summary: 29 errors (**), 0 flaws (~~), 32 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track William Bulley 5 Merit Network, Inc. 6 Allan C. Rubens 7 Tut Systems, Inc. 8 Jeff Haag 9 Glen Zorn 10 Cisco Systems, Inc. 11 November 2001 13 Diameter NASREQ Application 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 This document is an individual contribution for consideration by the 37 AAA Working Group of the Internet Engineering Task Force. Comments 38 should be submitted to the diameter@diameter.org mailing list. 40 Distribution of this memo is unlimited. 42 Copyright (C) The Internet Society 2001. All Rights Reserved. 44 Abstract 46 This document describes the Diameter application that is used for AAA 47 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 48 application, combined with the base protocol, satisfies the 49 requirements defined in the NASREQ AAA criteria specification and the 50 ROAMOPS AAA Criteria specification. 52 Given that it is expected that initial deployments of the Diameter 53 protocol in a dial-up environment will include legacy systems, this 54 application was carefully designed to ease the burden of servers that 55 must perform protocol conversion between RADIUS and Diameter. This 56 is achieved by re-using the RADIUS address space, eliminating the 57 need to perform attribute lookups. 59 Table of Contents 61 1.0 Introduction 62 1.1 Requirements language 63 1.2 Advertising application support 64 2.0 Supported AVPs 65 2.1 Diameter AVPs 66 2.1.1 NAS-Filter-Rule AVP 67 2.1.2 NAS-Session-Key AVP 68 2.1.3 NAS-Key-Direction AVP 69 2.1.4 NAS-Key-Type AVP 70 2.1.5 NAS-Key-Data AVP 71 2.1.6 NAS-Key-Binding AVP 72 2.1.7 NAS-Key-Lifetime AVP 73 2.1.8 NAS-IV AVP 74 2.2 Legacy RADIUS Attributes 75 2.2.1 NAS-IP-Address AVP 76 2.2.2 NAS-Identifier AVP 77 2.2.3 State AVP 78 3.0 Legacy RADIUS Authentication Support 79 3.1 Command-Codes Values 80 3.1.1 AA-Request (AAR) Command 81 3.1.1.1 User-Password AVP 82 3.1.1.2 CHAP-Auth AVP 83 3.1.1.3 CHAP-Ident AVP 84 3.1.1.4 CHAP-Algorithm AVP 85 3.1.1.5 CHAP-Response AVP 86 3.1.1.6 CHAP-Challenge AVP 87 3.1.1.7 ARAP-Password AVP 88 3.1.2 AA-Answer (AAA) Command 89 3.1.2.1 ARAP-Challenge-Response AVP 90 3.1.2.2 Password-Retry AVP 91 3.1.2.3 Prompt AVP 92 3.2 Reply-Message AVP 93 4.0 Extensible Authentication Protocol Support 94 4.1 Alternative Uses 95 4.2 Command-Codes Values 96 4.2.1 Diameter-EAP-Request (DER) Command 97 4.2.2 Diameter-EAP-Answer (DEA) Command 98 4.3 EAP-Payload AVP 99 5.0 Diameter Session Termination 100 6.0 Call and Session Information 101 6.1 NAS-Port AVP 102 6.2 Filter-Id AVP 103 6.3 Callback-Number AVP 104 6.4 Callback-Id AVP 105 6.5 Idle-Timeout AVP 106 6.6 Called-Station-Id AVP 107 6.7 Calling-Station-Id AVP 108 6.8 NAS-Port-Type AVP 109 6.9 Port-Limit AVP 110 6.10 Connect-Info AVP 111 7.0 Service Specific Authorization AVPs 112 7.1 Service-Type AVP 113 7.2 Framed Access Authorization AVPs 114 7.2.1 Framed-Protocol AVP 115 7.2.2 Framed-Routing AVP 116 7.2.3 Framed-MTU AVP 117 7.2.4 Framed-Compression AVP 118 7.2.5 IP Access 119 7.2.5.1 Framed-IP-Address AVP 120 7.2.5.2 Framed-IP-Netmask AVP 121 7.2.5.3 Framed-IP-Route AVP 122 7.2.5.4 Framed-Interface-Id AVP 123 7.2.5.5 Framed-IPv6-Prefix AVP 124 7.2.5.6 Framed-IPv6-Route AVP 125 7.2.5.7 Framed-IPv6-Pool AVP 126 7.2.6 IPX Access 127 7.2.6.1 Framed-IPX-Network AVP 128 7.2.7 Appletalk Access 129 7.2.7.1 Framed-AppleTalk-Link AVP 130 7.2.7.2 Framed-AppleTalk-Network AVP 131 7.2.7.3 Framed-AppleTalk-Zone AVP 132 7.2.8 ARAP Access 133 7.2.8.1 ARAP-Features AVP 134 7.2.8.2 ARAP-Zone-Access AVP 135 7.2.8.3 ARAP-Security AVP 136 7.2.8.4 ARAP-Security-Data AVP 137 7.3 Non-Framed Access Authorization AVPs 138 7.3.1 Login-IP-Host AVP 139 7.3.2 Login-Service AVP 140 7.3.3 TCP Services 141 7.3.3.1 Login-TCP-Port AVP 142 7.3.4 LAT Services 143 7.3.4.1 Login-LAT-Service AVP 144 7.3.4.2 Login-LAT-Node AVP 145 7.3.4.3 Login-LAT-Group AVP 146 7.3.4.4 Login-LAT-Port AVP 147 7.4 Tunneling AVP 148 7.4.1 Tunnel-Type AVP 149 7.4.2 Tunnel-Medium-Type AVP 150 7.4.3 Tunnel-Client-Endpoint AVP 151 7.4.4 Tunnel-Server-Endpoint AVP 152 7.4.5 Tunnel-Password AVP 153 7.4.6 Tunnel-Private-Group-ID AVP 154 7.4.7 Tunnel-Assignment-ID AVP 155 7.4.8 Tunnel-Preference AVP 156 7.4.9 Tunnel-Client-Auth-ID AVP 157 7.4.10 Tunnel-Server-Auth-ID AVP 158 8.0 Accounting Considerations 159 8.1 Accounting-Input-Extended-Octets AVP 160 8.2 Accounting-Output-Extended-Octets AVP 161 8.3 Accounting-Session-Time AVP 162 8.4 Accounting-Input-Extended-Packets AVP 163 8.5 Accounting-Output-Extended-Packets AVP 164 8.6 Accounting-Authentication-Type AVP 165 8.7 Acct-Tunnel-Connection AVP 166 8.8 Acct-Tunnel-Packets-Lost AVP 167 8.9 Accounting-EAP-Auth-Method AVP 168 9.0 RADIUS/Diameter Protocol Interactions 169 9.1 RADIUS request forwarded as Diameter request 170 9.2 Diameter request forwarded as RADIUS request 171 10.0 AVP Occurrence Table 172 10.1 NASREQ Command AVP Table 173 10.2 Accounting AVP Table 174 10.2.1 Framed Access 175 10.2.2 Non-Framed Access 176 11.0 IANA Considerations 177 11.1 Command Codes 178 11.2 AVP Codes 179 11.3 Application Identifier 180 11.4 NAS-Key-Binding AVP Values 181 11.5 NAS-Key-Direction AVP Values 182 11.6 NAS-Key-Type AVP Values 183 11.7 CHAP-Algorithm AVP Values 184 12.0 Security Considerations 185 13.0 References 186 14.0 Acknowledgements 187 15.0 Authors' Addresses 188 16.0 Full Copyright Statement 189 17.0 Expiration Date 191 1.0 Introduction 193 This document describes the Diameter application that is used for AAA 194 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 195 application, combined with the base protocol [2], satisfies the 196 requirements defined in the NASREQ AAA criteria specification [24] 197 and the ROAMOPS AAA Criteria specification [4]. 199 This document is divided into three main sections. The first section 200 defines the Diameter Command-Codes and AVPs that are needed to 201 support legacy authentication protocols, those that are typically 202 supported by RADIUS [1] servers. The second section defines the 203 Command-Codes and AVPs necessary for a Diameter node to support PPP's 204 Extensible Authentication Protocol (EAP) [25]. The third section 205 contains the Authorization AVPs that are needed for the various 206 services offered by a NAS, such as PPP dial-in, terminal server and 207 tunneling applications, such as L2TP [16]. 209 Given that it is expected that initial deployments of the Diameter 210 protocol in a dial-up environment will include legacy systems, this 211 application was carefully designed to ease the burden of servers that 212 must perform protocol conversion between RADIUS and Diameter. This 213 is achieved by re-using the RADIUS address space, eliminating the 214 need to perform attribute lookups. 216 1.1 Requirements language 218 In this document, the key words "MAY", "MUST", "MUST NOT", 219 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 220 interpreted as described in [12]. 222 1.2 Advertising application support 224 Diameter nodes conforming to this specification MAY advertise support 225 by including the value of one (1) in the Auth-Application-Id or the 226 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 227 Capabilities-Exchange-Answer command [2]. 229 2.0 Supported AVPs 230 This section lists all of the Diameter AVPs and the legacy RADIUS 231 attributes supported by this application. 233 2.1 Diameter AVPs 235 This section will define all of the AVPs that are not backward 236 compatible with the RADIUS protocol [1]. A Diameter message that 237 includes one of these AVPs MAY cause interoperability issues should 238 the request traverse a AAA node that only supports the RADIUS 239 protocol. However, the Diameter protocol SHOULD NOT be hampered from 240 future developments due to the existing installed base. 242 The following table describes the Diameter AVPs defined in the NASREQ 243 application, their AVP Code values, types, possible flag values and 244 whether the AVP MAY be encrypted. 246 Due to space constraints, the short form IPFiltrRule is used to 247 represent IPFilterRule. 249 +---------------------+ 250 | AVP Flag rules | 251 |----+-----+----+-----|----+ 252 AVP Section | | |SHLD| MUST|MAY | 253 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 254 -----------------------------------------|----+-----+----+-----|----| 255 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 256 NAS-Filter-Rule 400 2.1.1 IPFiltrRule| M | P | | V | Y | 257 NAS-Key-Binding 404 2.1.6 Enumerated | M | P | | V | Y | 258 NAS-Key-Data 405 2.1.5 OctetString| M | P | | V | N | 259 NAS-Key- 406 2.1.3 Enumerated | M | P | | V | N | 260 Direction | | | | | | 261 NAS-Key-Type 407 2.1.4 Enumerated | M | P | | V | N | 262 NAS-Key-Lifetime 409 2.1.7 Unsigned32 | M | P | | V | N | 263 NAS-IV 410 2.1.8 OctetString| M | P | | V | N | 264 NAS-Session-Key 408 2.1.2 Grouped | M | P | | V | Y | 265 Tunneling 403 7.4 Grouped | M | P | | V | N | 267 2.1.1 NAS-Filter-Rule AVP 269 The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule, and 270 provides filter rules that need to be configured on the NAS for the 271 user. One or more such AVPs MAY be present in an authorization 272 response. 274 2.1.2 NAS-Session-Key AVP 275 The NAS-Session-Key AVP (AVP Code 408) is of type Grouped, and 276 contains a session key distributed from Diameter servers to clients. 277 The keys MAY be used for integrity and/or confidentiality protection 278 between the NAS and the user. The keys MAY be distributed to the user 279 as part of an EAP authentication exchange. Its Data field has the 280 following ABNF grammar: 282 NAS-Session-Key ::= < AVP Header: 408 > 283 { NAS-Key-Direction } 284 { NAS-Key-Type } 285 { NAS-Key } 286 { NAS-Key-Data } 287 [ NAS-Key-Binding ] 288 [ NAS-Key-Lifetime ] 289 [ NAS-IV ] 290 * [ AVP ] 292 If strong authentication and confidentiality of the session keys is 293 required, it is recommended that the CMS security application [13] be 294 used to protect the NAS-Session-Key AVP. 296 The NAS-Session-Key AVP MAY appear zero or more times in the AAA and 297 DEA messages. When more than one NAS-Session-Key AVP is present in a 298 message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST 299 have different values. Otherwise, the AVPs would conflict with each 300 other. 302 If the optional NAS-Key-Lifetime AVP (see section 2.1.7, below) is 303 not present, then the lifetime of the NAS-Session-Key AVP is found in 304 the Authorization-Lifetime AVP. If a re-authorization request is 305 received prior to the expiration of the lifetime, new keys will need 306 to be established. 308 2.1.3 NAS-Key-Direction AVP 310 The NAS-Key-Direction AVP (AVP Code 406) is of type Enumerated, and 311 specifies the direction that the traffic is to be protected with the 312 key. The following values are supported: 314 BIDIRECTIONAL 1 315 The key is used in both directions 317 UPLINK 2 318 The key is used for traffic from the user 320 DOWNLINK 3 321 The key is used for traffic sent to user 323 2.1.4 NAS-Key-Type AVP 325 The NAS-Key-Type AVP (AVP Code 407) is of type Enumerated, and 326 specifies how the key is to be used. The following values are 327 supported: 329 CIPHER_KEY 1 330 The key is used to encrypt data 332 INTEGRITY_KEY 2 333 The key is used to authenticate the data 335 MASTER_CIPHER_KEY 3 336 The master cipher is used to derive further cipher keys 338 MASTER_INTEGRITY_KEY 4 339 The master integrity is used to derive further integrity keys 341 MASTER_KEY 5 342 The master can be used to derive any type of keys, but is not 343 guaranteed to be useful for any particular crypto system. 344 Additional processing will be required, and is not specified in 345 this document. 347 2.1.5 NAS-Key-Data AVP 349 The NAS-Key-Data AVP (AVP Code 405) is of type OctetString and 350 contains the session key to be used between the user and the access 351 device. 353 2.1.6 NAS-Key-Binding AVP 355 The NAS-Key-Binding AVP (AVP Code 404) is of type Enumerated, and 356 specifies the purpose for the key. A Diameter client MAY include this 357 AVP in a request to specify to the Diameter server the type of key it 358 desires. Responses that include the NAS-Session-Key AVP MUST include 359 this AVP which is used to specify the type of key found in the MAS- 360 Key-Data AVP. The following values are supported: 362 DES 1 363 The key created is used to secure links using DES 365 3DES 2 366 The key created is used to secure links using Triple DES 368 RC4-40 3 369 The key created is used to secure links using RC4 using 40-bit 370 keys 372 RC4-128 4 373 The key created is used to secure links using RC4 with 128-bit 374 keys 376 2.1.7 NAS-Key-Lifetime AVP 378 The NAS-Key-Lifetime AVP (AVP Code 409) is of type Unsigned32 and 379 represents the period of time (in seconds) for which the session key 380 is valid. The session key MUST NOT be used if the lifetime has 381 expired; if the key lifetime expires while the session to which it 382 applies is still active, either the session key MUST be changed or 383 the or the session MUST be terminated. 385 2.1.8 NAS-IV AVP 387 The NAS-IV AVP (AVP Code 410) is of type OctetString. Its contents 388 MAY be used as an initialization vector (IV) by cryptographic 389 algorithms (e.g., block ciphers). 391 2.2 Legacy RADIUS Attributes 393 The Diameter protocol reserves the first 255 AVP identifiers for 394 "legacy RADIUS" support. The following table contains the RADIUS 395 attributes supported by this Diameter application, their AVP code 396 values, types, possible flag values and whether the AVP MAY be 397 encrypted. RADIUS attributes not listed are not supported by the 398 Diameter protocol. 400 Due to space constraints, the short form DiamIdent is used to 401 represent DiameterIdentity. 403 +---------------------+ 404 | AVP Flag rules | 405 |----+-----+----+-----|----+ 406 AVP Section | | |SHLD| MUST|MAY | 407 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 408 -----------------------------------------|----+-----+----+-----|----| 409 Accounting- 45 8.6 Unsigned32 | M | P | | V | Y | 410 Authentication-Type | | | | | | 411 Accounting-EAP- 401 8.9 Enumerated | M | P | | V | Y | 412 Auth-Method | | | | | | 413 Accounting-Input- 42 8.1 Unsigned64 | M | P | | V | Y | 414 Extended-Octets | | | | | | 415 Accounting-Input- 47 8.4 Unsigned64 | M | P | | V | Y | 416 Extended-Packets | | | | | | 417 Accounting- 43 8.2 Unsigned64 | M | P | | V | Y | 418 Output-Extended-Octets | | | | | | 419 Accounting- 48 8.5 Unsigned64 | M | P | | V | Y | 420 Output-Extended-Packets | | | | | | 421 Accounting- 46 8.3 Unsigned32 | M | P | | V | Y | 422 Session-Time | | | | | | 423 Acct-Tunnel- 68 8.7 OctetString| M | P | | V | Y | 424 Connection | | | | | | 425 Acct-Tunnel- 86 8.8 Unsigned32 | M | P | | V | Y | 426 Packets-Lost | | | | | | 427 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 428 Response | | | | | | 429 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 430 ARAP-Password 70 3.1.1.7 OctetString| M | P | | V | Y | 431 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 432 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 433 Data | | | | | | 434 ARAP-Zone-Access 72 7.2.8.2 Enumerated | M | P | | V | Y | 435 Callback-Id 20 6.4 UTF8String | M | P | | V | Y | 436 Callback-Number 19 6.3 UTF8String | M | P | | V | Y | 437 Called-Station-Id 30 6.6 UTF8String | M | P | | V | Y | 438 Calling-Station- 31 6.7 UTF8String | M | P | | V | Y | 439 Id | | | | | | 440 CHAP-Auth 409 3.1.1.2 Grouped | M | P | | V | Y | 441 CHAP-Algorithm 412 3.1.1.4 Enumerated | M | P | | V | Y | 442 CHAP-Challenge 60 3.1.1.6 OctetString| M | P | | V | Y | 443 CHAP-Ident 410 3.1.1.3 OctetString| M | P | | V | Y | 444 CHAP-Response 411 3.1.1.5 OctetString| M | P | | V | Y | 445 Connect-Info 77 6.10 UTF8String | M | P | | V | Y | 446 Filter-Id 11 6.2 UTF8String | M | P | | V | Y | 447 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 448 Link | | | | | | 449 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 450 Network | | | | | | 451 +---------------------+ 452 | AVP Flag rules | 453 |----+-----+----+-----|----+ 454 AVP Section | | |SHLD| MUST|MAY | 455 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 456 -----------------------------------------|----+-----+----+-----|----| 457 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 458 Zone | | | | | | 459 Framed- 13 7.2.4 Enumerated | M | P | | V | Y | 460 Compression | | | | | | 461 Framed- 96 7.2.5.4 Unsigned64 | M | P | | V | Y | 462 Interface-Id | | | | | | 463 Framed-IPv6-Pool 100 7.2.5.7 UTF8String | M | P | | V | Y | 464 Framed-IPv6- 97 7.2.5.5 IPAddress | M | P | | V | Y | 465 Prefix | | | | | | 466 Framed-IPv6- 99 7.2.5.6 UTF8String | M | P | | V | Y | 467 Route | | | | | | 468 Framed-IP-Address 8 7.2.5.1 IPAddress | M | P | | V | Y | 469 Framed-IP-Netmask 9 7.2.5.2 IPAddress | M | P | | V | Y | 470 Framed-IP-Route 22 7.2.5.3 UTF8String | M | P | | V | Y | 471 Framed-IPX- 23 7.2.6.1 UTF8String | M | P | | V | Y | 472 Network | | | | | | 473 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 474 Framed-Protocol 7 7.2.1 Enumerated | M | P | | V | Y | 475 Framed-Routing 10 7.2.2 Enumerated | M | P | | V | Y | 476 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 477 Login-IP-Host 14 7.3.1 IPAddress | M | P | | V | Y | 478 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 479 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 480 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 481 Login-LAT-Service 34 7.3.4.1 OctetString| M | P | | V | Y | 482 Login-Service 15 7.3.2 Enumerated | M | P | | V | Y | 483 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 484 NAS-Identifier 32 2.2.2 DiamIdent | M | P | | V | Y | 485 NAS-IP-Address 4 2.2.1 IPAddress | M | P | | V | Y | 486 NAS-Port 5 6.1 Unsigned32 | M | P | | V | Y | 487 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 488 Password-Retry 75 3.1.2.2 Unsigned32 | M | P | | V | Y | 489 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 490 Prompt 76 3.1.2.3 Enumerated | M | P | | V | Y | 491 Reply-Message 18 3.2 UTF8String | M | P | | V | Y | 492 Service-Type 6 7.1 Enumerated | M | P | | V | Y | 493 State 24 2.2.3 OctetString| M | P | | V | Y | 494 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 495 Assignment-Id | | | | | | 496 Tunnel-Client- 90 7.4.9 Unsigned32 | M | P | | V | Y | 497 Auth-ID | | | | | | 498 +---------------------+ 499 | AVP Flag rules | 500 |----+-----+----+-----|----+ 501 AVP Section | | |SHLD| MUST|MAY | 502 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 503 -----------------------------------------|----+-----+----+-----|----| 504 Tunnel-Client- 66 7.4.3 UTF8String | M | P | | V | Y | 505 Endpoint | | | | | | 506 Tunnel-Medium- 65 7.4.2 Enumerated | M | P | | V | Y | 507 Type | | | | | | 508 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 509 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 510 Tunnel-Private- 81 7.4.6 UTF8String | M | P | | V | Y | 511 Group-ID | | | | | | 512 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 513 Auth-ID | | | | | | 514 Tunnel-Server- 67 7.4.4 UTF8String | M | P | | V | Y | 515 Endpoint | | | | | | 516 Tunnel-Type 64 7.4.1 Enumerated | M | P | | V | Y | 517 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 519 The AVPs defined in this section SHOULD only used when a 520 Diameter/RADIUS gateway function is invoked, and are not used in the 521 Diameter protocol. 523 2.2.1 NAS-IP-Address AVP 525 The NAS-IP-Address AVP (AVP Code 4) [1] is of type IPAddress, and 526 contains the IP Address of the NAS providing service to the user. 527 When this AVP is present, the Origin-Host AVP DOES NOT represent the 528 NAS providing service to the user. Note that this AVP SHOULD only 529 added by a RADIUS/Diameter protocol gateway (see Section 9.0). 531 2.2.2 NAS-Identifier AVP 533 The NAS-Identifier AVP (AVP Code 32) [1] is of type DiameterIdentity, 534 and contains the Identity of the NAS providing service to the user. 535 When this AVP is present, the Origin-Host AVP DOES NOT represent the 536 NAS providing service to the user. Note that this AVP SHOULD only 537 added by a RADIUS/Diameter protocol gateway (see Section 9.0). 539 2.2.3 State AVP 541 The State AVP (AVP Code 24) is of type OctetString and is used to 542 transmit the contents of the RADIUS State attribute, and no 543 interpretation of the contents should be made. Note that this AVP 544 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 545 9.0). 547 3.0 Legacy RADIUS Authentication Support 549 This section defines the new Command-Code [2] values required to 550 support the legacy authentication protocols (i.e. PAP, CHAP), as well 551 as the AVPs that are necessary to carry the authentication 552 information in the Diameter protocol. The functionality defined here 553 provides a RADIUS-like AAA service, over a more reliable and secure 554 transport, as defined in the base protocol [2]. 556 Unlike the RADIUS protocol [1], the Diameter protocol does not 557 require authentication information to be contained in a request from 558 the client. Therefore, it is possible to send a request for 559 authorization only. The type of service depends upon the Auth- 560 Request-Type AVP. This difference MAY cause operational issues in 561 environments that need RADIUS interoperability, and it MAY be 562 necessary that protocol conversion gateways add some authentication 563 information when transmitting to a RADIUS server. 565 The Diameter protocol allows for users to be periodically re- 566 authenticated and/or re-authorized. In such instances, the Session-Id 567 AVP in the AAR message MUST be the same as the one present in the 568 original authentication/authorization message. A Diameter server 569 informs the NAS of the authorized session lifetime via the Session- 570 Timeout AVP [1]. 572 A NAS MUST re-authenticate and/or authorize after the period provided 573 by the server. Furthermore, it is possible for Diameter servers to 574 issue an unsolicited re-authentication and/or re-authorization by 575 issuing an Re-Auth-Request message to the NAS. Upon receipt of such a 576 message, the NAS is instructed to issue a request to re-authenticate 577 and/or re-authorize the client. 579 3.1 Command-Codes Values 581 This section defines new Command-Code [2] values that MUST be 582 supported by all Diameter implementations that conform to this 583 specification. The following Command Codes are defined in this 584 section: 586 Command-Name Abbrev. Code Reference 587 -------------------------------------------------------- 588 AA-Answer AAA 265 3.1.2 589 AA-Request AAR 265 3.1.1 591 3.1.1 AA-Request (AAR) Command 593 The AA-Request message (AAR), indicated by the Command-Code field set 594 to 265 and the 'R' bit set in the Command Flags field, is used in 595 order to request authentication and/or authorization for a given PPP 596 user. The type of request is identified through the Auth-Request-Type 597 AVP, and the default mode is both authentication and authorization. 599 If Authentication is requested the User-Name attribute SHOULD be 600 present, as well as any additional authentication AVPs that would 601 carry the password information. A request for authorization only 602 SHOULD include the information from which the authorization will be 603 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 604 networks MAY use different AVPs for authorization purposes. A request 605 for authorization will include some AVPs defined in sections 2.0, 6.0 606 and 7.0. 608 It is possible for a single session to be authorized only first, then 609 followed by an authentication request. However, the inverse SHOULD 610 NOT be permitted. 612 This AA-Request message MAY be the result of a multi-round 613 authentication exchange, which occurs when the AAA is received with 614 the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent 615 AAR message SHOULD be sent, with the User-Password AVP that includes 616 the user's response to the prompt, and MUST include any State AVPs 617 that were present in the AAA. 619 Message Format 620 ::= < Diameter Header: 265, REQ, PXY > 621 < Session-Id > 622 { Auth-Application-Id } 623 { Origin-Host } 624 { Origin-Realm } 625 { Destination-Realm } 626 { Auth-Request-Type } 627 { Service-Type } 628 { NAS-IP-Address } 629 { NAS-Port } 630 [ Origin-State-Id ] 631 [ Destination-Host ] 632 [ NAS-Identifier ] 633 [ NAS-Port-Type ] 634 [ Port-Limit ] 635 [ User-Name ] 636 [ User-Password ] 637 [ Idle-Timeout ] 638 [ State ] 639 [ Authorization-Lifetime ] 640 [ Auth-Grace-Period ] 641 [ Auth-Session-State ] 642 [ Session-Timeout ] 643 [ NAS-Key-Binding ] 644 [ Callback-Number ] 645 [ Called-Station-Id ] 646 [ Calling-Station-Id ] 647 [ Connect-Info ] 648 [ CHAP-Auth ] 649 [ CHAP-Challenge ] 650 * [ Framed-Compression ] 651 [ Framed-Interface-Id ] 652 * [ Framed-IPv6-Prefix ] 653 [ Framed-IPv6-Pool ] 654 * [ Framed-IPv6-Route ] 655 [ Framed-IP-Address ] 656 [ Framed-IP-Netmask ] 657 [ Framed-Protocol ] 658 [ Framed-Routing ] 659 [ ARAP-Password ] 660 [ ARAP-Security ] 661 * [ ARAP-Security-Data ] 662 * [ Login-IP-Host ] 663 [ Login-LAT-Group ] 664 [ Login-LAT-Node ] 665 [ Login-LAT-Port ] 666 [ Login-LAT-Service ] 667 * [ Tunneling ] 668 * [ AVP ] 669 * [ Proxy-Info ] 670 * [ Route-Record ] 672 3.1.1.1 User-Password AVP 674 The User-Password AVP (AVP Code 2) is of type OctetString and 675 contains the password of the user to be authenticated, or the user's 676 input in a multi-round authentication exchange. 678 The User-Password AVP MUST be encrypted using the methods described 679 in [13], or where [13] isn't applied, the whole DIAMETER message flow 680 MUST be encrypted using IPsec and/or TLS as described in [2]. Unless 681 this AVP is used for one-time passwords, the User-Password AVP SHOULD 682 NOT be used in non-trusted proxy environments. 684 The clear-text password (prior to encryption) MUST NOT be longer than 685 128 bytes in length. 687 3.1.1.2 CHAP-Auth AVP 689 The CHAP-Auth AVP (AVP Code 409) is of type Grouped and contains the 690 information necessary to authenticate a user using the PPP Challenge- 691 Handshake Authentication Protocol (CHAP) [6]. If the CHAP-Auth AVP is 692 found in a message, the CHAP-Challenge AVP (see section 3.1.1.6) MUST 693 be present as well. The AVP containing the CHAP response depends upon 694 the value of the CHAP-Algorithm AVP (see section 3.1.1.4 for more 695 info). Its Data field has the following ABNF grammar: 697 CHAP-Auth ::= < AVP Header: 409 > 698 { CHAP-Algorithm } 699 { CHAP-Ident } 700 [ CHAP-Response ] 701 [ AVP ] 703 3.1.1.3 CHAP-Ident AVP 705 The CHAP-Ident AVP (AVP Code 410) is of type OctetString and contains 706 the one octet CHAP Identifier used in the computation of the CHAP 707 response [6]. 709 3.1.1.4 CHAP-Algorithm AVP 711 The CHAP-Algorithm AVP (AVP Code 412) is of type Enumerated and 712 contains the algorithm identifier used in the computation of the CHAP 713 response [6]. The following values are currently supported: 715 CHAP with MD5 5 716 The CHAP response is computed using the procedure decribed in 717 [6]. The CHAP-Response AVP MUST be present in the CHAP-Auth 718 AVP. 720 3.1.1.5 CHAP-Response AVP 722 The CHAP-Response AVP (AVP Code 411) is of type OctetString and 723 contains the 16 octet authentication data provided by the user in 724 response to the CHAP challenge [16]. The actual computation of the 725 CHAP response can be found in [6]. 727 3.1.1.6 CHAP-Challenge AVP 729 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 730 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 731 Handshake Authentication Protocol (CHAP) [6] user. 733 3.1.1.7 ARAP-Password AVP 735 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 736 only present when the Framed-Protocol AVP (see Section 7.2.1) is 737 included in the message and is set to ARAP. This AVP MUST NOT be 738 present if either the User-Password or the CHAP-Auth AVP is present. 739 See [32] for more information on the contents of this AVP. 741 3.1.2 AA-Answer (AAA) Command 743 The AA-Answer (AAA) message, indicated by the Command-Code field set 744 to 265 and the 'R' bit cleared in the Command Flags field, is sent in 745 response to the AA-Request message. If authorization was requested, a 746 successful response will include the authorization AVPs appropriate 747 for the service being provided, as defined in section 2.0, 6.0 and 748 7.0 750 For authentication exchanges that require more than a single round 751 trip, the server MUST set the Result-Code AVP to 752 DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY 753 include one or more Reply-Message and MAY include zero or one State 754 AVPs. When possible, authentication mechanisms that include more 755 than a single authentication round trip SHOULD use EAP (see section 756 4.0) 758 If the Reply-Message AVP was present, the access device SHOULD 759 display the text message to the user, and MUST prompt the user for a 760 response. If the access device is unable to prompt the user for a 761 new response, which could be achieved via PAP, it MUST treat this 762 answer as an error, and deny access. 764 Message Format 766 ::= < Diameter Header: 265, PXY > 767 < Session-Id > 768 { Auth-Application-Id } 769 { Auth-Request-Type } 770 { Result-Code } 771 { Origin-Host } 772 { Origin-Realm } 773 { Service-Type } 774 [ User-Name ] 775 [ Error-Message ] 776 [ Error-Reporting-Host ] 777 [ Idle-Timeout ] 778 [ Authorization-Lifetime ] 779 [ Auth-Grace-Period ] 780 [ Auth-Session-State ] 781 [ Re-Auth-Request-Type ] 782 [ Session-Timeout ] 783 [ State ] 784 * [ Reply-Message ] 785 [ Origin-State-Id ] 786 * [ Filter-Id ] 787 * [ NAS-Session-Key ] 788 [ Password-Retry ] 789 [ Prompt ] 790 [ ARAP-Challenge-Response ] 791 [ ARAP-Features ] 792 [ ARAP-Zone-Access ] 793 [ Callback-Id ] 794 [ Callback-Number ] 795 [ Framed-Appletalk-Link ] 796 * [ Framed-Appletalk-Network ] 797 [ Framed-Appletalk-Zone ] 798 * [ Framed-Compression ] 799 [ Framed-Interface-Id ] 800 * [ Framed-IPv6-Prefix ] 801 [ Framed-IPv6-Pool ] 802 * [ Framed-IPv6-Route ] 804 [ Framed-IP-Address ] 805 [ Framed-IP-Netmask ] 806 * [ Login-IP-Host ] 807 [ Login-LAT-Group ] 808 [ Login-LAT-Node ] 809 [ Login-LAT-Port ] 810 [ Login-LAT-Service ] 811 * [ Login-Service ] 812 * [ Login-TCP-Port ] 813 * [ NAS-Filter-Rule ] 814 * [ Tunneling ] 815 * [ Redirect-Host ] 816 [ Redirect-Host-Usage ] 817 [ Redirect-Max-Cache-Time ] 818 * [ AVP ] 819 * [ Proxy-Info ] 821 3.1.2.1 ARAP-Challenge-Response AVP 823 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 824 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 825 is included in the message and is set to ARAP. This AVP contains an 8 826 octet response to the dial-in client's challenge. The RADIUS server 827 calculates this value by taking the dial-in client's challenge from 828 the high order 8 octets of the ARAP-Password AVP and performing DES 829 encryption on this value with the authenticating user's password as 830 the key. If the user's password is less than 8 octets in length, the 831 password is padded at the end with NULL octets to a length of 8 832 before using it as a key. 834 3.1.2.2 Password-Retry AVP 836 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 837 included in the AA-Answer if the Result-Code indicates an 838 authentication failure. The value of this AVP indicates how many 839 authentication attempts a user may be permitted before being 840 disconnected. This AVP is primarily intended for use when the Framed- 841 Protocol AVP (see Section 7.2.1) is set to ARAP. 843 3.1.2.3 Prompt AVP 845 The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be 846 present in the AA-Answer message. When present, it is used by the NAS 847 to determine whether the user's response, when entered, should be 848 echoed. 850 The supported values are listed in [34]. 852 3.2 Reply-Message AVP 854 The Reply-Message AVP (AVP Code 18) is of type UTF8String, and 855 contains text which MAY be displayed to the user. When used in an 856 AA-Answer message with a successful Result-Code AVP it indicates the 857 success message. When found in the same message with a Result-Code 858 other than Diameter-SUCCESS it contains the failure message. 860 The Reply-Message AVP MAY indicate a dialog message to prompt the 861 user before another AA-Request attempt. When used in an AA-Answer, it 862 MAY indicate a dialog message to prompt the user for a response. 864 Multiple Reply-Message's MAY be included and if any are displayed, 865 they MUST be displayed in the same order as they appear in the 866 message. 868 4.0 Extensible Authentication Protocol Support 870 The Extensible Authentication Protocol (EAP), described in [25], 871 provides a standard mechanism for support of extensible 872 authentication methods. Through the use of EAP, support for a number 873 of authentication schemes may be added, including smart and token 874 cards, Kerberos, Public Key, One Time Passwords, and others. 876 This section describes the Command-Codes values and AVPs that are 877 required for an EAP payload to be encapsulated within the Diameter 878 protocol. Since authentication occurs between the EAP client and its 879 home Diameter server, end-to-end authentication is achieved, reducing 880 the possibility for fraudulent authentication, such as replay and 881 man-in-the-middle attacks. End-to-end authentication also provides 882 for mutual (bi-directional) authentication, which is not possible 883 with PAP and CHAP in a roaming PPP environment. 885 The EAP conversation between the authenticating peer and the access 886 device begins with the initiation of EAP within a link layer, such as 887 PPP or 802.1x. Once EAP has been initiated, the access device will 888 typically send to the Diameter server a Diameter-EAP-Request message 889 with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number 890 and the identity of the access device (e.g. Origin-Host or NAS- 891 Identifier) MUST be included in the Diameter-EAP-Request message. 893 If the Diameter home server supports EAP, it MUST respond with a 894 Diameter-EAP-Answer message containing an EAP-Payload AVP that 895 includes an encapsulated EAP payload [25], and the Result-Code AVP 896 set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent 897 request is expected. The EAP payload is forwarded by the access 898 device to the EAP client. 900 The initial Diameter-EAP-Answer in a multi-round exchange normally 901 includes an EAP-Request/Identity, requesting the EAP client to 902 identify itself. Upon receipt of the EAP client's EAP-Response [25], 903 the access device will then issue a second Diameter-EAP-Request 904 message, with the client's EAP payload encapsulated within the EAP- 905 Payload AVP. 907 A preferred approach is for the access device to issue the EAP- 908 Request/Identity message to the EAP client, and forward the EAP- 909 Response/Identity packet, encapsulated within the EAP-Payload AVP, as 910 a Diameter-EAP-Request to the Diameter server. This alternative 911 reduces the number of Diameter message round trips, and is compatible 912 with roaming environments, since the Destination-Realm is needed by 913 Diameter agents for routing purposes. Note that this alternative 914 cannot be universally employed, as there are circumstances where a 915 user's identity is not needed (such as when authorization occurs 916 based on a calling or called phone number). 918 The conversation continues until the Diameter server sends a 919 Diameter-EAP-Answer with a Result-Code AVP indicating success or 920 failure, and an optional EAP-Payload. The Result-Code AVP is used by 921 the access device to determine whether service is to be provided to 922 the EAP client. The access device MUST NOT rely on the contents of 923 the optional EAP-Payload to determine whether service is to be 924 provided. 926 A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- 927 Success or EAP-Failure MUST NOT have the Result-Code AVP set to 928 DIAMETER_MULTI_ROUND_AUTH. 930 If authorization was requested, a successful Diameter-EAP-Answer MUST 931 also include the appropriate authorization AVPs required for the 932 service requested (see sections 2.0, 6.0 and 7.0). Diameter-EAP- 933 Answer messages whose Result-Code AVP is set to 934 DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. 936 Unless the access device interprets the EAP-Response/Identity packet 937 returned by the authenticating peer, it will not have access to the 938 user's identity. Therefore, the Diameter Server SHOULD return the 939 user's identity by inserting it in the User-Name attribute of 940 subsequent Diameter-EAP-Answer packets. Without the user's identity, 941 the Session-Id AVP MAY be used for accounting and billing, however 942 operationally this MAY be very difficult to manage. 944 A home Diameter server MAY request EAP re-authentication by issuing 945 the Re-Auth-Request [2] message to the Diameter client. 947 Should an EAP authentication session be interrupted due to a home 948 server failure, the session MAY be directed to an alternate server, 949 but the authentication session will have to be restarted from the 950 beginning. 952 If a response is received with the Result-Code set to 953 DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the 954 Diameter server in the home realm does not support EAP. If possible, 955 the access device MAY attempt to negotiate another authentication 956 protocol, such as PAP or CHAP. An access device SHOULD be cautious 957 when determining whether a less secure authentication protocol will 958 be used, since this could be a result of a bidding down attack. 960 4.1 Alternative uses 962 Currently the conversation between the backend authentication server 963 and the Diameter server is proprietary because of lack of 964 standardization. In order to increase standardization and provide 965 interoperability between Diameter vendors and backend security 966 vendors, it is recommended that Diameter-encapsulated EAP be used for 967 this conversation. 969 This has the advantage of allowing the Diameter server to support EAP 970 without the need for authentication-specific code within the Diameter 971 server. Authentication-specific code can then reside on a backend 972 authentication server instead. 974 In the case where Diameter-encapsulated EAP is used in a conversation 975 between a Diameter server and a backend authentication server, the 976 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 977 Success message without inclusion of the expected authorization AVPs 978 required in a successful response. This means that the Diameter 979 server MUST add these attributes prior to sending an Diameter-EAP- 980 Answer/EAP-Payload/EAP-Success message to the access device. 982 4.2 Command-Codes Values 984 This section defines new Command-Code [2] values that MUST be 985 supported by all Diameter implementations conforming to this 986 specification. The following Command Codes are defined in this 987 section: 989 Command-Name Abbrev. Code Reference 990 -------------------------------------------------------- 991 Diameter-EAP-Answer DEA 268 4.2.2 992 Diameter-EAP-Request DER 268 4.2.1 994 4.2.1 Diameter-EAP-Request (DER) Command 996 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 997 field set to 268 and the 'R' bit set in the Command Flags field, is 998 sent by a Diameter client to a Diameter server and conveys an EAP- 999 Response [25] from the EAP client. The Diameter-EAP-Request MUST 1000 contain one EAP-Payload AVP, which contains the actual EAP payload. 1001 An EAP-Payload AVP with no data MAY be sent to the Diameter server to 1002 initiate an EAP authentication session. 1004 The DER message MAY be the result of a multi-round authentication 1005 exchange, which occurs when the DEA is received with the Result-Code 1006 AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST 1007 include any State AVPs that were present in the DEA. For re- 1008 authentication, it is recommended that the Identity request be 1009 skipped in order to reduce the number of authentication round trips. 1010 This is only possible when the user's identity is already known by 1011 the home Diameter server. 1013 Message Format 1015 ::= < Diameter Header: 268, REQ, PXY > 1016 < Session-Id > 1017 { Auth-Application-Id } 1018 { Origin-Host } 1019 { Origin-Realm } 1020 { Destination-Realm } 1021 { Auth-Request-Type } 1022 { Service-Type } 1023 { NAS-IP-Address } 1024 { NAS-Port } 1025 { EAP-Payload } 1026 [ Destination-Host ] 1027 [ Authorization-Lifetime ] 1028 [ Auth-Grace-Period ] 1029 [ Auth-Session-State ] 1030 [ Session-Timeout ] 1031 [ User-Name ] 1033 [ Idle-Timeout ] 1034 [ NAS-Identifier ] 1035 [ NAS-Port-Type ] 1036 [ Port-Limit ] 1037 [ State ] 1038 [ Origin-State-Id ] 1039 [ NAS-Key-Binding ] 1040 [ Callback-Number ] 1041 [ Called-Station-Id ] 1042 [ Calling-Station-Id ] 1043 [ Connect-Info ] 1044 * [ Framed-Compression ] 1045 [ Framed-Interface-Id ] 1046 * [ Framed-IPv6-Prefix ] 1047 [ Framed-IPv6-Pool ] 1048 * [ Framed-IPv6-Route ] 1049 [ Framed-IP-Address ] 1050 [ Framed-IP-Netmask ] 1051 [ Framed-Protocol ] 1052 [ Framed-Routing ] 1053 [ Tunneling ] 1054 * [ AVP ] 1055 * [ Proxy-Info ] 1056 * [ Route-Record ] 1058 4.2.2 Diameter-EAP-Answer (DEA) Command 1060 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 1061 field set to 268 and the 'R' bit cleared in the Command Flags field, 1062 is sent by the Diameter server to the client for one of the following 1063 reasons: 1065 1) The message is part of a multi-round authentication exchange, 1066 and the server is expecting a subsequent Diameter-EAP-Request. 1067 This is indicated by setting the Result-Code to 1068 DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State 1069 AVPs. 1070 2) the EAP client has been successfully authenticated and 1071 authorized, in which case the message MUST include the Result- 1072 Code AVP indicating success, and SHOULD include an EAP-Payload 1073 of type EAP-Success. This event MUST cause the access device 1074 to provide service to the EAP client. 1075 3) The EAP client has not been successfully authenticated and/or 1076 authorized, and the Result-Code AVP is set to indicate failure. 1077 This message SHOULD include an EAP-Payload, but this AVP is not 1078 used to determine whether service is to be provided. 1080 If the message from the Diameter client included a request for 1081 authorization, a successful response MUST include the authorization 1082 AVPs that are relevant to the service being provided. 1084 Message Format 1086 ::= < Diameter Header: 268, PXY > 1087 < Session-Id > 1088 { Auth-Application-Id } 1089 { Result-Code } 1090 { Origin-Host } 1091 { Origin-Realm } 1092 { Auth-Request-Type } 1093 { Service-Type } 1094 [ Error-Reporting-Host ] 1095 [ EAP-Payload ] 1096 [ User-Name ] 1097 [ Idle-Timeout ] 1098 [ Authorization-Lifetime ] 1099 [ Auth-Grace-Period ] 1100 [ Auth-Session-State ] 1101 [ Re-Auth-Request-Type ] 1102 [ Session-Timeout ] 1103 [ Origin-State-Id ] 1104 * [ NAS-Session-Key ] 1105 [ Callback-Id ] 1106 [ Callback-Number ] 1107 [ Framed-Appletalk-Link ] 1108 * [ Framed-Appletalk-Network ] 1109 [ Framed-Appletalk-Zone ] 1110 * [ Framed-Compression ] 1111 [ Framed-Interface-Id ] 1112 * [ Framed-IPv6-Prefix ] 1113 [ Framed-IPv6-Pool ] 1114 * [ Framed-IPv6-Route ] 1115 [ Framed-IP-Address ] 1116 [ Framed-IP-Netmask ] 1117 * [ Framed-IP-Route ] 1118 [ Framed-IPX-Network ] 1119 [ Framed-MTU ] 1120 * [ NAS-Filter-Rule ] 1121 * [ Tunneling ] 1122 * [ Redirect-Host ] 1123 [ Redirect-Host-Usage ] 1124 [ Redirect-Max-Cache-Time ] 1125 * [ AVP ] 1126 * [ Proxy-Info ] 1128 4.3 EAP-Payload AVP 1130 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1131 to encapsulate the actual EAP payload [25] that is being exchanged 1132 between the EAP client and the home Diameter server. 1134 5.0 Diameter Session Termination 1136 When a Network Access Server (NAS) receives an indication that a 1137 user's session is being disconnected (e.g. LCP Terminate is 1138 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1139 to its Diameter Server. This will ensure that any resources 1140 maintained on the servers is freed appropriately. 1142 Further, a NAS that receives a Abort-Session-Request (ASR) [2] MUST 1143 issue an STR if the session requested is active, and disconnect the 1144 PPP (or tunneling) session. 1146 6.0 Call and Session Information 1148 This section contains the authorization AVPs that are needed to 1149 identify call and session information, and allows the server to set 1150 constraints on a session. 1152 6.1 NAS-Port AVP 1154 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1155 physical port number of the NAS which is authenticating the user, and 1156 is normally only present in an authentication and/or authorization 1157 request. Note that this is using "port" in its sense of a physical 1158 connection on the NAS, not in the sense of a TCP or UDP port number. 1159 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1160 present in the request, if the NAS differentiates among its ports. 1162 6.2 Filter-Id AVP 1164 The Filter-Id AVP (AVP Code 11) is of type UTF8String, and contains 1165 the name of the filter list for this user. Zero or more Filter-Id 1166 AVPs MAY be sent in an authorization answer. 1168 Identifying a filter list by name allows the filter to be used on 1169 different NASes without regard to filter-list implementation details. 1170 However, this AVP is not roaming friendly since filter naming differs 1171 from one service provider to another. 1173 In non-RADIUS environments, it is strongly recommended that the NAS- 1174 Filter-Rule AVP be used instead. 1176 6.3 Callback-Number AVP 1178 The Callback-Number AVP (AVP Code 19) is of type UTF8String, and 1179 contains a dialing string to be used for callback. It MAY be used in 1180 an authentication and/or authorization request as a hint to the 1181 server that a Callback service is desired, but the server is not 1182 required to honor the hint in the corresponding response. 1184 The codification of the range of allowed usage of this field is 1185 outside the scope of this specification. 1187 6.4 Callback-Id AVP 1189 The Callback-Id AVP (AVP Code 20) is of type UTF8String, and contains 1190 the name of a place to be called, to be interpreted by the NAS. This 1191 AVP MAY be present in an authentication and/or authorization 1192 response. 1194 This AVP is not roaming friendly since it assumes that the Callback- 1195 Id is configured on the NAS. It is therefore preferable to use the 1196 Callback-Number AVP instead. 1198 6.5 Idle-Timeout AVP 1200 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1201 maximum number of consecutive seconds of idle connection allowed to 1202 the user before termination of the session or prompt. It MAY be used 1203 in an authentication and/or authorization request (or challenge) as a 1204 hint to the server that an idle timeout is desired, but the server is 1205 not required to honor the hint in the corresponding response. 1207 6.6 Called-Station-Id AVP 1209 The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and 1210 allows the NAS to send in the request the phone number that the user 1211 called, using Dialed Number Identification (DNIS) or a similar 1212 technology. Note that this may be different from the phone number the 1213 call comes in on. It SHOULD only be present in authentication and/or 1214 authorization requests. 1216 If the Auth-Request-Type AVP is set to authorization-only and the 1217 User-Name AVP is absent, the Diameter Server MAY perform 1218 authorization based on this field. This can be used by a NAS to 1219 request whether a call should be answered based on the DNIS. 1221 The codification of the range of allowed usage of this field is 1222 outside the scope of this specification. 1224 6.7 Calling-Station-Id AVP 1226 The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and 1227 allows the NAS to send in the request the phone number that the call 1228 came from, using Automatic Number Identification (ANI) or a similar 1229 technology. It SHOULD only be present in authentication and/or 1230 authorization requests. 1232 If the Auth-Request-Type AVP is set to authorization-only and the 1233 User-Name AVP is absent, the Diameter Server MAY perform 1234 authorization based on this field. This can be used by a NAS to 1235 request whether a call should be answered based on the ANI. 1237 The codification of the range of allowed usage of this field is 1238 outside the scope of this specification. 1240 6.8 NAS-Port-Type AVP 1242 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1243 contains the type of the physical port of the NAS which is 1244 authenticating the user. It can be used instead of or in addition to 1245 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1246 and/or authorization requests. This AVP MAY be combined with the NAS- 1247 Port AVP to assist in differentiating its ports. 1249 The supported values are defined in [34]. 1251 6.9 Port-Limit AVP 1253 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1254 maximum number of ports to be provided to the user by the NAS. It 1255 MAY be used in an authentication and/or authorization request as a 1256 hint to the server that multilink PPP [9] service is desired, but the 1257 server is not required to honor the hint in the corresponding 1258 response. 1260 6.10 Connect-Info AVP 1262 The Connect-Info AVP (AVP Code 77) is of type UTF8String, and is sent 1263 in the AA-Request message, and indicates the nature of the user's 1264 connection. The connection speed SHOULD be included at the beginning 1265 of the first Connect-Info AVP in the message. If the transmit and 1266 receive connection speeds differ, they may both be included in the 1267 first AVP with the transmit speed first (the speed the NAS modem 1268 transmits at), a slash (/), the receive speed, then optionally other 1269 information. 1271 7.0 Service Specific Authorization AVPs 1273 This section contains the RADIUS authorization AVPs that are 1274 supported in the Diameter protocol. The Service-Type AVP MUST be 1275 present in all messages, and based on the value of the Service-Type 1276 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1277 present. 1279 7.1 Service-Type AVP 1281 The Service-Type AVP (AVP Code 6) is of type Enumerated and contains 1282 the type of service the user has requested, or the type of service to 1283 be provided. One such AVP MAY be present in an authentication and/or 1284 authorization request or response. A NAS is not required to implement 1285 all of these service types, and MUST treat unknown or unsupported 1286 Service-Types as though a response with a Result-Code other than 1287 Diameter-SUCCESS had been received instead. 1289 When used in a request, the Service-Type AVP SHOULD be considered to 1290 be a hint to the server that the NAS has reason to believe the user 1291 would prefer the kind of service indicated, but the server is not 1292 required to honor the hint. The following values have been defined 1293 for the Service-Type AVP: 1295 The complete list of defined values can be found in [1] and [34]. The 1296 following values are extracted from [1], and are listed here since 1297 they are further qualified: 1299 Login 1 1300 The user should be connected to a host. The message MAY include 1301 additional AVPs defined in section 7.3. 1303 Framed 2 1304 A Framed Protocol should be started for the User, such as PPP 1305 or SLIP. The message MAY include additional AVPs defined in 1306 section 7.2, or 7.4 for tunneling services. 1308 Callback Login 3 1309 The user should be disconnected and called back, then connected 1310 to a host. The message MAY include additional AVPs defined in 1311 section 7.3. 1313 Callback Framed 4 1314 The user should be disconnected and called back, then a Framed 1315 Protocol should be started for the User, such as PPP or SLIP. 1316 The message MAY include additional AVPs defined in section 7.2, 1317 or 7.4 for tunneling services. 1319 7.2 Framed Access Authorization AVPs 1321 This section contains the authorization AVPs that are necessary to 1322 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1323 section MAY be present in a message if the Service-Type AVP was set 1324 to "Framed" or "Callback Framed". 1326 7.2.1 Framed-Protocol AVP 1328 The Framed-Protocol AVP (AVP Code 7) is of type Enumerated and 1329 contains the framing to be used for framed access. This AVP MAY be 1330 present in both requests and responses. The supported values are 1331 listed in [34]. 1333 7.2.2 Framed-Routing AVP 1335 The Framed-Routing AVP (AVP Code 10) is of type Enumerated and 1336 contains the routing method for the user, when the user is a router 1337 to a network. This AVP SHOULD only be present in authorization 1338 responses. The supported values are listed in [34]. 1340 7.2.3 Framed-MTU AVP 1342 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1343 the Maximum Transmission Unit to be configured for the user, when it 1344 is not negotiated by some other means (such as PPP). This AVP SHOULD 1345 only be present in authorization responses. The MTU value MUST be 1346 between the range of 64 and 65535. 1348 7.2.4 Framed-Compression AVP 1349 The Framed-Compression AVP (AVP Code 13) is of type Enumerated and 1350 contains the compression protocol to be used for the link. It MAY be 1351 used in an authorization request as a hint to the server that a 1352 specific compression type is desired, but the server is not required 1353 to honor the hint in the corresponding response. 1355 More than one compression protocol AVP MAY be sent. It is the 1356 responsibility of the NAS to apply the proper compression protocol to 1357 appropriate link traffic. 1359 The supported values are listed in [34]. 1361 7.2.5 IP Access 1363 The AVPs defined in this section are used when the user requests, or 1364 is being granted, access to IP. They are only present if the Framed- 1365 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1366 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1368 7.2.5.1 Framed-IP-Address AVP 1370 The Framed-IP-Address AVP (AVP Code 8) is of type IPAddress and 1371 contains the address to be configured for the user. It MAY be used in 1372 an authorization request as a hint to the server that a specific 1373 address is desired, but the server is not required to honor the hint 1374 in the corresponding response. 1376 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1377 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1378 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1379 that the NAS should select an address for the user (e.g. Assigned 1380 from a pool of addresses kept by the NAS). 1382 7.2.5.2 Framed-IP-Netmask AVP 1384 The Framed-IP-Netmask AVP (AVP Code 9) is of type IPAddress and 1385 contains the IP netmask to be configured for the user when the user 1386 is a router to a network. It MAY be used in an authorization request 1387 as a hint to the server that a specific netmask is desired, but the 1388 server is not required to honor the hint in the corresponding 1389 response. This AVP MUST be present in a response if the request 1390 included this AVP with a value of 0xFFFFFFFF. 1392 7.2.5.3 Framed-IP-Route AVP 1393 The Framed-IP-Route AVP (AVP Code 22) is of type UTF8String, and 1394 contains the routing information to be configured for the user on the 1395 NAS. Zero or more such AVPs MAY be present in an authorization 1396 response. 1398 The string MUST contain a destination prefix in dotted quad form 1399 optionally followed by a slash and a decimal length specifier stating 1400 how many high order bits of the prefix should be used. That is 1401 followed by a space, a gateway address in dotted quad form, a space, 1402 and one or more metrics separated by spaces. For example, 1403 "192.168.1.0/24 192.168.1.1 1". 1405 The length specifier may be omitted in which case it should default 1406 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1407 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1409 Whenever the gateway address is specified as "0.0.0.0" the IP address 1410 of the user SHOULD be used as the gateway address. 1412 7.2.5.4 Framed-Interface-Id AVP 1414 The Framed-Interface-Id AVP (AVP Code 96) is of type Unsigned64 and 1415 contains the IPv6 interface identifier to be configured for the user. 1416 It MAY be used in authorization requests as a hint to the server that 1417 a specific interface id is desired, but the server is not required to 1418 honor the hint in the corresponding response. 1420 7.2.5.5 Framed-IPv6-Prefix AVP 1422 The Framed-IPv6-Prefix AVP (AVP Code 97) is of type IPAddress and 1423 contains the IPv6 prefix to be configured for the user. One or more 1424 AVPs MAY be used in authorization requests as a hint to the server 1425 that a specific IPv6 prefixes are desired, but the server is not 1426 required to honor the hint in the corresponding response. 1428 7.2.5.6 Framed-IPv6-Route AVP 1430 The Framed-IPv6-Route AVP (AVP Code 99) is of type UTF8String, and 1431 contains the routing information to be configured for the user on the 1432 NAS. Zero or more such AVPs MAY be present in an authorization 1433 response. 1435 The string MUST contain an IPv6 address prefix followed by a slash 1436 and a decimal length specifier stating how many high order bits of 1437 the prefix should be used. That is followed by a space, a gateway 1438 address in hexadecimal notation, a space, and one or more metrics 1439 separated by spaces. For example: 1440 "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". 1442 Whenever the gateway address is the IPv6 unspecified address the IP 1443 address of the user SHOULD be used as the gateway address, such as: 1444 "2000:0:0:106::/64 :: 1". 1446 7.2.5.7 Framed-IPv6-Pool AVP 1448 The Framed-IPv6-Pool AVP (AVP Code 100) is of type UTF8String, and 1449 contains the name of an assigned pool that SHOULD be used to assign 1450 an IPv6 prefix for the user. If the access device does not support 1451 multiple prefix pools, it MUST ignore this AVP. 1453 7.2.6 IPX Access 1455 The AVPs defined in this section are used when the user requests, or 1456 is being granted, access to IPX. They are only present if the Framed- 1457 Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics proprietary 1458 IPX/SLIP, Gandalf proprietarySingleLink/MultiLink protocol, or X.75 1459 Synchronous. 1461 7.2.6.1 Framed-IPX-Network AVP 1463 The Framed-IPX-Network AVP (AVP Code 23) is of type UTF8String, and 1464 contains the IPX Network number to be configured for the user. It MAY 1465 be used in an authorization request as a hint to the server that a 1466 specific address is desired, but the server is not required to honor 1467 the hint in the corresponding response. 1469 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1470 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1471 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1472 that the NAS should select an address for the user (e.g. assigned 1473 from a pool of one or more IPX networks kept by the NAS). 1475 7.2.7 Appletalk Access 1477 The AVPs defined in this section are used when the user requests, or 1478 is being granted, access to Appletalk. They are only present if the 1479 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1480 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1482 7.2.7.1 Framed-AppleTalk-Link AVP 1484 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1485 contains the AppleTalk network number which should be used for the 1486 serial link to the user, which is another AppleTalk router. This AVP 1487 MUST only be present in an authorization response and is never used 1488 when the user is not another router. 1490 Despite the size of the field, values range from zero to 65535. The 1491 special value of zero indicates that this is an unnumbered serial 1492 link. A value of one to 65535 means that the serial line between the 1493 NAS and the user should be assigned that value as an AppleTalk 1494 network number. 1496 7.2.7.2 Framed-AppleTalk-Network AVP 1498 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1499 and contains the AppleTalk Network number which the NAS should probe 1500 to allocate an AppleTalk node for the user. This AVP MUST only be 1501 present in an authorization response and is never used when the user 1502 is not another router. Multiple instances of this AVP indicate that 1503 the NAS may probe using any of the network numbers specified. 1505 Despite the size of the field, values range from zero to 65535. The 1506 special value zero indicates that the NAS should assign a network for 1507 the user, using its default cable range. A value between one and 1508 65535 (inclusive) indicates the AppleTalk Network the NAS should 1509 probe to find an address for the user. 1511 7.2.7.3 Framed-AppleTalk-Zone AVP 1513 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1514 and contains the AppleTalk Default Zone to be used for this user. 1515 This AVP MUST only be present in an authorization response. Multiple 1516 instances of this AVP in the same message are not allowed. 1518 The codification of the range of allowed usage of this field is 1519 outside the scope of this specification. 1521 7.2.8 ARAP Access 1523 The AVPs defined in this section are used when the user requests, or 1524 is being granted, access to ARAP. They are only present if the 1525 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1526 Access Protocol (ARAP). 1528 7.2.8.1 ARAP-Features AVP 1530 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1531 be present in the AA-Accept message if the Framed-Protocol AVP is set 1532 to the value of ARAP. See [32] for more information of the format of 1533 this AVP. 1535 7.2.8.2 ARAP-Zone-Access AVP 1537 The ARAP-Zone-Access AVP (AVP Code 72) is of type Enumerated, and MAY 1538 be present in the AA-Accept message if the Framed-Protocol AVP is set 1539 to the value of ARAP. 1541 The supported values are listed in [34], and are defined in [32]. 1543 7.2.8.3 ARAP-Security AVP 1545 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1546 present in the AA-Answer message if the Framed-Protocol AVP is set to 1547 the value of ARAP, and the Result-Code AVP is set to 1548 DIAMETER_MULTI_ROUND_AUTH. See [32] for more information of the 1549 format of this AVP. 1551 7.2.8.4 ARAP-Security-Data AVP 1553 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1554 be present in the AA-Request or AA-Answer message if the Framed- 1555 Protocol AVP is set to the value of ARAP, and the Result-Code AVP is 1556 set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security 1557 module challenge or response associated with the ARAP Security Module 1558 specified in ARAP-Security. 1560 7.3 Non-Framed Access Authorization AVPs 1562 This section contains the authorization AVPs that are needed to 1563 support terminal server functionality. AVPs defined in this section 1564 MAY be present in a message if the Service-Type AVP was set to 1565 "Login" or "Callback Login". 1567 7.3.1 Login-IP-Host AVP 1569 The Login-IP-Host AVP (AVP Code 14) is of type IPAddress and contains 1570 the system with which to connect the user, when the Login-Service AVP 1571 is included. It MAY be used in an authorization request as a hint to 1572 the server that a specific host is desired, but the server is not 1573 required to honor the hint in the corresponding response. 1575 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1576 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1577 select an address. The value zero indicates that the NAS SHOULD 1578 select a host to connect the user to. 1580 7.3.2 Login-Service AVP 1582 The Login-Service AVP (AVP Code 15) is of type Enumerated and 1583 contains the service which should be used to connect the user to the 1584 login host. This AVP SHOULD only be present in authorization 1585 responses. 1587 The supported values are listed in [34]. 1589 7.3.3 TCP Services 1591 The AVP described in this section MAY be present if the Login-Service 1592 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1594 7.3.3.1 Login-TCP-Port AVP 1596 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1597 contains the TCP port with which the user is to be connected, when 1598 the Login-Service AVP is also present. This AVP SHOULD only be 1599 present in authorization responses. The value MUST NOT be greater 1600 than 65535. 1602 7.3.4 LAT Services 1604 The AVP described in this section MAY be present if the Login-Service 1605 AVP is set to LAT. 1607 7.3.4.1 Login-LAT-Service AVP 1609 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1610 contains the system with which the user is to be connected by LAT. It 1611 MAY be used in an authorization request as a hint to the server that 1612 a specific service is desired, but the server is not required to 1613 honor the hint in the corresponding response. This AVP MUST only be 1614 present in the response if the Login-Service AVP states that LAT is 1615 desired. 1617 Administrators use the service attribute when dealing with clustered 1618 systems, such as a VAX or Alpha cluster. In such an environment 1619 several different time sharing hosts share the same resources (disks, 1620 printers, etc.), and administrators often configure each to offer 1621 access (service) to each of the shared resources. In this case, each 1622 host in the cluster advertises its services through LAT broadcasts. 1624 Sophisticated users often know which service providers (machines) are 1625 faster and tend to use a node name when initiating a LAT connection. 1626 Alternately, some administrators want particular users to use certain 1627 machines as a primitive form of load balancing (although LAT knows 1628 how to do load balancing itself). 1630 The String field contains the identity of the LAT service to use. 1631 The LAT Architecture allows this string to contain $ (dollar), - 1632 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1633 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1634 string comparisons are case insensitive. 1636 7.3.4.2 Login-LAT-Node AVP 1638 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1639 contains the Node with which the user is to be automatically 1640 connected by LAT. It MAY be used in an authorization request as a 1641 hint to the server that a specific LAT node is desired, but the 1642 server is not required to honor the hint in the corresponding 1643 response. This AVP MUST only be present in a response if the Service- 1644 Type AVP is set to LAT. 1646 The String field contains the identity of the LAT service to use. 1647 The LAT Architecture allows this string to contain $ (dollar), - 1648 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1649 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1650 string comparisons are case insensitive. 1652 7.3.4.3 Login-LAT-Group AVP 1654 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1655 contains a string identifying the LAT group codes which this user is 1656 authorized to use. It MAY be used in an authorization request as a 1657 hint to the server that a specific group is desired, but the server 1658 is not required to honor the hint in the corresponding response. This 1659 AVP MUST only be present in a response if the Service-Type AVP is set 1660 to LAT. 1662 LAT supports 256 different group codes, which LAT uses as a form of 1663 access rights. LAT encodes the group codes as a 256 bit bitmap. 1665 Administrators can assign one or more of the group code bits at the 1666 LAT service provider; it will only accept LAT connections that have 1667 these group codes set in the bit map. The administrators assign a 1668 bitmap of authorized group codes to each user; LAT gets these from 1669 the operating system, and uses these in its requests to the service 1670 providers. 1672 The codification of the range of allowed usage of this field is 1673 outside the scope of this specification. 1675 7.3.4.4 Login-LAT-Port AVP 1677 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1678 contains the Port with which the user is to be connected by LAT. It 1679 MAY be used in an authorization request as a hint to the server that 1680 a specific port is desired, but the server is not required to honor 1681 the hint in the corresponding response. This AVP MUST only be present 1682 in a response if the Service-Type AVP is set to LAT. 1684 The String field contains the identity of the LAT service to use. 1685 The LAT Architecture allows this string to contain $ (dollar), - 1686 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1687 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1688 string comparisons are case insensitive. 1690 7.4 Tunneling AVP 1692 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1693 used to describe a tunnel. Its Data field has the following ABNF 1694 grammar: 1696 Tunneling ::= < AVP Header: 403 > 1697 { Tunnel-Type } 1698 { Tunnel-Medium-Type } 1699 { Tunnel-Client-Endpoint } 1700 { Tunnel-Server-Endpoint } 1701 [ Tunnel-Preference ] 1702 [ Tunnel-Client-Auth-ID ] 1703 [ Tunnel-Server-Auth-ID ] 1704 [ Tunnel-Assignment-ID ] 1705 [ Tunnel-Password ] 1707 [ Tunnel-Private-Group-ID ] 1709 7.4.1 Tunnel-Type AVP 1711 The Tunnel-Type AVP (AVP Code 64) is of type Enumerated and contains 1712 the tunneling protocol(s) to be used (in the case of a tunnel 1713 initiator) or the tunneling protocol in use (in the case of a tunnel 1714 terminator). It MAY be used in an authorization request as a hint to 1715 the server that a specific tunnel type is desired, but the server is 1716 not required to honor the hint in the corresponding response. 1718 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1719 Record within the Accounting-Request. 1721 A tunnel initiator is not required to implement any of these tunnel 1722 types; if a tunnel initiator receives a response that contains only 1723 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1724 as though a response was received with the Result-Code indicating a 1725 failure. 1727 The supported values are listed in [34]. 1729 7.4.2 Tunnel-Medium-Type AVP 1731 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Enumerated and 1732 contains the transport medium to use when creating a tunnel for those 1733 protocols (such as L2TP) that can operate over multiple transports. 1734 It MAY be used in an authorization request as a hint to the server 1735 that a specific medium is desired, but the server is not required to 1736 honor the hint in the corresponding response. 1738 The Value field contains one of the values listed under "Address 1739 Family Numbers" in [10]. The value of most importance is (1) for IPv4 1740 and (2) for IPv6. 1742 7.4.3 Tunnel-Client-Endpoint AVP 1744 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String, 1745 and contains the address of the initiator end of the tunnel. It MAY 1746 be used in an authorization request as a hint to the server that a 1747 specific endpoint is desired, but the server is not required to honor 1748 the hint in the corresponding response. 1750 This AVP SHOULD be included in the ADIF Record of the corresponding 1751 Accounting-Request messages, in which case it indicates the address 1752 from which the tunnel was initiated. This AVP, along with the Tunnel- 1753 Server-Endpoint and Session-Id AVP [2], MAY be used to provide a 1754 globally unique means to identify a tunnel for accounting and 1755 auditing purposes. 1757 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1758 fully qualified domain name (FQDN) of the tunnel client machine, or 1759 it is a "dotted-decimal" IP address. Conformant implementations MUST 1760 support the dotted-decimal format and SHOULD support the FQDN format 1761 for IP addresses. 1763 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1764 FQDN of the tunnel client machine, or it is a text representation of 1765 the address in either the preferred or alternate form [5]. 1766 Conformant implementations MUST support the preferred form and SHOULD 1767 support both the alternate text form and the FQDN format for IPv6 1768 addresses. 1770 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1771 referring to configuration data local to the Diameter client that 1772 describes the interface and medium-specific address to use. 1774 7.4.4 Tunnel-Server-Endpoint AVP 1776 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and 1777 contains the address of the server end of the tunnel. It MAY be used 1778 in an authorization request as a hint to the server that a specific 1779 endpoint is desired, but the server is not required to honor the hint 1780 in the corresponding response. 1782 This AVP SHOULD be included in the ADIF Record of the corresponding 1783 Accounting-Request messages, in which case it indicates the address 1784 from which the tunnel was initiated. This AVP, along with the Tunnel- 1785 Client-Endpoint and Session-Id AVP [2], MAY be used to provide a 1786 globally unique means to identify a tunnel for accounting and 1787 auditing purposes. 1789 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1790 fully qualified domain name (FQDN) of the tunnel client machine, or 1791 it is a "dotted-decimal" IP address. Conformant implementations MUST 1792 support the dotted-decimal format and SHOULD support the FQDN format 1793 for IP addresses. 1795 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1796 FQDN of the tunnel client machine, or it is a text representation of 1797 the address in either the preferred or alternate form [5]. 1798 Conformant implementations MUST support the preferred form and SHOULD 1799 support both the alternate text form and the FQDN format for IPv6 1800 addresses. 1802 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1803 referring to configuration data local to the Diameter client that 1804 describes the interface and medium-specific address to use. 1806 7.4.5 Tunnel-Password AVP 1808 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1809 contain a password to be used to authenticate to a remote server. 1810 This AVP MUST only be present in authorization responses in an 1811 encrypted form, using one of the methods described in [2] and [13]. 1813 7.4.6 Tunnel-Private-Group-ID AVP 1815 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type UTF8String, 1816 and contains the group ID for a particular tunneled session. The 1817 Tunnel-Private-Group-ID AVP MAY be included in an authorization 1818 request if the tunnel initiator can pre-determine the group resulting 1819 from a particular connection and SHOULD be included in the 1820 authorization response if this tunnel session is to be treated as 1821 belonging to a particular private group. Private groups may be used 1822 to associate a tunneled session with a particular group of users. 1823 For example, it MAY be used to facilitate routing of unregistered IP 1824 addresses through a particular interface. This value SHOULD be 1825 included the corresponding ADIF-Record in the Accounting-Request 1826 which pertain to a tunneled session. 1828 7.4.7 Tunnel-Assignment-ID AVP 1830 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1831 is used to indicate to the tunnel initiator the particular tunnel to 1832 which a session is to be assigned. Some tunneling protocols, such as 1833 PPTP [14] and L2TP, allow for sessions between the same two tunnel 1834 endpoints to be multiplexed over the same tunnel and also for a given 1835 session to utilize its own dedicated tunnel. This attribute provides 1836 a mechanism for Diameter to be used to inform the tunnel initiator 1837 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1838 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1839 sharing multiplexed tunnels to be assigned to different multiplexed 1840 tunnels. 1842 A particular tunneling implementation may assign differing 1843 characteristics to particular tunnels. For example, different 1844 tunnels may be assigned different QOS parameters. Such tunnels may 1845 be used to carry either individual or multiple sessions. The Tunnel- 1846 Assignment-ID attribute thus allows the Diameter server to indicate 1847 that a particular session is to be assigned to a tunnel that provides 1848 an appropriate level of service. It is expected that any QOS-related 1849 Diameter tunneling attributes defined in the future that accompany 1850 this attribute will be associated by the tunnel initiator with the ID 1851 given by this attribute. In the meantime, any semantic given to a 1852 particular ID string is a matter left to local configuration in the 1853 tunnel initiator. 1855 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1856 the tunnel initiator. The ID it specifies is intended to be of only 1857 local use to Diameter and the tunnel initiator. The ID assigned by 1858 the tunnel initiator is not conveyed to the tunnel peer. 1860 This attribute MAY be included in authorization responses. The tunnel 1861 initiator receiving this attribute MAY choose to ignore it and assign 1862 the session to an arbitrary multiplexed or non-multiplexed tunnel 1863 between the desired endpoints. This attribute SHOULD also be 1864 included in the corresponding ADIF-Record in the Accounting-Request 1865 messages which pertain to a tunneled session. 1867 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1868 should assign a session to a tunnel in the following manner: 1870 - If this AVP is present and a tunnel exists between the specified 1871 endpoints with the specified ID, then the session should be 1872 assigned to that tunnel. 1874 - If this AVP is present and no tunnel exists between the 1875 specified endpoints with the specified ID, then a new tunnel 1876 should be established for the session and the specified ID 1877 should be associated with the new tunnel. 1879 - If this AVP is not present, then the session is assigned to an 1880 unnamed tunnel. If an unnamed tunnel does not yet exist between 1881 the specified endpoints then it is established and used for this 1882 and subsequent sessions established without the Tunnel- 1883 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1884 session for which a Tunnel-Assignment-ID AVP was not specified 1885 to a named tunnel (i.e. one that was initiated by a session 1886 specifying this AVP). 1888 Note that the same ID may be used to name different tunnels if such 1889 tunnels are between different endpoints. 1891 7.4.8 Tunnel-Preference AVP 1893 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1894 used to identify the relative preference assigned to each tunnel when 1895 more than one set of tunneling AVPs is returned within separate 1896 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1897 hint to the server that a specific preference is desired, but the 1898 server is not required to honor the hint in the corresponding 1899 response. 1901 For example, suppose that AVPs describing two tunnels are returned by 1902 the server, one with a Tunnel-Type of PPTP and the other with a 1903 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1904 the Tunnel-Types returned, it will initiate a tunnel of that type. 1905 If, however, it supports both tunnel protocols, it SHOULD use the 1906 value of the Tunnel-Preference AVP to decide which tunnel should be 1907 started. The tunnel having the numerically lowest value in the Value 1908 field of this AVP SHOULD be given the highest preference. The values 1909 assigned to two or more instances of the Tunnel-Preference AVP within 1910 a given authorization response MAY be identical. In this case, the 1911 tunnel initiator SHOULD use locally configured metrics to decide 1912 which set of AVPs to use. 1914 7.4.9 Tunnel-Client-Auth-ID AVP 1916 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1917 specifies the name used by the tunnel initiator during the 1918 authentication phase of tunnel establishment. It MAY be used in an 1919 authorization request as a hint to the server that a specific 1920 preference is desired, but the server is not required to honor the 1921 hint in the corresponding response. This AVP MUST be present in the 1922 authorization response if an authentication name other than the 1923 default is desired. This AVP SHOULD be included in the corresponding 1924 ADIF-Record of the Accounting-Request messages which pertain to a 1925 tunneled session. 1927 7.4.10 Tunnel-Server-Auth-ID AVP 1929 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1930 and specifies the name used by the tunnel terminator during the 1931 authentication phase of tunnel establishment. It MAY be used in an 1932 authorization request as a hint to the server that a specific 1933 preference is desired, but the server is not required to honor the 1934 hint in the corresponding response. This AVP MUST be present in the 1935 authorization response if an authentication name other than the 1936 default is desired. This AVP SHOULD be included in the corresponding 1937 ADIF-Record of the Accounting-Request messages which pertain to a 1938 tunneled session. 1940 8.0 Accounting AVPs 1942 This section contains a description of the AVPs defined in this 1943 document that are to be included in Diameter accounting messages [2]. 1945 8.1 Accounting-Input-Extended-Octets AVP 1947 The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type 1948 Unsigned64, and contains the number of octets in IP packets received 1949 by the user. 1951 8.2 Accounting-Output-Extended-Octets AVP 1953 The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type 1954 Unsigned64, and contains the number of octets in IP packets sent to 1955 the user. 1957 8.3 Accounting-Session-Time AVP 1959 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1960 and indicates the length of the current session in seconds. 1962 8.4 Accounting-Input-Extended-Packets AVP 1964 The Accounting-Input-Extended-Packets (AVP Code 365) is of type 1965 Unsigned64, and contains the number of IP packets received by the 1966 user. 1968 8.5 Accounting-Output-Extended-Packets AVP 1970 The Accounting-Output-Extended-Packets (AVP Code 366) is of type 1971 Unsigned64, and contains the number of IP packets sent to the user. 1973 8.6 Accounting-Authentication-Type AVP 1975 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 1976 Unsigned32, and specifies how the user was authenticated. The 1977 supported values are listed in [34]. 1979 8.7 Acct-Tunnel-Connection AVP 1981 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 1982 and contains the identifier assigned to the tunnel session. This AVP, 1983 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1984 AVPs, may be used to provide a means to uniquely identify a tunnel 1985 session for auditing purposes. 1987 The format of the identifier in this AVP depends upon the value of 1988 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 1989 connection, the L2TP Tunnel ID and Call ID might be encoded in this 1990 field. The exact encoding of this field is implementation dependent. 1992 8.8 Acct-Tunnel-Packets-Lost AVP 1994 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 1995 and contains the number of packets lost on a given link. 1997 8.9 Accounting-EAP-Auth-Method AVP 1999 This Accounting-EAP-Auth-Method AVP (AVP Code 401) is of type 2000 Enumerated, and uses the EAP Type name space defined in [25]. 2002 9.0 RADIUS/Diameter Protocol Interactions 2004 This section describes some basic guidelines that may be used by 2005 servers that act as protocol gateways. Note that this document does 2006 not restrict implementations from creating other methods, as long as 2007 the bridging function doesn't break the RADIUS nor the Diameter 2008 protocol. 2010 There are essentially two different situations that must be handled; 2011 one where a RADIUS request is received that must be forwarded as a 2012 Diameter request, and the inverse. Note that this section uses two 2013 different terms; AVP and attribute. The former is used to signify a 2014 Diameter AVP, while the latter is used to signify a RADIUS attribute. 2016 9.1 RADIUS request forwarded as Diameter request 2018 This section describes the actions that should be followed when a 2019 protocol Gateway receives a RADIUS message that is to be translated 2020 to a Diameter message. 2022 It is important to note that RADIUS servers are inherently stateless, 2023 and this section maintains that assumption. It is quite possible for 2024 the RADIUS messages that comprises the session (i.e. authentication 2025 and accounting messages) be handled by different protocol gateways in 2026 the proxy network. Therefore a RADIUS->Diameter protocol gateway 2027 cannot maintain session state information. 2029 When a protocol gateway receives a RADIUS message, the following 2030 steps should be taken: 2032 - If the NAS-IP-Address attribute is present in the RADIUS 2033 message, the name MUST be translated to its corresponding FQDN, 2034 and encoded in the Diameter message's Origin-Host AVP. If the 2035 NAS-Identifier attribute is present, the data can be used in the 2036 Origin-Host AVP. 2037 - The Origin-Host AVP is added with the local server's identity. 2038 This will ensure that the corresponding response will be 2039 returned to the correct gateway server. The aaa protocol 2040 specified in the identity would be set to "radius". 2041 - The Destination-Realm AVP is created from the information found 2042 in the RADIUS User-Name attribute. 2043 - If the RADIUS CHAP-Password attribute is present, the Ident and 2044 Data portion of the attribute are used to create the CHAP-Auth 2045 Grouped AVP. 2046 - The Gateway Server must maintain state information relevant to 2047 the RADIUS request, such as the Identifier field in the RADIUS 2048 header, any existing RADIUS Proxy-State attribute as well as the 2049 source IP address and port number of the UDP packet. These may 2050 be maintained locally in a state table, or may be saved in a 2051 Proxy-Info AVP. 2052 - If the Acct-Session-Id attribute was found in the request, the 2053 contents are inserted in the Acct-Session-Id AVP. 2054 - If the RADIUS request contained a State attribute, and the 2055 prefix of the data is "Diameter/", the data following the prefix 2056 contains the Diameter Session-Id. If no such attributes are 2057 present, and the RADIUS command is an Access-Request, a new 2058 Session-Id is created. The Session-Id is included in the 2059 Session-Id AVP. 2060 - If the RADIUS message received is an Accounting-Request, with 2061 the Acct-Status-Type attribute set to STOP, the local server 2062 MUST issue a Session-Termination-Request message once the 2063 Diameter Accounting-Answer has been received. 2064 - If the RADIUS message contains the Accounting-Input-Octets, 2065 Accounting-Input-Packets, Accounting-Output-Octets or 2066 Accounting-Output-Packets, these attributes must be converted to 2067 the Diameter equivalent ones. Further, if the Acct-Input- 2068 Gigawords or Acct-Output-Gigawords attributes are present, these 2069 must be used to properly compute the Diameter accounting AVPs. 2071 The corresponding Diameter response is always guaranteed to be 2072 received by the same protocol gateway that translated the original 2073 request, due to the contents of the Origin-Host AVP in the Diameter 2074 request. The following steps are applied to the response message 2075 during the Diameter to RADIUS translation: 2077 - If the Diameter Command-Code is set to AA-Answer and the Result- 2078 Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must 2079 send a RADIUS Access-Challenge with the Diameter Session-Id and 2080 the Origin-Host AVPs encapsulated in the RADIUS State attribute, 2081 with the prefix "Diameter/". This is necessary in order to 2082 ensure that the protocol gateway that will receive the 2083 subsequent RADIUS Access-Request will have access to the Session 2084 Identifier, and be able to set the Destination-Host to the 2085 correct value. If the Multi-Round-Time-Out AVP is present, the 2086 value of the AVP MUST be inserted in the RADIUS Session-Timeout 2087 AVP. 2088 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 2089 AVP is saved in a new RADIUS Class attribute, whose format 2090 consists of the string "Diameter/" followed by the Diameter 2091 Session Identifier. This will ensure that the subsequent 2092 Accounting messages, which could be received by any protocol 2093 gateway, would have access to the original Diameter Session 2094 Identifier. 2095 - If a Proxy-State attribute was present in the RADIUS request, 2096 the same attribute is added in the response. This information 2097 may be found in the Proxy-Info AVP, or in a local state table. 2098 - If state information regarding the RADIUS request was saved in a 2099 Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and 2100 port number are extracted and used in issuing the RADIUS reply. 2102 9.2 Diameter request forwarded as RADIUS request 2104 When a server receives a Diameter request that is to be forwarded to 2105 a RADIUS entity, the following steps are an example of the steps that 2106 may be followed: 2108 - The Origin-Host AVP's value is inserted in the NAS-Identifier 2109 attribute. 2110 - The following information MUST be present in the corresponding 2111 Diameter response, and therefore MUST be saved either in a local 2112 state table, or it MAY be encoded in a RADIUS Proxy-State 2113 attribute: 2114 1. Origin-Host AVP 2115 2. Session-Id AVP 2116 3. Proxy-Info AVP 2117 4. Route-Record AVPs (in the proper order) 2118 5. Any other AVP that MUST be present in the response, and 2119 has no corresponding RADIUS attribute. 2120 - If the CHAP-Auth AVP is present, the Grouped AVPs are used 2121 to create the RADIUS CHAP-Password. 2122 - If the Accounting-Input-Extended-Octets, Accounting-Input- 2123 Extended-Packets, Accounting-Output-Extended-Octets or 2124 Accounting-Output-Extended-Packets AVPs are present, these 2125 must be translated to the corresponding RADIUS attributes. 2126 Further, the the Diameter AVPs do not fit within a 32-bit 2127 RADIUS attribute, the RADIUS Acct-Input-Gigawords and 2128 Acct-Output-Gigawords must be used. 2130 When the corresponding response is received by the gateway server, 2131 which is guaranteed in the RADIUS protocol, the following steps may 2132 be followed: 2134 - If the RADIUS code is set to Access-Challenge, a Diameter AA- 2135 Answer message is created with the Result-Code set to 2136 DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present 2137 in the RADIUS message, its value is inserted in the Multi-Round- 2138 Time-Out AVP. 2139 - If a Proxy-Info AVP is present, extract the encoded information, 2140 otherwise retrieve the information from the local state table. 2141 - The request's Origin-Host information is added to the 2142 Destination-Host AVP. 2143 - The Session-Id information is added to the Session-Id AVP. 2144 - The Route-Record AVPs MUST be added to the Diameter message, in 2145 the same order they were present in the request. 2146 - If a Proxy-Info AVP was present in the request, the same AVP 2147 MUST be added to the response. 2148 - If the RADIUS State attributes are present, these attributes 2149 must be present in the Diameter response. 2150 - Any other AVPs that were saved, and MUST be present in the 2151 response, are added to the message. 2153 10.0 AVP Occurrence Table 2155 The following tables presents the AVPs defined in this document, and 2156 specifies in which Diameter messages they MAY, or MAY NOT be present. 2157 Note that AVPs that can only be present within a Grouped AVP are not 2158 represented in this table. 2160 The table uses the following symbols: 2161 0 The AVP MUST NOT be present in the message. 2162 0+ Zero or more instances of the AVP MAY be present in the 2163 message. 2164 0-1 Zero or one instance of the AVP MAY be present in the 2165 message. 2166 1 One instance of the AVP MUST be present in the message. 2168 10.1 NASREQ Command AVP Table 2170 The table in this section is limited to the Command Codes defined in 2171 this specification. 2173 +-----------------------+ 2174 | Command-Code | 2175 |-----+-----+-----+-----+ 2176 Attribute Name | AAR | AAA | DER | DEA | 2177 ------------------------------|-----+-----+-----+-----| 2178 ARAP-Challenge-Response | 0 | 0-1 | 0 | 0-1 | 2179 ARAP-Features | 0 | 0-1 | 0 | 0-1 | 2180 ARAP-Password | 0-1 | 0 | 0 | 0 | 2181 ARAP-Security | 0-1 | 0 | 0 | 0 | 2182 ARAP-Security-Data | 0+ | 0 | 0 | 0 | 2183 ARAP-Zone-Access | 0 | 0-1 | 0 | 0-1 | 2184 Auth-Application-Id | 1 | 1 | 1 | 1 | 2185 Auth-Grace-Period | 0-1 | 0-1 | 0-1 | 0-1 | 2186 Auth-Session-State | 0-1 | 0-1 | 0-1 | 0-1 | 2187 Authorization-Lifetime | 0-1 | 0-1 | 0-1 | 0-1 | 2188 Callback-Id | 0 | 0-1 | 0 | 0-1 | 2189 Callback-Number | 0-1 | 0-1 | 0-1 | 0-1 | 2190 Called-Station-Id | 0-1 | 0 | 0-1 | 0 | 2191 Calling-Station-Id | 0-1 | 0 | 0-1 | 0 | 2192 CHAP-Auth | 0-1 | 0 | 0 | 0 | 2193 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 2194 Connect-Info | 0-1 | 0 | 0-1 | 0 | 2195 Destination-Host | 0+ | 0 | 0+ | 0 | 2196 Destination-Realm | 1 | 0 | 1 | 0 | 2197 EAP-Payload | 0 | 0 | 1 | 1 | 2198 Error-Message | 0 | 0-1 | 0 | 0-1 | 2199 Error-Reporting-Host | 0 | 0-1 | 0 | 0+ | 2200 Filter-Id | 0 | 0+ | 0 | 0+ | 2201 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0-1 | 2202 Framed-Appletalk-Network | 0 | 0+ | 0 | 0+ | 2203 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0-1 | 2204 Framed-Compression | 0+ | 0+ | 0+ | 0+ | 2205 Framed-Interface-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2206 Framed-IPv6-Prefix | 0+ | 0+ | 0+ | 0+ | 2207 Framed-IPv6-Pool | 0-1 | 0-1 | 0-1 | 0-1 | 2208 Framed-IPv6-Route | 0+ | 0+ | 0+ | 0+ | 2209 Framed-IP-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2210 Framed-IP-Netmask | 0-1 | 0-1 | 0-1 | 0-1 | 2211 +-----------------------+ 2212 | Command-Code | 2213 |-----+-----+-----+-----+ 2214 Attribute Name | AAR | AAA | DER | DEA | 2215 ------------------------------|-----+-----+-----+-----| 2216 Framed-IP-Route | 0 | 0+ | 0 | 0+ | 2217 Framed-IPX-Network | 0 | 0-1 | 0 | 0-1 | 2218 Framed-MTU | 0 | 0-1 | 0 | 0-1 | 2219 Framed-Protocol | 0-1 | 0 | 0-1 | 0 | 2220 Framed-Routing | 0-1 | 0 | 0-1 | 0 | 2221 Idle-Timeout | 0-1 | 0-1 | 0-1 | 0-1 | 2222 Login-IP-Host | 0+ | 0+ | 0 | 0 | 2223 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2224 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2225 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2226 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2227 Login-Service | 0 | 0+ | 0 | 0 | 2228 Login-TCP-Port | 0 | 0+ | 0 | 0 | 2229 NAS-Filter-Rule | 0 | 0+ | 0 | 0+ | 2230 NAS-IP-Address | 1 | 0 | 1 | 0 | 2231 NAS-Key-Binding | 0-1 | 0 | 0-1 | 0 | 2232 NAS-Port | 1 | 0 | 1 | 0 | 2233 NAS-Port-Type | 0-1 | 0 | 0-1 | 0 | 2234 NAS-Session-Key | 0 | 0+ | 0 | 0+ | 2235 Origin-Host | 1 | 1 | 1 | 1 | 2236 Origin-Realm | 1 | 1 | 1 | 1 | 2237 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2238 Password-Retry | 0 | 0-1 | 0 | 0 | 2239 Port-Limit | 0-1 | 0 | 0-1 | 0 | 2240 Prompt | 0 | 0-1 | 0 | 0 | 2241 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 2242 Redirect-Host | 0 | 0+ | 0 | 0+ | 2243 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 2244 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 2245 Reply-Message | 0 | 0 | 0 | 0 | 2246 Result-Code | 0 | 1 | 0 | 1 | 2247 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0-1 | 2248 Route-Record | 0+ | 0 | 0+ | 0 | 2249 Service-Type | 1 | 1 | 1 | 1 | 2250 Session-Id | 1 | 1 | 1 | 1 | 2251 Session-Timeout | 0-1 | 0-1 | 0 | 0-1 | 2252 State | 0-1 | 0-1 | 0 | 0-1 | 2253 Tunneling | 0+ | 0+ | 0+ | 0+ | 2254 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 2255 User-Password | 0-1 | 0 | 0 | 0 | 2257 10.2 Accounting AVP Table 2258 The tables in this section are used to represent which AVPs defined 2259 in this document are to be present in the Accounting messages, 2260 defined in [1]. 2262 10.2.1 Framed Access 2264 The table in this section is used when the Service-Type specifies 2265 Framed Access. 2267 +-----------+ 2268 | Command | 2269 | Code | 2270 |-----+-----+ 2271 Attribute Name | ACR | ACA | 2272 ---------------------------------------|-----+-----+ 2273 Accounting-Authentication-Type | 1 | 0-1 | 2274 Accounting-EAP-Auth-Method | 1 | 0-1 | 2275 Accounting-Input-Extended-Octets | 1 | 1 | 2276 Accounting-Input-Extended-Packets | 1 | 1 | 2277 Accounting-Output-Extended-Octets | 1 | 1 | 2278 Accounting-Output-Extended-Packets | 1 | 1 | 2279 Accounting-Session-Time | 1 | 1 | 2280 Accounting-State | 0 | 0 | 2281 Acct-Tunnel-Connection | 0-1 | 0-1 | 2282 Acct-Tunnel-Packets-Lost | 0-1 | 0-1 | 2283 Framed-AppleTalk-Link | 0-1 | 0-1 | 2284 Framed-AppleTalk-Network | 0-1 | 0-1 | 2285 Framed-AppleTalk-Zone | 0-1 | 0-1 | 2286 Framed-Compression | 0-1 | 0-1 | 2287 Framed-IP-Address | 0-1 | 0-1 | 2288 +-----------+ 2289 | Command | 2290 | Code | 2291 |-----+-----+ 2292 Attribute Name | ACR | ACA | 2293 ------------------------------|-----+-----+ 2294 Framed-IP-Netmask | 0-1 | 0-1 | 2295 Framed-IPX-Network | 0-1 | 0-1 | 2296 Framed-MTU | 0-1 | 0-1 | 2297 Framed-Protocol | 0-1 | 0-1 | 2298 Framed-Route | 0-1 | 0-1 | 2299 Framed-Routing | 0-1 | 0-1 | 2300 Service-Type | 1 | 1 | 2301 Tunnel-Assignment-ID | 0-1 | 0-1 | 2302 Tunnel-Client-Endpoint | 0-1 | 0-1 | 2303 Tunnel-Medium-Type | 0-1 | 0-1 | 2304 Tunnel-Private-Group-ID | 0-1 | 0-1 | 2305 Tunnel-Server-Endpoint | 0-1 | 0-1 | 2306 Tunnel-Type | 0-1 | 0-1 | 2307 ------------------------------|-----+-----+ 2309 10.2.2 Non-Framed Access 2311 The table in this section is used when the Service-Type specifies 2312 Non-Framed Access. 2314 +-----------+ 2315 | Command | 2316 | Code | 2317 |-----+-----+ 2318 Attribute Name | ACR | ACA | 2319 ---------------------------------------|-----+-----+ 2320 Accounting-Authentication-Type | 1 | 0-1 | 2321 Accounting-Input-Extended-Octets | 1 | 1 | 2322 Accounting-Input-Extended-Packets | 1 | 1 | 2323 Accounting-Output-Extended-Octets | 1 | 1 | 2324 Accounting-Output-Extended-Packets | 1 | 1 | 2325 Accounting-Session-Time | 1 | 1 | 2326 Accounting-State | 0 | 0 | 2327 Login-IP-Host | 0-1 | 0-1 | 2328 Login-LAT-Service | 0-1 | 0-1 | 2329 Login-LAT-Node | 0-1 | 0-1 | 2330 Login-LAT-Group | 0-1 | 0-1 | 2331 Login-LAT-Port | 0-1 | 0-1 | 2332 Login-Service | 0-1 | 0-1 | 2333 Login-TCP-Port | 0-1 | 0-1 | 2334 Service-Type | 1 | 1 | 2335 ---------------------------------------|-----+-----+ 2337 11.0 IANA Considerations 2339 This section contains the namespaces that have either been created in 2340 this specification, or the values assigned to existing namespaces 2341 managed by IANA. 2343 11.1 Command Codes 2345 This specification assigns the values 265 and 268 from the Command 2346 Code namespace defined in [2]. See sections 3.1 and 4.2 for the 2347 assignment of the namespace in this specification. 2349 11.2 AVP Codes 2351 This specification assigns the values 363-366 and 400-412 from the 2352 AVP Code namespace defined in [2]. See section 2.1 for the assignment 2353 of the namespace in this specification. 2355 This specification also makes use of AVPs in the 0-255 range, which 2356 are defined in [34]. 2358 11.3 Application Identifier 2360 This specification assigns the value one (1) to the Application 2361 Identifier namespace defined in [1]. See section 1.2 for more 2362 information. 2364 11.4 NAS-Key-Binding AVP Values 2366 As defined in Section 2.1.6, the NAS-Key-Binding AVP (AVP Code 404) 2367 defines the values 1-4. All remaining values, other than zero, are 2368 available for assignment via a Designated Expert [12]. 2370 11.5 NAS-Key-Direction AVP Values 2372 As defined in Section 2.1.3, the NAS-Key-Direction AVP (AVP Code 406) 2373 defines the values 1-3. All remaining values, other than zero, are 2374 available for assignment via IETF Consensus [12]. 2376 11.6 NAS-Key-Type AVP Values 2378 As defined in Section 2.1.4, the NAS-Key-Type AVP (AVP Code 407) 2379 defines the values 1-5. All remaining values, other than zero, are 2380 available for assignment via IETF Consensus [12]. 2382 11.7 CHAP-Algorithm AVP Values 2384 As defined in Section 3.1.1.4, the CHAP-Algorithm AVP (AVP Code 412) 2385 uses the values of the "PPP AUTHENTICATION ALGORITHMS" namespace 2386 defined in [6]. 2388 12.0 Security Considerations 2390 This document does not contain any security protocol, but does 2391 discuss how PPP authentication protocols can be carried within the 2392 Diameter protocol. The PPP authentication protocols that are 2393 described are PAP, CHAP and EAP. 2395 The use of PAP SHOULD be discouraged, since it exposes user's 2396 passwords to possibly non-trusted entities. PAP is also frequently 2397 used for use with One-Time Passwords (OTP), which does not expose any 2398 security risks. However, it is highly recommended that OTP be 2399 supported through the EAP protocol. 2401 This document also describes how CHAP can be carried within the 2402 Diameter protocol, which is required for backward RADIUS 2403 compatibility. The CHAP protocol, as used in a RADIUS environment, 2404 facilitates authentication replay attacks, and therefore SHOULD NOT 2405 be used when EAP is available. 2407 This specification also defines a method by which the home Diameter 2408 server can create and distribute registration keys to be used to 2409 authenticate link layer messages (e.g. PPP ECP). The keys SHOULD be 2410 be protected using the methods defined in [13]. 2412 13.0 References 2414 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica- 2415 tion Dial In User Service (RADIUS)", RFC 2865, June 2000. 2417 [2] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter 2418 Base Protocol", draft-ietf-aaa-diameter-08.txt, IETF work in 2419 progress, November 2001. 2421 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. January 2422 1999. 2424 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, 2425 January 1999. 2427 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2428 RFC 2373, July 1998 2430 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2431 (CHAP)", RFC 1994, August 1996. 2433 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial links", 2434 RFC 1144, February 1990. 2436 [8] ISO 8859. International Standard -- Information Processing -- 8-bit 2437 Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet 2438 No. 1, ISO 8859-1:1987. 2440 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol (MP)", 2441 RFC 1717, November 1994. 2443 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2444 October 1994 2446 [11] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications for 2447 Tunnel Protocol Support", RFC 2867, June 2000. 2449 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 2450 els", BCP 14, RFC 2119, March 1997. 2452 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Applica- 2453 tion", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in 2454 progress, November 2001. 2456 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, 2457 G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999 2459 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forward- 2460 ing (Protocol) 'L2F'", RFC 2341, May 1998 2462 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., 2463 Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 2464 1999 2466 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 2467 February 1997 2469 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2470 Protocol", RFC 2401, November 1998 2472 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 2474 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 2475 1996 2477 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 2478 August 1995 2480 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2481 Encapsulation (GRE)", RFC 1701, October 1994 2483 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2485 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2486 Server Protocols", RFC 3169, September 2001. 2488 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro- 2489 tocol (EAP)." RFC 2284, March 1998. 2491 [26] G. Pall, G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Pro- 2492 tocol", RFC 3078, March 2001. 2494 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considerations 2495 Section in RFCs", BCP 26, RFC 2434, October 1998 2497 [28] G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications for 2498 Tunnel Protocol Support", RFC 2867, June 2000. 2500 [29] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2501 2279, January 1998. 2503 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft- 2504 ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November 2505 2001. 2507 [31] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret, 2508 "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2509 2000. 2511 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2869, 2512 June 2000. 2514 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret, 2515 "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2516 2000. 2518 [34] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign- 2519 ments/radius-types 2521 [35] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2523 [36] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, Version 2 2524 (DESE-bis)", RFC 2419, September 1998. 2526 [37] H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2527 2402, September 1998. 2529 [38] B. Aboba, G. Zorn, D. Mitton, "RADIUS and IPv6", RFC 3162, August 2530 2001. 2532 [39] Information technology - Telecommunications and information 2533 exchange between systems - Local and metropolitan area networks - 2534 Specific Requirements Part 11: Wireless LAN Medium Access Control 2535 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 2536 802.11-1999, 1999. 2538 14.0 Acknowledgements 2540 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2541 Allen Simpson, and Steve Willens for their work on the original 2542 RADIUS, from which much of the concepts in this specification were 2543 derived; Carl Rigney and Ward Willats for [32]; Bernard Aboba and 2544 Dave Mitton for [38]; Dory Leifer, John Shriver, Matt Holdrege and 2545 Ignacio Goyret for their work on [33]. This document stole text and 2546 concepts from both [32] and [33]. Thanks goes to Carl Williams for 2547 providing IPv6 specific text. 2549 The authors would also like to acknowledge the following people for 2550 their contributions in the development of the Diameter protocol: 2552 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2553 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2554 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2555 and Jeff Weisberg 2557 Finally, Pat Calhoun would like to thank Sun Microsystems since most 2558 of the effort put into this document was done while he was in their 2559 employ. 2561 15.0 Authors' Addresses 2563 Questions about this memo can be directed to: 2565 Pat R. Calhoun 2566 Black Storm Networks 2567 250 Cambridge Avenue, Suite 200 2568 Palo Alto, California, 94306 2569 USA 2571 Phone: +1 650-617-2932 2572 Fax: +1 650-786-6445 2573 E-mail: pcalhoun@diameter.org 2575 William Bulley 2576 Merit Network, Inc. 2577 Building One, Suite 2000 2578 4251 Plymouth Road 2579 Ann Arbor, Michigan 48105-2785 2580 USA 2582 Phone: +1 734-764-9993 2583 Fax: +1 734-647-3185 2584 E-mail: web@merit.edu 2585 Allan C. Rubens 2586 Tut Systems, Inc. 2587 220 E. Huron, Suite 260 2588 Ann Arbor, MI 48104 2589 USA 2591 Phone: +1 734-995-1697 2592 E-Mail: arubens@tutsys.com 2594 Jeff Haag 2595 Cisco Systems 2596 7025 Kit Creek Road 2597 PO Box 14987 2598 Research Triangle Park, NC 27709 2600 Phone: 1-919-392-2353 2601 E-Mail: haag@cisco.com 2603 Glen Zorn 2604 Cisco Systems, Inc. 2605 500 108th Avenue N.E., Suite 500 2606 Bellevue, WA 98004 2607 USA 2609 Phone: +1 425 471 4861 2610 E-Mail: gwz@cisco.com 2612 16.0 Full Copyright Statement 2614 Copyright (C) The Internet Society (2001). All Rights Reserved. 2616 This document and translations of it may be copied and furnished to 2617 others, and derivative works that comment on or otherwise explain it 2618 or assist in its implementation may be prepared, copied, published 2619 and distributed, in whole or in part, without restriction of any 2620 kind, provided that the above copyright notice and this paragraph are 2621 included on all such copies and derivative works. However, this docu- 2622 ment itself may not be modified in any way, such as by removing the 2623 copyright notice or references to the Internet Society or other 2624 Internet organizations, except as needed for the purpose of develop- 2625 ing Internet standards in which case the procedures for copyrights 2626 defined in the Internet Standards process must be followed, or as 2627 required to translate it into languages other than English. The lim- 2628 ited permissions granted above are perpetual and will not be revoked 2629 by the Internet Society or its successors or assigns. This document 2630 and the information contained herein is provided on an "AS IS" basis 2631 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2632 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2633 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2634 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2635 FITNESS FOR A PARTICULAR PURPOSE. 2637 17.0 Expiration Date 2639 This memo is filed as and 2640 expires in May 2002.