idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 55 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 56 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 25 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 553 has weird spacing: '... of the conte...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The following tables presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8353 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 2289, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2301, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2315, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2325, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2329, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2336, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2339, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2342, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2345, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2348, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2351, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2354, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2370, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2393, but no explicit reference was found in the text == Unused Reference: '36' is defined on line 2395, but no explicit reference was found in the text == Unused Reference: '37' is defined on line 2398, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-03 ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') ** Obsolete normative reference: RFC 2373 (ref. '5') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '11') == Outdated reference: A later version (-02) exists of draft-ietf-aaa-diameter-e2e-sec-01 -- 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') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '24') ** Obsolete normative reference: RFC 2284 (ref. '25') (Obsoleted by RFC 3748) -- Possible downref: Normative reference to a draft: 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-03 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-06 -- Possible downref: Normative reference to a draft: ref. '31' ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '32') ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '33') -- Possible downref: Non-RFC (?) normative reference: ref. '34' ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '35') -- Duplicate reference: RFC2869, mentioned in '36', was also mentioned in '32'. ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '36') -- Duplicate reference: RFC2868, mentioned in '37', was also mentioned in '33'. ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '37') Summary: 28 errors (**), 0 flaws (~~), 29 warnings (==), 11 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 Sun Microsystems, Inc. 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 May 2001 13 Diameter NASREQ Extensions 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 This document is an individual contribution for consideration by the 37 AAA Working Group of the Internet Engineering Task Force. Comments 38 should be submitted to the diameter@diameter.org mailing list. 40 Distribution of this memo is unlimited. 42 Copyright (C) The Internet Society 2001. All Rights Reserved. 44 Abstract 46 This document describes the Diameter extension that is used for AAA 47 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 48 extension, combined with the base protocol, satisfies the 49 requirements defined in the NASREQ AAA criteria specification and the 50 ROAMOPS AAA Criteria specification. 52 Given that it is expected that initial deployments of the Diameter 53 protocol in a dial-up environment will include legacy systems, this 54 extension was carefully designed to ease the burden of servers that 55 must perform protocol conversion between RADIUS and Diameter. This 56 is achieved by re-using the RADIUS address space, eliminating the 57 need to perform attribute lookups. 59 Table of Contents 61 1.0 Introduction 62 1.1 Requirements language 63 1.2 Advertising extension support 64 2.0 Supported AVPs 65 2.1 Diameter AVPs 66 2.1.1 Request-Type AVP 67 2.1.2 Filter-Rule AVP 68 2.2 Legacy RADIUS Attributes 69 2.2.1 NAS-IP-Address AVP 70 2.2.2 NAS-Identifier AVP 71 2.2.3 State AVP 72 2.2.4 Class AVP 73 3.0 Legacy RADIUS Authentication Support 74 3.1 Command-Codes Values 75 3.1.1 AA-Request (AAR) Command 76 3.1.1.1 User-Password AVP 77 3.1.1.2 CHAP-Password AVP 78 3.1.1.3 CHAP-Challenge AVP 79 3.1.1.4 ARAP-Password AVP 80 3.1.2 AA-Answer (AAA) Command 81 3.1.2.1 ARAP-Challenge-Response AVP 82 3.1.2.2 Password-Retry AVP 83 3.1.3 AA-Challenge-Ind (ACI) Command 84 3.1.3.1 Prompt AVP 85 3.2 Reply-Message AVP 86 4.0 Extensible Authentication Protocol Support 87 4.1 Alternative Uses 88 4.2 Command-Codes Values 89 4.2.1 Diameter-EAP-Request (DER) Command 90 4.2.2 Diameter-EAP-Answer (DEA) Command 91 4.2.3 Diameter-EAP-Ind (DEI) Command 92 4.3 EAP-Payload AVP 93 5.0 Diameter Session Termination 94 6.0 Call and Session Information 95 6.1 NAS-Port AVP 96 6.2 Filter-Id AVP 97 6.3 Callback-Number AVP 98 6.4 Callback-Id AVP 99 6.5 Idle-Timeout AVP 100 6.6 Called-Station-Id AVP 101 6.7 Calling-Station-Id AVP 102 6.8 NAS-Port-Type AVP 103 6.9 Port-Limit AVP 104 6.10 Connect-Info AVP 105 7.0 Service Specific Authorization AVPs 106 7.1 Service-Type AVP 107 7.2 Framed Access Authorization AVPs 108 7.2.1 Framed-Protocol AVP 109 7.2.2 Framed-Routing AVP 110 7.2.3 Framed-MTU AVP 111 7.2.4 Framed-Compression AVP 112 7.2.5 IP Access 113 7.2.5.1 Framed-IP-Address AVP 114 7.2.5.2 Framed-IP-Netmask AVP 115 7.2.5.3 Framed-IP-Route AVP 116 7.2.6 IPX Access 117 7.2.6.1 Framed-IPX-Network AVP 118 7.2.7 Appletalk Access 119 7.2.7.1 Framed-AppleTalk-Link AVP 120 7.2.7.2 Framed-AppleTalk-Network AVP 121 7.2.7.3 Framed-AppleTalk-Zone AVP 122 7.2.8 ARAP Access 123 7.2.8.1 ARAP-Features AVP 124 7.2.8.2 ARAP-Zone-Access AVP 125 7.2.8.3 ARAP-Security AVP 126 7.2.8.4 ARAP-Security-Data AVP 127 7.3 Non-Framed Access Authorization AVPs 128 7.3.1 Login-IP-Host AVP 129 7.3.2 Login-Service AVP 130 7.3.3 TCP Services 131 7.3.3.1 Login-TCP-Port AVP 132 7.3.4 LAT Services 133 7.3.4.1 Login-LAT-Service AVP 134 7.3.4.2 Login-LAT-Node AVP 135 7.3.4.3 Login-LAT-Group AVP 136 7.3.4.4 Login-LAT-Port AVP 137 7.4 Tunneling AVP 138 7.4.1 Tunnel-Type AVP 139 7.4.2 Tunnel-Medium-Type AVP 140 7.4.3 Tunnel-Client-Endpoint AVP 141 7.4.4 Tunnel-Server-Endpoint AVP 142 7.4.5 Tunnel-Password AVP 143 7.4.6 Tunnel-Private-Group-ID AVP 144 7.4.7 Tunnel-Assignment-ID AVP 145 7.4.8 Tunnel-Preference AVP 146 7.4.9 Tunnel-Client-Auth-ID AVP 147 7.4.10 Tunnel-Server-Auth-ID AVP 148 8.0 Accounting Considerations 149 8.1 Accounting-Input-Octets AVP 150 8.2 Accounting-Output-Octets AVP 151 8.3 Accounting-Session-Time AVP 152 8.4 Accounting-Input-Packets AVP 153 8.5 Accounting-Output-Packets AVP 154 8.6 Accounting-Authentication-Type AVP 155 8.7 Acct-Tunnel-Connection AVP 156 8.8 Acct-Tunnel-Packets-Lost AVP 157 9.0 Interactions with Resource Management 158 10.0 RADIUS/Diameter Protocol Interactions 159 10.1 RADIUS request forwarded as Diameter request 160 10.2 Diameter request forwarded as RADIUS request 161 11.0 AVP Occurrence Table 162 11.1 NASREQ Command AVP Table 163 11.2 Accounting AVP Table 164 11.2.1 Framed Access 165 11.2.2 Non-Framed Access 166 12.0 IANA Considerations 167 12.1 Command Codes 168 12.2 AVP Codes 169 12.3 Request-Type AVP Values 170 12.4 Extension Identifier 171 13.0 Security Considerations 172 14.0 References 173 15.0 Acknowledgements 174 16.0 Authors' Addresses 175 17.0 Full Copyright Statement 176 18.0 Expiration Date 178 1.0 Introduction 180 This document describes the Diameter extension that is used for AAA 181 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 182 extension, combined with the base protocol [2], satisfies the 183 requirements defined in the NASREQ AAA criteria specification [24] 184 and the ROAMOPS AAA Criteria specification [4]. 186 This document is divided into three main sections. The first section 187 defines the Diameter Command-Codes and AVPs that are needed to 188 support legacy authentication protocols, those that are typically 189 supported by RADIUS [1] servers. The second section defines the 190 Command-Codes and AVPs necessary for a Diameter node to support PPP's 191 Extensible Authentication Protocol (EAP) [25]. The third section 192 contains the Authorization AVPs that are needed for the various 193 services offered by a NAS, such as PPP dial-in, terminal server and 194 tunneling applications, such as L2TP [16]. 196 Given that it is expected that initial deployments of the Diameter 197 protocol in a dial-up environment will include legacy systems, this 198 extension was carefully designed to ease the burden of servers that 199 must perform protocol conversion between RADIUS and Diameter. This 200 is achieved by re-using the RADIUS address space, eliminating the 201 need to perform attribute lookups. 203 The value assigned for the Extension-Id [2] AVP is one (1). 205 1.1 Requirements language 207 In this document, the key words "MAY", "MUST", "MUST NOT", 208 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 209 interpreted as described in [12]. 211 1.2 Advertising extension support 213 Diameter nodes conforming to this specification MAY advertise support 214 by including the value of one (1) in either the Device-Reboot-Ind 215 Command's [2] Auth-Extension-Id or Acct-Extension-Id AVPs. 217 2.0 Supported AVPs 219 This section lists all of the Diameter AVPs and the legacy RADIUS 220 attributes supported by this extension. 222 2.1 Diameter AVPs 224 This section will define all of the AVPs that are not backward 225 compatible with the RADIUS protocol [1]. A Diameter message that 226 includes one of these AVPs MAY cause interoperability issues should 227 the request traverse a AAA node that only supports the RADIUS 228 protocol. However, the Diameter protocol SHOULD NOT be hampered from 229 future developments due to the existing installed base. 231 The following table describes the Diameter AVPs defined in the NASREQ 232 extension, their AVP Code values, types, possible flag values and 233 whether the AVP MAY be encrypted. 235 +---------------------+ 236 | AVP Flag rules | 237 |----+-----+----+-----|----+ 238 AVP Section | | |SHLD| MUST|MAY | 239 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 240 -----------------------------------------|----+-----+----+-----|----| 241 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 242 Filter-Rule 400 2.1.2 OctetString| M | P | | V | Y | 243 Request-Type 401 2.1.1 Unsigned32 | M | P | | V | N | 244 Tunneling 403 7.4 Grouped | M | P | | V | N | 246 2.1.1 Request-Type AVP 248 The Request-Type AVP (AVP Code 401) is of type Unsigned32 and is used 249 to determine the type of request being transmitted. Note that a 250 request with this AVP set to a value other than 251 AUTHORIZE_AUTHENTICATE MAY break backward RADIUS compatibility. The 252 following values are defined: 254 AUTHENTICATE_ONLY 1 255 The request being sent is for authentication only, and MUST 256 contain the relevant authentication AVPs that are needed by the 257 Diameter server to authenticate the user. 259 AUTHORIZE_ONLY 2 260 The request being sent is for authorization only, and MUST 261 contain the authorization AVPs that are necessary to identify 262 the service being requested/offered. 264 AUTHORIZE_AUTHENTICATE 3 265 The request contains a request for both authentication and 266 authorization. The request MUST include both the relevant 267 authentication information, and authorization information 268 necessary to identify the service being requested/offered. 270 2.1.2 Filter-Rule AVP 272 The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in 273 the UTF-8 [29] format, and provides filter rules that need to be 274 configured on the NAS for the user. One or more such AVPs MAY be 275 present in an authorization response. 277 Each packet can be filtered based on the following information that 278 is associated with it: 280 Direction (in or out) 281 Source and destination IP address (possibly masked) 282 Protocol 283 Source and destination port (lists or ranges) 284 TCP flags 285 IP fragment flag 286 IP options 287 ICMP types 289 Rules for the appropriate direction are evaluated in order, with the 290 first matched rule terminating the evaluation. Each packet is 291 evaluated once. If no rule matches, the packet is dropped if the last 292 rule evaluated was a permit, and passed if the last rule was a deny. 294 The filters in the Filter-Rule AVP MUST follow the format: 296 action dir proto from src to dst [options] 298 action permit - Allow packets that match the rule. 299 deny - Drop packets that match the rule. 301 dir "in" is from the terminal, "out" is to the terminal. 303 proto An IP protocol specified by number. The "ip" keyword 304 means any protocol will match. 306 src and dst
[ports] 308 The
may be specified as: 309 ipno An IPv4 or IPv6 number in dotted-quad or 310 canonical IPv6 form. Only this exact IP 311 number will match the rule. 312 ipno/bits An IP number as above with a mask width of 313 the form 1.2.3.4/24. In this case all IP 314 numbers from 1.2.3.0 to 1.2.3.255 will 315 match. The bit width MUST be valid for 316 the IP version and the IP number MUST NOT 317 have bits set beyond the mask. 319 The sense of the match can be inverted by preceding 320 an address with the not modifier, causing all other 321 addresses to be matched instead. This does not 322 affect the selection of port numbers. 324 The keyword "any" is 0.0.0.0/0 or the IPv6 325 equivalent. The keyword "assigned" is the address 326 or set of addresses assigned to the terminal. The 327 first rule SHOULD be "deny in ip !assigned". 329 With the TCP and UDP protocols, optional ports may be 330 specified as: 332 {port|port-port}[,port[,...]] 334 The `-' notation specifies a range of ports 335 (including boundaries). 337 Fragmented packets which have a non-zero offset (i.e. 338 not the first fragment) will never match a rule which 339 has one or more port specifications. See the frag 340 option for details on matching fragmented packets. 342 options: 343 frag Match if the packet is a fragment and this is not the 344 first fragment of the datagram. frag may not be used 345 in conjunction with either tcpflags or TCP/UDP port 346 specifications. 348 ipoptions spec 349 Match if the IP header contains the comma separated 350 list of options specified in spec. The supported IP 351 options are: 353 ssrr (strict source route), lsrr (loose source route), 354 rr (record packet route) and ts (timestamp). The 355 absence of a particular option may be denoted with a 356 `!'. 358 tcpoptions spec 359 Match if the TCP header contains the comma separated 360 list of options specified in spec. The supported TCP 361 options are: 363 mss (maximum segment size), window (tcp window 364 advertisement), sack (selective ack), ts (rfc1323 365 timestamp) and cc (rfc1644 t/tcp connection count). 366 The absence of a particular option may be denoted with 367 a `!'. 369 established 370 TCP packets only. Match packets that have the RST or 371 ACK bits set. 373 setup TCP packets only. Match packets that have the SYN bit 374 set but no ACK bit. 376 tcpflags spec 377 TCP packets only. Match if the TCP header contains the 378 comma separated list of flags specified in spec. The 379 supported TCP flags are: 381 fin, syn, rst, psh, ack and urg. The absence of a 382 particular flag may be denoted with a `!'. A rule which 383 contains a tcpflags specification can never match a 384 fragmented packet which has a non-zero offset. See the 385 frag option for details on matching fragmented packets. 387 icmptypes types 388 ICMP packets only. Match if the ICMP type is in the 389 list types. The list may be specified as any 390 combination of ranges or individual types separated by 391 commas. The supported ICMP types are: 393 echo reply (0), destination unreachable (3), source 394 quench (4), redirect (5), echo request (8), router 395 advertisement (9), router solicitation (10), time-to- 396 live exceeded (11), IP header bad (12), timestamp 397 request (13), timestamp reply (14), information request 398 (15), information reply (16), address mask request (17) 399 and address mask reply (18). 401 There is one kind of packet that the NAS MUST always discard, that is 402 an IP fragment with a fragment offset of one. This is a valid 403 packet, but it only has one use, to try to circumvent firewalls. 405 A NAS that is unable to interpret or apply a deny rule MUST 406 terminate the session. A NAS that is unable to interpret or apply 407 a permit rule MAY apply a more restrictive rule. A NAS MAY apply 408 deny rules of its own before the supplied rules, for example to 409 protect the NAS owner's infrastructure. 411 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 412 ipfw.c code may provide a useful base for implementations. 414 2.2 Legacy RADIUS Attributes 416 The Diameter protocol reserves the first 255 AVP identifiers for 417 "legacy RADIUS" support. The following table contains the RADIUS 418 attributes supported by this Diameter extension, their AVP code 419 values, types, possible flag values and whether the AVP MAY be 420 encrypted. RADIUS attributes not listed are not supported by the 421 Diameter protocol. 423 +---------------------+ 424 | AVP Flag rules | 425 |----+-----+----+-----|----+ 426 AVP Section | | |SHLD| MUST|MAY | 427 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 428 -----------------------------------------|----+-----+----+-----|----| 429 Accounting- 45 8.6 Unsigned32 | | P | | V | Y | 430 Authentication-Type | | | | | | 431 Accounting-Input- 42 8.1 Unsigned32 | | P | | V | Y | 432 Octets | | | | | | 433 Accounting-Input- 47 8.4 Unsigned32 | | P | | V | Y | 434 Packets | | | | | | 435 Accounting- 43 8.2 Unsigned32 | | P | | V | Y | 436 Output-Octets | | | | | | 437 Accounting- 48 8.5 Unsigned32 | | P | | V | Y | 438 Output-Packets | | | | | | 439 Accounting- 46 8.3 Unsigned32 | | P | | V | Y | 440 Session-Time | | | | | | 441 Acct-Tunnel- 68 8.7 OctetString| | P | | V | Y | 442 Connection | | | | | | 443 Acct-Tunnel- 86 8.8 OctetString| | P | | V | Y | 444 Packets-Lost | | | | | | 445 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 446 Response | | | | | | 447 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 448 ARAP-Password 70 3.1.1.4 OctetString| M | P | | V | Y | 449 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 450 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 451 Data | | | | | | 452 ARAP-Zone-Access 72 7.2.8.2 Unsigned32 | M | P | | V | Y | 453 Callback-Id 20 6.4 OctetString| M | P | | V | Y | 454 Callback-Number 19 6.3 OctetString| M | P | | V | Y | 455 Called-Station-Id 30 6.6 OctetString| M | P | | V | Y | 456 Calling-Station- 31 6.7 OctetString| M | P | | V | Y | 457 Id | | | | | | 458 CHAP-Challenge 60 3.1.1.3 OctetString| M | P | | V | Y | 459 CHAP-Password 3 3.1.1.2 OctetString| M | P | | V | Y | 460 Class 25 2.2.4 OctetString| M | P | | V | Y | 461 Connect-Info 77 6.10 OctetString| | P | | V | Y | 462 Filter-Id 11 6.2 OctetString| M | P | | V | Y | 463 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 464 Link | | | | | | 465 +---------------------+ 466 | AVP Flag rules | 467 |----+-----+----+-----|----+ 468 AVP Section | | |SHLD| MUST|MAY | 469 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 470 -----------------------------------------|----+-----+----+-----|----| 471 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 472 Network | | | | | | 473 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 474 Zone | | | | | | 475 Framed-Protocol 7 7.2.1 Unsigned32 | M | P | | V | Y | 476 Framed-IP-Address 8 7.2.5.1 Address | M | P | | V | Y | 477 Framed- 13 7.2.4 Unsigned32 | M | P | | V | Y | 478 Compression | | | | | | 479 Framed-IP-Netmask 9 7.2.5.2 Address | M | P | | V | Y | 480 Framed-IP-Route 22 7.2.5.3 OctetString| M | P | | V | Y | 481 Framed-IPX- 23 7.2.6.1 OctetString| M | P | | V | Y | 482 Network | | | | | | 483 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 484 Framed-Routing 10 7.2.2 Unsigned32 | M | P | | V | Y | 485 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 486 Login-IP-Host 14 7.3.1 Address | M | P | | V | Y | 487 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 488 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 489 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 490 Login-LAT-Service 34 7.3.4.1 Unsigned32 | M | P | | V | Y | 491 Login-Service 15 7.3.2 Unsigned32 | M | P | | V | Y | 492 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 493 NAS-Identifier 32 2.2.2 OctetString| M | P | | V | Y | 494 NAS-IP-Address 4 2.2.1 Address | M | P | | V | Y | 495 NAS-Port 5 6.1.1 Unsigned32 | M | P | | V | Y | 496 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 497 Password-Retry 75 3.1.2.2 Unsigned32 | | P | | V | Y | 498 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 499 Prompt 76 3.1.3.1 Unsigned32 | | P | | V | Y | 500 Reply-Message 18 3.2 OctetString| M | P | | V | Y | 501 Service-Type 6 7.1 Unsigned32 | M | P | | V | Y | 502 State 24 2.2.3 OctetString| M | P | | V | Y | 503 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 504 Assignment-Id | | | | | | 505 Tunnel-Client- 90 7.4.9 OctetString| M | P | | V | Y | 506 Auth-ID | | | | | | 507 Tunnel-Client- 66 7.4.3 OctetString| M | P | | V | Y | 508 Endpoint | | | | | | 509 Tunnel-Medium- 65 7.4.2 Unsigned32 | M | P | | V | Y | 510 Type | | | | | | 511 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 512 +---------------------+ 513 | AVP Flag rules | 514 |----+-----+----+-----|----+ 515 AVP Section | | |SHLD| MUST|MAY | 516 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 517 -----------------------------------------|----+-----+----+-----|----| 518 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 519 Tunnel-Private- 81 7.4.6 OctetString| M | P | | V | Y | 520 Group-ID | | | | | | 521 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 522 Auth-ID | | | | | | 523 Tunnel-Server- 67 7.4.4 OctetString| M | P | | V | Y | 524 Endpoint | | | | | | 525 Tunnel-Type 64 7.4.1 Unsigned32 | M | P | | V | Y | 526 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 528 The AVPs defined in this section SHOULD only used when a 529 Diameter/RADIUS gateway function is invoked, and are not used in the 530 Diameter protocol. 532 2.2.1 NAS-IP-Address AVP 534 The NAS-IP-Address AVP (AVP Code 4) [1] is of type Address, and 535 contains the IP Address of the NAS providing service to the user. 536 When this AVP is present, the Origin-FQDN AVP DOES NOT represent the 537 NAS providing service to the user. Note that this AVP SHOULD only 538 added by a RADIUS/Diameter protocol gateway (see Section 10.0). 540 2.2.2 NAS-Identifier AVP 542 The NAS-Identifier AVP (AVP Code 32) [1] is of type OctetString, 543 encoded in the UTF-8 [29] format, and contains the Identity of the 544 NAS providing service to the user. When this AVP is present, the 545 Origin-FQDN AVP DOES NOT represent the NAS providing service to the 546 user. Note that this AVP SHOULD only added by a RADIUS/Diameter 547 protocol gateway (see Section 10.0). 549 2.2.3 State AVP 551 The State AVP (AVP Code 24) is of type OctetString and is used to 552 transmit the contents of the RADIUS State attribute, and no 553 interpretation of the contents should be made. Note that this AVP 554 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 555 10.0). 557 2.2.4 Class AVP 559 The Class AVP (AVP Code 25) is of type OctetString and is used to 560 transmit the contents of the RADIUS Class attribute, and no 561 interpretation of the contents should be made. Note that this AVP 562 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 563 10.0). 565 3.0 Legacy RADIUS Authentication Support 567 This section defines the new Command-Code [2] values required to 568 support the legacy authentication protocols (i.e. PAP, CHAP), as well 569 as the AVPs that are necessary to carry the authentication 570 information in the Diameter protocol. The functionality defined here 571 provides a RADIUS-like AAA service, over a more reliable and secure 572 transport, as defined in the base protocol [2]. 574 Unlike the RADIUS protocol [1], the Diameter protocol does not 575 require authentication information to be contained in a request from 576 the client. Therefore, it is possible to send a request for 577 authorization only. The type of service depends upon the Request-Type 578 AVP. This difference MAY cause operational issues in environments 579 that need RADIUS interoperability, and it MAY be necessary that 580 protocol conversion gateways add some authentication information when 581 transmitting to a RADIUS server. 583 The Diameter protocol allows for users to be periodically re- 584 authenticated and/or re-authorized. In such instances, the Session-Id 585 AVP in the AAR message MUST be the same as the one present in the 586 original authentication/authorization message. A Diameter server 587 informs the NAS of the authorized session lifetime via the Session- 588 Timeout AVP [1]. 590 A NAS MUST re-authenticate and/or authorize after the period provided 591 by the server. Furthermore, it is possible for Diameter servers to 592 issue an unsolicited re-authentication and/or re-authorization by 593 issuing an AA-Challenge-Ind message to the NAS. Upon receipt of such 594 a message, the NAS is instructed to issue a request to re- 595 authenticate and/or re-authorize the client. 597 3.1 Command-Codes Values 599 This section defines new Command-Code [2] values that MUST be 600 supported by all Diameter implementations that conform to this 601 specification. The following Command Codes are defined in this 602 section: 604 Command-Name Abbrev. Code Reference 605 -------------------------------------------------------- 606 AA-Answer AAA 266 3.1.2 607 AA-Challenge-Ind ACI 267 3.1.3 608 AA-Request AAR 265 3.1.1 610 3.1.1 AA-Request (AAR) Command 612 The AA-Request message (AAR), indicated by the Command-Code field set 613 to 265, is used in order to request authentication and/or 614 authorization for a given PPP user. The type of request is identified 615 through the Request-Type AVP, and the default mode is both 616 authentication and authorization. 618 If Authentication is requested the User-Name attribute SHOULD be 619 present, as well as any additional authentication AVPs that would 620 carry the password information. A request for authorization only 621 SHOULD include the information from which the authorization will be 622 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 623 networks MAY use different AVPs for authorization purposes. A request 624 for authorization will include some AVPs defined in sections 2.0, 6.0 625 and 7.0. 627 It is possible for a single session to be authorized only first, then 628 followed by an authentication request. However, the inverse SHOULD 629 NOT be permitted. 631 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 632 MUST be identical as the one provided in the initial AA-Request for 633 the same session. If the AA-Request is a result of an AA-Challenge- 634 Ind that included a State AVP, the same AVP MUST be present in the 635 following AA-Request. 637 Message Format 638 ::= < Diameter Header: 265 > 639 < Session-Id > 640 { Auth-Extension-Id } 641 { Origin-FQDN } 642 { Origin-Realm } 643 { Destination-Realm } 644 { Service-Type } 645 [ Destination-FQDN ] 646 [ NAS-Identifier ] 647 [ User-Name ] 648 [ User-Password ] 649 [ ARAP-Password ] 650 [ CHAP-Password ] 651 [ CHAP-Challenge ] 652 [ Idle-Timeout ] 653 [ State ] 654 * [ AVP ] 655 * [ Proxy-Info ] 656 * [ Route-Record ] 658 3.1.1.1 User-Password AVP 660 The User-Password AVP (AVP Code 2) is of type OctetString and 661 contains the password of the user to be authenticated, or the user's 662 input following an AA-Challenge-Ind. 664 This AVP MUST be encrypted using one of the methods described in [2] 665 or [13]. Unless this AVP is used for one-time passwords, the User- 666 Password AVP SHOULD NOT be used in non-trusted proxy environments. 668 The clear-text password (prior to encryption) MUST NOT be longer than 669 128 bytes in length. 671 3.1.1.2 CHAP-Password AVP 673 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 674 the response value provided by a PPP Challenge-Handshake 675 Authentication Protocol (CHAP) [6] user in response to the challenge. 677 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 678 AVP (see section 3.1.1.3) MUST be present as well. 680 0 1 2 3 681 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 AVP Header (AVP Code = 3) 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | CHAP Ident | Data ... 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 The CHAP Ident field contains the one octet CHAP Identifier from the 689 user's CHAP response [6]. The Data field is 16 octets, and contains 690 the CHAP Response from the user. The actual computation of the CHAP 691 response can be found in [6]. 693 3.1.1.3 CHAP-Challenge AVP 695 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 696 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 697 Handshake Authentication Protocol (CHAP) [6] user. 699 3.1.1.4 ARAP-Password AVP 701 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 702 only present when the Framed-Protocol AVP (see Section 7.2.1) is 703 included in the message and is set to ARAP. This AVP MUST NOT be 704 present if the User-Password or CHAP-Password AVPs are present. See 705 [32] for more information on the contents of this AVP. 707 3.1.2 AA-Answer (AAA) Command 709 The AA-Answer (AAA) message, indicated by the Command-Code field set 710 to 266, is sent in response to the AA-Request message. If 711 authorization was requested, a successful response will include the 712 authorization AVPs appropriate for the service being provided, as 713 defined in section 2.0, 6.0 and 7.0 715 Message Format 716 ::= < Diameter Header: 266 > 717 < Session-Id > 718 { Auth-Extension-Id } 719 { Result-Code } 720 { Origin-FQDN } 721 { Origin-Realm } 722 { Service-Type } 723 { Destination-FQDN } 724 [ User-Name ] 725 [ Error-Reporting-FQDN ] 726 [ Idle-Timeout ] 727 * [ AVP ] 728 * [ Proxy-Info ] 729 * [ Route-Record ] 731 3.1.2.1 ARAP-Challenge-Response AVP 733 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 734 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 735 is included in the message and is set to ARAP. This AVP contains an 8 736 octet response to the dial-in client's challenge. The RADIUS server 737 calculates this value by taking the dial-in client's challenge from 738 the high order 8 octets of the ARAP-Password AVP and performing DES 739 encryption on this value with the authenticating user's password as 740 the key. If the user's password is less than 8 octets in length, the 741 password is padded at the end with NULL octets to a length of 8 742 before using it as a key. 744 3.1.2.2 Password-Retry AVP 746 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 747 included in the AA-Answer if the Result-Code indicates an 748 authentication failure. The value of this AVP indicates how many 749 authentication attempts a user may be permitted before being 750 disconnected. This AVP is primarily intended for use when the 751 Framed-Protocol AVP (see Section 7.2.1) is set to ARAP. 753 3.1.3 AA-Challenge-Ind (ACI) Command 755 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 756 field set to 267, is sent by a Diameter Home server to issue a 757 challenge requiring a response to a dial-up user. The message MAY 758 have one or more Reply-Message AVP, the User-Name AVP and it MAY have 759 zero or one State AVP. No other AVPs are permitted in an AA- 760 Challenge-Ind other than security related AVPs [2, 13]. 762 On receipt of an AA-Challenge-Ind, the Identifier field is matched 763 with a pending AA-Request. Invalid messages are silently discarded. 765 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 766 Request SHOULD be sent. The NAS MAY display the text message, if any, 767 to the user, and then prompt the user for a response. It then sends 768 its original AA-Request with a new request ID, with the User-Password 769 AVP replaced by the user's response (encrypted), and including the 770 State AVP from the AA-Challenge-Ind, if any. 772 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 773 client and accept a PAP response which it can use as though the user 774 had entered the response. If the NAS cannot do so, it should treat 775 the AA-Challenge-Ind as though it had received an AA-Answer with a 776 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 778 When possible, authentication mechanisms that include more than a 779 single authentication round trip SHOULD use EAP (see section 4.0) 780 instead of the AA-Challenge-Ind. This command has been maintained for 781 RADIUS backward compatibility. 783 AA-Challenge-Ind ::= < Diameter Header: 267 > 784 < Session-Id > 785 { Auth-Extension-Id } 786 { Result-Code } 787 { Destination-Realm } 788 { Destination-FQDN } 789 { Origin-FQDN } 790 { Origin-Realm } 791 { Service-Type } 792 [ User-Name ] 793 [ Error-Reporting-FQDN ] 794 [ State ] 795 * [ AVP ] 796 * [ Reply-Message ] 797 * [ Proxy-Info ] 798 * [ Route-Record ] 800 3.1.3.1 Prompt AVP 802 The Prompt AVP (AVP Code 76) is of type Unsigned32, and MAY be 803 present in the AA-Challenge-Ind message. When present, it is used by 804 the NAS to determine whether the user's response, when entered, 805 should be echoed. 807 The supported values are listed in [34]. 809 3.2 Reply-Message AVP 811 The Reply-Message AVP (AVP Code 18) is of type OctetString, encoded 812 in the UTF-8 [29] format, and contains text which MAY be displayed to 813 the user. When used in an AA-Answer message with a successful 814 Result-Code AVP it indicates the success message. When found in the 815 same message with a Result-Code other than Diameter-SUCCESS it 816 contains the failure message. 818 The Reply-Message AVP MAY indicate a dialog message to prompt the 819 user before another AA-Request attempt. When used in an AA- 820 Challenge-Ind, it MAY indicate a dialog message to prompt the user 821 for a response. 823 Multiple Reply-Message's MAY be included and if any are displayed, 824 they MUST be displayed in the same order as they appear in the 825 message. 827 4.0 Extensible Authentication Protocol Support 829 The Extensible Authentication Protocol (EAP), described in [25], 830 provides a standard mechanism for support of additional 831 authentication methods within PPP. Through the use of EAP, support 832 for a number of authentication schemes may be added, including smart 833 and token cards, Kerberos, Public Key, One Time Passwords, and 834 others. 836 This section describes the Command-Codes values and AVPs that are 837 required for an EAP payload to be encapsulated within the Diameter 838 protocol. Since authentication occurs between the PPP client and its 839 home Diameter server, end-to-end authentication is achieved, reducing 840 the possibility for fraudulent authentication, such as replay and 841 man-in-the-middle attacks. End-to-end authentication also provides 842 for mutual (bi-directional) authentication, which is not possible 843 with PAP and CHAP in a roaming environment. 845 The Diameter/EAP extension allows a home Diameter server to initiate 846 an unsolicited authentication request to the user. This allows the 847 home server to periodically ensure that the user is still active, 848 which is useful when a server requires re-authentication to extend 849 the "life" of a session [26]. Server-initiated authentication can 850 reduce the number of protocol exchanges over the Internet. 852 The EAP conversation between the authenticating peer and the NAS 853 begins with the negotiation of EAP within LCP. Once EAP has been 854 negotiated, the NAS will typically send to the Diameter server a 855 Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying 856 an EAP-Start. The Port number and NAS Identifier MUST be included in 857 the AVPs issued by the NAS in the Diameter-EAP-Request packet. 859 If the Diameter home server supports EAP, it MUST respond with a 860 Diameter-EAP-Ind message containing an EAP-Payload AVP that includes 861 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 862 NAS to the PPP client. The initial Diameter-EAP-Ind normally includes 863 an EAP-Request/Identity, requesting the PPP client to identify 864 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 865 will then issue a second Diameter-EAP-Request message, with the 866 client's EAP payload encapsulated within the EAP-Payload AVP. The 867 conversation continues until the Diameter server sends a Diameter- 868 EAP-Answer with a Result-Code AVP indicating success or failure. A 869 Result-Code AVP containing a failure indication SHOULD also include 870 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 871 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 872 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 873 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 874 successfully terminate the PPP authentication phase. If authorization 875 was requested, a successful Diameter-EAP-Answer MUST also include the 876 appropriate authorization AVPs required for the service requested 877 (see sections 2.0, 6.0 and 7.0). 879 The above scenario creates a situation in which the NAS never needs 880 to manipulate an EAP packet. An alternative may be used in situations 881 where an EAP-Request/Identity message will always be sent by the NAS 882 to the authenticating peer. This involves having the NAS send an 883 EAP-Request/Identity message to the PPP client, and forwarding the 884 EAP-Response/Identity packet to the Diameter server in the EAP- 885 Payload AVP of a Diameter-EAP-Request packet. While this approach 886 will save a round-trip, it cannot be universally employed. There are 887 circumstances in which the user's identity may not be needed (such as 888 when authentication and accounting is handled based on the calling or 889 called phone number), and therefore an EAP-Request/Identity packet 890 may not necessarily be issued by the NAS to the authenticating peer. 892 Unless the NAS interprets the EAP-Response/Identity packet returned 893 by the authenticating peer, it will not have access to the user's 894 identity. Therefore, the Diameter Server SHOULD return the user's 895 identity by inserting it in the User-Name attribute of subsequent 896 Diameter-EAP-Answer packets. Without the user's identity, the 897 Session-Id AVP MAY be used for accounting and billing, however 898 operationally this MAY be very difficult to manage. 900 The Diameter-EAP-Ind message MAY be sent by a Diameter server in 901 order to initiate an unsolicited authentication of the PPP user, as 902 described in [26]. This functionality allows a home Diameter server 903 to easily extend the "life" of a session for a particular service, 904 while reducing the total number of authentication round-trips, should 905 the NAS initiate the periodic authentication. 907 Should an EAP authentication session be interrupted due to a home 908 server failure, the session MAY be directed to an alternate server, 909 but the authentication session will have to be restarted from the 910 beginning. 912 When Diameter is used in a roaming environment, the NAS SHOULD issue 913 the EAP-Request/Identity request to the PPP client, and forward the 914 EAP-Response in the initial Diameter-EAP-Request message. This allows 915 any Diameter proxies or brokers to identify the user, and forward the 916 message to the appropriate home server. If a response is received 917 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 918 an indication that a Diameter server in the proxy chain does not 919 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 920 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 921 cautious when determining whether a less secure authentication 922 protocol will be used, since this could be a result of a bidding down 923 attack. 925 4.1 Alternative uses 927 Currently the conversation between the backend authentication server 928 and the Diameter server is proprietary because of lack of 929 standardization. In order to increase standardization and provide 930 interoperability between Diameter vendors and backend security 931 vendors, it is recommended that Diameter-encapsulated EAP be used for 932 this conversation. 934 This has the advantage of allowing the Diameter server to support EAP 935 without the need for authentication-specific code within the Diameter 936 server. Authentication-specific code can then reside on a backend 937 authentication server instead. 939 In the case where Diameter-encapsulated EAP is used in a conversation 940 between a Diameter server and a backend authentication server, the 941 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 942 Success message without inclusion of the expected authorization AVPs 943 required in a successful response. This means that the Diameter 944 server MUST add these attributes prior to sending an Diameter-EAP- 945 Answer/EAP-Payload/EAP-Success message to the NAS. 947 4.2 Command-Codes Values 949 This section defines new Command-Code [2] values that MUST be 950 supported by all Diameter implementations conforming to this 951 specification. The following Command Codes are defined in this 952 section: 954 Command-Name Abbrev. Code Reference 955 -------------------------------------------------------- 956 Diameter-EAP-Answer DEA 269 4.2.2 957 Diameter-EAP-Ind DEI 270 4.2.3 958 Diameter-EAP-Request DER 268 4.2.1 960 4.2.1 Diameter-EAP-Request (DER) Command 962 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 963 field set to 268, is sent by a Diameter client to a Diameter server 964 and conveys an EAP-Response [25] from the dial-up PPP client. The 965 Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains 966 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent 967 to the Diameter server to initiate an EAP authentication session. 969 Upon receipt of a Diameter-EAP-Request, a Diameter server MUST issue 970 a reply. The reply may be either: 972 1) a Diameter-EAP-Ind containing an EAP-Request encapsulated 973 within an EAP-Payload attribute 974 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 975 within an EAP-Payload and a Result-Code indicating success. 976 3) a Diameter-EAP-Answer containing an EAP-Failure encapsulated 977 within an EAP-Payload and a Result-Code indicating failure. 978 4) A Message-Reject-Ind packet with a Result-Code set to 979 DIAMETER_COMMAND_UNSUPPORTED if a Diameter server does not 980 support the EAP extension. 982 Message Format 983 ::= < Diameter Header: 268 > 984 < Session-Id > 985 { Auth-Extension-Id } 986 { Origin-FQDN } 987 { Origin-Realm } 988 { Destination-Realm } 989 { Service-Type } 990 { EAP-Payload } 991 [ Destination-FQDN ] 992 [ User-Name ] 993 [ Idle-Timeout ] 994 [ NAS-IP-Address ] 995 [ NAS-Identifier ] 996 [ State ] 997 * [ AVP ] 998 * [ Proxy-Info ] 999 * [ Route-Record ] 1001 4.2.2 Diameter-EAP-Answer (DEA) Command 1003 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 1004 field set to 269, is sent by the Diameter server to the client to 1005 indicate either a successful or failed authentication. The Diameter- 1006 EAP-Answer message SHOULD include an EAP payload of type EAP-Success 1007 or EAP-Failure encapsulated within an EAP-Payload AVP. The Result- 1008 Code AVP MUST indicate a failure if the EAP-Failure payload is 1009 present, while the AVP MUST indicate success if the EAP-Success 1010 payload is present. 1012 If the message from the Diameter client included a request for 1013 authorization, a successful response MUST include the authorization 1014 AVPs that are relevant to the service being provided. 1016 Message Format 1017 ::= < Diameter Header: 269 > 1018 < Session-Id > 1019 { Auth-Extension-Id } 1020 { Result-Code } 1021 { Origin-FQDN } 1022 { Origin-Realm } 1023 { Destination-FQDN } 1024 { Service-Type } 1025 [ Error-Reporting-FQDN ] 1026 [ EAP-Payload ] 1027 [ User-Name ] 1028 [ Idle-Timeout ] 1029 * [ AVP ] 1030 * [ Proxy-Info ] 1031 * [ Route-Record ] 1033 4.2.3 Diameter-EAP-Ind (DEI) Command 1035 The Diameter-EAP-Ind (DEI) command, indicated by the Command-Code set 1036 to 270, has two uses. This message MAY be sent in response to a 1037 Diameter-EAP-Request message, and MUST contain an EAP-Response 1038 payload [25] encapsulated within an EAP-Payload AVP. 1040 Alternatively, this message MAY also be sent unsolicited from a 1041 Diameter server to a client to request re-authentication of a PPP 1042 client. For re-authentication, it is recommended that the Identity 1043 request be skipped in order to reduce the number of authentication 1044 round trips. This is only possible when the user's identity is 1045 already known by the home Diameter server. 1047 Upon receipt of the message, the NAS MUST issue the EAP payload to 1048 the PPP Client, and SHOULD respond with a Diameter-EAP-Request 1049 containing the EAP-Response [25] packet. 1051 Message Format 1052 ::= 1053 < Session-Id > 1054 { Auth-Extension-Id } 1055 { Destination-FQDN } 1056 { Destination-Realm } 1057 { Origin-FQDN } 1058 { Origin-Realm } 1059 { EAP-Payload } 1060 { Service-Type } 1061 [ User-Name ] 1062 * [ AVP ] 1063 * [ Proxy-Info ] 1064 * [ Route-Record ] 1066 4.3 EAP-Payload AVP 1068 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1069 to encapsulate the actual EAP payload [25] that is being exchanged 1070 between the dial-up PPP client and the home Diameter server. 1072 5.0 Diameter Session Termination 1074 When a Network Access Server (NAS) receives an indication that a 1075 user's session is being disconnected (e.g. LCP Terminate is 1076 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1077 to its Diameter Server. This will ensure that any resources 1078 maintained on the servers is freed appropriately. 1080 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 1081 disconnect the PPP (or tunneling) session and respond with an STR 1082 message. 1084 6.0 Call and Session Information 1086 This section contains the authorization AVPs that are needed to 1087 identify call and session information, and allows the server to set 1088 constraints on a session. 1090 6.1 NAS-Port AVP 1092 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1093 physical port number of the NAS which is authenticating the user, and 1094 is normally only present in an authentication and/or authorization 1095 request. Note that this is using "port" in its sense of a physical 1096 connection on the NAS, not in the sense of a TCP or UDP port number. 1097 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1098 present in the request, if the NAS differentiates among its ports. 1100 6.2 Filter-Id AVP 1102 The Filter-Id AVP (AVP Code 11) is of type OctetString, encoded in 1103 the UTF-8 [29] format, and contains the name of the filter list for 1104 this user. Zero or more Filter-Id AVPs MAY be sent in an 1105 authorization response. 1107 Identifying a filter list by name allows the filter to be used on 1108 different NASes without regard to filter-list implementation details. 1109 However, this AVP is not roaming friendly since filter naming differs 1110 from one service provider to another. 1112 In non-RADIUS environments, it is strongly recommended that the 1113 Filter-Rule AVP be used instead. 1115 6.3 Callback-Number AVP 1117 The Callback-Number AVP (AVP Code 19) is of type OctetString, encoded 1118 in the UTF-8 [29] format, and contains a dialing string to be used 1119 for callback. It MAY be used in an authentication and/or 1120 authorization request as a hint to the server that a Callback service 1121 is desired, but the server is not required to honor the hint in the 1122 corresponding response. 1124 The codification of the range of allowed usage of this field is 1125 outside the scope of this specification. 1127 6.4 Callback-Id AVP 1129 The Callback-Id AVP (AVP Code 20) is of type OctetString, encoded in 1130 the UTF-8 [29] format, and contains the name of a place to be called, 1131 to be interpreted by the NAS. This AVP MAY be present in an 1132 authentication and/or authorization response. 1134 This AVP is not roaming friendly since it assumes that the Callback- 1135 Id is configured on the NAS. It is therefore preferable to use the 1136 Callback-Number AVP instead. 1138 6.5 Idle-Timeout AVP 1139 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1140 maximum number of consecutive seconds of idle connection allowed to 1141 the user before termination of the session or prompt. It MAY be used 1142 in an authentication and/or authorization request (or challenge) as a 1143 hint to the server that an idle timeout is desired, but the server is 1144 not required to honor the hint in the corresponding response. 1146 6.6 Called-Station-Id AVP 1148 The Called-Station-Id AVP (AVP Code 30) is of type OctetString, 1149 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1150 request the phone number that the user called, using Dialed Number 1151 Identification (DNIS) or a similar technology. Note that this may be 1152 different from the phone number the call comes in on. It SHOULD only 1153 be present in authentication and/or authorization requests. 1155 If the Request-Type AVP is set to authorization-only and the User- 1156 Name AVP is absent, the Diameter Server MAY perform authorization 1157 based on this field. This can be used by a NAS to request whether a 1158 call should be answered based on the DNIS. 1160 The codification of the range of allowed usage of this field is 1161 outside the scope of this specification. 1163 6.7 Calling-Station-Id AVP 1165 The Calling-Station-Id AVP (AVP Code 31) is of type OctetString, 1166 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1167 request the phone number that the call came from, using Automatic 1168 Number Identification (ANI) or a similar technology. It SHOULD only 1169 be present in authentication and/or authorization requests. 1171 If the Request-Type AVP is set to authorization-only and the User- 1172 Name AVP is absent, the Diameter Server MAY perform authorization 1173 based on this field. This can be used by a NAS to request whether a 1174 call should be answered based on the ANI. 1176 The codification of the range of allowed usage of this field is 1177 outside the scope of this specification. 1179 6.8 NAS-Port-Type AVP 1181 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1182 contains the type of the physical port of the NAS which is 1183 authenticating the user. It can be used instead of or in addition to 1184 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1185 and/or authorization requests. This AVP MAY be combined with the 1186 NAS-Port AVP to assist in differentiating its ports. 1188 The supported values are defined in [34]. 1190 6.9 Port-Limit AVP 1192 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1193 maximum number of ports to be provided to the user by the NAS. It 1194 MAY be used in an authentication and/or authorization request as a 1195 hint to the server that multilink PPP [9] service is desired, but the 1196 server is not required to honor the hint in the corresponding 1197 response. 1199 6.10 Connect-Info AVP 1201 The Connect-Info AVP (AVP Code 77) is of type OctetString and is sent 1202 in the AA-Request message, and indicates the nature of the user's 1203 connection. The value consists of UTF-8 encoded 10646 characters. 1204 The connection speed SHOULD be included at the beginning of the first 1205 Connect-Info AVP in the message. If the transmit and receive 1206 connection speeds differ, they may both be included in the first AVP 1207 with the transmit speed first (the speed the NAS modem transmits at), 1208 a slash (/), the receive speed, then optionally other information. 1210 7.0 Service Specific Authorization AVPs 1212 This section contains the RADIUS authorization AVPs that are 1213 supported in the Diameter protocol. The Service-Type AVP MUST be 1214 present in all messages, and based on the value of the Service-Type 1215 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1216 present. 1218 7.1 Service-Type AVP 1220 The Service-Type AVP (AVP Code 6) is of type Unsigned32 and contains 1221 the type of service the user has requested, or the type of service to 1222 be provided. One such AVP MAY be present in an authentication and/or 1223 authorization request or response. A NAS is not required to implement 1224 all of these service types, and MUST treat unknown or unsupported 1225 Service-Types as though a response with a Result-Code other than 1226 Diameter-SUCCESS had been received instead. 1228 When used in a request, the Service-Type AVP SHOULD be considered to 1229 be a hint to the server that the NAS has reason to believe the user 1230 would prefer the kind of service indicated, but the server is not 1231 required to honor the hint. The following values have been defined 1232 for the Service-Type AVP: 1234 The complete list of defined values can be found in [1] and [34]. The 1235 following values are extracted from [1], and are listed here since 1236 they are further qualified: 1238 Login 1 1239 The user should be connected to a host. The message MAY include 1240 additional AVPs defined in section 7.3. 1242 Framed 2 1243 A Framed Protocol should be started for the User, such as PPP 1244 or SLIP. The message MAY include additional AVPs defined in 1245 section 7.2, or 7.4 for tunneling services. 1247 Callback Login 3 1248 The user should be disconnected and called back, then connected 1249 to a host. The message MAY include additional AVPs defined in 1250 section 7.3. 1252 Callback Framed 4 1253 The user should be disconnected and called back, then a Framed 1254 Protocol should be started for the User, such as PPP or SLIP. 1255 The message MAY include additional AVPs defined in section 7.2, 1256 or 7.4 for tunneling services. 1258 7.2 Framed Access Authorization AVPs 1260 This section contains the authorization AVPs that are necessary to 1261 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1262 section MAY be present in a message if the Service-Type AVP was set 1263 to "Framed" or "Callback Framed". 1265 7.2.1 Framed-Protocol AVP 1267 The Framed-Protocol AVP (AVP Code 7) is of type Unsigned32 and 1268 contains the framing to be used for framed access. This AVP MAY be 1269 present in both requests and responses. The supported values are 1270 listed in [34]. 1272 7.2.2 Framed-Routing AVP 1273 The Framed-Routing AVP (AVP Code 10) is of type Unsigned32 and 1274 contains the routing method for the user, when the user is a router 1275 to a network. This AVP SHOULD only be present in authorization 1276 responses. The supported values are listed in [34]. 1278 7.2.3 Framed-MTU AVP 1280 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1281 the Maximum Transmission Unit to be configured for the user, when it 1282 is not negotiated by some other means (such as PPP). This AVP SHOULD 1283 only be present in authorization responses. The MTU value MUST be 1284 between the range of 64 and 65535. 1286 7.2.4 Framed-Compression AVP 1288 The Framed-Compression AVP (AVP Code 13) is of type Unsigned32 and 1289 contains the compression protocol to be used for the link. It MAY be 1290 used in an authorization request as a hint to the server that a 1291 specific compression type is desired, but the server is not required 1292 to honor the hint in the corresponding response. 1294 More than one compression protocol AVP MAY be sent. It is the 1295 responsibility of the NAS to apply the proper compression protocol to 1296 appropriate link traffic. 1298 The supported values are listed in [34]. 1300 7.2.5 IP Access 1302 The AVPs defined in this section are used when the user requests, or 1303 is being granted, access to IP. They are only present if the Framed- 1304 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1305 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1307 7.2.5.1 Framed-IP-Address AVP 1309 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1310 contains the address to be configured for the user. It MAY be used in 1311 an authorization request as a hint to the server that a specific 1312 address is desired, but the server is not required to honor the hint 1313 in the corresponding response. 1315 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1316 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1317 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1318 that the NAS should select an address for the user (e.g. Assigned 1319 from a pool of addresses kept by the NAS). 1321 7.2.5.2 Framed-IP-Netmask AVP 1323 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1324 contains the IP netmask to be configured for the user when the user 1325 is a router to a network. It MAY be used in an authorization request 1326 as a hint to the server that a specific netmask is desired, but the 1327 server is not required to honor the hint in the corresponding 1328 response. This AVP MUST be present in a response if the request 1329 included this AVP with a value of 0xFFFFFFFF. 1331 7.2.5.3 Framed-IP-Route AVP 1333 The Framed-IP-Route AVP (AVP Code 22) is of type OctetString, encoded 1334 in the UTF-8 [29] format, and contains the routing information to be 1335 configured for the user on the NAS. Zero or more such AVPs MAY be 1336 present in an authorization response. 1338 The string MUST contain a destination prefix in dotted quad form 1339 optionally followed by a slash and a decimal length specifier stating 1340 how many high order bits of the prefix should be used. That is 1341 followed by a space, a gateway address in dotted quad form, a space, 1342 and one or more metrics separated by spaces. For example, 1343 "192.168.1.0/24 192.168.1.1 1". 1345 The length specifier may be omitted in which case it should default 1346 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1347 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1349 Whenever the gateway address is specified as "0.0.0.0" the IP address 1350 of the user SHOULD be used as the gateway address. 1352 7.2.6 IPX Access 1354 The AVPs defined in this section are used when the user requests, or 1355 is being granted, access to IPX. They are only present if the 1356 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics 1357 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1358 protocol, or X.75 Synchronous. 1360 7.2.6.1 Framed-IPX-Network AVP 1361 The Framed-IPX-Network AVP (AVP Code 23) is of type OctetString, 1362 encoded in the UTF-8 [29] format, and contains the IPX Network number 1363 to be configured for the user. It MAY be used in an authorization 1364 request as a hint to the server that a specific address is desired, 1365 but the server is not required to honor the hint in the corresponding 1366 response. 1368 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1369 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1370 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1371 that the NAS should select an address for the user (e.g. assigned 1372 from a pool of one or more IPX networks kept by the NAS). 1374 7.2.7 Appletalk Access 1376 The AVPs defined in this section are used when the user requests, or 1377 is being granted, access to Appletalk. They are only present if the 1378 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1379 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1381 7.2.7.1 Framed-AppleTalk-Link AVP 1383 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1384 contains the AppleTalk network number which should be used for the 1385 serial link to the user, which is another AppleTalk router. This AVP 1386 MUST only be present in an authorization response and is never used 1387 when the user is not another router. 1389 Despite the size of the field, values range from zero to 65535. The 1390 special value of zero indicates that this is an unnumbered serial 1391 link. A value of one to 65535 means that the serial line between the 1392 NAS and the user should be assigned that value as an AppleTalk 1393 network number. 1395 7.2.7.2 Framed-AppleTalk-Network AVP 1397 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1398 and contains the AppleTalk Network number which the NAS should probe 1399 to allocate an AppleTalk node for the user. This AVP MUST only be 1400 present in an authorization response and is never used when the user 1401 is not another router. Multiple instances of this AVP indicate that 1402 the NAS may probe using any of the network numbers specified. 1404 Despite the size of the field, values range from zero to 65535. The 1405 special value zero indicates that the NAS should assign a network for 1406 the user, using its default cable range. A value between one and 1407 65535 (inclusive) indicates the AppleTalk Network the NAS should 1408 probe to find an address for the user. 1410 7.2.7.3 Framed-AppleTalk-Zone AVP 1412 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1413 and contains the AppleTalk Default Zone to be used for this user. 1414 This AVP MUST only be present in an authorization response. Multiple 1415 instances of this AVP in the same message are not allowed. 1417 The codification of the range of allowed usage of this field is 1418 outside the scope of this specification. 1420 7.2.8 ARAP Access 1422 The AVPs defined in this section are used when the user requests, or 1423 is being granted, access to ARAP. They are only present if the 1424 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1425 Access Protocol (ARAP). 1427 7.2.8.1 ARAP-Features AVP 1429 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1430 be present in the AA-Accept message if the Framed-Protocol AVP is set 1431 to the value of ARAP. See [32] for more information of the format of 1432 this AVP. 1434 7.2.8.2 ARAP-Zone-Access AVP 1436 The ARAP-Zone-Access AVP (AVP Code 72) is of type Unsigned32, and MAY 1437 be present in the AA-Accept message if the Framed-Protocol AVP is set 1438 to the value of ARAP. 1440 The supported values are listed in [34], and are defined in [32]. 1442 7.2.8.3 ARAP-Security AVP 1444 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1445 present in the AA-Challenge-Ind message if the Framed-Protocol AVP is 1446 set to the value of ARAP. See [32] for more information of the 1447 format of this AVP. 1449 7.2.8.4 ARAP-Security-Data AVP 1451 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1452 be present in the AA-Request or AA-Challenge-Ind message if the 1453 Framed-Protocol AVP is set to the value of ARAP. This AVP contains 1454 the security module challenge or response associated with the ARAP 1455 Security Module specified in ARAP-Security. 1457 7.3 Non-Framed Access Authorization AVPs 1459 This section contains the authorization AVPs that are needed to 1460 support terminal server functionality. AVPs defined in this section 1461 MAY be present in a message if the Service-Type AVP was set to 1462 "Login" or "Callback Login". 1464 7.3.1 Login-IP-Host AVP 1466 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1467 the system with which to connect the user, when the Login-Service AVP 1468 is included. It MAY be used in an authorization request as a hint to 1469 the server that a specific host is desired, but the server is not 1470 required to honor the hint in the corresponding response. 1472 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1473 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1474 select an address. The value zero indicates that the NAS SHOULD 1475 select a host to connect the user to. 1477 7.3.2 Login-Service AVP 1479 The Login-Service AVP (AVP Code 15) is of type Unsigned32 and 1480 contains the service which should be used to connect the user to the 1481 login host. This AVP SHOULD only be present in authorization 1482 responses. 1484 The supported values are listed in [34]. 1486 7.3.3 TCP Services 1488 The AVP described in this section MAY be present if the Login-Service 1489 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1491 7.3.3.1 Login-TCP-Port AVP 1492 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1493 contains the TCP port with which the user is to be connected, when 1494 the Login-Service AVP is also present. This AVP SHOULD only be 1495 present in authorization responses. The value MUST NOT be greater 1496 than 65535. 1498 7.3.4 LAT Services 1500 The AVP described in this section MAY be present if the Login-Service 1501 AVP is set to LAT. 1503 7.3.4.1 Login-LAT-Service AVP 1505 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1506 contains the system with which the user is to be connected by LAT. It 1507 MAY be used in an authorization request as a hint to the server that 1508 a specific service is desired, but the server is not required to 1509 honor the hint in the corresponding response. This AVP MUST only be 1510 present in the response if the Login-Service AVP states that LAT is 1511 desired. 1513 Administrators use the service attribute when dealing with clustered 1514 systems, such as a VAX or Alpha cluster. In such an environment 1515 several different time sharing hosts share the same resources (disks, 1516 printers, etc.), and administrators often configure each to offer 1517 access (service) to each of the shared resources. In this case, each 1518 host in the cluster advertises its services through LAT broadcasts. 1520 Sophisticated users often know which service providers (machines) are 1521 faster and tend to use a node name when initiating a LAT connection. 1522 Alternately, some administrators want particular users to use certain 1523 machines as a primitive form of load balancing (although LAT knows 1524 how to do load balancing itself). 1526 The String field contains the identity of the LAT service to use. 1527 The LAT Architecture allows this string to contain $ (dollar), - 1528 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1529 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1530 string comparisons are case insensitive. 1532 7.3.4.2 Login-LAT-Node AVP 1534 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1535 contains the Node with which the user is to be automatically 1536 connected by LAT. It MAY be used in an authorization request as a 1537 hint to the server that a specific LAT node is desired, but the 1538 server is not required to honor the hint in the corresponding 1539 response. This AVP MUST only be present in a response if the 1540 Service-Type AVP is set to LAT. 1542 The String field contains the identity of the LAT service to use. 1543 The LAT Architecture allows this string to contain $ (dollar), - 1544 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1545 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1546 string comparisons are case insensitive. 1548 7.3.4.3 Login-LAT-Group AVP 1550 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1551 contains a string identifying the LAT group codes which this user is 1552 authorized to use. It MAY be used in an authorization request as a 1553 hint to the server that a specific group is desired, but the server 1554 is not required to honor the hint in the corresponding response. This 1555 AVP MUST only be present in a response if the Service-Type AVP is set 1556 to LAT. 1558 LAT supports 256 different group codes, which LAT uses as a form of 1559 access rights. LAT encodes the group codes as a 256 bit bitmap. 1561 Administrators can assign one or more of the group code bits at the 1562 LAT service provider; it will only accept LAT connections that have 1563 these group codes set in the bit map. The administrators assign a 1564 bitmap of authorized group codes to each user; LAT gets these from 1565 the operating system, and uses these in its requests to the service 1566 providers. 1568 The codification of the range of allowed usage of this field is 1569 outside the scope of this specification. 1571 7.3.4.4 Login-LAT-Port AVP 1573 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1574 contains the Port with which the user is to be connected by LAT. It 1575 MAY be used in an authorization request as a hint to the server that 1576 a specific port is desired, but the server is not required to honor 1577 the hint in the corresponding response. This AVP MUST only be present 1578 in a response if the Service-Type AVP is set to LAT. 1580 The String field contains the identity of the LAT service to use. 1581 The LAT Architecture allows this string to contain $ (dollar), - 1582 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1583 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1584 string comparisons are case insensitive. 1586 7.4 Tunneling AVP 1588 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1589 used to describe a tunnel. Its Data field has the following ABNF 1590 grammar: 1592 Tunneling = Type Medium Cep Sep Pw Gid Aid Pref Caid Said 1593 Type = Tunnel-Type ; See Section 7.4.1 1594 Medium = Tunnel-Medium-Type ; See Section 7.4.2 1595 Cep = Tunnel-Client-Endpoint ; See Section 7.4.3 1596 Sep = Tunnel-Server-Endpoint ; See Section 7.4.4 1597 Pw = Tunnel-Password ; See Section 7.4.5 1598 Gid = Tunnel-Private-Group-ID ; See Section 7.4.6 1599 Aid = Tunnel-Assignment-ID ; See Section 7.4.7 1600 Pref = Tunnel-Preference ; See Section 7.4.8 1601 Caid = Tunnel-Client-Auth-ID ; See Section 7.4.9 1602 Said = Tunnel-Server-Auth-ID ; See Section 7.1.4.10 1604 +---------------------------------------------------------------+ 1605 | AVP Header (AVP Code = 403) | 1606 +---------------------------------------------------------------+ 1607 | Tunnel-Type AVP | 1608 +---------------------------------------------------------------+ 1609 | Tunnel-Medium-Type AVP | 1610 +---------------------------------------------------------------+ 1611 | Tunnel-Client-Endpoint AVP | 1612 +---------------------------------------------------------------+ 1613 | Tunnel-Server-Endpoint AVP | 1614 +---------------------------------------------------------------+ 1615 | Tunnel-Password AVP | 1616 +---------------------------------------------------------------+ 1617 | Tunnel-Private-Group-Id AVP | 1618 +---------------------------------------------------------------+ 1619 | Tunnel-Assignment-ID AVP | 1620 +---------------------------------------------------------------+ 1621 | Tunnel-Preference AVP | 1622 +---------------------------------------------------------------+ 1623 | Tunnel-Client-Auth-ID AVP | 1624 +---------------------------------------------------------------+ 1625 | Tunnel-Server-Auth-ID AVP | 1626 +---------------------------------------------------------------+ 1628 7.4.1 Tunnel-Type AVP 1629 The Tunnel-Type AVP (AVP Code 64) is of type Unsigned32 and contains 1630 the tunneling protocol(s) to be used (in the case of a tunnel 1631 initiator) or the the tunneling protocol in use (in the case of a 1632 tunnel terminator). It MAY be used in an authorization request as a 1633 hint to the server that a specific tunnel type is desired, but the 1634 server is not required to honor the hint in the corresponding 1635 response. 1637 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1638 Record within the Accounting-Request. 1640 A tunnel initiator is not required to implement any of these tunnel 1641 types; if a tunnel initiator receives a response that contains only 1642 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1643 as though a response was received with the Result-Code indicating a 1644 failure. 1646 The supported values are listed in [34]. 1648 7.4.2 Tunnel-Medium-Type AVP 1650 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and 1651 contains the transport medium to use when creating a tunnel for those 1652 protocols (such as L2TP) that can operate over multiple transports. 1653 It MAY be used in an authorization request as a hint to the server 1654 that a specific medium is desired, but the server is not required to 1655 honor the hint in the corresponding response. 1657 The Value field contains one of the values listed under "Address 1658 Family Numbers" in [10]. The value of most importance is (1) for IPv4 1659 and (2) for IPv6. 1661 7.4.3 Tunnel-Client-Endpoint AVP 1663 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type OctetString, 1664 encoded in the UTF-8 [29] format, and contains the address of the 1665 initiator end of the tunnel. It MAY be used in an authorization 1666 request as a hint to the server that a specific endpoint is desired, 1667 but the server is not required to honor the hint in the corresponding 1668 response. 1670 This AVP SHOULD be included in the ADIF Record of the corresponding 1671 Accounting-Request messages, in which case it indicates the address 1672 from which the tunnel was initiated. This AVP, along with the 1673 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1674 a globally unique means to identify a tunnel for accounting and 1675 auditing purposes. 1677 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1678 fully qualified domain name (FQDN) of the tunnel client machine, or 1679 it is a "dotted-decimal" IP address. Conformant implementations MUST 1680 support the dotted-decimal format and SHOULD support the FQDN format 1681 for IP addresses. 1683 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1684 FQDN of the tunnel client machine, or it is a text representation of 1685 the address in either the preferred or alternate form [5]. 1686 Conformant implementations MUST support the preferred form and SHOULD 1687 support both the alternate text form and the FQDN format for IPv6 1688 addresses. 1690 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1691 referring to configuration data local to the Diameter client that 1692 describes the interface and medium-specific address to use. 1694 7.4.4 Tunnel-Server-Endpoint AVP 1696 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of OctetString, 1697 encoded in the UTF-8 [29] format, and contains the address of the 1698 server end of the tunnel. It MAY be used in an authorization request 1699 as a hint to the server that a specific endpoint is desired, but the 1700 server is not required to honor the hint in the corresponding 1701 response. 1703 This AVP SHOULD be included in the ADIF Record of the corresponding 1704 Accounting-Request messages, in which case it indicates the address 1705 from which the tunnel was initiated. This AVP, along with the 1706 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1707 a globally unique means to identify a tunnel for accounting and 1708 auditing purposes. 1710 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1711 fully qualified domain name (FQDN) of the tunnel client machine, or 1712 it is a "dotted-decimal" IP address. Conformant implementations MUST 1713 support the dotted-decimal format and SHOULD support the FQDN format 1714 for IP addresses. 1716 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1717 FQDN of the tunnel client machine, or it is a text representation of 1718 the address in either the preferred or alternate form [5]. 1719 Conformant implementations MUST support the preferred form and SHOULD 1720 support both the alternate text form and the FQDN format for IPv6 1721 addresses. 1723 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1724 referring to configuration data local to the Diameter client that 1725 describes the interface and medium-specific address to use. 1727 7.4.5 Tunnel-Password AVP 1729 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1730 contain a password to be used to authenticate to a remote server. 1731 This AVP MUST only be present in authorization responses in an 1732 encrypted form, using one of the methods described in [2] and [13]. 1734 7.4.6 Tunnel-Private-Group-ID AVP 1736 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type OctetString, 1737 encoded in the UTF-8 [29] format, and contains the group ID for a 1738 particular tunneled session. The Tunnel-Private-Group-ID AVP MAY be 1739 included in an authorization request if the tunnel initiator can 1740 pre-determine the group resulting from a particular connection and 1741 SHOULD be included in the authorization response if this tunnel 1742 session is to be treated as belonging to a particular private group. 1743 Private groups may be used to associate a tunneled session with a 1744 particular group of users. For example, it MAY be used to facilitate 1745 routing of unregistered IP addresses through a particular interface. 1746 This value SHOULD be included the corresponding ADIF-Record in the 1747 Accounting-Request which pertain to a tunneled session. 1749 7.4.7 Tunnel-Assignment-ID AVP 1751 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1752 is used to indicate to the tunnel initiator the particular tunnel to 1753 which a session is to be assigned. Some tunneling protocols, such as 1754 PPTP and L2TP, allow for sessions between the same two tunnel 1755 endpoints to be multiplexed over the same tunnel and also for a given 1756 session to utilize its own dedicated tunnel. This attribute provides 1757 a mechanism for Diameter to be used to inform the tunnel initiator 1758 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1759 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1760 sharing multiplexed tunnels to be assigned to different multiplexed 1761 tunnels. 1763 A particular tunneling implementation may assign differing 1764 characteristics to particular tunnels. For example, different 1765 tunnels may be assigned different QOS parameters. Such tunnels may 1766 be used to carry either individual or multiple sessions. The 1767 Tunnel-Assignment-ID attribute thus allows the Diameter server to 1768 indicate that a particular session is to be assigned to a tunnel that 1769 provides an appropriate level of service. It is expected that any 1770 QOS-related Diameter tunneling attributes defined in the future that 1771 accompany this attribute will be associated by the tunnel initiator 1772 with the ID given by this attribute. In the meantime, any semantic 1773 given to a particular ID string is a matter left to local 1774 configuration in the tunnel initiator. 1776 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1777 the tunnel initiator. The ID it specifies is intended to be of only 1778 local use to Diameter and the tunnel initiator. The ID assigned by 1779 the tunnel initiator is not conveyed to the tunnel peer. 1781 This attribute MAY be included in authorization responses. The tunnel 1782 initiator receiving this attribute MAY choose to ignore it and assign 1783 the session to an arbitrary multiplexed or non-multiplexed tunnel 1784 between the desired endpoints. This attribute SHOULD also be 1785 included in the corresponding ADIF-Record in the Accounting-Request 1786 messages which pertain to a tunneled session. 1788 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1789 should assign a session to a tunnel in the following manner: 1791 - If this AVP is present and a tunnel exists between the specified 1792 endpoints with the specified ID, then the session should be 1793 assigned to that tunnel. 1795 - If this AVP is present and no tunnel exists between the 1796 specified endpoints with the specified ID, then a new tunnel 1797 should be established for the session and the specified ID 1798 should be associated with the new tunnel. 1800 - If this AVP is not present, then the session is assigned to an 1801 unnamed tunnel. If an unnamed tunnel does not yet exist between 1802 the specified endpoints then it is established and used for this 1803 and subsequent sessions established without the Tunnel- 1804 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1805 session for which a Tunnel-Assignment-ID AVP was not specified 1806 to a named tunnel (i.e. one that was initiated by a session 1807 specifying this AVP). 1809 Note that the same ID may be used to name different tunnels if such 1810 tunnels are between different endpoints. 1812 7.4.8 Tunnel-Preference AVP 1814 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1815 used to identify the relative preference assigned to each tunnel when 1816 more than one set of tunneling AVPs is returned within separate 1817 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1818 hint to the server that a specific preference is desired, but the 1819 server is not required to honor the hint in the corresponding 1820 response. 1822 For example, suppose that AVPs describing two tunnels are returned by 1823 the server, one with a Tunnel-Type of PPTP and the other with a 1824 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1825 the Tunnel-Types returned, it will initiate a tunnel of that type. 1826 If, however, it supports both tunnel protocols, it SHOULD use the 1827 value of the Tunnel-Preference AVP to decide which tunnel should be 1828 started. The tunnel having the numerically lowest value in the Value 1829 field of this AVP SHOULD be given the highest preference. The values 1830 assigned to two or more instances of the Tunnel-Preference AVP within 1831 a given authorization response MAY be identical. In this case, the 1832 tunnel initiator SHOULD use locally configured metrics to decide 1833 which set of AVPs to use. 1835 7.4.9 Tunnel-Client-Auth-ID AVP 1837 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1838 specifies the name used by the tunnel initiator during the 1839 authentication phase of tunnel establishment. It MAY be used in an 1840 authorization request as a hint to the server that a specific 1841 preference is desired, but the server is not required to honor the 1842 hint in the corresponding response. This AVP MUST be present in the 1843 authorization response if an authentication name other than the 1844 default is desired. This AVP SHOULD be included in the corresponding 1845 ADIF-Record of the Accounting-Request messages which pertain to a 1846 tunneled session. 1848 7.4.10 Tunnel-Server-Auth-ID AVP 1850 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1851 and specifies the name used by the tunnel terminator during the 1852 authentication phase of tunnel establishment. It MAY be used in an 1853 authorization request as a hint to the server that a specific 1854 preference is desired, but the server is not required to honor the 1855 hint in the corresponding response. This AVP MUST be present in the 1856 authorization response if an authentication name other than the 1857 default is desired. This AVP SHOULD be included in the corresponding 1858 ADIF-Record of the Accounting-Request messages which pertain to a 1859 tunneled session. 1861 8.0 Accounting AVPs 1863 This section contains a description of the AVPs defined in this 1864 document that are to be included in Diameter accounting messages [2]. 1866 8.1 Accounting-Input-Octets AVP 1868 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 1869 and contains the number of octets in IP packets received by the user. 1871 8.2 Accounting-Output-Octets AVP 1873 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 1874 and contains the number of octets in IP packets sent to the user. 1876 8.3 Accounting-Session-Time AVP 1878 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1879 and indicates the length of the current session in seconds. 1881 8.4 Accounting-Input-Packets AVP 1883 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 1884 contains the number of IP packets received by the user. 1886 8.5 Accounting-Output-Packets AVP 1888 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 1889 and contains the number of IP packets sent to the user. 1891 8.6 Accounting-Authentication-Type AVP 1893 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 1894 Unsigned32, and specifies how the user was authenticated. The 1895 supported values are listed in [34]. 1897 8.7 Acct-Tunnel-Connection AVP 1899 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 1900 and contains the identifier assigned to the tunnel session. This AVP, 1901 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1902 AVPs, may be used to provide a means to uniquely identify a tunnel 1903 session for auditing purposes. 1905 The format of the identifier in this AVP depends upon the value of 1906 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 1907 connection, the L2TP Tunnel ID and Call ID might be encoded in this 1908 field. The exact encoding of this field is implementation dependent. 1910 8.8 Acct-Tunnel-Packets-Lost AVP 1912 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 1913 and contains the number of packets lost on a given link. 1915 9.0 Interactions with Resource Management 1917 The Resource Management extension [31] provides the ability for a 1918 Diameter node to query a peer for session state information. The 1919 document states that service-specific extensions are responsible for 1920 specifying what AVPs are to be present in the Resource-Token [31] 1921 AVP. 1923 In addition to the AVPs listed in [31], the Resource-Token with the 1924 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1925 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1926 IPX-Network MUST be present if the corresponding network is being 1927 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1928 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1929 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1930 AVPs MUST be present. 1932 10.0 RADIUS/Diameter Protocol Interactions 1934 This section describes some basic guidelines that may be used by 1935 servers that act as protocol gateways. Note that this document does 1936 not restrict implementations from creating other methods, as long as 1937 the bridging function doesn't break the RADIUS nor the Diameter 1938 protocol. 1940 There are essentially two different situations that must be handled; 1941 one where a RADIUS request is received that must be forwarded as a 1942 Diameter request, and the inverse. Note that this section uses two 1943 different terms; AVP and attribute. The former is used to signify a 1944 Diameter AVP, while the latter is used to signify a RADIUS attribute. 1946 10.1 RADIUS request forwarded as Diameter request 1948 This section describes the actions that should be followed when a 1949 protocol Gateway receives a RADIUS message that is to be translated 1950 to a Diameter message. 1952 It is important to note that RADIUS servers are inherently stateless, 1953 and this section maintains that assumption. It is quite possible for 1954 the RADIUS messages that comprises the session (i.e. authentication 1955 and accounting messages) be handled by different protocol gateways in 1956 the proxy network. Therefore a RADIUS->Diameter protocol gateway 1957 cannot maintain session state information. 1959 When a protocol gateway receives a RADIUS message, the following 1960 steps should be taken: 1962 - If the NAS-IP-Address attribute is present in the RADIUS 1963 message, the name MUST be translated to its corresponding FQDN, 1964 and encoded in the Diameter message's Origin-FQDN AVP. If the 1965 NAS-Identifier attribute is present, the data can be used in the 1966 Origin-FQDN AVP. 1967 - The Origin-FQDN AVP is added with the local server's identity. 1968 This will ensure that the corresponding response will be 1969 returned to the correct gateway server. 1970 - The Destination-Realm AVP is created from the information found 1971 in the RADIUS User-Name attribute. 1972 - The Gateway Server must maintain state information relevant to 1973 the RADIUS request, such as the Identifier field in the RADIUS 1974 header, any existing RADIUS Proxy-State attribute as well as the 1975 source IP address and port number of the UDP packet. These may 1976 be maintained locally in a state table, or may be saved in a 1977 Proxy-Info AVP. 1978 - If the Acct-Session-Id attribute was found in the request, the 1979 contents are inserted in the Acct-Session-Id AVP. 1980 - If the RADIUS request contained a Class or State attribute, and 1981 the prefix of the data is "Diameter/", the data following the 1982 prefix contains the Diameter Session-Id. If no such attributes 1983 are present, and the RADIUS command is an Access-Request, a new 1984 Session-Id is created. The Session-Id is included in the 1985 Session-Id AVP. 1986 - If the RADIUS message received is an Accounting-Request, with 1987 the Acct-Status-Type attribute set to STOP, the local server 1988 MUST issue a Session-Termination-Request message once the 1989 Diameter Accounting-Answer has been received. 1991 The corresponding Diameter response is always guaranteed to be 1992 received by the same protocol gateway that translated the original 1993 request, due to the contents of the Origin-FQDN AVP in the Diameter 1994 request. The following steps are applied to the response message 1995 during the Diameter to RADIUS translation: 1997 - If the Diameter Command-Code is set to AA-Challenge, the 1998 Diameter Session-Id and the Origin-FQDN AVPs are saved in the 1999 RADIUS State attribute, with the prefix "Diameter/". This is 2000 necessary in order to ensure that the protocol gateway that will 2001 receive the subsequent RADIUS Access-Request will have access to 2002 the Session Identifier, and be able to set the Destination-FQDN 2003 to the correct value. 2004 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 2005 AVP is saved in a new RADIUS Class attribute, whose format 2006 consists of the string "Diameter/" followed by the Diameter 2007 Session Identifier. This will ensure that the subsequent 2008 Accounting messages, which could be received by any protocol 2009 gateway, would have access to the original Diameter Session 2010 Identifier. 2011 - If a Proxy-State attribute was present in the RADIUS request, 2012 the same attribute is added in the response. This information 2013 may be found in the Proxy-Info AVP, or in a local state table. 2014 - If state information regarding the RADIUS request was saved in a 2015 Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and 2016 port number are extracted and used in issuing the RADIUS reply. 2018 10.2 Diameter request forwarded as RADIUS request 2020 When a server receives a Diameter request that is to be forwarded to 2021 a RADIUS entity, the following steps are an example of the steps that 2022 may be followed: 2024 - The Origin-FQDN AVP's value is inserted in the NAS-Identifier 2025 attribute. 2026 - The following information MUST be present in the corresponding 2027 Diameter response, and therefore MUST be saved either in a local 2028 state table, or it MAY be encoded in a RADIUS Proxy-State 2029 attribute: 2030 1. Origin-FQDN AVP 2031 2. Session-Id AVP 2032 3. Proxy-Info AVP 2033 4. Route-Record AVPs (in the proper order) 2034 5. Any other AVP that MUST be present in the response, and 2035 has no corresponding RADIUS attribute. 2037 When the corresponding response is received by the gateway server, 2038 which is guaranteed in the RADIUS protocol, the following steps may 2039 be followed: 2041 - If a Proxy-Info AVP is present, extract the encoded information, 2042 otherwise retrieve the information from the local state table. 2043 - The request's Origin-FQDN information is added to the 2044 Destination-FQDN AVP. 2045 - The Session-Id information is added to the Session-Id AVP. 2046 - The Route-Record AVPs MUST be added to the Diameter message, in 2047 the same order they were present in the request. 2048 - If a Proxy-Info AVP was present in the request, the same AVP MUST 2049 be added to the response. 2050 - If the RADIUS Class or State attributes are present, these 2051 attributes must be present in the Diameter response. 2052 - Any other AVPs that were saved, and MUST be present in the 2053 response, are added to the message. 2055 11.0 AVP Occurrence Table 2057 The following tables presents the AVPs defined in this document, and 2058 specifies in which Diameter messages they MAY, or MAY NOT be present. 2059 Note that AVPs that can only be present within a Grouped AVP are not 2060 represented in this table. 2062 The table uses the following symbols: 2063 0 The AVP MUST NOT be present in the message. 2064 0+ Zero or more instances of the AVP MAY be present in the 2065 message. 2066 0-1 Zero or one instance of the AVP MAY be present in the 2067 message. 2068 1 One instance of the AVP MUST be present in the message. 2070 11.1 NASREQ Command AVP Table 2072 The table in this section is limited to the Command Codes defined in 2073 this specification. 2075 +-----------------------------------+ 2076 | Command-Code | 2077 |-----+-----+-----+-----+-----+-----+ 2078 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 2079 ------------------------------|-----+-----+-----+-----+-----|-----| 2080 ARAP-Challenge-Response | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 2081 ARAP-Features | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 2082 ARAP-Password | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2083 ARAP-Security | 0-1 | 0 | 0-1 | 0-1 | 0 | 0-1 | 2084 ARAP-Security-Data | 0+ | 0 | 0 | 0+ | 0 | 0 | 2085 ARAP-Zone-Access | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2086 Callback-Id | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2087 +-----------------------------------+ 2088 | Command-Code | 2089 |-----+-----+-----+-----+-----+-----+ 2090 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 2091 ------------------------------|-----+-----+-----+-----+-----|-----| 2092 Callback-Number | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2093 Called-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2094 Calling-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2095 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 0 | 0 | 2096 CHAP-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2097 Class | 0 | 0+ | 0 | 0 | 0+ | 0 | 2098 Connect-Info | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2099 Destination-FQDN | 0+ | 1 | 1 | 0+ | 1 | 1 | 2100 Destination-Realm | 0 | 1 | 1 | 1 | 0 | 1 | 2101 EAP-Payload | 0 | 0 | 0 | 1 | 1 | 1 | 2102 Error-Reporting-FQDN | 0 | 0+ | 0+ | 0 | 0+ | 0 | 2103 Auth-Extension-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2104 Filter-Id | 0 | 0+ | 0 | 0 | 0+ | 0 | 2105 Filter-Rule | 0 | 0+ | 0 | 0 | 0+ | 0 | 2106 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2107 Framed-Appletalk-Network | 0 | 0+ | 0 | 0 | 0+ | 0 | 2108 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2109 Framed-Compression | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2110 Framed-IP-Address | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2111 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2112 Framed-IP-Route | 0 | 0+ | 0 | 0 | 0+ | 0 | 2113 Framed-IPX-Network | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2114 Framed-MTU | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2115 Framed-Protocol | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2116 Framed-Routing | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2117 Idle-Timeout | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2118 Login-IP-Host | 0+ | 0+ | 0 | 0 | 0 | 0 | 2119 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2120 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2121 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2122 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2123 Login-Service | 0 | 0+ | 0 | 0 | 0 | 0 | 2124 Login-TCP-Port | 0 | 0+ | 0 | 0 | 0 | 0 | 2125 NAS-IP-Address | 1 | 0 | 0 | 1 | 0 | 0 | 2126 NAS-Port | 1 | 0 | 0 | 1 | 0 | 0 | 2127 NAS-Port-Type | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2128 Origin-FQDN | 1 | 1 | 1 | 1 | 1 | 1 | 2129 Origin-Realm | 1 | 1 | 1 | 1 | 1 | 1 | 2130 Password-Retry | 0 | 0-1 | 0 | 0 | 0 | 0 | 2131 Port-Limit | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2132 Prompt | 0 | 0 | 0-1 | 0 | 0 | 0 | 2133 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2134 Reply-Message | 0 | 0 | 0+ | 0 | 0 | 0 | 2135 +-----------------------------------+ 2136 | Command-Code | 2137 |-----+-----+-----+-----+-----+-----+ 2138 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 2139 ------------------------------|-----+-----+-----+-----+-----|-----| 2140 Request-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2141 Result-Code | 0 | 1 | 0 | 0 | 1 | 0 | 2142 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2143 Service-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2144 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2145 Session-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2146 State | 0-1 | 0-1 | 0-1 | 0 | 0-1 | 0 | 2147 Tunneling | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2148 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2149 User-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2151 11.2 Accounting AVP Table 2153 The tables in this section are used to represent which AVPs defined 2154 in this document are to be present in the Accounting messages, 2155 defined in [1]. 2157 11.2.1 Framed Access 2159 The table in this section is used when the Service-Type specifies 2160 Framed Access. 2162 +-----------------------+ 2163 | Command-Code | 2164 |-----+-----+-----+-----+ 2165 Attribute Name | ACR | ACA | API | ASI | 2166 ------------------------------|-----+-----+-----+-----+ 2167 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2168 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2169 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2170 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2171 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2172 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2173 Accounting-State | 0 | 0 | 1 | 0 | 2174 Acct-Tunnel-Connection | 0-1 | 0-1 | 0 | 0 | 2175 Acct-Tunnel-Packets-Lost | 0-1 | 0-1 | 0 | 0 | 2176 Framed-AppleTalk-Link | 0-1 | 0-1 | 0 | 0 | 2177 Framed-AppleTalk-Network | 0-1 | 0-1 | 0 | 0 | 2178 Framed-AppleTalk-Zone | 0-1 | 0-1 | 0 | 0 | 2179 Framed-Compression | 0-1 | 0-1 | 0 | 0 | 2180 Framed-IP-Address | 0-1 | 0-1 | 0 | 0 | 2181 +-----------------------+ 2182 | Command-Code | 2183 |-----+-----+-----+-----+ 2184 Attribute Name | ACR | ACA | API | ASI | 2185 ------------------------------|-----+-----+-----+-----+ 2186 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0 | 2187 Framed-IPX-Network | 0-1 | 0-1 | 0 | 0 | 2188 Framed-MTU | 0-1 | 0-1 | 0 | 0 | 2189 Framed-Protocol | 0-1 | 0-1 | 0 | 0 | 2190 Framed-Route | 0-1 | 0-1 | 0 | 0 | 2191 Framed-Routing | 0-1 | 0-1 | 0 | 0 | 2192 Service-Type | 1 | 1 | 0 | 0 | 2193 Tunnel-Assignment-ID | 0-1 | 0-1 | 0 | 0 | 2194 Tunnel-Client-Endpoint | 0-1 | 0-1 | 0 | 0 | 2195 Tunnel-Medium-Type | 0-1 | 0-1 | 0 | 0 | 2196 Tunnel-Private-Group-ID | 0-1 | 0-1 | 0 | 0 | 2197 Tunnel-Server-Endpoint | 0-1 | 0-1 | 0 | 0 | 2198 Tunnel-Type | 0-1 | 0-1 | 0 | 0 | 2199 ------------------------------|-----+-----+-----+-----+ 2201 11.2.2 Non-Framed Access 2203 The table in this section is used when the Service-Type specifies 2204 Non-Framed Access. 2206 +-----------------------+ 2207 | Command-Code | 2208 |-----+-----+-----+-----+ 2209 Attribute Name | ACR | ACA | API | ASI | 2210 ------------------------------|-----+-----+-----+-----+ 2211 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2212 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2213 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2214 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2215 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2216 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2217 Accounting-State | 0 | 0 | 1 | 0 | 2218 Login-IP-Host | 0-1 | 0-1 | 0 | 0 | 2219 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2220 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2221 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2222 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2223 Login-Service | 0-1 | 0-1 | 0 | 0 | 2224 Login-TCP-Port | 0-1 | 0-1 | 0 | 0 | 2225 Service-Type | 1 | 1 | 0 | 0 | 2226 ------------------------------|-----+-----+-----+-----+ 2228 12.0 IANA Considerations 2230 This section contains the namespaces that have either been created in 2231 this specification, or the values assigned to existing namespaces 2232 managed by IANA. 2234 12.1 Command Codes 2236 This specification assigns the values 265-270 from the Command Code 2237 namespace defined in [2], and extended in [13] and [30]. See sections 2238 3.1 and 4.2 for the assignment of the namespace in this 2239 specification. 2241 12.2 AVP Codes 2243 This specification assigns the values 400-403 from the AVP Code 2244 namespace defined in [2], and extended in [13] and [30]. See section 2245 2.1 for the assignment of the namespace in this specification. 2247 This specification also makes use of AVPs in the 0-255 range, which 2248 are defined in [34]. 2250 12.3 Request-Type AVP Values 2252 As defined in Section 2.1.1, the Request-Type AVP (AVP Code 401) 2253 defines the values 1-3. All remaining values are available for 2254 assignment via IETF Consensus [27]. 2256 12.4 Extension Identifier 2258 This specification assigns the value one (1) to the Extension 2259 Identifier namespace defined in [1]. See section 1.2 for more 2260 information. 2262 13.0 Security Considerations 2264 This document does not contain any security protocol, but does 2265 discuss how PPP authentication protocols can be carried within the 2266 Diameter protocol. The PPP authentication protocols that are 2267 described are PAP, CHAP and EAP. 2269 The use of PAP SHOULD be discouraged, since it exposes user's 2270 passwords to possibly non-trusted entities. PAP is also frequently 2271 used for use with One-Time Passwords (OTP), which does not expose any 2272 security risks. However, it is highly recommended that OTP be 2273 supported through the EAP protocol. 2275 This document also describes how CHAP can be carried within the 2276 Diameter protocol, which is required for backward RADIUS 2277 compatibility. The CHAP protocol, as used in a RADIUS environment, 2278 facilitates authentication replay attacks, and therefore SHOULD NOT 2279 be used when EAP is available. 2281 14.0 References 2283 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 2284 cation Dial In User Service (RADIUS)", RFC 2865, June 2000. 2286 [2] Calhoun, Rubens, Akhtar, Guttman, "Diameter Base Protocol", 2287 draft-ietf-aaa-diameter-03.txt, IETF work in progress, May 2001. 2289 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 2290 ary 1999. 2292 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2293 2477, January 1999. 2295 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2296 RFC 2373, July 1998 2298 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2299 (CHAP)", RFC 1994, August 1996. 2301 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2302 links", RFC 1144, February 1990. 2304 [8] ISO 8859. International Standard -- Information Processing -- 2305 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2306 Alphabet No. 1, ISO 8859-1:1987. 2307 2309 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2310 (MP)", RFC 1717, November 1994. 2312 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2313 October 1994 2315 [11] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications 2316 for Tunnel Protocol Support", RFC 2867, June 2000. 2318 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2319 Levels", BCP 14, RFC 2119, March 1997. 2321 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter End-to-End Security 2322 Extension", draft-ietf-aaa-diameter-e2e-sec-01.txt, IETF work in 2323 progress, May 2001. 2325 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2326 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2327 July 1999 2329 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 2330 warding (Protocol) 'L2F'", RFC 2341, May 1998 2332 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 2333 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 2334 August 1999 2336 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2337 2107, February 1997 2339 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2340 Protocol", RFC 2401, November 1998 2342 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2343 1996 2345 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2346 October 1996 2348 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2349 1827, August 1995 2351 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2352 Encapsulation (GRE)", RFC 1701, October 1994 2354 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2356 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2357 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2358 in progress, June 2000. 2360 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 2361 Protocol (EAP)." RFC 2284, March 1998. 2363 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 2364 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 2365 1999. 2367 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 2368 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2370 [28] G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications 2371 for Tunnel Protocol Support", RFC 2867, June 2000. 2373 [29] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2374 2279, January 1998. 2376 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2377 ietf-aaa-diameter-mobileip-03.txt, IETF work in progress, May 2378 2001. 2380 [31] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2381 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 2383 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2384 2869, June 2000. 2386 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2387 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2388 June 2000. 2390 [34] IANA, "RADIUS Types", http://www.isi.edu/in- 2391 notes/iana/assignments/radius-types 2393 [35] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2395 [36] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2396 2869, June 2000. 2398 [37] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2399 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2400 June 2000. 2402 15.0 Acknowledgements 2404 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2405 Allen Simpson, and Steve Willens for their work on the original 2406 RADIUS, from which much of the concepts in this specification were 2407 derived from. Also Carl Rigney and Ward Willats for [32], and Glen 2408 Zorn, Dory Leifer, Allan C. Rubens, John Shriver, Matt Holdrege and 2409 Ignacio Goyret for their work on [33]. This document stole text and 2410 concepts from both [32] and [33]. 2412 The authors would also like to acknowledge the following people for 2413 their contribution in the development of the Diameter protocol: 2415 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2416 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2417 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2418 and Jeff Weisberg 2420 16.0 Authors' Addresses 2422 Questions about this memo can be directed to: 2424 Pat R. Calhoun 2425 Network and Security Research Center, Sun Labs 2426 Sun Microsystems, Inc. 2427 15 Network Circle 2428 Menlo Park, California, 94025 2429 USA 2431 Phone: +1 650-786-7733 2432 Fax: +1 650-786-6445 2433 E-mail: pcalhoun@eng.sun.com 2435 William Bulley 2436 Merit Network, Inc. 2437 Building One, Suite 2000 2438 4251 Plymouth Road 2439 Ann Arbor, Michigan 48105-2785 2440 USA 2442 Phone: +1 734-764-9993 2443 Fax: +1 734-647-3185 2444 E-mail: web@merit.edu 2446 Allan C. Rubens 2447 Tut Systems, Inc. 2448 220 E. Huron, Suite 260 2449 Ann Arbor, MI 48104 2450 USA 2452 Phone: +1 734-995-1697 2453 E-Mail: arubens@tutsys.com 2455 Jeff Haag 2456 Cisco Systems 2457 7025 Kit Creek Road 2458 PO Box 14987 2459 Research Triangle Park, NC 27709 2461 Phone: 1-919-392-2353 2462 E-Mail: haag@cisco.com 2464 Glen Zorn 2465 Cisco Systems, Inc. 2466 500 108th Avenue N.E., Suite 500 2467 Bellevue, WA 98004 2468 USA 2470 Phone: +1 425 438 8218 2471 E-Mail: gwz@cisco.com 2473 17.0 Full Copyright Statement 2475 Copyright (C) The Internet Society (2001). All Rights Reserved. 2477 This document and translations of it may be copied and furnished to 2478 others, and derivative works that comment on or otherwise explain it 2479 or assist in its implementation may be prepared, copied, published 2480 and distributed, in whole or in part, without restriction of any 2481 kind, provided that the above copyright notice and this paragraph are 2482 included on all such copies and derivative works. However, this docu- 2483 ment itself may not be modified in any way, such as by removing the 2484 copyright notice or references to the Internet Society or other 2485 Internet organizations, except as needed for the purpose of develop- 2486 ing Internet standards in which case the procedures for copyrights 2487 defined in the Internet Standards process must be followed, or as 2488 required to translate it into languages other than English. The lim- 2489 ited permissions granted above are perpetual and will not be revoked 2490 by the Internet Society or its successors or assigns. This document 2491 and the information contained herein is provided on an "AS IS" basis 2492 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2493 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2494 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2495 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2496 FITNESS FOR A PARTICULAR PURPOSE. 2498 18.0 Expiration Date 2500 This memo is filed as and 2501 expires in October 2001.