idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-00.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 51 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 52 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 7 characters 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 513 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 (February 2001) is 8470 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 1926, but not defined == Unused Reference: '3' is defined on line 2079, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2105, 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-00 ** 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) == Outdated reference: A later version (-01) exists of draft-ietf-aaa-diameter-framework-00 -- 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 2284 (ref. '25') (Obsoleted by RFC 3748) -- Possible downref: Normative reference to a draft: ref. '26' ** Obsolete normative reference: RFC 2434 (ref. '27') (Obsoleted by RFC 5226) -- Possible downref: Normative reference to a draft: ref. '28' == Outdated reference: A later version (-01) exists of draft-ietf-aaa-diameter-accounting-00 -- Possible downref: Normative reference to a draft: ref. '29' == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-00 == 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 (~~), 17 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 February 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 and 251 provides filter rules that need to be configured on the NAS for the 252 user. One or more such AVPs MAY be present in an authorization 253 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 Host-Name 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, and 504 contains the Identity of the NAS providing service to the user. When 505 this AVP is present, the Host-Name AVP DOES NOT represent the NAS 506 providing service to the user. Note that this AVP SHOULD only added 507 by a RADIUS/Diameter protocol gateway [28]. 509 2.2.3 State AVP 511 The State AVP (AVP Code 24) is of type OctetString and is used to 512 transmit the contents of the RADIUS State attribute, and no 513 interpretation of the contents should be made. Note that this AVP 514 SHOULD only added by a RADIUS/Diameter protocol gateway [28]. 516 2.2.4 Class AVP 518 The Class AVP (AVP Code 25) is of type OctetString and is used to 519 transmit the contents of the RADIUS Class attribute, and no 520 interpretation of the contents should be made. Note that this AVP 521 SHOULD only added by a RADIUS/Diameter protocol gateway [28]. 523 3.0 Legacy RADIUS Authentication Support 525 This section defines the new Command-Code [2] values required to 526 support the legacy authentication protocols (i.e. PAP, CHAP), as well 527 as the AVPs that are necessary to carry the authentication 528 information in the Diameter protocol. The functionality defined here 529 provides a RADIUS-like AAA service, over a more reliable and secure 530 transport, as defined in the base protocol [2]. 532 Unlike the RADIUS protocol [1], the Diameter protocol does not 533 require authentication information to be contained in a request from 534 the client. Therefore, it is possible to send a request for 535 authorization only. The type of service depends upon the Request-Type 536 AVP. This difference MAY cause operational issues in environments 537 that need RADIUS interoperability, and it MAY be necessary that 538 protocol conversion gateways add some authentication information when 539 transmitting to a RADIUS server. 541 The Diameter protocol allows for users to be periodically re- 542 authenticated and/or re-authorized. In such instances, the Session-Id 543 AVP in the AAR message MUST be the same as the one present in the 544 original authentication/authorization message. A Diameter server 545 informs the NAS of the authorized session lifetime via the Session- 546 Timeout AVP [1]. 548 A NAS MUST re-authenticate and/or authorize after the period provided 549 by the server. Furthermore, it is possible for Diameter servers to 550 issue an unsolicited re-authentication and/or re-authorization by 551 issuing an AA-Challenge-Ind message to the NAS. Upon receipt of such 552 a message, the NAS is instructed to issue a request to re- 553 authenticate and/or re-authorize the client. 555 3.1 Command-Codes Values 557 This section defines new Command-Code [2] values that MUST be 558 supported by all Diameter implementations that conform to this 559 specification. The following Command Codes are defined in this 560 section: 562 Command-Name Abbrev. Code Reference 563 -------------------------------------------------------- 564 AA-Answer AAA 266 3.1.2 565 AA-Challenge-Ind ACI 267 3.1.3 566 AA-Request AAR 265 3.1.1 568 3.1.1 AA-Request (AAR) Command 570 The AA-Request message (AAR), indicated by the Command-Code field set 571 to 265, is used in order to request authentication and/or 572 authorization for a given PPP user. The type of request is identified 573 through the Request-Type AVP, and the default mode is both 574 authentication and authorization. 576 If Authentication is requested the User-Name attribute SHOULD be 577 present, as well as any additional authentication AVPs that would 578 carry the password information. A request for authorization only 579 SHOULD include the information from which the authorization will be 580 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 581 networks MAY use different AVPs for authorization purposes. A request 582 for authorization will include some AVPs defined in sections 2.0, 6.0 583 and 7.0. 585 It is possible for a single session to be authorized only first, then 586 followed by an authentication request. However, the inverse SHOULD 587 NOT be permitted. 589 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 590 MUST be identical as the one provided in the initial AA-Request for 591 the same session. If the AA-Request is a result of an AA-Challenge- 592 Ind that included a State AVP, the same AVP MUST be present in the 593 following AA-Request. 595 Message Format 596 ::= < Diameter Header: 265 > 597 < Session-Id > 598 { Host-Name } 599 [ NAS-Identifier ] 600 [ User-Name ] 601 [ User-Password ] 602 [ ARAP-Password ] 603 [ CHAP-Password ] 604 [ CHAP-Challenge ] 605 [ State ] 606 * [ AVP ] 607 * [ Proxy-State ] 608 * [ Route-Record ] 609 * [ Routing-Realm ] 610 0*1< Integrity-Check-Value > 612 3.1.1.1 User-Password AVP 614 The User-Password AVP (AVP Code 2) is of type OctetString and 615 contains the password of the user to be authenticated, or the user's 616 input following an AA-Challenge-Ind. 618 This AVP MUST be encrypted using one of the methods described in [2] 619 or [13]. Unless this AVP is used for one-time passwords, the User- 620 Password AVP SHOULD NOT be used in non-trusted proxy environments. 622 The clear-text password (prior to encryption) MUST NOT be longer than 623 128 bytes in length. 625 3.1.1.2 CHAP-Password AVP 627 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 628 the response value provided by a PPP Challenge-Handshake 629 Authentication Protocol (CHAP) [6] user in response to the challenge. 631 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 632 AVP (see section 3.1.1.3) MUST be present as well. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 AVP Header (AVP Code = 3) 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | CHAP Ident | Data ... 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 The CHAP Ident field contains the one octet CHAP Identifier from the 643 user's CHAP response [6]. The Data field is 16 octets, and contains 644 the CHAP Response from the user. The actual computation of the CHAP 645 response can be found in [6]. 647 3.1.1.3 CHAP-Challenge AVP 649 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 650 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 651 Handshake Authentication Protocol (CHAP) [6] user. 653 3.1.1.4 ARAP-Password AVP 655 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 656 only present when the Framed-Protocol AVP (see Section 7.2.1) is 657 included in the message and is set to ARAP. This AVP MUST NOT be 658 present if the User-Password or CHAP-Password AVPs are present. See 659 [32] for more information on the contents of this AVP. 661 3.1.2 AA-Answer (AAA) Command 663 The AA-Answer (AAA) message, indicated by the Command-Code field set 664 to 266, is sent in response to the AA-Request message. If 665 authorization was requested, a successful response will include the 666 authorization AVPs appropriate for the service being provided, as 667 defined in section 2.0, 6.0 and 7.0 669 Message Format 671 ::= < Diameter Header: 266 > 672 < Session-Id > 673 { Result-Code } 674 { Host-Name } 675 [ User-Name ] 676 * [ AVP ] 677 * [ Proxy-State ] 678 * [ Route-Record ] 679 * [ Routing-Realm ] 680 0*1< Integrity-Check-Value > 682 3.1.2.1 ARAP-Challenge-Response AVP 684 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 685 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 686 is included in the message and is set to ARAP. This AVP contains an 8 687 octet response to the dial-in client's challenge. The RADIUS server 688 calculates this value by taking the dial-in client's challenge from 689 the high order 8 octets of the ARAP-Password AVP and performing DES 690 encryption on this value with the authenticating user's password as 691 the key. If the user's password is less than 8 octets in length, the 692 password is padded at the end with NULL octets to a length of 8 693 before using it as a key. 695 3.1.2.2 Password-Retry AVP 697 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 698 included in the AA-Answer if the Result-Code indicates an 699 authentication failure. The value of this AVP indicates how many 700 authentication attempts a user may be permitted before being 701 disconnected. This AVP is primarily intended for use when the 702 Framed-Protocol AVP (see Section 7.2.1) is set to ARAP. 704 3.1.3 AA-Challenge-Ind (ACI) Command 706 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 707 field set to 267, is sent by a Diameter Home server to issue a 708 challenge requiring a response to a dial-up user. The message MAY 709 have one or more Reply-Message AVP, the User-Name AVP and it MAY have 710 zero or one State AVP. No other AVPs are permitted in an AA- 711 Challenge-Ind other than security related AVPs [2, 13]. 713 On receipt of an AA-Challenge-Ind, the Identifier field is matched 714 with a pending AA-Request. Invalid messages are silently discarded. 716 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 717 Request SHOULD be sent. The NAS MAY display the text message, if any, 718 to the user, and then prompt the user for a response. It then sends 719 its original AA-Request with a new request ID, with the User-Password 720 AVP replaced by the user's response (encrypted), and including the 721 State AVP from the AA-Challenge-Ind, if any. 723 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 724 client and accept a PAP response which it can use as though the user 725 had entered the response. If the NAS cannot do so, it should treat 726 the AA-Challenge-Ind as though it had received an AA-Answer with a 727 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 729 When possible, authentication mechanisms that include more than a 730 single authentication round trip SHOULD use EAP (see section 4.0) 731 instead of the AA-Challenge-Ind. This command has been maintained for 732 RADIUS backward compatibility. 734 AA-Challenge-Ind ::= < Diameter Header: 267 > 735 < Session-Id > 736 { Result-Code } 737 { Host-Name } 738 [ User-Name ] 739 [ State ] 740 * [ AVP ] 741 * [ Reply-Message ] 742 * [ Proxy-State ] 743 * [ Route-Record ] 744 * [ Routing-Realm ] 745 0*1< Integrity-Check-Value > 747 3.1.3.1 Prompt AVP 749 The Prompt AVP (AVP Code 76) is of type Unsigned32, and MAY be 750 present in the AA-Challenge-Ind message. When present, it is used by 751 the NAS to determine whether the user's response, when entered, 752 should be echoed. The following values are defined: 753 0 No Echo 754 1 Echo 756 3.2 Reply-Message AVP 758 The Reply-Message AVP (AVP Code 18) is of type OctetString and 759 contains text which MAY be displayed to the user. When used in an 760 AA-Answer message with a successful Result-Code AVP it indicates the 761 success message. When found in the same message with a Result-Code 762 other than Diameter-SUCCESS it contains the failure message. 764 The Reply-Message AVP MAY indicate a dialog message to prompt the 765 user before another AA-Request attempt. When used in an AA- 766 Challenge-Ind, it MAY indicate a dialog message to prompt the user 767 for a response. 769 Multiple Reply-Message's MAY be included and if any are displayed, 770 they MUST be displayed in the same order as they appear in the 771 message. 773 4.0 Extensible Authentication Protocol Support 775 The Extensible Authentication Protocol (EAP), described in [25], 776 provides a standard mechanism for support of additional 777 authentication methods within PPP. Through the use of EAP, support 778 for a number of authentication schemes may be added, including smart 779 and token cards, Kerberos, Public Key, One Time Passwords, and 780 others. 782 This section describes the Command-Codes values and AVPs that are 783 required for an EAP payload to be encapsulated within the Diameter 784 protocol. Since authentication occurs between the PPP client and its 785 home Diameter server, end-to-end authentication is achieved, reducing 786 the possibility for fraudulent authentication, such as replay and 787 man-in-the-middle attacks. End-to-end authentication also provides 788 for mutual (bi-directional) authentication, which is not possible 789 with PAP and CHAP in a roaming environment. 791 The Diameter/EAP extension allows a home Diameter server to initiate 792 an unsolicited authentication request to the user. This allows the 793 home server to periodically ensure that the user is still active, 794 which is useful when a server requires re-authentication to extend 795 the "life" of a session [26]. Server-initiated authentication can 796 reduce the number of protocol exchanges over the Internet. 798 The EAP conversation between the authenticating peer and the NAS 799 begins with the negotiation of EAP within LCP. Once EAP has been 800 negotiated, the NAS will typically send to the Diameter server a 801 Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying 802 an EAP-Start. The Port number and NAS Identifier MUST be included in 803 the AVPs issued by the NAS in the Diameter-EAP-Request packet. 805 If the Diameter home server supports EAP, it MUST respond with a 806 Diameter-EAP-Ind message containing an EAP-Payload AVP that includes 807 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 808 NAS to the PPP client. The initial Diameter-EAP-Ind normally includes 809 an EAP-Request/Identity, requesting the PPP client to identify 810 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 811 will then issue a second Diameter-EAP-Request message, with the 812 client's EAP payload encapsulated within the EAP-Payload AVP. The 813 conversation continues until the Diameter server sends a Diameter- 814 EAP-Answer with a Result-Code AVP indicating success or failure. A 815 Result-Code AVP containing a failure indication SHOULD also include 816 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 817 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 818 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 819 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 820 successfully terminate the PPP authentication phase. If authorization 821 was requested, a successful Diameter-EAP-Answer MUST also include the 822 appropriate authorization AVPs required for the service requested 823 (see sections 2.0, 6.0 and 7.0). 825 The above scenario creates a situation in which the NAS never needs 826 to manipulate an EAP packet. An alternative may be used in situations 827 where an EAP-Request/Identity message will always be sent by the NAS 828 to the authenticating peer. This involves having the NAS send an 829 EAP-Request/Identity message to the PPP client, and forwarding the 830 EAP-Response/Identity packet to the Diameter server in the EAP- 831 Payload AVP of a Diameter-EAP-Request packet. While this approach 832 will save a round-trip, it cannot be universally employed. There are 833 circumstances in which the user's identity may not be needed (such as 834 when authentication and accounting is handled based on the calling or 835 called phone number), and therefore an EAP-Request/Identity packet 836 may not necessarily be issued by the NAS to the authenticating peer. 838 Unless the NAS interprets the EAP-Response/Identity packet returned 839 by the authenticating peer, it will not have access to the user's 840 identity. Therefore, the Diameter Server SHOULD return the user's 841 identity by inserting it in the User-Name attribute of subsequent 842 Diameter-EAP-Answer packets. Without the user's identity, the 843 Session-Id AVP MAY be used for accounting and billing, however 844 operationally this MAY be very difficult to manage. 846 The Diameter-EAP-Ind message MAY be sent by a Diameter server in 847 order to initiate an unsolicited authentication of the PPP user, as 848 described in [26]. This functionality allows a home Diameter server 849 to easily extend the "life" of a session for a particular service, 850 while reducing the total number of authentication round-trips, should 851 the NAS initiate the periodic authentication. 853 Should an EAP authentication session be interrupted due to a home 854 server failure, the session MAY be directed to an alternate server, 855 but the authentication session will have to be restarted from the 856 beginning. 858 When Diameter is used in a roaming environment, the NAS SHOULD issue 859 the EAP-Request/Identity request to the PPP client, and forward the 860 EAP-Response in the initial Diameter-EAP-Request message. This allows 861 any Diameter proxies or brokers to identify the user, and forward the 862 message to the appropriate home server. If a response is received 863 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 864 an indication that a Diameter server in the proxy chain does not 865 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 866 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 867 cautious when determining whether a less secure authentication 868 protocol will be used, since this could be a result of a bidding down 869 attack. See [28] for additional information. 871 4.1 Alternative uses 872 Currently the conversation between the backend authentication server 873 and the Diameter server is proprietary because of lack of 874 standardization. In order to increase standardization and provide 875 interoperability between Diameter vendors and backend security 876 vendors, it is recommended that Diameter-encapsulated EAP be used for 877 this conversation. 879 This has the advantage of allowing the Diameter server to support EAP 880 without the need for authentication-specific code within the Diameter 881 server. Authentication-specific code can then reside on a backend 882 authentication server instead. 884 In the case where Diameter-encapsulated EAP is used in a conversation 885 between a Diameter server and a backend authentication server, the 886 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 887 Success message without inclusion of the expected authorization AVPs 888 required in a successful response. This means that the Diameter 889 server MUST add these attributes prior to sending an Diameter-EAP- 890 Answer/EAP-Payload/EAP-Success message to the NAS. 892 4.2 Command-Codes Values 894 This section defines new Command-Code [2] values that MUST be 895 supported by all Diameter implementations conforming to this 896 specification. The following Command Codes are defined in this 897 section: 899 Command-Name Abbrev. Code Reference 900 -------------------------------------------------------- 901 Diameter-EAP-Answer DEA 269 4.2.2 902 Diameter-EAP-Ind DEI 270 4.2.3 903 Diameter-EAP-Request DER 268 4.2.1 905 4.2.1 Diameter-EAP-Request (DER) Command 907 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 908 field set to 268, is sent by a Diameter client to a Diameter server 909 and conveys an EAP-Response [25] from the dial-up PPP client. The 910 Diameter-EAP-Request MUST contain one EAP-Payload AVP, which contains 911 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent 912 to the Diameter server to initiate an EAP authentication session. 914 Upon receipt of a Diameter-EAP-Request, a Diameter server MUST issue 915 a reply. The reply may be either: 917 1) a Diameter-EAP-Ind containing an EAP-Request encapsulated 918 within an EAP-Payload attribute 919 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 920 within an EAP-Payload and a Result-Code indicating success. 921 3) a Diameter-EAP-Answer containing an EAP-Failure encapsulated 922 within an EAP-Payload and a Result-Code indicating failure. 923 4) A Message-Reject-Ind packet with a Result-Code set to 924 DIAMETER_COMMAND_UNSUPPORTED if a Diameter server does not 925 support the EAP extension. 927 Message Format 929 ::= < Diameter Header: 268 > 930 < Session-Id > 931 { Host-Name } 932 { EAP-Payload } 933 [ User-Name ] 934 [ NAS-IP-Address ] 935 [ NAS-Identifier ] 936 [ State ] 937 * [ AVP ] 938 * [ Proxy-State ] 939 * [ Route-Record ] 940 * [ Routing-Realm ] 941 0*1< Integrity-Check-Value > 943 4.2.2 Diameter-EAP-Answer (DEA) Command 945 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 946 field set to 269, is sent by the Diameter server to the client to 947 indicate either a successful or failed authentication. The Diameter- 948 EAP-Answer message SHOULD include an EAP payload of type EAP-Success 949 or EAP-Failure encapsulated within an EAP-Payload AVP. The Result- 950 Code AVP MUST indicate a failure if the EAP-Failure payload is 951 present, while the AVP MUST indicate success if the EAP-Success 952 payload is present. 954 If the message from the Diameter client included a request for 955 authorization, a successful response MUST include the authorization 956 AVPs that are relevant to the service being provided. 958 Message Format 959 ::= < Diameter Header: 269 > 960 < Session-Id > 961 { Result-Code } 962 { Host-Name } 963 [ EAP-Payload ] 964 [ User-Name ] 965 * [ AVP ] 966 * [ Proxy-State ] 967 * [ Route-Record ] 968 * [ Routing-Realm ] 969 0*1< Integrity-Check-Value > 971 4.2.3 Diameter-EAP-Ind (DEI) Command 973 The Diameter-EAP-Ind (DEI) command, indicated by the Command-Code set 974 to 270, has two uses. This message MAY be sent in response to a 975 Diameter-EAP-Request message, and MUST contain an EAP-Response 976 payload [25] encapsulated within an EAP-Payload AVP. 978 Alternatively, this message MAY also be sent unsolicited from a 979 Diameter server to a client to request re-authentication of a PPP 980 client. For re-authentication, it is recommended that the Identity 981 request be skipped in order to reduce the number of authentication 982 round trips. This is only possible when the user's identity is 983 already known by the home Diameter server. 985 Upon receipt of the message, the NAS MUST issue the EAP payload to 986 the PPP Client, and SHOULD respond with a Diameter-EAP-Request 987 containing the EAP-Response [25] packet. 989 Message Format 991 ::= 992 < Session-Id > 993 { Host-Name } 994 { EAP-Payload } 995 [ User-Name ] 996 * [ AVP ] 997 * [ Proxy-State ] 998 * [ Route-Record ] 999 * [ Routing-Realm ] 1000 0*1< Integrity-Check-Value > 1002 4.3 EAP-Payload AVP 1004 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1005 to encapsulate the actual EAP payload [25] that is being exchanged 1006 between the dial-up PPP client and the home Diameter server. 1008 5.0 Diameter Session Termination 1010 When a Network Access Server (NAS) receives an indication that a 1011 user's session is being disconnected (e.g. LCP Terminate is 1012 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1013 to its Diameter Server. This will ensure that any resources 1014 maintained on the servers is freed appropriately. 1016 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 1017 disconnect the PPP (or tunneling) session and respond with an STR 1018 message. 1020 6.0 Call and Session Information 1022 This section contains the authorization AVPs that are needed to 1023 identify call and session information, and allows the server to set 1024 constraints on a session. 1026 6.1 NAS-Port AVP 1028 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1029 physical port number of the NAS which is authenticating the user, and 1030 is normally only present in an authentication and/or authorization 1031 request. Note that this is using "port" in its sense of a physical 1032 connection on the NAS, not in the sense of a TCP or UDP port number. 1033 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1034 present in the request, if the NAS differentiates among its ports. 1036 6.2 Filter-Id AVP 1038 The Filter-Id AVP (AVP Code 11) is of type OctetString and contains 1039 the name of the filter list for this user. Zero or more Filter-Id 1040 AVPs MAY be sent in an authorization response. 1042 Identifying a filter list by name allows the filter to be used on 1043 different NASes without regard to filter-list implementation details. 1044 However, this AVP is not roaming friendly since filter naming differs 1045 from one service provider to another. 1047 In non-RADIUS environments, it is strongly recommended that the 1048 Filter-Rule AVP be used instead. 1050 6.3 Callback-Number AVP 1052 The Callback-Number AVP (AVP Code 19) is of type OctetString and 1053 contains a dialing string to be used for callback. It MAY be used in 1054 an authentication and/or authorization request as a hint to the 1055 server that a Callback service is desired, but the server is not 1056 required to honor the hint in the corresponding response. 1058 The codification of the range of allowed usage of this field is 1059 outside the scope of this specification. 1061 6.4 Callback-Id AVP 1063 The Callback-Id AVP (AVP Code 20) is of type OctetString and contains 1064 the name of a place to be called, to be interpreted by the NAS. This 1065 AVP MAY be present in an authentication and/or authorization 1066 response. 1068 This AVP is not roaming friendly since it assumes that the Callback- 1069 Id is configured on the NAS. It is therefore preferable to use the 1070 Callback-Number AVP instead. 1072 6.5 Idle-Timeout AVP 1074 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1075 maximum number of consecutive seconds of idle connection allowed to 1076 the user before termination of the session or prompt. It MAY be used 1077 in an authentication and/or authorization request (or challenge) as a 1078 hint to the server that an idle timeout is desired, but the server is 1079 not required to honor the hint in the corresponding response. 1081 6.6 Called-Station-Id AVP 1083 The Called-Station-Id AVP (AVP Code 30) is of type OctetString and 1084 allows the NAS to send in the request the phone number that the user 1085 called, using Dialed Number Identification (DNIS) or a similar 1086 technology. Note that this may be different from the phone number the 1087 call comes in on. It SHOULD only be present in authentication and/or 1088 authorization requests. 1090 If the Request-Type AVP is set to authorization-only and the User- 1091 Name AVP is absent, the Diameter Server MAY perform authorization 1092 based on this field. This can be used by a NAS to request whether a 1093 call should be answered based on the DNIS. 1095 The codification of the range of allowed usage of this field is 1096 outside the scope of this specification. 1098 6.7 Calling-Station-Id AVP 1100 The Calling-Station-Id AVP (AVP Code 31) is of type OctetString and 1101 allows the NAS to send in the request the phone number that the call 1102 came from, using Automatic Number Identification (ANI) or a similar 1103 technology. It SHOULD only be present in authentication and/or 1104 authorization requests. 1106 If the Request-Type AVP is set to authorization-only and the User- 1107 Name AVP is absent, the Diameter Server MAY perform authorization 1108 based on this field. This can be used by a NAS to request whether a 1109 call should be answered based on the ANI. 1111 The codification of the range of allowed usage of this field is 1112 outside the scope of this specification. 1114 6.8 NAS-Port-Type AVP 1116 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1117 contains the type of the physical port of the NAS which is 1118 authenticating the user. It can be used instead of or in addition to 1119 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1120 and/or authorization requests. This AVP MAY be combined with the 1121 NAS-Port AVP to assist in differentiating its ports. 1123 The following values are defined: 1124 0 Async 1125 1 Sync 1126 2 ISDN Sync 1127 3 ISDN Async V.120 1128 4 ISDN Async V.110 1129 5 Virtual 1130 6 PIAFS 1131 7 HDLC Clear Channel 1132 8 X.25 1133 9 X.75 1134 10 G.3 Fax 1135 11 SDSL - Symmetric DSL 1136 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 1137 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 1138 14 IDSL - ISDN Digital Subscriber Line 1139 15 Ethernet 1140 16 xDSL 1141 17 Cable 1142 18 Wireless - Other 1143 19 Wireless - IEEE 802.11 1145 "Virtual" refers to a connection to the NAS via some transport 1146 protocol, instead of through a physical port. For example, if a user 1147 telnetted into a NAS to authenticate himself as an Outbound-User, the 1148 request might include NAS-Port-Type = Virtual as a hint to the 1149 Diameter server that the user was not on a physical port. 1151 6.9 Port-Limit AVP 1153 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1154 maximum number of ports to be provided to the user by the NAS. It 1155 MAY be used in an authentication and/or authorization request as a 1156 hint to the server that multilink PPP [9] service is desired, but the 1157 server is not required to honor the hint in the corresponding 1158 response. 1160 6.10 Connect-Info AVP 1162 The Connect-Info AVP (AVP Code 77) is of type OctetString and is sent 1163 in the AA-Request message, and indicates the nature of the user's 1164 connection. The value consists of UTF-8 encoded 10646 characters. 1165 The connection speed SHOULD be included at the beginning of the first 1166 Connect-Info AVP in the message. If the transmit and receive 1167 connection speeds differ, they may both be included in the first AVP 1168 with the transmit speed first (the speed the NAS modem transmits at), 1169 a slash (/), the receive speed, then optionally other information. 1171 7.0 Service Specific Authorization AVPs 1173 This section contains the RADIUS authorization AVPs that are 1174 supported in the Diameter protocol. The Service-Type AVP MUST be 1175 present in all messages, and based on the value of the Service-Type 1176 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1177 present. 1179 7.1 Service-Type AVP 1181 The Service-Type AVP (AVP Code 6) is of type Unsigned32 and contains 1182 the type of service the user has requested, or the type of service to 1183 be provided. One such AVP MAY be present in an authentication and/or 1184 authorization request or response. A NAS is not required to implement 1185 all of these service types, and MUST treat unknown or unsupported 1186 Service-Types as though a response with a Result-Code other than 1187 Diameter-SUCCESS had been received instead. 1189 When used in a request, the Service-Type AVP SHOULD be considered to 1190 be a hint to the server that the NAS has reason to believe the user 1191 would prefer the kind of service indicated, but the server is not 1192 required to honor the hint. The following values have been defined 1193 for the Service-Type AVP: 1195 Login 1 1196 The user should be connected to a host. The message MAY include 1197 additional AVPs defined in section 7.3. 1199 Framed 2 1200 A Framed Protocol should be started for the User, such as PPP or 1201 SLIP. The message MAY include additional AVPs defined in section 1202 7.2, or 7.4 for tunneling services. 1204 Callback Login 3 1205 The user should be disconnected and called back, then connected to 1206 a host. The message MAY include additional AVPs defined in section 1207 7.3. 1209 Callback Framed 4 1210 The user should be disconnected and called back, then a Framed 1211 Protocol should be started for the User, such as PPP or SLIP. The 1212 message MAY include additional AVPs defined in section 7.2, or 7.4 1213 for tunneling services. 1215 Outbound 5 1216 The user should be granted access to outgoing devices. 1218 Administrative 6 1219 The user should be granted access to the administrative interface 1220 to the NAS from which privileged commands can be executed. 1222 NAS Prompt 7 1223 The user should be provided a command prompt on the NAS from which 1224 non-privileged commands can be executed. 1226 Authenticate Only 8 1227 Only Authentication is requested, and no authorization information 1228 needs to be returned in the response. 1230 Callback NAS Prompt 9 1231 The user should be disconnected and called back, then provided a 1232 command prompt on the NAS from which non-privileged commands can 1233 be executed. 1235 7.2 Framed Access Authorization AVPs 1237 This section contains the authorization AVPs that are necessary to 1238 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1239 section MAY be present in a message if the Service-Type AVP was set 1240 to "Framed" or "Callback Framed". 1242 7.2.1 Framed-Protocol AVP 1244 The Framed-Protocol AVP (AVP Code 7) is of type Unsigned32 and 1245 contains the framing to be used for framed access. This AVP MAY be 1246 present in both requests and responses. The following values are 1247 currently supported: 1249 1 PPP 1250 2 SLIP 1251 3 AppleTalk Remote Access Protocol (ARAP) 1252 4 Gandalf proprietary SingleLink/MultiLink protocol 1253 5 Xylogics proprietary IPX/SLIP 1254 6 X.75 Synchronous 1256 7.2.2 Framed-Routing AVP 1258 The Framed-Routing AVP (AVP Code 10) is of type Unsigned32 and 1259 contains the routing method for the user, when the user is a router 1260 to a network. This AVP SHOULD only be present in authorization 1261 responses. The following values are defined for this AVP: 1263 0 None 1264 1 Send routing packets 1265 2 Listen for routing packets 1266 3 Send and Listen 1268 7.2.3 Framed-MTU AVP 1270 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1271 the Maximum Transmission Unit to be configured for the user, when it 1272 is not negotiated by some other means (such as PPP). This AVP SHOULD 1273 only be present in authorization responses. The MTU value MUST be 1274 between the range of 64 and 65535. 1276 7.2.4 Framed-Compression AVP 1278 The Framed-Compression AVP (AVP Code 13) is of type Unsigned32 and 1279 contains the compression protocol to be used for the link. It MAY be 1280 used in an authorization request as a hint to the server that a 1281 specific compression type is desired, but the server is not required 1282 to honor the hint in the corresponding response. 1284 More than one compression protocol AVP MAY be sent. It is the 1285 responsibility of the NAS to apply the proper compression protocol to 1286 appropriate link traffic. 1288 The following values are defined: 1289 0 None 1290 1 VJ TCP/IP header compression [7] 1291 2 IPX header compression 1292 3 Stac-LZS compression 1294 7.2.5 IP Access 1296 The AVPs defined in this section are used when the user requests, or 1297 is being granted, access to IP. They are only present if the Framed- 1298 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1299 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1301 7.2.5.1 Framed-IP-Address AVP 1303 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1304 contains the address to be configured for the user. It MAY be used in 1305 an authorization request as a hint to the server that a specific 1306 address is desired, but the server is not required to honor the hint 1307 in the corresponding response. 1309 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1310 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1311 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1312 that the NAS should select an address for the user (e.g. Assigned 1313 from a pool of addresses kept by the NAS). 1315 7.2.5.2 Framed-IP-Netmask AVP 1317 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1318 contains the IP netmask to be configured for the user when the user 1319 is a router to a network. It MAY be used in an authorization request 1320 as a hint to the server that a specific netmask is desired, but the 1321 server is not required to honor the hint in the corresponding 1322 response. This AVP MUST be present in a response if the request 1323 included this AVP with a value of 0xFFFFFFFF. 1325 7.2.5.3 Framed-IP-Route AVP 1327 The Framed-IP-Route AVP (AVP Code 22) is of type OctetString and 1328 contains the routing information to be configured for the user on the 1329 NAS. Zero or more such AVPs MAY be present in an authorization 1330 response. 1332 The string MUST contain a destination prefix in dotted quad form 1333 optionally followed by a slash and a decimal length specifier stating 1334 how many high order bits of the prefix should be used. That is 1335 followed by a space, a gateway address in dotted quad form, a space, 1336 and one or more metrics separated by spaces. For example, 1337 "192.168.1.0/24 192.168.1.1 1". 1339 The length specifier may be omitted in which case it should default 1340 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1341 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1343 Whenever the gateway address is specified as "0.0.0.0" the IP address 1344 of the user SHOULD be used as the gateway address. 1346 7.2.6 IPX Access 1348 The AVPs defined in this section are used when the user requests, or 1349 is being granted, access to IPX. They are only present if the 1350 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics 1351 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1352 protocol, or X.75 Synchronous. 1354 7.2.6.1 Framed-IPX-Network AVP 1356 The Framed-IPX-Network AVP (AVP Code 23) is of type OctetString and 1357 contains the IPX Network number to be configured for the user. It MAY 1358 be used in an authorization request as a hint to the server that a 1359 specific address is desired, but the server is not required to honor 1360 the hint in the corresponding response. 1362 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1363 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1364 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1365 that the NAS should select an address for the user (e.g. assigned 1366 from a pool of one or more IPX networks kept by the NAS). 1368 7.2.7 Appletalk Access 1370 The AVPs defined in this section are used when the user requests, or 1371 is being granted, access to Appletalk. They are only present if the 1372 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1373 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1375 7.2.7.1 Framed-AppleTalk-Link AVP 1377 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1378 contains the AppleTalk network number which should be used for the 1379 serial link to the user, which is another AppleTalk router. This AVP 1380 MUST only be present in an authorization response and is never used 1381 when the user is not another router. 1383 Despite the size of the field, values range from zero to 65535. The 1384 special value of zero indicates that this is an unnumbered serial 1385 link. A value of one to 65535 means that the serial line between the 1386 NAS and the user should be assigned that value as an AppleTalk 1387 network number. 1389 7.2.7.2 Framed-AppleTalk-Network AVP 1391 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1392 and contains the AppleTalk Network number which the NAS should probe 1393 to allocate an AppleTalk node for the user. This AVP MUST only be 1394 present in an authorization response and is never used when the user 1395 is not another router. Multiple instances of this AVP indicate that 1396 the NAS may probe using any of the network numbers specified. 1398 Despite the size of the field, values range from zero to 65535. The 1399 special value zero indicates that the NAS should assign a network for 1400 the user, using its default cable range. A value between one and 1401 65535 (inclusive) indicates the AppleTalk Network the NAS should 1402 probe to find an address for the user. 1404 7.2.7.3 Framed-AppleTalk-Zone AVP 1406 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1407 and contains the AppleTalk Default Zone to be used for this user. 1408 This AVP MUST only be present in an authorization response. Multiple 1409 instances of this AVP in the same message are not allowed. 1411 The codification of the range of allowed usage of this field is 1412 outside the scope of this specification. 1414 7.2.8 ARAP Access 1416 The AVPs defined in this section are used when the user requests, or 1417 is being granted, access to ARAP. They are only present if the 1418 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1419 Access Protocol (ARAP). 1421 7.2.8.1 ARAP-Features AVP 1423 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1424 be present in the AA-Accept message if the Framed-Protocol AVP is set 1425 to the value of ARAP. See [32] for more information of the format of 1426 this AVP. 1428 7.2.8.2 ARAP-Zone-Access AVP 1430 The ARAP-Zone-Access AVP (AVP Code 72) is of type Unsigned32, and MAY 1431 be present in the AA-Accept message if the Framed-Protocol AVP is set 1432 to the value of ARAP. The following values are supported: 1433 1 Only allow access to default zone 1434 2 Use zone filter inclusively 1435 4 Use zone filter exclusively 1437 The value 3 is skipped, not because these are bit flags, but because 1438 3 in some ARAP implementations means "all zones" which is the same as 1439 not specifying a list at all under RADIUS. 1441 If this attribute is present and the value is 2 or 4 then a Filter-Id 1442 must also be present to name a zone list filter to apply the access 1443 flag to. 1445 7.2.8.3 ARAP-Security AVP 1447 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1448 present in the AA-Challenge-Ind message if the Framed-Protocol AVP is 1449 set to the value of ARAP. See [32] for more information of the 1450 format of this AVP. 1452 7.2.8.4 ARAP-Security-Data AVP 1453 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1454 be present in the AA-Request or AA-Challenge-Ind message if the 1455 Framed-Protocol AVP is set to the value of ARAP. This AVP contains 1456 the security module challenge or response associated with the ARAP 1457 Security Module specified in ARAP-Security. 1459 7.3 Non-Framed Access Authorization AVPs 1461 This section contains the authorization AVPs that are needed to 1462 support terminal server functionality. AVPs defined in this section 1463 MAY be present in a message if the Service-Type AVP was set to 1464 "Login" or "Callback Login". 1466 7.3.1 Login-IP-Host AVP 1468 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1469 the system with which to connect the user, when the Login-Service AVP 1470 is included. It MAY be used in an authorization request as a hint to 1471 the server that a specific host is desired, but the server is not 1472 required to honor the hint in the corresponding response. 1474 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1475 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1476 select an address. The value zero indicates that the NAS SHOULD 1477 select a host to connect the user to. 1479 7.3.2 Login-Service AVP 1481 The Login-Service AVP (AVP Code 15) is of type Unsigned32 and 1482 contains the service which should be used to connect the user to the 1483 login host. This AVP SHOULD only be present in authorization 1484 responses. 1486 The following values are defined: 1487 0 Telnet 1488 1 Rlogin 1489 2 TCP Clear 1490 3 PortMaster (proprietary) 1491 4 LAT 1492 5 X25-PAD 1493 6 X25-T3POS 1494 8 TCP Clear Quiet (supresses any NAS-generated connect string) 1496 7.3.3 TCP Services 1497 The AVP described in this section MAY be present if the Login-Service 1498 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1500 7.3.3.1 Login-TCP-Port AVP 1502 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1503 contains the TCP port with which the user is to be connected, when 1504 the Login-Service AVP is also present. This AVP SHOULD only be 1505 present in authorization responses. The value MUST NOT be greater 1506 than 65535. 1508 7.3.4 LAT Services 1510 The AVP described in this section MAY be present if the Login-Service 1511 AVP is set to LAT. 1513 7.3.4.1 Login-LAT-Service AVP 1515 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1516 contains the system with which the user is to be connected by LAT. It 1517 MAY be used in an authorization request as a hint to the server that 1518 a specific service is desired, but the server is not required to 1519 honor the hint in the corresponding response. This AVP MUST only be 1520 present in the response if the Login-Service AVP states that LAT is 1521 desired. 1523 Administrators use the service attribute when dealing with clustered 1524 systems, such as a VAX or Alpha cluster. In such an environment 1525 several different time sharing hosts share the same resources (disks, 1526 printers, etc.), and administrators often configure each to offer 1527 access (service) to each of the shared resources. In this case, each 1528 host in the cluster advertises its services through LAT broadcasts. 1530 Sophisticated users often know which service providers (machines) are 1531 faster and tend to use a node name when initiating a LAT connection. 1532 Alternately, some administrators want particular users to use certain 1533 machines as a primitive form of load balancing (although LAT knows 1534 how to do load balancing itself). 1536 The String field contains the identity of the LAT service to use. 1537 The LAT Architecture allows this string to contain $ (dollar), - 1538 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1539 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1540 string comparisons are case insensitive. 1542 7.3.4.2 Login-LAT-Node AVP 1544 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1545 contains the Node with which the user is to be automatically 1546 connected by LAT. It MAY be used in an authorization request as a 1547 hint to the server that a specific LAT node is desired, but the 1548 server is not required to honor the hint in the corresponding 1549 response. This AVP MUST only be present in a response if the 1550 Service-Type AVP is set to LAT. 1552 The String field contains the identity of the LAT service to use. 1553 The LAT Architecture allows this string to contain $ (dollar), - 1554 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1555 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1556 string comparisons are case insensitive. 1558 7.3.4.3 Login-LAT-Group AVP 1560 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1561 contains a string identifying the LAT group codes which this user is 1562 authorized to use. It MAY be used in an authorization request as a 1563 hint to the server that a specific group is desired, but the server 1564 is not required to honor the hint in the corresponding response. This 1565 AVP MUST only be present in a response if the Service-Type AVP is set 1566 to LAT. 1568 LAT supports 256 different group codes, which LAT uses as a form of 1569 access rights. LAT encodes the group codes as a 256 bit bitmap. 1571 Administrators can assign one or more of the group code bits at the 1572 LAT service provider; it will only accept LAT connections that have 1573 these group codes set in the bit map. The administrators assign a 1574 bitmap of authorized group codes to each user; LAT gets these from 1575 the operating system, and uses these in its requests to the service 1576 providers. 1578 The codification of the range of allowed usage of this field is 1579 outside the scope of this specification. 1581 7.3.4.4 Login-LAT-Port AVP 1583 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1584 contains the Port with which the user is to be connected by LAT. It 1585 MAY be used in an authorization request as a hint to the server that 1586 a specific port is desired, but the server is not required to honor 1587 the hint in the corresponding response. This AVP MUST only be present 1588 in a response if the Service-Type AVP is set to LAT. 1590 The String field contains the identity of the LAT service to use. 1591 The LAT Architecture allows this string to contain $ (dollar), - 1592 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1593 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1594 string comparisons are case insensitive. 1596 7.4 Tunneling AVP 1598 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1599 used to describe a tunnel. Its Data field has the following ABNF 1600 grammar: 1602 Tunneling = Type Medium Cep Sep Pw Gid Aid Pref Caid Said 1603 Type = Tunnel-Type ; See Section 7.4.1 1604 Medium = Tunnel-Medium-Type ; See Section 7.4.2 1605 Cep = Tunnel-Client-Endpoint ; See Section 7.4.3 1606 Sep = Tunnel-Server-Endpoint ; See Section 7.4.4 1607 Pw = Tunnel-Password ; See Section 7.4.5 1608 Gid = Tunnel-Private-Group-ID ; See Section 7.4.6 1609 Aid = Tunnel-Assignment-ID ; See Section 7.4.7 1610 Pref = Tunnel-Preference ; See Section 7.4.8 1611 Caid = Tunnel-Client-Auth-ID ; See Section 7.4.9 1612 Said = Tunnel-Server-Auth-ID ; See Section 7.1.4.10 1614 +---------------------------------------------------------------+ 1615 | AVP Header (AVP Code = TBD) | 1616 +---------------------------------------------------------------+ 1617 | Tunnel-Type AVP | 1618 +---------------------------------------------------------------+ 1619 | Tunnel-Medium-Type AVP | 1620 +---------------------------------------------------------------+ 1621 | Tunnel-Client-Endpoint AVP | 1622 +---------------------------------------------------------------+ 1623 | Tunnel-Server-Endpoint AVP | 1624 +---------------------------------------------------------------+ 1625 | Tunnel-Password AVP | 1626 +---------------------------------------------------------------+ 1627 | Tunnel-Private-Group-Id AVP | 1628 +---------------------------------------------------------------+ 1629 | Tunnel-Assignment-ID AVP | 1630 +---------------------------------------------------------------+ 1631 | Tunnel-Preference AVP | 1632 +---------------------------------------------------------------+ 1633 | Tunnel-Client-Auth-ID AVP | 1634 +---------------------------------------------------------------+ 1635 | Tunnel-Server-Auth-ID AVP | 1636 +---------------------------------------------------------------+ 1638 7.4.1 Tunnel-Type AVP 1640 The Tunnel-Type AVP (AVP Code 64) is of type Unsigned32 and contains 1641 the tunneling protocol(s) to be used (in the case of a tunnel 1642 initiator) or the the tunneling protocol in use (in the case of a 1643 tunnel terminator). It MAY be used in an authorization request as a 1644 hint to the server that a specific tunnel type is desired, but the 1645 server is not required to honor the hint in the corresponding 1646 response. 1648 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1649 Record within the Accounting-Request. 1651 A tunnel initiator is not required to implement any of these tunnel 1652 types; if a tunnel initiator receives a response that contains only 1653 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1654 as though a response was received with the Result-Code indicating a 1655 failure. 1657 The following values have been defined: 1658 1 Point-to-Point Tunneling Protocol (PPTP) [14] 1659 2 Layer Two Forwarding (L2F) [15] 1660 3 Layer Two Tunneling Protocol (L2TP) [16] 1661 4 Ascend Tunnel Management Protocol (ATMP) [17] 1662 5 Virtual Tunneling Protocol (VTP) 1663 6 IP Authentication Header in the Tunnel-mode (AH) [18] 1664 7 IP-in-IP Encapsulation (IP-IP) [19] 1665 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 1666 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [21] 1667 10 Generic Route Encapsulation (GRE) [22] 1668 11 Bay Dial Virtual Services (DVS) 1669 12 IP-in-IP Tunneling [23] 1671 7.4.2 Tunnel-Medium-Type AVP 1673 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and 1674 contains the transport medium to use when creating a tunnel for those 1675 protocols (such as L2TP) that can operate over multiple transports. 1676 It MAY be used in an authorization request as a hint to the server 1677 that a specific medium is desired, but the server is not required to 1678 honor the hint in the corresponding response. 1680 The Value field is three octets and contains one of the values listed 1681 under "Address Family Numbers" in [10]. The value of most importance 1682 is (1) for IPv4 and (2) for IPv6. 1684 7.4.3 Tunnel-Client-Endpoint AVP 1686 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type OctetString 1687 and contains the address of the initiator end of the tunnel. It MAY 1688 be used in an authorization request as a hint to the server that a 1689 specific endpoint is desired, but the server is not required to honor 1690 the hint in the corresponding response. 1692 This AVP SHOULD be included in the ADIF Record of the corresponding 1693 Accounting-Request messages, in which case it indicates the address 1694 from which the tunnel was initiated. This AVP, along with the 1695 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1696 a globally unique means to identify a tunnel for accounting and 1697 auditing purposes. 1699 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1700 fully qualified domain name (FQDN) of the tunnel client machine, or 1701 it is a "dotted-decimal" IP address. Conformant implementations MUST 1702 support the dotted-decimal format and SHOULD support the FQDN format 1703 for IP addresses. 1705 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1706 FQDN of the tunnel client machine, or it is a text representation of 1707 the address in either the preferred or alternate form [5]. 1708 Conformant implementations MUST support the preferred form and SHOULD 1709 support both the alternate text form and the FQDN format for IPv6 1710 addresses. 1712 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1713 referring to configuration data local to the Diameter client that 1714 describes the interface and medium-specific address to use. 1716 7.4.4 Tunnel-Server-Endpoint AVP 1718 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of OctetString and 1719 contains the address of the server end of the tunnel. It MAY be used 1720 in an authorization request as a hint to the server that a specific 1721 endpoint is desired, but the server is not required to honor the hint 1722 in the corresponding response. 1724 This AVP SHOULD be included in the ADIF Record of the corresponding 1725 Accounting-Request messages, in which case it indicates the address 1726 from which the tunnel was initiated. This AVP, along with the 1727 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1728 a globally unique means to identify a tunnel for accounting and 1729 auditing purposes. 1731 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1732 fully qualified domain name (FQDN) of the tunnel client machine, or 1733 it is a "dotted-decimal" IP address. Conformant implementations MUST 1734 support the dotted-decimal format and SHOULD support the FQDN format 1735 for IP addresses. 1737 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1738 FQDN of the tunnel client machine, or it is a text representation of 1739 the address in either the preferred or alternate form [5]. 1740 Conformant implementations MUST support the preferred form and SHOULD 1741 support both the alternate text form and the FQDN format for IPv6 1742 addresses. 1744 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1745 referring to configuration data local to the Diameter client that 1746 describes the interface and medium-specific address to use. 1748 7.4.5 Tunnel-Password AVP 1750 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1751 contain a password to be used to authenticate to a remote server. 1752 This AVP MUST only be present in authorization responses in an 1753 encrypted form, using one of the methods described in [2] and [13]. 1755 7.4.6 Tunnel-Private-Group-ID AVP 1757 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type OctetString 1758 and contains the group ID for a particular tunneled session. The 1759 Tunnel-Private-Group-ID AVP MAY be included in an authorization 1760 request if the tunnel initiator can pre-determine the group resulting 1761 from a particular connection and SHOULD be included in the 1762 authorization response if this tunnel session is to be treated as 1763 belonging to a particular private group. Private groups may be used 1764 to associate a tunneled session with a particular group of users. 1765 For example, it MAY be used to facilitate routing of unregistered IP 1766 addresses through a particular interface. This value SHOULD be 1767 included the corresponding ADIF-Record in the Accounting-Request 1768 which pertain to a tunneled session. 1770 7.4.7 Tunnel-Assignment-ID AVP 1772 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1773 is used to indicate to the tunnel initiator the particular tunnel to 1774 which a session is to be assigned. Some tunneling protocols, such as 1775 PPTP and L2TP, allow for sessions between the same two tunnel 1776 endpoints to be multiplexed over the same tunnel and also for a given 1777 session to utilize its own dedicated tunnel. This attribute provides 1778 a mechanism for Diameter to be used to inform the tunnel initiator 1779 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1780 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1781 sharing multiplexed tunnels to be assigned to different multiplexed 1782 tunnels. 1784 A particular tunneling implementation may assign differing 1785 characteristics to particular tunnels. For example, different 1786 tunnels may be assigned different QOS parameters. Such tunnels may 1787 be used to carry either individual or multiple sessions. The 1788 Tunnel-Assignment-ID attribute thus allows the Diameter server to 1789 indicate that a particular session is to be assigned to a tunnel that 1790 provides an appropriate level of service. It is expected that any 1791 QOS-related Diameter tunneling attributes defined in the future that 1792 accompany this attribute will be associated by the tunnel initiator 1793 with the ID given by this attribute. In the meantime, any semantic 1794 given to a particular ID string is a matter left to local 1795 configuration in the tunnel initiator. 1797 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1798 the tunnel initiator. The ID it specifies is intended to be of only 1799 local use to Diameter and the tunnel initiator. The ID assigned by 1800 the tunnel initiator is not conveyed to the tunnel peer. 1802 This attribute MAY be included in authorization responses. The tunnel 1803 initiator receiving this attribute MAY choose to ignore it and assign 1804 the session to an arbitrary multiplexed or non-multiplexed tunnel 1805 between the desired endpoints. This attribute SHOULD also be 1806 included in the corresponding ADIF-Record in the Accounting-Request 1807 messages which pertain to a tunneled session. 1809 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1810 should assign a session to a tunnel in the following manner: 1812 - If this AVP is present and a tunnel exists between the specified 1813 endpoints with the specified ID, then the session should be 1814 assigned to that tunnel. 1816 - If this AVP is present and no tunnel exists between the 1817 specified endpoints with the specified ID, then a new tunnel 1818 should be established for the session and the specified ID 1819 should be associated with the new tunnel. 1821 - If this AVP is not present, then the session is assigned to an 1822 unnamed tunnel. If an unnamed tunnel does not yet exist between 1823 the specified endpoints then it is established and used for this 1824 and subsequent sessions established without the Tunnel- 1825 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1826 session for which a Tunnel-Assignment-ID AVP was not specified 1827 to a named tunnel (i.e. one that was initiated by a session 1828 specifying this AVP). 1830 Note that the same ID may be used to name different tunnels if such 1831 tunnels are between different endpoints. 1833 7.4.8 Tunnel-Preference AVP 1835 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1836 used to identify the relative preference assigned to each tunnel when 1837 more than one set of tunneling AVPs is returned within separete 1838 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1839 hint to the server that a specific preference is desired, but the 1840 server is not required to honor the hint in the corresponding 1841 response. 1843 For example, suppose that AVPs describing two tunnels are returned by 1844 the server, one with a Tunnel-Type of PPTP and the other with a 1845 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1846 the Tunnel-Types returned, it will initiate a tunnel of that type. 1847 If, however, it supports both tunnel protocols, it SHOULD use the 1848 value of the Tunnel-Preference AVP to decide which tunnel should be 1849 started. The tunnel having the numerically lowest value in the Value 1850 field of this AVP SHOULD be given the highest preference. The values 1851 assigned to two or more instances of the Tunnel-Preference AVP within 1852 a given authorization response MAY be identical. In this case, the 1853 tunnel initiator SHOULD use locally configured metrics to decide 1854 which set of AVPs to use. 1856 7.4.9 Tunnel-Client-Auth-ID AVP 1858 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1859 specifies the name used by the tunnel initiator during the 1860 authentication phase of tunnel establishment. It MAY be used in an 1861 authorization request as a hint to the server that a specific 1862 preference is desired, but the server is not required to honor the 1863 hint in the corresponding response. This AVP MUST be present in the 1864 authorization response if an authentication name other than the 1865 default is desired. This AVP SHOULD be included in the corresponding 1866 ADIF-Record of the Accounting-Request messages which pertain to a 1867 tunneled session. 1869 7.4.10 Tunnel-Server-Auth-ID AVP 1871 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1872 and specifies the name used by the tunnel terminator during the 1873 authentication phase of tunnel establishment. It MAY be used in an 1874 authorization request as a hint to the server that a specific 1875 preference is desired, but the server is not required to honor the 1876 hint in the corresponding response. This AVP MUST be present in the 1877 authorization response if an authentication name other than the 1878 default is desired. This AVP SHOULD be included in the corresponding 1879 ADIF-Record of the Accounting-Request messages which pertain to a 1880 tunneled session. 1882 8.0 Accounting Considerations 1884 This section contains a description of the AVPs defined in this 1885 document that are to be included in Diameter accounting messages 1886 [29]. 1888 8.1 Framed Access 1889 This section contains the AVPs defined in this extension that are to 1890 be present in the Accounting-Request and optionally in the 1891 Accounting-Answer messages, defined in [29], when the Service-Type 1892 AVP specifies Framed service. 1894 ::= { Service-Type } 1895 { Framed-Protocol } 1896 [ Framed-IP-Address ] 1897 [ Framed-IP-Netmask ] 1898 [ Framed-Routing ] 1899 [ Framed-MTU ] 1900 [ Framed-Compression ] 1901 [ Framed-Route ] 1902 [ Framed-IPX-Network ] 1903 [ Framed-AppleTalk-Link ] 1904 [ Framed-AppleTalk-Network ] 1905 [ Framed-AppleTalk-Zone ] 1907 8.2 Non-Framed Access 1909 This section contains the AVPs defined in this extension that are to 1910 be present in the Accounting-Request and optionally in the 1911 Accounting-Answer messages, defined in [29], when the Service-Type 1912 AVP specifies non-Framed service. 1914 ::= { Service-Type } 1915 { Login-Service } 1916 [ Login-IP-Host ] 1917 [ Login-TCP-Port ] 1918 [ Login-LAT-Service ] 1919 [ Login-LAT-Node ] 1920 [ Login-LAT-Group ] 1921 [ Login-LAT-Port ] 1923 8.3 Tunneling 1925 Additional work is required to identify how to integrate tunneling in 1926 the Accounting extension. One method is as defined in [34], which 1927 would require new Accounting-Type messages (e.g. tunnel and link 1928 start/stop). 1930 9.0 Interactions with Resource Management 1932 The Resource Management extension [31] provides the ability for a 1933 Diameter node to query a peer for session state information. The 1934 document states that service-specific extensions are responsible for 1935 specifying what AVPs are to be present in the Resource-Token [31] 1936 AVP. 1938 In addition to the AVPs listed in [31], the Resource-Token with the 1939 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1940 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1941 IPX-Network MUST be present if the corresponding network is being 1942 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1943 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1944 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1945 AVPs MUST be present. 1947 10.0 AVP Table 1949 The following table presents the AVPs defined in this document, and 1950 specifies in which Diameter messages they MAY, or MAY NOT be present. 1951 Note that AVPs that can only be present within a Grouped AVP are not 1952 represented in this table. 1954 The table uses the following symbols: 1955 0 The AVP MUST NOT be present in the message. 1956 0+ Zero or more instances of the AVP MAY be present in the 1957 message. 1958 0-1 Zero or one instance of the AVP MAY be present in the 1959 message. 1960 1 One instance of the AVP MUST be present in the message. 1962 +-----------------------------------+ 1963 | Command-Code | 1964 |-----+-----+-----+-----+-----+-----+ 1965 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 1966 ------------------------------|-----+-----+-----+-----+-----|-----| 1967 ARAP-Challenge-Response | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1968 ARAP-Features | 0 | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 1969 ARAP-Password | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1970 ARAP-Security | 0-1 | 0 | 0-1 | 0-1 | 0 | 0-1 | 1971 ARAP-Security-Data | 0+ | 0 | 0 | 0+ | 0 | 0 | 1972 ARAP-Zone-Access | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1973 Callback-Id | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1974 Callback-Number | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 1975 Called-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1976 Calling-Station-Id | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1977 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 0 | 0 | 1978 CHAP-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 1979 Class | 0 | 0+ | 0 | 0 | 0+ | 0 | 1980 Connect-Info | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1981 +-----------------------------------+ 1982 | Command-Code | 1983 |-----+-----+-----+-----+-----+-----+ 1984 Attribute Name | AAA | AAR | ACI | DER | DEA | DEI | 1985 ------------------------------|-----+-----+-----+-----+-----|-----| 1986 EAP-Payload | 0 | 0 | 0 | 1 | 1 | 1 | 1987 Filter-Id | 0 | 0+ | 0 | 0 | 0+ | 0 | 1988 Filter-Rule | 0 | 0+ | 0 | 0 | 0+ | 0 | 1989 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1990 Framed-Appletalk-Network | 0 | 0+ | 0 | 0 | 0+ | 0 | 1991 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1992 Framed-Compression | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 1993 Framed-IP-Address | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1994 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0-1 | 0-1 | 0 | 1995 Framed-IP-Route | 0 | 0+ | 0 | 0 | 0+ | 0 | 1996 Framed-IPX-Network | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1997 Framed-MTU | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 1998 Framed-Protocol | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 1999 Framed-Routing | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2000 Host-Name | 1 | 1 | 1 | 1 | 1 | 1 | 2001 Integrity-Check-Value | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2002 Idle-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2003 Login-IP-Host | 0+ | 0+ | 0 | 0 | 0 | 0 | 2004 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2005 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2006 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2007 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 0 | 0 | 2008 Login-Service | 0 | 0+ | 0 | 0 | 0 | 0 | 2009 Login-TCP-Port | 0 | 0+ | 0 | 0 | 0 | 0 | 2010 NAS-IP-Address | 1 | 0 | 0 | 1 | 0 | 0 | 2011 NAS-Port | 1 | 0 | 0 | 1 | 0 | 0 | 2012 NAS-Port-Type | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2013 Password-Retry | 0 | 0-1 | 0 | 0 | 0 | 0 | 2014 Port-Limit | 0-1 | 0 | 0 | 0-1 | 0 | 0 | 2015 Prompt | 0 | 0 | 0-1 | 0 | 0 | 0 | 2016 Proxy-State | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2017 Reply-Message | 0 | 0 | 0+ | 0 | 0 | 0 | 2018 Request-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2019 Result-Code | 0 | 1 | 0 | 0 | 1 | 0 | 2020 Route-Record | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2021 Routing-Realm | 0+ | 0+ | 0+ | 0+ | 0+ | 0+ | 2022 Service-Type | 1 | 1 | 0 | 1 | 1 | 0 | 2023 Session-Id | 1 | 1 | 1 | 1 | 1 | 1 | 2024 Session-Timeout | 0 | 0-1 | 0 | 0 | 0-1 | 0 | 2025 State | 0-1 | 0-1 | 0-1 | 0 | 0-1 | 0 | 2026 Tunneling | 0+ | 0+ | 0 | 0+ | 0+ | 0 | 2027 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 0-1 | 2028 User-Password | 0-1 | 0 | 0 | 0 | 0 | 0 | 2030 11.0 IANA Considerations 2032 The command codes defined in Sections 3.1 and 4.2 are values taken 2033 from the Command-Code [2] address space and extended in [13], [29] 2034 and [30]. IANA should record the values as defined in Sections 2.1 2035 and 4.2. 2037 The AVPs defined in section 2.1 were alllocated from from the AVP 2038 numbering space defined in [2], and extended in [13], [29], and [30]. 2039 IANA should record the values as defined in Sections 2.1. 2041 The Diameter base protocol [2] reserves the first 255 AVPs for legacy 2042 RADIUS support [1]. The AVPs defined in section 2.2 are defined in 2043 [1] and [32], and no number assignment is necessary. 2045 11.1 Request-Type AVP Values 2047 The Request-Type AVP (section 2.1.1) has a set of values that MUST be 2048 maintained by IANA. Values 1 through 3 are defined in this document. 2049 The remaining values are available for assignment via Designated 2050 Expert [27]. 2052 12.0 Security Considerations 2054 This document does not contain any security protocol, but does 2055 discuss how PPP authentication protocols can be carried within the 2056 Diameter protocol. The PPP authentication protocols that are 2057 described are PAP, CHAP and EAP. 2059 The use of PAP SHOULD be discouraged, since it exposes user's 2060 passwords to possibly non-trusted entities. PAP is also frequently 2061 used for use with One-Time Passwords (OTP), which does not expose any 2062 security risks. However, it is highly recommended that OTP be 2063 supported through the EAP protocol. 2065 This document also describes how CHAP can be carried within the 2066 Diameter protocol, which is required for backward RADIUS 2067 compatibility. The CHAP protocol, as used in a RADIUS environment, 2068 facilitates authentication replay attacks, and therefore SHOULD NOT 2069 be used when EAP is available. 2071 13.0 References 2073 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 2075 [2] Calhoun, Rubens, Akhtar, Guttman, "Diameter Base Protocol", 2076 draft-ietf-aaa-diameter-00.txt, IETF work in progress, February 2077 2001. 2079 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 2080 ary 1999. 2082 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2083 2477, January 1999. 2085 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2086 RFC 2373, July 1998 2088 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2089 (CHAP)", RFC 1994, August 1996. 2091 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2092 links", RFC 1144, February 1990. 2094 [8] ISO 8859. International Standard -- Information Processing -- 2095 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2096 Alphabet No. 1, ISO 8859-1:1987. 2097 2099 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2100 (MP)", RFC 1717, November 1994. 2102 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2103 October 1994 2105 [11] Calhoun, Zorn, Pan, Akhtar, "Diameter Framework", draft-ietf- 2106 aaa-diameter-framework-00.txt, IETF work in progress, February 2107 2001. 2109 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2110 Levels", BCP 14, RFC 2119, March 1997. 2112 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security 2113 Extension", draft-calhoun-diameter-strong-crypto-06.txt, IETF 2114 work in progress, February 2001. 2116 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2117 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2118 July 1999 2120 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 2121 warding (Protocol) 'L2F'", RFC 2341, May 1998 2123 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 2124 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 2125 August 1999 2127 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2128 2107, February 1997 2130 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2131 Protocol", RFC 2401, November 1998 2133 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2134 1996 2136 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2137 October 1996 2139 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2140 1827, August 1995 2142 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2143 Encapsulation (GRE)", RFC 1701, October 1994 2145 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2147 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2148 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2149 in progress, June 2000. 2151 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 2152 Protocol (EAP)." RFC 2284, March 1998. 2154 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 2155 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 2156 1999. 2158 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 2159 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2161 [28] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 2162 Haag, "Diameter Implementation Guidelines", draft-ietf-aaa- 2163 diameter-impl-guide-00.txt, IETF work in progress, June 2000. 2165 [29] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "Diameter Accounting 2166 Extension", draft-ietf-aaa-diameter-accounting-00.txt, IETF work 2167 in progress, February 2001. 2169 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- 2170 ietf-aaa-diameter-mobileip-00.txt, IETF work in progress, 2171 February 2001. 2173 [31] P. Calhoun, "Diameter Resource Management", draft-calhoun- 2174 diameter-res-mgmt-06.txt, IETF Work in Progress, February 2001. 2176 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2177 2869, June 2000. 2179 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2180 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2181 June 2000. 2183 [24] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications 2184 for Tunnel Protocol Support", RFC 2867, June 2000. 2186 14.0 Acknowledgements 2188 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2189 Allen Simpson, and Steve Willens for their work on the original 2190 RADIUS, from which much of the concepts in this specification were 2191 derived from. Also Carl Rigney and Ward Willats for [32], and Glen 2192 Zorn, Dory Leifer, Allan C. Rubens, John Shriver, Matt Holdrege and 2193 Ignacio Goyret for their work on [33]. This document stole text and 2194 concepts from both [32] and [33]. 2196 The authors would also like to acknowledge the following people for 2197 their contribution in the development of the Diameter protocol: 2199 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2200 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2201 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2202 and Jeff Weisberg 2204 15.0 Authors' Addresses 2206 Questions about this memo can be directed to: 2208 Pat R. Calhoun 2209 Network and Security Research Center, Sun Labs 2210 Sun Microsystems, Inc. 2211 15 Network Circle 2212 Menlo Park, California, 94025 2213 USA 2215 Phone: +1 650-786-7733 2216 Fax: +1 650-786-6445 2218 E-mail: pcalhoun@eng.sun.com 2220 William Bulley 2221 Merit Network, Inc. 2222 Building One, Suite 2000 2223 4251 Plymouth Road 2224 Ann Arbor, Michigan 48105-2785 2225 USA 2227 Phone: +1 734-764-9993 2228 Fax: +1 734-647-3185 2229 E-mail: web@merit.edu 2231 Allan C. Rubens 2232 Tut Systems, Inc. 2233 220 E. Huron, Suite 260 2234 Ann Arbor, MI 48104 2235 USA 2237 Phone: +1 734-995-1697 2238 E-Mail: arubens@tutsys.com 2240 Jeff Haag 2241 Cisco Systems 2242 7025 Kit Creek Road 2243 PO Box 14987 2244 Research Triangle Park, NC 27709 2246 Phone: 1-919-392-2353 2247 E-Mail: haag@cisco.com 2249 Glen Zorn 2250 Cisco Systems, Inc. 2251 500 108th Avenue N.E., Suite 500 2252 Bellevue, WA 98004 2253 USA 2255 Phone: +1 425 438 8218 2256 E-Mail: gwz@cisco.com 2258 16.0 Full Copyright Statement 2260 Copyright (C) The Internet Society (2001). All Rights Reserved. 2262 This document and translations of it may be copied and furnished to 2263 others, and derivative works that comment on or otherwise explain it 2264 or assist in its implementation may be prepared, copied, published 2265 and distributed, in whole or in part, without restriction of any 2266 kind, provided that the above copyright notice and this paragraph are 2267 included on all such copies and derivative works. However, this docu- 2268 ment itself may not be modified in any way, such as by removing the 2269 copyright notice or references to the Internet Society or other 2270 Internet organizations, except as needed for the purpose of develop- 2271 ing Internet standards in which case the procedures for copyrights 2272 defined in the Internet Standards process must be followed, or as 2273 required to translate it into languages other than English. The lim- 2274 ited permissions granted above are perpetual and will not be revoked 2275 by the Internet Society or its successors or assigns. This document 2276 and the information contained herein is provided on an "AS IS" basis 2277 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2278 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2279 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2280 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2281 FITNESS FOR A PARTICULAR PURPOSE. 2283 17.0 Expiration Date 2285 This memo is filed as and 2286 expires in July 2001.