idnits 2.17.1 draft-ietf-aaa-diameter-nasreq-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 55 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 56 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 25 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 662 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 (June 2001) is 8323 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 2349, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2361, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2385, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2389, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 2396, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2399, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2402, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2408, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2411, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2414, but no explicit reference was found in the text == Unused Reference: '28' is defined on line 2430, but no explicit reference was found in the text == Unused Reference: '30' is defined on line 2436, but no explicit reference was found in the text == Unused Reference: '31' is defined on line 2440, but no explicit reference was found in the text == Unused Reference: '35' is defined on line 2454, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-05 ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') ** Obsolete normative reference: RFC 2373 (ref. '5') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '11') == Outdated reference: A later version (-04) exists of draft-ietf-aaa-diameter-cms-sec-00 -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '17') ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '24') ** Obsolete normative reference: RFC 2284 (ref. '25') (Obsoleted by RFC 3748) -- Possible downref: Normative reference to a draft: ref. '26' ** Obsolete normative reference: RFC 2434 (ref. '27') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2867, mentioned in '28', was also mentioned in '11'. ** Downref: Normative reference to an Informational RFC: RFC 2867 (ref. '28') ** Obsolete normative reference: RFC 2279 (ref. '29') (Obsoleted by RFC 3629) == Outdated reference: A later version (-20) exists of draft-ietf-aaa-diameter-mobileip-05 ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '31') ** Downref: Normative reference to an Informational RFC: RFC 2869 (ref. '32') -- Duplicate reference: RFC2868, mentioned in '33', was also mentioned in '31'. ** Downref: Normative reference to an Informational RFC: RFC 2868 (ref. '33') -- Possible downref: Non-RFC (?) normative reference: ref. '34' ** Downref: Normative reference to an Informational RFC: RFC 2866 (ref. '35') ** Obsolete normative reference: RFC 2402 (ref. '37') (Obsoleted by RFC 4302, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 3078 (ref. '38') Summary: 29 errors (**), 0 flaws (~~), 28 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 June 2001 13 Diameter NASREQ Application 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 application that is used for AAA 47 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 48 application, 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 application was carefully designed to ease the burden of servers that 55 must perform protocol conversion between RADIUS and Diameter. This 56 is achieved by re-using the RADIUS address space, eliminating the 57 need to perform attribute lookups. 59 Table of Contents 61 1.0 Introduction 62 1.1 Requirements language 63 1.2 Advertising application support 64 2.0 Supported AVPs 65 2.1 Diameter AVPs 66 2.1.1 Request-Type AVP 67 2.1.2 Filter-Rule AVP 68 2.1.3 NAS-Session-Key AVP 69 2.1.4 NAS-Key-Direction AVP 70 2.1.5 NAS-Key-Type AVP 71 2.1.6 NAS-Key-Data AVP 72 2.1.7 NAS-Key-Binding AVP 73 2.2 Legacy RADIUS Attributes 74 2.2.1 NAS-IP-Address AVP 75 2.2.2 NAS-Identifier AVP 76 2.2.3 State AVP 77 2.2.4 Class AVP 78 3.0 Legacy RADIUS Authentication Support 79 3.1 Command-Codes Values 80 3.1.1 AA-Request (AAR) Command 81 3.1.1.1 User-Password AVP 82 3.1.1.2 CHAP-Password AVP 83 3.1.1.3 CHAP-Challenge AVP 84 3.1.1.4 ARAP-Password AVP 85 3.1.2 AA-Answer (AAA) Command 86 3.1.2.1 ARAP-Challenge-Response AVP 87 3.1.2.2 Password-Retry AVP 88 3.1.2.3 Prompt AVP 89 3.2 Reply-Message AVP 90 4.0 Extensible Authentication Protocol Support 91 4.1 Alternative Uses 92 4.2 Command-Codes Values 93 4.2.1 Diameter-EAP-Request (DER) Command 94 4.2.2 Diameter-EAP-Answer (DEA) Command 95 4.3 EAP-Payload AVP 96 5.0 Diameter Session Termination 97 6.0 Call and Session Information 98 6.1 NAS-Port AVP 99 6.2 Filter-Id AVP 100 6.3 Callback-Number AVP 101 6.4 Callback-Id AVP 102 6.5 Idle-Timeout AVP 103 6.6 Called-Station-Id AVP 104 6.7 Calling-Station-Id AVP 105 6.8 NAS-Port-Type AVP 106 6.9 Port-Limit AVP 107 6.10 Connect-Info AVP 108 7.0 Service Specific Authorization AVPs 109 7.1 Service-Type AVP 110 7.2 Framed Access Authorization AVPs 111 7.2.1 Framed-Protocol AVP 112 7.2.2 Framed-Routing AVP 113 7.2.3 Framed-MTU AVP 114 7.2.4 Framed-Compression AVP 115 7.2.5 IP Access 116 7.2.5.1 Framed-IP-Address AVP 117 7.2.5.2 Framed-IP-Netmask AVP 118 7.2.5.3 Framed-IP-Route AVP 119 7.2.6 IPX Access 120 7.2.6.1 Framed-IPX-Network AVP 121 7.2.7 Appletalk Access 122 7.2.7.1 Framed-AppleTalk-Link AVP 123 7.2.7.2 Framed-AppleTalk-Network AVP 124 7.2.7.3 Framed-AppleTalk-Zone AVP 125 7.2.8 ARAP Access 126 7.2.8.1 ARAP-Features AVP 127 7.2.8.2 ARAP-Zone-Access AVP 128 7.2.8.3 ARAP-Security AVP 129 7.2.8.4 ARAP-Security-Data AVP 130 7.3 Non-Framed Access Authorization AVPs 131 7.3.1 Login-IP-Host AVP 132 7.3.2 Login-Service AVP 133 7.3.3 TCP Services 134 7.3.3.1 Login-TCP-Port AVP 135 7.3.4 LAT Services 136 7.3.4.1 Login-LAT-Service AVP 137 7.3.4.2 Login-LAT-Node AVP 138 7.3.4.3 Login-LAT-Group AVP 139 7.3.4.4 Login-LAT-Port AVP 140 7.4 Tunneling AVP 141 7.4.1 Tunnel-Type AVP 142 7.4.2 Tunnel-Medium-Type AVP 143 7.4.3 Tunnel-Client-Endpoint AVP 144 7.4.4 Tunnel-Server-Endpoint AVP 145 7.4.5 Tunnel-Password AVP 146 7.4.6 Tunnel-Private-Group-ID AVP 147 7.4.7 Tunnel-Assignment-ID AVP 148 7.4.8 Tunnel-Preference AVP 149 7.4.9 Tunnel-Client-Auth-ID AVP 150 7.4.10 Tunnel-Server-Auth-ID AVP 151 8.0 Accounting Considerations 152 8.1 Accounting-Input-Octets AVP 153 8.2 Accounting-Output-Octets AVP 154 8.3 Accounting-Session-Time AVP 155 8.4 Accounting-Input-Packets AVP 156 8.5 Accounting-Output-Packets AVP 157 8.6 Accounting-Authentication-Type AVP 158 8.7 Acct-Tunnel-Connection AVP 159 8.8 Acct-Tunnel-Packets-Lost AVP 160 9.0 RADIUS/Diameter Protocol Interactions 161 9.1 RADIUS request forwarded as Diameter request 162 9.2 Diameter request forwarded as RADIUS request 163 10.0 AVP Occurrence Table 164 10.1 NASREQ Command AVP Table 165 10.2 Accounting AVP Table 166 10.2.1 Framed Access 167 10.2.2 Non-Framed Access 168 11.0 IANA Considerations 169 11.1 Command Codes 170 11.2 AVP Codes 171 11.3 Request-Type AVP Values 172 11.4 Application Identifier 173 11.5 NAS-Key-Binding AVP Values 174 11.6 NAS-Key-Direction AVP Values 175 11.7 NAS-Key-Type AVP Values 176 12.0 Security Considerations 177 13.0 References 178 14.0 Acknowledgements 179 15.0 Authors' Addresses 180 16.0 Full Copyright Statement 181 17.0 Expiration Date 183 1.0 Introduction 185 This document describes the Diameter application that is used for AAA 186 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 187 application, combined with the base protocol [2], satisfies the 188 requirements defined in the NASREQ AAA criteria specification [24] 189 and the ROAMOPS AAA Criteria specification [4]. 191 This document is divided into three main sections. The first section 192 defines the Diameter Command-Codes and AVPs that are needed to 193 support legacy authentication protocols, those that are typically 194 supported by RADIUS [1] servers. The second section defines the 195 Command-Codes and AVPs necessary for a Diameter node to support PPP's 196 Extensible Authentication Protocol (EAP) [25]. The third section 197 contains the Authorization AVPs that are needed for the various 198 services offered by a NAS, such as PPP dial-in, terminal server and 199 tunneling applications, such as L2TP [16]. 201 Given that it is expected that initial deployments of the Diameter 202 protocol in a dial-up environment will include legacy systems, this 203 application was carefully designed to ease the burden of servers that 204 must perform protocol conversion between RADIUS and Diameter. This 205 is achieved by re-using the RADIUS address space, eliminating the 206 need to perform attribute lookups. 208 1.1 Requirements language 210 In this document, the key words "MAY", "MUST", "MUST NOT", 211 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 212 interpreted as described in [12]. 214 1.2 Advertising application support 216 Diameter nodes conforming to this specification MAY advertise support 217 by including the value of one (1) in the Auth-Application-Id or the 218 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 219 Capabilities-Exchange-Answer command [2]. 221 2.0 Supported AVPs 223 This section lists all of the Diameter AVPs and the legacy RADIUS 224 attributes supported by this application. 226 2.1 Diameter AVPs 228 This section will define all of the AVPs that are not backward 229 compatible with the RADIUS protocol [1]. A Diameter message that 230 includes one of these AVPs MAY cause interoperability issues should 231 the request traverse a AAA node that only supports the RADIUS 232 protocol. However, the Diameter protocol SHOULD NOT be hampered from 233 future developments due to the existing installed base. 235 The following table describes the Diameter AVPs defined in the NASREQ 236 application, their AVP Code values, types, possible flag values and 237 whether the AVP MAY be encrypted. 239 +---------------------+ 240 | AVP Flag rules | 241 |----+-----+----+-----|----+ 242 AVP Section | | |SHLD| MUST|MAY | 243 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 244 -----------------------------------------|----+-----+----+-----|----| 245 EAP-Payload 402 4.3 OctetString| M | P | | V | Y | 246 Filter-Rule 400 2.1.2 OctetString| M | P | | V | Y | 247 NAS-Key-Binding TBD 2.1.7 Unsigned32 | M | P | | V | Y | 248 NAS-Key-Data TBD 2.1.6 OctetString| M | P | | V | N | 249 NAS-Key- TBD 2.1.4 Unsigned32 | M | P | | V | N | 250 Direction | | | | | | 251 NAS-Key-Type TBD 2.1.5 Unsigned32 | M | P | | V | N | 252 NAS-Session-Key TBD 2.1.3 Grouped | M | P | | V | Y | 253 Request-Type 401 2.1.1 Unsigned32 | M | P | | V | N | 254 Tunneling 403 7.4 Grouped | M | P | | V | N | 256 2.1.1 Request-Type AVP 258 The Request-Type AVP (AVP Code 401) is of type Unsigned32 and is used 259 to determine the type of request being transmitted. Note that a 260 request with this AVP set to a value other than 261 AUTHORIZE_AUTHENTICATE MAY break backward RADIUS compatibility. The 262 following values are defined: 264 AUTHENTICATE_ONLY 1 265 The request being sent is for authentication only, and MUST 266 contain the relevant authentication AVPs that are needed by the 267 Diameter server to authenticate the user. 269 AUTHORIZE_ONLY 2 270 The request being sent is for authorization only, and MUST 271 contain the authorization AVPs that are necessary to identify 272 the service being requested/offered. 274 AUTHORIZE_AUTHENTICATE 3 275 The request contains a request for both authentication and 276 authorization. The request MUST include both the relevant 277 authentication information, and authorization information 278 necessary to identify the service being requested/offered. 280 2.1.2 Filter-Rule AVP 282 The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in 283 the UTF-8 [29] format, and provides filter rules that need to be 284 configured on the NAS for the user. One or more such AVPs MAY be 285 present in an authorization response. 287 Each packet can be filtered based on the following information that 288 is associated with it: 290 Direction (in or out) 291 Source and destination IP address (possibly masked) 292 Protocol 293 Source and destination port (lists or ranges) 294 TCP flags 295 IP fragment flag 296 IP options 297 ICMP types 299 Rules for the appropriate direction are evaluated in order, with the 300 first matched rule terminating the evaluation. Each packet is 301 evaluated once. If no rule matches, the packet is dropped if the last 302 rule evaluated was a permit, and passed if the last rule was a deny. 304 The filters in the Filter-Rule AVP MUST follow the format: 306 action dir proto from src to dst [options] 308 action permit - Allow packets that match the rule. 309 deny - Drop packets that match the rule. 311 dir "in" is from the terminal, "out" is to the terminal. 313 proto An IP protocol specified by number. The "ip" keyword 314 means any protocol will match. 316 src and dst
[ports] 318 The
may be specified as: 319 ipno An IPv4 or IPv6 number in dotted-quad or 320 canonical IPv6 form. Only this exact IP 321 number will match the rule. 322 ipno/bits An IP number as above with a mask width of 323 the form 1.2.3.4/24. In this case all IP 324 numbers from 1.2.3.0 to 1.2.3.255 will 325 match. The bit width MUST be valid for 326 the IP version and the IP number MUST NOT 327 have bits set beyond the mask. 329 The sense of the match can be inverted by preceding 330 an address with the not modifier, causing all other 331 addresses to be matched instead. This does not 332 affect the selection of port numbers. 334 The keyword "any" is 0.0.0.0/0 or the IPv6 335 equivalent. The keyword "assigned" is the address 336 or set of addresses assigned to the terminal. The 337 first rule SHOULD be "deny in ip !assigned". 339 With the TCP and UDP protocols, optional ports may be 340 specified as: 342 {port|port-port}[,port[,...]] 344 The `-' notation specifies a range of ports 345 (including boundaries). 347 Fragmented packets which have a non-zero offset (i.e. 348 not the first fragment) will never match a rule which 349 has one or more port specifications. See the frag 350 option for details on matching fragmented packets. 352 options: 353 frag Match if the packet is a fragment and this is not the 354 first fragment of the datagram. frag may not be used 355 in conjunction with either tcpflags or TCP/UDP port 356 specifications. 358 ipoptions spec 359 Match if the IP header contains the comma separated 360 list of options specified in spec. The supported IP 361 options are: 363 ssrr (strict source route), lsrr (loose source route), 364 rr (record packet route) and ts (timestamp). The 365 absence of a particular option may be denoted with a 366 `!'. 368 tcpoptions spec 369 Match if the TCP header contains the comma separated 370 list of options specified in spec. The supported TCP 371 options are: 373 mss (maximum segment size), window (tcp window 374 advertisement), sack (selective ack), ts (rfc1323 375 timestamp) and cc (rfc1644 t/tcp connection count). 376 The absence of a particular option may be denoted with 377 a `!'. 379 established 380 TCP packets only. Match packets that have the RST or 381 ACK bits set. 383 setup TCP packets only. Match packets that have the SYN bit 384 set but no ACK bit. 386 tcpflags spec 387 TCP packets only. Match if the TCP header contains the 388 comma separated list of flags specified in spec. The 389 supported TCP flags are: 391 fin, syn, rst, psh, ack and urg. The absence of a 392 particular flag may be denoted with a `!'. A rule which 393 contains a tcpflags specification can never match a 394 fragmented packet which has a non-zero offset. See the 395 frag option for details on matching fragmented packets. 397 icmptypes types 398 ICMP packets only. Match if the ICMP type is in the 399 list types. The list may be specified as any 400 combination of ranges or individual types separated by 401 commas. The supported ICMP types are: 403 echo reply (0), destination unreachable (3), source 404 quench (4), redirect (5), echo request (8), router 405 advertisement (9), router solicitation (10), time-to- 406 live exceeded (11), IP header bad (12), timestamp 407 request (13), timestamp reply (14), information request 408 (15), information reply (16), address mask request (17) 409 and address mask reply (18). 411 There is one kind of packet that the NAS MUST always discard, that is 412 an IP fragment with a fragment offset of one. This is a valid 413 packet, but it only has one use, to try to circumvent firewalls. 415 A NAS that is unable to interpret or apply a deny rule MUST 416 terminate the session. A NAS that is unable to interpret or apply 417 a permit rule MAY apply a more restrictive rule. A NAS MAY apply 418 deny rules of its own before the supplied rules, for example to 419 protect the NAS owner's infrastructure. 421 The rule syntax is a modified subset of ipfw(8) from FreeBSD, and the 422 ipfw.c code may provide a useful base for implementations. 424 2.1.3 NAS-Session-Key AVP 426 The NAS-Session-Key AVP (AVP Code TBD) is of type Grouped, and 427 contains a session key distributed from Diameter servers to clients. 428 The keys MAY be used for integrity and/or confidentiality protection 429 between the NAS and the user. The keys MAY be distributed to the user 430 as part of an EAP authentication exchange. Its Data field has the 431 following ABNF grammar: 433 NAS-Session-Key ::= < AVP Header: TBD > 434 { NAS-Key-Direction } 435 { NAS-Key-Type } 436 { NAS-Key } 437 { NAS-Key-Binding } 438 * [ AVP ] 440 NAS session keys are the keys created by a Diameter server, which it 441 distributes to the NAS, acting as a Diameter client. The keys can be 442 used for integrity and confidentiality protection between the NAS and 443 the user. The keys can be distributed to the user for example as part 444 of the EAP authentication procedure. 446 If strong authentication and confidentiality of the session keys is 447 required, it is recommended that the CMS security application [13] be 448 used to protect the NAS-Session-Key AVP. 450 The NAS-Session-Key AVP MAY appear zero or more times in the AAA and 451 DEA messages. When more than one NAS-Session-Key AVP is present in a 452 message, either the NAS-Key-Type or the NAS-Key-Direction AVPs MUST 453 have different values. Otherwise, the AVPs would conflict with each 454 other. 456 The lifetime of the NAS-Session-Key AVP is found in the 457 Authorization-Lifetime AVP. If a re-authorization request is received 458 prior to the expiration of the lifetime, new keys will need to be 459 distributed. 461 2.1.4 NAS-Key-Direction AVP 463 The NAS-Key-Direction AVP (AVP Code TBD) is of type Unsigned32, and 464 specifies the direction that the traffic is to be protected with the 465 key. The following values are supported: 467 BIDIRECTIONAL 1 468 The key is used in both directions 470 UPLINK 2 471 The key is used for traffic from the user 473 DOWNLINK 3 474 The key is used for traffic sent to user 476 2.1.5 NAS-Key-Type AVP 478 The NAS-Key-Type AVP (AVP Code TBD) is of type Unsigned32, and 479 specifies how the key is to be used. The following values are 480 supported: 482 CIPHER_KEY 1 483 The key is used to encrypt data 485 INTEGRITY_KEY 2 486 The key is used to authenticate the data 488 2.1.6 NAS-Key-Data AVP 490 The NAS-Key-Data AVP (AVP Code TBD) is of type OctetString and 491 contains the session key to be used between the user and the access 492 device. 494 2.1.7 NAS-Key-Binding AVP 496 The NAS-Key-Binding AVP (AVP Code TBD) is of type Unsigned32, and 497 specifies the purpose for the key. A Diameter client MAY include this 498 AVP in a request to specify to the Diameter server the type of key it 499 desires. This AVP MAY be present in a response from the Diameter 500 server to inform the client of the type of key found in the NAS- 501 Session-Key AVP. The following values are supported: 503 PPP DES 1 504 The key created is used to secure PPP links using DES [36] 506 PPP 3DES 2 507 The key created is used to secure PPP links using Triple DES 508 [37] 510 PPP MPPE 3 511 The key created is used to secure PPP links using MPPE [38] 513 802.11 WEP 4 514 The key created is used to secure 802.11 links using WEP [x] 516 802.11 WEP2 5 517 The key created is used to secure 802.11 links using WEP/2 [x] 519 802.11 AES/OCB 6 520 The key created is used to secure 802.11 links using AES/OCB 521 [x] 523 2.2 Legacy RADIUS Attributes 525 The Diameter protocol reserves the first 255 AVP identifiers for 526 "legacy RADIUS" support. The following table contains the RADIUS 527 attributes supported by this Diameter application, their AVP code 528 values, types, possible flag values and whether the AVP MAY be 529 encrypted. RADIUS attributes not listed are not supported by the 530 Diameter protocol. 532 +---------------------+ 533 | AVP Flag rules | 534 |----+-----+----+-----|----+ 535 AVP Section | | |SHLD| MUST|MAY | 536 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 537 -----------------------------------------|----+-----+----+-----|----| 538 Accounting- 45 8.6 Unsigned32 | | P | | V | Y | 539 Authentication-Type | | | | | | 540 Accounting-Input- 42 8.1 Unsigned32 | | P | | V | Y | 541 Octets | | | | | | 542 Accounting-Input- 47 8.4 Unsigned32 | | P | | V | Y | 543 Packets | | | | | | 544 Accounting- 43 8.2 Unsigned32 | | P | | V | Y | 545 Output-Octets | | | | | | 546 Accounting- 48 8.5 Unsigned32 | | P | | V | Y | 547 Output-Packets | | | | | | 548 Accounting- 46 8.3 Unsigned32 | | P | | V | Y | 549 Session-Time | | | | | | 550 Acct-Tunnel- 68 8.7 OctetString| | P | | V | Y | 551 Connection | | | | | | 552 Acct-Tunnel- 86 8.8 OctetString| | P | | V | Y | 553 Packets-Lost | | | | | | 554 ARAP-Challenge- 84 3.1.2.1 OctetString| M | P | | V | Y | 555 Response | | | | | | 556 ARAP-Features 71 7.2.8.1 OctetString| M | P | | V | Y | 557 ARAP-Password 70 3.1.1.4 OctetString| M | P | | V | Y | 558 ARAP-Security 73 7.2.8.3 Unsigned32 | M | P | | V | Y | 559 +---------------------+ 560 | AVP Flag rules | 561 |----+-----+----+-----|----+ 562 AVP Section | | |SHLD| MUST|MAY | 563 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 564 -----------------------------------------|----+-----+----+-----|----| 565 ARAP-Security- 74 7.2.8.4 OctetString| M | P | | V | Y | 566 Data | | | | | | 567 ARAP-Zone-Access 72 7.2.8.2 Unsigned32 | M | P | | V | Y | 568 Callback-Id 20 6.4 OctetString| M | P | | V | Y | 569 Callback-Number 19 6.3 OctetString| M | P | | V | Y | 570 Called-Station-Id 30 6.6 OctetString| M | P | | V | Y | 571 Calling-Station- 31 6.7 OctetString| M | P | | V | Y | 572 Id | | | | | | 573 CHAP-Challenge 60 3.1.1.3 OctetString| M | P | | V | Y | 574 CHAP-Password 3 3.1.1.2 OctetString| M | P | | V | Y | 575 Class 25 2.2.4 OctetString| M | P | | V | Y | 576 Connect-Info 77 6.10 OctetString| | P | | V | Y | 577 Filter-Id 11 6.2 OctetString| M | P | | V | Y | 578 Framed-Appletalk- 37 7.2.7.1 Unsigned32 | M | P | | V | Y | 579 Link | | | | | | 580 Framed-Appletalk- 38 7.2.7.2 Unsigned32 | M | P | | V | Y | 581 Network | | | | | | 582 Framed-Appletalk- 39 7.2.7.3 OctetString| M | P | | V | Y | 583 Zone | | | | | | 584 Framed-Protocol 7 7.2.1 Unsigned32 | M | P | | V | Y | 585 Framed-IP-Address 8 7.2.5.1 Address | M | P | | V | Y | 586 Framed- 13 7.2.4 Unsigned32 | M | P | | V | Y | 587 Compression | | | | | | 588 Framed-IP-Netmask 9 7.2.5.2 Address | M | P | | V | Y | 589 Framed-IP-Route 22 7.2.5.3 OctetString| M | P | | V | Y | 590 Framed-IPX- 23 7.2.6.1 OctetString| M | P | | V | Y | 591 Network | | | | | | 592 Framed-MTU 12 7.2.3 Unsigned32 | M | P | | V | Y | 593 Framed-Routing 10 7.2.2 Unsigned32 | M | P | | V | Y | 594 Idle-Timeout 28 6.5 Unsigned32 | M | P | | V | Y | 595 Login-IP-Host 14 7.3.1 Address | M | P | | V | Y | 596 Login-LAT-Group 36 7.3.4.3 OctetString| M | P | | V | Y | 597 Login-LAT-Node 35 7.3.4.2 OctetString| M | P | | V | Y | 598 Login-LAT-Port 63 7.3.4.4 OctetString| M | P | | V | Y | 599 Login-LAT-Service 34 7.3.4.1 Unsigned32 | M | P | | V | Y | 600 Login-Service 15 7.3.2 Unsigned32 | M | P | | V | Y | 601 Login-TCP-Port 16 7.3.3.1 Unsigned32 | M | P | | V | Y | 602 NAS-Identifier 32 2.2.2 OctetString| M | P | | V | Y | 603 NAS-IP-Address 4 2.2.1 Address | M | P | | V | Y | 604 NAS-Port 5 6.1.1 Unsigned32 | M | P | | V | Y | 605 NAS-Port-Type 61 6.8 Unsigned32 | M | P | | V | Y | 606 Password-Retry 75 3.1.2.2 Unsigned32 | | P | | V | Y | 607 +---------------------+ 608 | AVP Flag rules | 609 |----+-----+----+-----|----+ 610 AVP Section | | |SHLD| MUST|MAY | 611 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 612 -----------------------------------------|----+-----+----+-----|----| 613 Port-Limit 62 6.9 Unsigned32 | M | P | | V | Y | 614 Prompt 76 3.1.2.3 Unsigned32 | | P | | V | Y | 615 Reply-Message 18 3.2 OctetString| M | P | | V | Y | 616 Service-Type 6 7.1 Unsigned32 | M | P | | V | Y | 617 State 24 2.2.3 OctetString| M | P | | V | Y | 618 Tunnel- 82 7.4.7 OctetString| M | P | | V | Y | 619 Assignment-Id | | | | | | 620 Tunnel-Client- 90 7.4.9 OctetString| M | P | | V | Y | 621 Auth-ID | | | | | | 622 Tunnel-Client- 66 7.4.3 OctetString| M | P | | V | Y | 623 Endpoint | | | | | | 624 Tunnel-Medium- 65 7.4.2 Unsigned32 | M | P | | V | Y | 625 Type | | | | | | 626 Tunnel-Password 69 7.4.5 OctetString| M | P | | V | Y | 627 Tunnel-Preference 83 7.4.8 Unsigned32 | M | P | | V | Y | 628 Tunnel-Private- 81 7.4.6 OctetString| M | P | | V | Y | 629 Group-ID | | | | | | 630 Tunnel-Server- 91 7.4.10 OctetString| M | P | | V | Y | 631 Auth-ID | | | | | | 632 Tunnel-Server- 67 7.4.4 OctetString| M | P | | V | Y | 633 Endpoint | | | | | | 634 Tunnel-Type 64 7.4.1 Unsigned32 | M | P | | V | Y | 635 User-Password 2 3.1.1.1 OctetString| M | P | | V | Y | 637 The AVPs defined in this section SHOULD only used when a 638 Diameter/RADIUS gateway function is invoked, and are not used in the 639 Diameter protocol. 641 2.2.1 NAS-IP-Address AVP 643 The NAS-IP-Address AVP (AVP Code 4) [1] is of type Address, and 644 contains the IP Address of the NAS providing service to the user. 645 When this AVP is present, the Origin-Host AVP DOES NOT represent the 646 NAS providing service to the user. Note that this AVP SHOULD only 647 added by a RADIUS/Diameter protocol gateway (see Section 9.0). 649 2.2.2 NAS-Identifier AVP 651 The NAS-Identifier AVP (AVP Code 32) [1] is of type OctetString, 652 encoded in the UTF-8 [29] format, and contains the Identity of the 653 NAS providing service to the user. When this AVP is present, the 654 Origin-Host AVP DOES NOT represent the NAS providing service to the 655 user. Note that this AVP SHOULD only added by a RADIUS/Diameter 656 protocol gateway (see Section 9.0). 658 2.2.3 State AVP 660 The State AVP (AVP Code 24) is of type OctetString and is used to 661 transmit the contents of the RADIUS State attribute, and no 662 interpretation of the contents should be made. Note that this AVP 663 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 664 9.0). 666 2.2.4 Class AVP 668 The Class AVP (AVP Code 25) is of type OctetString and is used to 669 transmit the contents of the RADIUS Class attribute, and no 670 interpretation of the contents should be made. Note that this AVP 671 SHOULD only added by a RADIUS/Diameter protocol gateway (see Section 672 9.0). 674 3.0 Legacy RADIUS Authentication Support 676 This section defines the new Command-Code [2] values required to 677 support the legacy authentication protocols (i.e. PAP, CHAP), as well 678 as the AVPs that are necessary to carry the authentication 679 information in the Diameter protocol. The functionality defined here 680 provides a RADIUS-like AAA service, over a more reliable and secure 681 transport, as defined in the base protocol [2]. 683 Unlike the RADIUS protocol [1], the Diameter protocol does not 684 require authentication information to be contained in a request from 685 the client. Therefore, it is possible to send a request for 686 authorization only. The type of service depends upon the Request-Type 687 AVP. This difference MAY cause operational issues in environments 688 that need RADIUS interoperability, and it MAY be necessary that 689 protocol conversion gateways add some authentication information when 690 transmitting to a RADIUS server. 692 The Diameter protocol allows for users to be periodically re- 693 authenticated and/or re-authorized. In such instances, the Session-Id 694 AVP in the AAR message MUST be the same as the one present in the 695 original authentication/authorization message. A Diameter server 696 informs the NAS of the authorized session lifetime via the Session- 697 Timeout AVP [1]. 699 A NAS MUST re-authenticate and/or authorize after the period provided 700 by the server. Furthermore, it is possible for Diameter servers to 701 issue an unsolicited re-authentication and/or re-authorization by 702 issuing an AA-Challenge-Ind message to the NAS. Upon receipt of such 703 a message, the NAS is instructed to issue a request to re- 704 authenticate and/or re-authorize the client. 706 3.1 Command-Codes Values 708 This section defines new Command-Code [2] values that MUST be 709 supported by all Diameter implementations that conform to this 710 specification. The following Command Codes are defined in this 711 section: 713 Command-Name Abbrev. Code Reference 714 -------------------------------------------------------- 715 AA-Answer AAA 265 3.1.2 716 AA-Request AAR 265 3.1.1 718 3.1.1 AA-Request (AAR) Command 720 The AA-Request message (AAR), indicated by the Command-Code field set 721 to 265 and the 'R' bit set in the Command Flags field, is used in 722 order to request authentication and/or authorization for a given PPP 723 user. The type of request is identified through the Request-Type AVP, 724 and the default mode is both authentication and authorization. 726 If Authentication is requested the User-Name attribute SHOULD be 727 present, as well as any additional authentication AVPs that would 728 carry the password information. A request for authorization only 729 SHOULD include the information from which the authorization will be 730 performed, such as the User-Name, or DNIS and ANI AVPs. Certain 731 networks MAY use different AVPs for authorization purposes. A request 732 for authorization will include some AVPs defined in sections 2.0, 6.0 733 and 7.0. 735 It is possible for a single session to be authorized only first, then 736 followed by an authentication request. However, the inverse SHOULD 737 NOT be permitted. 739 This AA-Request message MAY be the result of a multi-round 740 authentication exchange, which occurs when the AAA is received with 741 the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A subsequent 742 AAR message SHOULD be sent, with the User-Password AVP that includes 743 the user's response to the prompt, and MUST include any State AVPs 744 that were present in the AAA. 746 Message Format 748 ::= < Diameter Header: 265, REQUEST > 749 < Session-Id > 750 { Auth-Application-Id } 751 { Origin-Host } 752 { Origin-Realm } 753 { Destination-Realm } 754 { Service-Type } 755 [ Destination-Host ] 756 [ NAS-Identifier ] 757 [ User-Name ] 758 [ User-Password ] 759 [ ARAP-Password ] 760 [ CHAP-Password ] 761 [ CHAP-Challenge ] 762 [ Idle-Timeout ] 763 [ State ] 764 [ Authorization-Lifetime ] 765 [ Session-Timeout ] 766 [ Origin-State-Id ] 767 [ NAS-Key-Binding ] 768 * [ AVP ] 769 * [ Proxy-Info ] 770 * [ Route-Record ] 772 3.1.1.1 User-Password AVP 774 The User-Password AVP (AVP Code 2) is of type OctetString and 775 contains the password of the user to be authenticated, or the user's 776 input in a multi-round authentication exchange. 778 This AVP MUST be encrypted using one of the methods described in [2] 779 or [13]. Unless this AVP is used for one-time passwords, the User- 780 Password AVP SHOULD NOT be used in non-trusted proxy environments. 782 The clear-text password (prior to encryption) MUST NOT be longer than 783 128 bytes in length. 785 3.1.1.2 CHAP-Password AVP 787 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 788 the response value provided by a PPP Challenge-Handshake 789 Authentication Protocol (CHAP) [6] user in response to the challenge. 791 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 792 AVP (see section 3.1.1.3) MUST be present as well. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 AVP Header (AVP Code = 3) 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | CHAP Ident | Data ... 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 The CHAP Ident field contains the one octet CHAP Identifier from the 803 user's CHAP response [6]. The Data field is 16 octets, and contains 804 the CHAP Response from the user. The actual computation of the CHAP 805 response can be found in [6]. 807 3.1.1.3 CHAP-Challenge AVP 809 The CHAP-Challenge AVP (AVP Code 60) is of type OctetString and 810 contains the CHAP Challenge sent by the NAS to a PPP Challenge- 811 Handshake Authentication Protocol (CHAP) [6] user. 813 3.1.1.4 ARAP-Password AVP 815 The ARAP-Password AVP (AVP Code 70) is of type OctetString and is 816 only present when the Framed-Protocol AVP (see Section 7.2.1) is 817 included in the message and is set to ARAP. This AVP MUST NOT be 818 present if the User-Password or CHAP-Password AVPs are present. See 819 [32] for more information on the contents of this AVP. 821 3.1.2 AA-Answer (AAA) Command 823 The AA-Answer (AAA) message, indicated by the Command-Code field set 824 to 265 and the 'R' bit cleared in the Command Flags field, is sent in 825 response to the AA-Request message. If authorization was requested, a 826 successful response will include the authorization AVPs appropriate 827 for the service being provided, as defined in section 2.0, 6.0 and 828 7.0 830 For authentication exchanges that require more than a single round 831 trip, the server MUST set the Result-Code AVP to 832 DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY 833 include one or more Reply-Message and MAY include zero or one State 834 AVPs. When possible, authentication mechanisms that include more 835 than a single authentication round trip SHOULD use EAP (see section 836 4.0) 837 If the Reply-Message AVP was present, the access device SHOULD 838 display the text message to the user, and MUST prompt the user for a 839 response. If the access device is unable to prompt the user for a 840 new response, which could be achieved via PAP, it MUST treat this 841 answer as an error, and deny access. 843 Message Format 845 ::= < Diameter Header: 265 > 846 < Session-Id > 847 { Auth-Application-Id } 848 { Result-Code } 849 { Origin-Host } 850 { Origin-Realm } 851 { Service-Type } 852 { Destination-Host } 853 [ User-Name ] 854 [ Error-Reporting-Host ] 855 [ Idle-Timeout ] 856 [ Authorization-Lifetime ] 857 [ Session-Timeout ] 858 [ State ] 859 * [ Reply-Message ] 860 [ Origin-State-Id ] 861 * [ NAS-Session-Key ] 862 * [ AVP ] 863 * [ Proxy-Info ] 864 * [ Route-Record ] 866 3.1.2.1 ARAP-Challenge-Response AVP 868 The ARAP-Challenge-Response AVP (AVP Code 84) is of type OctetString 869 and is only present when the Framed-Protocol AVP (see Section 7.2.1) 870 is included in the message and is set to ARAP. This AVP contains an 8 871 octet response to the dial-in client's challenge. The RADIUS server 872 calculates this value by taking the dial-in client's challenge from 873 the high order 8 octets of the ARAP-Password AVP and performing DES 874 encryption on this value with the authenticating user's password as 875 the key. If the user's password is less than 8 octets in length, the 876 password is padded at the end with NULL octets to a length of 8 877 before using it as a key. 879 3.1.2.2 Password-Retry AVP 881 The Password-Retry AVP (AVP Code 75) is of type Unsigned32 and MAY be 882 included in the AA-Answer if the Result-Code indicates an 883 authentication failure. The value of this AVP indicates how many 884 authentication attempts a user may be permitted before being 885 disconnected. This AVP is primarily intended for use when the 886 Framed-Protocol AVP (see Section 7.2.1) is set to ARAP. 888 3.1.2.3 Prompt AVP 890 The Prompt AVP (AVP Code 76) is of type Unsigned32, and MAY be 891 present in the AA-Answer message. When present, it is used by the NAS 892 to determine whether the user's response, when entered, should be 893 echoed. 895 The supported values are listed in [34]. 897 3.2 Reply-Message AVP 899 The Reply-Message AVP (AVP Code 18) is of type OctetString, encoded 900 in the UTF-8 [29] format, and contains text which MAY be displayed to 901 the user. When used in an AA-Answer message with a successful 902 Result-Code AVP it indicates the success message. When found in the 903 same message with a Result-Code other than Diameter-SUCCESS it 904 contains the failure message. 906 The Reply-Message AVP MAY indicate a dialog message to prompt the 907 user before another AA-Request attempt. When used in an AA-Answer, it 908 MAY indicate a dialog message to prompt the user for a response. 910 Multiple Reply-Message's MAY be included and if any are displayed, 911 they MUST be displayed in the same order as they appear in the 912 message. 914 4.0 Extensible Authentication Protocol Support 916 The Extensible Authentication Protocol (EAP), described in [25], 917 provides a standard mechanism for support of additional 918 authentication methods within PPP. Through the use of EAP, support 919 for a number of authentication schemes may be added, including smart 920 and token cards, Kerberos, Public Key, One Time Passwords, and 921 others. 923 This section describes the Command-Codes values and AVPs that are 924 required for an EAP payload to be encapsulated within the Diameter 925 protocol. Since authentication occurs between the PPP client and its 926 home Diameter server, end-to-end authentication is achieved, reducing 927 the possibility for fraudulent authentication, such as replay and 928 man-in-the-middle attacks. End-to-end authentication also provides 929 for mutual (bi-directional) authentication, which is not possible 930 with PAP and CHAP in a roaming environment. 932 The Diameter/EAP application allows a home Diameter server to 933 initiate an unsolicited authentication request to the user. This 934 allows the home server to periodically ensure that the user is still 935 active, which is useful when a server requires re-authentication to 936 extend the "life" of a session [26]. Server-initiated authentication 937 can reduce the number of protocol exchanges over the Internet. 939 The EAP conversation between the authenticating peer and the NAS 940 begins with the negotiation of EAP within LCP. Once EAP has been 941 negotiated, the NAS will typically send to the Diameter server a 942 Diameter-EAP-Request message with a NULL EAP-Payload AVP, signifying 943 an EAP-Start. The Port number and NAS Identifier MUST be included in 944 the AVPs issued by the NAS in the Diameter-EAP-Request packet. 946 If the Diameter home server supports EAP, it MUST respond with a 947 Diameter-EAP-Answer message containing an EAP-Payload AVP that 948 includes an encapsulated EAP payload [25], and the Result-Code AVP 949 set to DIAMETER_MULTI_ROUND_AUTH. The EAP payload is forwarded by the 950 NAS to the PPP client. The initial Diameter-EAP-Answer in a multi- 951 round exchange normally includes an EAP-Request/Identity, requesting 952 the PPP client to identify itself. Upon receipt of the PPP client's 953 EAP-Response [25], the NAS will then issue a second Diameter-EAP- 954 Request message, with the client's EAP payload encapsulated within 955 the EAP-Payload AVP. The conversation continues until the Diameter 956 server sends a Diameter-EAP-Answer with a Result-Code AVP indicating 957 success or failure. A Result-Code AVP containing a failure indication 958 SHOULD also include an EAP-Payload AVP containing an EAP-Failure [25] 959 payload, and the NAS SHOULD disconnect the PPP client by issuing a 960 LCP terminate. If the Result-Code AVP indicates success, the EAP- 961 Payload AVP MUST encapsulate an EAP-Success [25] payload, and the NAS 962 SHOULD successfully terminate the PPP authentication phase. If 963 authorization was requested, a successful Diameter-EAP-Answer MUST 964 also include the appropriate authorization AVPs required for the 965 service requested (see sections 2.0, 6.0 and 7.0). 967 The above scenario creates a situation in which the NAS never needs 968 to manipulate an EAP packet. An alternative may be used in situations 969 where an EAP-Request/Identity message will always be sent by the NAS 970 to the authenticating peer. This involves having the NAS send an 971 EAP-Request/Identity message to the PPP client, and forwarding the 972 EAP-Response/Identity packet to the Diameter server in the EAP- 973 Payload AVP of a Diameter-EAP-Request packet. While this approach 974 will save a round-trip, it cannot be universally employed. There are 975 circumstances in which the user's identity may not be needed (such as 976 when authentication and accounting is handled based on the calling or 977 called phone number), and therefore an EAP-Request/Identity packet 978 may not necessarily be issued by the NAS to the authenticating peer. 980 Unless the NAS interprets the EAP-Response/Identity packet returned 981 by the authenticating peer, it will not have access to the user's 982 identity. Therefore, the Diameter Server SHOULD return the user's 983 identity by inserting it in the User-Name attribute of subsequent 984 Diameter-EAP-Answer packets. Without the user's identity, the 985 Session-Id AVP MAY be used for accounting and billing, however 986 operationally this MAY be very difficult to manage. 988 The Diameter-EAP-Ind message MAY be sent by a Diameter server in 989 order to initiate an unsolicited authentication of the PPP user, as 990 described in [26]. This functionality allows a home Diameter server 991 to easily extend the "life" of a session for a particular service, 992 while reducing the total number of authentication round-trips, should 993 the NAS initiate the periodic authentication. 995 Should an EAP authentication session be interrupted due to a home 996 server failure, the session MAY be directed to an alternate server, 997 but the authentication session will have to be restarted from the 998 beginning. 1000 When Diameter is used in a roaming environment, the NAS SHOULD issue 1001 the EAP-Request/Identity request to the PPP client, and forward the 1002 EAP-Response in the initial Diameter-EAP-Request message. This allows 1003 any Diameter proxies or brokers to identify the user, and forward the 1004 message to the appropriate home server. If a response is received 1005 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 1006 an indication that a Diameter server in the proxy chain does not 1007 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 1008 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 1009 cautious when determining whether a less secure authentication 1010 protocol will be used, since this could be a result of a bidding down 1011 attack. 1013 4.1 Alternative uses 1015 Currently the conversation between the backend authentication server 1016 and the Diameter server is proprietary because of lack of 1017 standardization. In order to increase standardization and provide 1018 interoperability between Diameter vendors and backend security 1019 vendors, it is recommended that Diameter-encapsulated EAP be used for 1020 this conversation. 1022 This has the advantage of allowing the Diameter server to support EAP 1023 without the need for authentication-specific code within the Diameter 1024 server. Authentication-specific code can then reside on a backend 1025 authentication server instead. 1027 In the case where Diameter-encapsulated EAP is used in a conversation 1028 between a Diameter server and a backend authentication server, the 1029 latter will typically return an Diameter-EAP-Answer/EAP-Payload/EAP- 1030 Success message without inclusion of the expected authorization AVPs 1031 required in a successful response. This means that the Diameter 1032 server MUST add these attributes prior to sending an Diameter-EAP- 1033 Answer/EAP-Payload/EAP-Success message to the NAS. 1035 4.2 Command-Codes Values 1037 This section defines new Command-Code [2] values that MUST be 1038 supported by all Diameter implementations conforming to this 1039 specification. The following Command Codes are defined in this 1040 section: 1042 Command-Name Abbrev. Code Reference 1043 -------------------------------------------------------- 1044 Diameter-EAP-Answer DEA 268 4.2.2 1045 Diameter-EAP-Request DER 268 4.2.1 1047 4.2.1 Diameter-EAP-Request (DER) Command 1049 The Diameter-EAP-Request (DER) command, indicated by the Command-Code 1050 field set to 268 and the 'R' bit set in the Command Flags field, is 1051 sent by a Diameter client to a Diameter server and conveys an EAP- 1052 Response [25] from the dial-up PPP client. The Diameter-EAP-Request 1053 MUST contain one EAP-Payload AVP, which contains the actual EAP 1054 payload. An EAP-Payload AVP with no data MAY be sent to the Diameter 1055 server to initiate an EAP authentication session. 1057 Upon receipt of a Diameter-EAP-Request, a Diameter server MUST issue 1058 a reply. The reply may be either: 1060 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 1061 within an EAP-Payload and a Result-Code indicating a multi- 1062 round authentication exchange. 1063 2) a Diameter-EAP-Answer containing an EAP-Success encapsulated 1064 within an EAP-Payload and a Result-Code indicating success. 1065 3) a Diameter-EAP-Answer containing an EAP-Failure encapsulated 1066 within an EAP-Payload and a Result-Code indicating failure. 1068 The DER message MAY be the result of a multi-round 1069 authentication exchange, which occurs when the DEA is received 1070 with the Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. A 1071 subsequent DER message MUST include any State AVPs that were 1072 present in the DEA. For re-authentication, it is recommended 1073 that the Identity request be skipped in order to reduce the 1074 number of authentication round trips. This is only possible 1075 when the user's identity is already known by the home Diameter 1076 server. 1078 Message Format 1080 ::= < Diameter Header: 268, REQUEST > 1081 < Session-Id > 1082 { Auth-Application-Id } 1083 { Origin-Host } 1084 { Origin-Realm } 1085 { Destination-Realm } 1086 { Service-Type } 1087 { EAP-Payload } 1088 [ Destination-Host ] 1089 [ Authorization-Lifetime ] 1090 [ Session-Timeout ] 1091 [ User-Name ] 1092 [ Idle-Timeout ] 1093 [ NAS-IP-Address ] 1094 [ NAS-Identifier ] 1095 [ State ] 1096 [ Origin-State-Id ] 1097 [ NAS-Key-Binding ] 1098 * [ AVP ] 1099 * [ Proxy-Info ] 1100 * [ Route-Record ] 1102 4.2.2 Diameter-EAP-Answer (DEA) Command 1104 The Diameter-EAP-Answer (DEA) message, indicated by the Command-Code 1105 field set to 268 and the 'R' bit cleared in the Command Flags field, 1106 is sent by the Diameter server to the client to indicate either a 1107 successful or failed authentication. The Diameter-EAP-Answer message 1108 SHOULD include an EAP payload of type EAP-Success or EAP-Failure 1109 encapsulated within an EAP-Payload AVP. The Result-Code AVP MUST 1110 indicate a failure if the EAP-Failure payload is present, while the 1111 AVP MUST indicate success if the EAP-Success payload is present. 1113 If the message from the Diameter client included a request for 1114 authorization, a successful response MUST include the authorization 1115 AVPs that are relevant to the service being provided. 1117 For authentication exchanges that require more than a single round 1118 trip, the server MUST set the Result-Code AVP to 1119 DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY 1120 include zero or one State AVPs. 1122 Message Format 1124 ::= < Diameter Header: 268 > 1125 < Session-Id > 1126 { Auth-Application-Id } 1127 { Result-Code } 1128 { Origin-Host } 1129 { Origin-Realm } 1130 { Destination-Host } 1131 { Service-Type } 1132 [ Error-Reporting-Host ] 1133 [ EAP-Payload ] 1134 [ User-Name ] 1135 [ Idle-Timeout ] 1136 [ Authorization-Lifetime ] 1137 [ Session-Timeout ] 1138 [ Origin-State-Id ] 1139 * [ NAS-Session-Key ] 1140 * [ AVP ] 1141 * [ Proxy-Info ] 1142 * [ Route-Record ] 1144 4.3 EAP-Payload AVP 1146 The EAP-Payload AVP (AVP Code 402) is of type OctetString and is used 1147 to encapsulate the actual EAP payload [25] that is being exchanged 1148 between the dial-up PPP client and the home Diameter server. 1150 5.0 Diameter Session Termination 1152 When a Network Access Server (NAS) receives an indication that a 1153 user's session is being disconnected (e.g. LCP Terminate is 1154 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 1155 to its Diameter Server. This will ensure that any resources 1156 maintained on the servers is freed appropriately. 1158 Further, a NAS that receives a Abort-Session-Request (ASR) [2] MUST 1159 issue an STR if the session requested is active, and disconnect the 1160 PPP (or tunneling) session. 1162 6.0 Call and Session Information 1164 This section contains the authorization AVPs that are needed to 1165 identify call and session information, and allows the server to set 1166 constraints on a session. 1168 6.1 NAS-Port AVP 1170 The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains the 1171 physical port number of the NAS which is authenticating the user, and 1172 is normally only present in an authentication and/or authorization 1173 request. Note that this is using "port" in its sense of a physical 1174 connection on the NAS, not in the sense of a TCP or UDP port number. 1175 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 1176 present in the request, if the NAS differentiates among its ports. 1178 6.2 Filter-Id AVP 1180 The Filter-Id AVP (AVP Code 11) is of type OctetString, encoded in 1181 the UTF-8 [29] format, and contains the name of the filter list for 1182 this user. Zero or more Filter-Id AVPs MAY be sent in an 1183 authorization response. 1185 Identifying a filter list by name allows the filter to be used on 1186 different NASes without regard to filter-list implementation details. 1187 However, this AVP is not roaming friendly since filter naming differs 1188 from one service provider to another. 1190 In non-RADIUS environments, it is strongly recommended that the 1191 Filter-Rule AVP be used instead. 1193 6.3 Callback-Number AVP 1195 The Callback-Number AVP (AVP Code 19) is of type OctetString, encoded 1196 in the UTF-8 [29] format, and contains a dialing string to be used 1197 for callback. It MAY be used in an authentication and/or 1198 authorization request as a hint to the server that a Callback service 1199 is desired, but the server is not required to honor the hint in the 1200 corresponding response. 1202 The codification of the range of allowed usage of this field is 1203 outside the scope of this specification. 1205 6.4 Callback-Id AVP 1207 The Callback-Id AVP (AVP Code 20) is of type OctetString, encoded in 1208 the UTF-8 [29] format, and contains the name of a place to be called, 1209 to be interpreted by the NAS. This AVP MAY be present in an 1210 authentication and/or authorization response. 1212 This AVP is not roaming friendly since it assumes that the Callback- 1213 Id is configured on the NAS. It is therefore preferable to use the 1214 Callback-Number AVP instead. 1216 6.5 Idle-Timeout AVP 1218 The Idle-Timeout AVP (AVP Code 28) is of type Unsigned32 and sets the 1219 maximum number of consecutive seconds of idle connection allowed to 1220 the user before termination of the session or prompt. It MAY be used 1221 in an authentication and/or authorization request (or challenge) as a 1222 hint to the server that an idle timeout is desired, but the server is 1223 not required to honor the hint in the corresponding response. 1225 6.6 Called-Station-Id AVP 1227 The Called-Station-Id AVP (AVP Code 30) is of type OctetString, 1228 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1229 request the phone number that the user called, using Dialed Number 1230 Identification (DNIS) or a similar technology. Note that this may be 1231 different from the phone number the call comes in on. It SHOULD only 1232 be present in authentication and/or authorization requests. 1234 If the Request-Type AVP is set to authorization-only and the User- 1235 Name AVP is absent, the Diameter Server MAY perform authorization 1236 based on this field. This can be used by a NAS to request whether a 1237 call should be answered based on the DNIS. 1239 The codification of the range of allowed usage of this field is 1240 outside the scope of this specification. 1242 6.7 Calling-Station-Id AVP 1244 The Calling-Station-Id AVP (AVP Code 31) is of type OctetString, 1245 encoded in the UTF-8 [29] format, and allows the NAS to send in the 1246 request the phone number that the call came from, using Automatic 1247 Number Identification (ANI) or a similar technology. It SHOULD only 1248 be present in authentication and/or authorization requests. 1250 If the Request-Type AVP is set to authorization-only and the User- 1251 Name AVP is absent, the Diameter Server MAY perform authorization 1252 based on this field. This can be used by a NAS to request whether a 1253 call should be answered based on the ANI. 1255 The codification of the range of allowed usage of this field is 1256 outside the scope of this specification. 1258 6.8 NAS-Port-Type AVP 1260 The NAS-Port-Type AVP (AVP Code 61) is of type Unsigned32 and 1261 contains the type of the physical port of the NAS which is 1262 authenticating the user. It can be used instead of or in addition to 1263 the NAS-Port (5) AVP. This AVP SHOULD only be used in authentication 1264 and/or authorization requests. This AVP MAY be combined with the 1265 NAS-Port AVP to assist in differentiating its ports. 1267 The supported values are defined in [34]. 1269 6.9 Port-Limit AVP 1271 The Port-Limit AVP (AVP Code 62) is of type Unsigned32 and sets the 1272 maximum number of ports to be provided to the user by the NAS. It 1273 MAY be used in an authentication and/or authorization request as a 1274 hint to the server that multilink PPP [9] service is desired, but the 1275 server is not required to honor the hint in the corresponding 1276 response. 1278 6.10 Connect-Info AVP 1280 The Connect-Info AVP (AVP Code 77) is of type OctetString and is sent 1281 in the AA-Request message, and indicates the nature of the user's 1282 connection. The value consists of UTF-8 encoded 10646 characters. 1283 The connection speed SHOULD be included at the beginning of the first 1284 Connect-Info AVP in the message. If the transmit and receive 1285 connection speeds differ, they may both be included in the first AVP 1286 with the transmit speed first (the speed the NAS modem transmits at), 1287 a slash (/), the receive speed, then optionally other information. 1289 7.0 Service Specific Authorization AVPs 1291 This section contains the RADIUS authorization AVPs that are 1292 supported in the Diameter protocol. The Service-Type AVP MUST be 1293 present in all messages, and based on the value of the Service-Type 1294 AVP, additional AVPs defined in sections 7.2, 7.3 and 7.4 MAY be 1295 present. 1297 7.1 Service-Type AVP 1299 The Service-Type AVP (AVP Code 6) is of type Unsigned32 and contains 1300 the type of service the user has requested, or the type of service to 1301 be provided. One such AVP MAY be present in an authentication and/or 1302 authorization request or response. A NAS is not required to implement 1303 all of these service types, and MUST treat unknown or unsupported 1304 Service-Types as though a response with a Result-Code other than 1305 Diameter-SUCCESS had been received instead. 1307 When used in a request, the Service-Type AVP SHOULD be considered to 1308 be a hint to the server that the NAS has reason to believe the user 1309 would prefer the kind of service indicated, but the server is not 1310 required to honor the hint. The following values have been defined 1311 for the Service-Type AVP: 1313 The complete list of defined values can be found in [1] and [34]. The 1314 following values are extracted from [1], and are listed here since 1315 they are further qualified: 1317 Login 1 1318 The user should be connected to a host. The message MAY include 1319 additional AVPs defined in section 7.3. 1321 Framed 2 1322 A Framed Protocol should be started for the User, such as PPP 1323 or SLIP. The message MAY include additional AVPs defined in 1324 section 7.2, or 7.4 for tunneling services. 1326 Callback Login 3 1327 The user should be disconnected and called back, then connected 1328 to a host. The message MAY include additional AVPs defined in 1329 section 7.3. 1331 Callback Framed 4 1332 The user should be disconnected and called back, then a Framed 1333 Protocol should be started for the User, such as PPP or SLIP. 1334 The message MAY include additional AVPs defined in section 7.2, 1335 or 7.4 for tunneling services. 1337 7.2 Framed Access Authorization AVPs 1339 This section contains the authorization AVPs that are necessary to 1340 support framed access, such as PPP, SLIP, etc. AVPs defined in this 1341 section MAY be present in a message if the Service-Type AVP was set 1342 to "Framed" or "Callback Framed". 1344 7.2.1 Framed-Protocol AVP 1346 The Framed-Protocol AVP (AVP Code 7) is of type Unsigned32 and 1347 contains the framing to be used for framed access. This AVP MAY be 1348 present in both requests and responses. The supported values are 1349 listed in [34]. 1351 7.2.2 Framed-Routing AVP 1353 The Framed-Routing AVP (AVP Code 10) is of type Unsigned32 and 1354 contains the routing method for the user, when the user is a router 1355 to a network. This AVP SHOULD only be present in authorization 1356 responses. The supported values are listed in [34]. 1358 7.2.3 Framed-MTU AVP 1360 The Framed-MTU AVP (AVP Code 12) is of type Unsigned32 and contains 1361 the Maximum Transmission Unit to be configured for the user, when it 1362 is not negotiated by some other means (such as PPP). This AVP SHOULD 1363 only be present in authorization responses. The MTU value MUST be 1364 between the range of 64 and 65535. 1366 7.2.4 Framed-Compression AVP 1368 The Framed-Compression AVP (AVP Code 13) is of type Unsigned32 and 1369 contains the compression protocol to be used for the link. It MAY be 1370 used in an authorization request as a hint to the server that a 1371 specific compression type is desired, but the server is not required 1372 to honor the hint in the corresponding response. 1374 More than one compression protocol AVP MAY be sent. It is the 1375 responsibility of the NAS to apply the proper compression protocol to 1376 appropriate link traffic. 1378 The supported values are listed in [34]. 1380 7.2.5 IP Access 1382 The AVPs defined in this section are used when the user requests, or 1383 is being granted, access to IP. They are only present if the Framed- 1384 Protocol AVP (see Section 7.2.1) is set to PPP, SLIP, Gandalf 1385 proprietarySingleLink/MultiLink protocol, or X.75 Synchronous. 1387 7.2.5.1 Framed-IP-Address AVP 1389 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1390 contains the address to be configured for the user. It MAY be used in 1391 an authorization request as a hint to the server that a specific 1392 address is desired, but the server is not required to honor the hint 1393 in the corresponding response. 1395 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1396 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1397 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1398 that the NAS should select an address for the user (e.g. Assigned 1399 from a pool of addresses kept by the NAS). 1401 7.2.5.2 Framed-IP-Netmask AVP 1403 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1404 contains the IP netmask to be configured for the user when the user 1405 is a router to a network. It MAY be used in an authorization request 1406 as a hint to the server that a specific netmask is desired, but the 1407 server is not required to honor the hint in the corresponding 1408 response. This AVP MUST be present in a response if the request 1409 included this AVP with a value of 0xFFFFFFFF. 1411 7.2.5.3 Framed-IP-Route AVP 1413 The Framed-IP-Route AVP (AVP Code 22) is of type OctetString, encoded 1414 in the UTF-8 [29] format, and contains the routing information to be 1415 configured for the user on the NAS. Zero or more such AVPs MAY be 1416 present in an authorization response. 1418 The string MUST contain a destination prefix in dotted quad form 1419 optionally followed by a slash and a decimal length specifier stating 1420 how many high order bits of the prefix should be used. That is 1421 followed by a space, a gateway address in dotted quad form, a space, 1422 and one or more metrics separated by spaces. For example, 1423 "192.168.1.0/24 192.168.1.1 1". 1425 The length specifier may be omitted in which case it should default 1426 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1427 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1429 Whenever the gateway address is specified as "0.0.0.0" the IP address 1430 of the user SHOULD be used as the gateway address. 1432 7.2.6 IPX Access 1434 The AVPs defined in this section are used when the user requests, or 1435 is being granted, access to IPX. They are only present if the 1436 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Xylogics 1437 proprietary IPX/SLIP, Gandalf proprietarySingleLink/MultiLink 1438 protocol, or X.75 Synchronous. 1440 7.2.6.1 Framed-IPX-Network AVP 1442 The Framed-IPX-Network AVP (AVP Code 23) is of type OctetString, 1443 encoded in the UTF-8 [29] format, and contains the IPX Network number 1444 to be configured for the user. It MAY be used in an authorization 1445 request as a hint to the server that a specific address is desired, 1446 but the server is not required to honor the hint in the corresponding 1447 response. 1449 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1450 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1451 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1452 that the NAS should select an address for the user (e.g. assigned 1453 from a pool of one or more IPX networks kept by the NAS). 1455 7.2.7 Appletalk Access 1457 The AVPs defined in this section are used when the user requests, or 1458 is being granted, access to Appletalk. They are only present if the 1459 Framed-Protocol AVP (see Section 7.2.1) is set to PPP, Gandalf 1460 proprietary SingleLink/MultiLink protocol, or X.75 Synchronous. 1462 7.2.7.1 Framed-AppleTalk-Link AVP 1464 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Unsigned32 and 1465 contains the AppleTalk network number which should be used for the 1466 serial link to the user, which is another AppleTalk router. This AVP 1467 MUST only be present in an authorization response and is never used 1468 when the user is not another router. 1470 Despite the size of the field, values range from zero to 65535. The 1471 special value of zero indicates that this is an unnumbered serial 1472 link. A value of one to 65535 means that the serial line between the 1473 NAS and the user should be assigned that value as an AppleTalk 1474 network number. 1476 7.2.7.2 Framed-AppleTalk-Network AVP 1478 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Unsigned32 1479 and contains the AppleTalk Network number which the NAS should probe 1480 to allocate an AppleTalk node for the user. This AVP MUST only be 1481 present in an authorization response and is never used when the user 1482 is not another router. Multiple instances of this AVP indicate that 1483 the NAS may probe using any of the network numbers specified. 1485 Despite the size of the field, values range from zero to 65535. The 1486 special value zero indicates that the NAS should assign a network for 1487 the user, using its default cable range. A value between one and 1488 65535 (inclusive) indicates the AppleTalk Network the NAS should 1489 probe to find an address for the user. 1491 7.2.7.3 Framed-AppleTalk-Zone AVP 1493 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type OctetString 1494 and contains the AppleTalk Default Zone to be used for this user. 1495 This AVP MUST only be present in an authorization response. Multiple 1496 instances of this AVP in the same message are not allowed. 1498 The codification of the range of allowed usage of this field is 1499 outside the scope of this specification. 1501 7.2.8 ARAP Access 1503 The AVPs defined in this section are used when the user requests, or 1504 is being granted, access to ARAP. They are only present if the 1505 Framed-Protocol AVP (see Section 7.2.1) is set to AppleTalk Remote 1506 Access Protocol (ARAP). 1508 7.2.8.1 ARAP-Features AVP 1510 The ARAP-Features AVP (AVP Code 71) is of type OctetString, and MAY 1511 be present in the AA-Accept message if the Framed-Protocol AVP is set 1512 to the value of ARAP. See [32] for more information of the format of 1513 this AVP. 1515 7.2.8.2 ARAP-Zone-Access AVP 1516 The ARAP-Zone-Access AVP (AVP Code 72) is of type Unsigned32, and MAY 1517 be present in the AA-Accept message if the Framed-Protocol AVP is set 1518 to the value of ARAP. 1520 The supported values are listed in [34], and are defined in [32]. 1522 7.2.8.3 ARAP-Security AVP 1524 The ARAP-Security AVP (AVP Code 73) is of type Unsigned32, and MAY be 1525 present in the AA-Answer message if the Framed-Protocol AVP is set to 1526 the value of ARAP, and the Result-Code AVP is set to 1527 DIAMETER_MULTI_ROUND_AUTH. See [32] for more information of the 1528 format of this AVP. 1530 7.2.8.4 ARAP-Security-Data AVP 1532 The ARAP-Security AVP (AVP Code 74) is of type OctetString, and MAY 1533 be present in the AA-Request or AA-Answer message if the Framed- 1534 Protocol AVP is set to the value of ARAP, and the Result-Code AVP is 1535 set to DIAMETER_MULTI_ROUND_AUTH. This AVP contains the security 1536 module challenge or response associated with the ARAP Security Module 1537 specified in ARAP-Security. 1539 7.3 Non-Framed Access Authorization AVPs 1541 This section contains the authorization AVPs that are needed to 1542 support terminal server functionality. AVPs defined in this section 1543 MAY be present in a message if the Service-Type AVP was set to 1544 "Login" or "Callback Login". 1546 7.3.1 Login-IP-Host AVP 1548 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1549 the system with which to connect the user, when the Login-Service AVP 1550 is included. It MAY be used in an authorization request as a hint to 1551 the server that a specific host is desired, but the server is not 1552 required to honor the hint in the corresponding response. 1554 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1555 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1556 select an address. The value zero indicates that the NAS SHOULD 1557 select a host to connect the user to. 1559 7.3.2 Login-Service AVP 1561 The Login-Service AVP (AVP Code 15) is of type Unsigned32 and 1562 contains the service which should be used to connect the user to the 1563 login host. This AVP SHOULD only be present in authorization 1564 responses. 1566 The supported values are listed in [34]. 1568 7.3.3 TCP Services 1570 The AVP described in this section MAY be present if the Login-Service 1571 AVP is set to Telnet, Rlogin, TCP Clear or TCP Clear Quiet. 1573 7.3.3.1 Login-TCP-Port AVP 1575 The Login-TCP-Port AVP (AVP Code 16) is of type Unsigned32 and 1576 contains the TCP port with which the user is to be connected, when 1577 the Login-Service AVP is also present. This AVP SHOULD only be 1578 present in authorization responses. The value MUST NOT be greater 1579 than 65535. 1581 7.3.4 LAT Services 1583 The AVP described in this section MAY be present if the Login-Service 1584 AVP is set to LAT. 1586 7.3.4.1 Login-LAT-Service AVP 1588 The Login-LAT-Service AVP (AVP Code 34) is of type OctetString and 1589 contains the system with which the user is to be connected by LAT. It 1590 MAY be used in an authorization request as a hint to the server that 1591 a specific service is desired, but the server is not required to 1592 honor the hint in the corresponding response. This AVP MUST only be 1593 present in the response if the Login-Service AVP states that LAT is 1594 desired. 1596 Administrators use the service attribute when dealing with clustered 1597 systems, such as a VAX or Alpha cluster. In such an environment 1598 several different time sharing hosts share the same resources (disks, 1599 printers, etc.), and administrators often configure each to offer 1600 access (service) to each of the shared resources. In this case, each 1601 host in the cluster advertises its services through LAT broadcasts. 1603 Sophisticated users often know which service providers (machines) are 1604 faster and tend to use a node name when initiating a LAT connection. 1605 Alternately, some administrators want particular users to use certain 1606 machines as a primitive form of load balancing (although LAT knows 1607 how to do load balancing itself). 1609 The String field contains the identity of the LAT service to use. 1610 The LAT Architecture allows this string to contain $ (dollar), - 1611 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1612 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1613 string comparisons are case insensitive. 1615 7.3.4.2 Login-LAT-Node AVP 1617 The Login-LAT-Node AVP (AVP Code 35) is of type OctetString and 1618 contains the Node with which the user is to be automatically 1619 connected by LAT. It MAY be used in an authorization request as a 1620 hint to the server that a specific LAT node is desired, but the 1621 server is not required to honor the hint in the corresponding 1622 response. This AVP MUST only be present in a response if the 1623 Service-Type AVP is set to LAT. 1625 The String field contains the identity of the LAT service to use. 1626 The LAT Architecture allows this string to contain $ (dollar), - 1627 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1628 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1629 string comparisons are case insensitive. 1631 7.3.4.3 Login-LAT-Group AVP 1633 The Login-LAT-Group AVP (AVP Code 36) is of type OctetString and 1634 contains a string identifying the LAT group codes which this user is 1635 authorized to use. It MAY be used in an authorization request as a 1636 hint to the server that a specific group is desired, but the server 1637 is not required to honor the hint in the corresponding response. This 1638 AVP MUST only be present in a response if the Service-Type AVP is set 1639 to LAT. 1641 LAT supports 256 different group codes, which LAT uses as a form of 1642 access rights. LAT encodes the group codes as a 256 bit bitmap. 1644 Administrators can assign one or more of the group code bits at the 1645 LAT service provider; it will only accept LAT connections that have 1646 these group codes set in the bit map. The administrators assign a 1647 bitmap of authorized group codes to each user; LAT gets these from 1648 the operating system, and uses these in its requests to the service 1649 providers. 1651 The codification of the range of allowed usage of this field is 1652 outside the scope of this specification. 1654 7.3.4.4 Login-LAT-Port AVP 1656 The Login-LAT-Port AVP (AVP Code 63) is of type OctetString and 1657 contains the Port with which the user is to be connected by LAT. It 1658 MAY be used in an authorization request as a hint to the server that 1659 a specific port is desired, but the server is not required to honor 1660 the hint in the corresponding response. This AVP MUST only be present 1661 in a response if the Service-Type AVP is set to LAT. 1663 The String field contains the identity of the LAT service to use. 1664 The LAT Architecture allows this string to contain $ (dollar), - 1665 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1666 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1667 string comparisons are case insensitive. 1669 7.4 Tunneling AVP 1671 The Tunneling AVP (AVP Code 403) is of type Grouped and contains AVPs 1672 used to describe a tunnel. Its Data field has the following ABNF 1673 grammar: 1675 Tunneling ::= < AVP Header: 403 > 1676 { Tunnel-Type } 1677 { Tunnel-Medium-Type } 1678 { Tunnel-Client-Endpoint } 1679 { Tunnel-Server-Endpoint } 1680 [ Tunnel-Preference ] 1681 [ Tunnel-Client-Auth-ID ] 1682 [ Tunnel-Server-Auth-ID ] 1683 [ Tunnel-Assignment-ID ] 1684 [ Tunnel-Password ] 1685 [ Tunnel-Private-Group-ID ] 1687 7.4.1 Tunnel-Type AVP 1689 The Tunnel-Type AVP (AVP Code 64) is of type Unsigned32 and contains 1690 the tunneling protocol(s) to be used (in the case of a tunnel 1691 initiator) or the the tunneling protocol in use (in the case of a 1692 tunnel terminator). It MAY be used in an authorization request as a 1693 hint to the server that a specific tunnel type is desired, but the 1694 server is not required to honor the hint in the corresponding 1695 response. 1697 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1698 Record within the Accounting-Request. 1700 A tunnel initiator is not required to implement any of these tunnel 1701 types; if a tunnel initiator receives a response that contains only 1702 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1703 as though a response was received with the Result-Code indicating a 1704 failure. 1706 The supported values are listed in [34]. 1708 7.4.2 Tunnel-Medium-Type AVP 1710 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and 1711 contains the transport medium to use when creating a tunnel for those 1712 protocols (such as L2TP) that can operate over multiple transports. 1713 It MAY be used in an authorization request as a hint to the server 1714 that a specific medium is desired, but the server is not required to 1715 honor the hint in the corresponding response. 1717 The Value field contains one of the values listed under "Address 1718 Family Numbers" in [10]. The value of most importance is (1) for IPv4 1719 and (2) for IPv6. 1721 7.4.3 Tunnel-Client-Endpoint AVP 1723 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type OctetString, 1724 encoded in the UTF-8 [29] format, and contains the address of the 1725 initiator end of the tunnel. It MAY be used in an authorization 1726 request as a hint to the server that a specific endpoint is desired, 1727 but the server is not required to honor the hint in the corresponding 1728 response. 1730 This AVP SHOULD be included in the ADIF Record of the corresponding 1731 Accounting-Request messages, in which case it indicates the address 1732 from which the tunnel was initiated. This AVP, along with the 1733 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1734 a globally unique means to identify a tunnel for accounting and 1735 auditing purposes. 1737 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1738 fully qualified domain name (FQDN) of the tunnel client machine, or 1739 it is a "dotted-decimal" IP address. Conformant implementations MUST 1740 support the dotted-decimal format and SHOULD support the FQDN format 1741 for IP addresses. 1743 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1744 FQDN of the tunnel client machine, or it is a text representation of 1745 the address in either the preferred or alternate form [5]. 1746 Conformant implementations MUST support the preferred form and SHOULD 1747 support both the alternate text form and the FQDN format for IPv6 1748 addresses. 1750 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1751 referring to configuration data local to the Diameter client that 1752 describes the interface and medium-specific address to use. 1754 7.4.4 Tunnel-Server-Endpoint AVP 1756 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of OctetString, 1757 encoded in the UTF-8 [29] format, and contains the address of the 1758 server end of the tunnel. It MAY be used in an authorization request 1759 as a hint to the server that a specific endpoint is desired, but the 1760 server is not required to honor the hint in the corresponding 1761 response. 1763 This AVP SHOULD be included in the ADIF Record of the corresponding 1764 Accounting-Request messages, in which case it indicates the address 1765 from which the tunnel was initiated. This AVP, along with the 1766 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1767 a globally unique means to identify a tunnel for accounting and 1768 auditing purposes. 1770 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1771 fully qualified domain name (FQDN) of the tunnel client machine, or 1772 it is a "dotted-decimal" IP address. Conformant implementations MUST 1773 support the dotted-decimal format and SHOULD support the FQDN format 1774 for IP addresses. 1776 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1777 FQDN of the tunnel client machine, or it is a text representation of 1778 the address in either the preferred or alternate form [5]. 1779 Conformant implementations MUST support the preferred form and SHOULD 1780 support both the alternate text form and the FQDN format for IPv6 1781 addresses. 1783 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1784 referring to configuration data local to the Diameter client that 1785 describes the interface and medium-specific address to use. 1787 7.4.5 Tunnel-Password AVP 1789 The Tunnel-Password AVP (AVP Code 69) is of type OctetString and may 1790 contain a password to be used to authenticate to a remote server. 1791 This AVP MUST only be present in authorization responses in an 1792 encrypted form, using one of the methods described in [2] and [13]. 1794 7.4.6 Tunnel-Private-Group-ID AVP 1796 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type OctetString, 1797 encoded in the UTF-8 [29] format, and contains the group ID for a 1798 particular tunneled session. The Tunnel-Private-Group-ID AVP MAY be 1799 included in an authorization request if the tunnel initiator can 1800 pre-determine the group resulting from a particular connection and 1801 SHOULD be included in the authorization response if this tunnel 1802 session is to be treated as belonging to a particular private group. 1803 Private groups may be used to associate a tunneled session with a 1804 particular group of users. For example, it MAY be used to facilitate 1805 routing of unregistered IP addresses through a particular interface. 1806 This value SHOULD be included the corresponding ADIF-Record in the 1807 Accounting-Request which pertain to a tunneled session. 1809 7.4.7 Tunnel-Assignment-ID AVP 1811 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type OctetString and 1812 is used to indicate to the tunnel initiator the particular tunnel to 1813 which a session is to be assigned. Some tunneling protocols, such as 1814 PPTP and L2TP, allow for sessions between the same two tunnel 1815 endpoints to be multiplexed over the same tunnel and also for a given 1816 session to utilize its own dedicated tunnel. This attribute provides 1817 a mechanism for Diameter to be used to inform the tunnel initiator 1818 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1819 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1820 sharing multiplexed tunnels to be assigned to different multiplexed 1821 tunnels. 1823 A particular tunneling implementation may assign differing 1824 characteristics to particular tunnels. For example, different 1825 tunnels may be assigned different QOS parameters. Such tunnels may 1826 be used to carry either individual or multiple sessions. The 1827 Tunnel-Assignment-ID attribute thus allows the Diameter server to 1828 indicate that a particular session is to be assigned to a tunnel that 1829 provides an appropriate level of service. It is expected that any 1830 QOS-related Diameter tunneling attributes defined in the future that 1831 accompany this attribute will be associated by the tunnel initiator 1832 with the ID given by this attribute. In the meantime, any semantic 1833 given to a particular ID string is a matter left to local 1834 configuration in the tunnel initiator. 1836 The Tunnel-Assignment-ID AVP is of significance only to Diameter and 1837 the tunnel initiator. The ID it specifies is intended to be of only 1838 local use to Diameter and the tunnel initiator. The ID assigned by 1839 the tunnel initiator is not conveyed to the tunnel peer. 1841 This attribute MAY be included in authorization responses. The tunnel 1842 initiator receiving this attribute MAY choose to ignore it and assign 1843 the session to an arbitrary multiplexed or non-multiplexed tunnel 1844 between the desired endpoints. This attribute SHOULD also be 1845 included in the corresponding ADIF-Record in the Accounting-Request 1846 messages which pertain to a tunneled session. 1848 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1849 should assign a session to a tunnel in the following manner: 1851 - If this AVP is present and a tunnel exists between the specified 1852 endpoints with the specified ID, then the session should be 1853 assigned to that tunnel. 1855 - If this AVP is present and no tunnel exists between the 1856 specified endpoints with the specified ID, then a new tunnel 1857 should be established for the session and the specified ID 1858 should be associated with the new tunnel. 1860 - If this AVP is not present, then the session is assigned to an 1861 unnamed tunnel. If an unnamed tunnel does not yet exist between 1862 the specified endpoints then it is established and used for this 1863 and subsequent sessions established without the Tunnel- 1864 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1865 session for which a Tunnel-Assignment-ID AVP was not specified 1866 to a named tunnel (i.e. one that was initiated by a session 1867 specifying this AVP). 1869 Note that the same ID may be used to name different tunnels if such 1870 tunnels are between different endpoints. 1872 7.4.8 Tunnel-Preference AVP 1874 The Tunnel-Preference AVP (AVP Code 83) is of type Unsigned32 and is 1875 used to identify the relative preference assigned to each tunnel when 1876 more than one set of tunneling AVPs is returned within separate 1877 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1878 hint to the server that a specific preference is desired, but the 1879 server is not required to honor the hint in the corresponding 1880 response. 1882 For example, suppose that AVPs describing two tunnels are returned by 1883 the server, one with a Tunnel-Type of PPTP and the other with a 1884 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1885 the Tunnel-Types returned, it will initiate a tunnel of that type. 1886 If, however, it supports both tunnel protocols, it SHOULD use the 1887 value of the Tunnel-Preference AVP to decide which tunnel should be 1888 started. The tunnel having the numerically lowest value in the Value 1889 field of this AVP SHOULD be given the highest preference. The values 1890 assigned to two or more instances of the Tunnel-Preference AVP within 1891 a given authorization response MAY be identical. In this case, the 1892 tunnel initiator SHOULD use locally configured metrics to decide 1893 which set of AVPs to use. 1895 7.4.9 Tunnel-Client-Auth-ID AVP 1897 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type Unsigned32 and 1898 specifies the name used by the tunnel initiator during the 1899 authentication phase of tunnel establishment. It MAY be used in an 1900 authorization request as a hint to the server that a specific 1901 preference is desired, but the server is not required to honor the 1902 hint in the corresponding response. This AVP MUST be present in the 1903 authorization response if an authentication name other than the 1904 default is desired. This AVP SHOULD be included in the corresponding 1905 ADIF-Record of the Accounting-Request messages which pertain to a 1906 tunneled session. 1908 7.4.10 Tunnel-Server-Auth-ID AVP 1910 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type OctetString 1911 and specifies the name used by the tunnel terminator during the 1912 authentication phase of tunnel establishment. It MAY be used in an 1913 authorization request as a hint to the server that a specific 1914 preference is desired, but the server is not required to honor the 1915 hint in the corresponding response. This AVP MUST be present in the 1916 authorization response if an authentication name other than the 1917 default is desired. This AVP SHOULD be included in the corresponding 1918 ADIF-Record of the Accounting-Request messages which pertain to a 1919 tunneled session. 1921 8.0 Accounting AVPs 1923 This section contains a description of the AVPs defined in this 1924 document that are to be included in Diameter accounting messages [2]. 1926 8.1 Accounting-Input-Octets AVP 1928 The Accounting-Input-Octets AVP (AVP Code 42) is of type Unsigned64, 1929 and contains the number of octets in IP packets received by the user. 1931 8.2 Accounting-Output-Octets AVP 1933 The Accounting-Output-Octets AVP (AVP Code 43) is of type Unsigned64, 1934 and contains the number of octets in IP packets sent to the user. 1936 8.3 Accounting-Session-Time AVP 1938 The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, 1939 and indicates the length of the current session in seconds. 1941 8.4 Accounting-Input-Packets AVP 1943 The Accounting-Input-Packets (AVP Code 47) is of type Unsigned64, and 1944 contains the number of IP packets received by the user. 1946 8.5 Accounting-Output-Packets AVP 1948 The Accounting-Output-Packets (AVP Code 48) is of type Unsigned64, 1949 and contains the number of IP packets sent to the user. 1951 8.6 Accounting-Authentication-Type AVP 1953 The Accounting-Authentication-Type AVP (AVP Code 45) is of type 1954 Unsigned32, and specifies how the user was authenticated. The 1955 supported values are listed in [34]. 1957 8.7 Acct-Tunnel-Connection AVP 1959 The Acct-Tunnel-Connection AVP (AVP Code 68) is of type OctetString, 1960 and contains the identifier assigned to the tunnel session. This AVP, 1961 along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint 1962 AVPs, may be used to provide a means to uniquely identify a tunnel 1963 session for auditing purposes. 1965 The format of the identifier in this AVP depends upon the value of 1966 the Tunnel-Type AVP. For example, to fully identify an L2TP tunnel 1967 connection, the L2TP Tunnel ID and Call ID might be encoded in this 1968 field. The exact encoding of this field is implementation dependent. 1970 8.8 Acct-Tunnel-Packets-Lost AVP 1972 The Acct-Tunnel-Packets-Lost AVP (AVP Code 86) is of type Unsigned32 1973 and contains the number of packets lost on a given link. 1975 9.0 RADIUS/Diameter Protocol Interactions 1977 This section describes some basic guidelines that may be used by 1978 servers that act as protocol gateways. Note that this document does 1979 not restrict implementations from creating other methods, as long as 1980 the bridging function doesn't break the RADIUS nor the Diameter 1981 protocol. 1983 There are essentially two different situations that must be handled; 1984 one where a RADIUS request is received that must be forwarded as a 1985 Diameter request, and the inverse. Note that this section uses two 1986 different terms; AVP and attribute. The former is used to signify a 1987 Diameter AVP, while the latter is used to signify a RADIUS attribute. 1989 9.1 RADIUS request forwarded as Diameter request 1991 This section describes the actions that should be followed when a 1992 protocol Gateway receives a RADIUS message that is to be translated 1993 to a Diameter message. 1995 It is important to note that RADIUS servers are inherently stateless, 1996 and this section maintains that assumption. It is quite possible for 1997 the RADIUS messages that comprises the session (i.e. authentication 1998 and accounting messages) be handled by different protocol gateways in 1999 the proxy network. Therefore a RADIUS->Diameter protocol gateway 2000 cannot maintain session state information. 2002 When a protocol gateway receives a RADIUS message, the following 2003 steps should be taken: 2005 - If the NAS-IP-Address attribute is present in the RADIUS 2006 message, the name MUST be translated to its corresponding FQDN, 2007 and encoded in the Diameter message's Origin-Host AVP. If the 2008 NAS-Identifier attribute is present, the data can be used in the 2009 Origin-Host AVP. 2010 - The Origin-Host AVP is added with the local server's identity. 2011 This will ensure that the corresponding response will be 2012 returned to the correct gateway server. The protocol specified 2013 in the identity would be set to "radius://". 2014 - The Destination-Realm AVP is created from the information found 2015 in the RADIUS User-Name attribute. 2016 - The Gateway Server must maintain state information relevant to 2017 the RADIUS request, such as the Identifier field in the RADIUS 2018 header, any existing RADIUS Proxy-State attribute as well as the 2019 source IP address and port number of the UDP packet. These may 2020 be maintained locally in a state table, or may be saved in a 2021 Proxy-Info AVP. 2022 - If the Acct-Session-Id attribute was found in the request, the 2023 contents are inserted in the Acct-Session-Id AVP. 2024 - If the RADIUS request contained a Class or State attribute, and 2025 the prefix of the data is "Diameter/", the data following the 2026 prefix contains the Diameter Session-Id. If no such attributes 2027 are present, and the RADIUS command is an Access-Request, a new 2028 Session-Id is created. The Session-Id is included in the 2029 Session-Id AVP. 2030 - If the RADIUS message received is an Accounting-Request, with 2031 the Acct-Status-Type attribute set to STOP, the local server 2032 MUST issue a Session-Termination-Request message once the 2033 Diameter Accounting-Answer has been received. 2035 The corresponding Diameter response is always guaranteed to be 2036 received by the same protocol gateway that translated the original 2037 request, due to the contents of the Origin-Host AVP in the Diameter 2038 request. The following steps are applied to the response message 2039 during the Diameter to RADIUS translation: 2041 - If the Diameter Command-Code is set to AA-Answer and the 2042 Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway 2043 must send a RADIUS Access-Challenge with the the Diameter 2044 Session-Id and the Origin-Host AVPs are saved in the RADIUS 2045 State attribute, with the prefix "Diameter/". This is necessary 2046 in order to ensure that the protocol gateway that will receive 2047 the subsequent RADIUS Access-Request will have access to the 2048 Session Identifier, and be able to set the Destination-Host to 2049 the correct value. 2050 - If the Command-Code is set to AA-Answer, the Diameter Session-Id 2051 AVP is saved in a new RADIUS Class attribute, whose format 2052 consists of the string "Diameter/" followed by the Diameter 2053 Session Identifier. This will ensure that the subsequent 2054 Accounting messages, which could be received by any protocol 2055 gateway, would have access to the original Diameter Session 2056 Identifier. 2057 - If a Proxy-State attribute was present in the RADIUS request, 2058 the same attribute is added in the response. This information 2059 may be found in the Proxy-Info AVP, or in a local state table. 2060 - If state information regarding the RADIUS request was saved in a 2061 Proxy-Info AVP, the RADIUS Identifier and UDP IP Address and 2062 port number are extracted and used in issuing the RADIUS reply. 2064 9.2 Diameter request forwarded as RADIUS request 2066 When a server receives a Diameter request that is to be forwarded to 2067 a RADIUS entity, the following steps are an example of the steps that 2068 may be followed: 2070 - The Origin-Host AVP's value is inserted in the NAS-Identifier 2071 attribute. 2072 - The following information MUST be present in the corresponding 2073 Diameter response, and therefore MUST be saved either in a local 2074 state table, or it MAY be encoded in a RADIUS Proxy-State 2075 attribute: 2076 1. Origin-Host AVP 2077 2. Session-Id AVP 2078 3. Proxy-Info AVP 2079 4. Route-Record AVPs (in the proper order) 2080 5. Any other AVP that MUST be present in the response, and 2081 has no corresponding RADIUS attribute. 2083 When the corresponding response is received by the gateway server, 2084 which is guaranteed in the RADIUS protocol, the following steps may 2085 be followed: 2087 - If the RADIUS code is set to Access-Challenge, a Diameter AA- 2088 Answer message is created with the Result-Code set to 2089 DIAMETER_MULTI_ROUND_AUTH. 2090 - If a Proxy-Info AVP is present, extract the encoded information, 2091 otherwise retrieve the information from the local state table. 2092 - The request's Origin-Host information is added to the 2093 Destination-Host AVP. 2094 - The Session-Id information is added to the Session-Id AVP. 2095 - The Route-Record AVPs MUST be added to the Diameter message, in 2096 the same order they were present in the request. 2097 - If a Proxy-Info AVP was present in the request, the same AVP MUST 2098 be added to the response. 2099 - If the RADIUS Class or State attributes are present, these 2100 attributes must be present in the Diameter response. 2101 - Any other AVPs that were saved, and MUST be present in the 2102 response, are added to the message. 2104 10.0 AVP Occurrence Table 2106 The following tables presents the AVPs defined in this document, and 2107 specifies in which Diameter messages they MAY, or MAY NOT be present. 2108 Note that AVPs that can only be present within a Grouped AVP are not 2109 represented in this table. 2111 The table uses the following symbols: 2112 0 The AVP MUST NOT be present in the message. 2113 0+ Zero or more instances of the AVP MAY be present in the 2114 message. 2115 0-1 Zero or one instance of the AVP MAY be present in the 2116 message. 2117 1 One instance of the AVP MUST be present in the message. 2119 10.1 NASREQ Command AVP Table 2121 The table in this section is limited to the Command Codes defined in 2122 this specification. 2124 +-----------------------+ 2125 | Command-Code | 2126 |-----+-----+-----+-----+ 2127 Attribute Name | AAR | AAA | DER | DEA | 2128 ------------------------------|-----+-----+-----+-----| 2129 ARAP-Challenge-Response | 0 | 0-1 | 0 | 0-1 | 2130 ARAP-Features | 0 | 0-1 | 0 | 0-1 | 2131 ARAP-Password | 0-1 | 0 | 0-1 | 0 | 2132 ARAP-Security | 0-1 | 0 | 0-1 | 0 | 2133 ARAP-Security-Data | 0+ | 0 | 0+ | 0 | 2134 ARAP-Zone-Access | 0 | 0-1 | 0 | 0-1 | 2135 Callback-Id | 0 | 0-1 | 0 | 0-1 | 2136 Auth-Application-Id | 1 | 1 | 1 | 1 | 2137 Authorization-Lifetime | 0-1 | 0-1 | 0-1 | 0-1 | 2138 Callback-Number | 0-1 | 0-1 | 0-1 | 0-1 | 2139 Called-Station-Id | 0-1 | 0 | 0-1 | 0 | 2140 Calling-Station-Id | 0-1 | 0 | 0-1 | 0 | 2141 CHAP-Challenge | 0-1 | 0 | 0 | 0 | 2142 CHAP-Password | 0-1 | 0 | 0 | 0 | 2143 Class | 0 | 0+ | 0 | 0+ | 2144 Connect-Info | 0-1 | 0 | 0-1 | 0 | 2145 Destination-Host | 0+ | 1 | 0+ | 1 | 2146 Destination-Realm | 0 | 1 | 1 | 0 | 2147 EAP-Payload | 0 | 0 | 1 | 1 | 2148 Error-Reporting-Host | 0 | 0+ | 0 | 0+ | 2149 Filter-Id | 0 | 0+ | 0 | 0+ | 2150 Filter-Rule | 0 | 0+ | 0 | 0+ | 2151 Framed-Appletalk-Link | 0 | 0-1 | 0 | 0-1 | 2152 Framed-Appletalk-Network | 0 | 0+ | 0 | 0+ | 2153 Framed-Appletalk-Zone | 0 | 0-1 | 0 | 0-1 | 2154 +-----------------------+ 2155 | Command-Code | 2156 |-----+-----+-----+-----+ 2157 Attribute Name | AAR | AAA | DER | DEA | 2158 ------------------------------|-----+-----+-----+-----| 2159 Framed-Compression | 0+ | 0+ | 0+ | 0+ | 2160 Framed-IP-Address | 0-1 | 0 | 0-1 | 0 | 2161 Framed-IP-Netmask | 0-1 | 0-1 | 0-1 | 0-1 | 2162 Framed-IP-Route | 0 | 0+ | 0 | 0+ | 2163 Framed-IPX-Network | 0 | 0-1 | 0 | 0-1 | 2164 Framed-MTU | 0 | 0-1 | 0 | 0-1 | 2165 Framed-Protocol | 0-1 | 0 | 0-1 | 0 | 2166 Framed-Routing | 0-1 | 0 | 0-1 | 0 | 2167 Idle-Timeout | 0-1 | 0-1 | 0-1 | 0-1 | 2168 Login-IP-Host | 0+ | 0+ | 0 | 0 | 2169 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2170 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2171 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2172 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2173 Login-Service | 0 | 0+ | 0 | 0 | 2174 Login-TCP-Port | 0 | 0+ | 0 | 0 | 2175 NAS-IP-Address | 1 | 0 | 1 | 0 | 2176 NAS-Key-Binding | 0-1 | 0 | 0-1 | 0 | 2177 NAS-Port | 1 | 0 | 1 | 0 | 2178 NAS-Port-Type | 0-1 | 0 | 0-1 | 0 | 2179 NAS-Session-Key | 0 | 0+ | 0 | 0+ | 2180 Origin-Host | 1 | 1 | 1 | 1 | 2181 Origin-Realm | 1 | 1 | 1 | 1 | 2182 Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 2183 Password-Retry | 0 | 0-1 | 0 | 0 | 2184 Port-Limit | 0-1 | 0 | 0-1 | 0 | 2185 Prompt | 0 | 0-1 | 0 | 0 | 2186 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 2187 Reply-Message | 0 | 0 | 0 | 0 | 2188 Request-Type | 1 | 1 | 1 | 1 | 2189 Result-Code | 0 | 1 | 0 | 1 | 2190 Route-Record | 0+ | 0+ | 0+ | 0+ | 2191 Service-Type | 1 | 1 | 1 | 1 | 2192 Session-Id | 1 | 1 | 1 | 1 | 2193 Session-Timeout | 0 | 0-1 | 0 | 0-1 | 2194 State | 0-1 | 0-1 | 0 | 0-1 | 2195 Tunneling | 0+ | 0+ | 0+ | 0+ | 2196 User-Name | 0-1 | 0-1 | 0-1 | 0-1 | 2197 User-Password | 0-1 | 0 | 0 | 0 | 2199 10.2 Accounting AVP Table 2200 The tables in this section are used to represent which AVPs defined 2201 in this document are to be present in the Accounting messages, 2202 defined in [1]. 2204 10.2.1 Framed Access 2206 The table in this section is used when the Service-Type specifies 2207 Framed Access. 2209 +-----------------------+ 2210 | Command-Code | 2211 |-----+-----+-----+-----+ 2212 Attribute Name | ACR | ACA | ASI | API | 2213 ------------------------------|-----+-----+-----+-----+ 2214 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2215 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2216 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2217 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2218 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2219 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2220 Accounting-State | 0 | 0 | 1 | 0 | 2221 Acct-Tunnel-Connection | 0-1 | 0-1 | 0 | 0 | 2222 Acct-Tunnel-Packets-Lost | 0-1 | 0-1 | 0 | 0 | 2223 Framed-AppleTalk-Link | 0-1 | 0-1 | 0 | 0 | 2224 Framed-AppleTalk-Network | 0-1 | 0-1 | 0 | 0 | 2225 Framed-AppleTalk-Zone | 0-1 | 0-1 | 0 | 0 | 2226 Framed-Compression | 0-1 | 0-1 | 0 | 0 | 2227 Framed-IP-Address | 0-1 | 0-1 | 0 | 0 | 2228 Framed-IP-Netmask | 0-1 | 0-1 | 0 | 0 | 2229 Framed-IPX-Network | 0-1 | 0-1 | 0 | 0 | 2230 Framed-MTU | 0-1 | 0-1 | 0 | 0 | 2231 Framed-Protocol | 0-1 | 0-1 | 0 | 0 | 2232 Framed-Route | 0-1 | 0-1 | 0 | 0 | 2233 Framed-Routing | 0-1 | 0-1 | 0 | 0 | 2234 Service-Type | 1 | 1 | 0 | 0 | 2235 Tunnel-Assignment-ID | 0-1 | 0-1 | 0 | 0 | 2236 Tunnel-Client-Endpoint | 0-1 | 0-1 | 0 | 0 | 2237 Tunnel-Medium-Type | 0-1 | 0-1 | 0 | 0 | 2238 Tunnel-Private-Group-ID | 0-1 | 0-1 | 0 | 0 | 2239 Tunnel-Server-Endpoint | 0-1 | 0-1 | 0 | 0 | 2240 Tunnel-Type | 0-1 | 0-1 | 0 | 0 | 2241 ------------------------------|-----+-----+-----+-----+ 2243 10.2.2 Non-Framed Access 2245 The table in this section is used when the Service-Type specifies 2246 Non-Framed Access. 2248 +-----------------------+ 2249 | Command-Code | 2250 |-----+-----+-----+-----+ 2251 Attribute Name | ACR | ACA | ASI | API | 2252 ------------------------------|-----+-----+-----+-----+ 2253 Accounting-Authentication-Type| 1 | 0-1 | 0 | 0 | 2254 Accounting-Input-Octets | 1 | 1 | 0 | 0 | 2255 Accounting-Input-Packets | 1 | 1 | 0 | 0 | 2256 Accounting-Output-Octets | 1 | 1 | 0 | 0 | 2257 Accounting-Output-Packets | 1 | 1 | 0 | 0 | 2258 Accounting-Session-Time | 1 | 1 | 0 | 0 | 2259 Accounting-State | 0 | 0 | 1 | 0 | 2260 Login-IP-Host | 0-1 | 0-1 | 0 | 0 | 2261 Login-LAT-Service | 0-1 | 0-1 | 0 | 0 | 2262 Login-LAT-Node | 0-1 | 0-1 | 0 | 0 | 2263 Login-LAT-Group | 0-1 | 0-1 | 0 | 0 | 2264 Login-LAT-Port | 0-1 | 0-1 | 0 | 0 | 2265 Login-Service | 0-1 | 0-1 | 0 | 0 | 2266 Login-TCP-Port | 0-1 | 0-1 | 0 | 0 | 2267 Service-Type | 1 | 1 | 0 | 0 | 2268 ------------------------------|-----+-----+-----+-----+ 2270 11.0 IANA Considerations 2272 This section contains the namespaces that have either been created in 2273 this specification, or the values assigned to existing namespaces 2274 managed by IANA. 2276 11.1 Command Codes 2278 This specification assigns the values 265 and 268 from the Command 2279 Code namespace defined in [2]. See sections 3.1 and 4.2 for the 2280 assignment of the namespace in this specification. 2282 11.2 AVP Codes 2284 This specification assigns the values 400-403 from the AVP Code 2285 namespace defined in [2]. See section 2.1 for the assignment of the 2286 namespace in this specification. 2288 This specification also makes use of AVPs in the 0-255 range, which 2289 are defined in [34]. 2291 11.3 Request-Type AVP Values 2293 As defined in Section 2.1.1, the Request-Type AVP (AVP Code 401) 2294 defines the values 1-3. All remaining values are available for 2295 assignment via IETF Consensus [27]. 2297 11.4 Application Identifier 2299 This specification assigns the value one (1) to the Application 2300 Identifier namespace defined in [1]. See section 1.2 for more 2301 information. 2303 11.5 NAS-Key-Binding AVP Values 2305 As defined in Section 2.1.7, the NAS-Key-Binding AVP (AVP Code TBD) 2306 defines the values 1-6. All remaining values, other than zero, are 2307 available for assignment via a Designated Expert [12]. 2309 11.6 NAS-Key-Direction AVP Values 2311 As defined in Section 2.1.4, the NAS-Key-Direction AVP (AVP Code TBD) 2312 defines the values 1-3. All remaining values, other than zero, are 2313 available for assignment via IETF Consensus [12]. 2315 11.7 NAS-Key-Type AVP Values 2317 As defined in Section 2.1.5, the NAS-Key-Type AVP (AVP Code TBD) 2318 defines the values 1-2. All remaining values, other than zero, are 2319 available for assignment via IETF Consensus [12]. 2321 12.0 Security Considerations 2323 This document does not contain any security protocol, but does 2324 discuss how PPP authentication protocols can be carried within the 2325 Diameter protocol. The PPP authentication protocols that are 2326 described are PAP, CHAP and EAP. 2328 The use of PAP SHOULD be discouraged, since it exposes user's 2329 passwords to possibly non-trusted entities. PAP is also frequently 2330 used for use with One-Time Passwords (OTP), which does not expose any 2331 security risks. However, it is highly recommended that OTP be 2332 supported through the EAP protocol. 2334 This document also describes how CHAP can be carried within the 2335 Diameter protocol, which is required for backward RADIUS 2336 compatibility. The CHAP protocol, as used in a RADIUS environment, 2337 facilitates authentication replay attacks, and therefore SHOULD NOT 2338 be used when EAP is available. 2340 13.0 References 2342 [1] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authenti- 2343 cation Dial In User Service (RADIUS)", RFC 2865, June 2000. 2345 [2] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- 2346 ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in 2347 progress, June 2001. 2349 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 2350 ary 1999. 2352 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2353 2477, January 1999. 2355 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 2356 RFC 2373, July 1998 2358 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 2359 (CHAP)", RFC 1994, August 1996. 2361 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 2362 links", RFC 1144, February 1990. 2364 [8] ISO 8859. International Standard -- Information Processing -- 2365 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 2366 Alphabet No. 1, ISO 8859-1:1987. 2367 2369 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 2370 (MP)", RFC 1717, November 1994. 2372 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 2373 October 1994 2375 [11] G. Zorn, B. Aboba, D. Mitton, "RADIUS Accounting Modifications 2376 for Tunnel Protocol Support", RFC 2867, June 2000. 2378 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2379 Levels", BCP 14, RFC 2119, March 1997. 2381 [13] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Appli- 2382 cation", draft-ietf-aaa-diameter-cms-sec-00.txt, IETF work in 2383 progress, June 2001. 2385 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 2386 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 2387 July 1999 2389 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 2390 warding (Protocol) 'L2F'", RFC 2341, May 1998 2392 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 2393 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 2394 August 1999 2396 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2397 2107, February 1997 2399 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 2400 Protocol", RFC 2401, November 1998 2402 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 2403 1996 2405 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 2406 October 1996 2408 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 2409 1827, August 1995 2411 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 2412 Encapsulation (GRE)", RFC 1701, October 1994 2414 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 2416 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 2417 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 2418 in progress, June 2000. 2420 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 2421 Protocol (EAP)." RFC 2284, March 1998. 2423 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 2424 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 2425 1999. 2427 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 2428 tions Section in RFCs", BCP 26, RFC 2434, October 1998 2430 [28] G. Zorn, D. Mitton, B. Aboba, "RADIUS Accounting Modifications 2431 for Tunnel Protocol Support", RFC 2867, June 2000. 2433 [29] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2434 2279, January 1998. 2436 [30] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 2437 draft-ietf-aaa-diameter-mobileip-05.txt, IETF work in progress, 2438 June 2001. 2440 [31] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2441 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2442 June 2000. 2444 [32] C. Rigney, W. Willats, P. Calhoun, "RADIUS Extensions", RFC 2445 2869, June 2000. 2447 [33] G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goy- 2448 ret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, 2449 June 2000. 2451 [34] IANA, "RADIUS Types", http://www.isi.edu/in- 2452 notes/iana/assignments/radius-types 2454 [35] C. Rigney, "RADIUS Accounting", RFC 2866, June 2000. 2456 [36] K. Sklower, G. Meyer, "The PPP DES Encryption Protocol, Version 2457 2 (DESE-bis)", RFC 2419, September 1998. 2459 [37] H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE)", 2460 RFC 2402, September 1998. 2462 [38] G. Pall, G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) 2463 Protocol", RFC 3078, March 2001. 2465 14.0 Acknowledgements 2467 The authors would like to thank Carl Rigney, Allan C. Rubens, William 2468 Allen Simpson, and Steve Willens for their work on the original 2469 RADIUS, from which much of the concepts in this specification were 2470 derived from. Also Carl Rigney and Ward Willats for [32], and Glen 2471 Zorn, Dory Leifer, Allan C. Rubens, John Shriver, Matt Holdrege and 2472 Ignacio Goyret for their work on [33]. This document stole text and 2473 concepts from both [32] and [33]. 2475 The authors would also like to acknowledge the following people for 2476 their contribution in the development of the Diameter protocol: 2478 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 2479 Nancy Greene, Peter Heitman, Paul Krumviede, Fergal Ladley, Ryan 2480 Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John R. Vollbrecht 2481 and Jeff Weisberg 2483 15.0 Authors' Addresses 2485 Questions about this memo can be directed to: 2487 Pat R. Calhoun 2488 Network and Security Research Center, Sun Labs 2489 Sun Microsystems, Inc. 2490 15 Network Circle 2491 Menlo Park, California, 94025 2492 USA 2494 Phone: +1 650-786-7733 2495 Fax: +1 650-786-6445 2496 E-mail: pcalhoun@eng.sun.com 2498 William Bulley 2499 Merit Network, Inc. 2500 Building One, Suite 2000 2501 4251 Plymouth Road 2502 Ann Arbor, Michigan 48105-2785 2503 USA 2505 Phone: +1 734-764-9993 2506 Fax: +1 734-647-3185 2507 E-mail: web@merit.edu 2509 Allan C. Rubens 2510 Tut Systems, Inc. 2511 220 E. Huron, Suite 260 2512 Ann Arbor, MI 48104 2513 USA 2515 Phone: +1 734-995-1697 2516 E-Mail: arubens@tutsys.com 2518 Jeff Haag 2519 Cisco Systems 2520 7025 Kit Creek Road 2521 PO Box 14987 2522 Research Triangle Park, NC 27709 2524 Phone: 1-919-392-2353 2525 E-Mail: haag@cisco.com 2527 Glen Zorn 2528 Cisco Systems, Inc. 2529 500 108th Avenue N.E., Suite 500 2530 Bellevue, WA 98004 2531 USA 2533 Phone: +1 425 438 8218 2534 E-Mail: gwz@cisco.com 2536 16.0 Full Copyright Statement 2538 Copyright (C) The Internet Society (2001). All Rights Reserved. 2540 This document and translations of it may be copied and furnished to 2541 others, and derivative works that comment on or otherwise explain it 2542 or assist in its implementation may be prepared, copied, published 2543 and distributed, in whole or in part, without restriction of any 2544 kind, provided that the above copyright notice and this paragraph are 2545 included on all such copies and derivative works. However, this docu- 2546 ment itself may not be modified in any way, such as by removing the 2547 copyright notice or references to the Internet Society or other 2548 Internet organizations, except as needed for the purpose of develop- 2549 ing Internet standards in which case the procedures for copyrights 2550 defined in the Internet Standards process must be followed, or as 2551 required to translate it into languages other than English. The lim- 2552 ited permissions granted above are perpetual and will not be revoked 2553 by the Internet Society or its successors or assigns. This document 2554 and the information contained herein is provided on an "AS IS" basis 2555 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 2556 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 2557 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2558 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2559 FITNESS FOR A PARTICULAR PURPOSE. 2561 17.0 Expiration Date 2563 This memo is filed as and 2564 expires in December 2001.