idnits 2.17.1 draft-ietf-roamops-nai-04.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-18) 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 3 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 76 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 12 has weird spacing: '...), its areas...' == Line 13 has weird spacing: '... its worki...' == Line 17 has weird spacing: '... and may ...' == Line 18 has weird spacing: '...afts as refer...' == Line 21 has weird spacing: '... To learn...' == (41 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 June 1997) is 9812 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: '2' is defined on line 153, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 157, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-roamops-imprev-02 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-imprev (ref. '1') ** Obsolete normative reference: RFC 2058 (ref. '2') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '3') (Obsoleted by RFC 2139) -- Unexpected draft version: The latest known version of draft-ietf-http-v11-spec is -06, but you're referring to -07. Summary: 14 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROAMOPS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Standards Track 4 5 7 June 1997 7 The Network Access Identifier 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working docu- 12 ments of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute work- 14 ing documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference mate- 19 rial or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 26 The distribution of this memo is unlimited. It is filed as and expires January 1, 1998. Please send 28 comments to the authors. 30 2. Abstract 32 In order to enhance the interoperability of roaming and tunneling ser- 33 vices, it is desirable to have a standardized method for identifying 34 users. This document proposes syntax for the Network Access Identi- 35 fier (NAI). It is expected that this will be of interest for support 36 of roaming as well as tunneling. "Roaming capability" may be loosely 37 defined as the ability to use any one of multiple Internet service 38 providers (ISPs), while maintaining a formal, customer-vendor rela- 39 tionship with only one. Examples of cases where roaming capability 40 might be required include ISP "confederations" and ISP-provided corpo- 41 rate network access support. 43 3. Introduction 45 Considerable interest has arisen recently in a set of features that 46 fit within the general category of "roaming capability" for dialup 47 Internet users. Interested parties have included: 49 Regional Internet Service Providers (ISPs) operating within a 50 particular state or province, looking to combine their efforts 51 with those of other regional providers to offer dialup service 52 over a wider area. 54 National ISPs wishing to combine their operations with those of 55 one or more ISPs in another nation to offer more comprehensive 56 dialup service in a group of countries or on a continent. 58 Businesses desiring to offer their employees a comprehensive 59 package of dialup services on a global basis. Those services may 60 include Internet access as well as secure access to corporate 61 intranets via a Virtual Private Network (VPN), enabled by tunnel- 62 ing protocols such as PPTP, L2F and L2TP. 64 In order to enhance the interoperability of roaming and tunneling ser- 65 vices, it is desirable to have a standardized method for identifying 66 users. This document proposes syntax for the Network Access Identi- 67 fier (NAI). Methods for authentication routing or determination of 68 tunnel server endpoints will be addressed in future documents. 70 3.1. Terminology 72 This document frequently uses the following terms: 74 Network Access Identifier 75 The Network Access Identifier (NAI) is the userID submitted 76 by the client during PPP authentication. In roaming, the 77 purpose of the NAI is to identify the user as well as to 78 assist in the routing of the authentication request. Please 79 note that the NAI may not necessarily be the same as the 80 user's e-mail address or the userID submitted in an applica- 81 tion layer authentication. 83 Network Access Server 84 The Network Access Server (NAS) is the device that clients 85 dial in order to get access to the network. In PPTP termi- 86 nology this is referred to as the PPTP Access Concentrator 87 (PAC), and in L2TP terminology, it is referred to as the 88 L2TP Access Concentrator (LAC). 90 3.2. Purpose 92 As described in [1], there are now at least five services implementing 93 dialup roaming, and the number of Internet Service Providers involved 94 in roaming consortia is increasing rapidly. 96 In order to be able to offer roaming capability, one of the require- 97 ments is to be able to identify the user's home authentication server. 98 For use in roaming, this function is accomplished via the Network 99 Access Identifier (NAI) submitted by the user to the NAS in the ini- 100 tial PPP authentication. It is also expected that PACs and LACs will 101 use the NAI as part of the process of opening a new tunnel, in order 102 to determine the tunnel endpoint. 104 As proposed in this document, the Network Access Identifer is of the 105 form user@realm. Please note that while the realm is typically a Fully 106 Qualified Domain Name (FQDN) it is not required that this be the case, 107 and use of an FQDN as the realm does not imply use of DNS for location 108 of the RADIUS server or authentication routing. 110 Since to date roaming has been implemented on a relatively small 111 scale, existing implementations handle location of RADIUS servers 112 within a domain and perform authentication routing based on local 113 knowledge expressed in proxy configuration files. To date implementa- 114 tions have not found a need for use of DNS for location of the RADIUS 115 server within a domain, although this can be accomplished via use of 116 the DNS SRV record. Similarly, existing implementions have not found 117 a need for dynamic routing protocols, or propagation of global routing 118 information. 120 4. Formal Definition of the NAI 122 The grammar for the NAI is given below, using the augmented BNF nota- 123 tion described in reference [4]. 125 NAI = USERNAME ["@" REALM] 126 REALM = token "." token *[ "." token ] 127 USERNAME = token 129 Examples of valid Network Access Identifiers include: 131 fred 132 fred@bigco.com 133 nancy@eng.bigu.edu 135 Examples of invalid Network Access Identifiers include: 137 howard.edu 138 fred@bigco.com@smallco.com 139 bigco!fred@smallco.com 140 bigco%fred@smallco.com 142 5. Acknowledgements 144 Thanks to Glen Zorn of Microsoft for many useful discussions of this 145 problem space. 147 6. References 149 [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming 150 Implementations." Work in progress, draft-ietf-roamops-imprev-02.txt, 151 Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Merit, May, 1997. 153 [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 154 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 155 Daydreamer, January, 1997. 157 [3] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 158 1997. 160 [4] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." 161 draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. 163 7. Authors' Addresses 165 Bernard Aboba 166 Microsoft Corporation 167 One Microsoft Way 168 Redmond, WA 98052 170 Phone: 206-936-6605 171 EMail: bernarda@microsoft.com