idnits 2.17.1 draft-ietf-radius-tunnel-auth-07.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 19 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (June 1999) is 9075 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 754, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 757, but no explicit reference was found in the text -- No information found for draft-ietf-pppext-pptp-R1007 - is the name correct? -- Possible downref: Normative reference to a draft: 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') Summary: 19 errors (**), 0 flaws (~~), 7 warnings (==), 5 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 M. Holdrege 6 Ascend Communications 7 J. Shriver 8 Intel Corporation 9 June 1999 11 RADIUS Attributes for Tunnel Protocol Support 13 1. Status of this Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 The distribution of this memo is unlimited. It is filed as , and expires December 27, 1999. Please send 35 comments to the RADIUS Working Group mailing list (ietf- 36 radius@livingston.com) or to the authors (leifer@del.com, acr@del.com, 37 matt@ascend.com, John.Shriver@intel.com and glennz@microsoft.com). 39 2. Abstract 41 This document defines a set of RADIUS attributes designed to support the 42 provision of compulsory tunneling in dial-up networks. 44 3. Motivation 46 Many applications of tunneling protocols such as L2TP involve dial-up 47 network access. Some, such as the provision of access to corporate 48 intranets via the Internet, are characterized by voluntary tunneling: 49 the tunnel is created at the request of the user for a specific purpose. 50 Other applications involve compulsory tunneling: the tunnel is created 51 without any action from the user and without allowing the user any 52 choice in the matter. In order to provide this functionality, new 53 RADIUS attributes are needed to carry the tunneling information from the 54 RADIUS server to the tunnel end points; this document defines those 55 attributes. Specific recommendations for, and examples of, the 56 application of these attributes for L2TP can be found in draft-ietf- 57 radius-tunnel-imp-XX.txt. 59 4. Specification of Requirements 61 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 62 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 63 described in [14]. 65 5. Attributes 67 Multiple instances of each of the attributes defined below may be 68 included in a single RADIUS packet. In this case, the attributes to be 69 applied to any given tunnel SHOULD all contain the same value in their 70 respective Tag fields; otherwise, the Tag field SHOULD NOT be used. 72 If the RADIUS server returns attributes describing multiple tunnels then 73 the tunnels SHOULD be interpreted by the tunnel initiator as 74 alternatives and the server SHOULD include an instance of the Tunnel- 75 Preference Attribute in the set of Attributes pertaining to each 76 alternative tunnel. Similarly, if the RADIUS client includes multiple 77 sets of tunnel Attributes in an Access-Request packet, all the 78 Attributes pertaining to a given tunnel SHOULD contain the same value in 79 their respective Tag fiels and each set SHOULD include an appropriately 80 valued instance of the Tunnel-Preference Attribute. 82 5.1. Tunnel-Type 84 Description 86 This Attribute indicates the tunneling protocol(s) to be used (in 87 the case of a tunnel initiator) or the the tunneling protocol in 88 use (in the case of a tunnel terminator). It MAY be included in 89 Access-Request, Access-Accept and Accounting-Request packets. If 90 the Tunnel-Type Attribute is present in an Access-Request packet 91 sent from a tunnel initiator, it SHOULD be taken as a hint to the 92 RADIUS server as to the tunnelling protocols supported by the 93 tunnel end-point; the RADIUS server MAY ignore the hint, however. 94 A tunnel initiator is not required to implement any of these 95 tunnel types; if a tunnel initiator receives an Access-Accept 96 packet which contains only unknown or unsupported Tunnel-Types, 97 the tunnel initiator MUST behave as though an Access-Reject had 98 been received instead. 100 If the Tunnel-Type Attribute is present in an Access-Request 101 packet sent from a tunnel terminator, it SHOULD be taken to 102 signify the tunnelling protocol in use. In this case, if the 103 RADIUS server determines that the use of the communicated protocol 104 is not authorized, it MAY return an Access-Reject packet. If a 105 tunnel terminator receives an Access-Accept packet which contains 106 one or more Tunnel-Type Attributes, none of which represent the 107 tunneling protocol in use, the tunnel terminator SHOULD behave as 108 though an Access-Reject had been received instead. 110 A summary of the Tunnel-Type Attribute format is shown below. The 111 fields are transmitted from left to right. 113 0 1 2 3 114 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 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | Type | Length | Tag | Value 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 Value (cont) | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 Type 122 64 for Tunnel-Type 124 Length 125 Always 6. 127 Tag 128 The Tag field is one octet in length and is intended to provide a 129 means of grouping attributes in the same packet which refer to the 130 same tunnel. Valid values for this field are 0x01 through 0x1F, 131 inclusive. If the Tag field is unused, it MUST be zero (0x00). 133 Value 134 The Value field is three octets and contains one of the following 135 values, indicating the type of tunnel to be started. 137 1 Point-to-Point Tunneling Protocol (PPTP) [1] 138 2 Layer Two Forwarding (L2F) [2] 139 3 Layer Two Tunneling Protocol (L2TP) [3] 140 4 Ascend Tunnel Management Protocol (ATMP) [4] 141 5 Virtual Tunneling Protocol (VTP) 142 6 IP Authentication Header in the Tunnel-mode (AH) [5] 143 7 IP-in-IP Encapsulation (IP-IP) [6] 144 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7] 145 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8] 146 10 Generic Route Encapsulation (GRE) [9] 147 11 Bay Dial Virtual Services (DVS) 148 12 IP-in-IP Tunneling [10] 150 5.2. Tunnel-Medium-Type 152 Description 154 The Tunnel-Medium-Type Attribute indicates which transport medium 155 to use when creating a tunnel for those protocols (such as L2TP) 156 that can operate over multiple transports. It MAY be included in 157 both Access-Request and Access-Accept packets; if it is present in 158 an Access-Request packet, it SHOULD be taken as a hint to the 159 RADIUS server as to the tunnel media supported by the tunnel end- 160 point. The RADIUS server MAY ignore the hint, however. 162 A summary of the Tunnel-Medium-Type Attribute format is given below. 163 The fields are transmitted left to right. 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | Tag | Value | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 Value (cont) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 Type 174 65 for Tunnel-Medium-Type 176 Length 177 6 179 Tag 180 The Tag field is one octet in length and is intended to provide a 181 means of grouping attributes in the same packet which refer to the 182 same tunnel. Valid values for this field are 0x01 through 0x1F, 183 inclusive. If the Tag field is unused, it MUST be zero (0x00). 185 Value 186 The Value field is three octets and contains one of the values 187 listed under "Address Family Numbers" in [14]. For the sake of 188 convenience, a relevant excerpt of this list is reproduced below. 190 1 IP (IP version 4) 191 2 IP6 (IP version 6) 192 3 NSAP 193 4 HDLC (8-bit multidrop) 194 5 BBN 1822 195 6 802 (includes all 802 media plus Ethernet "canonical format") 196 7 E.163 (POTS) 197 8 E.164 (SMDS, Frame Relay, ATM) 198 9 F.69 (Telex) 199 10 X.121 (X.25, Frame Relay) 200 11 IPX 201 12 Appletalk 202 13 Decnet IV 203 14 Banyan Vines 204 15 E.164 with NSAP format subaddress 206 5.3. Tunnel-Client-Endpoint 208 Description 210 This Attribute contains the address of the initiator end of the 211 tunnel. It MAY be included in both Access-Request and Access- 212 Accept packets to indicate the address from which a new tunnel is 213 to be initiated. If the Tunnel-Client-Endpoint Attribute is 214 included in an Access-Request packet, the RADIUS server should 215 take the value as a hint; the server is not obligated to honor the 216 hint, however. This Attribute SHOULD be included in Accounting- 217 Request packets which contain Acct-Status-Type attributes with 218 values of either Start or Stop, in which case it indicates the 219 address from which the tunnel was initiated. This Attribute, 220 along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection- 221 ID attributes, may be used to provide a globally unique means to 222 identify a tunnel for accounting and auditing purposes. 224 A summary of the Tunnel-Client-Endpoint Attribute format is shown 225 below. The fields are transmitted from left to right. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Type | Length | Tag | String ... 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Type 234 66 for Tunnel-Client-Endpoint. 236 Length 237 >= 3 239 Tag 240 The Tag field is one octet in length and is intended to provide a 241 means of grouping attributes in the same packet which refer to the 242 same tunnel. If the value of the Tag field is greater than 0x00 243 and less than or equal to 0x1F, it SHOULD be interpreted as 244 indicating which tunnel (of several alternatives) this attribute 245 pertains. If the Tag field is greater than 0x1F, it SHOULD be 246 interpreted as the first byte of the following String field. 248 String 249 The format of the address represented by the String field depends 250 upon the value of the Tunnel-Medium-Type attribute. 252 If Tunnel-Medium-Type is IP (1) or IP6 (2), then this string is 253 either the fully qualified domain name of the tunnel client 254 machine, or it is a "dotted-decimal" IP address. Conformant 255 implementations MUST support the dotted-decimal format and SHOULD 256 support the FQDN format for IP addresses. 258 If Tunnel-Medium-Type is not IP or IP6, this string is a tag 259 referring to configuration data local to the RADIUS client that 260 describes the interface and medium-specific address to use. 262 5.4. Tunnel-Server-Endpoint 264 Description 266 This Attribute indicates the address of the server end of the 267 tunnel. The Tunnel-Server-Endpoint Attribute MAY be included (as 268 a hint to the RADIUS server) in the Access-Request packet and MUST 269 be included in the Access-Accept packet if the initiation of a 270 tunnel is desired. It SHOULD be included in Accounting-Request 271 packets which contain Acct-Status-Type attributes with values of 272 either Start or Stop and which pertain to a tunneled session. 273 This Attribute, along with the Tunnel-Client-Endpoint and Acct- 274 Tunnel-Connection-ID Attributes [11], may be used to provide a 275 globally unique means to identify a tunnel for accounting and 276 auditing purposes. 278 A summary of the Tunnel-Server-Endpoint Attribute format is shown 279 below. The fields are transmitted from left to right. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Type | Length | Tag | String ... 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type 288 67 for Tunnel-Server-Endpoint. 290 Length 291 >= 3 293 Tag 294 The Tag field is one octet in length and is intended to provide a 295 means of grouping attributes in the same packet which refer to the 296 same tunnel. If the value of the Tag field is greater than 0x00 297 and less than or equal to 0x1F, it SHOULD be interpreted as 298 indicating which tunnel (of several alternatives) this attribute 299 pertains. If the Tag field is greater than 0x1F, it SHOULD be 300 interpreted as the first byte of the following String field. 302 String 303 The format of the address represented by the String field depends 304 upon the value of the Tunnel-Medium-Type attribute. 306 If Tunnel-Medium-Type is IP (1) or IP6 (2), then this string is 307 either the fully qualified domain name of the tunnel client 308 machine, or it is a "dotted-decimal" IP address. Conformant 309 implementations MUST support the dotted-decimal format and SHOULD 310 support the FQDN format for IP addresses. 312 If Tunnel-Medium-Type is not IP or IP6, this string is a tag 313 referring to configuration data local to the RADIUS client that 314 describes the interface and medium-specific address to use. 316 5.5. Tunnel-Password 318 Description 320 This Attribute may contain a password to be used to authenticate 321 to a remote server. It may only be included in an Access-Accept 322 packet. 324 A summary of the Tunnel-Password Attribute format is shown below. 326 The fields are transmitted from left to right. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | Tag | Salt 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Salt (cont) | String ... 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Type 337 69 for Tunnel-Password 339 Length 340 >= 3 342 Tag 343 The Tag field is one octet in length and is intended to provide a 344 means of grouping attributes in the same packet which refer to the 345 same tunnel. Valid values for this field are 0x01 through 0x1F, 346 inclusive. If the value of the Tag field is greater than 0x00 and 347 less than or equal to 0x1F, it SHOULD be interpreted as indicating 348 which tunnel (of several alternatives) this attribute pertains; 349 otherwise, the Tag field SHOULD be ignored. 351 Salt 352 The Salt field is two octets in length and is used to ensure the 353 uniqueness of the encryption key used to encrypt each instance of 354 the Tunnel-Password attribute occurring in a given Access-Accept 355 packet. The most significant bit (leftmost) of the Salt field 356 MUST be set (1). The contents of each Salt field in a given 357 Access-Accept packet MUST be unique. 359 String 360 The plaintext String field consists of three logical sub-fields: 361 the Data-Length and Password sub-fields (both of which are 362 required), and the optional Padding sub-field. The Data-Length 363 sub-field is one octet in length and contains the length of the 364 unencrypted Password sub-field. The Password sub-field contains 365 the actual tunnel password. If the combined length (in octets) of 366 the unencrypted Data-Length and Password sub-fields is not an even 367 multiple of 16, then the Padding sub-field MUST be present. If it 368 is present, the length of the Padding sub-field is variable, 369 between 1 and 15 octets. The String field MUST be encrypted as 370 follows, prior to transmission: 372 Construct a plaintext version of the String field by 373 concatenating the Data-Length and Password sub-fields. If 374 necessary, pad the resulting string until its length (in 375 octets) is an even multiple of 16. It is recommended that zero 376 octets (0x00) be used for padding. Call this plaintext P. 378 Call the shared secret S, the pseudo-random 128-bit Request 379 Authenticator (from the corresponding Access-Request packet) R, 380 and the contents of the Salt field A. Break P into 16 octet 381 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 382 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 383 Intermediate values b(1), b(2)...c(i) are required. Encryption 384 is performed in the following manner ('+' indicates 385 concatenation): 387 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 388 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 389 . . 390 . . 391 . . 392 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 394 The resulting encrypted String field will contain 395 c(1)+c(2)+...+c(i). 397 On receipt, the process is reversed to yield the plaintext String. 399 5.6. Tunnel-Private-Group-ID 401 Description 403 This Attribute indicates the group ID for a particular tunneled 404 session. The Tunnel-Private-Group-ID Attribute MAY be included in 405 the Access-Request packet if the tunnel initiator can pre- 406 determine the group resulting from a particular connection and 407 SHOULD be included in the Access-Reply packet if this tunnel 408 session is to be treated as belonging to a particular private 409 group. Private groups may be used to associate a tunneled session 410 with a particular group of users. For example, it may be used to 411 facilitate routing of unregistered IP addresses through a 412 particular interface. It SHOULD be included in Accounting-Request 413 packets which contain Acct-Status-Type attributes with values of 414 either Start or Stop and which pertain to a tunneled session. 416 A summary of the Tunnel-Private-Group-ID Attribute format is shown 417 below. The fields are transmitted from left to right. 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length | Tag | String ... 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 Type 426 81 for Tunnel-Private-Group-ID. 428 Length 429 >= 3 431 Tag 432 The Tag field is one octet in length and is intended to provide a 433 means of grouping attributes in the same packet which refer to the 434 same tunnel. If the value of the Tag field is greater than 0x00 435 and less than or equal to 0x1F, it SHOULD be interpreted as 436 indicating which tunnel (of several alternatives) this attribute 437 pertains. If the Tag field is greater than 0x1F, it SHOULD be 438 interpreted as the first byte of the following String field. 440 String 441 This field must be present. The group is represented by the 442 String field. There is no restriction on the format of group IDs. 444 5.7. Tunnel-Assignment-ID 446 Description 448 This Attribute is used to indicate to the tunnel initiator the 449 particular tunnel to which a session is to be assigned. Some 450 tunneling protocols, such as PPTP and L2TP, allow for sessions 451 between the same two tunnel endpoints to be multiplexed over the 452 same tunnel and also for a given session to utilize its own 453 dedicated tunnel. This attribute provides a mechanism for RADIUS 454 to be used to inform the tunnel initiator (e.g. PAC, LAC) whether 455 to assign the session to a multiplexed tunnel or to a separate 456 tunnel. Furthermore, it allows for sessions sharing multiplexed 457 tunnels to be assigned to different multiplexed tunnels. 459 A particular tunneling implementation may assign differing 460 characteristics to particular tunnels. For example, different 461 tunnels may be assigned different QOS parameters. Such tunnels 462 may be used to carry either individual or multiple sessions. The 463 Tunnel-Assignment-ID attribute thus allows the RADIUS server to 464 indicate that a particular session is to be assigned to a tunnel 465 that provides an appropriate level of service. It is expected 466 that any QOS-related RADIUS tunneling attributes defined in the 467 future that accompany this attribute will be associated by the 468 tunnel initiator with the ID given by this attribute. In the 469 meantime, any semantic given to a particular ID string is a matter 470 left to local configuration in the tunnel initiator. 472 The Tunnel-Assignment-ID attribute is of significance only to 473 RADIUS and the tunnel initiator. The ID it specifies is intended 474 to be of only local use to RADIUS and the tunnel initiator. The 475 ID assigned by the tunnel initiator is not conveyed to the tunnel 476 peer. 478 This attribute MAY be included in the Access-Accept. The tunnel 479 initiator receiving this attribute MAY choose to ignore it and 480 assign the session to an arbitrary multiplexed or non-multiplexed 481 tunnel between the desired endpoints. This attribute SHOULD also 482 be included in Accounting-Request packets which contain Acct- 483 Status-Type attributes with values of either Start or Stop and 484 which pertain to a tunneled session. 486 If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, 487 then it should assign a session to a tunnel in the following 488 manner: 490 If this attribute is present and a tunnel exists between the 491 specified endpoints with the specified ID, then the session 492 should be assigned to that tunnel. 494 If this attribute is present and no tunnel exists between the 495 specified endpoints with the specified ID, then a new tunnel 496 should be established for the session and the specified ID 497 should be associated with the new tunnel. 499 If this attribute is not present, then the session is assigned 500 to an unnamed tunnel. If an unnamed tunnel does not yet exist 501 between the specified endpoints then it is established and used 502 for this and subsequent sessions established without the 503 Tunnel-Assignment-ID attribute. A tunnel initiator MUST NOT 504 assign a session for which a Tunnel-Assignment-ID Attribute was 505 not specified to a named tunnel (i.e. one that was initiated by 506 a session specifying this attribute). 508 Note that the same ID may be used to name different tunnels if 509 such tunnels are between different endpoints. 511 A summary of the Tunnel-Assignment-ID Attribute format is shown 512 below. The fields are transmitted from left to right. 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Type | Length | Tag | String ... 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Type 521 82 for Tunnel-Assignment-ID. 523 Length 524 > 3 526 Tag 527 The Tag field is one octet in length and is intended to provide a 528 means of grouping attributes in the same packet which refer to the 529 same tunnel. If the value of the Tag field is greater than 0x00 530 and less than or equal to 0x1F, it SHOULD be interpreted as 531 indicating which tunnel (of several alternatives) this attribute 532 pertains. If the Tag field is greater than 0x1F, it SHOULD be 533 interpreted as the first byte of the following String field. 535 String 536 This field must be present. The tunnel ID is represented by the 537 String field. There is no restriction on the format of the ID. 539 5.8. Tunnel-Preference 541 Description 543 If more than one set of tunneling attributes is returned by the 544 RADIUS server to the tunnel initiator, this Attribute SHOULD be 545 included in each set to indicate the relative preference assigned 546 to each tunnel. For example, suppose that Attributes describing 547 two tunnels are returned by the server, one with a Tunnel-Type of 548 PPTP and the other with a Tunnel-Type of L2TP. If the tunnel 549 initiator supports only one of the Tunnel-Types returned, it will 550 initiate a tunnel of that type. If, however, it supports both 551 tunnel protocols, it SHOULD use the value of the Tunnel-Preference 552 Attribute to decide which tunnel should be started. The tunnel 553 having the numerically lowest value in the Value field of this 554 Attribute SHOULD be given the highest preference. The values 555 assigned to two or more instances of the Tunnel-Preference 556 Attribute within a given Access-Accept packet MAY be identical. 557 In this case, the tunnel initiator SHOULD use locally configured 558 metrics to decide which set of attributes to use. This Attribute 559 MAY be included (as a hint to the server) in Access-Request 560 packets, but the RADIUS server is not required to honor this hint. 562 A summary of the Tunnel-Preference Attribute format is shown below. 563 The fields are transmitted from left to right. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Tag | Value 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Value (cont) | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Type 574 83 for Tunnel-Preference 576 Length 577 Always 6. 579 Tag 580 The Tag field is one octet in length and is intended to provide a 581 means of grouping attributes in the same packet which refer to the 582 same tunnel. Valid values for this field are 0x01 through 0x1F, 583 inclusive. If the Tag field is unused, it MUST be zero (0x00). 585 Value 586 The Value field is three octets in length and indicates the 587 preference to be given to the tunnel to which it refers; higher 588 preference is given to lower values, with 0x000000 being most 589 preferred and 0xFFFFFF least preferred. 591 5.9. Tunnel-Client-Auth-ID 593 Description 595 This Attribute specifies the name used by the tunnel initiator 596 during the authentication phase of tunnel establishment. The 597 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 598 RADIUS server) in the Access-Request packet, and MUST be included 599 in the Access-Request packet if an authentication name other than 600 the default is desired. This Attribute SHOULD be included in 601 Accounting-Request packets which contain Acct-Status-Type 602 attributes with values of either Start or Stop and which pertain 603 to a tunneled session. 605 A summary of the Tunnel-Client-Auth-ID Attribute format is shown 606 below. The fields are transmitted from left to right. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Type | Length | Tag | String ... 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 Type 615 ?? for Tunnel-Client-Auth-ID. 617 Length 618 > 3 620 Tag 621 The Tag field is one octet in length and is intended to provide a 622 means of grouping attributes in the same packet which refer to the 623 same tunnel. If the value of the Tag field is greater than 0x00 624 and less than or equal to 0x1F, it SHOULD be interpreted as 625 indicating which tunnel (of several alternatives) this attribute 626 pertains. If the Tag field is greater than 0x1F, it SHOULD be 627 interpreted as the first byte of the following String field. 629 String 630 This field must be present. The String field contains the 631 authentication name of the tunnel initiator. The authentication 632 name SHOULD be represented in the UTF-8 charset. 634 5.10. Tunnel-Server-Auth-ID 636 Description 638 This Attribute specifies the name used by the tunnel terminator 639 during the authentication phase of tunnel establishment. The 640 Tunnel-Client-Auth-ID Attribute MAY be included (as a hint to the 641 RADIUS server) in the Access-Request packet, and MUST be included 642 in the Access-Request packet if an authentication name other than 643 the default is desired. This Attribute SHOULD be included in 644 Accounting-Request packets which contain Acct-Status-Type 645 attributes with values of either Start or Stop and which pertain 646 to a tunneled session. 648 A summary of the Tunnel-Server-Auth-ID Attribute format is shown 649 below. The fields are transmitted from left to right. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | Tag | String ... 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 Type 657 ?? for Tunnel-Server-Auth-ID. 659 Length 660 > 3 662 Tag 663 The Tag field is one octet in length and is intended to provide a 664 means of grouping attributes in the same packet which refer to the 665 same tunnel. If the value of the Tag field is greater than 0x00 666 and less than or equal to 0x1F, it SHOULD be interpreted as 667 indicating which tunnel (of several alternatives) this attribute 668 pertains. If the Tag field is greater than 0x1F, it SHOULD be 669 interpreted as the first byte of the following String field. 671 String 672 This field must be present. The String field contains the 673 authentication name of the tunnel terminator. The authentication 674 name SHOULD be represented in the UTF-8 charset. 676 6. Table of Attributes 678 The following table provides a guide to which of the above attributes 679 may be found in which kinds of packets, and in what quantity. 681 Request Accept Reject Challenge Acct-Request # Attribute 682 0+ 0+ 0 0 0-1 64 Tunnel-Type 683 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 684 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 685 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 686 0 0+ 0 0 0 69 Tunnel-Password 687 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 688 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 689 0+ 0+ 0 0 0 83 Tunnel-Preference 690 0+ 0+ 0 0 0-1 ?? Tunnel-Client-Auth-ID 691 0+ 0+ 0 0 0-1 ?? Tunnel-Server-Auth-ID 693 The following table defines the meaning of the above table entries. 695 0 This attribute MUST NOT be present in packet. 696 0+ Zero or more instances of this attribute MAY be present in packet. 697 0-1 Zero or one instance of this attribute MAY be present in packet. 699 7. Security Considerations 701 The Tunnel-Password Attribute may contain information which should only 702 be known to a tunnel endpoint. However, the method used to hide the 703 value of the attribute is such that intervening RADIUS proxies will have 704 knowledge of the contents. For this reason, the Tunnel-Password 705 Attribute SHOULD NOT be included in Access-Accept packets which may pass 706 through (relatively) untrusted RADIUS proxies. In addition, the Tunnel- 707 Password Attribute SHOULD NOT be returned to an unauthenticated client; 708 if the corresponding Access-Request packet did not contain a verified 709 instance of the Signature Attribute [15], the Access-Accept packet 710 SHOULD NOT contain an instance of the Tunnel-Password Attribute. 712 Tunnel protocols offer various levels of security, from none (e.g., 713 PPTP) to strong (e.g., IPSec). Note, however, that in the compulsory 714 tunneling case any security measures in place only apply to traffic 715 between the tunnel endpoints. In particular, end-users SHOULD NOT rely 716 upon the security of the tunnel to protect their data; encryption and/or 717 integrity protection of tunneled traffic MUST NOT be considered as a 718 replacement for end-to-end security. 720 8. References 722 [1] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol -- PPTP", 723 draft-ietf-pppext-pptp-R1007.txt (work in progress), April 1999 725 [2] Valencia, A., Littlewood, M. and Kolar, T., "Cisco Layer Two 726 Forwarding (Protocol) 'L2F'", RFC 2341, May 1998 728 [3] Valencia, A., et al., "Layer Two Tunnelling Protocol (L2TP)", work 729 in progress, draft-ietf-pppext-l2tp-16.txt, June 1999 731 [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 732 February 1997 734 [5] Kent, S. and Atkinson, R., "Security Architecture for the Internet 735 Protocol", RFC 2401, November 1998 737 [6] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 739 [7] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 740 1996 742 [8] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 743 August 1995 745 [9] Hanks, S., et. al., "Generic Routing Encapsulation (GRE)", RFC 746 1701, October 1994 748 [10] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 750 [11] Zorn, G. and Mitton, D., "RADIUS Accounting Modifications for 751 Tunnel Protocol Support", draft-ietf-radius-tunnel-acct-03.txt 752 (work in progress), April 1999 754 [12] Rigney, C., et. al., "Remote Authentication Dialin User Service 755 (RADIUS)", RFC 2138, April 1997 757 [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement 758 Levels", BCP 14, RFC 2119, March 1997 760 [14] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, 761 October 1994 763 [15] Rigney, C. and Willats, S., "RADIUS Extensions", draft-ietf-radius- 764 ext-04.txt (work in progress), May 1999 766 9. Acknowledgements 768 Thanks to Dave Mitton for pointing out a nasty circular dependency in 769 the original Tunnel-Password attribute definition and (in no particular 770 order) to Kory Hamzeh, Bertrand Buclin, Andy Valencia, Bill Westfield, 771 Kris Michielsen, Gurdeep Singh Pall, Ran Atkinson, Aydin Edguer, and 772 Bernard Aboba for useful input and review. 774 10. Chair's Address 776 The RADIUS Working Group can be contacted via the current chair: 778 Carl Rigney 779 Livingston Enterprises 780 4464 Willow Road 781 Pleasanton, California 94588 783 Phone: +1 510 426 0770 784 E-Mail: cdr@livingston.com 786 11. Authors' Addresses 788 Questions about this memo can also be directed to: 790 Glen Zorn 791 Microsoft Corporation 792 One Microsoft Way 793 Redmond, Washington 98052 795 Phone: +1 425 703 1559 796 E-Mail: gwz@acm.org 798 Dory Leifer 799 Ascend Communications 800 1678 Broadway 801 Ann Arbor, MI 48105 803 Phone: +1 313 747 6152 804 E-Mail: leifer@ascend.com 806 John Shriver 807 Intel Corporation 808 28 Crosby Drive 809 Bedford, MA 01730 811 Phone: +1 781 687 1329 812 E-Mail: John.Shriver@intel.com 814 Allan Rubens 815 Ascend Communications 816 1678 Broadway 817 Ann Arbor, MI 48105 819 Phone: +1 313 761 6025 820 E-Mail: acr@del.com 822 Matt Holdrege 823 Ascend Communications 824 One Ascend Plaza 825 1701 Harbor Bay Parkway 826 Alameda, CA 94502 828 Phone: +1 510 769 6001 829 E-Mail: matt@ascend.com 831 12. Expiration Date 833 This memo is filed as , and 834 expires December 27, 1999.