idnits 2.17.1 draft-calhoun-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 38 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 39 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 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 3 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 == 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1571, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1597, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-17 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '4') ** Obsolete normative reference: RFC 2373 (ref. '5') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1717 (ref. '9') (Obsoleted by RFC 1990) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-07 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-05 -- 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) == Outdated reference: A later version (-05) exists of draft-calhoun-diameter-impl-guide-03 -- Possible downref: Normative reference to a draft: ref. '28' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-08 -- Possible downref: Normative reference to a draft: ref. '29' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-11 -- Possible downref: Normative reference to a draft: ref. '30' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-05 -- Possible downref: Normative reference to a draft: ref. '31' Summary: 22 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-nasreq-05.txt William Bulley 5 Date: September 2000 Merit Network, Inc. 6 Allan C. Rubens 7 Tut Systems, Inc. 8 Jeff Haag 9 Cisco Systems 11 DIAMETER NASREQ Extensions 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 This document is an individual contribution for consideration by the 35 AAA Working Group of the Internet Engineering Task Force. Comments 36 should be submitted to the diameter@diameter.org mailing list. 38 Distribution of this memo is unlimited. 40 Copyright (C) The Internet Society 1999. All Rights Reserved. 42 Abstract 44 This document describes the DIAMETER extension that is used for AAA 45 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 46 extension, combined with the base protocol, satisfies the 47 requirements defined in the NASREQ AAA criteria specification and the 48 ROAMOPS AAA Criteria specification. 50 Given that it is expected that initial deployments of the DIAMETER 51 protocol in a dial-up environment will include legacy systems, this 52 extension was carefully designed to ease the burden of servers that 53 must perform protocol conversion between RADIUS and DIAMETER. This 54 is achieved by re-using the RADIUS address space, eliminating the 55 need to perform attribute lookups. 57 Table of Contents 59 1.0 Introduction 60 1.1 Requirements language 61 2.0 Supported AVPs 62 2.1 DIAMETER AVPs 63 2.1.1 Request-Type AVP 64 2.1.2 Filter-Rule AVP 65 2.2 Legacy RADIUS Attributes 66 2.2.1 NAS-IP-Address AVP 67 2.2.2 NAS-Identifier AVP 68 2.2.3 State AVP 69 2.2.4 Class AVP 70 3.0 Legacy PPP Authentication Support 71 3.1 Command-Codes Values 72 3.1.1 AA-Request (AAR) Command 73 3.1.1.1 User-Password AVP 74 3.1.1.2 CHAP-Password AVP 75 3.1.1.3 CHAP-Challenge AVP 76 3.1.2 AA-Answer (AAA) Command 77 3.1.3 AA-Challenge-Ind (ACI) Command 78 3.2 Reply-Message AVP 79 4.0 Extensible Authentication Protocol Support 80 4.1 Alternative Uses 81 4.2 Command-Codes Values 82 4.2.1 DIAMETER-EAP-Request (DER) Command 83 4.2.2 DIAMETER-EAP-Answer (DEA) Command 84 4.2.3 DIAMETER-EAP-Ind (DEI) Command 85 4.3 EAP-Payload AVP 86 5.0 DIAMETER Session Termination 87 6.0 Legacy Authorization AVPs 88 6.1 Service Identification AVPs 89 6.1.1 NAS-Port AVP 90 6.1.2 Service-Type AVP 91 6.1.3 Filter-Id AVP 92 6.1.4 Callback-Number AVP 93 6.1.5 Callback-Id AVP 94 6.1.6 Idle-Timeout AVP 95 6.1.7 Called-Station-Id AVP 96 6.1.8 Calling-Station-Id AVP 97 6.1.9 NAS-Port-Type AVP 98 6.1.10 Port-Limit AVP 99 6.1.11 Filter-Rule AVP 100 6.2 Framed Access Authorization AVPs 101 6.2.1 Framed-Protocol AVP 102 6.2.2 Framed-IP-Address AVP 103 6.2.3 Framed-IP-Netmask AVP 104 6.2.4 Framed-Routing AVP 105 6.2.5 Framed-MTU AVP 106 6.2.6 Framed-Compression AVP 107 6.2.7 Framed-IP-Route AVP 108 6.2.8 Framed-IPX-Network AVP 109 6.2.9 Framed-AppleTalk-Link AVP 110 6.2.10 Framed-AppleTalk-Network AVP 111 6.2.11 Framed-AppleTalk-Zone AVP 112 6.3 Non-Framed Access Authorization AVPs 113 6.3.1 Login-IP-Host AVP 114 6.3.2 Login-Service AVP 115 6.3.3 Login-TCP-Port AVP 116 6.3.4 Login-LAT-Service AVP 117 6.3.5 Login-LAT-Node AVP 118 6.3.6 Login-LAT-Group AVP 119 6.3.7 Login-LAT-Port AVP 120 6.4 Tunneling AVPs 121 6.4.1 Tunnel-Type AVP 122 6.4.2 Tunnel-Medium-Type AVP 123 6.4.3 Tunnel-Client-Endpoint AVP 124 6.4.4 Tunnel-Server-Endpoint AVP 125 6.4.5 Tunnel-Password AVP 126 6.4.6 Tunnel-Private-Group-ID AVP 127 6.4.7 Tunnel-Assignment-ID AVP 128 6.4.8 Tunnel-Preference AVP 129 6.4.9 Tunnel-Client-Auth-ID AVP 130 6.4.10 Tunnel-Server-Auth-ID AVP 131 7.0 Interactions with Resource Management 132 8.0 IANA Considerations 133 8.1 Request-Type AVP Values 134 9.0 Security Considerations 135 10.0 References 136 11.0 Acknowledgements 137 12.0 Authors' Addresses 138 13.0 Full Copyright Statement 140 1.0 Introduction 142 This document describes the DIAMETER extension that is used for AAA 143 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 144 extension, combined with the base protocol [2], satisfies the 145 requirements defined in the NASREQ AAA criteria specification [24] 146 and the ROAMOPS AAA Criteria specification [4]. 148 This document is divided into three main sections. The first section 149 defines the DIAMETER Command-Codes and AVPs that are needed to 150 support legacy PPP authentication protocols, those that are typically 151 supported by RADIUS [1] servers. The second section defines the 152 Command-Codes and AVPs necessary for a DIAMETER node to support PPP's 153 Extensible Authentication Protocol (EAP) [25]. The third section 154 contains the Authorization AVPs that are needed for the various 155 services offered by a NAS, such as PPP dial-in, terminal server and 156 tunneling applications, such as L2TP [16]. 158 Given that it is expected that initial deployments of the DIAMETER 159 protocol in a dial-up environment will include legacy systems, this 160 extension was carefully designed to ease the burden of servers that 161 must perform protocol conversion between RADIUS and DIAMETER. This 162 is achieved by re-using the RADIUS address space, eliminating the 163 need to perform attribute lookups. 165 The value assigned for the Extension-Id [2] AVP is one (1). 167 1.1 Requirements language 169 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 170 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 171 described in [12]. 173 2.0 Supported AVPs 175 This section lists all of the DIAMETER AVPs and the legacy RADIUS 176 attributes supported by this extension. 178 2.1 DIAMETER AVPs 180 This section will define all of the AVPs that are not backward 181 compatible with the RADIUS protocol [1]. A DIAMETER message that 182 includes one of these AVPs MAY cause interoperability issues should 183 the request traverse a AAA node that only supports the RADIUS 184 protocol. However, the DIAMETER protocol SHOULD NOT be hampered from 185 future developments due to the existing installed base. 187 The following table describes the DIAMETER AVPs defined in the NASREQ 188 extension, their AVP Code values, types, possible flag values and 189 whether the AVP MAY be encrypted. 191 +---------------------+ 192 | AVP Flag rules | 193 |----+-----+----+-----|----+ 194 AVP Section Value | | |SHLD| MUST|MAY | 195 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 196 -----------------------------------------|----+-----+----+-----|----+ 197 Filter-Rule 400 2.1.2 String | M | P | | V | Y | 198 Request-Type 401 2.1.1 Integer32| M | P | | V | N | 199 EAP-Payload 402 4.2 Data | M | P | | V | Y | 201 2.1.1 Request-Type AVP 203 The Request-Type AVP (AVP Code 401) is of type Integer32 and is used 204 to determine the type of request being transmitted. Note that a 205 request with this AVP set to a value other than 206 AUTHORIZE_AUTHENTICATE MAY break backward RADIUS compatibility. The 207 following values are defined: 209 AUTHENTICATE_ONLY 1 210 The request being sent is for authentication only, and MUST 211 contain the relevant authentication AVPs that are needed by the 212 DIAMETER server to authenticate the user. 214 AUTHORIZE_ONLY 2 215 The request being sent is for authorization only, and MUST 216 contain the authorization AVPs that are necessary to identify 217 the service being requested/offered. 219 AUTHORIZE_AUTHENTICATE 3 220 The request contains a request for both authentication and 221 authorization. The request MUST include both the relevant 222 authentication information, and authorization information 223 necessary to identify the service being requested/offered. 225 2.1.2 Filter-Rule AVP 226 The Filter-Rule AVP (AVP Code 400) is of type String and provides 227 filter rules that need to be configured on the NAS for the user. One 228 or more such AVPs MAY be present in an authorization response. 230 The String field MUST contain a filter rule in the following format: 231 "permit (offset=value AND offset=value) OR offset=value" or "deny 232 (offset=value AND offset=value) OR offset=value". The keyword 233 "permit" means that the filter will allow any traffic that matches 234 the rule, while deny will not allow the traffic to be routed. The 235 filter rules can also use the keywords "AND" and "OR", for which no 236 additional explanation is necessary. The braces "(" and ")" can be 237 used to setup grouping of expressions. 239 2.2 Legacy RADIUS Attributes 241 The DIAMETER protocol reserves the first 255 AVP identifiers for 242 "legacy RADIUS" support, and SHOULD only used when a DIAMETER/RADIUS 243 gateway function is invoked. The following table contains the RADIUS 244 attributes supported by this DIAMETER extension, their AVP code 245 values, types, possible flag values and whether the AVP MAY be 246 encrypted. 248 +---------------------+ 249 | AVP Flag rules | 250 |----+-----+----+-----|----+ 251 AVP Section Value | | |SHLD| MUST|MAY | 252 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Encr| 253 -----------------------------------------|----+-----+----+-----|----+ 254 User-Password 2 3.1.1.1 Data | M | P | | V | Y | 255 CHAP-Password 3 3.1.1.2 Data | M | P | | V | Y | 256 NAS-IP-Address 4 2.2.1 Address | M | P | | V | Y | 257 NAS-Port 5 6.1.1 Integer32| M | P | | V | Y | 258 Service-Type 6 6.1.2 Integer32| M | P | | V | Y | 259 Framed-Protocol 7 6.2.1 Integer32| M | P | | V | Y | 260 Framed-IP-Address 8 6.2.2 Address | M | P | | V | Y | 261 Framed-IP-Netmask 9 6.2.3 Address | M | P | | V | Y | 262 Framed-Routing 10 6.2.4 Integer32| M | P | | V | Y | 263 Filter-Id 11 6.1.3 String | M | P | | V | Y | 264 Framed-MTU 12 6.2.5 Integer32| M | P | | V | Y | 265 Framed- 13 6.2.6 Integer32| M | P | | V | Y | 266 Compression | | | | | | 267 Login-IP-Host 14 6.3.1 Address | M | P | | V | Y | 268 Login-Service 15 6.3.2 Integer32| M | P | | V | Y | 269 Login-TCP-Port 16 6.3.3 Integer32| M | P | | V | Y | 270 Reply-Message 18 3.2 String | M | P | | V | Y | 271 Callback-Number 19 6.1.4 String | M | P | | V | Y | 272 Callback-Id 20 6.1.5 String | M | P | | V | Y | 273 Framed-IP-Route 22 6.2.7 String | M | P | | V | Y | 274 Framed-IPX-Route 23 6.2.8 String | M | P | | V | Y | 275 State 24 2.2.3 Data | M | P | | V | Y | 276 Class 25 2.2.4 Data | M | P | | V | Y | 277 Idle-Timeout 28 6.1.6 Integer32| M | P | | V | Y | 278 Called-Station-Id 30 6.1.7 String | M | P | | V | Y | 279 Calling-Station- 31 6.1.8 String | M | P | | V | Y | 280 Id | | | | | | 281 NAS-Identifier 32 2.2.2 String | M | P | | V | Y | 282 Login-LAT-Service 34 6.3.4 Integer32| M | P | | V | Y | 283 Login-LAT-Node 35 6.3.5 String | M | P | | V | Y | 284 Login-LAT-Group 36 6.3.6 Data | M | P | | V | Y | 285 Framed-Appletalk- 37 6.2.9 Integer32| M | P | | V | Y | 286 Link | | | | | | 287 Framed-Appletalk- 38 6.2.10 Integer32| M | P | | V | Y | 288 Network | | | | | | 289 Framed-Appletalk- 39 6.2.11 Data | M | P | | V | Y | 290 Zone | | | | | | 291 CHAP-Challenge 60 3.1.1.3 Data | M | P | | V | Y | 292 NAS-Port-Type 61 6.1.9 Integer32| M | P | | V | Y | 293 Port-Limit 62 6.1.10 Integer32| M | P | | V | Y | 294 Login-LAT-Port 63 6.3.7 String | M | P | | V | Y | 295 Tunnel-Type 64 6.4.1 Integer32| M | P | | V | Y | 296 Tunnel-Medium- 65 6.4.2 Integer32| M | P | | V | Y | 297 Type | | | | | | 298 Tunnel-Client- 66 6.4.3 String | M | P | | V | Y | 299 Endpoint | | | | | | 300 Tunnel-Server- 67 6.4.4 String | M | P | | V | Y | 301 Endpoint | | | | | | 302 Tunnel-Password 69 6.4.5 String | M | P | | V | Y | 303 Tunnel-Private- 81 6.4.6 String | M | P | | V | Y | 304 Group-ID | | | | | | 305 Tunnel- 82 6.4.7 String | M | P | | V | Y | 306 Assignment-Id | | | | | | 307 Tunnel-Preference 83 6.4.8 Integer32| M | P | | V | Y | 308 Tunnel-Client- 90 6.4.9 String | M | P | | V | Y | 309 Auth-ID | | | | | | 310 Tunnel-Server- 91 6.4.10 String | M | P | | V | Y | 311 Auth-ID | | | | | | 313 2.2.1 NAS-IP-Address AVP 315 The Host-IP-Address AVP (AVP Code 4) [1] is of type Address, and 316 contains the IP Address of the NAS providing service to the user. 317 When this AVP is present, the Host-Name AVP DOES NOT represent the 318 NAS providing service to the user. Note that this AVP SHOULD only 319 added by a RADIUS/DIAMETER protocol gateway [28]. 321 2.2.2 NAS-Identifier AVP 323 The NAS-Identifier AVP (AVP Code 32) [1] is of type String, and 324 contains the Identity of the NAS providing service to the user. When 325 this AVP is present, the Host-Name AVP DOES NOT represent the NAS 326 providing service to the user. Note that this AVP SHOULD only added 327 by a RADIUS/DIAMETER protocol gateway [28]. 329 2.2.3 State AVP 331 The State AVP (AVP Code 24) is used to transmit the contents of the 332 RADIUS State attribute, and no interpretation of the contents should 333 be made. Note that this AVP SHOULD only added by a RADIUS/DIAMETER 334 protocol gateway [28]. 336 2.2.4 Class AVP 338 The Class AVP (AVP Code 25) is used to transmit the contents of the 339 RADIUS Class attribute, and no interpretation of the contents should 340 be made. Note that this AVP SHOULD only added by a RADIUS/DIAMETER 341 protocol gateway [28]. 343 3.0 Legacy PPP Authentication Support 345 This section defines the new Command-Code [2] values required to 346 support the legacy PPP authentication protocol (PAP, CHAP), as well 347 as the AVPs that are necessary to carry the authentication 348 information in the DIAMETER protocol. The functionality defined here 349 provides a RADIUS-like AAA service, over a more reliable and secure 350 transport, as defined in the base protocol [2]. 352 Unlike the RADIUS protocol [1], the DIAMETER protocol does not 353 require authentication information to be contained in a request from 354 the client. Therefore, it is possible to send a request for 355 authorization only. The type of service depends upon the Request-Type 356 AVP. This difference MAY cause operational issues in environments 357 that need RADIUS interoperability, and it MAY be necessary that 358 protocol conversion gateways add some authentication information when 359 transmitting to a RADIUS server. 361 3.1 Command-Codes Values 363 This section defines new Command-Code [2] values that MUST be 364 supported by all DIAMETER implementations that conform to this 365 specification. The following Command Codes are defined in this 366 section: 368 Command-Name Abbrev. Code Reference 369 -------------------------------------------------------- 370 AA-Request AAR 265 3.1.1 371 AA-Answer AAA 266 3.1.2 372 AA-Challenge-Ind ACI 267 3.1.3 374 3.1.1 AA-Request (AAR) Command 376 The AA-Request message (AAR), indicated by the Command-Code field set 377 to 265, is used in order to request authentication and/or 378 authorization for a given PPP user. The type of request is identified 379 through the Request-Type AVP, and the default mode is both 380 authentication and authorization. 382 If Authentication is requested the User-Name attribute SHOULD be 383 present, as well as any additional authentication AVPs that would 384 carry the password information. A request for authorization only 385 SHOULD include the information from which the authorization will be 386 performed, such as the DNIS and ANI AVPs. Certain networks MAY use 387 different AVPs for authorization purposes. A request for 388 authorization will include some AVPs defined in sections 2.0 and 6.0. 390 It is possible for a single session to be authorized only first, then 391 followed by an authentication request. However, the inverse SHOULD 392 NOT be permitted. 394 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 395 MUST be identical as the one provided in the initial AA-Request for 396 the same session. If the AA-Request is a result of an AA-Challenge- 397 Ind that included a State AVP, the same AVP MUST be present in the 398 following AA-Request. 400 Message Format 401 ::= 402 403 404 [] 405 [] 406 [] 407 [] 408 [ || 409 && 410 ] 411 [] 412 [] 413 [ 414 415 ] 417 3.1.1.1 User-Password AVP 419 The User-Password AVP (AVP Code 2) is of type Data and contains the 420 password of the user to be authenticated, or the user's input 421 following an AA-Challenge-Ind. 423 This AVP MUST be encrypted using one of the methods described in [2] 424 or [13]. Unless this AVP is used for one-time passwords, the User- 425 Password AVP SHOULD NOT be used in non-trusted proxy environments. 427 The clear-text password (prior to encryption) MUST NOT be longer than 428 128 bytes in length. 430 3.1.1.2 CHAP-Password AVP 432 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 433 the response value provided by a PPP Challenge-Handshake 434 Authentication Protocol (CHAP) [6] user in response to the challenge. 436 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 437 AVP (see section 3.1.1.3) MUST be present as well. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 AVP Header (AVP Code = 3) 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | CHAP Ident | Data ... 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 The CHAP Ident field contains the one octet CHAP Identifier from the 448 user's CHAP response [6]. The Data field is 16 octets, and contains 449 the CHAP Response from the user. The actual computation of the CHAP 450 response can be found in [6]. 452 3.1.1.3 CHAP-Challenge AVP 454 The CHAP-Challenge AVP (AVP Code 60) is of type Data and contains the 455 CHAP Challenge sent by the NAS to a PPP Challenge-Handshake 456 Authentication Protocol (CHAP) [6] user. 458 3.1.2 AA-Answer (AAA) Command 460 The AA-Answer (AAA) message, indicated by the Command-Code field set 461 to 266, is sent in response to the AA-Request message. If 462 authorization was requested, a successful response will include the 463 authorization AVPs appropriate for the service being provided, as 464 defined in section 2.0 and 6.0. 466 Message Format 468 ::= 469 470 471 472 473 [] 474 [] 475 [ 476 477 ] 479 3.1.3 AA-Challenge-Ind (ACI) Command 481 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 482 field set to 267, is sent by a DIAMETER Home server to issue a 483 challenge requiring a response to a dial-up user. The message MAY 484 have one or more Reply-Message AVP, the User-Name AVP and it MAY have 485 zero or one State AVP. No other AVPs are permitted in an AA- 486 Challenge-Ind other than security related AVPs [2, 13]. 488 On receipt of an AA-Challenge-Ind, the Identifier field is matched 489 with a pending AA-Request. Invalid messages are silently discarded. 491 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 492 Request SHOULD be sent. The NAS MAY display the text message, if any, 493 to the user, and then prompt the user for a response. It then sends 494 its original AA-Request with a new request ID, with the User-Password 495 AVP replaced by the user's response (encrypted), and including the 496 State AVP from the AA-Challenge-Ind, if any. 498 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 499 client and accept a PAP response which it can use as though the user 500 had entered the response. If the NAS cannot do so, it should treat 501 the AA-Challenge-Ind as though it had received an AA-Answer with a 502 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 504 When possible, authentication mechanisms that include more than a 505 single authentication round trip SHOULD use EAP (see section 4.0) 506 instead of the AA-Challenge-Ind. This command has been maintained for 507 RADIUS backward compatibility. 509 AA-Challenge-Ind ::= 510 511 512 513 514 [] 515 [] 516 [] 517 [ 518 519 ] 521 3.2 Reply-Message AVP 523 The Reply-Message AVP (AVP Code 18) is of type String and contains 524 text which MAY be displayed to the user. When used in an AA-Answer 525 message with a successful Result-Code AVP it indicates the success 526 message. When found in the same message with a Result-Code other than 527 DIAMETER-SUCCESS it contains the failure message. 529 The Reply-Message AVP MAY indicate a dialog message to prompt the 530 user before another AA-Request attempt. When used in an AA- 531 Challenge-Ind, it MAY indicate a dialog message to prompt the user 532 for a response. 534 Multiple Reply-Message's MAY be included and if any are displayed, 535 they MUST be displayed in the same order as they appear in the 536 message. 538 4.0 Extensible Authentication Protocol Support 540 The Extensible Authentication Protocol (EAP), described in [25], 541 provides a standard mechanism for support of additional 542 authentication methods within PPP. Through the use of EAP, support 543 for a number of authentication schemes may be added, including smart 544 and token cards, Kerberos, Public Key, One Time Passwords, and 545 others. 547 This section describes the Command-Codes values and AVPs that are 548 required for an EAP payload to be encapsulated within the DIAMETER 549 protocol. Since authentication occurs between the PPP client and its 550 home DIAMETER server, end-to-end authentication is achieved, reducing 551 the possibility for fraudulent authentication, such as replay and 552 man-in-the-middle attacks. End-to-end authentication also provides 553 for mutual (bi-directional) authentication, which is not possible 554 with PAP and CHAP in a roaming environment. 556 The DIAMETER/EAP extension allows a home DIAMETER server to initiate 557 an unsolicited authentication request to the user. This allows the 558 home server to periodically ensure that the user is still active, 559 which is useful when a server requires re-authentication to extend 560 the "life" of a session [26]. Server-initiated authentication can 561 reduce the number of protocol exchanges over the Internet. 563 The EAP conversation between the authenticating peer and the NAS 564 begins with the negotiation of EAP within LCP. Once EAP has been 565 negotiated, the NAS will typically send to the DIAMETER server a 566 DIAMETER-EAP-Request message with a NULL EAP-Payload AVP, signifying 567 an EAP-Start. The Port number and NAS Identifier MUST be included in 568 the AVPs issued by the NAS in the DIAMETER-EAP-Request packet. 570 If the DIAMETER home server supports EAP, it MUST respond with a 571 DIAMETER-EAP-Ind message containing an EAP-Payload AVP that includes 572 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 573 NAS to the PPP client. The initial DIAMETER-EAP-Ind normally includes 574 an EAP-Request/Identity, requesting the PPP client to identify 575 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 576 will then issue a second DIAMETER-EAP-Request message, with the 577 client's EAP payload encapsulated within the EAP-Payload AVP. The 578 conversation continues until the DIAMETER server sends a DIAMETER- 579 EAP-Answer with a Result-Code AVP indicating success or failure. A 580 Result-Code AVP containing a failure indication SHOULD also include 581 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 582 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 583 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 584 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 585 successfully terminate the PPP authentication phase. If authorization 586 was requested, a successful DIAMETER-EAP-Answer MUST also include the 587 appropriate authorization AVPs required for the service requested 588 (see sections 2.0 and 6.0). 590 The above scenario creates a situation in which the NAS never needs 591 to manipulate an EAP packet. An alternative may be used in situations 592 where an EAP-Request/Identity message will always be sent by the NAS 593 to the authenticating peer. This involves having the NAS send an 594 EAP-Request/Identity message to the PPP client, and forwarding the 595 EAP-Response/Identity packet to the DIAMETER server in the EAP- 596 Payload AVP of a DIAMETER-EAP-Request packet. While this approach 597 will save a round-trip, it cannot be universally employed. There are 598 circumstances in which the user's identity may not be needed (such as 599 when authentication and accounting is handled based on the calling or 600 called phone number), and therefore an EAP-Request/Identity packet 601 may not necessarily be issued by the NAS to the authenticating peer. 603 Unless the NAS interprets the EAP-Response/Identity packet returned 604 by the authenticating peer, it will not have access to the user's 605 identity. Therefore, the DIAMETER Server SHOULD return the user's 606 identity by inserting it in the User-Name attribute of subsequent 607 DIAMETER-EAP-Answer packets. Without the user's identity, the 608 Session-Id AVP MAY be used for accounting and billing, however 609 operationally this MAY be very difficult to manage. 611 The DIAMETER-EAP-Ind message MAY be sent by a DIAMETER server in 612 order to initiate an unsolicited authentication of the PPP user, as 613 described in [26]. This functionality allows a home DIAMETER server 614 to easily extend the "life" of a session for a particular service, 615 while reducing the total number of authentication round-trips, should 616 the NAS initiate the periodic authentication. 618 Should an EAP authentication session be interrupted due to a home 619 server failure, the session MAY be directed to an alternate server, 620 but the authentication session will have to be restarted from the 621 beginning. 623 When DIAMETER is used in a roaming environment, the NAS SHOULD issue 624 the EAP-Request/Identity request to the PPP client, and forward the 625 EAP-Response in the initial DIAMETER-EAP-Request message. This allows 626 any DIAMETER proxies or brokers to identify the user, and forward the 627 message to the appropriate home server. If a response is received 628 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 629 an indication that a DIAMETER server in the proxy chain does not 630 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 631 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 632 cautious when determining whether a less secure authentication 633 protocol will be used, since this could be a result of a bidding down 634 attack. See [28] for additional information. 636 4.1 Alternative uses 638 Currently the conversation between the backend authentication server 639 and the DIAMETER server is proprietary because of lack of 640 standardization. In order to increase standardization and provide 641 interoperability between DIAMETER vendors and backend security 642 vendors, it is recommended that DIAMETER-encapsulated EAP be used for 643 this conversation. 645 This has the advantage of allowing the DIAMETER server to support EAP 646 without the need for authentication-specific code within the DIAMETER 647 server. Authentication-specific code can then reside on a backend 648 authentication server instead. 650 In the case where DIAMETER-encapsulated EAP is used in a conversation 651 between a DIAMETER server and a backend authentication server, the 652 latter will typically return an DIAMETER-EAP-Answer/EAP-Payload/EAP- 653 Success message without inclusion of the expected authorization AVPs 654 required in a successful response. This means that the DIAMETER 655 server MUST add these attributes prior to sending an DIAMETER-EAP- 656 Answer/EAP-Payload/EAP-Success message to the NAS. 658 4.2 Command-Codes Values 660 This section defines new Command-Code [2] values that MUST be 661 supported by all DIAMETER implementations conforming to this 662 specification. The following Command Codes are defined in this 663 section: 665 Command-Name Abbrev. Code Reference 666 -------------------------------------------------------- 667 DIAMETER-EAP-Request DER 268 4.2.1 668 DIAMETER-EAP-Answer DEA 269 4.2.2 669 DIAMETER-EAP-Ind DEI 270 4.2.3 670 DIAMETER-EAP-Terminate DET 275 4.2.4 672 4.2.1 DIAMETER-EAP-Request (DER) Command 674 The DIAMETER-EAP-Request (DER) command, indicated by the Command-Code 675 field set to 268, is sent by a DIAMETER client to a DIAMETER server 676 and conveys an EAP-Response [25] from the dial-up PPP client. The 677 DIAMETER-EAP-Request MUST contain one EAP-Payload AVP, which contains 678 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent 679 to the DIAMETER server to initiate an EAP authentication session. 681 Upon receipt of a DIAMETER-EAP-Request, a DIAMETER server MUST issue 682 a reply. The reply may be either: 684 1) a DIAMETER-EAP-Ind containing an EAP-Request encapsulated 685 within an EAP-Payload attribute 686 2) a DIAMETER-EAP-Answer containing an EAP-Success encapsulated 687 within an EAP-Payload and a Result-Code indicating success. 688 3) a DIAMETER-EAP-Answer containing an EAP-Failure encapsulated 689 within an EAP-Payload and a Result-Code indicating failure. 690 4) A Message-Reject-Ind packet with a Result-Code set to 691 DIAMETER_COMMAND_UNSUPPORTED if a DIAMETER server does not 692 support the EAP extension. 694 Message Format 696 ::= 697 698 [] 699 [] 700 [] 701 702 703 [ 704 705 ] 707 4.2.2 DIAMETER-EAP-Answer (DEA) Command 709 The DIAMETER-EAP-Answer (DEA) message, indicated by the Command-Code 710 field set to 269, is sent by the DIAMETER server to the client to 711 indicate either a successful or failed authentication. The DIAMETER- 712 EAP-Answer message SHOULD include an EAP payload of type EAP-Success 713 or EAP-Failure encapsulated within an EAP-Payload AVP. The Result- 714 Code AVP MUST indicate a failure if the EAP-Failure payload is 715 present, while the AVP MUST indicate success if the EAP-Success 716 payload is present. 718 If the message from the DIAMETER client included a request for 719 authorization, a successful response MUST include the authorization 720 AVPs that are relevant to the service being provided. 722 Message Format 724 ::= 725 726 727 728 [] 729 [] 730 [] 731 [ 732 733 ] 735 4.2.3 DIAMETER-EAP-Ind (DEI) Command 737 The DIAMETER-EAP-Ind (DEI) command, indicated by the Command-Code set 738 to 270, has two uses. This message MAY be sent in response to a 739 DIAMETER-EAP-Request message, and MUST contain an EAP-Response 740 payload [25] encapsulated within an EAP-Payload AVP. 742 Alternatively, this message MAY also be sent unsolicited from a 743 DIAMETER server to a client to request re-authentication of a PPP 744 client. For re-authentication, it is recommended that the Identity 745 request be skipped in order to reduce the number of authentication 746 round trips. This is only possible when the user's identity is 747 already known by the home DIAMETER server. 749 Upon receipt of the message, the NAS MUST issue the EAP payload to 750 the PPP Client, and SHOULD respond with a DIAMETER-EAP-Request 751 containing the EAP-Response [25] packet. 753 Message Format 755 ::= 756 757 758 759 760 [ 761 762 ] 764 4.3 EAP-Payload AVP 766 The EAP-Payload AVP (AVP Code 402) is of type Data and is used to 767 encapsulate the actual EAP payload [25] that is being exchanged 768 between the dial-up PPP client and the home DIAMETER server. 770 5.0 DIAMETER Session Termination 772 When a Network Access Server (NAS) receives an indication that a 773 user's session is being disconnected (e.g. LCP Terminate is 774 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 775 to its DIAMETER Server. This will ensure that any resources 776 maintained on the servers is freed appropriately. 778 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 779 disconnect the PPP (or tunneling) session and respond with an STR 780 message. 782 6.0 Legacy Authorization AVPs 784 This section contains the various authorization AVPs that are also 785 supported by the RADIUS protocol [1]. Use of these AVPs guarantees 786 interoperability with a RADIUS infrastructure. 788 6.1 Service Identification AVPs 790 This section contains the authorization AVPs that are needed to 791 identify a service, and to allow the server to set constraints on a 792 session. 794 6.1.1 NAS-Port AVP 796 The NAS-Port AVP (AVP Code 5) is of type Integer32 and contains the 797 physical port number of the NAS which is authenticating the user, and 798 is normally only present in an authentication and/or authorization 799 request. Note that this is using "port" in its sense of a physical 800 connection on the NAS, not in the sense of a TCP or UDP port number. 801 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 802 present in the request, if the NAS differentiates among its ports. 804 6.1.2 Service-Type AVP 806 The Service-Type AVP (AVP Code 6) is of type Integer32 and contains 807 the type of service the user has requested, or the type of service to 808 be provided. One such AVP MAY be present in an authentication and/or 809 authorization request or response. A NAS is not required to implement 810 all of these service types, and MUST treat unknown or unsupported 811 Service-Types as though a response with a Result-Code other than 812 DIAMETER-SUCCESS had been received instead. 814 When used in a request, the Service-Type AVP SHOULD be considered to 815 be a hint to the server that the NAS has reason to believe the user 816 would prefer the kind of service indicated, but the server is not 817 required to honor the hint. The following values have been defined 818 for the Service-Type AVP: 820 Login 1 821 The user should be connected to a host. 823 Framed 2 824 A Framed Protocol should be started for the User, such as PPP or 825 SLIP. 827 Callback Login 3 828 The user should be disconnected and called back, then connected to 829 a host. 831 Callback Framed 4 832 The user should be disconnected and called back, then a Framed 833 Protocol should be started for the User, such as PPP or SLIP. 835 Outbound 5 836 The user should be granted access to outgoing devices. 838 Administrative 6 839 The user should be granted access to the administrative interface 840 to the NAS from which privileged commands can be executed. 842 NAS Prompt 7 843 The user should be provided a command prompt on the NAS from which 844 non-privileged commands can be executed. 846 Authenticate Only 8 847 Only Authentication is requested, and no authorization information 848 needs to be returned in the response. 850 Callback NAS Prompt 9 851 The user should be disconnected and called back, then provided a 852 command prompt on the NAS from which non-privileged commands can 853 be executed. 855 6.1.3 Filter-Id AVP 857 The Filter-Id AVP (AVP Code 11) is of type String and contains the 858 name of the filter list for this user. Zero or more Filter-Id AVPs 859 MAY be sent in an authorization response. 861 Identifying a filter list by name allows the filter to be used on 862 different NASes without regard to filter-list implementation details. 863 However, this AVP is not roaming friendly since filter naming differs 864 from one service provider to another. 866 In non-RADIUS environments, it is strongly recommended that the 867 Filter-Rule AVP be used instead. 869 6.1.4 Callback-Number AVP 871 The Callback-Number AVP (AVP Code 19) is of type String and contains 872 a dialing string to be used for callback. It MAY be used in an 873 authentication and/or authorization request as a hint to the server 874 that a Callback service is desired, but the server is not required to 875 honor the hint in the corresponding response. 877 The codification of the range of allowed usage of this field is 878 outside the scope of this specification. 880 6.1.5 Callback-Id AVP 882 The Callback-Id AVP (AVP Code 20) is of type String and contains the 883 name of a place to be called, to be interpreted by the NAS. This AVP 884 MAY be present in an authentication and/or authorization response. 886 This AVP is not roaming friendly since it assumes that the Callback- 887 Id is configured on the NAS. It is therefore preferable to use the 888 Callback-Number AVP instead. 890 6.1.6 Idle-Timeout AVP 892 The Idle-Timeout AVP (AVP Code 28) is of type Integer32 and sets the 893 maximum number of consecutive seconds of idle connection allowed to 894 the user before termination of the session or prompt. It MAY be used 895 in an authentication and/or authorization request (or challenge) as a 896 hint to the server that an idle timeout is desired, but the server is 897 not required to honor the hint in the corresponding response. 899 6.1.7 Called-Station-Id AVP 901 The Called-Station-Id AVP (AVP Code 30) is of type String and allows 902 the NAS to send in the request the phone number that the user called, 903 using Dialed Number Identification (DNIS) or a similar technology. 904 Note that this may be different from the phone number the call comes 905 in on. It SHOULD only be present in authentication and/or 906 authorization requests. 908 If the Request-Type AVP is set to authorization-only and the User- 909 Name AVP is absent, the DIAMETER Server MAY perform authorization 910 based on this field. This can be used by a NAS to request whether a 911 call should be answered based on the DNIS. 913 The codification of the range of allowed usage of this field is 914 outside the scope of this specification. 916 6.1.8 Calling-Station-Id AVP 918 The Calling-Station-Id AVP (AVP Code 31) is of type String and allows 919 the NAS to send in the request the phone number that the call came 920 from, using Automatic Number Identification (ANI) or a similar 921 technology. It SHOULD only be present in authentication and/or 922 authorization requests. 924 If the Request-Type AVP is set to authorization-only and the User- 925 Name AVP is absent, the DIAMETER Server MAY perform authorization 926 based on this field. This can be used by a NAS to request whether a 927 call should be answered based on the ANI. 929 The codification of the range of allowed usage of this field is 930 outside the scope of this specification. 932 6.1.9 NAS-Port-Type AVP 934 The NAS-Port-Type AVP (AVP Code 61) is of type Integer32 and contains 935 the type of the physical port of the NAS which is authenticating the 936 user. It can be used instead of or in addition to the NAS-Port (5) 937 AVP. This AVP SHOULD only be used in authentication and/or 938 authorization requests. This AVP MAY be combined with the NAS-Port 939 AVP to assist in differentiating its ports. 941 The following values are defined: 942 0 Async 943 1 Sync 944 2 ISDN Sync 945 3 ISDN Async V.120 946 4 ISDN Async V.110 947 5 Virtual 948 6 PIAFS 949 7 HDLC Clear Channel 950 8 X.25 951 9 X.75 952 10 G.3 Fax 953 11 SDSL - Symmetric DSL 954 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 955 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 956 14 IDSL - ISDN Digital Subscriber Line 957 15 Ethernet 958 16 xDSL 959 17 Cable 960 18 Wireless - Other 961 19 Wireless - IEEE 802.11 963 "Virtual" refers to a connection to the NAS via some transport 964 protocol, instead of through a physical port. For example, if a user 965 telnetted into a NAS to authenticate himself as an Outbound-User, the 966 request might include NAS-Port-Type = Virtual as a hint to the 967 DIAMETER server that the user was not on a physical port. 969 6.1.10 Port-Limit AVP 971 The Port-Limit AVP (AVP Code 62) is of type Integer32 and sets the 972 maximum number of ports to be provided to the user by the NAS. It 973 MAY be used in an authentication and/or authorization request as a 974 hint to the server that multilink PPP [9] service is desired, but the 975 server is not required to honor the hint in the corresponding 976 response. 978 6.2 Framed Access Authorization AVPs 980 This section contains the authorization AVPs that are necessary to 981 support framed access, such as PPP, SLIP, etc. 983 6.2.1 Framed-Protocol AVP 985 The Framed-Protocol AVP (AVP Code 7) is of type Integer32 and 986 contains the framing to be used for framed access. This AVP MAY be 987 present in both requests and responses. The following values are 988 currently supported: 990 1 PPP 991 2 SLIP 992 3 AppleTalk Remote Access Protocol (ARAP) 993 4 Gandalf proprietary SingleLink/MultiLink protocol 994 5 Xylogics proprietary IPX/SLIP 995 6 X.75 Synchronous 997 6.2.2 Framed-IP-Address AVP 999 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1000 contains the address to be configured for the user. It MAY be used in 1001 an authorization request as a hint to the server that a specific 1002 address is desired, but the server is not required to honor the hint 1003 in the corresponding response. 1005 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1006 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1007 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1008 that the NAS should select an address for the user (e.g. Assigned 1009 from a pool of addresses kept by the NAS). 1011 6.2.3 Framed-IP-Netmask AVP 1013 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1014 contains the IP netmask to be configured for the user when the user 1015 is a router to a network. It MAY be used in an authorization request 1016 as a hint to the server that a specific netmask is desired, but the 1017 server is not required to honor the hint in the corresponding 1018 response. This AVP MUST be present in a response if the request 1019 included this AVP with a value of 0xFFFFFFFF. 1021 6.2.4 Framed-Routing AVP 1023 The Framed-Routing AVP (AVP Code 10) is of type Integer32 and 1024 contains the routing method for the user, when the user is a router 1025 to a network. This AVP SHOULD only be present in authorization 1026 responses. The following values are defined for this AVP: 1028 0 None 1029 1 Send routing packets 1030 2 Listen for routing packets 1031 3 Send and Listen 1033 6.2.5 Framed-MTU AVP 1035 The Framed-MTU AVP (AVP Code 12) is of type Integer32 and contains 1036 the Maximum Transmission Unit to be configured for the user, when it 1037 is not negotiated by some other means (such as PPP). This AVP SHOULD 1038 only be present in authorization responses. The MTU value MUST be 1039 between the range of 64 and 65535. 1041 6.2.6 Framed-Compression AVP 1043 The Framed-Compression AVP (AVP Code 13) is of type Integer32 and 1044 contains the compression protocol to be used for the link. It MAY be 1045 used in an authorization request as a hint to the server that a 1046 specific compression type is desired, but the server is not required 1047 to honor the hint in the corresponding response. 1049 More than one compression protocol AVP MAY be sent. It is the 1050 responsibility of the NAS to apply the proper compression protocol to 1051 appropriate link traffic. 1053 The following values are defined: 1054 0 None 1055 1 VJ TCP/IP header compression [7] 1056 2 IPX header compression 1057 3 Stac-LZS compression 1059 6.2.7 Framed-IP-Route AVP 1061 The Framed-IP-Route AVP (AVP Code 22) is of type String and contains 1062 the routing information to be configured for the user on the NAS. 1063 Zero or more such AVPs MAY be present in an authorization response. 1065 The string MUST contain a destination prefix in dotted quad form 1066 optionally followed by a slash and a decimal length specifier stating 1067 how many high order bits of the prefix should be used. That is 1068 followed by a space, a gateway address in dotted quad form, a space, 1069 and one or more metrics separated by spaces. For example, 1070 "192.168.1.0/24 192.168.1.1 1". 1072 The length specifier may be omitted in which case it should default 1073 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1074 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1076 Whenever the gateway address is specified as "0.0.0.0" the IP address 1077 of the user SHOULD be used as the gateway address. 1079 6.2.8 Framed-IPX-Network AVP 1081 The Framed-IPX-Network AVP (AVP Code 23) is of type String and 1082 contains the IPX Network number to be configured for the user. It MAY 1083 be used in an authorization request as a hint to the server that a 1084 specific address is desired, but the server is not required to honor 1085 the hint in the corresponding response. 1087 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1088 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1089 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1090 that the NAS should select an address for the user (e.g. assigned 1091 from a pool of one or more IPX networks kept by the NAS). 1093 6.2.9 Framed-AppleTalk-Link AVP 1095 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Integer32 and 1096 contains the AppleTalk network number which should be used for the 1097 serial link to the user, which is another AppleTalk router. This AVP 1098 MUST only be present in an authorization response and is never used 1099 when the user is not another router. 1101 Despite the size of the field, values range from zero to 65535. The 1102 special value of zero indicates that this is an unnumbered serial 1103 link. A value of one to 65535 means that the serial line between the 1104 NAS and the user should be assigned that value as an AppleTalk 1105 network number. 1107 6.2.10 Framed-AppleTalk-Network AVP 1109 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Integer32 1110 and contains the AppleTalk Network number which the NAS should probe 1111 to allocate an AppleTalk node for the user. This AVP MUST only be 1112 present in an authorization response and is never used when the user 1113 is not another router. Multiple instances of this AVP indicate that 1114 the NAS may probe using any of the network numbers specified. 1116 Despite the size of the field, values range from zero to 65535. The 1117 special value zero indicates that the NAS should assign a network for 1118 the user, using its default cable range. A value between one and 1119 65535 (inclusive) indicates the AppleTalk Network the NAS should 1120 probe to find an address for the user. 1122 6.2.11 Framed-AppleTalk-Zone AVP 1124 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type Data and 1125 contains the AppleTalk Default Zone to be used for this user. This 1126 AVP MUST only be present in an authorization response. Multiple 1127 instances of this AVP in the same message are not allowed. 1129 The codification of the range of allowed usage of this field is 1130 outside the scope of this specification. 1132 6.3 Non-Framed Access Authorization AVPs 1134 This section contains the authorization AVPs that are needed to 1135 support terminal server functionality. 1137 6.3.1 Login-IP-Host AVP 1139 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1140 the system with which to connect the user, when the Login-Service AVP 1141 is included. It MAY be used in an authorization request as a hint to 1142 the server that a specific host is desired, but the server is not 1143 required to honor the hint in the corresponding response. 1145 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1146 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1147 select an address. The value zero indicates that the NAS SHOULD 1148 select a host to connect the user to. 1150 6.3.2 Login-Service AVP 1152 The Login-Service AVP (AVP Code 15) is of type Integer32 and contains 1153 the service which should be used to connect the user to the login 1154 host. This AVP SHOULD only be present in authorization responses. 1156 The following values are defined: 1157 0 Telnet 1158 1 Rlogin 1159 2 TCP Clear 1160 3 PortMaster (proprietary) 1161 4 LAT 1162 5 X25-PAD 1163 6 X25-T3POS 1164 8 TCP Clear Quiet (supresses any NAS-generated connect string) 1166 6.3.3 Login-TCP-Port AVP 1168 The Login-TCP-Port AVP (AVP Code 16) is of type Integer32 and 1169 contains the TCP port with which the user is to be connected, when 1170 the Login-Service AVP is also present. This AVP SHOULD only be 1171 present in authorization responses. The value MUST NOT be greater 1172 than 65535. 1174 6.3.4 Login-LAT-Service AVP 1176 The Login-LAT-Service AVP (AVP Code 34) is of type String and 1177 contains the system with which the user is to be connected by LAT. It 1178 MAY be used in an authorization request as a hint to the server that 1179 a specific service is desired, but the server is not required to 1180 honor the hint in the corresponding response. This AVP MUST only be 1181 present in the response if the Login-Service AVP states that LAT is 1182 desired. 1184 Administrators use the service attribute when dealing with clustered 1185 systems, such as a VAX or Alpha cluster. In such an environment 1186 several different time sharing hosts share the same resources (disks, 1187 printers, etc.), and administrators often configure each to offer 1188 access (service) to each of the shared resources. In this case, each 1189 host in the cluster advertises its services through LAT broadcasts. 1191 Sophisticated users often know which service providers (machines) are 1192 faster and tend to use a node name when initiating a LAT connection. 1193 Alternately, some administrators want particular users to use certain 1194 machines as a primitive form of load balancing (although LAT knows 1195 how to do load balancing itself). 1197 The String field contains the identity of the LAT service to use. 1198 The LAT Architecture allows this string to contain $ (dollar), - 1199 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1200 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1201 string comparisons are case insensitive. 1203 6.3.5 Login-LAT-Node AVP 1205 The Login-LAT-Node AVP (AVP Code 35) is of type String and contains 1206 the Node with which the user is to be automatically connected by LAT. 1207 It MAY be used in an authorization request as a hint to the server 1208 that a specific LAT node is desired, but the server is not required 1209 to honor the hint in the corresponding response. This AVP MUST only 1210 be present in a response if the Service-Type AVP is set to LAT. 1212 The String field contains the identity of the LAT service to use. 1213 The LAT Architecture allows this string to contain $ (dollar), - 1214 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1215 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1216 string comparisons are case insensitive. 1218 6.3.6 Login-LAT-Group AVP 1219 The Login-LAT-Group AVP (AVP Code 36) is of type Data and contains a 1220 string identifying the LAT group codes which this user is authorized 1221 to use. It MAY be used in an authorization request as a hint to the 1222 server that a specific group is desired, but the server is not 1223 required to honor the hint in the corresponding response. This AVP 1224 MUST only be present in a response if the Service-Type AVP is set to 1225 LAT. 1227 LAT supports 256 different group codes, which LAT uses as a form of 1228 access rights. LAT encodes the group codes as a 256 bit bitmap. 1230 Administrators can assign one or more of the group code bits at the 1231 LAT service provider; it will only accept LAT connections that have 1232 these group codes set in the bit map. The administrators assign a 1233 bitmap of authorized group codes to each user; LAT gets these from 1234 the operating system, and uses these in its requests to the service 1235 providers. 1237 The codification of the range of allowed usage of this field is 1238 outside the scope of this specification. 1240 6.3.7 Login-LAT-Port AVP 1242 The Login-LAT-Port AVP (AVP Code 63) is of type String and contains 1243 the Port with which the user is to be connected by LAT. It MAY be 1244 used in an authorization request as a hint to the server that a 1245 specific port is desired, but the server is not required to honor the 1246 hint in the corresponding response. This AVP MUST only be present in 1247 a response if the Service-Type AVP is set to LAT. 1249 The String field contains the identity of the LAT service to use. 1250 The LAT Architecture allows this string to contain $ (dollar), - 1251 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1252 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1253 string comparisons are case insensitive. 1255 6.4 Tunneling AVPs 1257 This section contains the authorization AVPs that are needed for a 1258 NAS to support tunneling users. 1260 6.4.1 Tunnel-Type AVP 1262 The Tunnel-Type AVP (AVP Code 64) is of type Integer32 and contains 1263 the tunneling protocol(s) to be used (in the case of a tunnel 1264 initiator) or the the tunneling protocol in use (in the case of a 1265 tunnel terminator). It MAY be used in an authorization request as a 1266 hint to the server that a specific tunnel type is desired, but the 1267 server is not required to honor the hint in the corresponding 1268 response. 1270 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1271 Record within the Accounting-Request. 1273 A tunnel initiator is not required to implement any of these tunnel 1274 types; if a tunnel initiator receives a response that contains only 1275 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1276 as though a response was received with the Result-Code indicating a 1277 failure. 1279 The following values have been defined: 1280 1 Point-to-Point Tunneling Protocol (PPTP) [14] 1281 2 Layer Two Forwarding (L2F) [15] 1282 3 Layer Two Tunneling Protocol (L2TP) [16] 1283 4 Ascend Tunnel Management Protocol (ATMP) [17] 1284 5 Virtual Tunneling Protocol (VTP) 1285 6 IP Authentication Header in the Tunnel-mode (AH) [18] 1286 7 IP-in-IP Encapsulation (IP-IP) [19] 1287 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 1288 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [21] 1289 10 Generic Route Encapsulation (GRE) [22] 1290 11 Bay Dial Virtual Services (DVS) 1291 12 IP-in-IP Tunneling [23] 1293 6.4.2 Tunnel-Medium-Type AVP 1295 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Integer32 and 1296 contains the transport medium to use when creating a tunnel for those 1297 protocols (such as L2TP) that can operate over multiple transports. 1298 It MAY be used in an authorization request as a hint to the server 1299 that a specific medium is desired, but the server is not required to 1300 honor the hint in the corresponding response. 1302 The Value field is three octets and contains one of the values listed 1303 under "Address Family Numbers" in [10]. The value of most importance 1304 is (1) for IPv4 and (2) for IPv6. 1306 6.4.3 Tunnel-Client-Endpoint AVP 1308 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type String and 1309 contains the address of the initiator end of the tunnel. It MAY be 1310 used in an authorization request as a hint to the server that a 1311 specific endpoint is desired, but the server is not required to honor 1312 the hint in the corresponding response. 1314 This AVP SHOULD be included in the ADIF Record of the corresponding 1315 Accounting-Request messages, in which case it indicates the address 1316 from which the tunnel was initiated. This AVP, along with the 1317 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1318 a globally unique means to identify a tunnel for accounting and 1319 auditing purposes. 1321 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1322 fully qualified domain name (FQDN) of the tunnel client machine, or 1323 it is a "dotted-decimal" IP address. Conformant implementations MUST 1324 support the dotted-decimal format and SHOULD support the FQDN format 1325 for IP addresses. 1327 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1328 FQDN of the tunnel client machine, or it is a text representation of 1329 the address in either the preferred or alternate form [5]. 1330 Conformant implementations MUST support the preferred form and SHOULD 1331 support both the alternate text form and the FQDN format for IPv6 1332 addresses. 1334 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1335 referring to configuration data local to the DIAMETER client that 1336 describes the interface and medium-specific address to use. 1338 6.4.4 Tunnel-Server-Endpoint AVP 1340 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of String and 1341 contains the address of the server end of the tunnel. It MAY be used 1342 in an authorization request as a hint to the server that a specific 1343 endpoint is desired, but the server is not required to honor the hint 1344 in the corresponding response. 1346 This AVP SHOULD be included in the ADIF Record of the corresponding 1347 Accounting-Request messages, in which case it indicates the address 1348 from which the tunnel was initiated. This AVP, along with the 1349 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1350 a globally unique means to identify a tunnel for accounting and 1351 auditing purposes. 1353 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1354 fully qualified domain name (FQDN) of the tunnel client machine, or 1355 it is a "dotted-decimal" IP address. Conformant implementations MUST 1356 support the dotted-decimal format and SHOULD support the FQDN format 1357 for IP addresses. 1359 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1360 FQDN of the tunnel client machine, or it is a text representation of 1361 the address in either the preferred or alternate form [5]. 1362 Conformant implementations MUST support the preferred form and SHOULD 1363 support both the alternate text form and the FQDN format for IPv6 1364 addresses. 1366 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1367 referring to configuration data local to the DIAMETER client that 1368 describes the interface and medium-specific address to use. 1370 6.4.5 Tunnel-Password AVP 1372 The Tunnel-Password AVP (AVP Code 69) is of type Data and may contain 1373 a password to be used to authenticate to a remote server. This AVP 1374 MUST only be present in authorization responses in an encrypted form, 1375 using one of the methods described in [2] and [13]. 1377 6.4.6 Tunnel-Private-Group-ID AVP 1379 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type String and 1380 contains the group ID for a particular tunneled session. The Tunnel- 1381 Private-Group-ID AVP MAY be included in an authorization request if 1382 the tunnel initiator can pre-determine the group resulting from a 1383 particular connection and SHOULD be included in the authorization 1384 response if this tunnel session is to be treated as belonging to a 1385 particular private group. Private groups may be used to associate a 1386 tunneled session with a particular group of users. For example, it 1387 MAY be used to facilitate routing of unregistered IP addresses 1388 through a particular interface. This value SHOULD be included the 1389 corresponding ADIF-Record in the Accounting-Request which pertain to 1390 a tunneled session. 1392 6.4.7 Tunnel-Assignment-ID AVP 1394 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type String and is 1395 used to indicate to the tunnel initiator the particular tunnel to 1396 which a session is to be assigned. Some tunneling protocols, such as 1397 PPTP and L2TP, allow for sessions between the same two tunnel 1398 endpoints to be multiplexed over the same tunnel and also for a given 1399 session to utilize its own dedicated tunnel. This attribute provides 1400 a mechanism for DIAMETER to be used to inform the tunnel initiator 1401 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1402 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1403 sharing multiplexed tunnels to be assigned to different multiplexed 1404 tunnels. 1406 A particular tunneling implementation may assign differing 1407 characteristics to particular tunnels. For example, different 1408 tunnels may be assigned different QOS parameters. Such tunnels may 1409 be used to carry either individual or multiple sessions. The 1410 Tunnel-Assignment-ID attribute thus allows the DIAMETER server to 1411 indicate that a particular session is to be assigned to a tunnel that 1412 provides an appropriate level of service. It is expected that any 1413 QOS-related DIAMETER tunneling attributes defined in the future that 1414 accompany this attribute will be associated by the tunnel initiator 1415 with the ID given by this attribute. In the meantime, any semantic 1416 given to a particular ID string is a matter left to local 1417 configuration in the tunnel initiator. 1419 The Tunnel-Assignment-ID AVP is of significance only to DIAMETER and 1420 the tunnel initiator. The ID it specifies is intended to be of only 1421 local use to DIAMETER and the tunnel initiator. The ID assigned by 1422 the tunnel initiator is not conveyed to the tunnel peer. 1424 This attribute MAY be included in authorization responses. The tunnel 1425 initiator receiving this attribute MAY choose to ignore it and assign 1426 the session to an arbitrary multiplexed or non-multiplexed tunnel 1427 between the desired endpoints. This attribute SHOULD also be 1428 included in the corresponding ADIF-Record in the Accounting-Request 1429 messages which pertain to a tunneled session. 1431 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1432 should assign a session to a tunnel in the following manner: 1434 - If this AVP is present and a tunnel exists between the specified 1435 endpoints with the specified ID, then the session should be 1436 assigned to that tunnel. 1438 - If this AVP is present and no tunnel exists between the 1439 specified endpoints with the specified ID, then a new tunnel 1440 should be established for the session and the specified ID 1441 should be associated with the new tunnel. 1443 - If this AVP is not present, then the session is assigned to an 1444 unnamed tunnel. If an unnamed tunnel does not yet exist between 1445 the specified endpoints then it is established and used for this 1446 and subsequent sessions established without the Tunnel- 1447 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1448 session for which a Tunnel-Assignment-ID AVP was not specified 1449 to a named tunnel (i.e. one that was initiated by a session 1450 specifying this AVP). 1452 Note that the same ID may be used to name different tunnels if such 1453 tunnels are between different endpoints. 1455 6.4.8 Tunnel-Preference AVP 1457 The Tunnel-Preference AVP (AVP Code 83) is of type Integer32 and is 1458 used to identify the relative preference assigned to each tunnel when 1459 more than one set of tunneling AVPs is returned within separete 1460 Grouped-AVP AVPs. It MAY be used in an authorization request as a 1461 hint to the server that a specific preference is desired, but the 1462 server is not required to honor the hint in the corresponding 1463 response. 1465 For example, suppose that AVPs describing two tunnels are returned by 1466 the server, one with a Tunnel-Type of PPTP and the other with a 1467 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1468 the Tunnel-Types returned, it will initiate a tunnel of that type. 1469 If, however, it supports both tunnel protocols, it SHOULD use the 1470 value of the Tunnel-Preference AVP to decide which tunnel should be 1471 started. The tunnel having the numerically lowest value in the Value 1472 field of this AVP SHOULD be given the highest preference. The values 1473 assigned to two or more instances of the Tunnel-Preference AVP within 1474 a given authorization response MAY be identical. In this case, the 1475 tunnel initiator SHOULD use locally configured metrics to decide 1476 which set of AVPs to use. 1478 6.4.9 Tunnel-Client-Auth-ID AVP 1480 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type String and 1481 specifies the name used by the tunnel initiator during the 1482 authentication phase of tunnel establishment. It MAY be used in an 1483 authorization request as a hint to the server that a specific 1484 preference is desired, but the server is not required to honor the 1485 hint in the corresponding response. This AVP MUST be present in the 1486 authorization response if an authentication name other than the 1487 default is desired. This AVP SHOULD be included in the corresponding 1488 ADIF-Record of the Accounting-Request messages which pertain to a 1489 tunneled session. 1491 6.4.10 Tunnel-Server-Auth-ID AVP 1493 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type String and 1494 specifies the name used by the tunnel terminator during the 1495 authentication phase of tunnel establishment. It MAY be used in an 1496 authorization request as a hint to the server that a specific 1497 preference is desired, but the server is not required to honor the 1498 hint in the corresponding response. This AVP MUST be present in the 1499 authorization response if an authentication name other than the 1500 default is desired. This AVP SHOULD be included in the corresponding 1501 ADIF-Record of the Accounting-Request messages which pertain to a 1502 tunneled session. 1504 7.0 Interactions with Resource Management 1506 The Resource Management extension [31] provides the ability for a 1507 DIAMETER node to query a peer for session state information. The 1508 document states that service-specific extensions are responsible for 1509 specifying what AVPs are to be present in the Resource-Token [31] 1510 AVP. 1512 In addition to the AVPs listed in [31], the Resource-Token with the 1513 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1514 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1515 IPX-Network MUST be present if the corresponding network is being 1516 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1517 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1518 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1519 AVPs MUST be present. 1521 8.0 IANA Considerations 1523 The command codes defined in Sections 3.1 and 4.2 are values taken 1524 from the Command-Code [2] address space and extended in [13], [29] 1525 and [30]. IANA should record the values as defined in Sections 2.1 1526 and 4.2. 1528 The AVPs defined in section 2.1 were alllocated from from the AVP 1529 numbering space defined in [2], and extended in [13], [29] and [30]. 1530 IANA should record the values as defined in Sections 2.1. 1532 The DIAMETER base protocol [2] reserves the first 255 AVPs for legacy 1533 RADIUS support [1]. The AVPs defined in section 2.2 are defined in 1534 [1], and no number assignment is necessary. 1536 8.1 Request-Type AVP Values 1538 The Request-Type AVP (section 2.1.1) has a set of values that MUST be 1539 maintained by IANA. Values 1 through 3 are defined in this document. 1541 The remaining values are available for assignment via Designated 1542 Expert [27]. 1544 9.0 Security Considerations 1546 This document does not contain any security protocol, but does 1547 discuss how PPP authentication protocols can be carried within the 1548 DIAMETER protocol. The PPP authentication protocols that are 1549 described are PAP, CHAP and EAP. 1551 The use of PAP SHOULD be discouraged, since it exposes user's 1552 passwords to possibly non-trusted entities. PAP is also frequently 1553 used for use with One-Time Passwords (OTP), which does not expose any 1554 security risks. However, it is highly recommended that OTP be 1555 supported through the EAP protocol. 1557 This document also describes how CHAP can be carried within the 1558 DIAMETER protocol, which is required for backward RADIUS 1559 compatibility. The CHAP protocol, as used in a RADIUS environment, 1560 facilitates authentication replay attacks, and therefore SHOULD NOT 1561 be used when EAP is available. 1563 10.0 References 1565 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1567 [2] Calhoun, Rubens, Akhtar, Guttman, "DIAMETER Base Protocol", 1568 draft-calhoun-diameter-17.txt, IETF work in progress, September 1569 2000. 1571 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 1572 ary 1999. 1574 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 1575 2477, January 1999. 1577 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 1578 RFC 2373, July 1998 1580 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 1581 (CHAP)", RFC 1994, August 1996. 1583 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 1584 links", RFC 1144, February 1990. 1586 [8] ISO 8859. International Standard -- Information Processing -- 1587 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 1588 Alphabet No. 1, ISO 8859-1:1987. 1589 1591 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 1592 (MP)", RFC 1717, November 1994. 1594 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 1595 October 1994 1597 [11] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1598 calhoun-diameter-framework-07.txt, IETF work in progress, April 1599 2000. 1601 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1602 Levels", BCP 14, RFC 2119, March 1997. 1604 [13] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1605 Extension", draft-calhoun-diameter-strong-crypto-05.txt, IETF 1606 work in progress, September 2000. 1608 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 1609 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 1610 July 1999 1612 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 1613 warding (Protocol) 'L2F'", RFC 2341, May 1998 1615 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 1616 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 1617 August 1999 1619 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 1620 2107, February 1997 1622 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 1623 Protocol", RFC 2401, November 1998 1625 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1626 1996 1628 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1629 October 1996 1631 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1632 1827, August 1995 1634 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 1635 Encapsulation (GRE)", RFC 1701, October 1994 1637 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 1639 [24] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 1640 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 1641 in progress, June 2000. 1643 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 1644 Protocol (EAP)." RFC 2284, March 1998. 1646 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 1647 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 1648 1999. 1650 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 1651 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1653 [28] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1654 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1655 diameter-impl-guide-03.txt, IETF work in progress, June 2000. 1657 [29] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 1658 Extension", draft-calhoun-diameter-accounting-08.txt, IETF work 1659 in progress, September 2000. 1661 [30] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1662 calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- 1663 tember 2000. 1665 [31] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1666 calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep- 1667 tember 2000. 1669 11.0 Acknowledgements 1671 The authors would also like to acknowledge the following people for 1672 their contribution in the development of the DIAMETER protocol: 1674 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1675 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1676 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 1677 R. Vollbrecht, Jeff Weisberg and Glen Zorn 1679 12.0 Authors' Addresses 1680 Questions about this memo can be directed to: 1682 Pat R. Calhoun 1683 Network and Security Research Center, Sun Labs 1684 Sun Microsystems, Inc. 1685 15 Network Circle 1686 Menlo Park, California, 94025 1687 USA 1689 Phone: +1 650-786-7733 1690 Fax: +1 650-786-6445 1691 E-mail: pcalhoun@eng.sun.com 1693 William Bulley 1694 Merit Network, Inc. 1695 Building One, Suite 2000 1696 4251 Plymouth Road 1697 Ann Arbor, Michigan 48105-2785 1698 USA 1700 Phone: +1 734-764-9993 1701 Fax: +1 734-647-3185 1702 E-mail: web@merit.edu 1704 Allan C. Rubens 1705 Tut Systems, Inc. 1706 220 E. Huron, Suite 260 1707 Ann Arbor, MI 48104 1708 USA 1710 Phone: +1 734-995-1697 1711 E-Mail: arubens@tutsys.com 1713 Jeff Haag 1714 Cisco Systems 1715 7025 Kit Creek Road 1716 PO Box 14987 1717 Research Triangle Park, NC 27709 1719 Phone: 1-919-392-2353 1720 E-Mail: haag@cisco.com 1722 13.0 Full Copyright Statement 1723 Copyright (C) The Internet Society (1999). All Rights Reserved. 1725 This document and translations of it may be copied and furnished to 1726 others, and derivative works that comment on or otherwise explain it 1727 or assist in its implementation may be prepared, copied, published and 1728 distributed, in whole or in part, without restriction of any kind, 1729 provided that the above copyright notice and this paragraph are 1730 included on all such copies and derivative works. However, this 1731 document itself may not be modified in any way, such as by removing the 1732 copyright notice or references to the Internet Society or other Internet 1733 organizations, except as needed for the purpose of developing 1734 Internet standards in which case the procedures for copyrights defined 1735 in the Internet Standards process must be followed, or as required to 1736 translate it into languages other than English. The limited permissions 1737 granted above are perpetual and will not be revoked by the 1738 Internet Society or its successors or assigns. This document and the 1739 information contained herein is provided on an "AS IS" basis and THE 1740 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1741 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1742 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1743 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1744 PARTICULAR PURPOSE.