idnits 2.17.1 draft-ietf-roamops-nai-11.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-23) 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 6 longer pages, the longest (page 2) being 66 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 68 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 109 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 148: '... MUST support an NAI length of at ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == 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...' == (63 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 (22 July 1998) is 9407 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) ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '1') ** Obsolete normative reference: RFC 2138 (ref. '2') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. '3') (Obsoleted by RFC 2866) ** Obsolete normative reference: RFC 821 (ref. '5') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2052 (ref. '6') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2234 (ref. '7') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1825 (ref. '8') (Obsoleted by RFC 2401) Summary: 19 errors (**), 0 flaws (~~), 7 warnings (==), 2 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 CompuServe Network Services 6 22 July 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 25 (Europe), 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 January 15, 1999. Please send 29 comments to the authors. 31 2. Abstract 33 In order to enhance the interoperability of roaming and tunneling ser- 34 vices, it is desirable to have a standardized method for identifying 35 users. This document proposes syntax for the Network Access Identi- 36 fier (NAI), the userID submitted by the client during PPP authentica- 37 tion. It is expected that this will be of interest for support of 38 roaming as well as tunneling. "Roaming capability" may be loosely 39 defined as the ability to use any one of multiple Internet service 40 providers (ISPs), while maintaining a formal, customer-vendor rela- 41 tionship with only one. Examples of cases where roaming capability 42 might be required include ISP "confederations" and ISP-provided corpo- 43 rate network access support. 45 3. Introduction 47 Considerable interest has arisen recently in a set of features that 48 fit within the general category of "roaming capability" for dialup 49 Internet users. Interested parties have included: 51 Regional Internet Service Providers (ISPs) operating within a 52 particular state or province, looking to combine their efforts 53 with those of other regional providers to offer dialup service 54 over a wider area. 56 National ISPs wishing to combine their operations with those of 57 one or more ISPs in another nation to offer more comprehensive 58 dialup service in a group of countries or on a continent. 60 Businesses desiring to offer their employees a comprehensive 61 package of dialup services on a global basis. Those services may 62 include Internet access as well as secure access to corporate 63 intranets via a Virtual Private Network (VPN), enabled by tunnel- 64 ing protocols such as PPTP, L2F, L2TP, and IPSEC tunnel mode. 66 In order to enhance the interoperability of roaming and tunneling ser- 67 vices, it is desirable to have a standardized method for identifying 68 users. This document proposes syntax for the Network Access Identi- 69 fier (NAI). Examples of implementations that use the NAI, and 70 descriptions of its semantics, can be found in [1]. 72 3.1. Terminology 74 This document frequently uses the following terms: 76 Network Access Identifier 77 The Network Access Identifier (NAI) is the userID submitted 78 by the client during PPP authentication. In roaming, the 79 purpose of the NAI is to identify the user as well as to 80 assist in the routing of the authentication request. Please 81 note that the NAI may not necessarily be the same as the 82 user's e-mail address or the userID submitted in an applica- 83 tion layer authentication. 85 Network Access Server 86 The Network Access Server (NAS) is the device that clients 87 dial in order to get access to the network. In PPTP termi- 88 nology this is referred to as the PPTP Access Concentrator 89 (PAC), and in L2TP terminology, it is referred to as the 90 L2TP Access Concentrator (LAC). 92 Roaming Capability 93 Roaming capability can be loosely defined as the ability to 94 use any one of multiple Internet service providers (ISPs), 95 while maintaining a formal, customer-vendor relationship 96 with only one. Examples of cases where roaming capability 97 might be required include ISP "confederations" and ISP-pro- 98 vided corporate network access support. 100 Tunneling Service 101 A tunneling service is any network service enabled by tun- 102 neling protocols such as PPTP, L2F, L2TP, and IPSEC tunnel 103 mode. One example of a tunneling service is secure access 104 to corporate intranets via a Virtual Private Network (VPN). 106 3.2. Purpose 108 As described in [1], there are now a number of services implementing 109 dialup roaming, and the number of Internet Service Providers involved 110 in roaming consortia is increasing rapidly. 112 In order to be able to offer roaming capability, one of the require- 113 ments is to be able to identify the user's home authentication server. 114 For use in roaming, this function is accomplished via the Network 115 Access Identifier (NAI) submitted by the user to the NAS in the ini- 116 tial PPP authentication. It is also expected that NASes will use the 117 NAI as part of the process of opening a new tunnel, in order to deter- 118 mine the tunnel endpoint. 120 3.3. Notes for Implementors 122 As proposed in this document, the Network Access Identifier is of the 123 form user@realm. Please note that while the user portion of the NAI 124 conforms to the BNF described in [5], the BNF of the realm portion 125 allows the realm to begin with a digit, which is not permitted by the 126 BNF described in [4]. This change was made to reflect current prac- 127 tice; although not permitted by the BNF described in [4], FQDNs such 128 as 3com.com are commonly used, and accepted by current software. 130 While the realm is typically a Fully Qualified Domain Name (FQDN), it 131 is not required that this be the case, and thus the NAI need not be a 132 valid e-mail address. As a result, use of an FQDN as the realm does 133 not imply use of DNS for location of the authentication server or for 134 authentication routing. 136 Since to date roaming has been implemented on a relatively small 137 scale, existing implementations handle location of authentication 138 servers within a domain and perform authentication routing based on 139 local knowledge expressed in proxy configuration files. The implemen- 140 tations described in [1] have not found a need for use of DNS for 141 location of the authentication server within a domain, although this 142 can be accomplished via use of the DNS SRV record, described in [6]. 143 Similarly, existing implementations have not found a need for dynamic 144 routing protocols, or propagation of global routing information. 146 Please note that NAS vendors may need to modify their devices so as to 147 support the NAI as described in this document. Devices handling NAIs 148 MUST support an NAI length of at least 72 octets. 150 4. Formal definition of the NAI 152 The grammar for the NAI is given below, described in ABNF as docu- 153 mented in [7]. The grammar for the username is taken from [5], and 154 the grammar for the realm is an updated version of [4]. 156 nai = username / ( username "@" realm ) 157 username = dot-string 159 realm = label / ( realm "." label ) 161 label = let-dig *(ldh-str) 163 ldh-str = *( Alpha / Digit / "-" ) let-dig 165 dot-string = string / ( dot-string "." string ) 167 string = char / ( string char ) 169 char = c / ( "\" x ) 171 let-dig = Alpha / Digit 173 Alpha = %x41-5A / %x61-7A ; A-Z / a-z 175 Digit = %x30-39 ;0-9 177 c = < any one of the 128 ASCII characters, but 178 not any special or SP > 180 x = %x00-7F 181 ; all 127 ASCII characters, no exception 183 SP = %x20 ; Space character 185 special = "<" / ">" / "(" / ")" / "[" / "]" / "\" / "." 186 / "," / ";" / ":" / "@" / """ / Ctl 188 Ctl = %x00-1F / %x7F 189 ; the control characters (ASCII codes 0 through 31 190 ; inclusive and 127) 192 Examples of valid Network Access Identifiers include: 194 fred@foo 195 fred@3com.com 196 fred@foo-9.com 197 fred_smith@big-co.com 198 fred=?#$&*+-/^smith@bigco.com 199 fred@bigco.com 200 nancy@eng.bigu.edu 201 eng!nancy@bigu.edu 202 eng%nancy@bigu.edu 204 Examples of invalid Network Access Identifiers include: 206 fred@foo_9.com 207 @howard.edu 208 fred@bigco.com@smallco.com 209 eng:nancy@bigu.edu 210 eng;nancy@bigu.edu 211 @bigu.edu 213 5. Security Considerations 215 Since an NAI reveals the home affiliation of a user, it may assist an 216 attacker in further probing the username space. Typically this problem 217 is of most concern in protocols which transmit the user name in clear- 218 text across the Internet, such as in RADIUS, described in [2] and [3]. 219 In order to prevent snooping of the user name, protocols may use con- 220 fidentiality services provided by IPSEC, described in [8]. 222 6. Acknowledgements 224 Thanks to Glen Zorn of Microsoft for many useful discussions of this 225 problem space. 227 7. References 229 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 230 Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- 231 ainfo, Merit, September 1997. 233 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 234 cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, 235 Daydreamer, April 1997. 237 [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 238 1997. 240 [4] P. Mockapetris. "Domain Names - Implementation and Specifica- 241 tion." RFC 1035, Information Sciences Institute, University of South- 242 ern California, November 1987. 244 [5] J. Postel. "Simple Mail Transfer Protocol." RFC 821, Information 245 Sciences Institute, University of Southern California, August 1982. 247 [6] A. Gulbrandsen, P. Vixie. "A DNS RR for specifying the location 248 of services (DNS SRV)." RFC 2052, Troll Technologies, Vixie Enter- 249 prises, October 1996. 251 [7] D. Crocker, P. Overrell. "Augmented BNF for Syntax Specifica- 252 tions: ABNF." RFC 2234, Internet Mail Consortium, Demon Internet 253 Ltd., November 1997. 255 [8] R. Atkinson. "Security Architecture for the Internet Protocol." 256 RFC 1825, Naval Research Laboratory, August 1995. 258 8. Authors' Addresses 260 Bernard Aboba 261 Microsoft Corporation 262 One Microsoft Way 263 Redmond, WA 98052 265 Phone: 425-936-6605 266 EMail: bernarda@microsoft.com 268 Mark A. Beadles 269 CompuServe Network Services 270 5000 Britton Rd. 271 Hilliard, OH 43026 273 Phone: 614-723-1941 274 EMail: mbeadles@web.compuserve.com