idnits 2.17.1 draft-ietf-radius-tunnel-auth-08.txt: ** The Abstract section seems to be numbered 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2138, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). (Using the creation date from RFC2138, updated by this document, for RFC5378 checks: 1995-07-25) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1999) is 9021 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '12' is defined on line 792, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 795, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2637 (ref. '1') ** Downref: Normative reference to an Historic RFC: RFC 2341 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '4') ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 1827 (ref. '8') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '9') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '10') == Outdated reference: A later version (-04) exists of draft-ietf-radius-tunnel-acct-03 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-acct (ref. '11') ** Obsolete normative reference: RFC 2138 (ref. '12') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1700 (ref. '14') (Obsoleted by RFC 3232) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-04 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '15') ** Obsolete normative reference: RFC 2434 (ref. '16') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2373 (ref. '17') (Obsoleted by RFC 3513) Summary: 20 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Zorn 2 Internet-Draft Microsoft Corporation 3 Updates: RFC 2138 D. Leifer 4 Category: Standards Track A. Rubens 5 Ascend Communications 6 J. Shriver 7 Intel Corporation 8 M. Holdrege 9 I. Goyret 10 Lucent Technologies 11 August 1999 13 RADIUS Attributes for Tunnel Protocol Support 15 1. Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 The distribution of this memo is unlimited. It is filed as , and expires February 9, 2000. Please send 37 comments to the RADIUS Working Group mailing list (ietf- 38 radius@livingston.com) or to the authors (leifer@del.com, acr@del.com, 39 matt@lucent.com, igoyret@lucent.com, John.Shriver@intel.com and 40 gwz@acm.org). 42 2. Abstract 44 This document defines a set of RADIUS attributes designed to support the 45 provision of compulsory tunneling in dial-up networks. 47 3. Motivation 49 Many applications of tunneling protocols such as L2TP involve dial-up 50 network access. Some, such as the provision of access to corporate 51 intranets via the Internet, are characterized by voluntary tunneling: 52 the tunnel is created at the request of the user for a specific purpose. 53 Other applications involve compulsory tunneling: the tunnel is created 54 without any action from the user and without allowing the user any 55 choice in the matter. In order to provide this functionality, new 56 RADIUS attributes are needed to carry the tunneling information from the 57 RADIUS server to the tunnel end points; this document defines those 58 attributes. Specific recommendations for, and examples of, the 59 application of these attributes for L2TP can be found in draft-ietf- 60 radius-tunnel-imp-XX.txt. 62 4. Specification of Requirements 64 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 65 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 66 described in [14]. 68 5. Attributes 70 Multiple instances of each of the attributes defined below may be 71 included in a single RADIUS packet. In this case, the attributes to be 72 applied to any given tunnel SHOULD all contain the same value in their 73 respective Tag fields; otherwise, the Tag field SHOULD NOT be used. 75 If the RADIUS server returns attributes describing multiple tunnels then 76 the tunnels SHOULD be interpreted by the tunnel initiator as 77 alternatives and the server SHOULD include an instance of the Tunnel- 78 Preference Attribute in the set of Attributes pertaining to each 79 alternative tunnel. Similarly, if the RADIUS client includes multiple 80 sets of tunnel Attributes in an Access-Request packet, all the 81 Attributes pertaining to a given tunnel SHOULD contain the same value in 82 their respective Tag fiels and each set SHOULD include an appropriately 83 valued instance of the Tunnel-Preference Attribute. 85 5.1. Tunnel-Type 87 Description 89 This Attribute indicates the tunneling protocol(s) to be used (in 90 the case of a tunnel initiator) or the the tunneling protocol in 91 use (in the case of a tunnel terminator). It MAY be included in 92 Access-Request, Access-Accept and Accounting-Request packets. If 93 the Tunnel-Type Attribute is present in an Access-Request packet 94 sent from a tunnel initiator, it SHOULD be taken as a hint to the 95 RADIUS server as to the tunnelling protocols supported by the 96 tunnel end-point; the RADIUS server MAY ignore the hint, however. 97 A tunnel initiator is not required to implement any of these 98 tunnel types; if a tunnel initiator receives an Access-Accept 99 packet which contains only unknown or unsupported Tunnel-Types, 100 the tunnel initiator MUST behave as though an Access-Reject had 101 been received instead. 103 If the Tunnel-Type Attribute is present in an Access-Request 104 packet sent from a tunnel terminator, it SHOULD be taken to 105 signify the tunnelling protocol in use. In this case, if the 106 RADIUS server determines that the use of the communicated protocol 107 is not authorized, it MAY return an Access-Reject packet. If a 108 tunnel terminator receives an Access-Accept packet which contains 109 one or more Tunnel-Type Attributes, none of which represent the 110 tunneling protocol in use, the tunnel terminator SHOULD behave as 111 though an Access-Reject had been received instead. 113 A summary of the Tunnel-Type Attribute format is shown below. The 114 fields are transmitted from left to right. 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | Type | Length | Tag | Value 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Value (cont) | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 Type 125 64 for Tunnel-Type 127 Length 128 Always 6. 130 Tag 131 The Tag field is one octet in length and is intended to provide a 132 means of grouping attributes in the same packet which refer to the 133 same tunnel. Valid values for this field are 0x01 through 0x1F, 134 inclusive. If the Tag field is unused, it MUST be zero (0x00). 136 Value 137 The Value field is three octets and contains one of the following 138 values, indicating the type of tunnel to be started. 140 1 Point-to-Point Tunneling Protocol (PPTP) [1] 141 2 Layer Two Forwarding (L2F) [2] 142 3 Layer Two Tunneling Protocol (L2TP) [3] 143 4 Ascend Tunnel Management Protocol (ATMP) [4] 144 5 Virtual Tunneling Protocol (VTP) 145 6 IP Authentication Header in the Tunnel-mode (AH) [5] 146 7 IP-in-IP Encapsulation (IP-IP) [6] 147 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 148 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 149 10 Generic Route Encapsulation (GRE) [9] 150 11 Bay Dial Virtual Services (DVS) 151 12 IP-in-IP Tunneling [10] 153 5.2. Tunnel-Medium-Type 155 Description 157 The Tunnel-Medium-Type Attribute indicates which transport medium 158 to use when creating a tunnel for those protocols (such as L2TP) 159 that can operate over multiple transports. It MAY be included in 160 both Access-Request and Access-Accept packets; if it is present in 161 an Access-Request packet, it SHOULD be taken as a hint to the 162 RADIUS server as to the tunnel media supported by the tunnel end- 163 point. The RADIUS server MAY ignore the hint, however. 165 A summary of the Tunnel-Medium-Type Attribute format is given below. 166 The fields are transmitted left to right. 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | Tag | Value | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Value (cont) | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 Type 177 65 for Tunnel-Medium-Type 179 Length 180 6 182 Tag 183 The Tag field is one octet in length and is intended to provide a 184 means of grouping attributes in the same packet which refer to the 185 same tunnel. Valid values for this field are 0x01 through 0x1F, 186 inclusive. If the Tag field is unused, it MUST be zero (0x00). 188 Value 189 The Value field is three octets and contains one of the values 190 listed under "Address Family Numbers" in [14]. For the sake of 191 convenience, a relevant excerpt of this list is reproduced below. 193 1 IPv4 (IP version 4) 194 2 IPv6 (IP version 6) 195 3 NSAP 196 4 HDLC (8-bit multidrop) 197 5 BBN 1822 198 6 802 (includes all 802 media plus Ethernet "canonical format") 199 7 E.163 (POTS) 200 8 E.164 (SMDS, Frame Relay, ATM) 201 9 F.69 (Telex) 202 10 X.121 (X.25, Frame Relay) 203 11 IPX 204 12 Appletalk 205 13 Decnet IV 206 14 Banyan Vines 207 15 E.164 with NSAP format subaddress 209 5.3. Tunnel-Client-Endpoint 211 Description 213 This Attribute contains the address of the initiator end of the 214 tunnel. It MAY be included in both Access-Request and Access- 215 Accept packets to indicate the address from which a new tunnel is 216 to be initiated. If the Tunnel-Client-Endpoint Attribute is 217 included in an Access-Request packet, the RADIUS server should 218 take the value as a hint; the server is not obligated to honor the 219 hint, however. This Attribute SHOULD be included in Accounting- 220 Request packets which contain Acct-Status-Type attributes with 221 values of either Start or Stop, in which case it indicates the 222 address from which the tunnel was initiated. This Attribute, 223 along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- 224 ID attributes, may be used to provide a globally unique means to 225 identify a tunnel for accounting and auditing purposes. 227 A summary of the Tunnel-Client-Endpoint Attribute format is shown 228 below. The fields are transmitted from left to right. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type | Length | Tag | String ... 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Type 237 66 for Tunnel-Client-Endpoint. 239 Length 240 >= 3 242 Tag 243 The Tag field is one octet in length and is intended to provide a 244 means of grouping attributes in the same packet which refer to the 245 same tunnel. If the value of the Tag field is greater than 0x00 246 and less than or equal to 0x1F, it SHOULD be interpreted as 247 indicating which tunnel (of several alternatives) this attribute 248 pertains. If the Tag field is greater than 0x1F, it SHOULD be 249 interpreted as the first byte of the following String field. 251 String 252 The format of the address represented by the String field depends 253 upon the value of the Tunnel-Medium-Type attribute. 255 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 256 fully qualified domain name (FQDN) of the tunnel client machine, 257 or it is a "dotted-decimal" IP address. Conformant 258 implementations MUST support the dotted-decimal format and SHOULD 259 support the FQDN format for IP addresses. 261 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 262 FQDN of the tunnel client machine, or it is a text representation 263 of the address in either the preferred or alternate form [17]. 264 Conformant implementations MUST support the preferred form and 265 SHOULD support both the alternate text form and the FQDN format 266 for IPv6 addresses. 268 If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a 269 tag referring to configuration data local to the RADIUS client 270 that describes the interface and medium-specific address to use. 272 5.4. Tunnel-Server-Endpoint 274 Description 276 This Attribute indicates the address of the server end of the 277 tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as 278 a hint to the RADIUS server) in the Access-Request packet and MUST 279 be included in the Access-Accept packet if the initiation of a 280 tunnel is desired. It SHOULD be included in Accounting-Request 281 packets which contain Acct-Status-Type attributes with values of 282 either Start or Stop and which pertain to a tunneled session. 283 This Attribute, along with the Tunnel-Client-Endpoint and Acct- 284 Tunnel-Connection-ID Attributes [11], may be used to provide a 285 globally unique means to identify a tunnel for accounting and 286 auditing purposes. 288 A summary of the Tunnel-Server-Endpoint Attribute format is shown 289 below. The fields are transmitted from left to right. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length | Tag | String ... 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Type 298 67 for Tunnel-Server-Endpoint. 300 Length 301 >= 3 303 Tag 304 The Tag field is one octet in length and is intended to provide a 305 means of grouping attributes in the same packet which refer to the 306 same tunnel. If the value of the Tag field is greater than 0x00 307 and less than or equal to 0x1F, it SHOULD be interpreted as 308 indicating which tunnel (of several alternatives) this attribute 309 pertains. If the Tag field is greater than 0x1F, it SHOULD be 310 interpreted as the first byte of the following String field. 312 String 313 The format of the address represented by the String field depends 314 upon the value of the Tunnel-Medium-Type attribute. 316 If Tunnel-Medium-Type is IPv4 (1), then this string is either the 317 fully qualified domain name (FQDN) of the tunnel client machine, 318 or it is a "dotted-decimal" IP address. Conformant 319 implementations MUST support the dotted-decimal format and SHOULD 320 support the FQDN format for IP addresses. 322 If Tunnel-Medium-Type is IPv6 (2), then this string is either the 323 FQDN of the tunnel client machine, or it is a text representation 324 of the address in either the preferred or alternate form [17]. 325 Conformant implementations MUST support the preferred form and 326 SHOULD support both the alternate text form and the FQDN format 327 for IPv6 addresses. 329 If Tunnel-Medium-Type is not IPv4 or IPv6, this string is a tag 330 referring to configuration data local to the RADIUS client that 331 describes the interface and medium-specific address to use. 333 5.5. Tunnel-Password 335 Description 337 This Attribute may contain a password to be used to authenticate 338 to a remote server. It may only be included in an Access-Accept 339 packet. 341 A summary of the Tunnel-Password Attribute format is shown below. 342 The fields are transmitted from left to right. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Type | Length | Tag | Salt 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Salt (cont) | String ... 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Type 353 69 for Tunnel-Password 355 Length 356 >= 3 358 Tag 359 The Tag field is one octet in length and is intended to provide a 360 means of grouping attributes in the same packet which refer to the 361 same tunnel. Valid values for this field are 0x01 through 0x1F, 362 inclusive. If the value of the Tag field is greater than 0x00 and 363 less than or equal to 0x1F, it SHOULD be interpreted as indicating 364 which tunnel (of several alternatives) this attribute pertains; 365 otherwise, the Tag field SHOULD be ignored. 367 Salt 368 The Salt field is two octets in length and is used to ensure the 369 uniqueness of the encryption key used to encrypt each instance of 370 the Tunnel-Password attribute occurring in a given Access-Accept 371 packet. The most significant bit (leftmost) of the Salt field 372 MUST be set (1). The contents of each Salt field in a given 373 Access-Accept packet MUST be unique. 375 String 376 The plaintext String field consists of three logical sub-fields: 377 the Data-Length and Password sub-fields (both of which are 378 required), and the optional Padding sub-field. The Data-Length 379 sub-field is one octet in length and contains the length of the 380 unencrypted Password sub-field. The Password sub-field contains 381 the actual tunnel password. If the combined length (in octets) of 382 the unencrypted Data-Length and Password sub-fields is not an even 383 multiple of 16, then the Padding sub-field MUST be present. If it 384 is present, the length of the Padding sub-field is variable, 385 between 1 and 15 octets. The String field MUST be encrypted as 386 follows, prior to transmission: 388 Construct a plaintext version of the String field by 389 concatenating the Data-Length and Password sub-fields. If 390 necessary, pad the resulting string until its length (in 391 octets) is an even multiple of 16. It is recommended that zero 392 octets (0x00) be used for padding. Call this plaintext P. 394 Call the shared secret S, the pseudo-random 128-bit Request 395 Authenticator (from the corresponding Access-Request packet) R, 396 and the contents of the Salt field A. Break P into 16 octet 397 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 398 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 399 Intermediate values b(1), b(2)...c(i) are required. Encryption 400 is performed in the following manner ('+' indicates 401 concatenation): 403 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 404 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 405 . . 406 . . 407 . . 408 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 410 The resulting encrypted String field will contain 411 c(1)+c(2)+...+c(i). 413 On receipt, the process is reversed to yield the plaintext String. 415 5.6. Tunnel-Private-Group-ID 417 Description 419 This Attribute indicates the group ID for a particular tunneled 420 session. The Tunnel-Private-Group-ID Attribute MAY be included in 421 the Access-Request packet if the tunnel initiator can pre- 422 determine the group resulting from a particular connection and 423 SHOULD be included in the Access-Reply packet if this tunnel 424 session is to be treated as belonging to a particular private 425 group. Private groups may be used to associate a tunneled session 426 with a particular group of users. For example, it may be used to 427 facilitate routing of unregistered IP addresses through a 428 particular interface. It SHOULD be included in Accounting-Request 429 packets which contain Acct-Status-Type attributes with values of 430 either Start or Stop and which pertain to a tunneled session. 432 A summary of the Tunnel-Private-Group-ID Attribute format is shown 433 below. The fields are transmitted from left to right. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | Tag | String ... 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Type 442 81 for Tunnel-Private-Group-ID. 444 Length 445 >= 3 447 Tag 448 The Tag field is one octet in length and is intended to provide a 449 means of grouping attributes in the same packet which refer to the 450 same tunnel. If the value of the Tag field is greater than 0x00 451 and less than or equal to 0x1F, it SHOULD be interpreted as 452 indicating which tunnel (of several alternatives) this attribute 453 pertains. If the Tag field is greater than 0x1F, it SHOULD be 454 interpreted as the first byte of the following String field. 456 String 457 This field must be present. The group is represented by the 458 String field. There is no restriction on the format of group IDs. 460 5.7. Tunnel-Assignment-ID 462 Description 464 This Attribute is used to indicate to the tunnel initiator the 465 particular tunnel to which a session is to be assigned. Some 466 tunneling protocols, such as PPTP and L2TP, allow for sessions 467 between the same two tunnel endpoints to be multiplexed over the 468 same tunnel and also for a given session to utilize its own 469 dedicated tunnel. This attribute provides a mechanism for RADIUS 470 to be used to inform the tunnel initiator (e.g. PAC, LAC) whether 471 to assign the session to a multiplexed tunnel or to a separate 472 tunnel. Furthermore, it allows for sessions sharing multiplexed 473 tunnels to be assigned to different multiplexed tunnels. 475 A particular tunneling implementation may assign differing 476 characteristics to particular tunnels. For example, different 477 tunnels may be assigned different QOS parameters. Such tunnels 478 may be used to carry either individual or multiple sessions. The 479 Tunnel-Assignment-ID attribute thus allows the RADIUS server to 480 indicate that a particular session is to be assigned to a tunnel 481 that provides an appropriate level of service. It is expected 482 that any QOS-related RADIUS tunneling attributes defined in the 483 future that accompany this attribute will be associated by the 484 tunnel initiator with the ID given by this attribute. In the 485 meantime, any semantic given to a particular ID string is a matter 486 left to local configuration in the tunnel initiator. 488 The Tunnel-Assignment-ID attribute is of significance only to 489 RADIUS and the tunnel initiator. The ID it specifies is intended 490 to be of only local use to RADIUS and the tunnel initiator. The 491 ID assigned by the tunnel initiator is not conveyed to the tunnel 492 peer. 494 This attribute MAY be included in the Access-Accept. The tunnel 495 initiator receiving this attribute MAY choose to ignore it and 496 assign the session to an arbitrary multiplexed or non-multiplexed 497 tunnel between the desired endpoints. This attribute SHOULD also 498 be included in Accounting-Request packets which contain Acct- 499 Status-Type attributes with values of either Start or Stop and 500 which pertain to a tunneled session. 502 If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, 503 then it should assign a session to a tunnel in the following 504 manner: 506 If this attribute is present and a tunnel exists between the 507 specified endpoints with the specified ID, then the session 508 should be assigned to that tunnel. 510 If this attribute is present and no tunnel exists between the 511 specified endpoints with the specified ID, then a new tunnel 512 should be established for the session and the specified ID 513 should be associated with the new tunnel. 515 If this attribute is not present, then the session is assigned 516 to an unnamed tunnel. If an unnamed tunnel does not yet exist 517 between the specified endpoints then it is established and used 518 for this and subsequent sessions established without the 519 Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT 520 assign a session for which a Tunnel-Assignment-ID Attribute was 521 not specified to a named tunnel (i.e. one that was initiated by 522 a session specifying this attribute). 524 Note that the same ID may be used to name different tunnels if 525 such tunnels are between different endpoints. 527 A summary of the Tunnel-Assignment-ID Attribute format is shown 528 below. The fields are transmitted from left to right. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length | Tag | String ... 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Type 537 82 for Tunnel-Assignment-ID. 539 Length 540 > 3 542 Tag 543 The Tag field is one octet in length and is intended to provide a 544 means of grouping attributes in the same packet which refer to the 545 same tunnel. If the value of the Tag field is greater than 0x00 546 and less than or equal to 0x1F, it SHOULD be interpreted as 547 indicating which tunnel (of several alternatives) this attribute 548 pertains. If the Tag field is greater than 0x1F, it SHOULD be 549 interpreted as the first byte of the following String field. 551 String 552 This field must be present. The tunnel ID is represented by the 553 String field. There is no restriction on the format of the ID. 555 5.8. Tunnel-Preference 557 Description 559 If more than one set of tunneling attributes is returned by the 560 RADIUS server to the tunnel initiator, this Attribute SHOULD be 561 included in each set to indicate the relative preference assigned 562 to each tunnel. For example, suppose that Attributes describing 563 two tunnels are returned by the server, one with a Tunnel-Type of 564 PPTP and the other with a Tunnel-Type of L2TP. If the tunnel 565 initiator supports only one of the Tunnel-Types returned, it will 566 initiate a tunnel of that type. If, however, it supports both 567 tunnel protocols, it SHOULD use the value of the Tunnel-Preference 568 Attribute to decide which tunnel should be started. The tunnel 569 having the numerically lowest value in the Value field of this 570 Attribute SHOULD be given the highest preference. The values 571 assigned to two or more instances of the Tunnel-Preference 572 Attribute within a given Access-Accept packet MAY be identical. 573 In this case, the tunnel initiator SHOULD use locally configured 574 metrics to decide which set of attributes to use. This Attribute 575 MAY be included (as a hint to the server) in Access-Request 576 packets, but the RADIUS server is not required to honor this hint. 578 A summary of the Tunnel-Preference Attribute format is shown below. 579 The fields are transmitted from left to right. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type | Length | Tag | Value 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Value (cont) | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 Type 590 83 for Tunnel-Preference 592 Length 593 Always 6. 595 Tag 596 The Tag field is one octet in length and is intended to provide a 597 means of grouping attributes in the same packet which refer to the 598 same tunnel. Valid values for this field are 0x01 through 0x1F, 599 inclusive. If the Tag field is unused, it MUST be zero (0x00). 601 Value 602 The Value field is three octets in length and indicates the 603 preference to be given to the tunnel to which it refers; higher 604 preference is given to lower values, with 0x000000 being most 605 preferred and 0xFFFFFF least preferred. 607 5.9. Tunnel-Client-Auth-ID 609 Description 611 This Attribute specifies the name used by the tunnel initiator 612 during the authentication phase of tunnel establishment. The 613 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 614 RADIUS server) in the Access-Request packet, and MUST be included 615 in the Access-Request packet if an authentication name other than 616 the default is desired. This Attribute SHOULD be included in 617 Accounting-Request packets which contain Acct-Status-Type 618 attributes with values of either Start or Stop and which pertain 619 to a tunneled session. 621 A summary of the Tunnel-Client-Auth-ID Attribute format is shown 622 below. The fields are transmitted from left to right. 624 0 1 2 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Type | Length | Tag | String ... 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Type 631 90 for Tunnel-Client-Auth-ID. 633 Length 634 > 3 636 Tag 637 The Tag field is one octet in length and is intended to provide a 638 means of grouping attributes in the same packet which refer to the 639 same tunnel. If the value of the Tag field is greater than 0x00 640 and less than or equal to 0x1F, it SHOULD be interpreted as 641 indicating which tunnel (of several alternatives) this attribute 642 pertains. If the Tag field is greater than 0x1F, it SHOULD be 643 interpreted as the first byte of the following String field. 645 String 646 This field must be present. The String field contains the 647 authentication name of the tunnel initiator. The authentication 648 name SHOULD be represented in the UTF-8 charset. 650 5.10. Tunnel-Server-Auth-ID 652 Description 654 This Attribute specifies the name used by the tunnel terminator 655 during the authentication phase of tunnel establishment. The 656 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 657 RADIUS server) in the Access-Request packet, and MUST be included 658 in the Access-Request packet if an authentication name other than 659 the default is desired. This Attribute SHOULD be included in 660 Accounting-Request packets which contain Acct-Status-Type 661 attributes with values of either Start or Stop and which pertain 662 to a tunneled session. 664 A summary of the Tunnel-Server-Auth-ID Attribute format is shown 665 below. The fields are transmitted from left to right. 667 0 1 2 3 668 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 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 | Type | Length | Tag | String ... 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 Type 674 91 for Tunnel-Server-Auth-ID. 676 Length 677 > 3 679 Tag 680 The Tag field is one octet in length and is intended to provide a 681 means of grouping attributes in the same packet which refer to the 682 same tunnel. If the value of the Tag field is greater than 0x00 683 and less than or equal to 0x1F, it SHOULD be interpreted as 684 indicating which tunnel (of several alternatives) this attribute 685 pertains. If the Tag field is greater than 0x1F, it SHOULD be 686 interpreted as the first byte of the following String field. 688 String 689 This field must be present. The String field contains the 690 authentication name of the tunnel terminator. The authentication 691 name SHOULD be represented in the UTF-8 charset. 693 6. Table of Attributes 695 The following table provides a guide to which of the above attributes 696 may be found in which kinds of packets, and in what quantity. 698 Request Accept Reject Challenge Acct-Request # Attribute 699 0+ 0+ 0 0 0-1 64 Tunnel-Type 700 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 701 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 702 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 703 0 0+ 0 0 0 69 Tunnel-Password 704 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 705 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 706 0+ 0+ 0 0 0 83 Tunnel-Preference 707 0+ 0+ 0 0 0-1 90 Tunnel-Client-Auth-ID 708 0+ 0+ 0 0 0-1 91 Tunnel-Server-Auth-ID 710 The following table defines the meaning of the above table entries. 712 0 This attribute MUST NOT be present in packet. 713 0+ Zero or more instances of this attribute MAY be present in packet. 714 0-1 Zero or one instance of this attribute MAY be present in packet. 716 7. Security Considerations 718 The Tunnel-Password Attribute may contain information which should only 719 be known to a tunnel endpoint. However, the method used to hide the 720 value of the attribute is such that intervening RADIUS proxies will have 721 knowledge of the contents. For this reason, the Tunnel-Password 722 Attribute SHOULD NOT be included in Access-Accept packets which may pass 723 through (relatively) untrusted RADIUS proxies. In addition, the Tunnel- 724 Password Attribute SHOULD NOT be returned to an unauthenticated client; 725 if the corresponding Access-Request packet did not contain a verified 726 instance of the Signature Attribute [15], the Access-Accept packet 727 SHOULD NOT contain an instance of the Tunnel-Password Attribute. 729 Tunnel protocols offer various levels of security, from none (e.g., 730 PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory 731 tunneling case any security measures in place only apply to traffic 732 between the tunnel endpoints. In particular, end-users SHOULD NOT rely 733 upon the security of the tunnel to protect their data; encryption and/or 734 integrity protection of tunneled traffic MUST NOT be considered as a 735 replacement for end-to-end security. 737 8. IANA Considerations 739 This document defines a number of "magic" numbers to be maintained by 740 the IANA. This section explains the criteria to be used by the IANA to 741 assign additional numbers in each of these lists. The following 742 subsections describe the assignment policy for the namespaces defined 743 elsewhere in this document. 745 8.1. Tunnel-Type Attribute Values 747 Values 1-12 of the Tunnel-Type Attribute are defined in Section 5.1; the 748 remaining values are available for assignment by the IANA with IETF 749 Consensus [16]. 751 8.2. Tunnel-Medium-Type Attribute Values 753 Values 1-15 of the Tunnel-Medium-Type Attribute are defined in Section 754 5.2; the remaining values are available for assignment by the IANA with 755 IETF Consensus [16]. 757 9. References 759 [1] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W., Zorn, 760 G., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999 762 [2] Valencia, A., Littlewood, M., Kolar, T., "Cisco Layer Two 763 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 765 [3] Townsley, W. M., Valencia, A., Rubens, A., Pall, G. S., Zorn, G., 766 Palter, B., "Layer Two Tunnelling Protocol (L2TP)", RFC 2661, 767 August 1999 769 [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 770 February 1997 772 [5] Kent, S., Atkinson, R., "Security Architecture for the Internet 773 Protocol", RFC 2401, November 1998 775 [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 777 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 778 1996 780 [8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 781 August 1995 783 [9] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing 784 Encapsulation (GRE)", RFC 1701, October 1994 786 [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 788 [11] Zorn, G., Mitton, D., "RADIUS Accounting Modifications for Tunnel 789 Protocol Support", draft-ietf-radius-tunnel-acct-03.txt (work in 790 progress), April 1999 792 [12] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 793 Authentication Dialin User Service (RADIUS)", RFC 2138, April 1997 795 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement 796 Levels", BCP 14, RFC 2119, March 1997 798 [14] Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, 799 October 1994 801 [15] Rigney, C., Willats, W., Calhoun, P., "RADIUS Extensions", draft- 802 ietf-radius-ext-04.txt (work in progress), May 1999 804 [16] Narten, T., Alvestrand, H., "Guidelines for writing an IANA 805 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 807 [17] Hinden, R., Deering, S., "IP Version 6 Addressing Architecture", 808 RFC 2373, July 1998 810 10. Acknowledgements 812 Thanks to Dave Mitton for pointing out a nasty circular dependency in 813 the original Tunnel-Password attribute definition and (in no particular 814 order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, 815 Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and 816 Bernard Aboba for useful input and review. 818 11. Chair's Address 820 The RADIUS Working Group can be contacted via the current chair: 822 Carl Rigney 823 Livingston Enterprises 824 4464 Willow Road 825 Pleasanton, California 94588 827 Phone: +1 510 426 0770 828 E-Mail: cdr@livingston.com 830 12. Authors' Addresses 832 Questions about this memo can also be directed to: 834 Glen Zorn 835 Microsoft Corporation 836 One Microsoft Way 837 Redmond, Washington 98052 839 Phone: +1 425 703 1559 840 E-Mail: gwz@acm.org 842 Dory Leifer 843 Ascend Communications 844 1678 Broadway 845 Ann Arbor, MI 48105 847 Phone: +1 734 747 6152 848 E-Mail: leifer@del.com 850 John Shriver 851 Intel Corporation 852 28 Crosby Drive 853 Bedford, MA 01730 855 Phone: +1 781 687 1329 856 E-Mail: John.Shriver@intel.com 858 Allan Rubens 859 Ascend Communications 860 1678 Broadway 861 Ann Arbor, MI 48105 863 Phone: +1 313 761 6025 864 E-Mail: acr@del.com 866 Matt Holdrege 867 Lucent Technologies 868 One Ascend Plaza 869 1701 Harbor Bay Parkway 870 Alameda, CA 94502 872 Phone: +1 510 769 6001 873 E-Mail: matt@lucent.com 875 Ignacio Goyret 876 Lucent Technologies 877 One Ascend Plaza 878 1701 Harbor Bay Parkway 879 Alameda, CA 94502 880 Phone: +1 510 769 6001 881 E-Mail: igoyret@lucent.com 883 13. Expiration Date 885 This memo is filed as , and 886 expires February 9, 2000.