idnits 2.17.1 draft-ietf-radius-tunnel-auth-02.txt: 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-03-28) 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 Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations 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 an Authors' Addresses Section. ** There are 96 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 6 characters in excess of 72. ** There are 16 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 79: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 82: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 88: '... SHOULD NOT...' RFC 2119 keyword, line 95: '... MAY This word, or the adjecti...' (24 more instances...) == 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 RFC2058, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2059, 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...' == (91 more instances...) (Using the creation date from RFC2059, 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 (July 1997) is 9753 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) No issues found here. Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Zorn 3 Internet-Draft Microsoft Corporation 4 Updates: RFC 2058, RFC 2059 D. Leifer 5 Category: Standards Track Ascend Communications 6 John Shriver 7 Shiva Corporation 8 July 1997 10 RADIUS Attributes for Tunnel Protocol Support 12 11.. 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 February 1, 1997. Please send 31 comments to the RADIUS Working Group mailing list (ietf-radius@liv- 32 ingston.com) or to the authors (liefer@del.com, jas@shiva.com and 33 glennz@microsoft.com). 35 22.. Abstract 37 This document defines a set of RADIUS attributes designed to support the 38 provision of compulsory tunneling in dial-up networks. RADIUS 39 attributes for both authorization and accounting are specified. 41 33.. Motivation 43 Many applications of tunneling protocols such as PPTP and L2TP involve 44 dial-up network access. Some, such as the provision of secure access to 45 corporate intranets via the Internet, are characterized by voluntary 46 tunneling: the tunnel is created at the request of the user for a spe- 47 cific purpose. Other applications involve compulsory tunneling: the 48 tunnel is created without any action from the user and without allowing 49 the user any choice in the matter. Examples of applications that might 50 be implemented using compulsory tunnels are Internet software upgrade 51 servers, software registration servers and banking services. These are 52 all services which, without compulsory tunneling, would probably be pro- 53 vided using dedicated networks or at least dedicated network access 54 servers (NAS), since they are characterized by the need to limit user 55 access to specific hosts. Given the existence of widespread support for 56 compulsory tunneling, however, these types of services could be accessed 57 via any Internet service provider (ISP). The most popular means of 58 authorizing dial-up network users today is through the RADIUS protocol. 59 The use of RADIUS allows the dial-up users' authorization and authenti- 60 cation data to be maintained in a central location, rather than on each 61 NAS. It makes sense to use RADIUS to centrally administer compulsory 62 tunneling, since RADIUS is widely deployed and was designed to carry 63 this type of information. In order to provide this functionality, new 64 RADIUS attributes are needed to carry the tunneling information from the 65 RADIUS server to the NAS and to transfer accounting data from the NAS to 66 the RADIUS accounting server; this document defines those attributes. 67 Specific recommendations for, and examples of, the application of these 68 attributes for the L2TP and PPTP protocols can be found in draft-ietf- 69 radius-tunnel-imp-XX.txt. 71 44.. Specification of Requirements 73 In this document, several words are used to signify the requirements of 74 the specification. These words are often capitalized. 76 MUST This word, or the adjective "required", means that the 77 definition is an absolute requirement of the specification. 79 MUST NOT This phrase means that the definition is an absolute 80 prohibition of the specification. 82 SHOULD This word, or the adjective "recommended", means that there 83 may exist valid reasons in particular circumstances to 84 ignore this item, but the full implications must be 85 understood and carefully weighed before choosing a 86 different course. 88 SHOULD NOT 89 This phrase means that there may exist valid reasons in par- 90 ticular circumstances when the particular behavior is 91 acceptable or even useful, but the full implications should 92 be understood and the case carefully weighed before imple- 93 menting any behavior described with this label. 95 MAY This word, or the adjective "optional", means that this 96 item is one of an allowed set of alternatives. An 97 implementation which does not include this option MUST be 98 prepared to interoperate with another implementation which 99 does include the option. 101 55.. Attributes 103 Multiple instances of each of the attributes defined below may be 104 included in a single RADIUS packet. In this case, the attributes to be 105 applied to any given tunnel SHOULD all contain the same value in their 106 respective Tag fields. 108 55..11.. Tunnel-Type 110 Description 112 This Attribute indicates the tunneling protocol(s) to be used. It 113 MAY be included in Access-Request, Access-Accept and Accounting- 114 Request packets. If the Tunnel-Type Attribute is present in an 115 Access-Request packet, it SHOULD be taken as a hint to the RADIUS 116 server as to the tunnelling protocols supported by the NAS; the 117 RADIUS server MAY ignore the hint, however. A NAS is not required 118 to implement any of these tunnel types; if a NAS receives an 119 Access-Accept packet which contains only unknown or unsupported 120 Tunnel-Types, the NAS MUST behave as though an Access-Reject had 121 been received instead. 123 A summary of the Tunnel-Type Attribute format is shown below. The 124 fields are transmitted from left to right. 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | Tag | Value 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 Value (cont) | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Type 137 64 for Tunnel-Type 139 Length 141 Always 6. 143 Tag 145 The Tag field is one octet in length and is intended to provide a 146 means of grouping attributes in the same packet which refer to the 147 same tunnel. If the Tag field is unused, it MUST be zero. 149 Value 151 The Value field is three octets and contains one of the following 152 values, indicating the type of tunnel to be started. 154 1 Point-to-Point Tunneling Protocol (PPTP) 155 2 Layer Two Forwarding (L2F) 156 3 Layer Two Tunneling Protocol (L2TP) 157 4 Ascend Tunnel Management Protocol (ATMP) 158 5 Virtual Tunneling Protocol (VTP) 159 6 IP Authentication Header in the Tunnel-mode (AH) 160 7 IP-in-IP Encapsulation (IP-IP) 161 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) 162 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) 163 10 Generic Route Encapsulation (GRE) 164 11 Bay Dial Virtual Services (DVS) 166 55..22.. Tunnel-Medium-Type 168 Description 170 The Tunnel-Medium-Type Attribute indicates which transport medium 171 to use when creating a tunnel for those protocols (such as L2TP) 172 that can operate over multiple transports. It MAY be included in 173 both Access-Request and Access-Accept packets; if it is present in 174 an Access-Request packet, it SHOULD be taken as a hint to the 175 RADIUS server as to the tunnel mediums supported by the NAS. The 176 RADIUS server MAY ignore the hint, however. 178 A summary of the Tunnel-Medium-Type Attribute format is given below. 179 The fields are transmitted left to right. 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Type | Length | Tag | Value | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Value (cont) | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Type 191 65 for Tunnel-Medium-Type 193 Length 195 6 197 Tag 199 The Tag field is one octet in length and is intended to provide a 200 means of grouping attributes in the same packet which refer to the 201 same tunnel. If the Tag field is unused, it MUST be zero 202 (0x0000). 204 Value 206 The Value field is three octets nd contains one of the following 207 values: 209 1 IP 210 2 X.25 211 3 ATM 212 4 Frame Relay 214 55..33.. Acct-Tunnel-Client-Endpoint 216 Description 218 This Attribute contains the address of the NAS end of the tunnel. 219 It SHOULD be included in Accounting-Request packets which contain 220 Acct-Status-Type attributes with values of either Start or Stop. 221 This Attribute, along with the Tunnel-Server-Endpoint and Acct- 222 Tunnel-Connection-ID attributes, may be used to provide a globally 223 unique means to identify a tunnel for accounting and auditing pur- 224 poses. 226 A summary of the Acct-Tunnel-Client-Endpoint Attribute format is 227 shown below. The fields are transmitted from left to right. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | String ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Type 237 66 for Acct-Tunnel-Client-Endpoint. 239 Length 241 >= 2 243 String 244 The format of the address represented by the String field depends 245 upon the value of the Tunnel-Medium-Type attribute. 247 If Tunnel-Medium-Type is IP (1), then this string is either the 248 fully qualified domain name, or it is a "dotted-decimal" IP 249 address. 251 If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4), 252 this string is a tag referring to configuration data local to the 253 RADIUS client that describes the interface and medium-specific 254 address to use. 256 55..44.. Tunnel-Server-Endpoint 258 Description 260 This Attribute indicates the address of the server end of the tun- 261 nel. The Tunnel-Server-Endpoint Attribute MAY be included (as a 262 hint to the RADIUS server) in the Access-Request packet and MUST 263 be included in the Access-Accept packet if the initiation of a 264 tunnel is desired. It SHOULD be included in Accounting-Request 265 packets which contain Acct-Status-Type attributes with values of 266 either Start or Stop and which pertain to a tunneled session. 267 This Attribute, along with the Acc-Tunnel-Client-Endpoint and 268 Acct-Tunnel-Connection-ID attributes, may be used to provide a 269 globally unique means to identify a tunnel for accounting and 270 auditing purposes. 272 A summary of the Tunnel-Server-Endpoint Attribute format is shown 273 below. The fields are transmitted from left to right. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Type | Length | Tag | String ... 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 Type 283 67 for Tunnel-Server-Endpoint. 285 Length 287 >= 3 289 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. If the Tag field is unused, it MUST be zero 294 (0x0000). 296 String 297 The format of the address represented by the String field depends 298 upon the value of the Tunnel-Medium-Type attribute. 300 If Tunnel-Medium-Type is IP (1), then this string is either the 301 fully qualified domain name, or it is a "dotted-decimal" IP 302 address. 304 If Tunnel-Medium-Type is X.25 (2), ATM (3), or Frame Relay (4), 305 this string is a tag referring to configuration data local to the 306 RADIUS client that describes the interface and medium-specific 307 address to use. 309 55..55.. Acct-Tunnel-Connection 311 Description 313 This Attribute indicates the identifier assigned to the call. It 314 SHOULD be included in Accounting-Request packets which contain 315 Acct-Status-Type attributes with values of either Start or Stop. 316 This attribute, along with the Acct-Tunnel-Client-Endpoint and 317 Tunnel-Server-Endpoint attributes, may be used to provide a glob- 318 ally unique means to identify a call for accounting and auditing 319 purposes. 321 A summary of the Acct-Tunnel-Connection Attribute format is shown 322 below. 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 | String ... 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Type 332 68 for Acct-Tunnel-Connection 334 Length 336 >= 2 338 String 339 The format of the identifier represented by the String field 340 depends upon the value of the Tunnel-Type attribute. 342 55..66.. Tunnel-Private-Group-ID 344 Description 346 This Attribute indicates the group ID for a particular tunneled 347 session. The Tunnel-Private-Group-ID Attribute MAY be included in 348 the Access-Request packet if the NAS can pre-determine the group 349 resulting from a particular connection and SHOULD be included in 350 the Access-Reply packet if this tunnel session is to be treated as 351 belonging to a particular private group. Private groups may be 352 used to associate a tunneled session with a particular group of 353 users. For example, it may be used to facilitate routing of 354 unregistered IP addresses through a particular interface. It 355 SHOULD be included in Accounting-Request packets which contain 356 Acct-Status-Type attributes with values of either Start or Stop 357 and which pertain to a tunneled session. 359 A summary of the Tunnel-Private-Group-ID Attribute format is shown 360 below. The fields are transmitted from left to right. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length | Tag | String ... 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Type 369 ?? for Tunnel-Private-Group-ID. 371 Length 373 >= 3 375 Tag 377 The Tag field is one octet in length and is intended to provide a 378 means of grouping attributes in the same packet which refer to the 379 same tunnel. If the Tag field is unused, it MUST be zero 380 (0x0000). 382 String 383 This field must be present. The group is represented by the 384 String field. There is no restriction on the format of group IDs. 386 66.. Table of Attributes 388 The following table provides a guide to which of the above attributes 389 may be found in which kinds of packets, and in what quantity. 391 Request Accept Reject Challenge Acct-Request # Attribute 392 0+ 0+ 0 0 0-1 64 Tunnel-Type 393 0+ 0+ 0 0 0-1 65 Tunnel-Medium-Type 394 0 0 0 0 0-1 66 Acct-Tunnel-Client-Endpoint 395 0+ 0+ 0 0 0-1 67 Tunnel-Server-Endpoint 396 0 0 0 0 0-1 68 Acct-Tunnel-Connection 397 0+ 0+ 0 0 0-1 ?? Tunnel-Private-Group-ID 399 The following table defines the meaning of the above table entries. 401 0 This attribute MUST NOT be present in packet. 402 0+ Zero or more instances of this attribute MAY be present in packet. 403 0-1 Zero or one instance of this attribute MAY be present in packet. 405 77.. Security Considerations 407 None (submissions welcome). 409 88.. Acknowledgements 411 Thanks (in no particular order) to Kory Hamzeh (kory@ascend.com), 412 Bertrand Buclin (Bertrand.Buclin@att.ch), Dave Mitton (dmitton@baynet- 413 works.com), Andy Valencia (vandys@cisco.com), Bill Westfield 414 (billw@cisco.com), Kris Michielsen (kmichiel@cisco.com), Gurdeep Singh 415 Pall (gurdeep@microsoft.com), Ran Atkinson (rja@home.net) and Bernard 416 Aboba (aboba@internaut.com) for salient input and review. 418 99.. Chair's Address 420 The RAQDIUS Working Group can be contacted via the current chair: 422 Carl Rigney 423 Livingston Enterprises 424 6920 Koll Center Parkway, Suite 220 425 Pleasanton, California 94566 427 Phone: +1 510 426 0770 428 E-Mail: cdr@livingston.com 430 1100.. Author's Address 432 Questions about this memo can also be directed to: 434 Glen Zorn 435 Microsoft Corporation 436 One Microsoft Way 437 Redmond, Washington 98052 439 Phone: +1 206 703 1559 440 E-Mail: glennz@microsoft.com 442 Dory Leifer 443 Ascend Communications 444 1678 Broadway 445 Ann Arbor, MI 48105 447 Phone: +1 313 747 6152 448 E-Mail: leifer@ascend.com 450 John Shriver 451 Shiva Corporation 452 28 Crosby Drive 453 Bedford, MA 01730 455 Phone: +1 617 270 8329 456 E-Mail: jas@shiva.com