idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 2660 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? 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 198 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == 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 539 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2458, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2470, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2483, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2496, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2503, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2506, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2509, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2511, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2514, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2517, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2520, but no explicit reference was found in the text == Unused Reference: '26' is defined on line 2528, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 2531, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2534, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 2537, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2544, but no explicit reference was found in the text == Unused Reference: '34' is defined on line 2554, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2556, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2559, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2562, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-10 ** 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') -- 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-09 ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '31') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '32') -- Possible downref: Non-RFC (?) normative reference: ref. '33' ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '34') ** Obsolete normative reference: RFC 2402 (ref. '36') (Obsoleted by RFC 4302, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. '38' Summary: 28 errors (**), 0 flaws (~~), 28 warnings (==), 8 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 David Spence | 12 Interlink Networks, Inc. | 13 March 2002 | 15 Diameter NASREQ Application 17 Status of this Memo 19 This document is an Internet-Draft and is subject to all provisions | 20 of Section 10 of RFC2026. | 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at: 34 http://www.ietf.org/1id-abstracts.html | 36 The list of Internet-Draft Shadow Directories can be accessed at: 38 http://www.ietf.org/shadow.html. 40 This memo describes work in progress within the AAA Working Group. | 41 Comments are welcome and should be submitted to aaa-wg@merit.edu. 43 Distribution of this memo is unlimited. 45 Copyright (C) The Internet Society 2002. All Rights Reserved. | 47 Abstract 49 This document describes the Diameter application that is used for AAA 50 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 51 application, combined with the base protocol, satisfies the 52 requirements defined in the NASREQ AAA criteria specification and the 53 ROAMOPS AAA Criteria specification. 55 Given that it is expected that initial deployments of the Diameter 56 protocol in a dial-up environment will include legacy systems, this 57 application was carefully designed to ease the burden of servers that 58 must perform protocol conversion between RADIUS and Diameter. This 59 is achieved by re-using the RADIUS address space, eliminating the 60 need to perform attribute lookups. 62 Table of Contents 64 1.0 Introduction 65 1.1 Requirements language 66 1.2 Advertising application support 67 2.0 Supported AVPs 68 2.1 Diameter AVPs 69 2.1.1 NAS-Filter-Rule AVP 70 2.1.2 NAS-Session-Key AVP 71 2.1.3 NAS-Key-Direction AVP 72 2.1.4 NAS-Key-Type AVP 73 2.1.5 NAS-Key-Data AVP 74 2.1.6 NAS-Key-Binding AVP 75 2.1.7 NAS-Key-Lifetime AVP 76 2.1.8 NAS-IV AVP 77 2.2 Legacy RADIUS Attributes 78 2.2.1 NAS-IP-Address AVP 79 2.2.2 NAS-Identifier AVP 80 2.2.3 State AVP 81 3.0 Legacy RADIUS Authentication Support 82 3.1 Command-Codes Values 83 3.1.1 AA-Request (AAR) Command 84 3.1.1.1 User-Password AVP 85 3.1.1.2 CHAP-Auth AVP 86 3.1.1.3 CHAP-Ident AVP 87 3.1.1.4 CHAP-Algorithm AVP 88 3.1.1.5 CHAP-Response AVP 89 3.1.1.6 CHAP-Challenge AVP 90 3.1.1.7 ARAP-Password AVP 91 3.1.2 AA-Answer (AAA) Command 92 3.1.2.1 ARAP-Challenge-Response AVP 93 3.1.2.2 Password-Retry AVP 94 3.1.2.3 Prompt AVP 95 3.2 Reply-Message AVP 96 4.0 Extensible Authentication Protocol Support 97 4.1 Alternative Uses 98 4.2 Command-Codes Values 99 4.2.1 Diameter-EAP-Request (DER) Command 100 4.2.2 Diameter-EAP-Answer (DEA) Command 101 4.3 EAP-Payload AVP 102 5.0 Diameter Session Termination 103 6.0 Call and Session Information 104 6.1 NAS-Port AVP 105 6.2 Filter-Id AVP 106 6.3 Callback-Number AVP 107 6.4 Callback-Id AVP 108 6.5 Idle-Timeout AVP 109 6.6 Called-Station-Id AVP 110 6.7 Calling-Station-Id AVP 111 6.8 NAS-Port-Type AVP 112 6.9 Port-Limit AVP 113 6.10 Connect-Info AVP 114 7.0 Service Specific Authorization AVPs 115 7.1 Service-Type AVP 116 7.2 Framed Access Authorization AVPs 117 7.2.1 Framed-Protocol AVP 118 7.2.2 Framed-Routing AVP 119 7.2.3 Framed-MTU AVP 120 7.2.4 Framed-Compression AVP 121 7.2.5 IP Access 122 7.2.5.1 Framed-IP-Address AVP 123 7.2.5.2 Framed-IP-Netmask AVP 124 7.2.5.3 Framed-IP-Route AVP 125 7.2.5.4 Framed-Interface-Id AVP 126 7.2.5.5 Framed-IPv6-Prefix AVP 127 7.2.5.6 Framed-IPv6-Route AVP 128 7.2.5.7 Framed-IPv6-Pool AVP 129 7.2.6 IPX Access 130 7.2.6.1 Framed-IPX-Network AVP 131 7.2.7 Appletalk Access 132 7.2.7.1 Framed-AppleTalk-Link AVP 133 7.2.7.2 Framed-AppleTalk-Network AVP 134 7.2.7.3 Framed-AppleTalk-Zone AVP 135 7.2.8 ARAP Access 136 7.2.8.1 ARAP-Features AVP 137 7.2.8.2 ARAP-Zone-Access AVP 138 7.2.8.3 ARAP-Security AVP 139 7.2.8.4 ARAP-Security-Data AVP 140 7.3 Non-Framed Access Authorization AVPs 141 7.3.1 Login-IP-Host AVP 142 7.3.2 Login-Service AVP 143 7.3.3 TCP Services 144 7.3.3.1 Login-TCP-Port AVP 145 7.3.4 LAT Services 146 7.3.4.1 Login-LAT-Service AVP 147 7.3.4.2 Login-LAT-Node AVP 148 7.3.4.3 Login-LAT-Group AVP 149 7.3.4.4 Login-LAT-Port AVP 150 7.4 Tunneling AVPs | 151 7.4.1 Tunnel-Type AVP 152 7.4.2 Tunnel-Medium-Type AVP 153 7.4.3 Tunnel-Client-Endpoint AVP 154 7.4.4 Tunnel-Server-Endpoint AVP 155 7.4.5 Tunnel-Password AVP 156 7.4.6 Tunnel-Private-Group-ID AVP 157 7.4.7 Tunnel-Assignment-ID AVP 158 7.4.8 Tunnel-Preference AVP 159 7.4.9 Tunnel-Client-Auth-ID AVP 160 7.4.10 Tunnel-Server-Auth-ID AVP 161 8.0 Accounting Considerations 162 8.1 Accounting-Input-Octets AVP | 163 8.2 Accounting-Output-Octets AVP | 164 8.3 Acct-Session-Time AVP | 165 8.4 Accounting-Input-Packets AVP | 166 8.5 Accounting-Output-Packets AVP | 167 8.6 Accounting-Authentication-Type AVP 168 8.7 Acct-Tunnel-Connection AVP 169 8.8 Acct-Tunnel-Packets-Lost AVP 170 8.9 Accounting-EAP-Auth-Method AVP 171 9.0 RADIUS/Diameter Protocol Interactions 172 9.1 RADIUS request forwarded as Diameter request 173 9.2 Diameter request forwarded as RADIUS request 174 10.0 AVP Occurrence Table 175 10.1 NASREQ Command AVP Table 176 10.2 Accounting AVP Table 177 10.2.1 Framed Access 178 10.2.2 Non-Framed Access 179 11.0 IANA Considerations 180 11.1 Command Codes 181 11.2 AVP Codes 182 11.3 Application Identifier 183 11.4 NAS-Key-Binding AVP Values 184 11.5 NAS-Key-Direction AVP Values 185 11.6 NAS-Key-Type AVP Values 186 11.7 CHAP-Algorithm AVP Values 187 12.0 Security Considerations 188 13.0 References 189 14.0 Acknowledgements 190 15.0 Authors' Addresses 191 16.0 Full Copyright Statement 193 1.0 Introduction 195 This document describes the Diameter application that is used for AAA 196 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 197 application, combined with the base protocol [2], satisfies the 198 requirements defined in the NASREQ AAA criteria specification [24] 199 and the ROAMOPS AAA Criteria specification [4]. 201 This document is divided into three main sections. The first section 202 defines the Diameter Command-Codes and AVPs that are needed to 203 support legacy authentication protocols, those that are typically 204 supported by RADIUS [1] servers. The second section defines the 205 Command-Codes and AVPs necessary for a Diameter node to support PPP's 206 Extensible Authentication Protocol (EAP) [25]. The third section 207 contains the Authorization AVPs that are needed for the various 208 services offered by a NAS, such as PPP dial-in, terminal server and 209 tunneling applications, such as L2TP [16]. 211 Given that it is expected that initial deployments of the Diameter 212 protocol in a dial-up environment will include legacy systems, this 213 application was carefully designed to ease the burden of servers that 214 must perform protocol conversion between RADIUS and Diameter. This 215 is achieved by re-using the RADIUS address space, eliminating the 216 need to perform attribute lookups. 218 1.1 Requirements language 220 In this document, the key words "MAY", "MUST", "MUST NOT", | 221 "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be | 222 interpreted as described in [12]. 224 1.2 Advertising application support 226 Diameter nodes conforming to this specification MAY advertise support 227 by including the value of one (1) in the Auth-Application-Id or the 228 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 229 Capabilities-Exchange-Answer command [2]. 231 2.0 Supported AVPs 233 This section lists all of the Diameter AVPs and the legacy RADIUS 234 attributes supported by this application. 236 2.1 Diameter AVPs 238 This section will define all of the AVPs that are not backward 239 compatible with the RADIUS protocol [1]. A Diameter message that 240 includes one of these AVPs MAY cause interoperability issues should 241 the request traverse a AAA node that only supports the RADIUS | 242 protocol. However, the Diameter protocol should not be hampered from 243 future developments due to the existing installed base. 245 The following table describes the Diameter AVPs defined in the NASREQ 246 application, their AVP Code values, types, possible flag values and 247 whether the AVP MAY be encrypted. 249 Due to space constraints, the short form IPFiltrRule is used to 250 represent IPFilterRule. 252 +---------------------+ 253 | AVP Flag rules | 254 |----+-----+----+-----|----+ 255 AVP Section | | |SHLD| MUST|MAY | 256 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 257 -----------------------------------------|----+-----+----+-----|----| 258 Accounting- 363 8.1 Unsigned64 | M | P | | V | Y | | 259 Input-Octets | | | | | | | 260 Accounting- 365 8.4 Unsigned64 | M | P | | V | Y | | 261 Input-Packets | | | | | | | 262 Accounting- 364 8.2 Unsigned64 | M | P | | V | Y | | 263 Output-Octets | | | | | | | 264 Accounting- 366 8.5 Unsigned64 | M | P | | V | Y | | 265 Output-Packets | | | | | | | 266 Accounting-EAP- 401 8.9 Enumerated | M | P | | V | Y | | 267 Auth-Method | | | | | | | 268 CHAP-Auth 409 3.1.1.2 Grouped | M | P | | V | Y | | 269 CHAP-Algorithm 412 3.1.1.4 Enumerated | M | P | | V | Y | | 270 CHAP-Ident 410 3.1.1.3 OctetString| M | P | | V | Y | | 271 CHAP-Response 411 3.1.1.5 OctetString| M | P | | V | Y | | 272 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 273 NAS-Filter-Rule 400 2.1.1 IPFiltrRule| M | P | | V | Y | 274 NAS-Key-Binding 404 2.1.6 Enumerated | M | P | | V | Y | 275 NAS-Key-Data 405 2.1.5 OctetString| M | P | | V | N | 276 NAS-Key- 406 2.1.3 Enumerated | M | P | | V | N | 277 Direction | | | | | | 278 NAS-Key-Type 407 2.1.4 Enumerated | M | P | | V | N | 279 NAS-Key-Lifetime 413 2.1.7 Unsigned32 | M | P | | V | N | | 280 NAS-IV 414 2.1.8 OctetString| M | P | | V | N | | 281 NAS-Session-Key 408 2.1.2 Grouped | M | P | | V | Y | 282 Tunneling 403 7.4 Grouped | M | P | | V | N | 284 2.1.1 NAS-Filter-Rule AVP 286 The NAS-Filter-Rule AVP (AVP Code 400) is of type IPFilterRule, and 287 provides filter rules that need to be configured on the NAS for the 288 user. One or more such AVPs MAY be present in an authorization 289 response. 291 2.1.2 NAS-Session-Key AVP 293 The NAS-Session-Key AVP (AVP Code 408) is of type Grouped, and 294 contains a session key distributed from Diameter servers to clients. 295 The keys MAY be used for integrity and/or confidentiality protection 296 between the NAS and the user. The keys MAY be distributed to the user 297 as part of an EAP authentication exchange. Its Data field has the 298 following ABNF grammar: 300 NAS-Session-Key ::= < AVP Header: 408 > 301 { NAS-Key-Direction } 302 { NAS-Key-Type } 303 { NAS-Key } 304 { NAS-Key-Data } 305 { NAS-Key-Binding } | 306 [ NAS-Key-Lifetime ] 307 [ NAS-IV ] 308 * [ AVP ] 310 If strong authentication and confidentiality of the session keys is 311 required, it is recommended that the CMS security application [13] be 312 used to protect the NAS-Session-Key AVP. 314 The NAS-Session-Key AVP MAY appear zero or more times in the AAA and 315 DEA messages. When more than one NAS-Session-Key AVP is present in a 316 message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST 317 have different values. Otherwise, the AVPs would conflict with each 318 other. 320 If the optional NAS-Key-Lifetime AVP (see section 2.1.7, below) is 321 not present, then the lifetime of the NAS-Session-Key AVP is found in 322 the Authorization-Lifetime AVP. If a re-authorization request is 323 received prior to the expiration of the lifetime, new keys will need 324 to be established. 326 2.1.3 NAS-Key-Direction AVP 328 The NAS-Key-Direction AVP (AVP Code 406) is of type Enumerated, and 329 specifies the direction that the traffic is to be protected with the 330 key. The following values are supported: 332 BIDIRECTIONAL 1 333 The key is used in both directions 335 UPLINK 2 336 The key is used for traffic from the user 338 DOWNLINK 3 339 The key is used for traffic sent to user 341 2.1.4 NAS-Key-Type AVP 343 The NAS-Key-Type AVP (AVP Code 407) is of type Enumerated, and 344 specifies how the key is to be used. The following values are 345 supported: 347 CIPHER_KEY 1 348 The key is used to encrypt data 350 INTEGRITY_KEY 2 351 The key is used to authenticate the data 353 MASTER_CIPHER_KEY 3 354 The master cipher is used to derive further cipher keys 356 MASTER_INTEGRITY_KEY 4 357 The master integrity is used to derive further integrity keys 359 MASTER_KEY 5 360 The master can be used to derive any type of keys, but is not 361 guaranteed to be useful for any particular crypto system. 362 Additional processing will be required, and is not specified in 363 this document. 365 2.1.5 NAS-Key-Data AVP 367 The NAS-Key-Data AVP (AVP Code 405) is of type OctetString and 368 contains the session key to be used between the user and the access 369 device. 371 2.1.6 NAS-Key-Binding AVP 373 The NAS-Key-Binding AVP (AVP Code 404) is of type Enumerated, and 374 specifies the purpose for the key. A Diameter client MAY include this 375 AVP in a request to specify to the Diameter server the type of key it 376 desires. Responses that include the NAS-Session-Key AVP MUST include 377 this AVP which is used to specify the type of key found in the MAS- 378 Key-Data AVP. The following values are supported: 380 DES 1 381 The key created is used to secure links using DES 383 3DES 2 384 The key created is used to secure links using Triple DES 386 RC4-40 3 387 The key created is used to secure links using RC4 using 40-bit 388 keys 390 RC4-128 4 391 The key created is used to secure links using RC4 with 128-bit 392 keys 394 2.1.7 NAS-Key-Lifetime AVP 396 The NAS-Key-Lifetime AVP (AVP Code 413) is of type Unsigned32 and | 397 represents the period of time (in seconds) for which the session key 398 is valid. The session key MUST NOT be used if the lifetime has 399 expired; if the key lifetime expires while the session to which it 400 applies is still active, either the session key MUST be changed or 401 the or the session MUST be terminated. 403 2.1.8 NAS-IV AVP 405 The NAS-IV AVP (AVP Code 414) is of type OctetString. Its contents | 406 MAY be used as an initialization vector (IV) by cryptographic 407 algorithms (e.g., block ciphers). 409 2.2 Legacy RADIUS Attributes 411 The Diameter protocol reserves the AVP Codes 0-255 for "legacy | 412 RADIUS" support. The following table contains the RADIUS attributes 413 supported by this Diameter application, their AVP code values, types, 414 possible flag values and whether the AVP MAY be encrypted. RADIUS 415 attributes not listed are not supported by the Diameter protocol. 417 Due to space constraints, the short form DiamIdent is used to 418 represent DiameterIdentity. 420 +---------------------+ 421 | AVP Flag rules | 422 |----+-----+----+-----|----+ 423 AVP Section | | |SHLD| MUST|MAY | 424 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 425 -----------------------------------------|----+-----+----+-----|----| 426 Accounting- 45 8.6 Unsigned32 | M | P | | V | Y | 427 Authentication-Type | | | | | | 428 Acct-Session-Time 46 8.3 Unsigned32 | M | P | | V | Y | | 429 Acct-Tunnel- 68 8.7 OctetString| M | P | | V | Y | 430 Connection | | | | | | 431 Acct-Tunnel- 86 8.8 Unsigned32 | M | P | | V | Y | 432 Packets-Lost | | | | | | 433 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 434 Response | | | | | | 435 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 436 ARAP-Password 70 3.1.1.7 OctetString| M | P | | V | Y | 437 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 438 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 439 Data | | | | | | 440 ARAP-Zone-Access 72 7.2.8.2 Enumerated | M | P | | V | Y | 441 Callback-Id 20 6.4 UTF8String | M | P | | V | Y | 442 Callback-Number 19 6.3 UTF8String | M | P | | V | Y | 443 Called-Station-Id 30 6.6 UTF8String | M | P | | V | Y | 444 Calling-Station- 31 6.7 UTF8String | M | P | | V | Y | 445 Id | | | | | | 446 CHAP-Challenge 60 3.1.1.6 OctetString| M | P | | V | Y | | 447 Connect-Info 77 6.10 UTF8String | M | P | | V | Y | | 448 Filter-Id 11 6.2 UTF8String | M | P | | V | Y | 449 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 450 Link | | | | | | 451 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 452 Network | | | | | | 453 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 454 Zone | | | | | | 455 Framed- 13 7.2.4 Enumerated | M | P | | V | Y | 456 Compression | | | | | | 457 Framed- 96 7.2.5.4 Unsigned64 | M | P | | V | Y | 458 Interface-Id | | | | | | 459 Framed-IPv6-Pool 100 7.2.5.7 UTF8String | M | P | | V | Y | 460 Framed-IPv6- 97 7.2.5.5 IPAddress | M | P | | V | Y | 461 Prefix | | | | | | 462 Framed-IPv6- 99 7.2.5.6 UTF8String | M | P | | V | Y | 463 Route | | | | | | 464 Framed-IP-Address 8 7.2.5.1 IPAddress | M | P | | V | Y | 465 Framed-IP-Netmask 9 7.2.5.2 IPAddress | M | P | | V | Y | 466 Framed-IP-Route 22 7.2.5.3 UTF8String | M | P | | V | Y | 467 +---------------------+ 468 | AVP Flag rules | 469 |----+-----+----+-----|----+ 470 AVP Section | | |SHLD| MUST|MAY | 471 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 472 -----------------------------------------|----+-----+----+-----|----| 473 Framed-IPX- 23 7.2.6.1 UTF8String | M | P | | V | Y | 474 Network | | | | | | 475 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 476 Framed-Protocol 7 7.2.1 Enumerated | M | P | | V | Y | 477 Framed-Routing 10 7.2.2 Enumerated | M | P | | V | Y | 478 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 479 Login-IP-Host 14 7.3.1 IPAddress | M | P | | V | Y | 480 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 481 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 482 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 483 Login-LAT-Service 34 7.3.4.1 OctetString| M | P | | V | Y | 484 Login-Service 15 7.3.2 Enumerated | M | P | | V | Y | 485 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 486 NAS-Identifier 32 2.2.2 UTF8String | M | P | | V | Y | | 487 NAS-IP-Address 4 2.2.1 IPAddress | M | P | | V | Y | 488 NAS-Port 5 6.1 Unsigned32 | M | P | | V | Y | 489 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 490 Password-Retry 75 3.1.2.2 Unsigned32 | M | P | | V | Y | 491 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 492 Prompt 76 3.1.2.3 Enumerated | M | P | | V | Y | 493 Reply-Message 18 3.2 UTF8String | M | P | | V | Y | 494 Service-Type 6 7.1 Enumerated | M | P | | V | Y | 495 State 24 2.2.3 OctetString| M | P | | V | Y | 496 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 497 Assignment-Id | | | | | | 498 Tunnel-Client- 90 7.4.9 Unsigned32 | M | P | | V | Y | 499 Auth-ID | | | | | | 500 Tunnel-Client- 66 7.4.3 UTF8String | M | P | | V | Y | 501 Endpoint | | | | | | 502 Tunnel-Medium- 65 7.4.2 Enumerated | M | P | | V | Y | 503 Type | | | | | | 504 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 505 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 506 Tunnel-Private- 81 7.4.6 UTF8String | M | P | | V | Y | 507 Group-ID | | | | | | 508 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 509 Auth-ID | | | | | | 510 Tunnel-Server- 67 7.4.4 UTF8String | M | P | | V | Y | 511 Endpoint | | | | | | 512 Tunnel-Type 64 7.4.1 Enumerated | M | P | | V | Y | 513 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 514 The AVPs defined in this section SHOULD only used when a 515 Diameter/RADIUS gateway function is invoked, and are not used in the 516 Diameter protocol. 518 2.2.1 NAS-IP-Address AVP 520 The NAS-IP-Address AVP (AVP Code 4) [1] is of type IPAddress, and 521 contains the IP Address of the NAS providing service to the user. 522 When this AVP is present, the Origin-Host AVP DOES NOT represent the 523 NAS providing service to the user. Note that this AVP SHOULD only 524 added by a RADIUS/Diameter protocol gateway (see Section 9.0). 526 2.2.2 NAS-Identifier AVP 528 The NAS-Identifier AVP (AVP Code 32) [1] is of type UTF8String and | 529 contains the identity of the NAS providing service to the user. When 530 this AVP is present, the Origin-Host AVP DOES NOT represent the NAS 531 providing service to the user. Note that this AVP SHOULD only added 532 by a RADIUS/Diameter protocol gateway (see Section 9.0). This AVP | 533 may only be used in AAR and DER messages. 535 2.2.3 State AVP 537 The State AVP (AVP Code 24) is of type OctetString and is used to 538 transmit the contents of the RADIUS State attribute, and no 539 interpretation of the contents should be made. Note that this AVP 540 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 541 9.0). 543 3.0 Legacy RADIUS Authentication Support 545 This section defines the new Command-Code [2] values required to 546 support the legacy authentication protocols (i.e. PAP, CHAP), as well 547 as the AVPs that are necessary to carry the authentication 548 information in the Diameter protocol. The functionality defined here 549 provides a RADIUS-like AAA service, over a more reliable and secure 550 transport, as defined in the base protocol [2]. 552 Unlike the RADIUS protocol [1], the Diameter protocol does not 553 require authentication information to be contained in a request from 554 the client. Therefore, it is possible to send a request for 555 authorization only. The type of service depends upon the Auth- 556 Request-Type AVP. This difference MAY cause operational issues in 557 environments that need RADIUS interoperability, and it MAY be 558 necessary that protocol conversion gateways add some authentication 559 information when transmitting to a RADIUS server. 561 The Diameter protocol allows for users to be periodically re- 562 authenticated and/or re-authorized. In such instances, the Session-Id 563 AVP in the AAR message MUST be the same as the one present in the 564 original authentication/authorization message. A Diameter server 565 informs the NAS of the maximum time allowed before re-authentication | 566 or re-authorization via the Authorization-Lifetime AVP [1]. Note, | 567 however, that the Authorization-Lifetime AVP SHOULD NOT be used if | 568 the AAR or DER message contained a NAS-IP-Address or NAS-Identifier | 569 AVP since this would mean that the NAS is using RADIUS which does not | 570 support re-authentication or re-authorization. 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, Called-Station-Id, or Calling- | 604 Station-Id AVPs. Certain networks MAY use different AVPs for 605 authorization purposes. A request for authorization will include some 606 AVPs defined in sections 2.0, 6.0 and 7.0. 608 It is possible for a single session to be authorized 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 621 ::= < Diameter Header: 265, REQ, PXY > 622 < Session-Id > 623 { Auth-Application-Id } 624 { Origin-Host } 625 { Origin-Realm } 626 { Destination-Realm } 627 { Auth-Request-Type } 628 [ NAS-Port ] | 629 [ Origin-State-Id ] 630 [ Destination-Host ] 631 [ NAS-IP-Address ] | 632 [ NAS-Identifier ] 633 [ NAS-Port-Type ] 634 [ Port-Limit ] 635 [ User-Name ] 636 [ User-Password ] 637 [ Service-Type ] | 638 [ Idle-Timeout ] 639 [ State ] 640 [ Authorization-Lifetime ] 641 [ Auth-Grace-Period ] 642 [ Auth-Session-State ] 643 [ Session-Timeout ] 644 [ NAS-Key-Binding ] 645 [ Callback-Number ] 646 [ Called-Station-Id ] 647 [ Calling-Station-Id ] 648 [ Connect-Info ] 649 [ CHAP-Auth ] 650 [ CHAP-Challenge ] 651 * [ Framed-Compression ] 653 [ Framed-Interface-Id ] 654 * [ Framed-IPv6-Prefix ] 655 [ Framed-IP-Address ] | 656 [ Framed-IP-Netmask ] 657 [ Framed-MTU ] | 658 [ Framed-Protocol ] 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 * [ Proxy-Info ] 669 * [ Route-Record ] 670 * [ AVP ] 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 described 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 [ User-Name ] 774 [ Service-Type ] | 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 ] 790 [ Port-Limit ] | 791 [ Prompt ] 792 [ ARAP-Challenge-Response ] 793 [ ARAP-Features ] 794 [ ARAP-Security ] | 795 * [ ARAP-Security-Data ] | 796 [ ARAP-Zone-Access ] 797 [ Callback-Id ] 798 [ Callback-Number ] 799 [ Framed-Appletalk-Link ] 800 * [ Framed-Appletalk-Network ] 801 [ Framed-Appletalk-Zone ] 802 * [ Framed-Compression ] 803 [ Framed-Interface-Id ] 804 * [ Framed-IPv6-Prefix ] 805 [ Framed-IPv6-Pool ] 806 * [ Framed-IPv6-Route ] 807 [ Framed-IP-Address ] 808 [ Framed-IP-Netmask ] 809 * [ Framed-IP-Route ] | 810 [ Framed-IPX-Network ] | 811 [ Framed-MTU ] | 812 [ Framed-Protocol ] | 813 [ Framed-Routing ] | 814 * [ Login-IP-Host ] 815 [ Login-LAT-Group ] 816 [ Login-LAT-Node ] 817 [ Login-LAT-Port ] 818 [ Login-LAT-Service ] 819 [ Login-Service ] | 820 [ Login-TCP-Port ] | 821 * [ NAS-Filter-Rule ] 822 * [ Tunneling ] 823 * [ Redirect-Host ] 824 [ Redirect-Host-Usage ] 825 [ Redirect-Max-Cache-Time ] 826 * [ Proxy-Info ] 827 * [ AVP ] 829 3.1.2.1 ARAP-Challenge-Response AVP 831 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 832 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 833 is included in the message and is set to ARAP. This AVP contains an 8 834 octet response to the dial-in client's challenge. The RADIUS server 835 calculates this value by taking the dial-in client's challenge from 836 the high order 8 octets of the ARAP-Password AVP and performing DES 837 encryption on this value with the authenticating user's password as 838 the key. If the user's password is less than 8 octets in length, the 839 password is padded at the end with NULL octets to a length of 8 840 before using it as a key. 842 3.1.2.2 Password-Retry AVP 844 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 845 included in the AA-Answer if the Result-Code indicates an 846 authentication failure. The value of this AVP indicates how many 847 authentication attempts a user may be permitted before being 848 disconnected. This AVP is primarily intended for use when the Framed- 849 Protocol AVP (see Section 7.2.1) is set to ARAP. 851 3.1.2.3 Prompt AVP 853 The Prompt AVP (AVP Code 76) is of type Enumerated, and MAY be 854 present in the AA-Answer message. When present, it is used by the NAS 855 to determine whether the user's response, when entered, should be 856 echoed. 858 The supported values are listed in [33]. 860 3.2 Reply-Message AVP 862 The Reply-Message AVP (AVP Code 18) is of type UTF8String, and 863 contains text which MAY be displayed to the user. When used in an 864 AA-Answer message with a successful Result-Code AVP it indicates the 865 success message. When found in the same message with a Result-Code 866 other than Diameter-SUCCESS it contains the failure message. 868 The Reply-Message AVP MAY indicate a dialog message to prompt the 869 user before another AA-Request attempt. When used in an AA-Answer, it 870 MAY indicate a dialog message to prompt the user for a response. 872 Multiple Reply-Message's MAY be included and if any are displayed, 873 they MUST be displayed in the same order as they appear in the 874 message. 876 4.0 Extensible Authentication Protocol Support 878 The Extensible Authentication Protocol (EAP), described in [25], 879 provides a standard mechanism for support of extensible 880 authentication methods. Through the use of EAP, support for a number 881 of authentication schemes may be added, including smart and token 882 cards, Kerberos, Public Key, One Time Passwords, and others. 884 This section describes the Command-Codes values and AVPs that are 885 required for an EAP payload to be encapsulated within the Diameter 886 protocol. Since authentication occurs between the EAP client and its 887 home Diameter server, end-to-end authentication is achieved, reducing 888 the possibility for fraudulent authentication, such as replay and 889 man-in-the-middle attacks. End-to-end authentication also provides 890 for mutual (bi-directional) authentication, which is not possible 891 with PAP and CHAP in a roaming PPP environment. 893 The EAP conversation between the authenticating peer and the access 894 device begins with the initiation of EAP within a link layer, such as 895 PPP or 802.1x. Once EAP has been initiated, the access device will 896 typically send to the Diameter server a Diameter-EAP-Request message 897 with a NULL EAP-Payload AVP, signifying an EAP-Start. The Port number 898 and the identity of the access device (e.g. Origin-Host or NAS- 899 Identifier) MUST be included in the Diameter-EAP-Request message. 901 If the Diameter home server supports EAP, it MUST respond with a 902 Diameter-EAP-Answer message containing an EAP-Payload AVP that 903 includes an encapsulated EAP payload [25], and the Result-Code AVP 904 set to DIAMETER_MULTI_ROUND_AUTH, signifying that a subsequent 905 request is expected. The EAP payload is forwarded by the access 906 device to the EAP client. 908 The initial Diameter-EAP-Answer in a multi-round exchange normally 909 includes an EAP-Request/Identity, requesting the EAP client to 910 identify itself. Upon receipt of the EAP client's EAP-Response [25], 911 the access device will then issue a second Diameter-EAP-Request 912 message, with the client's EAP payload encapsulated within the EAP- 913 Payload AVP. 915 A preferred approach is for the access device to issue the EAP- 916 Request/Identity message to the EAP client, and forward the EAP- 917 Response/Identity packet, encapsulated within the EAP-Payload AVP, as 918 a Diameter-EAP-Request to the Diameter server. This alternative 919 reduces the number of Diameter message round trips, and is compatible 920 with roaming environments, since the Destination-Realm is needed by 921 Diameter agents for routing purposes. Note that this alternative 922 cannot be universally employed, as there are circumstances where a 923 user's identity is not needed (such as when authorization occurs 924 based on a calling or called phone number). 926 The conversation continues until the Diameter server sends a 927 Diameter-EAP-Answer with a Result-Code AVP indicating success or 928 failure, and an optional EAP-Payload. The Result-Code AVP is used by 929 the access device to determine whether service is to be provided to 930 the EAP client. The access device MUST NOT rely on the contents of 931 the optional EAP-Payload to determine whether service is to be 932 provided. 934 A Diameter-EAP-Answer message containing an EAP-Payload of type EAP- 935 Success or EAP-Failure MUST NOT have the Result-Code AVP set to 936 DIAMETER_MULTI_ROUND_AUTH. 938 If authorization was requested, a successful Diameter-EAP-Answer MUST 939 also include the appropriate authorization AVPs required for the 940 service requested (see sections 2.0, 6.0 and 7.0). Diameter-EAP- 941 Answer messages whose Result-Code AVP is set to 942 DIAMETER_MULTI_ROUND_AUTH MAY include authorization AVPs. 944 Unless the access device interprets the EAP-Response/Identity packet 945 returned by the authenticating peer, it will not have access to the 946 user's identity. Therefore, the Diameter Server SHOULD return the 947 user's identity by inserting it in the User-Name attribute of 948 subsequent Diameter-EAP-Answer packets. Without the user's identity, 949 the Session-Id AVP MAY be used for accounting and billing, however 950 operationally this MAY be very difficult to manage. 952 A home Diameter server MAY request EAP re-authentication by issuing 953 the Re-Auth-Request [2] message to the Diameter client. 955 Should an EAP authentication session be interrupted due to a home 956 server failure, the session MAY be directed to an alternate server, 957 but the authentication session will have to be restarted from the 958 beginning. 960 If a response is received with the Result-Code set to 961 DIAMETER_COMMAND_UNSUPPORTED [2], it is an indication that the 962 Diameter server in the home realm does not support EAP. If possible, 963 the access device MAY attempt to negotiate another authentication 964 protocol, such as PAP or CHAP. An access device SHOULD be cautious 965 when determining whether a less secure authentication protocol will 966 be used, since this could be a result of a bidding down attack. 968 4.1 Alternative uses 970 Currently the conversation between the backend authentication server 971 and the Diameter server is proprietary because of lack of 972 standardization. In order to increase standardization and provide 973 interoperability between Diameter vendors and backend security 974 vendors, it is recommended that Diameter-encapsulated EAP be used for 975 this conversation. 977 This has the advantage of allowing the Diameter server to support EAP 978 without the need for authentication-specific code within the Diameter 979 server. Authentication-specific code can then reside on a backend 980 authentication server instead. 982 In the case where Diameter-encapsulated EAP is used in a conversation 983 between a Diameter server and a backend authentication server, the 984 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 985 Success message without inclusion of the expected authorization AVPs 986 required in a successful response. This means that the Diameter 987 server MUST add these attributes prior to sending an Diameter-EAP- 988 Answer/EAP-Payload/EAP-Success message to the access device. 990 4.2 Command-Codes Values 992 This section defines new Command-Code [2] values that MUST be 993 supported by all Diameter implementations conforming to this 994 specification. The following Command Codes are defined in this 995 section: 997 Command-Name Abbrev. Code Reference 998 -------------------------------------------------------- 999 Diameter-EAP-Answer DEA 268 4.2.2 1000 Diameter-EAP-Request DER 268 4.2.1 1002 4.2.1 Diameter-EAP-Request (DER) Command 1004 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 1005 field set to 268 and the 'R' bit set in the Command Flags field, is 1006 sent by a Diameter client to a Diameter server and conveys an EAP- 1007 Response [25] from the EAP client. The Diameter-EAP-Request MUST 1008 contain one EAP-Payload AVP, which contains the actual EAP payload. 1009 An EAP-Payload AVP with no data MAY be sent to the Diameter server to 1010 initiate an EAP authentication session. 1012 The DER message MAY be the result of a multi-round authentication 1013 exchange, which occurs when the DEA is received with the Result-Code 1014 AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent DER message MUST 1015 include any State AVPs that were present in the DEA. For re- 1016 authentication, it is recommended that the Identity request be 1017 skipped in order to reduce the number of authentication round trips. 1018 This is only possible when the user's identity is already known by 1019 the home Diameter server. 1021 Message Format 1023 ::= < Diameter Header: 268, REQ, PXY > 1024 < Session-Id > 1025 { Auth-Application-Id } 1026 { Origin-Host } 1027 { Origin-Realm } 1028 { Destination-Realm } 1029 { Auth-Request-Type } 1030 { EAP-Payload } 1031 [ NAS-Port ] | 1032 [ Destination-Host ] 1033 [ Authorization-Lifetime ] 1034 [ Auth-Grace-Period ] 1035 [ Auth-Session-State ] 1036 [ Session-Timeout ] 1037 [ User-Name ] 1038 [ Service-Type ] | 1039 [ Idle-Timeout ] 1040 [ NAS-IP-Address ] | 1041 [ NAS-Identifier ] 1042 [ NAS-Port-Type ] 1043 [ Port-Limit ] 1044 [ State ] 1045 [ Origin-State-Id ] 1046 [ NAS-Key-Binding ] 1047 [ Callback-Number ] 1048 [ Called-Station-Id ] 1049 [ Calling-Station-Id ] 1050 [ Connect-Info ] 1051 * [ Framed-Compression ] 1052 [ Framed-Interface-Id ] 1053 * [ Framed-IPv6-Prefix ] 1054 [ Framed-IP-Address ] | 1055 [ Framed-IP-Netmask ] 1056 [ Framed-MTU ] | 1057 [ Framed-Protocol ] 1058 * [ Tunneling ] | 1059 * [ Proxy-Info ] 1060 * [ Route-Record ] 1061 * [ AVP ] 1063 4.2.2 Diameter-EAP-Answer (DEA) Command 1065 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 1066 field set to 268 and the 'R' bit cleared in the Command Flags field, 1067 is sent by the Diameter server to the client for one of the following 1068 reasons: 1070 1) The message is part of a multi-round authentication exchange, 1071 and the server is expecting a subsequent Diameter-EAP-Request. 1072 This is indicated by setting the Result-Code to 1073 DIAMETER_MULTI_ROUND_AUTH, and MAY include zero or more State 1074 AVPs. 1075 2) the EAP client has been successfully authenticated and 1076 authorized, in which case the message MUST include the Result- 1077 Code AVP indicating success, and SHOULD include an EAP-Payload 1078 of type EAP-Success. This event MUST cause the access device 1079 to provide service to the EAP client. 1080 3) The EAP client has not been successfully authenticated and/or 1081 authorized, and the Result-Code AVP is set to indicate failure. 1082 This message SHOULD include an EAP-Payload, but this AVP is not 1083 used to determine whether service is to be provided. 1085 If the message from the Diameter client included a request for 1086 authorization, a successful response MUST include the authorization 1087 AVPs that are relevant to the service being provided. 1089 Message Format 1091 ::= < Diameter Header: 268, PXY > 1092 < Session-Id > 1093 { Auth-Application-Id } 1094 { Result-Code } 1095 { Origin-Host } 1096 { Origin-Realm } 1097 { Auth-Request-Type } 1098 [ Error-Reporting-Host ] 1099 [ EAP-Payload ] 1100 [ User-Name ] 1101 [ Service-Type ] | 1102 [ Idle-Timeout ] 1103 [ Authorization-Lifetime ] 1104 [ Auth-Grace-Period ] 1105 [ Auth-Session-State ] 1106 [ Re-Auth-Request-Type ] 1107 [ Session-Timeout ] 1108 [ State ] | 1109 [ Origin-State-Id ] 1110 * [ Filter-ID ] | 1111 * [ NAS-Session-Key ] 1112 [ Callback-Id ] 1113 [ Callback-Number ] 1114 [ Framed-Appletalk-Link ] 1115 * [ Framed-Appletalk-Network ] 1117 [ Framed-Appletalk-Zone ] 1118 * [ Framed-Compression ] 1119 [ Framed-Interface-Id ] 1120 * [ Framed-IPv6-Prefix ] 1121 [ Framed-IPv6-Pool ] 1122 * [ Framed-IPv6-Route ] 1123 [ Framed-IP-Address ] 1124 [ Framed-IP-Netmask ] 1125 * [ Framed-IP-Route ] 1126 [ Framed-IPX-Network ] 1127 [ Framed-MTU ] 1128 [ Framed-Protocol ] | 1129 [ Framed-Routing ] | 1130 * [ NAS-Filter-Rule ] 1131 * [ Tunneling ] 1132 * [ Redirect-Host ] 1133 [ Redirect-Host-Usage ] 1134 [ Redirect-Max-Cache-Time ] 1135 [ Port-Limit ] | 1136 * [ Proxy-Info ] 1137 * [ AVP ] 1139 4.3 EAP-Payload AVP 1141 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1142 to encapsulate the actual EAP payload [25] that is being exchanged 1143 between the EAP client and the home Diameter server. 1145 5.0 Diameter Session Termination 1147 When a Network Access Server (NAS) receives an indication that a 1148 user's session is being disconnected (e.g. LCP Terminate is 1149 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1150 to its Diameter Server. This will ensure that any resources 1151 maintained on the servers is freed appropriately. 1153 Further, a NAS that receives a Abort-Session-Request (ASR) [2] MUST 1154 issue an STR if the session requested is active, and disconnect the 1155 PPP (or tunneling) session. 1157 6.0 Call and Session Information 1159 This section contains the authorization AVPs that are needed to 1160 identify call and session information, and allows the server to set 1161 constraints on a session. 1163 6.1 NAS-Port AVP 1165 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1166 physical port number of the NAS which is authenticating the user, and 1167 is normally only present in an authentication and/or authorization 1168 request. Note that this is using "port" in its sense of a physical 1169 connection on the NAS, not in the sense of a TCP or UDP port number. 1170 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1171 present in the request, if the NAS differentiates among its ports. 1173 6.2 Filter-Id AVP 1175 The Filter-Id AVP (AVP Code 11) is of type UTF8String, and contains 1176 the name of the filter list for this user. Zero or more Filter-Id 1177 AVPs MAY be sent in an authorization answer. 1179 Identifying a filter list by name allows the filter to be used on 1180 different NASes without regard to filter-list implementation details. 1181 However, this AVP is not roaming friendly since filter naming differs 1182 from one service provider to another. 1184 In non-RADIUS environments, it is RECOMMENDED that the NAS-Filter- | 1185 Rule AVP be used instead. 1187 6.3 Callback-Number AVP 1189 The Callback-Number AVP (AVP Code 19) is of type UTF8String, and 1190 contains a dialing string to be used for callback. It MAY be used in 1191 an authentication and/or authorization request as a hint to the 1192 server that a Callback service is desired, but the server is not 1193 required to honor the hint in the corresponding response. 1195 The codification of the range of allowed usage of this field is 1196 outside the scope of this specification. 1198 6.4 Callback-Id AVP 1200 The Callback-Id AVP (AVP Code 20) is of type UTF8String, and contains 1201 the name of a place to be called, to be interpreted by the NAS. This 1202 AVP MAY be present in an authentication and/or authorization 1203 response. 1205 This AVP is not roaming friendly since it assumes that the Callback- 1206 Id is configured on the NAS. It is therefore preferable to use the 1207 Callback-Number AVP instead. 1209 6.5 Idle-Timeout AVP 1211 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1212 maximum number of consecutive seconds of idle connection allowed to 1213 the user before termination of the session or prompt. It MAY be used 1214 in an authentication and/or authorization request (or challenge) as a 1215 hint to the server that an idle timeout is desired, but the server is 1216 not required to honor the hint in the corresponding response. 1218 6.6 Called-Station-Id AVP 1220 The Called-Station-Id AVP (AVP Code 30) is of type UTF8String, and 1221 allows the NAS to send in the request the phone number that the user 1222 called, using Dialed Number Identification (DNIS) or a similar 1223 technology. Note that this may be different from the phone number the 1224 call comes in on. It SHOULD only be present in authentication and/or 1225 authorization requests. 1227 If the Auth-Request-Type AVP is set to authorization-only and the 1228 User-Name AVP is absent, the Diameter Server MAY perform 1229 authorization based on this field. This can be used by a NAS to 1230 request whether a call should be answered based on the DNIS. 1232 The codification of the range of allowed usage of this field is 1233 outside the scope of this specification. 1235 6.7 Calling-Station-Id AVP 1237 The Calling-Station-Id AVP (AVP Code 31) is of type UTF8String, and 1238 allows the NAS to send in the request the phone number that the call 1239 came from, using Automatic Number Identification (ANI) or a similar 1240 technology. It SHOULD only be present in authentication and/or 1241 authorization requests. 1243 If the Auth-Request-Type AVP is set to authorization-only and the 1244 User-Name AVP is absent, the Diameter Server MAY perform 1245 authorization based on this field. This can be used by a NAS to 1246 request whether a call should be answered based on the ANI. 1248 The codification of the range of allowed usage of this field is 1249 outside the scope of this specification. 1251 6.8 NAS-Port-Type AVP 1252 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1253 contains the type of the physical port of the NAS which is 1254 authenticating the user. It can be used instead of or in addition to 1255 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1256 and/or authorization requests. This AVP MAY be combined with the NAS- 1257 Port AVP to assist in differentiating its ports. 1259 The supported values are defined in [33]. 1261 6.9 Port-Limit AVP 1263 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1264 maximum number of ports to be provided to the user by the NAS. It 1265 MAY be used in an authentication and/or authorization request as a 1266 hint to the server that multilink PPP [9] service is desired, but the 1267 server is not required to honor the hint in the corresponding 1268 response. 1270 6.10 Connect-Info AVP 1272 The Connect-Info AVP (AVP Code 77) is of type UTF8String, and is sent 1273 in the AA-Request message, and indicates the nature of the user's 1274 connection. The connection speed SHOULD be included at the beginning 1275 of the first Connect-Info AVP in the message. If the transmit and 1276 receive connection speeds differ, they may both be included in the 1277 first AVP with the transmit speed first (the speed the NAS modem 1278 transmits at), a slash (/), the receive speed, then optionally other 1279 information. 1281 7.0 Service Specific Authorization AVPs 1283 This section contains the RADIUS authorization AVPs that are 1284 supported in the Diameter protocol. The Service-Type AVP SHOULD be | 1285 present in all messages, and based on the value of the Service-Type 1286 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1287 present. 1289 7.1 Service-Type AVP 1291 The Service-Type AVP (AVP Code 6) is of type Enumerated and contains 1292 the type of service the user has requested, or the type of service to 1293 be provided. One such AVP MAY be present in an authentication and/or 1294 authorization request or response. A NAS is not required to implement 1295 all of these service types, and MUST treat unknown or unsupported 1296 Service-Types as though a response with a Result-Code other than 1297 Diameter-SUCCESS had been received instead. 1299 When used in a request, the Service-Type AVP SHOULD be considered to 1300 be a hint to the server that the NAS has reason to believe the user 1301 would prefer the kind of service indicated, but the server is not 1302 required to honor the hint. The following values have been defined 1303 for the Service-Type AVP: 1305 The complete list of defined values can be found in [1] and [33]. The 1306 following values are extracted from [1], and are listed here since 1307 they are further qualified: 1309 Login 1 1310 The user should be connected to a host. The message MAY include 1311 additional AVPs defined in section 7.3. 1313 Framed 2 1314 A Framed Protocol should be started for the User, such as PPP 1315 or SLIP. The message MAY include additional AVPs defined in 1316 section 7.2, or 7.4 for tunneling services. 1318 Callback Login 3 1319 The user should be disconnected and called back, then connected 1320 to a host. The message MAY include additional AVPs defined in 1321 section 7.3. 1323 Callback Framed 4 1324 The user should be disconnected and called back, then a Framed 1325 Protocol should be started for the User, such as PPP or SLIP. 1326 The message MAY include additional AVPs defined in section 7.2, 1327 or 7.4 for tunneling services. 1329 7.2 Framed Access Authorization AVPs 1331 This section contains the authorization AVPs that are necessary to 1332 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1333 section MAY be present in a message if the Service-Type AVP was set 1334 to "Framed" or "Callback Framed". 1336 7.2.1 Framed-Protocol AVP 1338 The Framed-Protocol AVP (AVP Code 7) is of type Enumerated and 1339 contains the framing to be used for framed access. This AVP MAY be 1340 present in both requests and responses. The supported values are 1341 listed in [33]. 1343 7.2.2 Framed-Routing AVP 1345 The Framed-Routing AVP (AVP Code 10) is of type Enumerated and 1346 contains the routing method for the user, when the user is a router 1347 to a network. This AVP SHOULD only be present in authorization 1348 responses. The supported values are listed in [33]. 1350 7.2.3 Framed-MTU AVP 1352 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1353 the Maximum Transmission Unit to be configured for the user, when it 1354 is not negotiated by some other means (such as PPP). This AVP SHOULD 1355 only be present in authorization responses. The MTU value MUST be 1356 between the range of 64 and 65535. 1358 7.2.4 Framed-Compression AVP 1360 The Framed-Compression AVP (AVP Code 13) is of type Enumerated and 1361 contains the compression protocol to be used for the link. It MAY be 1362 used in an authorization request as a hint to the server that a 1363 specific compression type is desired, but the server is not required 1364 to honor the hint in the corresponding response. 1366 More than one compression protocol AVP MAY be sent. It is the 1367 responsibility of the NAS to apply the proper compression protocol to 1368 appropriate link traffic. 1370 The supported values are listed in [33]. 1372 7.2.5 IP Access 1374 The AVPs defined in this section are used when the user requests, or 1375 is being granted, access to IP. They are only present if the Framed- 1376 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1377 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1379 7.2.5.1 Framed-IP-Address AVP 1381 The Framed-IP-Address AVP (AVP Code 8) is of type IPAddress and 1382 contains the address to be configured for the user. It MAY be used in 1383 an authorization request as a hint to the server that a specific 1384 address is desired, but the server is not required to honor the hint 1385 in the corresponding response. 1387 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1388 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1389 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1390 that the NAS should select an address for the user (e.g. Assigned 1391 from a pool of addresses kept by the NAS). 1393 7.2.5.2 Framed-IP-Netmask AVP 1395 The Framed-IP-Netmask AVP (AVP Code 9) is of type IPAddress and 1396 contains the IP netmask to be configured for the user when the user 1397 is a router to a network. It MAY be used in an authorization request 1398 as a hint to the server that a specific netmask is desired, but the 1399 server is not required to honor the hint in the corresponding 1400 response. This AVP MUST be present in a response if the request 1401 included this AVP with a value of 0xFFFFFFFF. 1403 7.2.5.3 Framed-IP-Route AVP 1405 The Framed-IP-Route AVP (AVP Code 22) is of type UTF8String, and 1406 contains the routing information to be configured for the user on the 1407 NAS. Zero or more such AVPs MAY be present in an authorization 1408 response. 1410 The string MUST contain a destination prefix in dotted quad form 1411 optionally followed by a slash and a decimal length specifier stating 1412 how many high order bits of the prefix should be used. That is 1413 followed by a space, a gateway address in dotted quad form, a space, 1414 and one or more metrics separated by spaces. For example, 1415 "192.168.1.0/24 192.168.1.1 1". 1417 The length specifier may be omitted in which case it should default 1418 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1419 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1421 Whenever the gateway address is specified as "0.0.0.0" the IP address 1422 of the user SHOULD be used as the gateway address. 1424 7.2.5.4 Framed-Interface-Id AVP 1426 The Framed-Interface-Id AVP (AVP Code 96) is of type Unsigned64 and 1427 contains the IPv6 interface identifier to be configured for the user. 1428 It MAY be used in authorization requests as a hint to the server that 1429 a specific interface id is desired, but the server is not required to 1430 honor the hint in the corresponding response. 1432 7.2.5.5 Framed-IPv6-Prefix AVP 1434 The Framed-IPv6-Prefix AVP (AVP Code 97) is of type IPAddress and 1435 contains the IPv6 prefix to be configured for the user. One or more 1436 AVPs MAY be used in authorization requests as a hint to the server 1437 that a specific IPv6 prefixes are desired, but the server is not 1438 required to honor the hint in the corresponding response. 1440 7.2.5.6 Framed-IPv6-Route AVP 1442 The Framed-IPv6-Route AVP (AVP Code 99) is of type UTF8String, and 1443 contains the routing information to be configured for the user on the 1444 NAS. Zero or more such AVPs MAY be present in an authorization 1445 response. 1447 The string MUST contain an IPv6 address prefix followed by a slash 1448 and a decimal length specifier stating how many high order bits of 1449 the prefix should be used. That is followed by a space, a gateway 1450 address in hexadecimal notation, a space, and one or more metrics 1451 separated by spaces. For example: 1452 "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". 1454 Whenever the gateway address is the IPv6 unspecified address the IP 1455 address of the user SHOULD be used as the gateway address, such as: 1456 "2000:0:0:106::/64 :: 1". 1458 7.2.5.7 Framed-IPv6-Pool AVP 1460 The Framed-IPv6-Pool AVP (AVP Code 100) is of type UTF8String, and 1461 contains the name of an assigned pool that SHOULD be used to assign 1462 an IPv6 prefix for the user. If the access device does not support 1463 multiple prefix pools, it MUST ignore this AVP. 1465 7.2.6 IPX Access 1467 The AVPs defined in this section are used when the user requests, or 1468 is being granted, access to IPX. They are only present if the Framed- 1469 Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics proprietary 1470 IPX/SLIP, Gandalf proprietarySingleLink/MultiLink protocol, or X.75 1471 Synchronous. 1473 7.2.6.1 Framed-IPX-Network AVP 1475 The Framed-IPX-Network AVP (AVP Code 23) is of type UTF8String, and 1476 contains the IPX Network number to be configured for the user. It MAY 1477 be used in an authorization request as a hint to the server that a 1478 specific address is desired, but the server is not required to honor 1479 the hint in the corresponding response. 1481 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1482 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1483 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1484 that the NAS should select an address for the user (e.g. assigned 1485 from a pool of one or more IPX networks kept by the NAS). 1487 7.2.7 Appletalk Access 1489 The AVPs defined in this section are used when the user requests, or 1490 is being granted, access to Appletalk. They are only present if the 1491 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1492 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1494 7.2.7.1 Framed-AppleTalk-Link AVP 1496 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1497 contains the AppleTalk network number which should be used for the 1498 serial link to the user, which is another AppleTalk router. This AVP 1499 MUST only be present in an authorization response and is never used 1500 when the user is not another router. 1502 Despite the size of the field, values range from zero to 65535. The 1503 special value of zero indicates that this is an unnumbered serial 1504 link. A value of one to 65535 means that the serial line between the 1505 NAS and the user should be assigned that value as an AppleTalk 1506 network number. 1508 7.2.7.2 Framed-AppleTalk-Network AVP 1510 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1511 and contains the AppleTalk Network number which the NAS should probe 1512 to allocate an AppleTalk node for the user. This AVP MUST only be 1513 present in an authorization response and is never used when the user 1514 is not another router. Multiple instances of this AVP indicate that 1515 the NAS may probe using any of the network numbers specified. 1517 Despite the size of the field, values range from zero to 65535. The 1518 special value zero indicates that the NAS should assign a network for 1519 the user, using its default cable range. A value between one and 1520 65535 (inclusive) indicates the AppleTalk Network the NAS should 1521 probe to find an address for the user. 1523 7.2.7.3 Framed-AppleTalk-Zone AVP 1525 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1526 and contains the AppleTalk Default Zone to be used for this user. 1527 This AVP MUST only be present in an authorization response. Multiple 1528 instances of this AVP in the same message are not allowed. 1530 The codification of the range of allowed usage of this field is 1531 outside the scope of this specification. 1533 7.2.8 ARAP Access 1535 The AVPs defined in this section are used when the user requests, or 1536 is being granted, access to ARAP. They are only present if the 1537 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1538 Access Protocol (ARAP). 1540 7.2.8.1 ARAP-Features AVP 1542 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1543 be present in the AA-Accept message if the Framed-Protocol AVP is set 1544 to the value of ARAP. See [32] for more information of the format of 1545 this AVP. 1547 7.2.8.2 ARAP-Zone-Access AVP 1549 The ARAP-Zone-Access AVP (AVP Code 72) is of type Enumerated, and MAY 1550 be present in the AA-Accept message if the Framed-Protocol AVP is set 1551 to the value of ARAP. 1553 The supported values are listed in [33], and are defined in [32]. 1555 7.2.8.3 ARAP-Security AVP 1557 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1558 present in the AA-Answer message if the Framed-Protocol AVP is set to 1559 the value of ARAP, and the Result-Code AVP is set to 1560 DIAMETER_MULTI_ROUND_AUTH. See [32] for more information of the 1561 format of this AVP. 1563 7.2.8.4 ARAP-Security-Data AVP 1565 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1566 be present in the AA-Request or AA-Answer message if the Framed- 1567 Protocol AVP is set to the value of ARAP, and the Result-Code AVP is 1568 set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security 1569 module challenge or response associated with the ARAP Security Module 1570 specified in ARAP-Security. 1572 7.3 Non-Framed Access Authorization AVPs 1574 This section contains the authorization AVPs that are needed to 1575 support terminal server functionality. AVPs defined in this section 1576 MAY be present in a message if the Service-Type AVP was set to 1577 "Login" or "Callback Login". 1579 7.3.1 Login-IP-Host AVP 1581 The Login-IP-Host AVP (AVP Code 14) is of type IPAddress and contains 1582 the system with which to connect the user, when the Login-Service AVP 1583 is included. It MAY be used in an authorization request as a hint to 1584 the server that a specific host is desired, but the server is not 1585 required to honor the hint in the corresponding response. 1587 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1588 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1589 select an address. The value zero indicates that the NAS SHOULD 1590 select a host to connect the user to. 1592 7.3.2 Login-Service AVP 1594 The Login-Service AVP (AVP Code 15) is of type Enumerated and 1595 contains the service which should be used to connect the user to the 1596 login host. This AVP SHOULD only be present in authorization 1597 responses. 1599 The supported values are listed in [33]. 1601 7.3.3 TCP Services 1603 The AVP described in this section MAY be present if the Login-Service 1604 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1606 7.3.3.1 Login-TCP-Port AVP 1608 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1609 contains the TCP port with which the user is to be connected, when 1610 the Login-Service AVP is also present. This AVP SHOULD only be 1611 present in authorization responses. The value MUST NOT be greater 1612 than 65535. 1614 7.3.4 LAT Services 1616 The AVP described in this section MAY be present if the Login-Service 1617 AVP is set to LAT. 1619 7.3.4.1 Login-LAT-Service AVP 1621 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1622 contains the system with which the user is to be connected by LAT. It 1623 MAY be used in an authorization request as a hint to the server that 1624 a specific service is desired, but the server is not required to 1625 honor the hint in the corresponding response. This AVP MUST only be 1626 present in the response if the Login-Service AVP states that LAT is 1627 desired. 1629 Administrators use the service attribute when dealing with clustered 1630 systems, such as a VAX or Alpha cluster. In such an environment 1631 several different time sharing hosts share the same resources (disks, 1632 printers, etc.), and administrators often configure each to offer 1633 access (service) to each of the shared resources. In this case, each 1634 host in the cluster advertises its services through LAT broadcasts. 1636 Sophisticated users often know which service providers (machines) are 1637 faster and tend to use a node name when initiating a LAT connection. 1638 Alternately, some administrators want particular users to use certain 1639 machines as a primitive form of load balancing (although LAT knows 1640 how to do load balancing itself). 1642 The String field contains the identity of the LAT service to use. 1643 The LAT Architecture allows this string to contain $ (dollar), - 1644 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1645 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1646 string comparisons are case insensitive. 1648 7.3.4.2 Login-LAT-Node AVP 1650 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1651 contains the Node with which the user is to be automatically 1652 connected by LAT. It MAY be used in an authorization request as a 1653 hint to the server that a specific LAT node is desired, but the 1654 server is not required to honor the hint in the corresponding 1655 response. This AVP MUST only be present in a response if the Service- 1656 Type AVP is set to LAT. 1658 The String field contains the identity of the LAT service to use. 1659 The LAT Architecture allows this string to contain $ (dollar), - 1660 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1661 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1662 string comparisons are case insensitive. 1664 7.3.4.3 Login-LAT-Group AVP 1666 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1667 contains a string identifying the LAT group codes which this user is 1668 authorized to use. It MAY be used in an authorization request as a 1669 hint to the server that a specific group is desired, but the server 1670 is not required to honor the hint in the corresponding response. This 1671 AVP MUST only be present in a response if the Service-Type AVP is set 1672 to LAT. 1674 LAT supports 256 different group codes, which LAT uses as a form of 1675 access rights. LAT encodes the group codes as a 256 bit bitmap. 1677 Administrators can assign one or more of the group code bits at the 1678 LAT service provider; it will only accept LAT connections that have 1679 these group codes set in the bit map. The administrators assign a 1680 bitmap of authorized group codes to each user; LAT gets these from 1681 the operating system, and uses these in its requests to the service 1682 providers. 1684 The codification of the range of allowed usage of this field is 1685 outside the scope of this specification. 1687 7.3.4.4 Login-LAT-Port AVP 1689 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1690 contains the Port with which the user is to be connected by LAT. It 1691 MAY be used in an authorization request as a hint to the server that 1692 a specific port is desired, but the server is not required to honor 1693 the hint in the corresponding response. This AVP MUST only be present 1694 in a response if the Service-Type AVP is set to LAT. 1696 The String field contains the identity of the LAT service to use. 1698 The LAT Architecture allows this string to contain $ (dollar), - 1699 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1700 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1701 string comparisons are case insensitive. 1703 7.4 Tunneling AVPs | 1705 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1706 used to describe a tunnel. Its Data field has the following ABNF 1707 grammar: 1709 Tunneling ::= < AVP Header: 403 > 1710 { Tunnel-Type } 1711 { Tunnel-Medium-Type } 1712 { Tunnel-Client-Endpoint } 1713 { Tunnel-Server-Endpoint } 1714 [ Tunnel-Preference ] 1715 [ Tunnel-Client-Auth-ID ] 1716 [ Tunnel-Server-Auth-ID ] 1717 [ Tunnel-Assignment-ID ] 1718 [ Tunnel-Password ] 1719 [ Tunnel-Private-Group-ID ] 1721 7.4.1 Tunnel-Type AVP 1723 The Tunnel-Type AVP (AVP Code 64) is of type Enumerated and contains 1724 the tunneling protocol(s) to be used (in the case of a tunnel 1725 initiator) or the tunneling protocol in use (in the case of a tunnel 1726 terminator). It MAY be used in an authorization request as a hint to 1727 the server that a specific tunnel type is desired, but the server is 1728 not required to honor the hint in the corresponding response. 1730 The Tunnel-Type AVP SHOULD also be included in Accounting-Request | 1731 messages. 1733 A tunnel initiator is not required to implement any of these tunnel 1734 types; if a tunnel initiator receives a response that contains only 1735 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1736 as though a response was received with the Result-Code indicating a 1737 failure. 1739 The supported values are listed in [33]. 1741 7.4.2 Tunnel-Medium-Type AVP 1742 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Enumerated and 1743 contains the transport medium to use when creating a tunnel for those 1744 protocols (such as L2TP) that can operate over multiple transports. 1745 It MAY be used in an authorization request as a hint to the server 1746 that a specific medium is desired, but the server is not required to 1747 honor the hint in the corresponding response. 1749 The Value field contains one of the values listed under "Address 1750 Family Numbers" in [10]. The value of most importance is (1) for IPv4 1751 and (2) for IPv6. 1753 7.4.3 Tunnel-Client-Endpoint AVP 1755 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type UTF8String, 1756 and contains the address of the initiator end of the tunnel. It MAY 1757 be used in an authorization request as a hint to the server that a 1758 specific endpoint is desired, but the server is not required to honor 1759 the hint in the corresponding response. 1761 This AVP SHOULD be included in the corresponding Accounting-Request | 1762 messages, in which case it indicates the address from which the 1763 tunnel was initiated. This AVP, along with the Tunnel-Server-Endpoint 1764 and Session-Id AVP [2], MAY be used to provide a globally unique 1765 means to identify a tunnel for accounting and auditing purposes. 1767 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1768 fully qualified domain name (FQDN) of the tunnel client machine, or 1769 it is a "dotted-decimal" IP address. Conformant implementations MUST 1770 support the dotted-decimal format and SHOULD support the FQDN format 1771 for IP addresses. 1773 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1774 FQDN of the tunnel client machine, or it is a text representation of 1775 the address in either the preferred or alternate form [5]. 1776 Conformant implementations MUST support the preferred form and SHOULD 1777 support both the alternate text form and the FQDN format for IPv6 1778 addresses. 1780 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1781 referring to configuration data local to the Diameter client that 1782 describes the interface and medium-specific address to use. 1784 7.4.4 Tunnel-Server-Endpoint AVP 1786 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of UTF8String, and 1787 contains the address of the server end of the tunnel. It MAY be used 1788 in an authorization request as a hint to the server that a specific 1789 endpoint is desired, but the server is not required to honor the hint 1790 in the corresponding response. 1792 This AVP SHOULD be included in the corresponding Accounting-Request | 1793 messages, in which case it indicates the address from which the 1794 tunnel was initiated. This AVP, along with the Tunnel-Client-Endpoint 1795 and Session-Id AVP [2], MAY be used to provide a globally unique 1796 means to identify a tunnel for accounting and auditing purposes. 1798 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1799 fully qualified domain name (FQDN) of the tunnel client machine, or 1800 it is a "dotted-decimal" IP address. Conformant implementations MUST 1801 support the dotted-decimal format and SHOULD support the FQDN format 1802 for IP addresses. 1804 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1805 FQDN of the tunnel client machine, or it is a text representation of 1806 the address in either the preferred or alternate form [5]. 1807 Conformant implementations MUST support the preferred form and SHOULD 1808 support both the alternate text form and the FQDN format for IPv6 1809 addresses. 1811 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1812 referring to configuration data local to the Diameter client that 1813 describes the interface and medium-specific address to use. 1815 7.4.5 Tunnel-Password AVP 1817 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1818 contain a password to be used to authenticate to a remote server. 1819 This AVP MUST only be present in authorization responses in an 1820 encrypted form, using one of the methods described in [2] and [13]. 1822 7.4.6 Tunnel-Private-Group-ID AVP 1824 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type UTF8String, 1825 and contains the group ID for a particular tunneled session. The 1826 Tunnel-Private-Group-ID AVP MAY be included in an authorization 1827 request if the tunnel initiator can pre-determine the group resulting 1828 from a particular connection and SHOULD be included in the 1829 authorization response if this tunnel session is to be treated as 1830 belonging to a particular private group. Private groups may be used 1831 to associate a tunneled session with a particular group of users. 1832 For example, it MAY be used to facilitate routing of unregistered IP 1833 addresses through a particular interface. This AVP SHOULD be | 1834 included in the Accounting-Request messages which pertain to the | 1835 tunneled session. 1837 7.4.7 Tunnel-Assignment-ID AVP 1839 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1840 is used to indicate to the tunnel initiator the particular tunnel to 1841 which a session is to be assigned. Some tunneling protocols, such as 1842 PPTP [14] and L2TP, allow for sessions between the same two tunnel 1843 endpoints to be multiplexed over the same tunnel and also for a given 1844 session to utilize its own dedicated tunnel. This attribute provides 1845 a mechanism for Diameter to be used to inform the tunnel initiator 1846 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1847 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1848 sharing multiplexed tunnels to be assigned to different multiplexed 1849 tunnels. 1851 A particular tunneling implementation may assign differing 1852 characteristics to particular tunnels. For example, different 1853 tunnels may be assigned different QOS parameters. Such tunnels may 1854 be used to carry either individual or multiple sessions. The Tunnel- 1855 Assignment-ID attribute thus allows the Diameter server to indicate 1856 that a particular session is to be assigned to a tunnel that provides 1857 an appropriate level of service. It is expected that any QOS-related 1858 Diameter tunneling attributes defined in the future that accompany 1859 this attribute will be associated by the tunnel initiator with the ID 1860 given by this attribute. In the meantime, any semantic given to a 1861 particular ID string is a matter left to local configuration in the 1862 tunnel initiator. 1864 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1865 the tunnel initiator. The ID it specifies is intended to be of only 1866 local use to Diameter and the tunnel initiator. The ID assigned by 1867 the tunnel initiator is not conveyed to the tunnel peer. 1869 This attribute MAY be included in authorization responses. The tunnel 1870 initiator receiving this attribute MAY choose to ignore it and assign 1871 the session to an arbitrary multiplexed or non-multiplexed tunnel | 1872 between the desired endpoints. This AVP SHOULD also be included in | 1873 the Accounting-Request messages which pertain to the tunneled | 1874 session. 1876 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1877 should assign a session to a tunnel in the following manner: 1879 - If this AVP is present and a tunnel exists between the specified 1880 endpoints with the specified ID, then the session should be 1881 assigned to that tunnel. 1883 - If this AVP is present and no tunnel exists between the 1884 specified endpoints with the specified ID, then a new tunnel 1885 should be established for the session and the specified ID 1886 should be associated with the new tunnel. 1888 - If this AVP is not present, then the session is assigned to an 1889 unnamed tunnel. If an unnamed tunnel does not yet exist between 1890 the specified endpoints then it is established and used for this 1891 and subsequent sessions established without the Tunnel- 1892 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1893 session for which a Tunnel-Assignment-ID AVP was not specified 1894 to a named tunnel (i.e. one that was initiated by a session 1895 specifying this AVP). 1897 Note that the same ID may be used to name different tunnels if such 1898 tunnels are between different endpoints. 1900 7.4.8 Tunnel-Preference AVP 1902 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1903 used to identify the relative preference assigned to each tunnel when 1904 more than one set of tunneling AVPs is returned within separate 1905 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1906 hint to the server that a specific preference is desired, but the 1907 server is not required to honor the hint in the corresponding 1908 response. 1910 For example, suppose that AVPs describing two tunnels are returned by 1911 the server, one with a Tunnel-Type of PPTP and the other with a 1912 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1913 the Tunnel-Types returned, it will initiate a tunnel of that type. 1914 If, however, it supports both tunnel protocols, it SHOULD use the 1915 value of the Tunnel-Preference AVP to decide which tunnel should be 1916 started. The tunnel having the numerically lowest value in the Value 1917 field of this AVP SHOULD be given the highest preference. The values 1918 assigned to two or more instances of the Tunnel-Preference AVP within 1919 a given authorization response MAY be identical. In this case, the 1920 tunnel initiator SHOULD use locally configured metrics to decide 1921 which set of AVPs to use. 1923 7.4.9 Tunnel-Client-Auth-ID AVP 1925 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1926 specifies the name used by the tunnel initiator during the 1927 authentication phase of tunnel establishment. It MAY be used in an 1928 authorization request as a hint to the server that a specific 1929 preference is desired, but the server is not required to honor the 1930 hint in the corresponding response. This AVP MUST be present in the 1931 authorization response if an authentication name other than the 1932 default is desired. This AVP SHOULD be included in the Accounting- | 1933 Request messages which pertain to the tunneled session. 1935 7.4.10 Tunnel-Server-Auth-ID AVP 1937 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1938 and specifies the name used by the tunnel terminator during the 1939 authentication phase of tunnel establishment. It MAY be used in an 1940 authorization request as a hint to the server that a specific 1941 preference is desired, but the server is not required to honor the 1942 hint in the corresponding response. This AVP MUST be present in the 1943 authorization response if an authentication name other than the 1944 default is desired. This AVP SHOULD be included in the the | 1945 Accounting-Request messages which pertain to the tunneled session. 1947 8.0 Accounting AVPs 1949 This section contains a description of the AVPs defined in this 1950 document that are to be included in Diameter accounting messages [2]. 1952 8.1 Accounting-Input--Octets AVP | 1954 The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, | 1955 and contains the number of octets received from the user. | 1957 For NASREQ usage, this AVP indicates how many octets have been | 1958 received from the port in the course of this session and can only be | 1959 present in ACR messages with an Accounting-Record-Type of | 1960 INTERIM_RECORD or STOP_RECORD. 1962 8.2 Accounting-Output-Octets AVP | 1964 The Accounting-Output-Octets AVP (AVP Code 364) is of type | 1965 Unsigned64, and contains the number of octets sent to the user. | 1967 For NASREQ usage, this AVP indicates how many octets have been sent | 1968 to the port in the course of this session and can only be present in | 1969 ACR messages with an Accounting-Record-Type of INTERIM_RECORD or | 1970 STOP_RECORD. 1972 8.3 Acct-Session-Time AVP | 1974 The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32, and | 1975 indicates the length of the current session in seconds. It can only | 1976 be present in ACR messages with an Accounting-Record-Type of | 1977 INTERIM_RECORD or STOP_RECORD. 1979 8.4 Accounting-Input-Packets AVP | 1981 The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, | 1982 and contains the number of packets received from the user. | 1984 For NASREQ usage, this AVP indicates how many packets have been | 1985 received from the port over the course of a session being provided to | 1986 a Framed User and can only be present in ACR messages with an | 1987 Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD. 1989 8.5 Accounting-Output-Packets AVP | 1991 The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, | 1992 and contains the number of IP packets sent to the user. | 1994 For NASREQ usage, this AVP indicates how many packets have been sent | 1995 to the port over the course of a session being provided to a Framed | 1996 User and can only be present in ACR messages with an Accounting- | 1997 Record-Type of INTERIM_RECORD or STOP_RECORD. 1999 8.6 Accounting-Authentication-Type AVP 2001 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 2002 Unsigned32, and specifies how the user was authenticated. The 2003 supported values are listed in [33]. 2005 8.7 Acct-Tunnel-Connection AVP 2007 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 2008 and contains the identifier assigned to the tunnel session. This AVP, 2009 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 2010 AVPs, may be used to provide a means to uniquely identify a tunnel 2011 session for auditing purposes. 2013 The format of the identifier in this AVP depends upon the value of 2014 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 2015 connection, the L2TP Tunnel ID and Call ID might be encoded in this 2016 field. The exact encoding of this field is implementation dependent. 2018 8.8 Acct-Tunnel-Packets-Lost AVP 2020 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 2021 and contains the number of packets lost on a given link. 2023 8.9 Accounting-EAP-Auth-Method AVP 2025 This Accounting-EAP-Auth-Method AVP (AVP Code 401) is of type 2026 Enumerated, and uses the EAP Type name space defined in [25]. 2028 9.0 RADIUS/Diameter Protocol Interactions 2030 This section describes some basic guidelines that may be used by 2031 servers that act as protocol gateways. Note that this document does 2032 not restrict implementations from creating other methods, as long as 2033 the bridging function doesn't break the RADIUS nor the Diameter 2034 protocol. 2036 There are essentially two different situations that must be handled; 2037 one where a RADIUS request is received that must be forwarded as a 2038 Diameter request, and the inverse. Note that this section uses two 2039 different terms; AVP and attribute. The former is used to signify a 2040 Diameter AVP, while the latter is used to signify a RADIUS attribute. 2042 9.1 RADIUS request forwarded as Diameter request 2044 This section describes the actions that should be followed when a 2045 protocol Gateway receives a RADIUS message that is to be translated 2046 to a Diameter message. 2048 It is important to note that RADIUS servers are inherently stateless, 2049 and this section maintains that assumption. It is quite possible for 2050 the RADIUS messages that comprises the session (i.e. authentication 2051 and accounting messages) be handled by different protocol gateways in 2052 the proxy network. Therefore a RADIUS->Diameter protocol gateway 2053 cannot maintain session state information. 2055 When a protocol gateway receives a RADIUS message, the following 2056 steps should be taken: 2058 - If the NAS-IP-Address attribute is present in the RADIUS 2059 message, the name MUST be translated to its corresponding FQDN, 2060 and encoded in the Diameter message's Origin-Host AVP. If the 2061 NAS-Identifier attribute is present, the data can be used in the 2062 Origin-Host AVP. 2063 - The Origin-Host AVP is added with the local server's identity. 2064 This will ensure that the corresponding response will be 2065 returned to the correct gateway server. The aaa protocol 2066 specified in the identity would be set to "radius". 2067 - The Destination-Realm AVP is created from the information found 2068 in the RADIUS User-Name attribute. 2069 - If the RADIUS CHAP-Password attribute is present, the Ident and 2070 Data portion of the attribute are used to create the CHAP-Auth 2071 Grouped AVP. 2072 - The Gateway Server must maintain state information relevant to 2073 the RADIUS request, such as the Identifier field in the RADIUS 2074 header, any existing RADIUS Proxy-State attribute as well as the 2075 source IP address and port number of the UDP packet. These may 2076 be maintained locally in a state table, or may be saved in a 2077 Proxy-Info AVP. 2078 - If the Acct-Session-Id attribute was found in the request, the 2079 contents are inserted in the Acct-Session-Id AVP. 2080 - If the RADIUS request contained a State attribute, and the 2081 prefix of the data is "Diameter/", the data following the prefix 2082 contains the Diameter Session-Id. If no such attributes are 2083 present, and the RADIUS command is an Access-Request, a new 2084 Session-Id is created. The Session-Id is included in the 2085 Session-Id AVP. 2086 - If the RADIUS message received is an Accounting-Request, with 2087 the Acct-Status-Type attribute set to STOP, the local server 2088 MUST issue a Session-Termination-Request message once the 2089 Diameter Accounting-Answer has been received. 2090 - If the RADIUS message contains the Accounting-Input-Octets, 2091 Accounting-Input-Packets, Accounting-Output-Octets or 2092 Accounting-Output-Packets, these attributes must be converted to 2093 the Diameter equivalent ones. Further, if the Acct-Input- 2094 Gigawords or Acct-Output-Gigawords attributes are present, these 2095 must be used to properly compute the Diameter accounting AVPs. 2097 The corresponding Diameter response is always guaranteed to be 2098 received by the same protocol gateway that translated the original 2099 request, due to the contents of the Origin-Host AVP in the Diameter 2100 request. The following steps are applied to the response message 2101 during the Diameter to RADIUS translation: 2103 - If the Diameter Command-Code is set to AA-Answer and the Result- 2104 Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must 2105 send a RADIUS Access-Challenge with the Diameter Session-Id and 2106 the Origin-Host AVPs encapsulated in the RADIUS State attribute, 2107 with the prefix "Diameter/". This is necessary in order to 2108 ensure that the protocol gateway that will receive the 2109 subsequent RADIUS Access-Request will have access to the Session 2110 Identifier, and be able to set the Destination-Host to the 2111 correct value. If the Multi-Round-Time-Out AVP is present, the 2112 value of the AVP MUST be inserted in the RADIUS Session-Timeout 2113 AVP. 2114 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 2115 AVP is saved in a new RADIUS Class attribute, whose format 2116 consists of the string "Diameter/" followed by the Diameter 2117 Session Identifier. This will ensure that the subsequent 2118 Accounting messages, which could be received by any protocol 2119 gateway, would have access to the original Diameter Session 2120 Identifier. 2121 - If a Proxy-State attribute was present in the RADIUS request, 2122 the same attribute is added in the response. This information 2123 may be found in the Proxy-Info AVP, or in a local state table. 2124 - If state information regarding the RADIUS request was saved in a 2125 Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and 2126 port number are extracted and used in issuing the RADIUS reply. 2128 9.2 Diameter request forwarded as RADIUS request 2130 When a server receives a Diameter request that is to be forwarded to 2131 a RADIUS entity, the following steps are an example of the steps that 2132 may be followed: 2134 - The Origin-Host AVP's value is inserted in the NAS-Identifier 2135 attribute. 2136 - The following information MUST be present in the corresponding 2137 Diameter response, and therefore MUST be saved either in a local 2138 state table, or it MAY be encoded in a RADIUS Proxy-State 2139 attribute: 2140 1. Origin-Host AVP 2141 2. Session-Id AVP 2142 3. Proxy-Info AVP 2143 4. Route-Record AVPs (in the proper order) 2144 5. Any other AVP that MUST be present in the response, and 2145 has no corresponding RADIUS attribute. 2146 - If the CHAP-Auth AVP is present, the Grouped AVPs are used 2147 to create the RADIUS CHAP-Password. | 2148 - If the Accounting-Input-Octets, Accounting-Input-Packets, | 2149 Accounting-Output-Octets or Accounting-Output-Packets AVPs 2150 are present, these must be translated to the corresponding 2151 RADIUS attributes. Further, the the Diameter AVPs do not 2152 fit within a 32-bit RADIUS attribute, the RADIUS Acct- 2153 Input-Gigawords and Acct-Output-Gigawords must be used. 2155 When the corresponding response is received by the gateway server, 2156 which is guaranteed in the RADIUS protocol, the following steps may 2157 be followed: 2159 - If the RADIUS code is set to Access-Challenge, a Diameter AA- 2160 Answer message is created with the Result-Code set to 2161 DIAMETER_MULTI_ROUND_AUTH. If the Session-Timeout AVP is present 2162 in the RADIUS message, its value is inserted in the Multi-Round- 2163 Time-Out AVP. 2164 - If a Proxy-Info AVP is present, extract the encoded information, 2165 otherwise retrieve the information from the local state table. 2166 - The request's Origin-Host information is added to the 2167 Destination-Host AVP. 2168 - The Session-Id information is added to the Session-Id AVP. 2169 - The Route-Record AVPs MUST be added to the Diameter message, in 2170 the same order they were present in the request. 2171 - If a Proxy-Info AVP was present in the request, the same AVP 2172 MUST be added to the response. 2173 - If the RADIUS State attributes are present, these attributes 2174 must be present in the Diameter response. 2175 - Any other AVPs that were saved, and MUST be present in the 2176 response, are added to the message. 2178 10.0 AVP Occurrence Table 2180 The following tables presents the AVPs defined in this document, and 2181 specifies in which Diameter messages they MAY, or MAY NOT be present. 2182 Note that AVPs that can only be present within a Grouped AVP are not 2183 represented in this table. 2185 The table uses the following symbols: 2186 0 The AVP MUST NOT be present in the message. 2187 0+ Zero or more instances of the AVP MAY be present in the 2188 message. 2189 0-1 Zero or one instance of the AVP MAY be present in the 2190 message. 2191 1 One instance of the AVP MUST be present in the message. 2193 10.1 NASREQ Command AVP Table 2195 The table in this section is limited to the Command Codes defined in 2196 this specification. 2198 +-----------------------+ 2199 | Command-Code | 2200 |-----+-----+-----+-----+ 2201 Attribute Name | AAR | AAA | DER | DEA | 2202 ------------------------------|-----+-----+-----+-----| 2203 ARAP-Challenge-Response | 0 | 0-1 | 0 | 0 | | 2204 ARAP-Features | 0 | 0-1 | 0 | 0 | | 2205 ARAP-Password | 0-1 | 0 | 0 | 0 | 2206 ARAP-Security | 0-1 | 0-1 | 0 | 0 | | 2207 ARAP-Security-Data | 0+ | 0+ | 0 | 0 | | 2208 ARAP-Zone-Access | 0 | 0-1 | 0 | 0 | | 2209 Auth-Application-Id | 1 | 1 | 1 | 1 | 2210 Auth-Grace-Period | 0-1 | 0-1 | 0-1 | 0-1 | 2211 Auth-Request-Type | 1 | 1 | 1 | 1 | | 2212 Auth-Session-State | 0-1 | 0-1 | 0-1 | 0-1 | 2213 Authorization-Lifetime | 0-1 | 0-1 | 0-1 | 0-1 | 2214 Callback-Id | 0 | 0-1 | 0 | 0-1 | 2215 Callback-Number | 0-1 | 0-1 | 0-1 | 0-1 | 2216 Called-Station-Id | 0-1 | 0 | 0-1 | 0 | 2217 Calling-Station-Id | 0-1 | 0 | 0-1 | 0 | 2218 CHAP-Auth | 0-1 | 0 | 0 | 0 | 2219 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 2220 Connect-Info | 0-1 | 0 | 0-1 | 0 | 2221 Destination-Host | 0-1 | 0 | 0-1 | 0 | | 2222 Destination-Realm | 1 | 0 | 1 | 0 | 2223 EAP-Payload | 0 | 0 | 1 | 0-1 | | 2224 Error-Message | 0 | 0-1 | 0 | 0-1 | 2225 Error-Reporting-Host | 0 | 0-1 | 0 | 0+ | 2226 Filter-Id | 0 | 0+ | 0 | 0+ | 2227 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0-1 | 2228 Framed-Appletalk-Network | 0 | 0+ | 0 | 0+ | 2229 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0-1 | 2230 Framed-Compression | 0+ | 0+ | 0+ | 0+ | 2231 Framed-Interface-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2232 Framed-IP-Address | 0-1 | 0-1 | 0-1 | 0-1 | 2233 Framed-IP-Netmask | 0-1 | 0-1 | 0-1 | 0-1 | 2234 Framed-IP-Route | 0 | 0+ | 0 | 0+ | 2235 Framed-IPv6-Prefix | 0+ | 0+ | 0+ | 0+ | 2236 Framed-IPv6-Pool | 0 | 0-1 | 0 | 0-1 | | 2237 Framed-IPv6-Route | 0 | 0+ | 0 | 0+ | | 2238 Framed-IPX-Network | 0 | 0-1 | 0 | 0-1 | 2239 Framed-MTU | 0-1 | 0-1 | 0-1 | 0-1 | | 2240 Framed-Protocol | 0-1 | 0-1 | 0-1 | 0-1 | | 2241 Framed-Routing | 0 | 0-1 | 0 | 0-1 | | 2242 Idle-Timeout | 0-1 | 0-1 | 0-1 | 0-1 | 2243 Login-IP-Host | 0+ | 0+ | 0 | 0 | 2244 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2245 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2246 +-----------------------+ 2247 | Command-Code | 2248 |-----+-----+-----+-----+ 2249 Attribute Name | AAR | AAA | DER | DEA | 2250 ------------------------------|-----+-----+-----+-----| 2251 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2252 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2253 Login-Service | 0 | 0-1 | 0 | 0 | | 2254 Login-TCP-Port | 0 | 0-1 | 0 | 0 | | 2255 NAS-Filter-Rule | 0 | 0+ | 0 | 0+ | 2256 NAS-Identifier | 0-1 | 0 | 0-1 | 0 | | 2257 NAS-IP-Address | 0-1 | 0 | 0-1 | 0 | | 2258 NAS-Key-Binding | 0-1 | 0 | 0-1 | 0 | 2259 NAS-Port | 0-1 | 0 | 0-1 | 0 | | 2260 NAS-Port-Type | 0-1 | 0 | 0-1 | 0 | 2261 NAS-Session-Key | 0 | 0+ | 0 | 0+ | 2262 Origin-Host | 1 | 1 | 1 | 1 | 2263 Origin-Realm | 1 | 1 | 1 | 1 | 2264 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2265 Password-Retry | 0 | 0-1 | 0 | 0 | 2266 Port-Limit | 0-1 | 0-1 | 0-1 | 0-1 | | 2267 Prompt | 0 | 0-1 | 0 | 0 | 2268 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 2269 Redirect-Host | 0 | 0+ | 0 | 0+ | 2270 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 2271 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 2272 Reply-Message | 0 | 0+ | 0 | 0 | | 2273 Result-Code | 0 | 1 | 0 | 1 | 2274 Re-Auth-Request-Type | 0 | 0-1 | 0 | 0-1 | 2275 Route-Record | 0+ | 0 | 0+ | 0 | 2276 Service-Type | 0-1 | 0-1 | 0-1 | 0-1 | | 2277 Session-Id | 1 | 1 | 1 | 1 | 2278 Session-Timeout | 0-1 | 0-1 | 0-1 | 0-1 | | 2279 State | 0-1 | 0-1 | 0-1 | 0-1 | | 2280 Tunneling | 0+ | 0+ | 0+ | 0+ | 2281 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 2282 User-Password | 0-1 | 0 | 0 | 0 | 2284 10.2 Accounting AVP Table 2286 The tables in this section are used to represent which AVPs defined 2287 in this document are to be present in the Accounting messages, 2288 defined in [1]. 2290 10.2.1 Framed Access 2291 The table in this section is used when the Service-Type specifies 2292 Framed Access. 2294 +-----------+ 2295 | Command | 2296 | Code | 2297 |-----+-----+ 2298 Attribute Name | ACR | ACA | 2299 ---------------------------------------|-----+-----+ 2300 Accounting-Authentication-Type | 1 | 0-1 | 2301 Accounting-EAP-Auth-Method | 1 | 0-1 | 2302 Accounting-Input-Octets | 1 | 1 | | 2303 Accounting-Input-Packets | 1 | 1 | | 2304 Accounting-Output-Octets | 1 | 1 | | 2305 Accounting-Output-Packets | 1 | 1 | | 2306 Acct-Session-Time | 1 | 1 | | 2307 Accounting-State | 0 | 0 | 2308 Acct-Tunnel-Connection | 0-1 | 0-1 | 2309 Acct-Tunnel-Packets-Lost | 0-1 | 0-1 | 2310 Framed-AppleTalk-Link | 0-1 | 0-1 | 2311 Framed-AppleTalk-Network | 0-1 | 0-1 | 2312 Framed-AppleTalk-Zone | 0-1 | 0-1 | 2313 Framed-Compression | 0-1 | 0-1 | 2314 Framed-IP-Address | 0-1 | 0-1 | 2315 Framed-IP-Netmask | 0-1 | 0-1 | 2316 Framed-IPX-Network | 0-1 | 0-1 | 2317 Framed-MTU | 0-1 | 0-1 | 2318 Framed-Protocol | 0-1 | 0-1 | 2319 Framed-Route | 0-1 | 0-1 | 2320 Framed-Routing | 0-1 | 0-1 | 2321 NAS-Filter-Rule | 0-1 | 0-1 | | 2322 NAS-Identifier | 0-1 | 0-1 | | 2323 NAS-IP-Address | 0-1 | 0-1 | | 2324 NAS-Key-Binding | 0 | 0 | | 2325 NAS-Port | 0-1 | 0-1 | | 2326 NAS-Port-Type | 0-1 | 0-1 | | 2327 NAS-Session-Key | 0 | 0 | | 2328 Service-Type | 0-1 | 0-1 | 2329 State | 0 | 0 | | 2330 Tunnel-Assignment-ID | 0-1 | 0-1 | 2331 Tunnel-Client-Endpoint | 0-1 | 0-1 | 2332 Tunnel-Medium-Type | 0-1 | 0-1 | 2333 Tunnel-Private-Group-ID | 0-1 | 0-1 | 2334 Tunnel-Server-Endpoint | 0-1 | 0-1 | 2335 Tunnel-Type | 0-1 | 0-1 | 2336 ---------------------------------------|-----+-----+ 2337 10.2.2 Non-Framed Access 2339 The table in this section is used when the Service-Type specifies 2340 Non-Framed Access. 2342 +-----------+ 2343 | Command | 2344 | Code | 2345 |-----+-----+ 2346 Attribute Name | ACR | ACA | 2347 ---------------------------------------|-----+-----+ 2348 Accounting-Authentication-Type | 1 | 0-1 | 2349 Accounting-Input-Octets | 1 | 1 | | 2350 Accounting-Input-Packets | 0 | 0 | | 2351 Accounting-Output-Octets | 1 | 1 | | 2352 Accounting-Output-Packets | 0 | 0 | | 2353 Acct-Session-Time | 1 | 1 | | 2354 Accounting-State | 0 | 0 | 2355 Login-IP-Host | 0-1 | 0-1 | 2356 Login-LAT-Service | 0-1 | 0-1 | 2357 Login-LAT-Node | 0-1 | 0-1 | 2358 Login-LAT-Group | 0-1 | 0-1 | 2359 Login-LAT-Port | 0-1 | 0-1 | 2360 Login-Service | 0-1 | 0-1 | 2361 Login-TCP-Port | 0-1 | 0-1 | 2362 NAS-Filter-Rule | 0 | 0 | | 2363 NAS-Identifier | 0-1 | 0-1 | | 2364 NAS-IP-Address | 0-1 | 0-1 | | 2365 NAS-Key-Binding | 0 | 0 | | 2366 NAS-Port | 0-1 | 0-1 | | 2367 NAS-Port-Type | 0-1 | 0-1 | | 2368 NAS-Session-Key | 0 | 0 | | 2369 Service-Type | 0-1 | 0-1 | 2370 State | 0 | 0 | | 2371 ---------------------------------------|-----+-----+ 2373 11.0 IANA Considerations 2375 This section contains the namespaces that have either been created in 2376 this specification, or the values assigned to existing namespaces 2377 managed by IANA. 2379 11.1 Command Codes 2381 This specification assigns the values 265 and 268 from the Command 2382 Code namespace defined in [2]. See sections 3.1 and 4.2 for the 2383 assignment of the namespace in this specification. 2385 11.2 AVP Codes 2387 This specification assigns the values 363-366 and 400-414 from the | 2388 AVP Code namespace defined in [2]. See section 2.1 for the assignment 2389 of the namespace in this specification. Note that the values 363-366 | 2390 are jointly, but consistently, assigned in [30]. 2392 This specification also makes use of AVPs in the 0-255 range, which 2393 are defined in [33]. 2395 11.3 Application Identifier 2397 This specification assigns the value one (1) to the Application 2398 Identifier namespace defined in [1]. See section 1.2 for more 2399 information. 2401 11.4 NAS-Key-Binding AVP Values 2403 As defined in Section 2.1.6, the NAS-Key-Binding AVP (AVP Code 404) 2404 defines the values 1-4. All remaining values, other than zero, are 2405 available for assignment via a Designated Expert [12]. 2407 11.5 NAS-Key-Direction AVP Values 2409 As defined in Section 2.1.3, the NAS-Key-Direction AVP (AVP Code 406) 2410 defines the values 1-3. All remaining values, other than zero, are 2411 available for assignment via IETF Consensus [12]. 2413 11.6 NAS-Key-Type AVP Values 2415 As defined in Section 2.1.4, the NAS-Key-Type AVP (AVP Code 407) 2416 defines the values 1-5. All remaining values, other than zero, are 2417 available for assignment via IETF Consensus [12]. 2419 11.7 CHAP-Algorithm AVP Values 2421 As defined in Section 3.1.1.4, the CHAP-Algorithm AVP (AVP Code 412) 2422 uses the values of the "PPP AUTHENTICATION ALGORITHMS" namespace 2423 defined in [6]. 2425 12.0 Security Considerations 2427 This document does not contain any security protocol, but does 2428 discuss how PPP authentication protocols can be carried within the 2429 Diameter protocol. The PPP authentication protocols that are 2430 described are PAP, CHAP and EAP. 2432 The use of PAP SHOULD be discouraged, since it exposes user's 2433 passwords to possibly non-trusted entities. PAP is also frequently 2434 used for use with One-Time Passwords (OTP), which does not expose any 2435 security risks. However, it is highly recommended that OTP be 2436 supported through the EAP protocol. 2438 This document also describes how CHAP can be carried within the 2439 Diameter protocol, which is required for backward RADIUS 2440 compatibility. The CHAP protocol, as used in a RADIUS environment, 2441 facilitates authentication replay attacks, and therefore SHOULD NOT 2442 be used when EAP is available. 2444 This specification also defines a method by which the home Diameter 2445 server can create and distribute registration keys to be used to 2446 authenticate link layer messages (e.g. PPP ECP). The keys SHOULD be 2447 be protected using the methods defined in [13]. 2449 13.0 References 2451 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentica- 2452 tion Dial In User Service (RADIUS)", RFC 2865, June 2000. | 2454 [2] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, J. Lough- | 2455 ney, "Diameter Base Protocol", draft-ietf-aaa-diameter-10.txt, IETF | 2456 work in progress, March 2002. 2458 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. January 2459 1999. 2461 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, 2462 January 1999. 2464 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2465 RFC 2373, July 1998 2467 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2468 (CHAP)", RFC 1994, August 1996. 2470 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial links", 2471 RFC 1144, February 1990. 2473 [8] ISO 8859. International Standard -- Information Processing -- 8-bit 2474 Single-Byte Coded Graphic Character Sets -- Part 1: Latin Alphabet 2475 No. 1, ISO 8859-1:1987. 2477 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol (MP)", 2478 RFC 1717, November 1994. 2480 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2481 October 1994 2483 [11] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications for 2484 Tunnel Protocol Support", RFC 2867, June 2000. 2486 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 2487 els", BCP 14, RFC 2119, March 1997. | 2489 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Applica- | 2490 tion", draft-ietf-aaa-diameter-cms-sec-04.txt, IETF work in | 2491 progress, March 2002. 2493 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, 2494 G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999 2496 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two Forward- 2497 ing (Protocol) 'L2F'", RFC 2341, May 1998 2499 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., 2500 Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 2501 1999 2503 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 2504 February 1997 2506 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2507 Protocol", RFC 2401, November 1998 2509 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 2511 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 2512 1996 2514 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 2515 August 1995 2517 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2518 Encapsulation (GRE)", RFC 1701, October 1994 2520 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2522 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2523 Server Protocols", RFC 3169, September 2001. 2525 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication Pro- 2526 tocol (EAP)." RFC 2284, March 1998. 2528 [26] G. Pall, G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Pro- 2529 tocol", RFC 3078, March 2001. 2531 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considerations 2532 Section in RFCs", BCP 26, RFC 2434, October 1998 2534 [28] G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications for 2535 Tunnel Protocol Support", RFC 2867, June 2000. 2537 [29] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2538 2279, January 1998. | 2540 [30] P. Calhoun, C. Perkins, T. Johansson, "Diameter Mobile IP Applica- | 2541 tion", draft-ietf-aaa-diameter-mobileip-09.txt, IETF work in | 2542 progress, March 2002. 2544 [31] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret, 2545 "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2546 2000. 2548 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2869, 2549 June 2000. | 2551 [33] IANA, "RADIUS Types", http://www.isi.edu/in-notes/iana/assign- | 2552 ments/radius-types 2554 [34] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2556 [35] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, Version 2 2557 (DESE-bis)", RFC 2419, September 1998. 2559 [36] H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2560 2402, September 1998. 2562 [37] B. Aboba, G. Zorn, D. Mitton, "RADIUS and IPv6", RFC 3162, August 2563 2001. 2565 [38] Information technology - Telecommunications and information 2566 exchange between systems - Local and metropolitan area networks - 2567 Specific Requirements Part 11: Wireless LAN Medium Access Control 2568 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 2569 802.11-1999, 1999. 2571 14.0 Acknowledgements 2573 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2574 Allen Simpson, and Steve Willens for their work on the original 2575 RADIUS, from which much of the concepts in this specification were 2576 derived; Carl Rigney and Ward Willats for [32]; Bernard Aboba and 2577 Dave Mitton for [38]; Dory Leifer, John Shriver, Matt Holdrege and 2578 Ignacio Goyret for their work on [33]. This document stole text and 2579 concepts from both [32] and [33]. Thanks goes to Carl Williams for 2580 providing IPv6 specific text. 2582 The authors would also like to acknowledge the following people for 2583 their contributions in the development of the Diameter protocol: 2585 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2586 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2587 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2588 and Jeff Weisberg 2590 Finally, Pat Calhoun would like to thank Sun Microsystems since most 2591 of the effort put into this document was done while he was in their 2592 employ. 2594 15.0 Authors' Addresses 2596 Questions about this memo can be directed to: 2598 Pat R. Calhoun 2599 Black Storm Networks 2600 250 Cambridge Avenue, Suite 200 2601 Palo Alto, California, 94306 2602 USA 2604 Phone: +1 650-617-2932 2605 Fax: +1 650-786-6445 2606 E-mail: pcalhoun@diameter.org 2608 William Bulley 2609 Merit Network, Inc. 2611 Building One, Suite 2000 2612 4251 Plymouth Road 2613 Ann Arbor, Michigan 48105-2785 2614 USA 2616 Phone: +1 734-764-9993 2617 Fax: +1 734-647-3185 2618 E-mail: web@merit.edu 2620 Allan C. Rubens 2621 Tut Systems, Inc. 2622 220 E. Huron, Suite 260 2623 Ann Arbor, MI 48104 2624 USA 2626 Phone: +1 734-995-1697 2627 E-Mail: arubens@tutsys.com 2629 Jeff Haag 2630 Cisco Systems 2631 7025 Kit Creek Road 2632 PO Box 14987 2633 Research Triangle Park, NC 27709 2635 Phone: 1-919-392-2353 2636 E-Mail: haag@cisco.com 2638 Glen Zorn 2639 Cisco Systems, Inc. 2640 500 108th Avenue N.E., Suite 500 2641 Bellevue, WA 98004 2642 USA 2644 Phone: +1 425 471 4861 2645 E-Mail: gwz@cisco.com 2647 David Spence | 2648 Interlink Networks, Inc. | 2649 775 Technology Drive, Suite 200 | 2650 Ann Arbor, MI 48108 | 2651 USA | 2653 Phone: +1 734 821 1203 | 2654 Fax: +1 734 821 1235 | 2656 EMail: dspence@interlinknetworks.com | 2658 16.0 Full Copyright Statement 2660 Copyright (C) The Internet Society (2002). All Rights Reserved. | 2662 This document and translations of it may be copied and furnished to 2663 others, and derivative works that comment on or otherwise explain it 2664 or assist in its implementation may be prepared, copied, published 2665 and distributed, in whole or in part, without restriction of any 2666 kind, provided that the above copyright notice and this paragraph are 2667 included on all such copies and derivative works. However, this docu- 2668 ment itself may not be modified in any way, such as by removing the 2669 copyright notice or references to the Internet Society or other 2670 Internet organizations, except as needed for the purpose of develop- 2671 ing Internet standards in which case the procedures for copyrights 2672 defined in the Internet Standards process must be followed, or as 2673 required to translate it into languages other than English. The lim- 2674 ited permissions granted above are perpetual and will not be revoked 2675 by the Internet Society or its successors or assigns. This document 2676 and the information contained herein is provided on an "AS IS" basis 2677 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2678 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2679 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2680 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2681 FITNESS FOR A PARTICULAR PURPOSE. |