idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-01.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 52 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 53 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 514 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 table 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 (March 2001) is 8435 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) == Missing Reference: '34' is mentioned on line 1953, but not defined == Unused Reference: '3' is defined on line 2109, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2135, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-01 ** 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) -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-06 -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '17') ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '24') ** Obsolete normative reference: RFC 2279 (ref. '25') (Obsoleted by RFC 3629) -- Possible downref: Normative reference to a draft: ref. '26' ** Obsolete normative reference: RFC 2434 (ref. '27') (Obsoleted by RFC 5226) -- Possible downref: Normative reference to a draft: ref. '28' -- Possible downref: Normative reference to a draft: ref. '29' == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-01 == 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') Summary: 24 errors (**), 0 flaws (~~), 15 warnings (==), 10 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 March 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 2.0 Supported AVPs 64 2.1 Diameter AVPs 65 2.1.1 Request-Type AVP 66 2.1.2 Filter-Rule AVP 67 2.2 Legacy RADIUS Attributes 68 2.2.1 NAS-IP-Address AVP 69 2.2.2 NAS-Identifier AVP 70 2.2.3 State AVP 71 2.2.4 Class AVP 72 3.0 Legacy RADIUS Authentication Support 73 3.1 Command-Codes Values 74 3.1.1 AA-Request (AAR) Command 75 3.1.1.1 User-Password AVP 76 3.1.1.2 CHAP-Password AVP 77 3.1.1.3 CHAP-Challenge AVP 78 3.1.1.4 ARAP-Password AVP 79 3.1.2 AA-Answer (AAA) Command 80 3.1.2.1 ARAP-Challenge-Response AVP 81 3.1.2.2 Password-Retry AVP 82 3.1.3 AA-Challenge-Ind (ACI) Command 83 3.1.3.1 Prompt AVP 84 3.2 Reply-Message AVP 85 4.0 Extensible Authentication Protocol Support 86 4.1 Alternative Uses 87 4.2 Command-Codes Values 88 4.2.1 Diameter-EAP-Request (DER) Command 89 4.2.2 Diameter-EAP-Answer (DEA) Command 90 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 Framed Access 150 8.2 Non-Framed Access 151 8.3 Tunneling 152 9.0 Interactions with Resource Management 153 10.0 AVP Table 154 11.0 IANA Considerations 155 11.1 Request-Type AVP Values 156 12.0 Security Considerations 157 13.0 References 158 14.0 Acknowledgements 159 15.0 Authors' Addresses 160 16.0 Full Copyright Statement 162 1.0 Introduction 164 This document describes the Diameter extension that is used for AAA 165 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 166 extension, combined with the base protocol [2], satisfies the 167 requirements defined in the NASREQ AAA criteria specification [24] 168 and the ROAMOPS AAA Criteria specification [4]. 170 This document is divided into three main sections. The first section 171 defines the Diameter Command-Codes and AVPs that are needed to 172 support legacy authentication protocols, those that are typically 173 supported by RADIUS [1] servers. The second section defines the 174 Command-Codes and AVPs necessary for a Diameter node to support PPP's 175 Extensible Authentication Protocol (EAP) [25]. The third section 176 contains the Authorization AVPs that are needed for the various 177 services offered by a NAS, such as PPP dial-in, terminal server and 178 tunneling applications, such as L2TP [16]. 180 Given that it is expected that initial deployments of the Diameter 181 protocol in a dial-up environment will include legacy systems, this 182 extension was carefully designed to ease the burden of servers that 183 must perform protocol conversion between RADIUS and Diameter. This 184 is achieved by re-using the RADIUS address space, eliminating the 185 need to perform attribute lookups. 187 The value assigned for the Extension-Id [2] AVP is one (1). 189 1.1 Requirements language 191 In this document, the key words "MAY", "MUST", "MUST NOT", 192 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 193 interpreted as described in [12]. 195 2.0 Supported AVPs 197 This section lists all of the Diameter AVPs and the legacy RADIUS 198 attributes supported by this extension. 200 2.1 Diameter AVPs 202 This section will define all of the AVPs that are not backward 203 compatible with the RADIUS protocol [1]. A Diameter message that 204 includes one of these AVPs MAY cause interoperability issues should 205 the request traverse a AAA node that only supports the RADIUS 206 protocol. However, the Diameter protocol SHOULD NOT be hampered from 207 future developments due to the existing installed base. 209 The following table describes the Diameter AVPs defined in the NASREQ 210 extension, their AVP Code values, types, possible flag values and 211 whether the AVP MAY be encrypted. 213 +---------------------+ 214 | AVP Flag rules | 215 |----+-----+----+-----|----+ 216 AVP Section | | |SHLD| MUST|MAY | 217 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 218 -----------------------------------------|----+-----+----+-----|----| 219 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 220 Filter-Rule 400 2.1.2 OctetString| M | P | | V | Y | 221 Request-Type 401 2.1.1 Unsigned32 | M | P | | V | N | 222 Tunneling 403 7.4 Grouped | M | P | | V | N | 224 2.1.1 Request-Type AVP 226 The Request-Type AVP (AVP Code 401) is of type Unsigned32 and is used 227 to determine the type of request being transmitted. Note that a 228 request with this AVP set to a value other than 229 AUTHORIZE_AUTHENTICATE MAY break backward RADIUS compatibility. The 230 following values are defined: 232 AUTHENTICATE_ONLY 1 233 The request being sent is for authentication only, and MUST 234 contain the relevant authentication AVPs that are needed by the 235 Diameter server to authenticate the user. 237 AUTHORIZE_ONLY 2 238 The request being sent is for authorization only, and MUST 239 contain the authorization AVPs that are necessary to identify 240 the service being requested/offered. 242 AUTHORIZE_AUTHENTICATE 3 243 The request contains a request for both authentication and 244 authorization. The request MUST include both the relevant 245 authentication information, and authorization information 246 necessary to identify the service being requested/offered. 248 2.1.2 Filter-Rule AVP 250 The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in 251 the UTF-8 [25] format, and provides filter rules that need to be 252 configured on the NAS for the user. One or more such AVPs MAY be 253 present in an authorization response. 255 Each packet can be filtered based on the following information that 256 is associated with it: 258 Direction (in or out) 259 Source and destination IP address (possibly masked) 260 Protocol 261 Source and destination port (lists or ranges) 262 TCP flags 263 IP fragment flag 264 IP options 265 ICMP types 267 Rules for the appropriate direction are evaluated in order, with the 268 first matched rule terminating the evaluation. Each packet is 269 evaluated once. If no rule matches, the packet is dropped if the last 270 rule evaluated was a permit, and passed if the last rule was a deny. 272 The filters in the Filter-Rule AVP MUST follow the format: 274 action dir proto from src to dst [options] 276 action permit - Allow packets that match the rule. 277 deny - Drop packets that match the rule. 279 dir "in" is from the terminal, "out" is to the terminal. 281 proto An IP protocol specified by number. The "ip" keyword 282 means any protocol will match. 284 src and dst
[ports] 286 The
may be specified as: 287 ipno An IPv4 or IPv6 number in dotted-quad or 288 canonical IPv6 form. Only this exact IP 289 number will match the rule. 290 ipno/bits An IP number as above with a mask width of 291 the form 1.2.3.4/24. In this case all IP 292 numbers from 1.2.3.0 to 1.2.3.255 will 293 match. The bit width MUST be valid for 294 the IP version and the IP number MUST NOT 295 have bits set beyond the mask. 297 The sense of the match can be inverted by preceding 298 an address with the not modifier, causing all other 299 addresses to be matched instead. This does not 300 affect the selection of port numbers. 302 The keyword "any" is 0.0.0.0/0 or the IPv6 303 equivalent. The keyword "assigned" is the address 304 or set of addresses assigned to the terminal. The 305 first rule SHOULD be "deny in ip !assigned". 307 With the TCP and UDP protocols, optional ports may be 308 specified as: 310 {port|port-port}[,port[,...]] 312 The `-' notation specifies a range of ports 313 (including boundaries). 315 Fragmented packets which have a non-zero offset (i.e. 316 not the first fragment) will never match a rule which 317 has one or more port specifications. See the frag 318 option for details on matching fragmented packets. 320 options: 321 frag Match if the packet is a fragment and this is not the 322 first fragment of the datagram. frag may not be used 323 in conjunction with either tcpflags or TCP/UDP port 324 specifications. 326 ipoptions spec 327 Match if the IP header contains the comma separated 328 list of options specified in spec. The supported IP 329 options are: 331 ssrr (strict source route), lsrr (loose source route), 332 rr (record packet route) and ts (timestamp). The 333 absence of a particular option may be denoted with a 334 `!'. 336 tcpoptions spec 337 Match if the TCP header contains the comma separated 338 list of options specified in spec. The supported TCP 339 options are: 341 mss (maximum segment size), window (tcp window 342 advertisement), sack (selective ack), ts (rfc1323 343 timestamp) and cc (rfc1644 t/tcp connection count). 344 The absence of a particular option may be denoted with 345 a `!'. 347 established 348 TCP packets only. Match packets that have the RST or 349 ACK bits set. 351 setup TCP packets only. Match packets that have the SYN bit 352 set but no ACK bit. 354 tcpflags spec 355 TCP packets only. Match if the TCP header contains the 356 comma separated list of flags specified in spec. The 357 supported TCP flags are: 359 fin, syn, rst, psh, ack and urg. The absence of a 360 particular flag may be denoted with a `!'. A rule which 361 contains a tcpflags specification can never match a 362 fragmented packet which has a non-zero offset. See the 363 frag option for details on matching fragmented packets. 365 icmptypes types 366 ICMP packets only. Match if the ICMP type is in the 367 list types. The list may be specified as any 368 combination of ranges or individual types separated by 369 commas. The supported ICMP types are: 371 echo reply (0), destination unreachable (3), source 372 quench (4), redirect (5), echo request (8), router 373 advertisement (9), router solicitation (10), time-to- 374 live exceeded (11), IP header bad (12), timestamp 375 request (13), timestamp reply (14), information request 376 (15), information reply (16), address mask request (17) 377 and address mask reply (18). 379 There is one kind of packet that the NAS MUST always discard, that is 380 an IP fragment with a fragment offset of one. This is a valid 381 packet, but it only has one use, to try to circumvent firewalls. 383 A NAS that is unable to interpret or apply a deny rule MUST 384 terminate the session. A NAS that is unable to interpret or apply 385 a permit rule MAY apply a more restrictive rule. A NAS MAY apply 386 deny rules of its own before the supplied rules, for example to 387 protect the NAS owner's infrastructure. 389 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 390 ipfw.c code may provide a useful base for implementations. 392 2.2 Legacy RADIUS Attributes 394 The Diameter protocol reserves the first 255 AVP identifiers for 395 "legacy RADIUS" support. The following table contains the RADIUS 396 attributes supported by this Diameter extension, their AVP code 397 values, types, possible flag values and whether the AVP MAY be 398 encrypted. RADIUS attributes not listed are not supported by the 399 Diameter protocol. 401 +---------------------+ 402 | AVP Flag rules | 403 |----+-----+----+-----|----+ 404 AVP Section | | |SHLD| MUST|MAY | 405 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 406 -----------------------------------------|----+-----+----+-----|----| 407 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 408 Response | | | | | | 409 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 410 ARAP-Password 70 3.1.1.4 OctetString| M | P | | V | Y | 411 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 412 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 413 Data | | | | | | 414 ARAP-Zone-Access 72 7.2.8.2 Unsigned32 | M | P | | V | Y | 415 Callback-Id 20 6.4 OctetString| M | P | | V | Y | 416 Callback-Number 19 6.3 OctetString| M | P | | V | Y | 417 Called-Station-Id 30 6.6 OctetString| M | P | | V | Y | 418 Calling-Station- 31 6.7 OctetString| M | P | | V | Y | 419 Id | | | | | | 420 CHAP-Challenge 60 3.1.1.3 OctetString| M | P | | V | Y | 421 CHAP-Password 3 3.1.1.2 OctetString| M | P | | V | Y | 422 Class 25 2.2.4 OctetString| M | P | | V | Y | 423 Connect-Info 77 6.10 OctetString| M | P | | V | Y | 424 Filter-Id 11 6.2 OctetString| M | P | | V | Y | 425 +---------------------+ 426 | AVP Flag rules | 427 |----+-----+----+-----|----+ 428 AVP Section | | |SHLD| MUST|MAY | 429 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 430 -----------------------------------------|----+-----+----+-----|----| 431 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 432 Link | | | | | | 433 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 434 Network | | | | | | 435 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 436 Zone | | | | | | 437 Framed-Protocol 7 7.2.1 Unsigned32 | M | P | | V | Y | 438 Framed-IP-Address 8 7.2.5.1 Address | M | P | | V | Y | 439 Framed- 13 7.2.4 Unsigned32 | M | P | | V | Y | 440 Compression | | | | | | 441 Framed-IP-Netmask 9 7.2.5.2 Address | M | P | | V | Y | 442 Framed-IP-Route 22 7.2.5.3 OctetString| M | P | | V | Y | 443 Framed-IPX-Route 23 7.2.6.1 OctetString| M | P | | V | Y | 444 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 445 Framed-Routing 10 7.2.2 Unsigned32 | M | P | | V | Y | 446 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 447 Login-IP-Host 14 7.3.1 Address | M | P | | V | Y | 448 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 449 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 450 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 451 Login-LAT-Service 34 7.3.4.1 Unsigned32 | M | P | | V | Y | 452 Login-Service 15 7.3.2 Unsigned32 | M | P | | V | Y | 453 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 454 NAS-Identifier 32 2.2.2 OctetString| M | P | | V | Y | 455 NAS-IP-Address 4 2.2.1 Address | M | P | | V | Y | 456 NAS-Port 5 6.1.1 Unsigned32 | M | P | | V | Y | 457 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 458 Password-Retry 75 3.1.2.2 Unsigned32 | M | P | | V | Y | 459 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 460 Prompt 76 3.1.3.1 Unsigned32 | M | P | | V | Y | 461 Reply-Message 18 3.2 OctetString| M | P | | V | Y | 462 Service-Type 6 7.1 Unsigned32 | M | P | | V | Y | 463 State 24 2.2.3 OctetString| M | P | | V | Y | 464 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 465 Assignment-Id | | | | | | 466 Tunnel-Client- 90 7.4.9 OctetString| M | P | | V | Y | 467 Auth-ID | | | | | | 468 Tunnel-Client- 66 7.4.3 OctetString| M | P | | V | Y | 469 Endpoint | | | | | | 470 +---------------------+ 471 | AVP Flag rules | 472 |----+-----+----+-----|----+ 473 AVP Section | | |SHLD| MUST|MAY | 474 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 475 -----------------------------------------|----+-----+----+-----|----| 476 Tunnel-Medium- 65 7.4.2 Unsigned32 | M | P | | V | Y | 477 Type | | | | | | 478 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 479 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 480 Tunnel-Private- 81 7.4.6 OctetString| M | P | | V | Y | 481 Group-ID | | | | | | 482 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 483 Auth-ID | | | | | | 484 Tunnel-Server- 67 7.4.4 OctetString| M | P | | V | Y | 485 Endpoint | | | | | | 486 Tunnel-Type 64 7.4.1 Unsigned32 | M | P | | V | Y | 487 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 489 The AVPs defined in this section SHOULD only used when a 490 Diameter/RADIUS gateway function is invoked, and are not used in the 491 Diameter protocol. 493 2.2.1 NAS-IP-Address AVP 495 The NAS-IP-Address AVP (AVP Code 4) [1] is of type Address, and 496 contains the IP Address of the NAS providing service to the user. 497 When this AVP is present, the Origin-FQDN AVP DOES NOT represent the 498 NAS providing service to the user. Note that this AVP SHOULD only 499 added by a RADIUS/Diameter protocol gateway [28]. 501 2.2.2 NAS-Identifier AVP 503 The NAS-Identifier AVP (AVP Code 32) [1] is of type OctetString, 504 encoded in the UTF-8 [25] format, and contains the Identity of the 505 NAS providing service to the user. When this AVP is present, the 506 Origin-FQDN AVP DOES NOT represent the NAS providing service to the 507 user. Note that this AVP SHOULD only added by a RADIUS/Diameter 508 protocol gateway [28]. 510 2.2.3 State AVP 512 The State AVP (AVP Code 24) is of type OctetString and is used to 513 transmit the contents of the RADIUS State attribute, and no 514 interpretation of the contents should be made. Note that this AVP 515 SHOULD only added by a RADIUS/Diameter protocol gateway [28]. 517 2.2.4 Class AVP 519 The Class AVP (AVP Code 25) is of type OctetString and is used to 520 transmit the contents of the RADIUS Class attribute, and no 521 interpretation of the contents should be made. Note that this AVP 522 SHOULD only added by a RADIUS/Diameter protocol gateway [28]. 524 3.0 Legacy RADIUS Authentication Support 526 This section defines the new Command-Code [2] values required to 527 support the legacy authentication protocols (i.e. PAP, CHAP), as well 528 as the AVPs that are necessary to carry the authentication 529 information in the Diameter protocol. The functionality defined here 530 provides a RADIUS-like AAA service, over a more reliable and secure 531 transport, as defined in the base protocol [2]. 533 Unlike the RADIUS protocol [1], the Diameter protocol does not 534 require authentication information to be contained in a request from 535 the client. Therefore, it is possible to send a request for 536 authorization only. The type of service depends upon the Request-Type 537 AVP. This difference MAY cause operational issues in environments 538 that need RADIUS interoperability, and it MAY be necessary that 539 protocol conversion gateways add some authentication information when 540 transmitting to a RADIUS server. 542 The Diameter protocol allows for users to be periodically re- 543 authenticated and/or re-authorized. In such instances, the Session-Id 544 AVP in the AAR message MUST be the same as the one present in the 545 original authentication/authorization message. A Diameter server 546 informs the NAS of the authorized session lifetime via the Session- 547 Timeout AVP [1]. 549 A NAS MUST re-authenticate and/or authorize after the period provided 550 by the server. Furthermore, it is possible for Diameter servers to 551 issue an unsolicited re-authentication and/or re-authorization by 552 issuing an AA-Challenge-Ind message to the NAS. Upon receipt of such 553 a message, the NAS is instructed to issue a request to re- 554 authenticate and/or re-authorize the client. 556 3.1 Command-Codes Values 558 This section defines new Command-Code [2] values that MUST be 559 supported by all Diameter implementations that conform to this 560 specification. The following Command Codes are defined in this 561 section: 563 Command-Name Abbrev. Code Reference 564 -------------------------------------------------------- 565 AA-Answer AAA 266 3.1.2 566 AA-Challenge-Ind ACI 267 3.1.3 567 AA-Request AAR 265 3.1.1 569 3.1.1 AA-Request (AAR) Command 571 The AA-Request message (AAR), indicated by the Command-Code field set 572 to 265, is used in order to request authentication and/or 573 authorization for a given PPP user. The type of request is identified 574 through the Request-Type AVP, and the default mode is both 575 authentication and authorization. 577 If Authentication is requested the User-Name attribute SHOULD be 578 present, as well as any additional authentication AVPs that would 579 carry the password information. A request for authorization only 580 SHOULD include the information from which the authorization will be 581 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 582 networks MAY use different AVPs for authorization purposes. A request 583 for authorization will include some AVPs defined in sections 2.0, 6.0 584 and 7.0. 586 It is possible for a single session to be authorized only first, then 587 followed by an authentication request. However, the inverse SHOULD 588 NOT be permitted. 590 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 591 MUST be identical as the one provided in the initial AA-Request for 592 the same session. If the AA-Request is a result of an AA-Challenge- 593 Ind that included a State AVP, the same AVP MUST be present in the 594 following AA-Request. 596 Message Format 597 ::= < Diameter Header: 265 > 598 < Session-Id > 599 { Extension-Id } 600 { Origin-FQDN } 601 { Origin-Realm } 602 { Destination-Realm } 603 [ NAS-Identifier ] 604 [ User-Name ] 605 [ User-Password ] 606 [ ARAP-Password ] 607 [ CHAP-Password ] 608 [ CHAP-Challenge ] 609 [ State ] 610 * [ AVP ] 611 * [ Proxy-State ] 612 * [ Route-Record ] 613 0*1< Integrity-Check-Value > 615 3.1.1.1 User-Password AVP 617 The User-Password AVP (AVP Code 2) is of type OctetString and 618 contains the password of the user to be authenticated, or the user's 619 input following an AA-Challenge-Ind. 621 This AVP MUST be encrypted using one of the methods described in [2] 622 or [13]. Unless this AVP is used for one-time passwords, the User- 623 Password AVP SHOULD NOT be used in non-trusted proxy environments. 625 The clear-text password (prior to encryption) MUST NOT be longer than 626 128 bytes in length. 628 3.1.1.2 CHAP-Password AVP 630 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 631 the response value provided by a PPP Challenge-Handshake 632 Authentication Protocol (CHAP) [6] user in response to the challenge. 634 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 635 AVP (see section 3.1.1.3) MUST be present as well. 637 0 1 2 3 638 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 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 AVP Header (AVP Code = 3) 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | CHAP Ident | Data ... 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 The CHAP Ident field contains the one octet CHAP Identifier from the 646 user's CHAP response [6]. The Data field is 16 octets, and contains 647 the CHAP Response from the user. The actual computation of the CHAP 648 response can be found in [6]. 650 3.1.1.3 CHAP-Challenge AVP 652 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 653 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 654 Handshake Authentication Protocol (CHAP) [6] user. 656 3.1.1.4 ARAP-Password AVP 658 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 659 only present when the Framed-Protocol AVP (see Section 7.2.1) is 660 included in the message and is set to ARAP. This AVP MUST NOT be 661 present if the User-Password or CHAP-Password AVPs are present. See 662 [32] for more information on the contents of this AVP. 664 3.1.2 AA-Answer (AAA) Command 666 The AA-Answer (AAA) message, indicated by the Command-Code field set 667 to 266, is sent in response to the AA-Request message. If 668 authorization was requested, a successful response will include the 669 authorization AVPs appropriate for the service being provided, as 670 defined in section 2.0, 6.0 and 7.0 672 Message Format 673 ::= < Diameter Header: 266 > 674 < Session-Id > 675 { Extension-Id } 676 { Result-Code } 677 { Destination-Realm } 678 { Origin-FQDN } 679 { Origin-Realm } 680 [ User-Name ] 681 [ Error-Reporting-FQDN ] 682 * [ AVP ] 683 * [ Proxy-State ] 684 * [ Route-Record ] 685 0*1< Integrity-Check-Value > 687 3.1.2.1 ARAP-Challenge-Response AVP 689 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 690 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 691 is included in the message and is set to ARAP. This AVP contains an 8 692 octet response to the dial-in client's challenge. The RADIUS server 693 calculates this value by taking the dial-in client's challenge from 694 the high order 8 octets of the ARAP-Password AVP and performing DES 695 encryption on this value with the authenticating user's password as 696 the key. If the user's password is less than 8 octets in length, the 697 password is padded at the end with NULL octets to a length of 8 698 before using it as a key. 700 3.1.2.2 Password-Retry AVP 702 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 703 included in the AA-Answer if the Result-Code indicates an 704 authentication failure. The value of this AVP indicates how many 705 authentication attempts a user may be permitted before being 706 disconnected. This AVP is primarily intended for use when the 707 Framed-Protocol AVP (see Section 7.2.1) is set to ARAP. 709 3.1.3 AA-Challenge-Ind (ACI) Command 711 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 712 field set to 267, is sent by a Diameter Home server to issue a 713 challenge requiring a response to a dial-up user. The message MAY 714 have one or more Reply-Message AVP, the User-Name AVP and it MAY have 715 zero or one State AVP. No other AVPs are permitted in an AA- 716 Challenge-Ind other than security related AVPs [2, 13]. 718 On receipt of an AA-Challenge-Ind, the Identifier field is matched 719 with a pending AA-Request. Invalid messages are silently discarded. 721 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 722 Request SHOULD be sent. The NAS MAY display the text message, if any, 723 to the user, and then prompt the user for a response. It then sends 724 its original AA-Request with a new request ID, with the User-Password 725 AVP replaced by the user's response (encrypted), and including the 726 State AVP from the AA-Challenge-Ind, if any. 728 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 729 client and accept a PAP response which it can use as though the user 730 had entered the response. If the NAS cannot do so, it should treat 731 the AA-Challenge-Ind as though it had received an AA-Answer with a 732 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 734 When possible, authentication mechanisms that include more than a 735 single authentication round trip SHOULD use EAP (see section 4.0) 736 instead of the AA-Challenge-Ind. This command has been maintained for 737 RADIUS backward compatibility. 739 AA-Challenge-Ind ::= < Diameter Header: 267 > 740 < Session-Id > 741 { Extension-Id } 742 { Result-Code } 743 { Destination-Realm } 744 { Destination-FQDN } 745 { Origin-FQDN } 746 { Origin-Realm } 747 [ User-Name ] 748 [ Error-Reporting-FQDN ] 749 [ State ] 750 * [ AVP ] 751 * [ Reply-Message ] 752 * [ Proxy-State ] 753 * [ Route-Record ] 754 0*1< Integrity-Check-Value > 756 3.1.3.1 Prompt AVP 758 The Prompt AVP (AVP Code 76) is of type Unsigned32, and MAY be 759 present in the AA-Challenge-Ind message. When present, it is used by 760 the NAS to determine whether the user's response, when entered, 761 should be echoed. The following values are defined: 762 0 No Echo 763 1 Echo 765 3.2 Reply-Message AVP 767 The Reply-Message AVP (AVP Code 18) is of type OctetString, encoded 768 in the UTF-8 [25] format, and contains text which MAY be displayed to 769 the user. When used in an AA-Answer message with a successful 770 Result-Code AVP it indicates the success message. When found in the 771 same message with a Result-Code other than Diameter-SUCCESS it 772 contains the failure message. 774 The Reply-Message AVP MAY indicate a dialog message to prompt the 775 user before another AA-Request attempt. When used in an AA- 776 Challenge-Ind, it MAY indicate a dialog message to prompt the user 777 for a response. 779 Multiple Reply-Message's MAY be included and if any are displayed, 780 they MUST be displayed in the same order as they appear in the 781 message. 783 4.0 Extensible Authentication Protocol Support 785 The Extensible Authentication Protocol (EAP), described in [25], 786 provides a standard mechanism for support of additional 787 authentication methods within PPP. Through the use of EAP, support 788 for a number of authentication schemes may be added, including smart 789 and token cards, Kerberos, Public Key, One Time Passwords, and 790 others. 792 This section describes the Command-Codes values and AVPs that are 793 required for an EAP payload to be encapsulated within the Diameter 794 protocol. Since authentication occurs between the PPP client and its 795 home Diameter server, end-to-end authentication is achieved, reducing 796 the possibility for fraudulent authentication, such as replay and 797 man-in-the-middle attacks. End-to-end authentication also provides 798 for mutual (bi-directional) authentication, which is not possible 799 with PAP and CHAP in a roaming environment. 801 The Diameter/EAP extension allows a home Diameter server to initiate 802 an unsolicited authentication request to the user. This allows the 803 home server to periodically ensure that the user is still active, 804 which is useful when a server requires re-authentication to extend 805 the "life" of a session [26]. Server-initiated authentication can 806 reduce the number of protocol exchanges over the Internet. 808 The EAP conversation between the authenticating peer and the NAS 809 begins with the negotiation of EAP within LCP. Once EAP has been 810 negotiated, the NAS will typically send to the Diameter server a 811 Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying 812 an EAP-Start. The Port number and NAS Identifier MUST be included in 813 the AVPs issued by the NAS in the Diameter-EAP-Request packet. 815 If the Diameter home server supports EAP, it MUST respond with a 816 Diameter-EAP-Ind message containing an EAP-Payload AVP that includes 817 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 818 NAS to the PPP client. The initial Diameter-EAP-Ind normally includes 819 an EAP-Request/Identity, requesting the PPP client to identify 820 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 821 will then issue a second Diameter-EAP-Request message, with the 822 client's EAP payload encapsulated within the EAP-Payload AVP. The 823 conversation continues until the Diameter server sends a Diameter- 824 EAP-Answer with a Result-Code AVP indicating success or failure. A 825 Result-Code AVP containing a failure indication SHOULD also include 826 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 827 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 828 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 829 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 830 successfully terminate the PPP authentication phase. If authorization 831 was requested, a successful Diameter-EAP-Answer MUST also include the 832 appropriate authorization AVPs required for the service requested 833 (see sections 2.0, 6.0 and 7.0). 835 The above scenario creates a situation in which the NAS never needs 836 to manipulate an EAP packet. An alternative may be used in situations 837 where an EAP-Request/Identity message will always be sent by the NAS 838 to the authenticating peer. This involves having the NAS send an 839 EAP-Request/Identity message to the PPP client, and forwarding the 840 EAP-Response/Identity packet to the Diameter server in the EAP- 841 Payload AVP of a Diameter-EAP-Request packet. While this approach 842 will save a round-trip, it cannot be universally employed. There are 843 circumstances in which the user's identity may not be needed (such as 844 when authentication and accounting is handled based on the calling or 845 called phone number), and therefore an EAP-Request/Identity packet 846 may not necessarily be issued by the NAS to the authenticating peer. 848 Unless the NAS interprets the EAP-Response/Identity packet returned 849 by the authenticating peer, it will not have access to the user's 850 identity. Therefore, the Diameter Server SHOULD return the user's 851 identity by inserting it in the User-Name attribute of subsequent 852 Diameter-EAP-Answer packets. Without the user's identity, the 853 Session-Id AVP MAY be used for accounting and billing, however 854 operationally this MAY be very difficult to manage. 856 The Diameter-EAP-Ind message MAY be sent by a Diameter server in 857 order to initiate an unsolicited authentication of the PPP user, as 858 described in [26]. This functionality allows a home Diameter server 859 to easily extend the "life" of a session for a particular service, 860 while reducing the total number of authentication round-trips, should 861 the NAS initiate the periodic authentication. 863 Should an EAP authentication session be interrupted due to a home 864 server failure, the session MAY be directed to an alternate server, 865 but the authentication session will have to be restarted from the 866 beginning. 868 When Diameter is used in a roaming environment, the NAS SHOULD issue 869 the EAP-Request/Identity request to the PPP client, and forward the 870 EAP-Response in the initial Diameter-EAP-Request message. This allows 871 any Diameter proxies or brokers to identify the user, and forward the 872 message to the appropriate home server. If a response is received 873 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 874 an indication that a Diameter server in the proxy chain does not 875 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 876 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 877 cautious when determining whether a less secure authentication 878 protocol will be used, since this could be a result of a bidding down 879 attack. See [28] for additional information. 881 4.1 Alternative uses 883 Currently the conversation between the backend authentication server 884 and the Diameter server is proprietary because of lack of 885 standardization. In order to increase standardization and provide 886 interoperability between Diameter vendors and backend security 887 vendors, it is recommended that Diameter-encapsulated EAP be used for 888 this conversation. 890 This has the advantage of allowing the Diameter server to support EAP 891 without the need for authentication-specific code within the Diameter 892 server. Authentication-specific code can then reside on a backend 893 authentication server instead. 895 In the case where Diameter-encapsulated EAP is used in a conversation 896 between a Diameter server and a backend authentication server, the 897 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 898 Success message without inclusion of the expected authorization AVPs 899 required in a successful response. This means that the Diameter 900 server MUST add these attributes prior to sending an Diameter-EAP- 901 Answer/EAP-Payload/EAP-Success message to the NAS. 903 4.2 Command-Codes Values 905 This section defines new Command-Code [2] values that MUST be 906 supported by all Diameter implementations conforming to this 907 specification. The following Command Codes are defined in this 908 section: 910 Command-Name Abbrev. Code Reference 911 -------------------------------------------------------- 912 Diameter-EAP-Answer DEA 269 4.2.2 913 Diameter-EAP-Ind DEI 270 4.2.3 914 Diameter-EAP-Request DER 268 4.2.1 916 4.2.1 Diameter-EAP-Request (DER) Command 918 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 919 field set to 268, is sent by a Diameter client to a Diameter server 920 and conveys an EAP-Response [25] from the dial-up PPP client. The 921 Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains 922 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent 923 to the Diameter server to initiate an EAP authentication session. 925 Upon receipt of a Diameter-EAP-Request, a Diameter server MUST issue 926 a reply. The reply may be either: 928 1) a Diameter-EAP-Ind containing an EAP-Request encapsulated 929 within an EAP-Payload attribute 930 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 931 within an EAP-Payload and a Result-Code indicating success. 932 3) a Diameter-EAP-Answer containing an EAP-Failure encapsulated 933 within an EAP-Payload and a Result-Code indicating failure. 934 4) A Message-Reject-Ind packet with a Result-Code set to 935 DIAMETER_COMMAND_UNSUPPORTED if a Diameter server does not 936 support the EAP extension. 938 Message Format 939 ::= < Diameter Header: 268 > 940 < Session-Id > 941 { Extension-Id } 942 { Origin-FQDN } 943 { Origin-Realm } 944 { Destination-Realm } 945 { EAP-Payload } 946 [ User-Name ] 947 [ NAS-IP-Address ] 948 [ NAS-Identifier ] 949 [ State ] 950 * [ AVP ] 951 * [ Proxy-State ] 952 * [ Route-Record ] 953 0*1< Integrity-Check-Value > 955 4.2.2 Diameter-EAP-Answer (DEA) Command 957 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 958 field set to 269, is sent by the Diameter server to the client to 959 indicate either a successful or failed authentication. The Diameter- 960 EAP-Answer message SHOULD include an EAP payload of type EAP-Success 961 or EAP-Failure encapsulated within an EAP-Payload AVP. The Result- 962 Code AVP MUST indicate a failure if the EAP-Failure payload is 963 present, while the AVP MUST indicate success if the EAP-Success 964 payload is present. 966 If the message from the Diameter client included a request for 967 authorization, a successful response MUST include the authorization 968 AVPs that are relevant to the service being provided. 970 Message Format 972 ::= < Diameter Header: 269 > 973 < Session-Id > 974 { Extension-Id } 975 { Result-Code } 976 { Origin-FQDN } 977 { Origin-Realm } 978 { Destination-Realm } 979 [ Error-Reporting-FQDN ] 980 [ EAP-Payload ] 981 [ User-Name ] 982 * [ AVP ] 983 * [ Proxy-State ] 984 * [ Route-Record ] 985 0*1< Integrity-Check-Value > 987 4.2.3 Diameter-EAP-Ind (DEI) Command 989 The Diameter-EAP-Ind (DEI) command, indicated by the Command-Code set 990 to 270, has two uses. This message MAY be sent in response to a 991 Diameter-EAP-Request message, and MUST contain an EAP-Response 992 payload [25] encapsulated within an EAP-Payload AVP. 994 Alternatively, this message MAY also be sent unsolicited from a 995 Diameter server to a client to request re-authentication of a PPP 996 client. For re-authentication, it is recommended that the Identity 997 request be skipped in order to reduce the number of authentication 998 round trips. This is only possible when the user's identity is 999 already known by the home Diameter server. 1001 Upon receipt of the message, the NAS MUST issue the EAP payload to 1002 the PPP Client, and SHOULD respond with a Diameter-EAP-Request 1003 containing the EAP-Response [25] packet. 1005 Message Format 1007 ::= 1008 < Session-Id > 1009 { Extension-Id } 1010 { Destination-FQDN } 1011 { Destination-Realm } 1012 { Origin-FQDN } 1013 { Origin-Realm } 1014 { EAP-Payload } 1015 [ User-Name ] 1016 * [ AVP ] 1017 * [ Proxy-State ] 1018 * [ Route-Record ] 1019 0*1< Integrity-Check-Value > 1021 4.3 EAP-Payload AVP 1023 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1024 to encapsulate the actual EAP payload [25] that is being exchanged 1025 between the dial-up PPP client and the home Diameter server. 1027 5.0 Diameter Session Termination 1029 When a Network Access Server (NAS) receives an indication that a 1030 user's session is being disconnected (e.g. LCP Terminate is 1031 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1032 to its Diameter Server. This will ensure that any resources 1033 maintained on the servers is freed appropriately. 1035 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 1036 disconnect the PPP (or tunneling) session and respond with an STR 1037 message. 1039 6.0 Call and Session Information 1041 This section contains the authorization AVPs that are needed to 1042 identify call and session information, and allows the server to set 1043 constraints on a session. 1045 6.1 NAS-Port AVP 1047 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1048 physical port number of the NAS which is authenticating the user, and 1049 is normally only present in an authentication and/or authorization 1050 request. Note that this is using "port" in its sense of a physical 1051 connection on the NAS, not in the sense of a TCP or UDP port number. 1052 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1053 present in the request, if the NAS differentiates among its ports. 1055 6.2 Filter-Id AVP 1057 The Filter-Id AVP (AVP Code 11) is of type OctetString, encoded in 1058 the UTF-8 [25] format, and contains the name of the filter list for 1059 this user. Zero or more Filter-Id AVPs MAY be sent in an 1060 authorization response. 1062 Identifying a filter list by name allows the filter to be used on 1063 different NASes without regard to filter-list implementation details. 1064 However, this AVP is not roaming friendly since filter naming differs 1065 from one service provider to another. 1067 In non-RADIUS environments, it is strongly recommended that the 1068 Filter-Rule AVP be used instead. 1070 6.3 Callback-Number AVP 1072 The Callback-Number AVP (AVP Code 19) is of type OctetString, encoded 1073 in the UTF-8 [25] format, and contains a dialing string to be used 1074 for callback. It MAY be used in an authentication and/or 1075 authorization request as a hint to the server that a Callback service 1076 is desired, but the server is not required to honor the hint in the 1077 corresponding response. 1079 The codification of the range of allowed usage of this field is 1080 outside the scope of this specification. 1082 6.4 Callback-Id AVP 1084 The Callback-Id AVP (AVP Code 20) is of type OctetString, encoded in 1085 the UTF-8 [25] format, and contains the name of a place to be called, 1086 to be interpreted by the NAS. This AVP MAY be present in an 1087 authentication and/or authorization response. 1089 This AVP is not roaming friendly since it assumes that the Callback- 1090 Id is configured on the NAS. It is therefore preferable to use the 1091 Callback-Number AVP instead. 1093 6.5 Idle-Timeout AVP 1095 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1096 maximum number of consecutive seconds of idle connection allowed to 1097 the user before termination of the session or prompt. It MAY be used 1098 in an authentication and/or authorization request (or challenge) as a 1099 hint to the server that an idle timeout is desired, but the server is 1100 not required to honor the hint in the corresponding response. 1102 6.6 Called-Station-Id AVP 1104 The Called-Station-Id AVP (AVP Code 30) is of type OctetString, 1105 encoded in the UTF-8 [25] format, and allows the NAS to send in the 1106 request the phone number that the user called, using Dialed Number 1107 Identification (DNIS) or a similar technology. Note that this may be 1108 different from the phone number the call comes in on. It SHOULD only 1109 be present in authentication and/or authorization requests. 1111 If the Request-Type AVP is set to authorization-only and the User- 1112 Name AVP is absent, the Diameter Server MAY perform authorization 1113 based on this field. This can be used by a NAS to request whether a 1114 call should be answered based on the DNIS. 1116 The codification of the range of allowed usage of this field is 1117 outside the scope of this specification. 1119 6.7 Calling-Station-Id AVP 1120 The Calling-Station-Id AVP (AVP Code 31) is of type OctetString, 1121 encoded in the UTF-8 [25] format, and allows the NAS to send in the 1122 request the phone number that the call came from, using Automatic 1123 Number Identification (ANI) or a similar technology. It SHOULD only 1124 be present in authentication and/or authorization requests. 1126 If the Request-Type AVP is set to authorization-only and the User- 1127 Name AVP is absent, the Diameter Server MAY perform authorization 1128 based on this field. This can be used by a NAS to request whether a 1129 call should be answered based on the ANI. 1131 The codification of the range of allowed usage of this field is 1132 outside the scope of this specification. 1134 6.8 NAS-Port-Type AVP 1136 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1137 contains the type of the physical port of the NAS which is 1138 authenticating the user. It can be used instead of or in addition to 1139 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1140 and/or authorization requests. This AVP MAY be combined with the 1141 NAS-Port AVP to assist in differentiating its ports. 1143 The following values are defined: 1144 0 Async 1145 1 Sync 1146 2 ISDN Sync 1147 3 ISDN Async V.120 1148 4 ISDN Async V.110 1149 5 Virtual 1150 6 PIAFS 1151 7 HDLC Clear Channel 1152 8 X.25 1153 9 X.75 1154 10 G.3 Fax 1155 11 SDSL - Symmetric DSL 1156 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude 1157 Phase Modulation 1158 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 1159 14 IDSL - ISDN Digital Subscriber Line 1160 15 Ethernet 1161 16 xDSL 1162 17 Cable 1163 18 Wireless - Other 1164 19 Wireless - IEEE 802.11 1166 "Virtual" refers to a connection to the NAS via some transport 1167 protocol, instead of through a physical port. For example, if a user 1168 telnetted into a NAS to authenticate himself as an Outbound-User, the 1169 request might include NAS-Port-Type = Virtual as a hint to the 1170 Diameter server that the user was not on a physical port. 1172 6.9 Port-Limit AVP 1174 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1175 maximum number of ports to be provided to the user by the NAS. It 1176 MAY be used in an authentication and/or authorization request as a 1177 hint to the server that multilink PPP [9] service is desired, but the 1178 server is not required to honor the hint in the corresponding 1179 response. 1181 6.10 Connect-Info AVP 1183 The Connect-Info AVP (AVP Code 77) is of type OctetString and is sent 1184 in the AA-Request message, and indicates the nature of the user's 1185 connection. The value consists of UTF-8 encoded 10646 characters. 1186 The connection speed SHOULD be included at the beginning of the first 1187 Connect-Info AVP in the message. If the transmit and receive 1188 connection speeds differ, they may both be included in the first AVP 1189 with the transmit speed first (the speed the NAS modem transmits at), 1190 a slash (/), the receive speed, then optionally other information. 1192 7.0 Service Specific Authorization AVPs 1194 This section contains the RADIUS authorization AVPs that are 1195 supported in the Diameter protocol. The Service-Type AVP MUST be 1196 present in all messages, and based on the value of the Service-Type 1197 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1198 present. 1200 7.1 Service-Type AVP 1202 The Service-Type AVP (AVP Code 6) is of type Unsigned32 and contains 1203 the type of service the user has requested, or the type of service to 1204 be provided. One such AVP MAY be present in an authentication and/or 1205 authorization request or response. A NAS is not required to implement 1206 all of these service types, and MUST treat unknown or unsupported 1207 Service-Types as though a response with a Result-Code other than 1208 Diameter-SUCCESS had been received instead. 1210 When used in a request, the Service-Type AVP SHOULD be considered to 1211 be a hint to the server that the NAS has reason to believe the user 1212 would prefer the kind of service indicated, but the server is not 1213 required to honor the hint. The following values have been defined 1214 for the Service-Type AVP: 1216 Login 1 1217 The user should be connected to a host. The message MAY include 1218 additional AVPs defined in section 7.3. 1220 Framed 2 1221 A Framed Protocol should be started for the User, such as PPP or 1222 SLIP. The message MAY include additional AVPs defined in section 1223 7.2, or 7.4 for tunneling services. 1225 Callback Login 3 1226 The user should be disconnected and called back, then connected to 1227 a host. The message MAY include additional AVPs defined in section 1228 7.3. 1230 Callback Framed 4 1231 The user should be disconnected and called back, then a Framed 1232 Protocol should be started for the User, such as PPP or SLIP. The 1233 message MAY include additional AVPs defined in section 7.2, or 7.4 1234 for tunneling services. 1236 Outbound 5 1237 The user should be granted access to outgoing devices. 1239 Administrative 6 1240 The user should be granted access to the administrative interface 1241 to the NAS from which privileged commands can be executed. 1243 NAS Prompt 7 1244 The user should be provided a command prompt on the NAS from which 1245 non-privileged commands can be executed. 1247 Authenticate Only 8 1248 Only Authentication is requested, and no authorization information 1249 needs to be returned in the response. 1251 Callback NAS Prompt 9 1252 The user should be disconnected and called back, then provided a 1253 command prompt on the NAS from which non-privileged commands can 1254 be executed. 1256 7.2 Framed Access Authorization AVPs 1257 This section contains the authorization AVPs that are necessary to 1258 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1259 section MAY be present in a message if the Service-Type AVP was set 1260 to "Framed" or "Callback Framed". 1262 7.2.1 Framed-Protocol AVP 1264 The Framed-Protocol AVP (AVP Code 7) is of type Unsigned32 and 1265 contains the framing to be used for framed access. This AVP MAY be 1266 present in both requests and responses. The following values are 1267 currently supported: 1269 1 PPP 1270 2 SLIP 1271 3 AppleTalk Remote Access Protocol (ARAP) 1272 4 Gandalf proprietary SingleLink/MultiLink protocol 1273 5 Xylogics proprietary IPX/SLIP 1274 6 X.75 Synchronous 1276 7.2.2 Framed-Routing AVP 1278 The Framed-Routing AVP (AVP Code 10) is of type Unsigned32 and 1279 contains the routing method for the user, when the user is a router 1280 to a network. This AVP SHOULD only be present in authorization 1281 responses. The following values are defined for this AVP: 1283 0 None 1284 1 Send routing packets 1285 2 Listen for routing packets 1286 3 Send and Listen 1288 7.2.3 Framed-MTU AVP 1290 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1291 the Maximum Transmission Unit to be configured for the user, when it 1292 is not negotiated by some other means (such as PPP). This AVP SHOULD 1293 only be present in authorization responses. The MTU value MUST be 1294 between the range of 64 and 65535. 1296 7.2.4 Framed-Compression AVP 1298 The Framed-Compression AVP (AVP Code 13) is of type Unsigned32 and 1299 contains the compression protocol to be used for the link. It MAY be 1300 used in an authorization request as a hint to the server that a 1301 specific compression type is desired, but the server is not required 1302 to honor the hint in the corresponding response. 1304 More than one compression protocol AVP MAY be sent. It is the 1305 responsibility of the NAS to apply the proper compression protocol to 1306 appropriate link traffic. 1308 The following values are defined: 1309 0 None 1310 1 VJ TCP/IP header compression [7] 1311 2 IPX header compression 1312 3 Stac-LZS compression 1314 7.2.5 IP Access 1316 The AVPs defined in this section are used when the user requests, or 1317 is being granted, access to IP. They are only present if the Framed- 1318 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1319 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1321 7.2.5.1 Framed-IP-Address AVP 1323 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1324 contains the address to be configured for the user. It MAY be used in 1325 an authorization request as a hint to the server that a specific 1326 address is desired, but the server is not required to honor the hint 1327 in the corresponding response. 1329 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1330 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1331 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1332 that the NAS should select an address for the user (e.g. Assigned 1333 from a pool of addresses kept by the NAS). 1335 7.2.5.2 Framed-IP-Netmask AVP 1337 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1338 contains the IP netmask to be configured for the user when the user 1339 is a router to a network. It MAY be used in an authorization request 1340 as a hint to the server that a specific netmask is desired, but the 1341 server is not required to honor the hint in the corresponding 1342 response. This AVP MUST be present in a response if the request 1343 included this AVP with a value of 0xFFFFFFFF. 1345 7.2.5.3 Framed-IP-Route AVP 1347 The Framed-IP-Route AVP (AVP Code 22) is of type OctetString, encoded 1348 in the UTF-8 [25] format, and contains the routing information to be 1349 configured for the user on the NAS. Zero or more such AVPs MAY be 1350 present in an authorization response. 1352 The string MUST contain a destination prefix in dotted quad form 1353 optionally followed by a slash and a decimal length specifier stating 1354 how many high order bits of the prefix should be used. That is 1355 followed by a space, a gateway address in dotted quad form, a space, 1356 and one or more metrics separated by spaces. For example, 1357 "192.168.1.0/24 192.168.1.1 1". 1359 The length specifier may be omitted in which case it should default 1360 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1361 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1363 Whenever the gateway address is specified as "0.0.0.0" the IP address 1364 of the user SHOULD be used as the gateway address. 1366 7.2.6 IPX Access 1368 The AVPs defined in this section are used when the user requests, or 1369 is being granted, access to IPX. They are only present if the 1370 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics 1371 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1372 protocol, or X.75 Synchronous. 1374 7.2.6.1 Framed-IPX-Network AVP 1376 The Framed-IPX-Network AVP (AVP Code 23) is of type OctetString, 1377 encoded in the UTF-8 [25] format, and contains the IPX Network number 1378 to be configured for the user. It MAY be used in an authorization 1379 request as a hint to the server that a specific address is desired, 1380 but the server is not required to honor the hint in the corresponding 1381 response. 1383 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1384 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1385 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1386 that the NAS should select an address for the user (e.g. assigned 1387 from a pool of one or more IPX networks kept by the NAS). 1389 7.2.7 Appletalk Access 1390 The AVPs defined in this section are used when the user requests, or 1391 is being granted, access to Appletalk. They are only present if the 1392 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1393 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1395 7.2.7.1 Framed-AppleTalk-Link AVP 1397 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1398 contains the AppleTalk network number which should be used for the 1399 serial link to the user, which is another AppleTalk router. This AVP 1400 MUST only be present in an authorization response and is never used 1401 when the user is not another router. 1403 Despite the size of the field, values range from zero to 65535. The 1404 special value of zero indicates that this is an unnumbered serial 1405 link. A value of one to 65535 means that the serial line between the 1406 NAS and the user should be assigned that value as an AppleTalk 1407 network number. 1409 7.2.7.2 Framed-AppleTalk-Network AVP 1411 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1412 and contains the AppleTalk Network number which the NAS should probe 1413 to allocate an AppleTalk node for the user. This AVP MUST only be 1414 present in an authorization response and is never used when the user 1415 is not another router. Multiple instances of this AVP indicate that 1416 the NAS may probe using any of the network numbers specified. 1418 Despite the size of the field, values range from zero to 65535. The 1419 special value zero indicates that the NAS should assign a network for 1420 the user, using its default cable range. A value between one and 1421 65535 (inclusive) indicates the AppleTalk Network the NAS should 1422 probe to find an address for the user. 1424 7.2.7.3 Framed-AppleTalk-Zone AVP 1426 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1427 and contains the AppleTalk Default Zone to be used for this user. 1428 This AVP MUST only be present in an authorization response. Multiple 1429 instances of this AVP in the same message are not allowed. 1431 The codification of the range of allowed usage of this field is 1432 outside the scope of this specification. 1434 7.2.8 ARAP Access 1436 The AVPs defined in this section are used when the user requests, or 1437 is being granted, access to ARAP. They are only present if the 1438 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1439 Access Protocol (ARAP). 1441 7.2.8.1 ARAP-Features AVP 1443 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1444 be present in the AA-Accept message if the Framed-Protocol AVP is set 1445 to the value of ARAP. See [32] for more information of the format of 1446 this AVP. 1448 7.2.8.2 ARAP-Zone-Access AVP 1450 The ARAP-Zone-Access AVP (AVP Code 72) is of type Unsigned32, and MAY 1451 be present in the AA-Accept message if the Framed-Protocol AVP is set 1452 to the value of ARAP. The following values are supported: 1453 1 Only allow access to default zone 1454 2 Use zone filter inclusively 1455 4 Use zone filter exclusively 1457 The value 3 is skipped, not because these are bit flags, but because 1458 3 in some ARAP implementations means "all zones" which is the same as 1459 not specifying a list at all under RADIUS. 1461 If this attribute is present and the value is 2 or 4 then a Filter-Id 1462 must also be present to name a zone list filter to apply the access 1463 flag to. 1465 7.2.8.3 ARAP-Security AVP 1467 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1468 present in the AA-Challenge-Ind message if the Framed-Protocol AVP is 1469 set to the value of ARAP. See [32] for more information of the 1470 format of this AVP. 1472 7.2.8.4 ARAP-Security-Data AVP 1474 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1475 be present in the AA-Request or AA-Challenge-Ind message if the 1476 Framed-Protocol AVP is set to the value of ARAP. This AVP contains 1477 the security module challenge or response associated with the ARAP 1478 Security Module specified in ARAP-Security. 1480 7.3 Non-Framed Access Authorization AVPs 1482 This section contains the authorization AVPs that are needed to 1483 support terminal server functionality. AVPs defined in this section 1484 MAY be present in a message if the Service-Type AVP was set to 1485 "Login" or "Callback Login". 1487 7.3.1 Login-IP-Host AVP 1489 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1490 the system with which to connect the user, when the Login-Service AVP 1491 is included. It MAY be used in an authorization request as a hint to 1492 the server that a specific host is desired, but the server is not 1493 required to honor the hint in the corresponding response. 1495 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1496 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1497 select an address. The value zero indicates that the NAS SHOULD 1498 select a host to connect the user to. 1500 7.3.2 Login-Service AVP 1502 The Login-Service AVP (AVP Code 15) is of type Unsigned32 and 1503 contains the service which should be used to connect the user to the 1504 login host. This AVP SHOULD only be present in authorization 1505 responses. 1507 The following values are defined: 1508 0 Telnet 1509 1 Rlogin 1510 2 TCP Clear 1511 3 PortMaster (proprietary) 1512 4 LAT 1513 5 X25-PAD 1514 6 X25-T3POS 1515 8 TCP Clear Quiet (supresses any NAS-generated connect string) 1517 7.3.3 TCP Services 1519 The AVP described in this section MAY be present if the Login-Service 1520 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1522 7.3.3.1 Login-TCP-Port AVP 1524 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1525 contains the TCP port with which the user is to be connected, when 1526 the Login-Service AVP is also present. This AVP SHOULD only be 1527 present in authorization responses. The value MUST NOT be greater 1528 than 65535. 1530 7.3.4 LAT Services 1532 The AVP described in this section MAY be present if the Login-Service 1533 AVP is set to LAT. 1535 7.3.4.1 Login-LAT-Service AVP 1537 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1538 contains the system with which the user is to be connected by LAT. It 1539 MAY be used in an authorization request as a hint to the server that 1540 a specific service is desired, but the server is not required to 1541 honor the hint in the corresponding response. This AVP MUST only be 1542 present in the response if the Login-Service AVP states that LAT is 1543 desired. 1545 Administrators use the service attribute when dealing with clustered 1546 systems, such as a VAX or Alpha cluster. In such an environment 1547 several different time sharing hosts share the same resources (disks, 1548 printers, etc.), and administrators often configure each to offer 1549 access (service) to each of the shared resources. In this case, each 1550 host in the cluster advertises its services through LAT broadcasts. 1552 Sophisticated users often know which service providers (machines) are 1553 faster and tend to use a node name when initiating a LAT connection. 1554 Alternately, some administrators want particular users to use certain 1555 machines as a primitive form of load balancing (although LAT knows 1556 how to do load balancing itself). 1558 The String field contains the identity of the LAT service to use. 1559 The LAT Architecture allows this string to contain $ (dollar), - 1560 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1561 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1562 string comparisons are case insensitive. 1564 7.3.4.2 Login-LAT-Node AVP 1566 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1567 contains the Node with which the user is to be automatically 1568 connected by LAT. It MAY be used in an authorization request as a 1569 hint to the server that a specific LAT node is desired, but the 1570 server is not required to honor the hint in the corresponding 1571 response. This AVP MUST only be present in a response if the 1572 Service-Type AVP is set to LAT. 1574 The String field contains the identity of the LAT service to use. 1575 The LAT Architecture allows this string to contain $ (dollar), - 1576 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1577 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1578 string comparisons are case insensitive. 1580 7.3.4.3 Login-LAT-Group AVP 1582 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1583 contains a string identifying the LAT group codes which this user is 1584 authorized to use. It MAY be used in an authorization request as a 1585 hint to the server that a specific group is desired, but the server 1586 is not required to honor the hint in the corresponding response. This 1587 AVP MUST only be present in a response if the Service-Type AVP is set 1588 to LAT. 1590 LAT supports 256 different group codes, which LAT uses as a form of 1591 access rights. LAT encodes the group codes as a 256 bit bitmap. 1593 Administrators can assign one or more of the group code bits at the 1594 LAT service provider; it will only accept LAT connections that have 1595 these group codes set in the bit map. The administrators assign a 1596 bitmap of authorized group codes to each user; LAT gets these from 1597 the operating system, and uses these in its requests to the service 1598 providers. 1600 The codification of the range of allowed usage of this field is 1601 outside the scope of this specification. 1603 7.3.4.4 Login-LAT-Port AVP 1605 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1606 contains the Port with which the user is to be connected by LAT. It 1607 MAY be used in an authorization request as a hint to the server that 1608 a specific port is desired, but the server is not required to honor 1609 the hint in the corresponding response. This AVP MUST only be present 1610 in a response if the Service-Type AVP is set to LAT. 1612 The String field contains the identity of the LAT service to use. 1614 The LAT Architecture allows this string to contain $ (dollar), - 1615 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1616 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1617 string comparisons are case insensitive. 1619 7.4 Tunneling AVP 1621 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1622 used to describe a tunnel. Its Data field has the following ABNF 1623 grammar: 1625 Tunneling = Type Medium Cep Sep Pw Gid Aid Pref Caid Said 1626 Type = Tunnel-Type ; See Section 7.4.1 1627 Medium = Tunnel-Medium-Type ; See Section 7.4.2 1628 Cep = Tunnel-Client-Endpoint ; See Section 7.4.3 1629 Sep = Tunnel-Server-Endpoint ; See Section 7.4.4 1630 Pw = Tunnel-Password ; See Section 7.4.5 1631 Gid = Tunnel-Private-Group-ID ; See Section 7.4.6 1632 Aid = Tunnel-Assignment-ID ; See Section 7.4.7 1633 Pref = Tunnel-Preference ; See Section 7.4.8 1634 Caid = Tunnel-Client-Auth-ID ; See Section 7.4.9 1635 Said = Tunnel-Server-Auth-ID ; See Section 7.1.4.10 1637 +---------------------------------------------------------------+ 1638 | AVP Header (AVP Code = 403) | 1639 +---------------------------------------------------------------+ 1640 | Tunnel-Type AVP | 1641 +---------------------------------------------------------------+ 1642 | Tunnel-Medium-Type AVP | 1643 +---------------------------------------------------------------+ 1644 | Tunnel-Client-Endpoint AVP | 1645 +---------------------------------------------------------------+ 1646 | Tunnel-Server-Endpoint AVP | 1647 +---------------------------------------------------------------+ 1648 | Tunnel-Password AVP | 1649 +---------------------------------------------------------------+ 1650 | Tunnel-Private-Group-Id AVP | 1651 +---------------------------------------------------------------+ 1652 | Tunnel-Assignment-ID AVP | 1653 +---------------------------------------------------------------+ 1654 | Tunnel-Preference AVP | 1655 +---------------------------------------------------------------+ 1656 | Tunnel-Client-Auth-ID AVP | 1657 +---------------------------------------------------------------+ 1658 | Tunnel-Server-Auth-ID AVP | 1659 +---------------------------------------------------------------+ 1661 7.4.1 Tunnel-Type AVP 1663 The Tunnel-Type AVP (AVP Code 64) is of type Unsigned32 and contains 1664 the tunneling protocol(s) to be used (in the case of a tunnel 1665 initiator) or the the tunneling protocol in use (in the case of a 1666 tunnel terminator). It MAY be used in an authorization request as a 1667 hint to the server that a specific tunnel type is desired, but the 1668 server is not required to honor the hint in the corresponding 1669 response. 1671 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1672 Record within the Accounting-Request. 1674 A tunnel initiator is not required to implement any of these tunnel 1675 types; if a tunnel initiator receives a response that contains only 1676 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1677 as though a response was received with the Result-Code indicating a 1678 failure. 1680 The following values have been defined: 1681 1 Point-to-Point Tunneling Protocol (PPTP) [14] 1682 2 Layer Two Forwarding (L2F) [15] 1683 3 Layer Two Tunneling Protocol (L2TP) [16] 1684 4 Ascend Tunnel Management Protocol (ATMP) [17] 1685 5 Virtual Tunneling Protocol (VTP) 1686 6 IP Authentication Header in the Tunnel-mode (AH) [18] 1687 7 IP-in-IP Encapsulation (IP-IP) [19] 1688 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 1689 9 IP Encapsulating Security Payload in the 1690 Tunnel-mode (ESP) [21] 1691 10 Generic Route Encapsulation (GRE) [22] 1692 11 Bay Dial Virtual Services (DVS) 1693 12 IP-in-IP Tunneling [23] 1695 7.4.2 Tunnel-Medium-Type AVP 1697 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and 1698 contains the transport medium to use when creating a tunnel for those 1699 protocols (such as L2TP) that can operate over multiple transports. 1700 It MAY be used in an authorization request as a hint to the server 1701 that a specific medium is desired, but the server is not required to 1702 honor the hint in the corresponding response. 1704 The Value field is three octets and contains one of the values listed 1705 under "Address Family Numbers" in [10]. The value of most importance 1706 is (1) for IPv4 and (2) for IPv6. 1708 7.4.3 Tunnel-Client-Endpoint AVP 1710 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type OctetString, 1711 encoded in the UTF-8 [25] format, and contains the address of the 1712 initiator end of the tunnel. It MAY be used in an authorization 1713 request as a hint to the server that a specific endpoint is desired, 1714 but the server is not required to honor the hint in the corresponding 1715 response. 1717 This AVP SHOULD be included in the ADIF Record of the corresponding 1718 Accounting-Request messages, in which case it indicates the address 1719 from which the tunnel was initiated. This AVP, along with the 1720 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1721 a globally unique means to identify a tunnel for accounting and 1722 auditing purposes. 1724 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1725 fully qualified domain name (FQDN) of the tunnel client machine, or 1726 it is a "dotted-decimal" IP address. Conformant implementations MUST 1727 support the dotted-decimal format and SHOULD support the FQDN format 1728 for IP addresses. 1730 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1731 FQDN of the tunnel client machine, or it is a text representation of 1732 the address in either the preferred or alternate form [5]. 1733 Conformant implementations MUST support the preferred form and SHOULD 1734 support both the alternate text form and the FQDN format for IPv6 1735 addresses. 1737 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1738 referring to configuration data local to the Diameter client that 1739 describes the interface and medium-specific address to use. 1741 7.4.4 Tunnel-Server-Endpoint AVP 1743 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of OctetString, 1744 encoded in the UTF-8 [25] format, and contains the address of the 1745 server end of the tunnel. It MAY be used in an authorization request 1746 as a hint to the server that a specific endpoint is desired, but the 1747 server is not required to honor the hint in the corresponding 1748 response. 1750 This AVP SHOULD be included in the ADIF Record of the corresponding 1751 Accounting-Request messages, in which case it indicates the address 1752 from which the tunnel was initiated. This AVP, along with the 1753 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1754 a globally unique means to identify a tunnel for accounting and 1755 auditing purposes. 1757 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1758 fully qualified domain name (FQDN) of the tunnel client machine, or 1759 it is a "dotted-decimal" IP address. Conformant implementations MUST 1760 support the dotted-decimal format and SHOULD support the FQDN format 1761 for IP addresses. 1763 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1764 FQDN of the tunnel client machine, or it is a text representation of 1765 the address in either the preferred or alternate form [5]. 1766 Conformant implementations MUST support the preferred form and SHOULD 1767 support both the alternate text form and the FQDN format for IPv6 1768 addresses. 1770 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1771 referring to configuration data local to the Diameter client that 1772 describes the interface and medium-specific address to use. 1774 7.4.5 Tunnel-Password AVP 1776 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1777 contain a password to be used to authenticate to a remote server. 1778 This AVP MUST only be present in authorization responses in an 1779 encrypted form, using one of the methods described in [2] and [13]. 1781 7.4.6 Tunnel-Private-Group-ID AVP 1783 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type OctetString, 1784 encoded in the UTF-8 [25] format, and contains the group ID for a 1785 particular tunneled session. The Tunnel-Private-Group-ID AVP MAY be 1786 included in an authorization request if the tunnel initiator can 1787 pre-determine the group resulting from a particular connection and 1788 SHOULD be included in the authorization response if this tunnel 1789 session is to be treated as belonging to a particular private group. 1790 Private groups may be used to associate a tunneled session with a 1791 particular group of users. For example, it MAY be used to facilitate 1792 routing of unregistered IP addresses through a particular interface. 1793 This value SHOULD be included the corresponding ADIF-Record in the 1794 Accounting-Request which pertain to a tunneled session. 1796 7.4.7 Tunnel-Assignment-ID AVP 1798 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1799 is used to indicate to the tunnel initiator the particular tunnel to 1800 which a session is to be assigned. Some tunneling protocols, such as 1801 PPTP and L2TP, allow for sessions between the same two tunnel 1802 endpoints to be multiplexed over the same tunnel and also for a given 1803 session to utilize its own dedicated tunnel. This attribute provides 1804 a mechanism for Diameter to be used to inform the tunnel initiator 1805 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1806 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1807 sharing multiplexed tunnels to be assigned to different multiplexed 1808 tunnels. 1810 A particular tunneling implementation may assign differing 1811 characteristics to particular tunnels. For example, different 1812 tunnels may be assigned different QOS parameters. Such tunnels may 1813 be used to carry either individual or multiple sessions. The 1814 Tunnel-Assignment-ID attribute thus allows the Diameter server to 1815 indicate that a particular session is to be assigned to a tunnel that 1816 provides an appropriate level of service. It is expected that any 1817 QOS-related Diameter tunneling attributes defined in the future that 1818 accompany this attribute will be associated by the tunnel initiator 1819 with the ID given by this attribute. In the meantime, any semantic 1820 given to a particular ID string is a matter left to local 1821 configuration in the tunnel initiator. 1823 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1824 the tunnel initiator. The ID it specifies is intended to be of only 1825 local use to Diameter and the tunnel initiator. The ID assigned by 1826 the tunnel initiator is not conveyed to the tunnel peer. 1828 This attribute MAY be included in authorization responses. The tunnel 1829 initiator receiving this attribute MAY choose to ignore it and assign 1830 the session to an arbitrary multiplexed or non-multiplexed tunnel 1831 between the desired endpoints. This attribute SHOULD also be 1832 included in the corresponding ADIF-Record in the Accounting-Request 1833 messages which pertain to a tunneled session. 1835 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1836 should assign a session to a tunnel in the following manner: 1838 - If this AVP is present and a tunnel exists between the specified 1839 endpoints with the specified ID, then the session should be 1840 assigned to that tunnel. 1842 - If this AVP is present and no tunnel exists between the 1843 specified endpoints with the specified ID, then a new tunnel 1844 should be established for the session and the specified ID 1845 should be associated with the new tunnel. 1847 - If this AVP is not present, then the session is assigned to an 1848 unnamed tunnel. If an unnamed tunnel does not yet exist between 1849 the specified endpoints then it is established and used for this 1850 and subsequent sessions established without the Tunnel- 1851 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1852 session for which a Tunnel-Assignment-ID AVP was not specified 1853 to a named tunnel (i.e. one that was initiated by a session 1854 specifying this AVP). 1856 Note that the same ID may be used to name different tunnels if such 1857 tunnels are between different endpoints. 1859 7.4.8 Tunnel-Preference AVP 1861 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1862 used to identify the relative preference assigned to each tunnel when 1863 more than one set of tunneling AVPs is returned within separete 1864 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1865 hint to the server that a specific preference is desired, but the 1866 server is not required to honor the hint in the corresponding 1867 response. 1869 For example, suppose that AVPs describing two tunnels are returned by 1870 the server, one with a Tunnel-Type of PPTP and the other with a 1871 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1872 the Tunnel-Types returned, it will initiate a tunnel of that type. 1873 If, however, it supports both tunnel protocols, it SHOULD use the 1874 value of the Tunnel-Preference AVP to decide which tunnel should be 1875 started. The tunnel having the numerically lowest value in the Value 1876 field of this AVP SHOULD be given the highest preference. The values 1877 assigned to two or more instances of the Tunnel-Preference AVP within 1878 a given authorization response MAY be identical. In this case, the 1879 tunnel initiator SHOULD use locally configured metrics to decide 1880 which set of AVPs to use. 1882 7.4.9 Tunnel-Client-Auth-ID AVP 1884 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1885 specifies the name used by the tunnel initiator during the 1886 authentication phase of tunnel establishment. It MAY be used in an 1887 authorization request as a hint to the server that a specific 1888 preference is desired, but the server is not required to honor the 1889 hint in the corresponding response. This AVP MUST be present in the 1890 authorization response if an authentication name other than the 1891 default is desired. This AVP SHOULD be included in the corresponding 1892 ADIF-Record of the Accounting-Request messages which pertain to a 1893 tunneled session. 1895 7.4.10 Tunnel-Server-Auth-ID AVP 1897 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1898 and specifies the name used by the tunnel terminator during the 1899 authentication phase of tunnel establishment. It MAY be used in an 1900 authorization request as a hint to the server that a specific 1901 preference is desired, but the server is not required to honor the 1902 hint in the corresponding response. This AVP MUST be present in the 1903 authorization response if an authentication name other than the 1904 default is desired. This AVP SHOULD be included in the corresponding 1905 ADIF-Record of the Accounting-Request messages which pertain to a 1906 tunneled session. 1908 8.0 Accounting Considerations 1910 This section contains a description of the AVPs defined in this 1911 document that are to be included in Diameter accounting messages 1912 [29]. 1914 8.1 Framed Access 1916 This section contains the AVPs defined in this extension that are to 1917 be present in the Accounting-Request and optionally in the 1918 Accounting-Answer messages, defined in [29], when the Service-Type 1919 AVP specifies Framed service. 1921 ::= { Service-Type } 1922 { Framed-Protocol } 1923 [ Framed-IP-Address ] 1924 [ Framed-IP-Netmask ] 1925 [ Framed-Routing ] 1926 [ Framed-MTU ] 1927 [ Framed-Compression ] 1928 [ Framed-Route ] 1929 [ Framed-IPX-Network ] 1930 [ Framed-AppleTalk-Link ] 1931 [ Framed-AppleTalk-Network ] 1932 [ Framed-AppleTalk-Zone ] 1934 8.2 Non-Framed Access 1936 This section contains the AVPs defined in this extension that are to 1937 be present in the Accounting-Request and optionally in the 1938 Accounting-Answer messages, defined in [29], when the Service-Type 1939 AVP specifies non-Framed service. 1941 ::= { Service-Type } 1942 { Login-Service } 1943 [ Login-IP-Host ] 1944 [ Login-TCP-Port ] 1945 [ Login-LAT-Service ] 1946 [ Login-LAT-Node ] 1947 [ Login-LAT-Group ] 1948 [ Login-LAT-Port ] 1950 8.3 Tunneling 1952 Additional work is required to identify how to integrate tunneling in 1953 the Accounting extension. One method is as defined in [34], which 1954 would require new Accounting-Type messages (e.g. tunnel and link 1955 start/stop). 1957 9.0 Interactions with Resource Management 1959 The Resource Management extension [31] provides the ability for a 1960 Diameter node to query a peer for session state information. The 1961 document states that service-specific extensions are responsible for 1962 specifying what AVPs are to be present in the Resource-Token [31] 1963 AVP. 1965 In addition to the AVPs listed in [31], the Resource-Token with the 1966 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1967 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1968 IPX-Network MUST be present if the corresponding network is being 1969 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1970 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1971 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1972 AVPs MUST be present. 1974 10.0 AVP Table 1976 The following table presents the AVPs defined in this document, and 1977 specifies in which Diameter messages they MAY, or MAY NOT be present. 1978 Note that AVPs that can only be present within a Grouped AVP are not 1979 represented in this table. 1981 The table uses the following symbols: 1982 0 The AVP MUST NOT be present in the message. 1983 0+ Zero or more instances of the AVP MAY be present in the 1984 message. 1985 0-1 Zero or one instance of the AVP MAY be present in the 1986 message. 1987 1 One instance of the AVP MUST be present in the message. 1989 +-----------------------------------+ 1990 | Command-Code | 1991 |-----+-----+-----+-----+-----+-----+ 1992 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 1993 ------------------------------|-----+-----+-----+-----+-----|-----| 1994 ARAP-Challenge-Response | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1995 ARAP-Features | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1996 ARAP-Password | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1997 ARAP-Security | 0-1 | 0 | 0-1 | 0-1 | 0 | 0-1 | 1998 ARAP-Security-Data | 0+ | 0 | 0 | 0+ | 0 | 0 | 1999 ARAP-Zone-Access | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2000 Callback-Id | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2001 Callback-Number | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2002 Called-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2003 Calling-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2004 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 0 | 0 | 2005 CHAP-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2006 Class | 0 | 0+ | 0 | 0 | 0+ | 0 | 2007 Connect-Info | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2008 Destination-FQDN | 0+ | 0+ | 1 | 0+ | 0+ | 1 | 2009 Destination-Realm | 1 | 1 | 1 | 1 | 1 | 1 | 2010 EAP-Payload | 0 | 0 | 0 | 1 | 1 | 1 | 2011 Error-Reporting-FQDN | 0 | 0+ | 0+ | 0 | 0+ | 0 | 2012 Extension-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2013 Filter-Id | 0 | 0+ | 0 | 0 | 0+ | 0 | 2014 Filter-Rule | 0 | 0+ | 0 | 0 | 0+ | 0 | 2015 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2016 Framed-Appletalk-Network | 0 | 0+ | 0 | 0 | 0+ | 0 | 2017 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2018 Framed-Compression | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2019 Framed-IP-Address | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2020 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 2021 Framed-IP-Route | 0 | 0+ | 0 | 0 | 0+ | 0 | 2022 Framed-IPX-Network | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2023 Framed-MTU | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2024 Framed-Protocol | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2025 Framed-Routing | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2026 Integrity-Check-Value | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2027 Idle-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2028 Login-IP-Host | 0+ | 0+ | 0 | 0 | 0 | 0 | 2029 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2030 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2031 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2032 +-----------------------------------+ 2033 | Command-Code | 2034 |-----+-----+-----+-----+-----+-----+ 2035 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 2036 ------------------------------|-----+-----+-----+-----+-----|-----| 2037 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2038 Login-Service | 0 | 0+ | 0 | 0 | 0 | 0 | 2039 Login-TCP-Port | 0 | 0+ | 0 | 0 | 0 | 0 | 2040 NAS-IP-Address | 1 | 0 | 0 | 1 | 0 | 0 | 2041 NAS-Port | 1 | 0 | 0 | 1 | 0 | 0 | 2042 NAS-Port-Type | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2043 Origin-FQDN | 1 | 1 | 1 | 1 | 1 | 1 | 2044 Origin-Realm | 1 | 1 | 1 | 1 | 1 | 1 | 2045 Password-Retry | 0 | 0-1 | 0 | 0 | 0 | 0 | 2046 Port-Limit | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2047 Prompt | 0 | 0 | 0-1 | 0 | 0 | 0 | 2048 Proxy-State | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2049 Reply-Message | 0 | 0 | 0+ | 0 | 0 | 0 | 2050 Request-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2051 Result-Code | 0 | 1 | 0 | 0 | 1 | 0 | 2052 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2053 Service-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2054 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2055 Session-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2056 State | 0-1 | 0-1 | 0-1 | 0 | 0-1 | 0 | 2057 Tunneling | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2058 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2059 User-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2061 11.0 IANA Considerations 2063 The command codes defined in Sections 3.1 and 4.2 are values taken 2064 from the Command-Code [2] address space and extended in [13], [29] 2065 and [30]. IANA should record the values as defined in Sections 2.1 2066 and 4.2. 2068 The AVPs defined in section 2.1 were alllocated from from the AVP 2069 numbering space defined in [2], and extended in [13], [29], and [30]. 2070 IANA should record the values as defined in Sections 2.1. 2072 The Diameter base protocol [2] reserves the first 255 AVPs for legacy 2073 RADIUS support [1]. The AVPs defined in section 2.2 are defined in 2074 [1] and [32], and no number assignment is necessary. 2076 11.1 Request-Type AVP Values 2077 The Request-Type AVP (section 2.1.1) has a set of values that MUST be 2078 maintained by IANA. Values 1 through 3 are defined in this document. 2079 The remaining values are available for assignment via Designated 2080 Expert [27]. 2082 12.0 Security Considerations 2084 This document does not contain any security protocol, but does 2085 discuss how PPP authentication protocols can be carried within the 2086 Diameter protocol. The PPP authentication protocols that are 2087 described are PAP, CHAP and EAP. 2089 The use of PAP SHOULD be discouraged, since it exposes user's 2090 passwords to possibly non-trusted entities. PAP is also frequently 2091 used for use with One-Time Passwords (OTP), which does not expose any 2092 security risks. However, it is highly recommended that OTP be 2093 supported through the EAP protocol. 2095 This document also describes how CHAP can be carried within the 2096 Diameter protocol, which is required for backward RADIUS 2097 compatibility. The CHAP protocol, as used in a RADIUS environment, 2098 facilitates authentication replay attacks, and therefore SHOULD NOT 2099 be used when EAP is available. 2101 13.0 References 2103 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 2105 [2] Calhoun, Rubens, Akhtar, Guttman, "Diameter Base Protocol", 2106 draft-ietf-aaa-diameter-01.txt, IETF work in progress, March 2107 2001. 2109 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 2110 ary 1999. 2112 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2113 2477, January 1999. 2115 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2116 RFC 2373, July 1998 2118 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2119 (CHAP)", RFC 1994, August 1996. 2121 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2122 links", RFC 1144, February 1990. 2124 [8] ISO 8859. International Standard -- Information Processing -- 2125 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2126 Alphabet No. 1, ISO 8859-1:1987. 2127 2129 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2130 (MP)", RFC 1717, November 1994. 2132 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2133 October 1994 2135 [11] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-ietf- 2136 aaa-diameter-framework-01.txt, IETF work in progress, March 2137 2001. 2139 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2140 Levels", BCP 14, RFC 2119, March 1997. 2142 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 2143 Extension", draft-calhoun-diameter-strong-crypto-06.txt, IETF 2144 work in progress, February 2001. 2146 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2147 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2148 July 1999 2150 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 2151 warding (Protocol) 'L2F'", RFC 2341, May 1998 2153 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 2154 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 2155 August 1999 2157 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2158 2107, February 1997 2160 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2161 Protocol", RFC 2401, November 1998 2163 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2164 1996 2166 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2167 October 1996 2169 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2170 1827, August 1995 2172 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2173 Encapsulation (GRE)", RFC 1701, October 1994 2175 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2177 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2178 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2179 in progress, June 2000. 2181 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 2182 Protocol (EAP)." RFC 2284, March 1998. 2184 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 2185 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 2186 1999. 2188 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 2189 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2191 [28] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 2192 Haag, "Diameter Implementation Guidelines", draft-ietf-aaa- 2193 diameter-impl-guide-00.txt, IETF work in progress, June 2000. 2195 [29] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 2196 Extension", draft-ietf-aaa-diameter-accounting-01.txt, IETF work 2197 in progress, March 2001. 2199 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2200 ietf-aaa-diameter-mobileip-01.txt, IETF work in progress, March 2201 2001. 2203 [31] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2204 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 2206 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2207 2869, June 2000. 2209 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2210 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2211 June 2000. 2213 [24] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications 2214 for Tunnel Protocol Support", RFC 2867, June 2000. 2216 [25] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2217 2279, January 1998. 2219 14.0 Acknowledgements 2221 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2222 Allen Simpson, and Steve Willens for their work on the original 2223 RADIUS, from which much of the concepts in this specification were 2224 derived from. Also Carl Rigney and Ward Willats for [32], and Glen 2225 Zorn, Dory Leifer, Allan C. Rubens, John Shriver, Matt Holdrege and 2226 Ignacio Goyret for their work on [33]. This document stole text and 2227 concepts from both [32] and [33]. 2229 The authors would also like to acknowledge the following people for 2230 their contribution in the development of the Diameter protocol: 2232 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2233 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2234 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2235 and Jeff Weisberg 2237 15.0 Authors' Addresses 2239 Questions about this memo can be directed to: 2241 Pat R. Calhoun 2242 Network and Security Research Center, Sun Labs 2243 Sun Microsystems, Inc. 2244 15 Network Circle 2245 Menlo Park, California, 94025 2246 USA 2248 Phone: +1 650-786-7733 2249 Fax: +1 650-786-6445 2250 E-mail: pcalhoun@eng.sun.com 2252 William Bulley 2253 Merit Network, Inc. 2254 Building One, Suite 2000 2255 4251 Plymouth Road 2256 Ann Arbor, Michigan 48105-2785 2257 USA 2259 Phone: +1 734-764-9993 2260 Fax: +1 734-647-3185 2261 E-mail: web@merit.edu 2263 Allan C. Rubens 2264 Tut Systems, Inc. 2265 220 E. Huron, Suite 260 2266 Ann Arbor, MI 48104 2267 USA 2269 Phone: +1 734-995-1697 2270 E-Mail: arubens@tutsys.com 2272 Jeff Haag 2273 Cisco Systems 2274 7025 Kit Creek Road 2275 PO Box 14987 2276 Research Triangle Park, NC 27709 2278 Phone: 1-919-392-2353 2279 E-Mail: haag@cisco.com 2281 Glen Zorn 2282 Cisco Systems, Inc. 2283 500 108th Avenue N.E., Suite 500 2284 Bellevue, WA 98004 2285 USA 2287 Phone: +1 425 438 8218 2288 E-Mail: gwz@cisco.com 2290 16.0 Full Copyright Statement 2292 Copyright (C) The Internet Society (2001). All Rights Reserved. 2294 This document and translations of it may be copied and furnished to 2295 others, and derivative works that comment on or otherwise explain it 2296 or assist in its implementation may be prepared, copied, published 2297 and distributed, in whole or in part, without restriction of any 2298 kind, provided that the above copyright notice and this paragraph are 2299 included on all such copies and derivative works. However, this docu- 2300 ment itself may not be modified in any way, such as by removing the 2301 copyright notice or references to the Internet Society or other 2302 Internet organizations, except as needed for the purpose of develop- 2303 ing Internet standards in which case the procedures for copyrights 2304 defined in the Internet Standards process must be followed, or as 2305 required to translate it into languages other than English. The lim- 2306 ited permissions granted above are perpetual and will not be revoked 2307 by the Internet Society or its successors or assigns. This document 2308 and the information contained herein is provided on an "AS IS" basis 2309 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2310 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2311 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2312 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2313 FITNESS FOR A PARTICULAR PURPOSE. 2315 17.0 Expiration Date 2317 This memo is filed as and 2318 expires in August 2001.