idnits 2.17.1 draft-ietf-roamops-nai-12.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. Found some kind of copyright notice around line 297 but it does not match any copyright boilerplate known by this tool. 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. == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 91 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 135 instances of too long lines in the document, the longest one being 3 characters 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 142: '... MUST support an NAI length of at ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (86 more instances...) -- 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 (7 November 1998) is 9302 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? '1' on line 264 looks like a reference -- Missing reference section? '9' on line 231 looks like a reference -- Missing reference section? '5' on line 220 looks like a reference -- Missing reference section? '4' on line 217 looks like a reference -- Missing reference section? '7' on line 225 looks like a reference -- Missing reference section? '2' on line 239 looks like a reference -- Missing reference section? '3' on line 239 looks like a reference -- Missing reference section? '6' on line 267 looks like a reference -- Missing reference section? '8' on line 241 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft 4 Category: Standards Track Mark A. Beadles 5 WorldCom Advanced Networks 6 7 November 1998 8 The Network Access Identifier 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as and expires May 1, 1999. Please send com- 29 ments to the authors. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 3. Abstract 37 In order to enhance the interoperability of roaming and tunneling ser- 38 vices, it is desirable to have a standardized method for identifying 39 users. This document proposes syntax for the Network Access Identi- 40 fier (NAI), the userID submitted by the client during PPP authentica- 41 tion. It is expected that this will be of interest for support of 42 roaming as well as tunneling. "Roaming capability" may be loosely 43 defined as the ability to use any one of multiple Internet service 44 providers (ISPs), while maintaining a formal, customer-vendor rela- 45 tionship with only one. Examples of where roaming capabilities might 46 be required include ISP "confederations" and ISP-provided corporate 47 network access support. 49 4. Introduction 51 Considerable interest has arisen recently in a set of features that 52 fit within the general category of "roaming capability" for dialup 53 Internet users. Interested parties have included: 55 Regional Internet Service Providers (ISPs) operating within a 56 particular state or province, looking to combine their efforts 57 with those of other regional providers to offer dialup service 58 over a wider area. 60 National ISPs wishing to combine their operations with those of 61 one or more ISPs in another nation to offer more comprehensive 62 dialup service in a group of countries or on a continent. 64 Businesses desiring to offer their employees a comprehensive 65 package of dialup services on a global basis. Those services may 66 include Internet access as well as secure access to corporate 67 intranets via a Virtual Private Network (VPN), enabled by tunnel- 68 ing protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode. 70 In order to enhance the interoperability of roaming and tunneling ser- 71 vices, it is desirable to have a standardized method for identifying 72 users. This document proposes syntax for the Network Access Identi- 73 fier (NAI). Examples of implementations that use the NAI, and 74 descriptions of its semantics, can be found in [1]. 76 4.1. Terminology 78 This document frequently uses the following terms: 80 Network Access Identifier 81 The Network Access Identifier (NAI) is the userID submitted 82 by the client during PPP authentication. In roaming, the 83 purpose of the NAI is to identify the user as well as to 84 assist in the routing of the authentication request. Please 85 note that the NAI may not necessarily be the same as the 86 user's e-mail address or the userID submitted in an applica- 87 tion layer authentication. 89 Network Access Server 90 The Network Access Server (NAS) is the device that clients 91 dial in order to get access to the network. In PPTP termi- 92 nology this is referred to as the PPTP Access Concentrator 93 (PAC), and in L2TP terminology, it is referred to as the 94 L2TP Access Concentrator (LAC). 96 Roaming Capability 97 Roaming capability can be loosely defined as the ability to 98 use any one of multiple Internet service providers (ISPs), 99 while maintaining a formal, customer-vendor relationship 100 with only one. Examples of cases where roaming capability 101 might be required include ISP "confederations" and ISP- 102 provided corporate network access support. 104 Tunneling Service 105 A tunneling service is any network service enabled by tun- 106 neling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel 107 mode. One example of a tunneling service is secure access 108 to corporate intranets via a Virtual Private Network (VPN). 110 4.2. Requirements language 112 In this document, the key words "MAY", "MUST, "MUST NOT", 113 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 114 interpreted as described in [9]. 116 4.3. Purpose 118 As described in [1], there are now a number of services implementing 119 dialup roaming, and the number of Internet Service Providers involved 120 in roaming consortia is increasing rapidly. 122 In order to be able to offer roaming capability, one of the require- 123 ments is to be able to identify the user's home authentication server. 124 For use in roaming, this function is accomplished via the Network 125 Access Identifier (NAI) submitted by the user to the NAS in the ini- 126 tial PPP authentication. It is also expected that NASes will use the 127 NAI as part of the process of opening a new tunnel, in order to deter- 128 mine the tunnel endpoint. 130 4.4. Notes for Implementors 132 As proposed in this document, the Network Access Identifier is of the 133 form user@realm. Please note that while the user portion of the NAI 134 conforms to the BNF described in [5], the BNF of the realm portion 135 allows the realm to begin with a digit, which is not permitted by the 136 BNF described in [4]. This change was made to reflect current prac- 137 tice; although not permitted by the BNF described in [4], FQDNs such 138 as 3com.com are commonly used, and accepted by current software. 140 Please note that NAS vendors may need to modify their devices so as to 141 support the NAI as described in this document. Devices handling NAIs 142 MUST support an NAI length of at least 72 octets. 144 5. Formal definition of the NAI 146 The grammar for the NAI is given below, described in ABNF as docu- 147 mented in [7]. The grammar for the username is taken from [5], and 148 the grammar for the realm is an updated version of [4]. 150 nai = username / ( username "@" realm ) 151 username = dot-string 153 realm = realm "." label 155 label = let-dig * (ldh-str) 157 ldh-str = *( Alpha / Digit / "-" ) let-dig 159 dot-string = string / ( dot-string "." string ) 161 string = char / ( string char ) 163 char = c / ( "\" x ) 165 let-dig = Alpha / Digit 167 Alpha = %x41-5A / %x61-7A ; A-Z / a-z 169 Digit = %x30-39 ;0-9 171 c = < any one of the 128 ASCII characters, but 172 not any special or SP > 174 x = %x00-7F 175 ; all 127 ASCII characters, no exception 177 SP = %x20 ; Space character 179 special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." 180 / "," / ";" / ":" / "@" / %x22 / Ctl 182 Ctl = %x00-1F / %x7F 183 ; the control characters (ASCII codes 0 through 31 184 ; inclusive and 127) 186 Examples of valid Network Access Identifiers include: 188 fred@3com.com 189 fred@foo-9.com 190 fred_smith@big-co.com 191 fred=?#$&*+-/^smith@bigco.com 192 fred@bigco.com 193 nancy@eng.bigu.edu 194 eng!nancy@bigu.edu 195 eng%nancy@bigu.edu 197 Examples of invalid Network Access Identifiers include: 199 fred@foo 200 fred@foo_9.com 201 @howard.edu 202 fred@bigco.com@smallco.com 203 eng:nancy@bigu.edu 204 eng;nancy@bigu.edu 205 @bigu.edu 207 6. References 209 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roam- 210 ing Implementations", RFC 2194, September 1997. 212 [2] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen- 213 tication Dial In User Service (RADIUS)", RFC 2138, April 1997. 215 [3] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. 217 [4] Mockapetris, P., "Domain Names - Implementation and Specifica- 218 tion", RFC 1035, November 1987. 220 [5] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 1982. 222 [6] Gulbrandsen A., and P. Vixie, "A DNS RR for specifying the loca- 223 tion of services (DNS SRV)", RFC 2052, October 1996. 225 [7] Crocker, D., and P. Overrell, "Augmented BNF for Syntax Specifica- 226 tions: ABNF", RFC 2234, November 1997. 228 [8] Atkinson, R., "Security Architecture for the Internet Protocol", 229 RFC 1825, August 1995. 231 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 232 Levels", BCP 14, RFC 2119, March 1997. 234 7. Security Considerations 236 Since an NAI reveals the home affiliation of a user, it may assist an 237 attacker in further probing the username space. Typically this problem 238 is of most concern in protocols which transmit the user name in clear- 239 text across the Internet, such as in RADIUS, described in [2] and [3]. 240 In order to prevent snooping of the user name, protocols may use con- 241 fidentiality services provided by IPSEC, described in [8]. 243 8. IANA Considerations 245 This document defines a new namespace that will need to be adminis- 246 tered, namely the NAI realm namespace. In order to to avoid creating 247 any new administrative procedures, administration of the NAI realm 248 namespace will piggyback on the administration of the DNS namespace. 250 NAI realm names are required to be unique and the rights to use a 251 given NAI realm for roaming purposes are obtained coincident with 252 acquiring the rights to use a particular fully qualified domain name 253 (FQDN). Those wishing to use an NAI realm name should first acquire 254 the rights to use the corresponding FQDN. Using an NAI realm without 255 ownership of the corresponding FQDN creates the possibility of 256 conflict and therefore is to be discouraged. 258 Note that the use of an FQDN as the realm name does not imply use of 259 the DNS for location of the authentication server or for authentica- 260 tion routing. Since to date roaming has been implemented on a rela- 261 tively small scale, existing implementations typically handle location 262 of authentication servers within a domain and perform authentication 263 routing based on local knowledge expressed in proxy configuration 264 files. The implementations described in [1] have not found a need for 265 use of DNS for location of the authentication server within a domain, 266 although this can be accomplished via use of the DNS SRV record, 267 described in [6]. Similarly, existing implementations have not found 268 a need for dynamic routing protocols, or propagation of global routing 269 information. Note also that there is no requirement that the NAI rep- 270 resent a valid email address. 272 9. Acknowledgements 274 Thanks to Glen Zorn of Microsoft for many useful discussions of this 275 problem space. 277 10. Authors' Addresses 279 Bernard Aboba 280 Microsoft Corporation 281 One Microsoft Way 282 Redmond, WA 98052 284 Phone: 425-936-6605 285 EMail: bernarda@microsoft.com 287 Mark A. Beadles 288 WorldCom Advanced Networks 289 5000 Britton Rd. 290 Hilliard, OH 43026 292 Phone: 614-723-1941 293 EMail: mbeadles@wcom.net 295 11. Full Copyright Statement 297 Copyright (C) The Internet Society (1997). All Rights Reserved. 298 This document and translations of it may be copied and furnished to 299 others, and derivative works that comment on or otherwise explain it 300 or assist in its implmentation may be prepared, copied, published and 301 distributed, in whole or in part, without restriction of any kind, 302 provided that the above copyright notice and this paragraph are 303 included on all such copies and derivative works. However, this docu- 304 ment itself may not be modified in any way, such as by removing the 305 copyright notice or references to the Internet Society or other Inter- 306 net organizations, except as needed for the purpose of developing 307 Internet standards in which case the procedures for copyrights defined 308 in the Internet Standards process must be followed, or as required to 309 translate it into languages other than English. The limited permis- 310 sions granted above are perpetual and will not be revoked by the 311 Internet Society or its successors or assigns. This document and the 312 information contained herein is provided on an "AS IS" basis and THE 313 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 314 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 315 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 316 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 317 PARTICULAR PURPOSE." 319 12. Expiration Date 321 This memo is filed as , and expires May 322 1, 1999.