idnits 2.17.1 draft-ietf-radius-tunnel-auth-06.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 179 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** 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: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...This document...' == Line 15 has weird spacing: '...as, and its...' == Line 20 has weird spacing: '...and may be ...' == Line 21 has weird spacing: '...ference mater...' == Line 24 has weird spacing: '...To learn the...' == (174 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). (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 (September 1998) is 9355 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: '13' is defined on line 659, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '1') ** Downref: Normative reference to an Historic draft: draft-valencia-l2f (ref. '2') == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-11 ** Downref: Normative reference to an Informational RFC: RFC 2107 (ref. '4') -- Possible downref: Normative reference to a draft: ref. '5' -- Unexpected draft version: The latest known version of draft-ietf-ipsec-auth-header is -06, but you're referring to -07. ** Obsolete normative reference: RFC 1827 (ref. '9') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '10') ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '11') == Outdated reference: A later version (-04) exists of draft-ietf-radius-tunnel-acct-02 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-acct (ref. '12') ** Obsolete normative reference: RFC 2138 (ref. '13') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 1700 (ref. '15') (Obsoleted by RFC 3232) == Outdated reference: A later version (-06) exists of draft-ietf-radius-ext-01 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-ext (ref. '16') Summary: 22 errors (**), 0 flaws (~~), 13 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 Ascend Communications 6 J. Shriver 7 Shiva Corporation 8 September 1998 10 RADIUS Attributes for Tunnel Protocol Support 12 1. Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working docu- 15 ments of the Internet Engineering Task Force (IETF), its areas, and its 16 working groups. Note that other groups may also distribute working doc- 17 uments as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 27 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 29 The distribution of this memo is unlimited. It is filed as , and expires April 5, 1999. Please send com- 31 ments to the RADIUS Working Group mailing list (ietf-radius@liv- 32 ingston.com) or to the authors (leifer@del.com, acr@del.com, 33 jas@shiva.com and glennz@microsoft.com). 35 2. Abstract 37 This document defines a set of RADIUS attributes designed to support the 38 provision of compulsory tunneling in dial-up networks. 40 3. Motivation 42 Many applications of tunneling protocols such as PPTP and L2TP involve 43 dial-up network access. Some, such as the provision of secure access to 44 corporate intranets via the Internet, are characterized by voluntary 45 tunneling: the tunnel is created at the request of the user for a spe- 46 cific purpose. Other applications involve compulsory tunneling: the 47 tunnel is created without any action from the user and without allowing 48 the user any choice in the matter. Examples of applications that might 49 be implemented using compulsory tunnels are Internet software upgrade 50 servers, software registration servers and banking services. These are 51 all services which, without compulsory tunneling, would probably be pro- 52 vided using dedicated networks or at least dedicated network access 53 servers (NAS), since they are characterized by the need to limit user 54 access to specific hosts. Given the existence of widespread support for 55 compulsory tunneling, however, these types of services could be accessed 56 via any Internet service provider (ISP). The most popular means of 57 authorizing dial-up network users today is through the RADIUS protocol. 58 The use of RADIUS allows the dial-up users' authorization and authenti- 59 cation data to be maintained in a central location, rather than on each 60 NAS. It makes sense to use RADIUS to centrally administer compulsory 61 tunneling, since RADIUS is widely deployed and was designed to carry 62 this type of information. In order to provide this functionality, new 63 RADIUS attributes are needed to carry the tunneling information from the 64 RADIUS server to the tunnel initiator; this document defines those 65 attributes. Specific recommendations for, and examples of, the applica- 66 tion of these attributes for the L2TP and PPTP protocols can be found in 67 draft-ietf-radius-tunnel-imp-XX.txt. 69 4. Specification of Requirements 71 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 72 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 73 described in [14]. 75 5. Attributes 77 Multiple instances of each of the attributes defined below may be 78 included in a single RADIUS packet. In this case, the attributes to be 79 applied to any given tunnel SHOULD all contain the same value in their 80 respective Tag fields; otherwise, the Tag field SHOULD NOT be used. 82 If the RADIUS server returns attributes describing multiple tunnels then 83 the tunnels SHOULD be interpreted by the tunnel initiator as alterna- 84 tives and the server SHOULD include an instance of the Tunnel-Preference 85 Attribute in the set of Attributes pertaining to each alternative 86 tunnel. Similarly, if the RADIUS client includes multiple sets of tun- 87 nel Attributes in an Access-Request packet, all the Attributes pertain- 88 ing to a given tunnel SHOULD contain the same value in their respective 89 Tag fiels and each set SHOULD include an appropriately valued instance 90 of the Tunnel-Preference Attribute. 92 5.1. Tunnel-Type 94 Description 96 This Attribute indicates the tunneling protocol(s) to be used. It 97 MAY be included in Access-Request, Access-Accept and Accounting- 98 Request packets. If the Tunnel-Type Attribute is present in an 99 Access-Request packet, it SHOULD be taken as a hint to the RADIUS 100 server as to the tunnelling protocols supported by the tunnel ini- 101 tiator; the RADIUS server MAY ignore the hint, however. A tunnel 102 initiator is not required to implement any of these tunnel types; 103 if a tunnel initiator receives an Access-Accept packet which con- 104 tains only unknown or unsupported Tunnel-Types, the tunnel initia- 105 tor MUST behave as though an Access-Reject had been received 106 instead. 108 A summary of the Tunnel-Type Attribute format is shown below. The 109 fields are transmitted from left to right. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | Type | Length | Tag | Value 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 Value (cont) | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 Type 120 64 for Tunnel-Type 122 Length 123 Always 6. 125 Tag 126 The Tag field is one octet in length and is intended to provide a 127 means of grouping attributes in the same packet which refer to the 128 same tunnel. Valid values for this field are 0x01 through 0x1F, 129 inclusive. If the Tag field is unused, it MUST be zero. 131 Value 132 The Value field is three octets and contains one of the following 133 values, indicating the type of tunnel to be started. 135 1 Point-to-Point Tunneling Protocol (PPTP) [1] 136 2 Layer Two Forwarding (L2F) [2] 137 3 Layer Two Tunneling Protocol (L2TP) [3] 138 4 Ascend Tunnel Management Protocol (ATMP) [4] 139 5 Virtual Tunneling Protocol (VTP) [5] 140 6 IP Authentication Header in the Tunnel-mode (AH) [6] 141 7 IP-in-IP Encapsulation (IP-IP) [7] 142 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8] 143 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [9] 144 10 Generic Route Encapsulation (GRE) [10] 145 11 Bay Dial Virtual Services (DVS) 146 12 IP-in-IP Tunneling [11] 148 5.2. Tunnel-Medium-Type 150 Description 152 The Tunnel-Medium-Type Attribute indicates which transport medium 153 to use when creating a tunnel for those protocols (such as L2TP) 154 that can operate over multiple transports. It MAY be included in 155 both Access-Request and Access-Accept packets; if it is present in 156 an Access-Request packet, it SHOULD be taken as a hint to the 157 RADIUS server as to the tunnel mediums supported by the tunnel 158 initiator. The RADIUS server MAY ignore the hint, however. 160 A summary of the Tunnel-Medium-Type Attribute format is given below. 161 The fields are transmitted left to right. 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type | Length | Tag | Value | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Value (cont) | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Type 172 65 for Tunnel-Medium-Type 174 Length 175 6 177 Tag 178 The Tag field is one octet in length and is intended to provide a 179 means of grouping attributes in the same packet which refer to the 180 same tunnel. Valid values for this field are 0x01 through 0x1F, 181 inclusive. If the Tag field is unused, it MUST be zero (0x0000). 183 Value 184 The Value field is three octets and contains one of the values 185 listed under "Address Family Numbers" in [15]. For the sake of 186 convenience, a relevant excerpt of this list is reproduced below. 188 1 IP (IP version 4) 189 2 IP6 (IP version 6) 190 3 NSAP 191 4 HDLC (8-bit multidrop) 192 5 BBN 1822 193 6 802 (includes all 802 media plus Ethernet "canonical format") 194 7 E.163 (POTS) 195 8 E.164 (SMDS, Frame Relay, ATM) 196 9 F.69 (Telex) 197 10 X.121 (X.25, Frame Relay) 198 11 IPX 199 12 Appletalk 200 13 Decnet IV 201 14 Banyan Vines 202 15 E.164 with NSAP format subaddress 204 5.3. Tunnel-Client-Endpoint 206 Description 208 This Attribute contains the address of the initiator end of the 209 tunnel. It MAY be included in both Access-Request and Access- 210 Accept packets to indicate the address from which a new tunnel is 211 to be initiated. If the Tunnel-Client-Endpoint Attribute is 212 included in an Access-Request packet, the RADIUS server should 213 take the value as a hint; the server is not obligated to honor the 214 hint, however. It SHOULD be included in Accounting-Request pack- 215 ets which contain Acct-Status-Type attributes with values of 216 either Start or Stop, in which case it indicates the address from 217 which the tunnel was initiated. This Attribute, along with the 218 Tunnel-Server-Endpoint and Acct-Tunnel-Connection-ID attributes, 219 may be used to provide a globally unique means to identify a tun- 220 nel for accounting and auditing purposes. 222 A summary of the Tunnel-Client-Endpoint Attribute format is shown 223 below. The fields are transmitted from left to right. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Tag | String ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Type 231 66 for Tunnel-Client-Endpoint. 233 Length 234 >= 3 236 Tag 237 The Tag field is one octet in length and is intended to provide a 238 means of grouping attributes in the same packet which refer to the 239 same tunnel. Valid values for this field are 0x01 through 0x1F, 240 inclusive. If the value of the Tag field is less than or equal to 241 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- 242 eral alternatives) this attribute pertains; otherwise, it SHOULD 243 be interpreted as the first byte of the following String field. 245 String 246 The format of the address represented by the String field depends 247 upon the value of the Tunnel-Medium-Type attribute. 249 If Tunnel-Medium-Type is IP (1) or IP6 (2), then this string is 250 either the fully qualified domain name of the tunnel client 251 machine, or it is a "dotted-decimal" IP address. Conformant 252 implementations MUST support the dotted-decimal format and SHOULD 253 support the FQDN format for IP addresses. 255 If Tunnel-Medium-Type is not IP or IP6, this string is a tag 256 referring to configuration data local to the RADIUS client that 257 describes the interface and medium-specific address to use. 259 5.4. Tunnel-Server-Endpoint 261 Description 263 This Attribute indicates the address of the server end of the tun- 264 nel. The Tunnel-Server-Endpoint Attribute MAY be included (as a 265 hint to the RADIUS server) in the Access-Request packet and MUST 266 be included in the Access-Accept packet if the initiation of a 267 tunnel is desired. It SHOULD be included in Accounting-Request 268 packets which contain Acct-Status-Type attributes with values of 269 either Start or Stop and which pertain to a tunneled session. 270 This Attribute, along with the Tunnel-Client-Endpoint and Acct- 271 Tunnel-Connection-ID Attributes [12], may be used to provide a 272 globally unique means to identify a tunnel for accounting and 273 auditing purposes. 275 A summary of the Tunnel-Server-Endpoint Attribute format is shown 276 below. The fields are transmitted from left to right. 278 0 1 2 3 279 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 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Type | Length | Tag | String ... 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Type 285 67 for Tunnel-Server-Endpoint. 287 Length 288 >= 3 290 Tag 291 The Tag field is one octet in length and is intended to provide a 292 means of grouping attributes in the same packet which refer to the 293 same tunnel. Valid values for this field are 0x01 through 0x1F, 294 inclusive. If the value of the Tag field is less than or equal to 295 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- 296 eral alternatives) this attribute pertains; otherwise, it SHOULD 297 be interpreted as the first byte of the following String field. 299 String 300 The format of the address represented by the String field depends 301 upon the value of the Tunnel-Medium-Type attribute. 303 If Tunnel-Medium-Type is IP (1) or IP6 (2), then this string is 304 either the fully qualified domain name of the tunnel client 305 machine, or it is a "dotted-decimal" IP address. Conformant 306 implementations MUST support the dotted-decimal format and SHOULD 307 support the FQDN format for IP addresses. 309 If Tunnel-Medium-Type is not IP or IP6, this string is a tag 310 referring to configuration data local to the RADIUS client that 311 describes the interface and medium-specific address to use. 313 5.5. Tunnel-Password 315 Description 317 This Attribute may contain a password to be used to authenticate 318 to a remote server. It may only be included in an Access-Accept 319 packet. 321 A summary of the Tunnel-Password Attribute format is shown below. 322 The fields are transmitted from left to right. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Type | Length | Tag | Salt 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Salt (cont) | String ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Type 333 69 for Tunnel-Password 335 Length 336 >= 3 338 Tag 339 The Tag field is one octet in length and is intended to provide a 340 means of grouping attributes in the same packet which refer to the 341 same tunnel. Valid values for this field are 0x01 through 0x1F, 342 inclusive. If the value of the Tag field is less than or equal to 343 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- 344 eral alternatives) this attribute pertains; otherwise, it SHOULD 345 be ignored. 347 Salt 348 The Salt field is two octets in length and is used to ensure the 349 uniqueness of the encryption key used to encrypt each instance of 350 the Tunnel-Password attribute occurring in a given Access-Accept 351 packet. The most significant bit (leftmost) of the Salt field 352 MUST be set (1). The contents of each Salt field in a given 353 Access-Accept packet MUST be unique. 355 String 356 The plaintext String field consists of three logical sub-fields: 357 the Data-Length and Password sub-fields (both of which are 358 required), and the optional Padding sub-field. The Data-Length 359 sub-field is one octet in length and contains the length of the 360 unencrypted Password sub-field. The Password sub-field contains 361 the actual tunnel password. If the combined length (in octets) of 362 the unencrypted Data-Length and Password sub-fields is not an even 363 multiple of 16, then the Padding sub-field MUST be present. If it 364 is present, the length of the Padding sub-field is variable, 365 between 1 and 15 octets. The String field MUST be encrypted as 366 follows, prior to transmission: 368 Construct a plaintext version of the String field by concate- 369 nating the Data-Length and Password sub-fields. If necessary, 370 pad the resulting string until its length (in octets) is an 371 even multiple of 16. It is recommended that zero octets (0x00) 372 be used for padding. Call this plaintext P. 374 Call the shared secret S, the pseudo-random 128-bit Request 375 Authenticator (from the corresponding Access-Request packet) R, 376 and the contents of the Salt field A. Break P into 16 octet 377 chunks p(1), p(2)...p(i), where i = len(P)/16. Call the 378 ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. 379 Intermediate values b(1), b(2)...c(i) are required. Encryption 380 is performed in the following manner ('+' indicates concatena- 381 tion): 383 b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) 384 b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) 385 . . 386 . . 387 . . 388 b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) 390 The resulting encrypted String field will contain 391 c(1)+c(2)+...+c(i). 393 On receipt, the process is reversed to yield the plaintext String. 395 5.6. Tunnel-Private-Group-ID 397 Description 399 This Attribute indicates the group ID for a particular tunneled 400 session. The Tunnel-Private-Group-ID Attribute MAY be included in 401 the Access-Request packet if the tunnel initiator can pre-deter- 402 mine the group resulting from a particular connection and SHOULD 403 be included in the Access-Reply packet if this tunnel session is 404 to be treated as belonging to a particular private group. Private 405 groups may be used to associate a tunneled session with a particu- 406 lar group of users. For example, it may be used to facilitate 407 routing of unregistered IP addresses through a particular inter- 408 face. It SHOULD be included in Accounting-Request packets which 409 contain Acct-Status-Type attributes with values of either Start or 410 Stop and which pertain to a tunneled session. 412 A summary of the Tunnel-Private-Group-ID Attribute format is shown 413 below. The fields are transmitted from left to right. 415 0 1 2 3 416 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 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Type | Length | Tag | String ... 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Type 421 81 for Tunnel-Private-Group-ID. 423 Length 424 >= 3 426 Tag 427 The Tag field is one octet in length and is intended to provide a 428 means of grouping attributes in the same packet which refer to the 429 same tunnel. Valid values for this field are 0x01 through 0x1F, 430 inclusive. If the value of the Tag field is less than or equal to 431 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- 432 eral alternatives) this attribute pertains; otherwise, it SHOULD 433 be interpreted as the first byte of the following String field. 435 String 436 This field must be present. The group is represented by the 437 String field. There is no restriction on the format of group IDs. 439 5.7. Tunnel-Assignment-ID 441 Description 443 This Attribute is used to indicate to the tunnel initiator the 444 particular tunnel to which a session is to be assigned. Some tun- 445 neling protocols, such as PPTP and L2TP, allow for sessions 446 between the same two tunnel endpoints to be multiplexed over the 447 same tunnel and also for a given session to utilize its own dedi- 448 cated tunnel. This attribute provides a mechanism for RADIUS to 449 be used to inform the tunnel initiator (e.g. PAC, LAC) whether to 450 assign the session to a multiplexed tunnel or to a separate tun- 451 nel. Furthermore, it allows for sessions sharing multiplexed tun- 452 nels to be assigned to different multiplexed tunnels. 454 A particular tunneling implementation may assign differing charac- 455 teristics to particular tunnels. For example, different tunnels 456 may be assigned different QOS parameters. Such tunnels may be 457 used to carry either individual or multiple sessions. The Tunnel- 458 Assignment-ID attribute thus allows the RADIUS server to indicate 459 that a particular session is to be assigned to a tunnel that pro- 460 vides an appropriate level of service. It is expected that any 461 QOS-related RADIUS tunneling attributes defined in the future that 462 accompany this attribute will be associated by the tunnel initia- 463 tor with the ID given by this attribute. In the meantime, any 464 semantic given to a particular ID string is a matter left to local 465 configuration in the tunnel initiator. 467 The Tunnel-Assignment-ID attribute is of significance only to 468 RADIUS and the tunnel initiator. The ID it specifies is intended 469 to be of only local use to RADIUS and the tunnel initiator. The 470 ID assigned by the tunnel initiator is not conveyed to the tunnel 471 peer. 473 This attribute MAY be included in the Access-Accept. The tunnel 474 initiator receiving this attribute MAY choose to ignore it and 475 assign the session to an arbitrary multiplexed or non-multiplexed 476 tunnel between the desired endpoints. This attribute SHOULD also 477 be included in Accounting-Request packets which contain Acct-Sta- 478 tus-Type attributes with values of either Start or Stop and which 479 pertain to a tunneled session. 481 If a tunnel initiator supports the Tunnel-Assignment-ID Attribute, 482 then it should assign a session to a tunnel in the following man- 483 ner: 485 If this attribute is present and a tunnel exists between the 486 specified endpoints with the specified ID, then the session 487 should be assigned to that tunnel. 489 If this attribute is present and no tunnel exists between the 490 specified endpoints with the specified ID, then a new tunnel 491 should be established for the session and the specified ID 492 should be associated with the new tunnel. 494 If this attribute is not present, then the session is assigned 495 to an unnamed tunnel. If an unnamed tunnel does not yet exist 496 between the specified endpoints then it is established and used 497 for this and subsequent sessions established without the Tun- 498 nel-Assignment-ID attribute. A tunnel initiator MUST NOT 499 assign a session for which a Tunnel-Assignment-ID Attribute was 500 not specified to a named tunnel (i.e. one that was initiated by 501 a session specifying this attribute). 503 Note that the same ID may be used to name different tunnels if 504 such tunnels are between different endpoints. 506 A summary of the Tunnel-Assignment-ID Attribute format is shown 507 below. The fields are transmitted from left to right. 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Type | Length | Tag | String ... 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 Type 515 82 for Tunnel-Assignment-ID. 517 Length 518 > 3 520 Tag 521 The Tag field is one octet in length and is intended to provide a 522 means of grouping attributes in the same packet which refer to the 523 same tunnel. Valid values for this field are 0x01 through 0x1F, 524 inclusive. If the value of the Tag field is less than or equal to 525 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- 526 eral alternatives) this attribute pertains; otherwise, it SHOULD 527 be interpreted as the first byte of the following String field. 529 String 530 This field must be present. The tunnel ID is represented by the 531 String field. There is no restriction on the format of the ID. 533 5.8. Tunnel-Preference 535 Description 537 If more than one set of tunneling attributes is returned by the 538 RADIUS server to the tunnel initiator, this Attribute SHOULD be 539 included in each set to indicate the relative preference assigned 540 to each tunnel. For example, suppose that Attributes describing 541 two tunnels are returned by the server, one with a Tunnel-Type of 542 PPTP and the other with a Tunnel-Type of L2TP. If the tunnel ini- 543 tiator supports only one of the Tunnel-Types returned, it will 544 initiate a tunnel of that type. If, however, it supports both 545 tunnel protocols, it SHOULD use the value of the Tunnel-Preference 546 Attribute to decide which tunnel should be started. The tunnel 547 having the numerically lowest value in the Value field of this 548 Attribute SHOULD be given the highest preference. The values 549 assigned to two or more instances of the Tunnel-Preference 550 Attribute within a given Access-Accept packet MAY be identical. 551 In this case, the tunnel initiator SHOULD use locally configured 552 metrics to decide which set of attributes to use. This Attribute 553 MAY be included (as a hint to the server) in Access-Request pack- 554 ets, but the RADIUS server is not required to honor this hint. 556 A summary of the Tunnel-Preference Attribute format is shown below. 557 The fields are transmitted from left to right. 559 0 1 2 3 560 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | Tag | Value 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Value (cont) | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 Type 569 83 for Tunnel-Preference 571 Length 572 Always 6. 574 Tag 575 The Tag field is one octet in length and is intended to provide a 576 means of grouping attributes in the same packet which refer to the 577 same tunnel. Valid values for this field are 0x01 through 0x1F, 578 inclusive. If the Tag field is unused, it MUST be zero. 580 Value 581 The Value field is three octets in length and indicates the pref- 582 erence to be given to the tunnel to which it refers; higher pref- 583 erence is given to lower values, with 0x000000 being most pre- 584 ferred and 0xFFFFFF least preferred. 586 6. Table of Attributes 588 The following table provides a guide to which of the above attributes 589 may be found in which kinds of packets, and in what quantity. 591 Request Accept Reject Challenge Acct-Request # Attribute 592 0+ 0+ 0 0 0-1 64 Tunnel-Type 593 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 594 0+ 0+ 0 0 0-1 66 Tunnel-Client-Endpoint 595 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 596 0 0+ 0 0 0 69 Tunnel-Password 597 0+ 0+ 0 0 0-1 81 Tunnel-Private-Group-ID 598 0 0+ 0 0 0-1 82 Tunnel-Assignment-ID 599 0+ 0+ 0 0 0 83 Tunnel-Preference 601 The following table defines the meaning of the above table entries. 603 0 This attribute MUST NOT be present in packet. 604 0+ Zero or more instances of this attribute MAY be present in packet. 605 0-1 Zero or one instance of this attribute MAY be present in packet. 607 7. Security Considerations 609 The Tunnel-Password Attribute may contain information which should only 610 be known to a tunnel endpoint. However, the method used to hide the 611 value of the attribute is such that intervening RADIUS proxies will have 612 knowledge of the contents. For this reason, the Tunnel-Password 613 Attribute SHOULD NOT be included in Access-Accept packets which may pass 614 through (relatively) untrusted RADIUS proxies. In addition, the Tunnel- 615 Password Attribute SHOULD NOT be returned to an unauthenticated client; 616 if the corresponding Access-Request packet did not contain a verified 617 instance of the Signature Attribute [16], the Access-Accept packet 618 SHOULD NOT contain an instance of the Tunnel-Password Attribute. 620 8. References 622 [1] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol -- PPTP", 623 draft-ietf-pppext-pptp-04.txt (work in progress), July 1998 625 [2] Valencia, A., Littlewood, M. and Kolar, T., "Layer Two Forwarding 626 (Protocol) 'L2F'", draft-valencia-l2f-00.txt (work in progress), 627 October 1997 629 [3] Valencia, A., et al., "Layer Two Tunnelling Protocol (L2TP)", work 630 in progress, draft-ietf-pppext-l2tp-11.txt, May 1998 632 [4] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP", RFC 2107, 633 February 1997 635 [5] Calhoun, P. and Wong, E., "Virtual Tunneling Protocol (VTP)", 636 draft-calhoun-vtp-protocol-00.txt (work in progress), July 1996 637 (expired) 639 [6] Kent, S. and Atkinson, R., "IP Authentication Header", draft-ietf- 640 ipsec-auth-header-07.txt (work in progress), July 1998 642 [7] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996 644 [8] Perkins, C., "Minimal Encapsulation within IP", RFC 2004, October 645 1996 647 [9] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827, 648 August 1995 650 [10] Hanks, S., et. al., "Generic Routing Encapsulation (GRE)", RFC 651 1701, October 1994 653 [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995 655 [12] Zorn, G. and Mitton, D., "RADIUS Accounting Modifications for Tun- 656 nel Protocol Support", draft-ietf-radius-tunnel-acct-02.txt (work 657 in progress), September 1998 659 [13] Rigney, C., et. al., "Remote Authentication Dialin User Service 660 (RADIUS)", RFC 2138, April 1997 662 [14] Bradner, S., "Key words for use in RFCs to Indicate Requirement 663 Levels", RFC 2119, March 1997 665 [15] Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, RFC 1700, 666 October 1994 668 [16] Rigney, C. and Willats, S., "RADIUS Extensions", draft-ietf-radius- 669 ext-01.txt (work in progress), September 1997 671 9. Acknowledgements 673 Thanks to Dave Mitton (dmitton@baynetworks.com) for pointing out a nasty 674 circular dependency in the original Tunnel-Password attribute definition 675 and (in no particular order) to Kory Hamzeh (kory@ascend.com), Bertrand 676 Buclin (Bertrand.Buclin@att.ch), Dave Mitton (dmitton@baynetworks.com), 677 Andy Valencia (vandys@cisco.com), Bill Westfield (billw@cisco.com), Kris 678 Michielsen (kmichiel@cisco.com), Gurdeep Singh Pall (gur- 679 deep@microsoft.com), Ran Atkinson (rja@home.net), Aydin Edguer 680 (edguer@MorningStar.com) and Bernard Aboba (aboba@internaut.com) for 681 useful input and review. 683 10. Chair's Address 685 The RADIUS Working Group can be contacted via the current chair: 687 Carl Rigney 688 Livingston Enterprises 689 4464 Willow Road 690 Pleasanton, California 94588 692 Phone: +1 510 426 0770 693 E-Mail: cdr@livingston.com 695 11. Authors' Addresses 697 Questions about this memo can also be directed to: 699 Glen Zorn 700 Microsoft Corporation 701 One Microsoft Way 702 Redmond, Washington 98052 704 Phone: +1 425 703 1559 705 E-Mail: glennz@microsoft.com 707 Dory Leifer 708 Ascend Communications 709 1678 Broadway 710 Ann Arbor, MI 48105 712 Phone: +1 313 747 6152 713 E-Mail: leifer@ascend.com 715 John Shriver 716 Shiva Corporation 717 28 Crosby Drive 718 Bedford, MA 01730 720 Phone: +1 781 687 1329 721 E-Mail: jas@shiva.com 723 Allan Rubens 724 Ascend Communications 725 1678 Broadway 726 Ann Arbor, MI 48105 728 Phone: +1 313 761 6025 729 E-Mail: acr@del.com 731 12. Expiration Date 733 This memo is filed as , and 734 expires April 5, 1999.