idnits 2.17.1 draft-ietf-radius-tunnel-auth-01.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-19) 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 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.) ** There are 71 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 73: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 76: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 79: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 85: '... SHOULD NOT...' RFC 2119 keyword, line 92: '... MAY This word, or the adjecti...' (15 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. -- The draft header indicates that this document updates RFC24, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...This document...' == Line 11 has weird spacing: '...as, and its...' == Line 16 has weird spacing: '...and may be ...' == Line 17 has weird spacing: '...ference mater...' == Line 20 has weird spacing: '...To learn the...' == (66 more instances...) -- No information found for rfc24 - is the name correct? (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 (24 March 1997) is 9888 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) -- Missing reference section? 'PPTP' on line 39 looks like a reference -- Missing reference section? 'L2TP' on line 39 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 8 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 2058, RFC 2059 24 March 1997 4 Category: Standards Track 6 RADIUS Attributes for Tunnel Protocol Support 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working doc- 13 uments as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 23 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 25 The distribution of this memo is unlimited. It is filed as , and expires October 1, 1997. Please send 27 comments to the RADIUS Working Group mailing list (ietf- 28 radius@livingston.com) or to the author (glennz@microsoft.com). 30 2. Abstract 32 This document specifies a set of RADIUS attributes designed to support 33 the provision of mandatory tunneling in dial-up networks. RADIUS 34 attributes for both authorization and accounting are specified. 36 3. Introduction 38 Many of the most interesting applications of tunneling protocols such as 39 PPTP [PPTP] and L2TP [L2TP] involve dial-up network access. Some, such 40 as the provision of secure access to corporate intranets via the Inter- 41 net, are characterized by voluntary tunneling: the tunnel is created at 42 the request of the user for a specific purpose. Other, potentially more 43 compelling, applications involve compulsory tunneling: the tunnel is 44 created automatically, without any action from the user and more impor- 45 tantly, without allowing the user any choice in the matter. Examples of 46 applications that might be implemented using compulsory tunnels are 47 Internet software upgrade servers, software registration servers and 48 banking services. These are all services which, without compulsory tun- 49 neling, would probably be provided using dedicated networks or at least 50 dedicated network access servers (NAS), since they are characterized by 51 the need to limit user access to specific hosts. Given the existence of 52 widespread support for compulsory tunneling, however, these types of 53 services could be accessed via virtually any Internet service provider 54 (ISP). The most popular means of authorizing dial-up network users 55 today is through the RADIUS protocol. The use of RADIUS allows the 56 dial-up users' authorization and authentication data to be maintained in 57 a central location, rather than being subject to manual configuration. 58 It makes sense to use RADIUS to centrally administer compulsory tunnel- 59 ing, since RADIUS is widely deployed and was designed to carry this type 60 of information. In order to provide this functionality, new RADIUS 61 attributes are needed to carry the tunneling information from the RADIUS 62 server to the NAS and to transfer accounting data from the NAS to the 63 RADIUS server; this document defines those attributes. 65 4. Specification of Requirements 67 In this document, several words are used to signify the requirements of 68 the specification. These words are often capitalized. 70 In this document, several words are used to signify the requirements of 71 the specification. These words are often capitalized. 73 MUST This word, or the adjective "required", means that the 74 definition is an absolute requirement of the specification. 76 MUST NOT This phrase means that the definition is an absolute 77 prohibition of the specification. 79 SHOULD This word, or the adjective "recommended", means that there 80 may exist valid reasons in particular circumstances to 81 ignore this item, but the full implications must be 82 understood and carefully weighed before choosing a 83 different course. 85 SHOULD NOT 86 This phrase means that there may exist valid reasons in par- 87 ticular circumstances when the particular behavior is 88 acceptable or even useful, but the full implications should 89 be understood and the case carefully weighed before imple- 90 menting any behavior described with this label. 92 MAY This word, or the adjective "optional", means that this 93 item is one of an allowed set of alternatives. An 94 implementation which does not include this option MUST be 95 prepared to interoperate with another implementation which 96 does include the option. 98 5. Attributes 100 Multiple instances of each of the attributes defined below may be 101 included in a single RADIUS packet. If this is done, the attributes to 102 be applied to each distinct tunnel SHOULD all contain the same value in 103 their respective Tag fields. 105 5.1. Tunnel-Type 107 Description 109 This Attribute indicates the tunneling protocol(s) to be used. It 110 MAY be included in both Access-Request and Access-Accept packets; 111 if it is present in an Access-Request packet, it SHOULD be taken 112 as a hint to the RADIUS server as to the tunnel mediums supported 113 by the NAS. The RADIUS server MAY ignore the hint, however. A 114 NAS is not required to implement any of these tunnel types; If a 115 NAS receives an Access-Accept packet which contains only unknown 116 or unsupported Tunnel-Types, the NAS MUST behave as though an 117 Access-Reject had been received instead. 119 A summary of the Tunnel-Type Attribute format is shown below. The 120 fields are transmitted from left to right. 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Type | Length | Tag | Value | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 Type 130 64 for Tunnel-Type 132 Length 133 Always 4. 135 Tag 137 The Tag field is one octet in length and is intended to provide a 138 means of grouping attributes in the same packet which refer to the 139 same tunnel. 141 Value 143 The Value field is one octet and contains one of the following 144 values, indicating the type of tunnel to be started. 146 1 PPTP 147 2 L2F 148 3 L2TP 149 4 ATMP 150 5 VTP 151 6 AH 152 7 IP-IP 154 5.2. Tunnel-Medium-Type 156 Description 158 The Tunnel-Medium-Type Attribute indicates which transport medium 159 to use when creating a tunnel for those protocols (such as L2TP) 160 that can operate over multiple transports. It MAY be included in 161 both Access-Request and Access-Accept packets; if it is present in 162 an Access-Request packet, it SHOULD be taken as a hint to the 163 RADIUS server as to the tunnel mediums supported by the NAS. The 164 RADIUS server MAY ignore the hint, however. 166 A summary of the Tunnel-Medium-Type Attribute format is given below. 167 The fields are transmitted left to right. 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | Tag | Value | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Type 177 65 for Tunnel-Medium-Type 179 Length 181 4 183 Tag 185 The Tag field is one octet in length and is intended to provide a 186 means of grouping attributes in the same packet which refer to the 187 same tunnel. 189 Value 191 The Value field is one octet. 193 1 IP 194 2 X.25 195 3 ATM 196 4 Frame Relay 198 5.3. Acct-Tunnel-Client-Endpoint 200 Description 202 This Attribute contains the address of the NAS end of the tunnel. 203 It SHOULD be included in Accounting-Request packets which contain 204 Acct-Status-Type attributes with values of either Start or Stop. 205 This Attribute, along with the Tunnel-Server-Endpoint and Acct- 206 Tunnel-Connection-ID attributes, may be used to provide a globally 207 unique means to identify a tunnel for accounting purposes. 209 A summary of the Acct-Tunnel-Client-Endpoint Attribute format is 210 shown below. The fields are transmitted from left to right. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | Tag | String ... 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Type 220 66 for Acct-Tunnel-Client-Endpoint. 222 Length 224 >= 3 226 Tag 228 The Tag field is one octet in length and is intended to provide a 229 means of grouping attributes in the same packet which refer to the 230 same tunnel. 232 String 233 The format of the address represented by the String field depends 234 upon the value of the Tunnel-Medium-Type attribute. 236 5.4. Tunnel-Server-Endpoint 238 Description 240 This Attribute indicates the address of the server end of the tun- 241 nel. It SHOULD be included in Accounting-Request packets which 242 contain Acct-Status-Type attributes with values of either Start or 243 Stop. This Attribute, along with the Acc-Tunnel-Client-Endpoint 244 and Acct-Tunnel-Connection-ID attributes, may be used to provide a 245 globally unique means to identify a tunnel for accounting pur- 246 poses. 248 A summary of the Tunnel-Server-Endpoint Attribute format is shown 249 below. The fields are transmitted from left to right. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Type | Length | Tag | String ... 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Type 259 67 for Tunnel-Server-Endpoint. 261 Length 263 >= 3 265 Tag 267 The Tag field is one octet in length and is intended to provide a 268 means of grouping attributes in the same packet which refer to the 269 same tunnel. 271 String 272 The format of the address represented by the String field depends 273 upon the value of the Tunnel-Medium-Type attribute. 275 5.5. Acct-Tunnel-Connection-ID 277 Description 279 This Attribute indicates the identifier assigned to the call. It 280 SHOULD be included in Accounting-Request packets which contain 281 Acct-Status-Type attributes with values of either Start or Stop. 282 This attribute, along with the Acct-Tunnel-Client-Endpoint and 283 Tunnel-Server-Endpoint attributes, may be used to provide a glob- 284 ally unique means to identify a call for accounting purposes. 286 A summary of the Acct-Tunnel-Connection-ID Attribute format is shown 287 below. The fields are transmitted from left to right. 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | Tag | String ... 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Type 297 68 for Acct-Tunnel-Connection-ID 299 Length 301 >= 3 303 Tag 305 The Tag field is one octet in length and is intended to provide a 306 means of grouping attributes in the same packet which refer to the 307 same tunnel. 309 String 310 The format of the identifier represented by the String field 311 depends upon the value of the Tunnel-Type attribute. 313 5.6. Tunnel-Password 315 Description 317 This Attribute may contain a key or password. It may only be 318 included in an Access-Accept packet. 320 A summary of the Tunnel-Password Attribute format is shown below. 321 The fields are transmitted from left to right. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | Tag | String ... 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Type 331 69 for Tunnel-Password 333 Length 335 >= 3 337 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. 343 String 345 If this field is present, it MUST be hidden in the same fashion as 346 the User-Password Attribute, with the exception that the Response- 347 Authenticator MUST be used in place of the Request-Authenticator 348 (see RFC 2058, Section 5.2). 350 6. Security Considerations 352 The Tunnel-Password Attribute may contain information which should only 353 be known to a tunnel endpoint. The method used to hide the value of the 354 attribute, however, is such that intervening RADIUS proxies will have 355 knowledge of the contents. For this reason, the Tunnel-Password 356 Attribute SHOULD NOT be included in Access-Accept packets which may pass 357 through (relatively) untrusted RADIUS proxies. 359 7. Acknowledgements 361 Thanks to Kory Hamzeh of Ascend Communications; Bertrand Buclin of AT&T 362 Laboratries Europe; Andy Valencia, Bill Westfield and Kris Michielsen of 363 cisco Systems; amd Gurdeep Singh Pall and Bernard Aboba of Microsoft 364 Corporation for salient input and review. 366 8. Chair's Address 368 The RAQDIUS Working Group can be contacted via the current chair: 370 Carl Rigney 371 Livingston Enterprises 372 6920 Koll Center Parkway, Suite 220 373 Pleasanton, California 94566 375 Phone: +1 510 426 0770 376 E-Mail: cdr@livingston.com 378 9. Author's Address 380 Questions about this memo can also be directed to: 382 Glen Zorn 383 Microsoft Corporation 384 One Microsoft Way 385 Redmond, Washington 98052 387 Phone: +1 206 703 1559 388 E-Mail: glennz@microsoft.com