idnits 2.17.1 draft-calhoun-diameter-nasreq-01.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 35 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 36 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 67 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 == Line 1575 has weird spacing: '... copied and ...' == Line 1576 has weird spacing: '...s, and deriv...' == Line 1578 has weird spacing: '...ed, in whole...' == Line 1579 has weird spacing: '...hat the above...' == Line 1581 has weird spacing: '...such as by r...' == (4 more instances...) == 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 1457, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1475, 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-11 -- 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-05 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-00 -- Possible downref: Normative reference to a draft: ref. '13' ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '14') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '15') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '17') ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '21') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '22') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '23') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-03 ** 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-00 -- Possible downref: Normative reference to a draft: ref. '28' Summary: 22 errors (**), 0 flaws (~~), 19 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-nasreq-01.txt William Bulley 4 Date: December 1999 Merit Network, Inc. 5 Allan C. Rubens 6 Tut Systems, Inc. 7 Jeff Haag 8 Cisco Systems 10 DIAMETER NASREQ Extensions 12 Status of this Memo 14 This document is an individual contribution for consideration by the 15 AAA Working Group of the Internet Engineering Task Force. Comments 16 should be submitted to the diameter@ipass.com mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 37 http://www.ietf.org/shadow.html. 39 Copyright (C) The Internet Society 1999. All Rights Reserved. 41 Abstract 43 This document describes the DIAMETER extension that is used for AAA 44 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 45 extension, combined with the base protocol, satisfies the 46 requirements defined in the NASREQ AAA criteria specification and the 47 ROAMOPS AAA Criteria specification. 49 Given that it is expected that initial deployments of the DIAMETER 50 protocol in a dial-up environment will include legacy systems, this 51 extension was carefully designed to ease the burden of servers that 52 must perform protocol conversion between RADIUS and DIAMETER. This 53 is achieved by re-using the RADIUS address space, eliminating the 54 need to perform attribute lookups. 56 Table of Contents 58 1.0 Introduction 59 1.1 Requirements language 60 2.0 DIAMETER AVPs 61 2.1 Request-Type AVP 62 2.2 Filter-Rule AVP 63 3.0 Legacy PPP Authentication Support 64 3.1 Command-Codes AVP Values 65 3.1.1 AA-Request (AAR) Command 66 3.1.1.1 User-Password AVP 67 3.1.1.2 CHAP-Password AVP 68 3.1.1.3 CHAP-Challenge AVP 69 3.1.2 AA-Answer (AAA) Command 70 3.1.3 AA-Challenge-Ind (ACI) Command 71 3.2 Reply-Message AVP 72 4.0 Extensible Authentication Protocol Support 73 4.1 Alternative Uses 74 4.2 Command-Codes AVP Values 75 4.2.1 DIAMETER-EAP-Request (DER) Command 76 4.2.2 DIAMETER-EAP-Answer (DEA) Command 77 4.2.3 DIAMETER-EAP-Ind (DEI) Command 78 4.3 EAP-Payload AVP 79 5.0 Legacy Authorization AVPs 80 5.1 Service Identification AVPs 81 5.1.1 NAS-Port AVP 82 5.1.2 Service-Type AVP 83 5.1.3 Filter-Id AVP 84 5.1.4 Callback-Number AVP 85 5.1.5 Callback-Id AVP 86 5.1.6 Idle-Timeout AVP 87 5.1.7 Called-Station-Id AVP 88 5.1.8 Calling-Station-Id AVP 89 5.1.9 NAS-Port-Type AVP 90 5.1.10 Port-Limit AVP 91 5.1.11 Filter-Rule AVP 92 5.2 Framed Access Authorization AVPs 93 5.2.1 Framed-Protocol AVP 94 5.2.2 Framed-IP-Address AVP 95 5.2.3 Framed-IP-Netmask AVP 96 5.2.4 Framed-Routing AVP 97 5.2.5 Framed-MTU AVP 98 5.2.6 Framed-Compression AVP 99 5.2.7 Framed-IP-Route AVP 100 5.2.8 Framed-IPX-Network AVP 101 5.2.9 Framed-AppleTalk-Link AVP 102 5.2.10 Framed-AppleTalk-Network AVP 103 5.2.11 Framed-AppleTalk-Zone AVP 105 5.3 Non-Framed Access Authorization AVPs 106 5.3.1 Login-IP-Host AVP 107 5.3.2 Login-Service AVP 108 5.3.3 Login-TCP-Port AVP 109 5.3.4 Login-LAT-Service AVP 110 5.3.5 Login-LAT-Node AVP 111 5.3.6 Login-LAT-Group AVP 112 5.3.7 Login-LAT-Port AVP 113 5.4 Tunneling AVPs 114 5.4.1 Tunnel-Type AVP 115 5.4.2 Tunnel-Medium-Type AVP 116 5.4.3 Tunnel-Client-Endpoint AVP 117 5.4.4 Tunnel-Server-Endpoint AVP 118 5.4.5 Tunnel-Password AVP 119 5.4.6 Tunnel-Private-Group-ID AVP 120 5.4.7 Tunnel-Assignment-ID AVP 121 5.4.8 Tunnel-Preference AVP 122 5.4.9 Tunnel-Client-Auth-ID AVP 123 5.4.10 Tunnel-Server-Auth-ID AVP 124 6.0 IANA Considerations 125 6.1 Request-Type AVP Values 126 7.0 Security Considerations 127 8.0 References 128 9.0 Acknowledgements 129 10.0 Authors' Addresses 130 11.0 Full Copyright Statement 132 1.0 Introduction 134 This document describes the DIAMETER extension that is used for AAA 135 in a PPP/SLIP Dial-Up and Terminal Server Access environment. This 136 extension, combined with the base protocol [2], satisfies the 137 requirements defined in the NASREQ AAA criteria specification [24] 138 and the ROAMOPS AAA Criteria specification [4]. 140 This document is divided into three main sections. The first section 141 defines the DIAMETER Command-Codes and AVPs that are needed to 142 support legacy PPP authentication protocols, those that are typically 143 supported by RADIUS [1] servers. The second section defines the 144 Command-Codes and AVPs necessary for a DIAMETER node to support PPP's 145 Extensible Authentication Protocol (EAP) [25]. The third section 146 contains the Authorization AVPs that are needed for the various 147 services offered by a NAS, such as PPP dial-in, terminal server and 148 tunneling applications, such as L2TP [16]. 150 Given that it is expected that initial deployments of the DIAMETER 151 protocol in a dial-up environment will include legacy systems, this 152 extension was carefully designed to ease the burden of servers that 153 must perform protocol conversion between RADIUS and DIAMETER. This 154 is achieved by re-using the RADIUS address space, eliminating the 155 need to perform attribute lookups. 157 The value assigned for the Extension-Id [2] AVP is one (1). 159 1.1 Requirements language 161 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 162 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 163 described in [12]. 165 2.0 DIAMETER AVPs 167 This section will define all of the AVPs that are not backward 168 compatible with the RADIUS protocol [1]. A DIAMETER message that 169 includes one of these AVPs MAY cause interoperability issues should 170 the request traverse a AAA node that only supports the RADIUS 171 protocol. However, the DIAMETER protocol SHOULD NOT be hampered from 172 future developments due to the existing installed base. 174 The following table describes the DIAMETER AVPs defined in the NASREQ 175 extension, their AVP Code values, types, possible flag values and 176 whether the AVP MAY be encrypted. 178 +---------------------+ 179 | AVP Flag rules | 180 |----+-----+----+-----|----+ 181 AVP Section Value | | |SHLD| MUST|Encr| 182 Attribute Name Code Defined Type |MUST| MAY | NOT| NOT|Cand| 183 -----------------------------------------|----+-----+----+-----|----+ 184 User-Password 2 3.1.1.1 Data | M | P | | T,V | Y | 185 CHAP-Password 3 3.1.1.2 Data | M | P | | T,V | Y | 186 NAS-Port 5 5.1.1 Integer32| M | P | | T,V | Y | 187 Service-Type 6 5.1.2 Integer32| M | P | | T,V | Y | 188 Framed-Protocol 7 5.2.1 Integer32| M | P | | T,V | Y | 189 Framed-IP-Address 8 5.2.2 Address | M | P | | T,V | Y | 190 Framed-IP-Netmask 9 5.2.3 Address | M | P | | T,V | Y | 191 Framed-Routing 10 5.2.4 Integer32| M | P | | T,V | Y | 192 Filter-Id 11 5.1.3 String | M | P | | T,V | Y | 193 Framed-MTU 12 5.2.5 Integer32| M | P | | T,V | Y | 194 Framed- 13 5.2.6 Integer32| M | P | | T,V | Y | 195 Compression | | | | | | 196 Login-IP-Host 14 5.3.1 Address | M | P | | T,V | Y | 197 Login-Service 15 5.3.2 Integer32| M | P | | T,V | Y | 198 Login-TCP-Port 16 5.3.3 Integer32| M | P | | T,V | Y | 199 Reply-Message 18 3.2 String | M | P | | T,V | Y | 200 Callback-Number 19 5.1.4 String | M | P | | T,V | Y | 201 Callback-Id 20 5.1.5 String | M | P | | T,V | Y | 202 Framed-IP-Route 22 5.2.7 String | M | P | | T,V | Y | 203 Framed-IPX-Route 23 5.2.8 String | M | P | | T,V | Y | 204 Idle-Timeout 28 5.1.6 Integer32| M | P | | T,V | Y | 205 Called-Station-Id 30 5.1.7 String | M | P | | T,V | Y | 206 Calling-Station- 31 5.1.8 String | M | P | | T,V | Y | 207 Id | | | | | | 208 Login-LAT-Service 34 5.3.4 Integer32| M | P | | T,V | Y | 209 Login-LAT-Node 35 5.3.5 String | M | P | | T,V | Y | 210 Login-LAT-Group 36 5.3.6 Data | M | P | | T,V | Y | 211 Framed-Appletalk- 37 5.2.9 Integer32| M | P | | T,V | Y | 212 Link | | | | | | 213 Framed-Appletalk- 38 5.2.10 Integer32| M | P | | T,V | Y | 214 Network | | | | | | 215 Framed-Appletalk- 39 5.2.11 Data | M | P | | T,V | Y | 216 Zone | | | | | | 217 CHAP-Challenge 60 3.1.1.3 Data | M | P | | T,V | Y | 218 NAS-Port-Type 61 5.1.9 Integer32| M | P | | T,V | Y | 219 Port-Limit 62 5.1.10 Integer32| M | P | | T,V | Y | 220 Login-LAT-Port 63 5.3.7 String | M | P | | T,V | Y | 221 Tunnel-Type 64 5.4.1 Integer32| M | P,T | | V | Y | 222 Tunnel-Medium- 65 5.4.2 Integer32| M | P,T | | V | Y | 223 Type | | | | | | 224 Tunnel-Client- 66 5.4.3 String | M | P,T | | V | Y | 225 Endpoint | | | | | | 226 Tunnel-Server- 67 5.4.4 String | M | P,T | | V | Y | 227 Endpoint | | | | | | 228 Tunnel-Password 69 5.4.5 String | M | P,T | | V | Y | 229 Tunnel-Private- 81 5.4.6 String | M | P,T | | V | Y | 230 Group-ID | | | | | | 231 Tunnel- 82 5.4.7 String | M | P,T | | V | Y | 232 Assignment-Id | | | | | | 233 Tunnel-Preference 83 5.4.8 Integer32| M | P,T | | V | Y | 234 Tunnel-Client- 90 5.4.9 String | M | P,T | | V | Y | 235 Auth-ID | | | | | | 236 Tunnel-Server- 91 5.4.10 String | M | P,T | | V | Y | 237 Auth-ID | | | | | | 238 Filter-Rule 400 2.2 String | M | P | | T,V | Y | 239 Request-Type 401 2.1 Integer32| M | P | | T,V | N | 240 EAP-Payload 402 4.2 Data | M | P | | T,V | Y | 242 2.1 Request-Type AVP 244 The Request-Type AVP (AVP Code 401) is of type Integer32 and is 245 used to determine the type of request being transmitted. Note that 246 a request with this AVP set to a value other than AUTHORIZE_AUTHENTICATE 247 MAY break backward RADIUS compatibility. The following values are 248 defined: 250 AUTHENTICATE_ONLY 1 251 The request being sent is for authentication only, and MUST 252 contain the relevant authentication AVPs that are needed by 253 the DIAMETER server to authenticate the user. 255 AUTHORIZE_ONLY 2 256 The request being sent is for authorization only, and MUST 257 contain the authorization AVPs that are necessary to identify 258 the service being requested/offered. 260 AUTHORIZE_AUTHENTICATE 3 261 The request contains a request for both authentication and 262 authorization. The request MUST include both the relevant 263 authentication information, and authorization information 264 necessary to identify the service being requested/offered. 266 2.2 Filter-Rule AVP 268 The Filter-Rule AVP (AVP Code 400) is of type String and provides 269 filter rules that need to be configured on the NAS for the user. One or 270 more such AVPs MAY be present in an authorization response. 272 The String field MUST contain a filter rule in the following format: 273 "permit (offset=value AND offset=value) OR offset=value" or 274 "deny (offset=value AND offset=value) OR offset=value". The keyword 275 "permit" means that the filter will allow any traffic that matches 276 the rule, while deny will not allow the traffic to be routed. The 277 filter rules can also use the keywords "AND" and "OR", for which 278 no additional explanation is necessary. The braces "(" and ")" can 279 be used to setup grouping of expressions. 281 3.0 Legacy PPP Authentication Support 283 This section defines the new Command-Code AVP [2] values required 284 to support the legacy PPP authentication protocol (PAP, CHAP), as 285 well as the AVPs that are necessary to carry the authentication 286 information in the DIAMETER protocol. The functionality defined 287 here provides a RADIUS-like AAA service, over a more reliable and 288 secure transport, as defined in the base protocol [2]. 290 Unlike the RADIUS protocol [1], the DIAMETER protocol does not 291 require authentication information to be contained in a request 292 from the client. Therefore, it is possible to send a request for 293 authorization only. The type of service depends upon the Request-Type 294 AVP. This difference MAY cause operational issues in environments 295 that need RADIUS interoperability, and it MAY be necessary that 296 protocol conversion gateways add some authentication information 297 when transmitting to a RADIUS server. 299 3.1 Command-Codes AVP Values 301 This section defines new Command-Code [2] values that MUST be supported 302 by all DIAMETER implementations that conform to this specification. 304 3.1.1 AA-Request (AAR) Command 306 The AA-Request message (AAR), indicated by the Command-Code AVP set 307 to 265, is used in order to request authentication and/or authorization 308 for a given PPP user. The type of request is identified through the 309 Request-Type AVP, and the default mode is both authentication and 310 authorization. 312 If Authentication is requested the User-Name attribute SHOULD be 313 present, as well as any additional authentication AVPs that would 314 carry the password information. A request for authorization only 315 SHOULD include the information from which the authorization will 316 be performed, such as the DNIS and ANI AVPs. Certain networks MAY 317 use different AVPs for authorization purposes. A request for 318 authorization will include some AVPs defined in sections 2.0 and 5.0. 320 It is possible for a single session to be authorized only first, then 321 followed by an authentication request. However, the inverse SHOULD NOT 322 be permitted. 324 If the AA-Request is a result of an AA-Challenge-Ind, the Session-Id 325 MUST be identical as the one provided in the initial AA-Request 326 for the same session. If the AA-Request is a result of an 327 AA-Challenge-Ind that included a State AVP, the same AVP MUST be 328 present in the following AA-Request. 330 Message Format 331 ::= 332 333 334 335 [] 336 [] 337 [ || 338 && 339 ] 340 [] 341 [] 342 [ 343 344 ] 346 3.1.1.1 User-Password AVP 348 The User-Password AVP (AVP Code 2) is of type Data and contains 349 the password of the user to be authenticated, or the user's input 350 following an AA-Challenge-Ind. 352 This AVP MUST be encrypted using one of the methods described in 353 [2] or [13]. Unless this AVP is used for one-time passwords, the 354 User-Password AVP SHOULD NOT be used in non-trusted proxy 355 environments. 357 The clear-text password (prior to encryption) MUST NOT be longer 358 than 128 bytes in length. 360 3.1.1.2 CHAP-Password AVP 362 The CHAP-Password AVP (AVP Code 3) is of type Complex and contains the 363 response value provided by a PPP Challenge-Handshake Authentication 364 Protocol (CHAP) [6] user in response to the challenge. 366 If the CHAP-Password AVP is found in a message, the CHAP-Challenge 367 AVP (see section 3.1.1.3) MUST be present as well. 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 AVP Header (AVP Code = 3) 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | CHAP Ident | Data ... 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 The CHAP Ident field contains the one octet CHAP Identifier from the 378 user's CHAP response [6]. The Data field is 16 octets, and contains 379 the CHAP Response from the user. The actual computation of the CHAP 380 response can be found in [6]. 382 3.1.1.3 CHAP-Challenge AVP 384 The CHAP-Challenge AVP (AVP Code 60) is of type Data and contains the 385 CHAP Challenge sent by the NAS to a PPP Challenge-Handshake 386 Authentication Protocol (CHAP) [6] user. 388 3.1.2 AA-Answer (AAA) Command 390 The AA-Answer (AAA) message, indicated by the Command-Code AVP set 391 to 266, is sent in response to the AA-Request message. If 392 authorization was requested, a successful response will include 393 the authorization AVPs appropriate for the service being provided, 394 as defined in section 2.0 and 5.0. 396 Message Format 398 ::= 399 400 401 402 403 [] 404 [] 405 [] 406 [ 407 408 ] 410 3.1.3 AA-Challenge-Ind (ACI) Command 412 The AA-Challenge-Ind (ACI) message, indicated by the Command-Code 413 AVP set to 267, is sent by a DIAMETER Home server to issue a 414 challenge requiring a response to a dial-up user. The message MAY 415 have one or more Reply-Message AVP, the User-Name AVP and it MAY 416 have zero or one State AVP. No other AVPs are permitted in an 417 AA-Challenge-Ind other than security related AVPs [2, 13]. 419 On receipt of an AA-Challenge-Ind, the Identifier field is 420 matched with a pending AA-Request. Invalid messages 421 are silently discarded. 423 The receipt of a valid AA-Challenge-Ind indicates that a 424 new AA-Request SHOULD be sent. The NAS MAY display 425 the text message, if any, to the user, and then prompt the user 426 for a response. It then sends its original AA-Request 427 with a new request ID, with the User-Password AVP replaced by the 428 user's response (encrypted), and including the State AVP 429 from the AA-Challenge-Ind, if any. 431 A NAS that supports PAP MAY forward the Reply-Message to the 432 dial-in client and accept a PAP response which it can use as though 433 the user had entered the response. If the NAS cannot do so, it 434 should treat the AA-Challenge-Ind as though it had received an 435 AA-Answer with a Result-Code AVP set to a value other than 436 DIAMETER_SUCCESS instead. 438 When possible, authentication mechanisms that include more than 439 a single authentication round trip SHOULD use EAP (see section 4.0) 440 instead of the AA-Challenge-Ind. This command has been maintained for 441 RADIUS backward compatibility. 443 AA-Challenge-Ind ::= 444 445 446 447 448 [] 449 [] 450 [] 451 [] 452 [ 453 454 ] 456 3.2 Reply-Message AVP 458 The Reply-Message AVP (AVP Code 18) is of type String and contains 459 text which MAY be displayed to the user. When used in an AA-Answer 460 message with a successful Result-Code AVP it indicates the success 461 message. When found in the same message with a Result-Code other 462 than DIAMETER-SUCCESS it contains the failure message. 464 The Reply-Message AVP MAY indicate a dialog message to prompt the 465 user before another AA-Request attempt. When used in an AA-Challenge-Ind, 466 it MAY indicate a dialog message to prompt the user for a response. 468 Multiple Reply-Message's MAY be included and if any are displayed, 469 they MUST be displayed in the same order as they appear in the 470 message. 472 4.0 Extensible Authentication Protocol Support 474 The Extensible Authentication Protocol (EAP), described in [25], 475 provides a standard mechanism for support of additional authentication 476 methods within PPP. Through the use of EAP, support for a number of 477 authentication schemes may be added, including smart and token cards, 478 Kerberos, Public Key, One Time Passwords, and others. 480 This section describes the Command-Codes values and AVPs that are 481 required for an EAP payload to be encapsulated within the DIAMETER 482 protocol. Since authentication occurs between the PPP client and its 483 home DIAMETER server, end-to-end authentication is achieved, reducing 484 the possibility for fraudulent authentication, such as replay and 485 man-in-the-middle attacks. End-to-end authentication also provides for 486 mutual (bi-directional) authentication, which is not possible with 487 PAP and CHAP in a roaming environment. 489 The DIAMETER/EAP extension allows a home DIAMETER server to initiate 490 an unsolicited authentication request to the user. This allows the 491 home server to periodically ensure that the user is still active, which 492 is useful when a server requires re-authentication to extend the "life" 493 of a session [26]. Server-initiated authentication can reduce the number 494 of protocol exchanges over the Internet. 496 The EAP conversation between the authenticating peer and the NAS 497 begins with the negotiation of EAP within LCP. Once EAP has been 498 negotiated, the NAS will typically send to the DIAMETER server a 499 DIAMETER-EAP-Request message with a NULL EAP-Payload AVP, signifying 500 an EAP-Start. The Port number and NAS Identifier MUST be included 501 in the AVPs issued by the NAS in the DIAMETER-EAP-Request packet. 503 If the DIAMETER home server supports EAP, it MUST respond with a 504 DIAMETER-EAP-Ind message containing an EAP-Payload AVP that 505 includes an encapsulated EAP payload [25]. The EAP payload is 506 forwarded by the NAS to the PPP client. The initial 507 DIAMETER-EAP-Ind normally includes an EAP-Request/Identity, 508 requesting the PPP client to identify itself. Upon receipt of the 509 PPP client's EAP-Response [25], the NAS will then issue a second 510 DIAMETER-EAP-Request message, with the client's EAP payload encapsulated 511 within the EAP-Payload AVP. The conversation continues until the 512 DIAMETER server sends a DIAMETER-EAP-Answer with a Result-Code AVP 513 indicating success or failure. A Result-Code AVP containing a 514 failure indication SHOULD also include an EAP-Payload AVP containing 515 an EAP-Failure [25] payload, and the NAS SHOULD disconnect the PPP client 516 by issuing a LCP terminate. If the Result-Code AVP indicates success, 517 the EAP-Payload AVP MUST encapsulate an EAP-Success [25] payload, and 518 the NAS SHOULD successfully terminate the PPP authentication phase. If 519 authorization was requested, a successful DIAMETER-EAP-Answer MUST also 520 include the appropriate authorization AVPs required for the service 521 requested (see sections 2.0 and 5.0). 523 The above scenario creates a situation in which the NAS never needs to 524 manipulate an EAP packet. An alternative may be used in situations 525 where an EAP-Request/Identity message will always be sent by the NAS 526 to the authenticating peer. This involves having the NAS send an 527 EAP-Request/Identity message to the PPP client, and forwarding 528 the EAP-Response/Identity packet to the DIAMETER server in the 529 EAP-Payload AVP of a DIAMETER-EAP-Request packet. While this approach 530 will save a round-trip, it cannot be universally employed. There are 531 circumstances in which the user's identity may not be needed (such as 532 when authentication and accounting is handled based on the calling or 533 called phone number), and therefore an EAP-Request/Identity packet may 534 not necessarily be issued by the NAS to the authenticating peer. 536 Unless the NAS interprets the EAP-Response/Identity packet returned by 537 the authenticating peer, it will not have access to the user's 538 identity. Therefore, the DIAMETER Server SHOULD return the user's 539 identity by inserting it in the User-Name attribute of subsequent 540 DIAMETER-EAP-Answer packets. Without the user's identity, the Session-Id 541 AVP MAY be used for accounting and billing, however operationally this 542 MAY be very difficult to manage. 544 The DIAMETER-EAP-Ind message MAY be sent by a DIAMETER server in order 545 to initiate an unsolicited authentication of the PPP user, as described 546 in [26]. This functionality allows a home DIAMETER server to easily 547 extend the "life" of a session for a particular service, while reducing 548 the total number of authentication round-trips, should the NAS initiate 549 the periodic authentication. 551 Should an EAP authentication session be interrupted due to a home 552 server failure, the session MAY be directed to an alternate server, 553 but the authentication session will have to be restarted from the 554 beginning. 556 When DIAMETER is used in a roaming environment, the NAS SHOULD issue 557 the EAP-Request/Identity request to the PPP client, and forward the 558 EAP-Response in the initial DIAMETER-EAP-Request message. This allows 559 any DIAMETER proxies or brokers to identify the user, and forward 560 the message to the appropriate home server. If a response is 561 received with the Result-Code set to DIAMETER_COMMAND_UNSUPPORTED [2], 562 it is an indication that a DIAMETER server in the proxy chain does 563 not support EAP. The NAS MAY re-open LCP and attempt to negotiate 564 another PPP authentication protocol, such as PAP or CHAP. A NAS SHOULD 565 be cautious when determining whether a less secure authentication 566 protocol will be used, since this could be a result of a bidding down 567 attack. See [28] for additional information. 569 4.1 Alternative uses 571 Currently the conversation between the backend authentication server 572 and the DIAMETER server is proprietary because of lack of 573 standardization. In order to increase standardization and provide 574 interoperability between DIAMETER vendors and backend security vendors, 575 it is recommended that DIAMETER-encapsulated EAP be used for this 576 conversation. 578 This has the advantage of allowing the DIAMETER server to support EAP 579 without the need for authentication-specific code within the DIAMETER 580 server. Authentication-specific code can then reside on a backend 581 authentication server instead. 583 In the case where DIAMETER-encapsulated EAP is used in a conversation 584 between a DIAMETER server and a backend authentication server, the latter 585 will typically return an DIAMETER-EAP-Answer/EAP-Payload/EAP-Success 586 message without inclusion of the expected authorization AVPs required in 587 a successful response. This means that the DIAMETER server MUST add 588 these attributes prior to sending an 589 DIAMETER-EAP-Answer/EAP-Payload/EAP-Success message to the NAS. 591 4.2 Command-Codes AVP Values 593 This section defines new Command-Code [2] values that MUST be supported 594 by all DIAMETER implementations conforming to this specification. 596 4.2.1 DIAMETER-EAP-Request (DER) Command 598 The DIAMETER-EAP-Request (DER) command, indicated by the Command-Code 599 AVP set to 268, is sent by a DIAMETER client to a DIAMETER server 600 and conveys an EAP-Response [25] from the dial-up PPP client. The 601 DIAMETER-EAP-Request MUST contain one EAP-Payload AVP, which contains 602 the actual EAP payload. An EAP-Payload AVP with no data MAY be sent to 603 the DIAMETER server to initiate an EAP authentication session. 605 Upon receipt of a DIAMETER-EAP-Request, a DIAMETER server MUST 606 issue a reply. The reply may be either: 608 1) a DIAMETER-EAP-Ind containing an EAP-Request encapsulated 609 within an EAP-Payload attribute 611 2) a DIAMETER-EAP-Answer containing an EAP-Success encapsulated 612 within an EAP-Payload and a Result-Code indicating success. 613 3) a DIAMETER-EAP-Answer containing an EAP-Failure encapsulated 614 within an EAP-Payload and a Result-Code indicating failure. 615 4) A Message-Reject-Ind packet with a Result-Code set to 616 DIAMETER_COMMAND_UNSUPPORTED if a DIAMETER server does not support 617 the EAP extension. 619 Message Format 621 ::= 622 623 624 [] 625 626 627 [ 628 629 ] 631 4.2.2 DIAMETER-EAP-Answer (DEA) Command 633 The DIAMETER-EAP-Answer (DEA) message, indicated by the Command-Code 634 AVP set to 269, is sent by the DIAMETER server to the client to 635 indicate either a successful or failed authentication. The 636 DIAMETER-EAP-Answer message SHOULD include an EAP payload of 637 type EAP-Success or EAP-Failure encapsulated within an EAP-Payload 638 AVP. The Result-Code AVP MUST indicate a failure if the EAP-Failure 639 payload is present, while the AVP MUST indicate success if the 640 EAP-Success payload is present. 642 If the message from the DIAMETER client included a request for 643 authorization, a successful response MUST include the authorization 644 AVPs that are relevant to the service being provided. 646 Message Format 648 ::= 649 650 651 652 [] 653 [] 654 [] 655 [] 656 [ 657 658 ] 660 4.2.3 DIAMETER-EAP-Ind (DEI) Command 662 The DIAMETER-EAP-Ind (DEI) command, indicated by the Command-Code 663 AVP set to 270, has two uses. This message MAY be sent in 664 response to a DIAMETER-EAP-Request message, and MUST contain 665 an EAP-Response payload [25] encapsulated within an EAP-Payload AVP. 667 Alternatively, this message MAY also be sent unsolicited from a 668 DIAMETER server to a client to request re-authentication of a 669 PPP client. For re-authentication, it is recommended that the 670 Identity request be skipped in order to reduce the number of 671 authentication round trips. This is only possible when the user's 672 identity is already known by the home DIAMETER server. 674 Upon receipt of the message, the NAS MUST issue the EAP payload to 675 the PPP Client, and SHOULD respond with a DIAMETER-EAP-Request 676 containing the EAP-Response [25] packet. 678 Message Format 680 ::= 681 682 683 [] 684 685 686 [ 687 688 ] 690 4.3 EAP-Payload AVP 692 The EAP-Payload AVP (AVP Code 402) is of type Data and is used to 693 encapsulate the actual EAP payload [25] that is being exchanged 694 between the dial-up PPP client and the home DIAMETER server. 696 5.0 Legacy Authorization AVPs 698 This section contains the various authorization AVPs that are also 699 supported by the RADIUS protocol [1]. Use of these AVPs guarantees 700 interoperability with a RADIUS infrastructure. 702 5.1 Service Identification AVPs 704 This section contains the authorization AVPs that are needed to identify 705 a service, and to allow the server to set constraints on a session. 707 5.1.1 NAS-Port AVP 709 The NAS-Port AVP (AVP Code 5) is of type Integer32 and contains the physical 710 port number of the NAS which is authenticating the user, and is normally 711 only present in an authentication and/or authorization request. Note that 712 this is using "port" in its sense of a physical connection on the NAS, not 713 in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Type 714 (AVP Code 61) or both SHOULD be present in the request, if the 715 NAS differentiates among its ports. 717 5.1.2 Service-Type AVP 719 The Service-Type AVP (AVP Code 6) is of type Integer32 and contains 720 the type of service the user has requested, or the type of service to 721 be provided. One such AVP MAY be present in an authentication and/or 722 authorization request or response. A NAS is not required to implement 723 all of these service types, and MUST treat unknown or unsupported 724 Service-Types as though a response with a Result-Code other than 725 DIAMETER-SUCCESS had been received instead. 727 When used in a request, the Service-Type AVP SHOULD be 728 considered to be a hint to the server that the NAS has reason 729 to believe the user would prefer the kind of service indicated, 730 but the server is not required to honor the hint. The following 731 values have been defined for the Service-Type AVP: 733 Login 1 734 The user should be connected to a host. 736 Framed 2 737 A Framed Protocol should be started for the User, such as PPP 738 or SLIP. 740 Callback Login 3 741 The user should be disconnected and called back, then connected 742 to a host. 744 Callback Framed 4 745 The user should be disconnected and called back, then a Framed 746 Protocol should be started for the User, such as PPP or SLIP. 748 Outbound 5 749 The user should be granted access to outgoing devices. 751 Administrative 6 752 The user should be granted access to the administrative interface 753 to the NAS from which privileged commands can be executed. 755 NAS Prompt 7 756 The user should be provided a command prompt on the NAS from 757 which non-privileged commands can be executed. 759 Authenticate Only 8 760 Only Authentication is requested, and no authorization information 761 needs to be returned in the response. 763 Callback NAS Prompt 9 764 The user should be disconnected and called back, then provided 765 a command prompt on the NAS from which non-privileged commands 766 can be executed. 768 5.1.3 Filter-Id AVP 770 The Filter-Id AVP (AVP Code 11) is of type String and contains the 771 name of the filter list for this user. Zero or more Filter-Id AVPs 772 MAY be sent in an authorization response. 774 Identifying a filter list by name allows the filter to be used on 775 different NASes without regard to filter-list implementation 776 details. However, this AVP is not roaming friendly since filter 777 naming differs from one service provider to another. 779 In non-RADIUS environments, it is strongly recommended that the 780 Filter-Rule AVP be used instead. 782 5.1.4 Callback-Number AVP 784 The Callback-Number AVP (AVP Code 19) is of type String and contains 785 a dialing string to be used for callback. It MAY be used in an 786 authentication and/or authorization request as a hint to the server 787 that a Callback service is desired, but the server is not required 788 to honor the hint in the corresponding response. 790 The codification of the range of allowed usage of this field is 791 outside the scope of this specification. 793 5.1.5 Callback-Id AVP 795 The Callback-Id AVP (AVP Code 20) is of type String and contains the 796 name of a place to be called, to be interpreted by the NAS. This AVP 797 MAY be present in an authentication and/or authorization response. 799 This AVP is not roaming friendly since it assumes that the 800 Callback-Id is configured on the NAS. It is therefore preferable 801 to use the Callback-Number AVP instead. 803 5.1.6 Idle-Timeout AVP 805 The Idle-Timeout AVP (AVP Code 28) is of type Integer32 and sets the 806 maximum number of consecutive seconds of idle connection allowed to 807 the user before termination of the session or prompt. It MAY be used 808 in an authentication and/or authorization request (or challenge) as a 809 hint to the server that an idle timeout is desired, but the server 810 is not required to honor the hint in the corresponding response. 812 5.1.7 Called-Station-Id AVP 814 The Called-Station-Id AVP (AVP Code 30) is of type String and allows 815 the NAS to send in the request the phone number that the 816 user called, using Dialed Number Identification (DNIS) or a similar 817 technology. Note that this may be different from the phone number the 818 call comes in on. It SHOULD only be present in authentication and/or 819 authorization requests. 821 If the Request-Type AVP is set to authorization-only and the User-Name 822 AVP is absent, the DIAMETER Server MAY perform authorization based on 823 this field. This can be used by a NAS to request whether a call should 824 be answered based on the DNIS. 826 The codification of the range of allowed usage of this field is 827 outside the scope of this specification. 829 5.1.8 Calling-Station-Id AVP 831 The Calling-Station-Id AVP (AVP Code 31) is of type String and allows 832 the NAS to send in the request the phone number that the 833 call came from, using Automatic Number Identification (ANI) or a similar 834 technology. It SHOULD only be present in authentication and/or 835 authorization requests. 837 If the Request-Type AVP is set to authorization-only and the User-Name 838 AVP is absent, the DIAMETER Server MAY perform authorization based on 839 this field. This can be used by a NAS to request whether a call should 840 be answered based on the ANI. 842 The codification of the range of allowed usage of this field is 843 outside the scope of this specification. 845 5.1.9 NAS-Port-Type AVP 847 The NAS-Port-Type AVP (AVP Code 61) is of type Integer32 and contains 848 the type of the physical port of the NAS which is authenticating the 849 user. It can be used instead of or in addition to the NAS-Port (5) AVP. 850 This AVP SHOULD only be used in authentication and/or authorization 851 requests. This AVP MAY be combined with the NAS-Port AVP to assist 852 in differentiating its ports. 854 The following values are defined: 855 0 Async 856 1 Sync 857 2 ISDN Sync 858 3 ISDN Async V.120 859 4 ISDN Async V.110 860 5 Virtual 861 6 PIAFS 862 7 HDLC Clear Channel 863 8 X.25 864 9 X.75 865 10 G.3 Fax 866 11 SDSL - Symmetric DSL 867 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 868 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 869 14 IDSL - ISDN Digital Subscriber Line 870 15 Ethernet 871 16 xDSL 872 17 Cable 873 18 Wireless - Other 874 19 Wireless - IEEE 802.11 876 "Virtual" refers to a connection to the NAS via some transport 877 protocol, instead of through a physical port. For example, if a user 878 telnetted into a NAS to authenticate himself as an Outbound-User, the 879 request might include NAS-Port-Type = Virtual as a hint to the 880 DIAMETER server that the user was not on a physical port. 882 5.1.10 Port-Limit AVP 883 The Port-Limit AVP (AVP Code 62) is of type Integer32 and sets the 884 maximum number of ports to be provided to the user by the NAS. It 885 MAY be used in an authentication and/or authorization request as a 886 hint to the server that multilink PPP [9] service is desired, but the 887 server is not required to honor the hint in the corresponding 888 response. 890 5.2 Framed Access Authorization AVPs 892 This section contains the authorization AVPs that are necessary to 893 support framed access, such as PPP, SLIP, etc. 895 5.2.1 Framed-Protocol AVP 897 The Framed-Protocol AVP (AVP Code 7) is of type Integer32 and 898 contains the framing to be used for framed access. This AVP MAY be 899 present in both requests and responses. The following values are 900 currently supported: 902 1 PPP 903 2 SLIP 904 3 AppleTalk Remote Access Protocol (ARAP) 905 4 Gandalf proprietary SingleLink/MultiLink protocol 906 5 Xylogics proprietary IPX/SLIP 907 6 X.75 Synchronous 909 5.2.2 Framed-IP-Address AVP 911 The Framed-IP-Address AVP (AVP Code 8) is of type Address and 912 contains the address to be configured for the user. It MAY be used in 913 an authorization request as a hint to the server that a specific 914 address is desired, but the server is not required to honor the hint 915 in the corresponding response. 917 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 918 The value 0xFFFFFFFF indicates that the NAS should allow the user to 919 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 920 that the NAS should select an address for the user (e.g. Assigned 921 from a pool of addresses kept by the NAS). 923 5.2.3 Framed-IP-Netmask AVP 925 The Framed-IP-Netmask AVP (AVP Code 9) is of type Address and 926 contains the IP netmask to be configured for the user when the user 927 is a router to a network. It MAY be used in an authorization request 928 as a hint to the server that a specific netmask is desired, but the 929 server is not required to honor the hint in the corresponding 930 response. This AVP MUST be present in a response if the request 931 included this AVP with a value of 0xFFFFFFFF. 933 5.2.4 Framed-Routing AVP 935 The Framed-Routing AVP (AVP Code 10) is of type Integer32 and 936 contains the routing method for the user, when the user is a router 937 to a network. This AVP SHOULD only be present in authorization 938 responses. The following values are defined for this AVP: 940 0 None 941 1 Send routing packets 942 2 Listen for routing packets 943 3 Send and Listen 945 5.2.5 Framed-MTU AVP 947 The Framed-MTU AVP (AVP Code 12) is of type Integer32 and contains 948 the Maximum Transmission Unit to be configured for the user, when it 949 is not negotiated by some other means (such as PPP). This AVP SHOULD 950 only be present in authorization responses. The MTU value MUST be 951 between the range of 64 and 65535. 953 5.2.6 Framed-Compression AVP 955 The Framed-Compression AVP (AVP Code 13) is of type Integer32 and 956 contains the compression protocol to be used for the link. It MAY be 957 used in an authorization request as a hint to the server that a 958 specific compression type is desired, but the server is not required 959 to honor the hint in the corresponding response. 961 More than one compression protocol AVP MAY be sent. It is the 962 responsibility of the NAS to apply the proper compression protocol to 963 appropriate link traffic. 965 The following values are defined: 966 0 None 967 1 VJ TCP/IP header compression [7] 968 2 IPX header compression 969 3 Stac-LZS compression 971 5.2.7 Framed-IP-Route AVP 973 The Framed-IP-Route AVP (AVP Code 22) is of type String and contains 974 the routing information to be configured for the user on the NAS. 975 Zero or more such AVPs MAY be present in an authorization response. 977 The string MUST contain a destination prefix in dotted quad form 978 optionally followed by a slash and a decimal length specifier stating 979 how many high order bits of the prefix should be used. That is 980 followed by a space, a gateway address in dotted quad form, a space, 981 and one or more metrics separated by spaces. For example, 982 "192.168.1.0/24 192.168.1.1 1". 984 The length specifier may be omitted in which case it should default 985 to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 986 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". 988 Whenever the gateway address is specified as "0.0.0.0" the IP address 989 of the user SHOULD be used as the gateway address. 991 5.2.8 Framed-IPX-Network AVP 993 The Framed-IPX-Network AVP (AVP Code 23) is of type String and 994 contains the IPX Network number to be configured for the user. It MAY 995 be used in an authorization request as a hint to the server that a 996 specific address is desired, but the server is not required to honor 997 the hint in the corresponding response. 999 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1000 The value 0xFFFFFFFF indicates that the NAS should allow the user to 1001 select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates 1002 that the NAS should select an address for the user (e.g. assigned 1003 from a pool of one or more IPX networks kept by the NAS). 1005 5.2.9 Framed-AppleTalk-Link AVP 1007 The Framed-AppleTalk-Link AVP (AVP Code 37) is of type Integer32 and 1008 contains the AppleTalk network number which should be used for the 1009 serial link to the user, which is another AppleTalk router. This AVP 1010 MUST only be present in an authorization response and is never used 1011 when the user is not another router. 1013 Despite the size of the field, values range from zero to 65535. The 1014 special value of zero indicates that this is an unnumbered serial 1015 link. A value of one to 65535 means that the serial line between the 1016 NAS and the user should be assigned that value as an AppleTalk 1017 network number. 1019 5.2.10 Framed-AppleTalk-Network AVP 1021 The Framed-AppleTalk-Network AVP (AVP Code 38) is of type Integer32 1022 and contains the AppleTalk Network number which the NAS should probe 1023 to allocate an AppleTalk node for the user. This AVP MUST only be 1024 present in an authorization response and is never used when the user 1025 is not another router. Multiple instances of this AVP indicate that 1026 the NAS may probe using any of the network numbers specified. 1028 Despite the size of the field, values range from zero to 65535. The 1029 special value zero indicates that the NAS should assign a network for 1030 the user, using its default cable range. A value between one and 1031 65535 (inclusive) indicates the AppleTalk Network the NAS should 1032 probe to find an address for the user. 1034 5.2.11 Framed-AppleTalk-Zone AVP 1036 The Framed-AppleTalk-Zone AVP (AVP Code 39) is of type Data and 1037 contains the AppleTalk Default Zone to be used for this user. This 1038 AVP MUST only be present in an authorization response. Multiple 1039 instances of this AVP in the same message are not allowed. 1041 The codification of the range of allowed usage of this field is 1042 outside the scope of this specification. 1044 5.3 Non-Framed Access Authorization AVPs 1046 This section contains the authorization AVPs that are needed to 1047 support terminal server functionality. 1049 5.3.1 Login-IP-Host AVP 1051 The Login-IP-Host AVP (AVP Code 14) is of type Address and contains 1052 the system with which to connect the user, when the Login-Service AVP 1053 is included. It MAY be used in an authorization request as a hint to 1054 the server that a specific host is desired, but the server is not 1055 required to honor the hint in the corresponding response. 1057 Two addresses have special significance; 0xFFFFFFFF and 0xFFFFFFFE. 1058 The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to 1059 select an address. The value zero indicates that the NAS SHOULD 1060 select a host to connect the user to. 1062 5.3.2 Login-Service AVP 1064 The Login-Service AVP (AVP Code 15) is of type Integer32 and contains 1065 the service which should be used to connect the user to the login 1066 host. This AVP SHOULD only be present in authorization responses. 1068 The following values are defined: 1069 0 Telnet 1070 1 Rlogin 1071 2 TCP Clear 1072 3 PortMaster (proprietary) 1073 4 LAT 1074 5 X25-PAD 1075 6 X25-T3POS 1076 8 TCP Clear Quiet (supresses any NAS-generated connect string) 1078 5.3.3 Login-TCP-Port AVP 1080 The Login-TCP-Port AVP (AVP Code 16) is of type Integer32 and 1081 contains the TCP port with which the user is to be connected, when 1082 the Login-Service AVP is also present. This AVP SHOULD only be 1083 present in authorization responses. The value MUST NOT be greater 1084 than 65535. 1086 5.3.4 Login-LAT-Service AVP 1088 The Login-LAT-Service AVP (AVP Code 34) is of type String and 1089 contains the system with which the user is to be connected by LAT. It 1090 MAY be used in an authorization request as a hint to the server that 1091 a specific service is desired, but the server is not required to 1092 honor the hint in the corresponding response. This AVP MUST only be 1093 present in the response if the Login-Service AVP states that LAT is 1094 desired. 1096 Administrators use the service attribute when dealing with clustered 1097 systems, such as a VAX or Alpha cluster. In such an environment 1098 several different time sharing hosts share the same resources (disks, 1099 printers, etc.), and administrators often configure each to offer 1100 access (service) to each of the shared resources. In this case, each 1101 host in the cluster advertises its services through LAT broadcasts. 1103 Sophisticated users often know which service providers (machines) are 1104 faster and tend to use a node name when initiating a LAT connection. 1105 Alternately, some administrators want particular users to use certain 1106 machines as a primitive form of load balancing (although LAT knows 1107 how to do load balancing itself). 1109 The String field contains the identity of the LAT service to use. 1110 The LAT Architecture allows this string to contain $ (dollar), - 1111 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1112 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1113 string comparisons are case insensitive. 1115 5.3.5 Login-LAT-Node AVP 1117 The Login-LAT-Node AVP (AVP Code 35) is of type String and contains 1118 the Node with which the user is to be automatically connected by LAT. 1119 It MAY be used in an authorization request as a hint to the server 1120 that a specific LAT node is desired, but the server is not required 1121 to honor the hint in the corresponding response. This AVP MUST only 1122 be present in a response if the Service-Type AVP is set to LAT. 1124 The String field contains the identity of the LAT service to use. 1125 The LAT Architecture allows this string to contain $ (dollar), - 1126 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1127 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1128 string comparisons are case insensitive. 1130 5.3.6 Login-LAT-Group AVP 1132 The Login-LAT-Group AVP (AVP Code 36) is of type Data and contains a 1133 string identifying the LAT group codes which this user is authorized 1134 to use. It MAY be used in an authorization request as a hint to the 1135 server that a specific group is desired, but the server is not 1136 required to honor the hint in the corresponding response. This AVP 1137 MUST only be present in a response if the Service-Type AVP is set to 1138 LAT. 1140 LAT supports 256 different group codes, which LAT uses as a form of 1141 access rights. LAT encodes the group codes as a 256 bit bitmap. 1143 Administrators can assign one or more of the group code bits at the 1144 LAT service provider; it will only accept LAT connections that have 1145 these group codes set in the bit map. The administrators assign a 1146 bitmap of authorized group codes to each user; LAT gets these from 1147 the operating system, and uses these in its requests to the service 1148 providers. 1150 The codification of the range of allowed usage of this field is 1151 outside the scope of this specification. 1153 5.3.7 Login-LAT-Port AVP 1154 The Login-LAT-Port AVP (AVP Code 63) is of type String and contains 1155 the Port with which the user is to be connected by LAT. It MAY be 1156 used in an authorization request as a hint to the server that a 1157 specific port is desired, but the server is not required to honor the 1158 hint in the corresponding response. This AVP MUST only be present in 1159 a response if the Service-Type AVP is set to LAT. 1161 The String field contains the identity of the LAT service to use. 1162 The LAT Architecture allows this string to contain $ (dollar), - 1163 (hyphen), . (period), _ (underscore), numerics, upper and lower case 1164 alphabetics, and the ISO Latin-1 character set extension [8]. All LAT 1165 string comparisons are case insensitive. 1167 5.4 Tunneling AVPs 1169 This section contains the authorization AVPs that are needed for a 1170 NAS to support tunneling users. 1172 5.4.1 Tunnel-Type AVP 1174 The Tunnel-Type AVP (AVP Code 64) is of type Integer32 and contains 1175 the tunneling protocol(s) to be used (in the case of a tunnel 1176 initiator) or the the tunneling protocol in use (in the case of a 1177 tunnel terminator). It MAY be used in an authorization request as a 1178 hint to the server that a specific tunnel type is desired, but the 1179 server is not required to honor the hint in the corresponding 1180 response. 1182 The Tunnel-Type SHOULD also be present in the corresponding ADIF 1183 Record within the Accounting-Request. 1185 A tunnel initiator is not required to implement any of these tunnel 1186 types; if a tunnel initiator receives a response that contains only 1187 unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave 1188 as though a response was received with the Result-Code indicating a 1189 failure. 1191 The following values have been defined: 1192 1 Point-to-Point Tunneling Protocol (PPTP) [14] 1193 2 Layer Two Forwarding (L2F) [15] 1194 3 Layer Two Tunneling Protocol (L2TP) [16] 1195 4 Ascend Tunnel Management Protocol (ATMP) [17] 1196 5 Virtual Tunneling Protocol (VTP) 1197 6 IP Authentication Header in the Tunnel-mode (AH) [18] 1198 7 IP-in-IP Encapsulation (IP-IP) [19] 1199 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [20] 1200 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [21] 1201 10 Generic Route Encapsulation (GRE) [22] 1202 11 Bay Dial Virtual Services (DVS) 1203 12 IP-in-IP Tunneling [23] 1205 5.4.2 Tunnel-Medium-Type AVP 1207 The Tunnel-Medium-Type AVP (AVP Code 65) is of type Integer32 and 1208 contains the transport medium to use when creating a tunnel for those 1209 protocols (such as L2TP) that can operate over multiple transports. 1210 It MAY be used in an authorization request as a hint to the server 1211 that a specific medium is desired, but the server is not required to 1212 honor the hint in the corresponding response. 1214 The Value field is three octets and contains one of the values listed 1215 under "Address Family Numbers" in [10]. The value of most importance 1216 is (1) for IPv4 and (2) for IPv6. 1218 5.4.3 Tunnel-Client-Endpoint AVP 1220 The Tunnel-Client-Endpoint AVP (AVP Code 66) is of type String and 1221 contains the address of the initiator end of the tunnel. It MAY be 1222 used in an authorization request as a hint to the server that a 1223 specific endpoint is desired, but the server is not required to honor 1224 the hint in the corresponding response. 1226 This AVP SHOULD be included in the ADIF Record of the corresponding 1227 Accounting-Request messages, in which case it indicates the address 1228 from which the tunnel was initiated. This AVP, along with the 1229 Tunnel-Server-Endpoint and Session-Id AVP [2], MAY be used to provide 1230 a globally unique means to identify a tunnel for accounting and 1231 auditing purposes. 1233 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1234 fully qualified domain name (FQDN) of the tunnel client machine, or 1235 it is a "dotted-decimal" IP address. Conformant implementations MUST 1236 support the dotted-decimal format and SHOULD support the FQDN format 1237 for IP addresses. 1239 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1240 FQDN of the tunnel client machine, or it is a text representation of 1241 the address in either the preferred or alternate form [5]. 1242 Conformant implementations MUST support the preferred form and SHOULD 1243 support both the alternate text form and the FQDN format for IPv6 1244 addresses. 1246 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a tag 1247 referring to configuration data local to the DIAMETER client that 1248 describes the interface and medium-specific address to use. 1250 5.4.4 Tunnel-Server-Endpoint AVP 1252 The Tunnel-Server-Endpoint AVP (AVP Code 67) is of String and 1253 contains the address of the server end of the tunnel. It MAY be used 1254 in an authorization request as a hint to the server that a specific 1255 endpoint is desired, but the server is not required to honor the hint 1256 in the corresponding response. 1258 This AVP SHOULD be included in the ADIF Record of the corresponding 1259 Accounting-Request messages, in which case it indicates the address 1260 from which the tunnel was initiated. This AVP, along with the 1261 Tunnel-Client-Endpoint and Session-Id AVP [2], MAY be used to provide 1262 a globally unique means to identify a tunnel for accounting and 1263 auditing purposes. 1265 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 1266 fully qualified domain name (FQDN) of the tunnel client machine, or 1267 it is a "dotted-decimal" IP address. Conformant implementations MUST 1268 support the dotted-decimal format and SHOULD support the FQDN format 1269 for IP addresses. 1271 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 1272 FQDN of the tunnel client machine, or it is a text representation of 1273 the address in either the preferred or alternate form [5]. 1274 Conformant implementations MUST support the preferred form and SHOULD 1275 support both the alternate text form and the FQDN format for IPv6 1276 addresses. 1278 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 1279 referring to configuration data local to the DIAMETER client that 1280 describes the interface and medium-specific address to use. 1282 5.4.5 Tunnel-Password AVP 1284 The Tunnel-Password AVP (AVP Code 69) is of type Data and may contain 1285 a password to be used to authenticate to a remote server. This AVP 1286 MUST only be present in authorization responses in an encrypted form, 1287 using one of the methods described in [2] and [13]. 1289 5.4.6 Tunnel-Private-Group-ID AVP 1290 The Tunnel-Private-Group-ID AVP (AVP Code 81) is of type String and 1291 contains the group ID for a particular tunneled session. The Tunnel- 1292 Private-Group-ID AVP MAY be included in an authorization request if 1293 the tunnel initiator can pre-determine the group resulting from a 1294 particular connection and SHOULD be included in the authorization 1295 response if this tunnel session is to be treated as belonging to a 1296 particular private group. Private groups may be used to associate a 1297 tunneled session with a particular group of users. For example, it 1298 MAY be used to facilitate routing of unregistered IP addresses 1299 through a particular interface. This value SHOULD be included the 1300 corresponding ADIF-Record in the Accounting-Request which pertain to 1301 a tunneled session. 1303 5.4.7 Tunnel-Assignment-ID AVP 1305 The Tunnel-Assignment-ID AVP (AVP Code 82) is of type String and is 1306 used to indicate to the tunnel initiator the particular tunnel to 1307 which a session is to be assigned. Some tunneling protocols, such as 1308 PPTP and L2TP, allow for sessions between the same two tunnel 1309 endpoints to be multiplexed over the same tunnel and also for a given 1310 session to utilize its own dedicated tunnel. This attribute provides 1311 a mechanism for DIAMETER to be used to inform the tunnel initiator 1312 (e.g. PAC, LAC) whether to assign the session to a multiplexed 1313 tunnel or to a separate tunnel. Furthermore, it allows for sessions 1314 sharing multiplexed tunnels to be assigned to different multiplexed 1315 tunnels. 1317 A particular tunneling implementation may assign differing 1318 characteristics to particular tunnels. For example, different 1319 tunnels may be assigned different QOS parameters. Such tunnels may 1320 be used to carry either individual or multiple sessions. The 1321 Tunnel-Assignment-ID attribute thus allows the DIAMETER server to 1322 indicate that a particular session is to be assigned to a tunnel that 1323 provides an appropriate level of service. It is expected that any 1324 QOS-related DIAMETER tunneling attributes defined in the future that 1325 accompany this attribute will be associated by the tunnel initiator 1326 with the ID given by this attribute. In the meantime, any semantic 1327 given to a particular ID string is a matter left to local 1328 configuration in the tunnel initiator. 1330 The Tunnel-Assignment-ID AVP is of significance only to DIAMETER and 1331 the tunnel initiator. The ID it specifies is intended to be of only 1332 local use to DIAMETER and the tunnel initiator. The ID assigned by 1333 the tunnel initiator is not conveyed to the tunnel peer. 1335 This attribute MAY be included in authorization responses. The tunnel 1336 initiator receiving this attribute MAY choose to ignore it and assign 1337 the session to an arbitrary multiplexed or non-multiplexed tunnel 1338 between the desired endpoints. This attribute SHOULD also be 1339 included in the corresponding ADIF-Record in the Accounting-Request 1340 messages which pertain to a tunneled session. 1342 If a tunnel initiator supports the Tunnel-Assignment-ID AVP, then it 1343 should assign a session to a tunnel in the following manner: 1345 - If this AVP is present and a tunnel exists between the specified 1346 endpoints with the specified ID, then the session should be 1347 assigned to that tunnel. 1349 - If this AVP is present and no tunnel exists between the 1350 specified endpoints with the specified ID, then a new tunnel 1351 should be established for the session and the specified ID 1352 should be associated with the new tunnel. 1354 - If this AVP is not present, then the session is assigned to an 1355 unnamed tunnel. If an unnamed tunnel does not yet exist between 1356 the specified endpoints then it is established and used for this 1357 and subsequent sessions established without the Tunnel- 1358 Assignment-ID attribute. A tunnel initiator MUST NOT assign a 1359 session for which a Tunnel-Assignment-ID AVP was not specified 1360 to a named tunnel (i.e. one that was initiated by a session 1361 specifying this AVP). 1363 Note that the same ID may be used to name different tunnels if such 1364 tunnels are between different endpoints. 1366 5.4.8 Tunnel-Preference AVP 1368 The Tunnel-Preference AVP (AVP Code 83) is of type Integer32 and is 1369 used to identify the relative preference assigned to each tunnel when 1370 more than one set of tunneling AVPs is returned (tagged). It MAY be 1371 used in an authorization request as a hint to the server that a 1372 specific preference is desired, but the server is not required to 1373 honor the hint in the corresponding response. 1375 For example, suppose that AVPs describing two tunnels are returned by 1376 the server, one with a Tunnel-Type of PPTP and the other with a 1377 Tunnel-Type of L2TP. If the tunnel initiator supports only one of 1378 the Tunnel-Types returned, it will initiate a tunnel of that type. 1379 If, however, it supports both tunnel protocols, it SHOULD use the 1380 value of the Tunnel-Preference AVP to decide which tunnel should be 1381 started. The tunnel having the numerically lowest value in the Value 1382 field of this AVP SHOULD be given the highest preference. The values 1383 assigned to two or more instances of the Tunnel-Preference AVP within 1384 a given authorization response MAY be identical. In this case, the 1385 tunnel initiator SHOULD use locally configured metrics to decide 1386 which set of AVPs to use. 1388 5.4.9 Tunnel-Client-Auth-ID AVP 1390 The Tunnel-Client-Auth-ID AVP (AVP Code 90) is of type String and 1391 specifies the name used by the tunnel initiator during the 1392 authentication phase of tunnel establishment. It MAY be used in an 1393 authorization request as a hint to the server that a specific 1394 preference is desired, but the server is not required to honor the 1395 hint in the corresponding response. This AVP MUST be present in the 1396 authorization response if an authentication name other than the 1397 default is desired. This AVP SHOULD be included in the corresponding 1398 ADIF-Record of the Accounting-Request messages which pertain to a 1399 tunneled session. 1401 5.4.10 Tunnel-Server-Auth-ID AVP 1403 The Tunnel-Server-Auth-ID AVP (AVP Code 91) is of type String and 1404 specifies the name used by the tunnel terminator during the 1405 authentication phase of tunnel establishment. It MAY be used in an 1406 authorization request as a hint to the server that a specific 1407 preference is desired, but the server is not required to honor the 1408 hint in the corresponding response. This AVP MUST be present in the 1409 authorization response if an authentication name other than the 1410 default is desired. This AVP SHOULD be included in the corresponding 1411 ADIF-Record of the Accounting-Request messages which pertain to a 1412 tunneled session. 1414 6.0 IANA Considerations 1416 The values for the Command-Code AVP in sections 3.0 and 4.0 were 1417 taken from the numbering space defined for Command-Code AVP in [2]. 1418 The numbers for the various AVPs defined in sections 2.0 and 4.0 were 1419 taken from the AVP numbering space defined in [2]. 1421 The numbering space for the various AVPs, and associated values 1422 defined in sections 3.0 and 5.0 are taken from the RADIUS protocol 1423 [1]. 1425 6.1 Request-Type AVP Values 1427 The Request-Type AVP (section 2.1) has a set of values that MUST be 1428 maintained by IANA. Values 1 through 3 are defined in this document. 1429 The remaining values are available for assignment via Designated 1430 Expert [27]. 1432 7.0 Security Considerations 1434 This document does not contain any security protocol, but does 1435 discuss how PPP authentication protocols can be carried within the 1436 DIAMETER protocol. The PPP authentication protocols that are 1437 described are PAP, CHAP and EAP. 1439 The use of PAP SHOULD be discouraged, since it exposes user's 1440 passwords to possibly non-trusted entities. PAP is also frequently 1441 used for use with One-Time Passwords (OTP), which does not expose any 1442 security risks. However, it is highly recommended that OTP be 1443 supported through the EAP protocol. 1445 This document also describes how CHAP can be carried within the 1446 DIAMETER protocol, which is required for backward RADIUS 1447 compatibility. The CHAP protocol, as used in a RADIUS environment, 1448 facilitates authentication replay attacks, and therefore SHOULD NOT 1449 be used when EAP is available. 1451 8.0 References 1453 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1454 [2] Calhoun, Rubens, Akhtar, Guttman, "DIAMETER Base Protocol", 1455 draft-calhoun-diameter-11.txt (work in progress), December 1456 1999. 1457 [3] Aboba, Beadles, "The Network Access Identifier." RFC 2486. 1458 January 1999. 1459 [4] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 1460 2477, January 1999. 1461 [5] Hinden, R., Deering, S., "IP Version 6 Addressing 1462 Architecture", RFC 2373, July 1998 1463 [6] W. Simpson, "PPP Challenge Handshake Authentication Protocol 1464 (CHAP)", RFC 1994, August 1996. 1465 [7] Jacobson, "Compressing TCP/IP headers for low-speed serial 1466 links", RFC 1144, February 1990. 1467 [8] ISO 8859. International Standard -- Information Processing -- 1468 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin 1469 Alphabet No. 1, ISO 8859-1:1987. 1470 1471 [9] Sklower, Lloyd, McGregor, Carr, "The PPP Multilink Protocol 1472 (MP)", RFC 1717, November 1994. 1473 [10] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 1474 October 1994 1475 [11] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft- 1476 calhoun-diameter-framework-05.txt (work in progress), December 1477 1999. 1478 [12] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1479 Levels", BCP 14, RFC 2119, March 1997. 1480 [13] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1481 Extension", draft-calhoun-diameter-strong-crypto-00.txt (work 1482 in progress), December 1999. 1483 [14] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., 1484 Zorn, G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, 1485 July 1999 1486 [15] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two 1487 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 1488 [16] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, 1489 G., Palter, B., "Layer Two Tunneling Protocol (L2TP)", RFC 1490 2661, August 1999 1491 [17] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 1492 2107, February 1997 1493 [18] Kent, S., Atkinson, R., "Security Architecture for the Internet 1494 Protocol", RFC 2401, November 1998 1495 [19] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1496 1996 1497 [20] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, 1498 October 1996 1499 [21] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1500 1827, August 1995 1501 [22] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 1502 Encapsulation (GRE)", RFC 1701, October 1994 1503 [23] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 1504 [24] M. Beadles, "Criteria for Evaluating Network Access Server 1505 Protocols", draft-ietf-nasreq-criteria-03.txt (work in 1506 progress), October 1999. 1507 [25] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authentication 1508 Protocol (EAP)." RFC 2284, March 1998. 1509 [26] G. Zorn, P. R. Calhoun, "Limiting Fraud in Roaming", draft- 1510 ietf-roamops-fraud-limit-00.txt (work in progress), May 1999. 1511 [27] Narten, Alvestrand, "Guidelines for Writing an IANA 1512 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 1513 [28] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J. 1514 Haag, "DIAMETER Implementation Guidelines", draft-calhoun- 1515 diameter-impl-guide-00.txt (work in progress), December 1999. 1517 9.0 Acknowledgements 1519 The authors would also like to acknowledge the following people for 1520 their contribution in the development of the DIAMETER protocol: 1522 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 1523 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 1524 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 1525 R. Vollbrecht, Jeff Weisberg and Glen Zorn 1527 10.0 Authors' Addresses 1529 Questions about this memo can be directed to: 1531 Pat R. Calhoun 1532 Network and Security Research Center, Sun Labs 1533 Sun Microsystems, Inc. 1534 15 Network Circle 1535 Menlo Park, California, 94025 1536 USA 1538 Phone: 1-650-786-7733 1539 Fax: 1-650-786-6445 1540 E-mail: pcalhoun@eng.sun.com 1542 William Bulley 1543 Merit Network, Inc. 1544 Building One, Suite 2000 1545 4251 Plymouth Road 1546 Ann Arbor, Michigan 48105-2785 1547 USA 1549 Phone: 1-734-764-9993 1550 Fax: 1-734-647-3185 1551 E-mail: web@merit.edu 1553 Allan C. Rubens 1554 Tut Systems, Inc. 1555 220 E. Huron, Suite 260 1556 Ann Arbor, MI 48104 1557 USA 1559 Phone: 1-734-995-1697 1560 E-Mail: arubens@tutsys.com 1562 Jeff Haag 1563 Cisco Systems 1564 7025 Kit Creek Road 1565 PO Box 14987 1566 Research Triangle Park, NC 27709 1568 Phone: 1-919-392-2353 1569 E-Mail: haag@cisco.com 1571 11.0 Full Copyright Statement 1573 Copyright (C) The Internet Society (1999). All Rights Reserved. 1575 This document and translations of it may be copied and furnished to 1576 others, and derivative works that comment on or otherwise explain it 1577 or assist in its implementation may be prepared, copied, published and 1578 distributed, in whole or in part, without restriction of any kind, 1579 provided that the above copyright notice and this paragraph are 1580 included on all such copies and derivative works. However, this docu- 1581 ment itself may not be modified in any way, such as by removing the 1582 copyright notice or references to the Internet Society or other Inter- 1583 net organizations, except as needed for the purpose of developing 1584 Internet standards in which case the procedures for copyrights defined 1585 in the Internet Standards process must be followed, or as required to 1586 translate it into languages other than English. The limited permis- 1587 sions granted above are perpetual and will not be revoked by the 1588 Internet Society or its successors or assigns. This document and the 1589 information contained herein is provided on an "AS IS" basis and THE 1590 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1591 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 1592 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1593 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1594 PARTICULAR PURPOSE."