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