idnits 2.17.1 draft-calhoun-diameter-nasreq-03.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 1572, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1598, 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-14 -- 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-03 -- 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-04 ** 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-02 -- Possible downref: Normative reference to a draft: ref. '28' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-05 -- Possible downref: Normative reference to a draft: ref. '29' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-07 -- Possible downref: Normative reference to a draft: ref. '30' == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-03 -- 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-03.txt William Bulley 5 Date: April 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 AVP 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 AVP 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 | | T,V | Y | 198 Request-Type 401 2.1.1 Integer32| M | P | | T,V | N | 199 EAP-Payload 402 4.2 Data | M | P | | T,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 | | T,V | Y | 255 CHAP-Password 3 3.1.1.2 Data | M | P | | T,V | Y | 256 NAS-Identifier 4 2.2.1 Address | M | P | | T,V | Y | 257 NAS-Port 5 6.1.1 Integer32| M | P | | T,V | Y | 258 Service-Type 6 6.1.2 Integer32| M | P | | T,V | Y | 259 Framed-Protocol 7 6.2.1 Integer32| M | P | | T,V | Y | 260 Framed-IP-Address 8 6.2.2 Address | M | P | | T,V | Y | 261 Framed-IP-Netmask 9 6.2.3 Address | M | P | | T,V | Y | 262 Framed-Routing 10 6.2.4 Integer32| M | P | | T,V | Y | 263 Filter-Id 11 6.1.3 String | M | P | | T,V | Y | 264 Framed-MTU 12 6.2.5 Integer32| M | P | | T,V | Y | 265 Framed- 13 6.2.6 Integer32| M | P | | T,V | Y | 266 Compression | | | | | | 267 Login-IP-Host 14 6.3.1 Address | M | P | | T,V | Y | 268 Login-Service 15 6.3.2 Integer32| M | P | | T,V | Y | 269 Login-TCP-Port 16 6.3.3 Integer32| M | P | | T,V | Y | 270 Reply-Message 18 3.2 String | M | P | | T,V | Y | 271 Callback-Number 19 6.1.4 String | M | P | | T,V | Y | 272 Callback-Id 20 6.1.5 String | M | P | | T,V | Y | 273 Framed-IP-Route 22 6.2.7 String | M | P | | T,V | Y | 274 Framed-IPX-Route 23 6.2.8 String | M | P | | T,V | Y | 275 State 24 2.2.3 Data | M | P | | T,V | Y | 276 Class 25 2.2.4 Data | M | P | | T,V | Y | 277 Idle-Timeout 28 6.1.6 Integer32| M | P | | T,V | Y | 278 Called-Station-Id 30 6.1.7 String | M | P | | T,V | Y | 279 Calling-Station- 31 6.1.8 String | M | P | | T,V | Y | 280 Id | | | | | | 281 NAS-Identifier 32 2.2.2 String | M | P | | T,V | Y | 282 Login-LAT-Service 34 6.3.4 Integer32| M | P | | T,V | Y | 283 Login-LAT-Node 35 6.3.5 String | M | P | | T,V | Y | 284 Login-LAT-Group 36 6.3.6 Data | M | P | | T,V | Y | 285 Framed-Appletalk- 37 6.2.9 Integer32| M | P | | T,V | Y | 286 Link | | | | | | 287 Framed-Appletalk- 38 6.2.10 Integer32| M | P | | T,V | Y | 288 Network | | | | | | 289 Framed-Appletalk- 39 6.2.11 Data | M | P | | T,V | Y | 290 Zone | | | | | | 291 CHAP-Challenge 60 3.1.1.3 Data | M | P | | T,V | Y | 292 NAS-Port-Type 61 6.1.9 Integer32| M | P | | T,V | Y | 293 Port-Limit 62 6.1.10 Integer32| M | P | | T,V | Y | 294 Login-LAT-Port 63 6.3.7 String | M | P | | T,V | Y | 295 Tunnel-Type 64 6.4.1 Integer32| M | P,T | | V | Y | 296 Tunnel-Medium- 65 6.4.2 Integer32| M | P,T | | V | Y | 297 Type | | | | | | 298 Tunnel-Client- 66 6.4.3 String | M | P,T | | V | Y | 299 Endpoint | | | | | | 300 Tunnel-Server- 67 6.4.4 String | M | P,T | | V | Y | 301 Endpoint | | | | | | 302 Tunnel-Password 69 6.4.5 String | M | P,T | | V | Y | 303 Tunnel-Private- 81 6.4.6 String | M | P,T | | V | Y | 304 Group-ID | | | | | | 305 Tunnel- 82 6.4.7 String | M | P,T | | V | Y | 306 Assignment-Id | | | | | | 307 Tunnel-Preference 83 6.4.8 Integer32| M | P,T | | V | Y | 308 Tunnel-Client- 90 6.4.9 String | M | P,T | | V | Y | 309 Auth-ID | | | | | | 310 Tunnel-Server- 91 6.4.10 String | M | P,T | | 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 AVP [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 AVP 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 AVP 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 416 ] 418 3.1.1.1 User-Password AVP 420 The User-Password AVP (AVP Code 2) is of type Data and contains the 421 password of the user to be authenticated, or the user's input 422 following an AA-Challenge-Ind. 424 This AVP MUST be encrypted using one of the methods described in [2] 425 or [13]. Unless this AVP is used for one-time passwords, the User- 426 Password AVP SHOULD NOT be used in non-trusted proxy environments. 428 The clear-text password (prior to encryption) MUST NOT be longer than 429 128 bytes in length. 431 3.1.1.2 CHAP-Password AVP 433 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains 434 the response value provided by a PPP Challenge-Handshake 435 Authentication Protocol (CHAP) [6] user in response to the challenge. 437 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 438 AVP (see section 3.1.1.3) MUST be present as well. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 AVP Header (AVP Code = 3) 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | CHAP Ident | Data ... 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The CHAP Ident field contains the one octet CHAP Identifier from the 449 user's CHAP response [6]. The Data field is 16 octets, and contains 450 the CHAP Response from the user. The actual computation of the CHAP 451 response can be found in [6]. 453 3.1.1.3 CHAP-Challenge AVP 455 The CHAP-Challenge AVP (AVP Code 60) is of type Data and contains the 456 CHAP Challenge sent by the NAS to a PPP Challenge-Handshake 457 Authentication Protocol (CHAP) [6] user. 459 3.1.2 AA-Answer (AAA) Command 461 The AA-Answer (AAA) message, indicated by the Command-Code AVP set to 462 266, is sent in response to the AA-Request message. If authorization 463 was requested, a successful response will include the authorization 464 AVPs appropriate for the service being provided, as defined in 465 section 2.0 and 6.0. 467 Message Format 469 ::= 470 471 472 473 474 475 [] 476 [] 477 [ 478 479 ] 481 3.1.3 AA-Challenge-Ind (ACI) Command 483 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code AVP 484 set to 267, is sent by a DIAMETER Home server to issue a challenge 485 requiring a response to a dial-up user. The message MAY have one or 486 more Reply-Message AVP, the User-Name AVP and it MAY have zero or one 487 State AVP. No other AVPs are permitted in an AA-Challenge-Ind other 488 than security related AVPs [2, 13]. 490 On receipt of an AA-Challenge-Ind, the Identifier field is matched 491 with a pending AA-Request. Invalid messages are silently discarded. 493 The receipt of a valid AA-Challenge-Ind indicates that a new AA- 494 Request SHOULD be sent. The NAS MAY display the text message, if any, 495 to the user, and then prompt the user for a response. It then sends 496 its original AA-Request with a new request ID, with the User-Password 497 AVP replaced by the user's response (encrypted), and including the 498 State AVP from the AA-Challenge-Ind, if any. 500 A NAS that supports PAP MAY forward the Reply-Message to the dial-in 501 client and accept a PAP response which it can use as though the user 502 had entered the response. If the NAS cannot do so, it should treat 503 the AA-Challenge-Ind as though it had received an AA-Answer with a 504 Result-Code AVP set to a value other than DIAMETER_SUCCESS instead. 506 When possible, authentication mechanisms that include more than a 507 single authentication round trip SHOULD use EAP (see section 4.0) 508 instead of the AA-Challenge-Ind. This command has been maintained for 509 RADIUS backward compatibility. 511 AA-Challenge-Ind ::= 512 513 514 515 516 517 [] 518 [] 519 [] 520 [ 521 522 ] 524 3.2 Reply-Message AVP 526 The Reply-Message AVP (AVP Code 18) is of type String and contains 527 text which MAY be displayed to the user. When used in an AA-Answer 528 message with a successful Result-Code AVP it indicates the success 529 message. When found in the same message with a Result-Code other than 530 DIAMETER-SUCCESS it contains the failure message. 532 The Reply-Message AVP MAY indicate a dialog message to prompt the 533 user before another AA-Request attempt. When used in an AA- 534 Challenge-Ind, it MAY indicate a dialog message to prompt the user 535 for a response. 537 Multiple Reply-Message's MAY be included and if any are displayed, 538 they MUST be displayed in the same order as they appear in the 539 message. 541 4.0 Extensible Authentication Protocol Support 543 The Extensible Authentication Protocol (EAP), described in [25], 544 provides a standard mechanism for support of additional 545 authentication methods within PPP. Through the use of EAP, support 546 for a number of authentication schemes may be added, including smart 547 and token cards, Kerberos, Public Key, One Time Passwords, and 548 others. 550 This section describes the Command-Codes values and AVPs that are 551 required for an EAP payload to be encapsulated within the DIAMETER 552 protocol. Since authentication occurs between the PPP client and its 553 home DIAMETER server, end-to-end authentication is achieved, reducing 554 the possibility for fraudulent authentication, such as replay and 555 man-in-the-middle attacks. End-to-end authentication also provides 556 for mutual (bi-directional) authentication, which is not possible 557 with PAP and CHAP in a roaming environment. 559 The DIAMETER/EAP extension allows a home DIAMETER server to initiate 560 an unsolicited authentication request to the user. This allows the 561 home server to periodically ensure that the user is still active, 562 which is useful when a server requires re-authentication to extend 563 the "life" of a session [26]. Server-initiated authentication can 564 reduce the number of protocol exchanges over the Internet. 566 The EAP conversation between the authenticating peer and the NAS 567 begins with the negotiation of EAP within LCP. Once EAP has been 568 negotiated, the NAS will typically send to the DIAMETER server a 569 DIAMETER-EAP-Request message with a NULL EAP-Payload AVP, signifying 570 an EAP-Start. The Port number and NAS Identifier MUST be included in 571 the AVPs issued by the NAS in the DIAMETER-EAP-Request packet. 573 If the DIAMETER home server supports EAP, it MUST respond with a 574 DIAMETER-EAP-Ind message containing an EAP-Payload AVP that includes 575 an encapsulated EAP payload [25]. The EAP payload is forwarded by the 576 NAS to the PPP client. The initial DIAMETER-EAP-Ind normally includes 577 an EAP-Request/Identity, requesting the PPP client to identify 578 itself. Upon receipt of the PPP client's EAP-Response [25], the NAS 579 will then issue a second DIAMETER-EAP-Request message, with the 580 client's EAP payload encapsulated within the EAP-Payload AVP. The 581 conversation continues until the DIAMETER server sends a DIAMETER- 582 EAP-Answer with a Result-Code AVP indicating success or failure. A 583 Result-Code AVP containing a failure indication SHOULD also include 584 an EAP-Payload AVP containing an EAP-Failure [25] payload, and the 585 NAS SHOULD disconnect the PPP client by issuing a LCP terminate. If 586 the Result-Code AVP indicates success, the EAP-Payload AVP MUST 587 encapsulate an EAP-Success [25] payload, and the NAS SHOULD 588 successfully terminate the PPP authentication phase. If authorization 589 was requested, a successful DIAMETER-EAP-Answer MUST also include the 590 appropriate authorization AVPs required for the service requested 591 (see sections 2.0 and 6.0). 593 The above scenario creates a situation in which the NAS never needs 594 to manipulate an EAP packet. An alternative may be used in situations 595 where an EAP-Request/Identity message will always be sent by the NAS 596 to the authenticating peer. This involves having the NAS send an 597 EAP-Request/Identity message to the PPP client, and forwarding the 598 EAP-Response/Identity packet to the DIAMETER server in the EAP- 599 Payload AVP of a DIAMETER-EAP-Request packet. While this approach 600 will save a round-trip, it cannot be universally employed. There are 601 circumstances in which the user's identity may not be needed (such as 602 when authentication and accounting is handled based on the calling or 603 called phone number), and therefore an EAP-Request/Identity packet 604 may not necessarily be issued by the NAS to the authenticating peer. 606 Unless the NAS interprets the EAP-Response/Identity packet returned 607 by the authenticating peer, it will not have access to the user's 608 identity. Therefore, the DIAMETER Server SHOULD return the user's 609 identity by inserting it in the User-Name attribute of subsequent 610 DIAMETER-EAP-Answer packets. Without the user's identity, the 611 Session-Id AVP MAY be used for accounting and billing, however 612 operationally this MAY be very difficult to manage. 614 The DIAMETER-EAP-Ind message MAY be sent by a DIAMETER server in 615 order to initiate an unsolicited authentication of the PPP user, as 616 described in [26]. This functionality allows a home DIAMETER server 617 to easily extend the "life" of a session for a particular service, 618 while reducing the total number of authentication round-trips, should 619 the NAS initiate the periodic authentication. 621 Should an EAP authentication session be interrupted due to a home 622 server failure, the session MAY be directed to an alternate server, 623 but the authentication session will have to be restarted from the 624 beginning. 626 When DIAMETER is used in a roaming environment, the NAS SHOULD issue 627 the EAP-Request/Identity request to the PPP client, and forward the 628 EAP-Response in the initial DIAMETER-EAP-Request message. This allows 629 any DIAMETER proxies or brokers to identify the user, and forward the 630 message to the appropriate home server. If a response is received 631 with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], it is 632 an indication that a DIAMETER server in the proxy chain does not 633 support EAP. The NAS MAY re-open LCP and attempt to negotiate another 634 PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD be 635 cautious when determining whether a less secure authentication 636 protocol will be used, since this could be a result of a bidding down 637 attack. See [28] for additional information. 639 4.1 Alternative uses 641 Currently the conversation between the backend authentication server 642 and the DIAMETER server is proprietary because of lack of 643 standardization. In order to increase standardization and provide 644 interoperability between DIAMETER vendors and backend security 645 vendors, it is recommended that DIAMETER-encapsulated EAP be used for 646 this conversation. 648 This has the advantage of allowing the DIAMETER server to support EAP 649 without the need for authentication-specific code within the DIAMETER 650 server. Authentication-specific code can then reside on a backend 651 authentication server instead. 653 In the case where DIAMETER-encapsulated EAP is used in a conversation 654 between a DIAMETER server and a backend authentication server, the 655 latter will typically return an DIAMETER-EAP-Answer/EAP-Payload/EAP- 656 Success message without inclusion of the expected authorization AVPs 657 required in a successful response. This means that the DIAMETER 658 server MUST add these attributes prior to sending an DIAMETER-EAP- 659 Answer/EAP-Payload/EAP-Success message to the NAS. 661 4.2 Command-Codes AVP Values 663 This section defines new Command-Code [2] values that MUST be 664 supported by all DIAMETER implementations conforming to this 665 specification. The following Command Codes are defined in this 666 section: 668 Command-Name Abbrev. Code Reference 669 -------------------------------------------------------- 670 DIAMETER-EAP-Request DER 268 4.2.1 671 DIAMETER-EAP-Answer DEA 269 4.2.2 672 DIAMETER-EAP-Ind DEI 270 4.2.3 673 DIAMETER-EAP-Terminate DET 275 4.2.4 675 4.2.1 DIAMETER-EAP-Request (DER) Command 677 The DIAMETER-EAP-Request (DER) command, indicated by the Command-Code 678 AVP set to 268, is sent by a DIAMETER client to a DIAMETER server and 679 conveys an EAP-Response [25] from the dial-up PPP client. The 680 DIAMETER-EAP-Request MUST contain one EAP-Payload AVP, which contains 681 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent 682 to the DIAMETER server to initiate an EAP authentication session. 684 Upon receipt of a DIAMETER-EAP-Request, a DIAMETER server MUST issue 685 a reply. The reply may be either: 687 1) a DIAMETER-EAP-Ind containing an EAP-Request encapsulated 688 within an EAP-Payload attribute 689 2) a DIAMETER-EAP-Answer containing an EAP-Success encapsulated 690 within an EAP-Payload and a Result-Code indicating success. 691 3) a DIAMETER-EAP-Answer containing an EAP-Failure encapsulated 692 within an EAP-Payload and a Result-Code indicating failure. 693 4) A Message-Reject-Ind packet with a Result-Code set to 694 DIAMETER_COMMAND_UNSUPPORTED if a DIAMETER server does not 695 support the EAP extension. 697 Message Format 699 ::= 700 701 702 [] 703 [] 704 [] 705 706 707 [ 708 709 ] 711 4.2.2 DIAMETER-EAP-Answer (DEA) Command 713 The DIAMETER-EAP-Answer (DEA) message, indicated by the Command-Code 714 AVP set to 269, is sent by the DIAMETER server to the client to 715 indicate either a successful or failed authentication. The DIAMETER- 716 EAP-Answer message SHOULD include an EAP payload of type EAP-Success 717 or EAP-Failure encapsulated within an EAP-Payload AVP. The Result- 718 Code AVP MUST indicate a failure if the EAP-Failure payload is 719 present, while the AVP MUST indicate success if the EAP-Success 720 payload is present. 722 If the message from the DIAMETER client included a request for 723 authorization, a successful response MUST include the authorization 724 AVPs that are relevant to the service being provided. 726 Message Format 727 ::= 728 729 730 731 732 [] 733 [] 734 [] 735 [ 736 737 ] 739 4.2.3 DIAMETER-EAP-Ind (DEI) Command 741 The DIAMETER-EAP-Ind (DEI) command, indicated by the Command-Code AVP 742 set to 270, has two uses. This message MAY be sent in response to a 743 DIAMETER-EAP-Request message, and MUST contain an EAP-Response 744 payload [25] encapsulated within an EAP-Payload AVP. 746 Alternatively, this message MAY also be sent unsolicited from a 747 DIAMETER server to a client to request re-authentication of a PPP 748 client. For re-authentication, it is recommended that the Identity 749 request be skipped in order to reduce the number of authentication 750 round trips. This is only possible when the user's identity is 751 already known by the home DIAMETER server. 753 Upon receipt of the message, the NAS MUST issue the EAP payload to 754 the PPP Client, and SHOULD respond with a DIAMETER-EAP-Request 755 containing the EAP-Response [25] packet. 757 Message Format 759 ::= 760 761 762 763 764 765 [ 766 767 ] 769 4.3 EAP-Payload AVP 771 The EAP-Payload AVP (AVP Code 402) is of type Data and is used to 772 encapsulate the actual EAP payload [25] that is being exchanged 773 between the dial-up PPP client and the home DIAMETER server. 775 5.0 DIAMETER Session Termination 777 When a Network Access Server (NAS) receives an indication that a 778 user's session is being disconnected (e.g. LCP Terminate is 779 received), the NAS MUST issue a Session-Termination-Request (STR) [2] 780 to its DIAMETER Server. This will ensure that any resources 781 maintained on the servers is freed appropriately. 783 Further, a NAS that receives a Session-Termination-Ind (STI) [2] MUST 784 disconnect the PPP (or tunneling) session and respond with an STR 785 message. 787 6.0 Legacy Authorization AVPs 789 This section contains the various authorization AVPs that are also 790 supported by the RADIUS protocol [1]. Use of these AVPs guarantees 791 interoperability with a RADIUS infrastructure. 793 6.1 Service Identification AVPs 795 This section contains the authorization AVPs that are needed to 796 identify a service, and to allow the server to set constraints on a 797 session. 799 6.1.1 NAS-Port AVP 801 The NAS-Port AVP (AVP Code 5) is of type Integer32 and contains the 802 physical port number of the NAS which is authenticating the user, and 803 is normally only present in an authentication and/or authorization 804 request. Note that this is using "port" in its sense of a physical 805 connection on the NAS, not in the sense of a TCP or UDP port number. 806 Either NAS-Port or NAS-Port-Type (AVP Code 61) or both SHOULD be 807 present in the request, if the NAS differentiates among its ports. 809 6.1.2 Service-Type AVP 811 The Service-Type AVP (AVP Code 6) is of type Integer32 and contains 812 the type of service the user has requested, or the type of service to 813 be provided. One such AVP MAY be present in an authentication and/or 814 authorization request or response. A NAS is not required to implement 815 all of these service types, and MUST treat unknown or unsupported 816 Service-Types as though a response with a Result-Code other than 817 DIAMETER-SUCCESS had been received instead. 819 When used in a request, the Service-Type AVP SHOULD be considered to 820 be a hint to the server that the NAS has reason to believe the user 821 would prefer the kind of service indicated, but the server is not 822 required to honor the hint. The following values have been defined 823 for the Service-Type AVP: 825 Login 1 826 The user should be connected to a host. 828 Framed 2 829 A Framed Protocol should be started for the User, such as PPP or 830 SLIP. 832 Callback Login 3 833 The user should be disconnected and called back, then connected to 834 a host. 836 Callback Framed 4 837 The user should be disconnected and called back, then a Framed 838 Protocol should be started for the User, such as PPP or SLIP. 840 Outbound 5 841 The user should be granted access to outgoing devices. 843 Administrative 6 844 The user should be granted access to the administrative interface 845 to the NAS from which privileged commands can be executed. 847 NAS Prompt 7 848 The user should be provided a command prompt on the NAS from which 849 non-privileged commands can be executed. 851 Authenticate Only 8 852 Only Authentication is requested, and no authorization information 853 needs to be returned in the response. 855 Callback NAS Prompt 9 856 The user should be disconnected and called back, then provided a 857 command prompt on the NAS from which non-privileged commands can 858 be executed. 860 6.1.3 Filter-Id AVP 862 The Filter-Id AVP (AVP Code 11) is of type String and contains the 863 name of the filter list for this user. Zero or more Filter-Id AVPs 864 MAY be sent in an authorization response. 866 Identifying a filter list by name allows the filter to be used on 867 different NASes without regard to filter-list implementation details. 868 However, this AVP is not roaming friendly since filter naming differs 869 from one service provider to another. 871 In non-RADIUS environments, it is strongly recommended that the 872 Filter-Rule AVP be used instead. 874 6.1.4 Callback-Number AVP 876 The Callback-Number AVP (AVP Code 19) is of type String and contains 877 a dialing string to be used for callback. It MAY be used in an 878 authentication and/or authorization request as a hint to the server 879 that a Callback service is desired, but the server is not required to 880 honor the hint in the corresponding response. 882 The codification of the range of allowed usage of this field is 883 outside the scope of this specification. 885 6.1.5 Callback-Id AVP 887 The Callback-Id AVP (AVP Code 20) is of type String and contains the 888 name of a place to be called, to be interpreted by the NAS. This AVP 889 MAY be present in an authentication and/or authorization response. 891 This AVP is not roaming friendly since it assumes that the Callback- 892 Id is configured on the NAS. It is therefore preferable to use the 893 Callback-Number AVP instead. 895 6.1.6 Idle-Timeout AVP 897 The Idle-Timeout AVP (AVP Code 28) is of type Integer32 and sets the 898 maximum number of consecutive seconds of idle connection allowed to 899 the user before termination of the session or prompt. It MAY be used 900 in an authentication and/or authorization request (or challenge) as a 901 hint to the server that an idle timeout is desired, but the server is 902 not required to honor the hint in the corresponding response. 904 6.1.7 Called-Station-Id AVP 906 The Called-Station-Id AVP (AVP Code 30) is of type String and allows 907 the NAS to send in the request the phone number that the user called, 908 using Dialed Number Identification (DNIS) or a similar technology. 909 Note that this may be different from the phone number the call comes 910 in on. It SHOULD only be present in authentication and/or 911 authorization requests. 913 If the Request-Type AVP is set to authorization-only and the User- 914 Name AVP is absent, the DIAMETER Server MAY perform authorization 915 based on this field. This can be used by a NAS to request whether a 916 call should be answered based on the DNIS. 918 The codification of the range of allowed usage of this field is 919 outside the scope of this specification. 921 6.1.8 Calling-Station-Id AVP 923 The Calling-Station-Id AVP (AVP Code 31) is of type String and allows 924 the NAS to send in the request the phone number that the call came 925 from, using Automatic Number Identification (ANI) or a similar 926 technology. It SHOULD only be present in authentication and/or 927 authorization requests. 929 If the Request-Type AVP is set to authorization-only and the User- 930 Name AVP is absent, the DIAMETER Server MAY perform authorization 931 based on this field. This can be used by a NAS to request whether a 932 call should be answered based on the ANI. 934 The codification of the range of allowed usage of this field is 935 outside the scope of this specification. 937 6.1.9 NAS-Port-Type AVP 939 The NAS-Port-Type AVP (AVP Code 61) is of type Integer32 and contains 940 the type of the physical port of the NAS which is authenticating the 941 user. It can be used instead of or in addition to the NAS-Port (5) 942 AVP. This AVP SHOULD only be used in authentication and/or 943 authorization requests. This AVP MAY be combined with the NAS-Port 944 AVP to assist in differentiating its ports. 946 The following values are defined: 947 0 Async 948 1 Sync 949 2 ISDN Sync 950 3 ISDN Async V.120 951 4 ISDN Async V.110 952 5 Virtual 953 6 PIAFS 954 7 HDLC Clear Channel 955 8 X.25 956 9 X.75 957 10 G.3 Fax 958 11 SDSL - Symmetric DSL 959 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 960 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 961 14 IDSL - ISDN Digital Subscriber Line 962 15 Ethernet 963 16 xDSL 964 17 Cable 965 18 Wireless - Other 966 19 Wireless - IEEE 802.11 968 "Virtual" refers to a connection to the NAS via some transport 969 protocol, instead of through a physical port. For example, if a user 970 telnetted into a NAS to authenticate himself as an Outbound-User, the 971 request might include NAS-Port-Type = Virtual as a hint to the 972 DIAMETER server that the user was not on a physical port. 974 6.1.10 Port-Limit AVP 976 The Port-Limit AVP (AVP Code 62) is of type Integer32 and sets the 977 maximum number of ports to be provided to the user by the NAS. It 978 MAY be used in an authentication and/or authorization request as a 979 hint to the server that multilink PPP [9] service is desired, but the 980 server is not required to honor the hint in the corresponding 981 response. 983 6.2 Framed Access Authorization AVPs 985 This section contains the authorization AVPs that are necessary to 986 support framed access, such as PPP, SLIP, etc. 988 6.2.1 Framed-Protocol AVP 990 The Framed-Protocol AVP (AVP Code 7) is of type Integer32 and 991 contains the framing to be used for framed access. This AVP MAY be 992 present in both requests and responses. The following values are 993 currently supported: 995 1 PPP 996 2 SLIP 997 3 AppleTalk Remote Access Protocol (ARAP) 998 4 Gandalf proprietary SingleLink/MultiLink protocol 999 5 Xylogics proprietary IPX/SLIP 1000 6 X.75 Synchronous 1002 6.2.2 Framed-IP-Address AVP 1004 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 1005 contains the address to be configured for the user. It MAY be used in 1006 an authorization request as a hint to the server that a specific 1007 address is desired, but the server is not required to honor the hint 1008 in the corresponding response. 1010 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1011 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1012 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1013 that the NAS should select an address for the user (e.g. Assigned 1014 from a pool of addresses kept by the NAS). 1016 6.2.3 Framed-IP-Netmask AVP 1018 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 1019 contains the IP netmask to be configured for the user when the user 1020 is a router to a network. It MAY be used in an authorization request 1021 as a hint to the server that a specific netmask is desired, but the 1022 server is not required to honor the hint in the corresponding 1023 response. This AVP MUST be present in a response if the request 1024 included this AVP with a value of 0xFFFFFFFF. 1026 6.2.4 Framed-Routing AVP 1028 The Framed-Routing AVP (AVP Code 10) is of type Integer32 and 1029 contains the routing method for the user, when the user is a router 1030 to a network. This AVP SHOULD only be present in authorization 1031 responses. The following values are defined for this AVP: 1033 0 None 1034 1 Send routing packets 1035 2 Listen for routing packets 1036 3 Send and Listen 1038 6.2.5 Framed-MTU AVP 1040 The Framed-MTU AVP (AVP Code 12) is of type Integer32 and contains 1041 the Maximum Transmission Unit to be configured for the user, when it 1042 is not negotiated by some other means (such as PPP). This AVP SHOULD 1043 only be present in authorization responses. The MTU value MUST be 1044 between the range of 64 and 65535. 1046 6.2.6 Framed-Compression AVP 1048 The Framed-Compression AVP (AVP Code 13) is of type Integer32 and 1049 contains the compression protocol to be used for the link. It MAY be 1050 used in an authorization request as a hint to the server that a 1051 specific compression type is desired, but the server is not required 1052 to honor the hint in the corresponding response. 1054 More than one compression protocol AVP MAY be sent. It is the 1055 responsibility of the NAS to apply the proper compression protocol to 1056 appropriate link traffic. 1058 The following values are defined: 1059 0 None 1060 1 VJ TCP/IP header compression [7] 1061 2 IPX header compression 1062 3 Stac-LZS compression 1064 6.2.7 Framed-IP-Route AVP 1066 The Framed-IP-Route AVP (AVP Code 22) is of type String and contains 1067 the routing information to be configured for the user on the NAS. 1068 Zero or more such AVPs MAY be present in an authorization response. 1070 The string MUST contain a destination prefix in dotted quad form 1071 optionally followed by a slash and a decimal length specifier stating 1072 how many high order bits of the prefix should be used. That is 1073 followed by a space, a gateway address in dotted quad form, a space, 1074 and one or more metrics separated by spaces. For example, 1075 "192.168.1.0/24 192.168.1.1 1". 1077 The length specifier may be omitted in which case it should default 1078 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 1079 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 1081 Whenever the gateway address is specified as "0.0.0.0" the IP address 1082 of the user SHOULD be used as the gateway address. 1084 6.2.8 Framed-IPX-Network AVP 1085 The Framed-IPX-Network AVP (AVP Code 23) is of type String and 1086 contains the IPX Network number to be configured for the user. It MAY 1087 be used in an authorization request as a hint to the server that a 1088 specific address is desired, but the server is not required to honor 1089 the hint in the corresponding response. 1091 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1092 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1093 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1094 that the NAS should select an address for the user (e.g. assigned 1095 from a pool of one or more IPX networks kept by the NAS). 1097 6.2.9 Framed-AppleTalk-Link AVP 1099 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Integer32 and 1100 contains the AppleTalk network number which should be used for the 1101 serial link to the user, which is another AppleTalk router. This AVP 1102 MUST only be present in an authorization response and is never used 1103 when the user is not another router. 1105 Despite the size of the field, values range from zero to 65535. The 1106 special value of zero indicates that this is an unnumbered serial 1107 link. A value of one to 65535 means that the serial line between the 1108 NAS and the user should be assigned that value as an AppleTalk 1109 network number. 1111 6.2.10 Framed-AppleTalk-Network AVP 1113 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Integer32 1114 and contains the AppleTalk Network number which the NAS should probe 1115 to allocate an AppleTalk node for the user. This AVP MUST only be 1116 present in an authorization response and is never used when the user 1117 is not another router. Multiple instances of this AVP indicate that 1118 the NAS may probe using any of the network numbers specified. 1120 Despite the size of the field, values range from zero to 65535. The 1121 special value zero indicates that the NAS should assign a network for 1122 the user, using its default cable range. A value between one and 1123 65535 (inclusive) indicates the AppleTalk Network the NAS should 1124 probe to find an address for the user. 1126 6.2.11 Framed-AppleTalk-Zone AVP 1128 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type Data and 1129 contains the AppleTalk Default Zone to be used for this user. This 1130 AVP MUST only be present in an authorization response. Multiple 1131 instances of this AVP in the same message are not allowed. 1133 The codification of the range of allowed usage of this field is 1134 outside the scope of this specification. 1136 6.3 Non-Framed Access Authorization AVPs 1138 This section contains the authorization AVPs that are needed to 1139 support terminal server functionality. 1141 6.3.1 Login-IP-Host AVP 1143 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1144 the system with which to connect the user, when the Login-Service AVP 1145 is included. It MAY be used in an authorization request as a hint to 1146 the server that a specific host is desired, but the server is not 1147 required to honor the hint in the corresponding response. 1149 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1150 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1151 select an address. The value zero indicates that the NAS SHOULD 1152 select a host to connect the user to. 1154 6.3.2 Login-Service AVP 1156 The Login-Service AVP (AVP Code 15) is of type Integer32 and contains 1157 the service which should be used to connect the user to the login 1158 host. This AVP SHOULD only be present in authorization responses. 1160 The following values are defined: 1161 0 Telnet 1162 1 Rlogin 1163 2 TCP Clear 1164 3 PortMaster (proprietary) 1165 4 LAT 1166 5 X25-PAD 1167 6 X25-T3POS 1168 8 TCP Clear Quiet (supresses any NAS-generated connect string) 1170 6.3.3 Login-TCP-Port AVP 1172 The Login-TCP-Port AVP (AVP Code 16) is of type Integer32 and 1173 contains the TCP port with which the user is to be connected, when 1174 the Login-Service AVP is also present. This AVP SHOULD only be 1175 present in authorization responses. The value MUST NOT be greater 1176 than 65535. 1178 6.3.4 Login-LAT-Service AVP 1180 The Login-LAT-Service AVP (AVP Code 34) is of type String and 1181 contains the system with which the user is to be connected by LAT. It 1182 MAY be used in an authorization request as a hint to the server that 1183 a specific service is desired, but the server is not required to 1184 honor the hint in the corresponding response. This AVP MUST only be 1185 present in the response if the Login-Service AVP states that LAT is 1186 desired. 1188 Administrators use the service attribute when dealing with clustered 1189 systems, such as a VAX or Alpha cluster. In such an environment 1190 several different time sharing hosts share the same resources (disks, 1191 printers, etc.), and administrators often configure each to offer 1192 access (service) to each of the shared resources. In this case, each 1193 host in the cluster advertises its services through LAT broadcasts. 1195 Sophisticated users often know which service providers (machines) are 1196 faster and tend to use a node name when initiating a LAT connection. 1197 Alternately, some administrators want particular users to use certain 1198 machines as a primitive form of load balancing (although LAT knows 1199 how to do load balancing itself). 1201 The String field contains the identity of the LAT service to use. 1202 The LAT Architecture allows this string to contain $ (dollar), - 1203 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1204 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1205 string comparisons are case insensitive. 1207 6.3.5 Login-LAT-Node AVP 1209 The Login-LAT-Node AVP (AVP Code 35) is of type String and contains 1210 the Node with which the user is to be automatically connected by LAT. 1211 It MAY be used in an authorization request as a hint to the server 1212 that a specific LAT node is desired, but the server is not required 1213 to honor the hint in the corresponding response. This AVP MUST only 1214 be present in a response if the Service-Type AVP is set to LAT. 1216 The String field contains the identity of the LAT service to use. 1217 The LAT Architecture allows this string to contain $ (dollar), - 1218 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1219 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1220 string comparisons are case insensitive. 1222 6.3.6 Login-LAT-Group AVP 1224 The Login-LAT-Group AVP (AVP Code 36) is of type Data and contains a 1225 string identifying the LAT group codes which this user is authorized 1226 to use. It MAY be used in an authorization request as a hint to the 1227 server that a specific group is desired, but the server is not 1228 required to honor the hint in the corresponding response. This AVP 1229 MUST only be present in a response if the Service-Type AVP is set to 1230 LAT. 1232 LAT supports 256 different group codes, which LAT uses as a form of 1233 access rights. LAT encodes the group codes as a 256 bit bitmap. 1235 Administrators can assign one or more of the group code bits at the 1236 LAT service provider; it will only accept LAT connections that have 1237 these group codes set in the bit map. The administrators assign a 1238 bitmap of authorized group codes to each user; LAT gets these from 1239 the operating system, and uses these in its requests to the service 1240 providers. 1242 The codification of the range of allowed usage of this field is 1243 outside the scope of this specification. 1245 6.3.7 Login-LAT-Port AVP 1247 The Login-LAT-Port AVP (AVP Code 63) is of type String and contains 1248 the Port with which the user is to be connected by LAT. It MAY be 1249 used in an authorization request as a hint to the server that a 1250 specific port is desired, but the server is not required to honor the 1251 hint in the corresponding response. This AVP MUST only be present in 1252 a response if the Service-Type AVP is set to LAT. 1254 The String field contains the identity of the LAT service to use. 1255 The LAT Architecture allows this string to contain $ (dollar), - 1256 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1257 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1258 string comparisons are case insensitive. 1260 6.4 Tunneling AVPs 1262 This section contains the authorization AVPs that are needed for a 1263 NAS to support tunneling users. 1265 6.4.1 Tunnel-Type AVP 1267 The Tunnel-Type AVP (AVP Code 64) is of type Integer32 and contains 1268 the tunneling protocol(s) to be used (in the case of a tunnel 1269 initiator) or the the tunneling protocol in use (in the case of a 1270 tunnel terminator). It MAY be used in an authorization request as a 1271 hint to the server that a specific tunnel type is desired, but the 1272 server is not required to honor the hint in the corresponding 1273 response. 1275 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1276 Record within the Accounting-Request. 1278 A tunnel initiator is not required to implement any of these tunnel 1279 types; if a tunnel initiator receives a response that contains only 1280 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1281 as though a response was received with the Result-Code indicating a 1282 failure. 1284 The following values have been defined: 1285 1 Point-to-Point Tunneling Protocol (PPTP) [14] 1286 2 Layer Two Forwarding (L2F) [15] 1287 3 Layer Two Tunneling Protocol (L2TP) [16] 1288 4 Ascend Tunnel Management Protocol (ATMP) [17] 1289 5 Virtual Tunneling Protocol (VTP) 1290 6 IP Authentication Header in the Tunnel-mode (AH) [18] 1291 7 IP-in-IP Encapsulation (IP-IP) [19] 1292 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 1293 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [21] 1294 10 Generic Route Encapsulation (GRE) [22] 1295 11 Bay Dial Virtual Services (DVS) 1296 12 IP-in-IP Tunneling [23] 1298 6.4.2 Tunnel-Medium-Type AVP 1300 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Integer32 and 1301 contains the transport medium to use when creating a tunnel for those 1302 protocols (such as L2TP) that can operate over multiple transports. 1303 It MAY be used in an authorization request as a hint to the server 1304 that a specific medium is desired, but the server is not required to 1305 honor the hint in the corresponding response. 1307 The Value field is three octets and contains one of the values listed 1308 under "Address Family Numbers" in [10]. The value of most importance 1309 is (1) for IPv4 and (2) for IPv6. 1311 6.4.3 Tunnel-Client-Endpoint AVP 1313 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type String and 1314 contains the address of the initiator end of the tunnel. It MAY be 1315 used in an authorization request as a hint to the server that a 1316 specific endpoint is desired, but the server is not required to honor 1317 the hint in the corresponding response. 1319 This AVP SHOULD be included in the ADIF Record of the corresponding 1320 Accounting-Request messages, in which case it indicates the address 1321 from which the tunnel was initiated. This AVP, along with the 1322 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1323 a globally unique means to identify a tunnel for accounting and 1324 auditing purposes. 1326 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1327 fully qualified domain name (FQDN) of the tunnel client machine, or 1328 it is a "dotted-decimal" IP address. Conformant implementations MUST 1329 support the dotted-decimal format and SHOULD support the FQDN format 1330 for IP addresses. 1332 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1333 FQDN of the tunnel client machine, or it is a text representation of 1334 the address in either the preferred or alternate form [5]. 1335 Conformant implementations MUST support the preferred form and SHOULD 1336 support both the alternate text form and the FQDN format for IPv6 1337 addresses. 1339 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1340 referring to configuration data local to the DIAMETER client that 1341 describes the interface and medium-specific address to use. 1343 6.4.4 Tunnel-Server-Endpoint AVP 1345 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of String and 1346 contains the address of the server end of the tunnel. It MAY be used 1347 in an authorization request as a hint to the server that a specific 1348 endpoint is desired, but the server is not required to honor the hint 1349 in the corresponding response. 1351 This AVP SHOULD be included in the ADIF Record of the corresponding 1352 Accounting-Request messages, in which case it indicates the address 1353 from which the tunnel was initiated. This AVP, along with the 1354 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1355 a globally unique means to identify a tunnel for accounting and 1356 auditing purposes. 1358 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1359 fully qualified domain name (FQDN) of the tunnel client machine, or 1360 it is a "dotted-decimal" IP address. Conformant implementations MUST 1361 support the dotted-decimal format and SHOULD support the FQDN format 1362 for IP addresses. 1364 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1365 FQDN of the tunnel client machine, or it is a text representation of 1366 the address in either the preferred or alternate form [5]. 1367 Conformant implementations MUST support the preferred form and SHOULD 1368 support both the alternate text form and the FQDN format for IPv6 1369 addresses. 1371 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1372 referring to configuration data local to the DIAMETER client that 1373 describes the interface and medium-specific address to use. 1375 6.4.5 Tunnel-Password AVP 1377 The Tunnel-Password AVP (AVP Code 69) is of type Data and may contain 1378 a password to be used to authenticate to a remote server. This AVP 1379 MUST only be present in authorization responses in an encrypted form, 1380 using one of the methods described in [2] and [13]. 1382 6.4.6 Tunnel-Private-Group-ID AVP 1384 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type String and 1385 contains the group ID for a particular tunneled session. The Tunnel- 1386 Private-Group-ID AVP MAY be included in an authorization request if 1387 the tunnel initiator can pre-determine the group resulting from a 1388 particular connection and SHOULD be included in the authorization 1389 response if this tunnel session is to be treated as belonging to a 1390 particular private group. Private groups may be used to associate a 1391 tunneled session with a particular group of users. For example, it 1392 MAY be used to facilitate routing of unregistered IP addresses 1393 through a particular interface. This value SHOULD be included the 1394 corresponding ADIF-Record in the Accounting-Request which pertain to 1395 a tunneled session. 1397 6.4.7 Tunnel-Assignment-ID AVP 1399 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type String and is 1400 used to indicate to the tunnel initiator the particular tunnel to 1401 which a session is to be assigned. Some tunneling protocols, such as 1402 PPTP and L2TP, allow for sessions between the same two tunnel 1403 endpoints to be multiplexed over the same tunnel and also for a given 1404 session to utilize its own dedicated tunnel. This attribute provides 1405 a mechanism for DIAMETER to be used to inform the tunnel initiator 1406 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1407 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1408 sharing multiplexed tunnels to be assigned to different multiplexed 1409 tunnels. 1411 A particular tunneling implementation may assign differing 1412 characteristics to particular tunnels. For example, different 1413 tunnels may be assigned different QOS parameters. Such tunnels may 1414 be used to carry either individual or multiple sessions. The 1415 Tunnel-Assignment-ID attribute thus allows the DIAMETER server to 1416 indicate that a particular session is to be assigned to a tunnel that 1417 provides an appropriate level of service. It is expected that any 1418 QOS-related DIAMETER tunneling attributes defined in the future that 1419 accompany this attribute will be associated by the tunnel initiator 1420 with the ID given by this attribute. In the meantime, any semantic 1421 given to a particular ID string is a matter left to local 1422 configuration in the tunnel initiator. 1424 The Tunnel-Assignment-ID AVP is of significance only to DIAMETER and 1425 the tunnel initiator. The ID it specifies is intended to be of only 1426 local use to DIAMETER and the tunnel initiator. The ID assigned by 1427 the tunnel initiator is not conveyed to the tunnel peer. 1429 This attribute MAY be included in authorization responses. The tunnel 1430 initiator receiving this attribute MAY choose to ignore it and assign 1431 the session to an arbitrary multiplexed or non-multiplexed tunnel 1432 between the desired endpoints. This attribute SHOULD also be 1433 included in the corresponding ADIF-Record in the Accounting-Request 1434 messages which pertain to a tunneled session. 1436 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1437 should assign a session to a tunnel in the following manner: 1439 - If this AVP is present and a tunnel exists between the specified 1440 endpoints with the specified ID, then the session should be 1441 assigned to that tunnel. 1443 - If this AVP is present and no tunnel exists between the 1444 specified endpoints with the specified ID, then a new tunnel 1445 should be established for the session and the specified ID 1446 should be associated with the new tunnel. 1448 - If this AVP is not present, then the session is assigned to an 1449 unnamed tunnel. If an unnamed tunnel does not yet exist between 1450 the specified endpoints then it is established and used for this 1451 and subsequent sessions established without the Tunnel- 1452 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1453 session for which a Tunnel-Assignment-ID AVP was not specified 1454 to a named tunnel (i.e. one that was initiated by a session 1455 specifying this AVP). 1457 Note that the same ID may be used to name different tunnels if such 1458 tunnels are between different endpoints. 1460 6.4.8 Tunnel-Preference AVP 1462 The Tunnel-Preference AVP (AVP Code 83) is of type Integer32 and is 1463 used to identify the relative preference assigned to each tunnel when 1464 more than one set of tunneling AVPs is returned (tagged). It MAY be 1465 used in an authorization request as a hint to the server that a 1466 specific preference is desired, but the server is not required to 1467 honor the hint in the corresponding response. 1469 For example, suppose that AVPs describing two tunnels are returned by 1470 the server, one with a Tunnel-Type of PPTP and the other with a 1471 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1472 the Tunnel-Types returned, it will initiate a tunnel of that type. 1473 If, however, it supports both tunnel protocols, it SHOULD use the 1474 value of the Tunnel-Preference AVP to decide which tunnel should be 1475 started. The tunnel having the numerically lowest value in the Value 1476 field of this AVP SHOULD be given the highest preference. The values 1477 assigned to two or more instances of the Tunnel-Preference AVP within 1478 a given authorization response MAY be identical. In this case, the 1479 tunnel initiator SHOULD use locally configured metrics to decide 1480 which set of AVPs to use. 1482 6.4.9 Tunnel-Client-Auth-ID AVP 1484 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type String and 1485 specifies the name used by the tunnel initiator during the 1486 authentication phase of tunnel establishment. It MAY be used in an 1487 authorization request as a hint to the server that a specific 1488 preference is desired, but the server is not required to honor the 1489 hint in the corresponding response. This AVP MUST be present in the 1490 authorization response if an authentication name other than the 1491 default is desired. This AVP SHOULD be included in the corresponding 1492 ADIF-Record of the Accounting-Request messages which pertain to a 1493 tunneled session. 1495 6.4.10 Tunnel-Server-Auth-ID AVP 1496 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type String and 1497 specifies the name used by the tunnel terminator during the 1498 authentication phase of tunnel establishment. It MAY be used in an 1499 authorization request as a hint to the server that a specific 1500 preference is desired, but the server is not required to honor the 1501 hint in the corresponding response. This AVP MUST be present in the 1502 authorization response if an authentication name other than the 1503 default is desired. This AVP SHOULD be included in the corresponding 1504 ADIF-Record of the Accounting-Request messages which pertain to a 1505 tunneled session. 1507 7.0 Interactions with Resource Management 1509 The Resource Management extension [31] provides the ability for a 1510 DIAMETER node to query a peer for session state information. The 1511 document states that service-specific extensions are responsible for 1512 specifying what AVPs are to be present in the Resource-Token [31] 1513 AVP. 1515 In addition to the AVPs listed in [31], the Resource-Token with the 1516 Extension-Id AVP set to one (1) MUST include the Service-Type AVP. In 1517 the event of a framed (PPP) user, the Framed-IP-Address and Framed- 1518 IPX-Network MUST be present if the corresponding network is being 1519 used. For Login users, the Login-IP-Host AVP and Login-Service AVP 1520 MUST be present. For tunneling users, the Tunnel-Type, Tunnel- 1521 Medium-Type, Tunnel-Client-Endpoint, and the Tunnel-Server-Endpoint 1522 AVPs MUST be present. 1524 8.0 IANA Considerations 1526 The command codes defined in Sections 3.1 and 4.2 are values taken 1527 from the Command-Code AVP [2] address space and extended in [13], 1528 [29] and [30]. IANA should record the values as defined in Sections 1529 2.1 and 4.2. 1531 The AVPs defined in section 2.1 were alllocated from from the AVP 1532 numbering space defined in [2], and extended in [13], [29] and [30]. 1533 IANA should record the values as defined in Sections 2.1. 1535 The DIAMETER base protocol [2] reserves the first 255 AVPs for legacy 1536 RADIUS support [1]. The AVPs defined in section 2.2 are defined in 1537 [1], and no number assignment is necessary. 1539 8.1 Request-Type AVP Values 1540 The Request-Type AVP (section 2.1.1) has a set of values that MUST be 1541 maintained by IANA. Values 1 through 3 are defined in this document. 1542 The remaining values are available for assignment via Designated 1543 Expert [27]. 1545 9.0 Security Considerations 1547 This document does not contain any security protocol, but does 1548 discuss how PPP authentication protocols can be carried within the 1549 DIAMETER protocol. The PPP authentication protocols that are 1550 described are PAP, CHAP and EAP. 1552 The use of PAP SHOULD be discouraged, since it exposes user's 1553 passwords to possibly non-trusted entities. PAP is also frequently 1554 used for use with One-Time Passwords (OTP), which does not expose any 1555 security risks. However, it is highly recommended that OTP be 1556 supported through the EAP protocol. 1558 This document also describes how CHAP can be carried within the 1559 DIAMETER protocol, which is required for backward RADIUS 1560 compatibility. The CHAP protocol, as used in a RADIUS environment, 1561 facilitates authentication replay attacks, and therefore SHOULD NOT 1562 be used when EAP is available. 1564 10.0 References 1566 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1568 [2] Calhoun, Rubens, Akhtar, Guttman, "DIAMETER Base Protocol", 1569 draft-calhoun-diameter-14.txt, IETF work in progress, April 1570 2000. 1572 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. Janu- 1573 ary 1999. 1575 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 1576 2477, January 1999. 1578 [5] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 1579 RFC 2373, July 1998 1581 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 1582 (CHAP)", RFC 1994, August 1996. 1584 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 1585 links", RFC 1144, February 1990. 1587 [8] ISO 8859. International Standard -- Information Processing -- 1588 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 1589 Alphabet No. 1, ISO 8859-1:1987. 1590 1592 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 1593 (MP)", RFC 1717, November 1994. 1595 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 1596 October 1994 1598 [11] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1599 calhoun-diameter-framework-07.txt, IETF work in progress, April 1600 2000. 1602 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1603 Levels", BCP 14, RFC 2119, March 1997. 1605 [13] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1606 Extension", draft-calhoun-diameter-strong-crypto-03.txt, IETF 1607 work in progress, April 2000. 1609 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 1610 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 1611 July 1999 1613 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two For- 1614 warding (Protocol) 'L2F'", RFC 2341, May 1998 1616 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 1617 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 2661, 1618 August 1999 1620 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 1621 2107, February 1997 1623 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 1624 Protocol", RFC 2401, November 1998 1626 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1627 1996 1629 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1630 October 1996 1632 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1633 1827, August 1995 1635 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 1636 Encapsulation (GRE)", RFC 1701, October 1994 1638 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 1640 [24] M. Beadles, "Criteria for Evaluating Network Access Server Pro- 1641 tocols", draft-ietf-nasreq-criteria-04.txt, IETF work in pro- 1642 gress, March 2000. 1644 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 1645 Protocol (EAP)." RFC 2284, March 1998. 1647 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 1648 ietf-roamops-fraud-limit-00.txt, IETF work in progress, May 1649 1999. 1651 [27] Narten, Alvestrand, "Guidelines for Writing an IANA Considera- 1652 tions Section in RFCs", BCP 26, RFC 2434, October 1998 1654 [28] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1655 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1656 diameter-impl-guide-02.txt, IETF work in progress, April 2000. 1658 [29] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 1659 Extension", draft-calhoun-diameter-accounting-05.txt, IETF work 1660 in progress, April 2000. 1662 [30] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1663 calhoun-diameter-mobileip-07.txt, IETF work in progress, April 1664 2000. 1666 [31] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1667 calhoun-diameter-res-mgmt-03.txt, IETF Work in Progress, April 1668 2000. 1670 11.0 Acknowledgements 1672 The authors would also like to acknowledge the following people for 1673 their contribution in the development of the DIAMETER protocol: 1675 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1676 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1677 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 1678 R. Vollbrecht, Jeff Weisberg and Glen Zorn 1680 12.0 Authors' Addresses 1682 Questions about this memo can be directed to: 1684 Pat R. Calhoun 1685 Network and Security Research Center, Sun Labs 1686 Sun Microsystems, Inc. 1687 15 Network Circle 1688 Menlo Park, California, 94025 1689 USA 1691 Phone: +1 650-786-7733 1692 Fax: +1 650-786-6445 1693 E-mail: pcalhoun@eng.sun.com 1695 William Bulley 1696 Merit Network, Inc. 1697 Building One, Suite 2000 1698 4251 Plymouth Road 1699 Ann Arbor, Michigan 48105-2785 1700 USA 1702 Phone: +1 734-764-9993 1703 Fax: +1 734-647-3185 1704 E-mail: web@merit.edu 1706 Allan C. Rubens 1707 Tut Systems, Inc. 1708 220 E. Huron, Suite 260 1709 Ann Arbor, MI 48104 1710 USA 1712 Phone: +1 734-995-1697 1713 E-Mail: arubens@tutsys.com 1715 Jeff Haag 1716 Cisco Systems 1717 7025 Kit Creek Road 1718 PO Box 14987 1719 Research Triangle Park, NC 27709 1721 Phone: 1-919-392-2353 1722 E-Mail: haag@cisco.com 1724 13.0 Full Copyright Statement 1726 Copyright (C) The Internet Society (1999). All Rights Reserved. 1728 This document and translations of it may be copied and furnished to 1729 others, and derivative works that comment on or otherwise explain it 1730 or assist in its implementation may be prepared, copied, published and 1731 distributed, in whole or in part, without restriction of any kind, 1732 provided that the above copyright notice and this paragraph are 1733 included on all such copies and derivative works. However, this 1734 document itself may not be modified in any way, such as by removing the 1735 copyright notice or references to the Internet Society or other Internet 1736 organizations, except as needed for the purpose of developing 1737 Internet standards in which case the procedures for copyrights defined 1738 in the Internet Standards process must be followed, or as required to 1739 translate it into languages other than English. The limited permissions 1740 granted above are perpetual and will not be revoked by the 1741 Internet Society or its successors or assigns. This document and the 1742 information contained herein is provided on an "AS IS" basis and THE 1743 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1744 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1745 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1746 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1747 PARTICULAR PURPOSE.