idnits 2.17.1 draft-ietf-roamops-nai-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-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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 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 5 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 59 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 99 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 11 has weird spacing: '...), its areas...' == Line 12 has weird spacing: '... its worki...' == Line 16 has weird spacing: '... and may ...' == Line 17 has weird spacing: '...afts as refer...' == Line 20 has weird spacing: '... To learn...' == (54 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 171, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-roamops-imprev-01 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-imprev (ref. '1') == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-02 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '2') ** Obsolete normative reference: RFC 2058 (ref. '3') (Obsoleted by RFC 2138) ** Obsolete normative reference: RFC 2059 (ref. '4') (Obsoleted by RFC 2139) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-01 == Outdated reference: A later version (-10) exists of draft-ietf-pppext-pptp-00 ** Downref: Normative reference to an Informational draft: draft-ietf-pppext-pptp (ref. '6') == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '7') == Outdated reference: A later version (-07) exists of draft-ietf-radius-tunnel-imp-00 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-imp (ref. '8') -- Unexpected draft version: The latest known version of draft-ietf-http-v11-spec is -06, but you're referring to -07. == Outdated reference: A later version (-03) exists of draft-ietf-roamops-dnsrr-00 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 19 errors (**), 0 flaws (~~), 17 warnings (==), 4 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 Corporation 4 6 The Network Access Identifier 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 12 its working groups. Note that other groups may also distribute work- 13 ing documents 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 mate- 18 rial 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 23 (Europe), 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 September 1, 1997. Please send 27 comments to the authors. 29 2. Abstract 31 This document describes issues relating to user identification in pro- 32 vision of "roaming capability" for dialup Internet users. "Roaming 33 capability" may be loosely defined as the ability to use any one of 34 multiple Internet service providers (ISPs), while maintaining a for- 35 mal, customer-vendor relationship with only one. Examples of cases 36 where roaming capability might be required include ISP "confedera- 37 tions" and ISP-provided corporate network access support. 39 3. Introduction 41 Considerable interest has arisen recently in a set of features that 42 fit within the general category of "roaming capability" for dialup 43 Internet users. Interested parties have included: 45 Regional Internet Service Providers (ISPs) operating within a 46 particular state or province, looking to combine their efforts 47 with those of other regional providers to offer dialup service 48 over a wider area. 50 National ISPs wishing to combine their operations with those of 51 one or more ISPs in another nation to offer more comprehensive 52 dialup service in a group of countries or on a continent. 54 Businesses desiring to offer their employees a comprehensive 55 package of dialup services on a global basis. Those services may 56 include Internet access as well as secure access to corporate 57 intranets via a Virtual Private Network (VPN), enabled by tunnel- 58 ing protocols such as PPTP, L2F and L2TP. 60 This document focuses on issues of user identification for use in 61 roaming services. However, since roaming and tunneling are closely 62 related, it is believed that the considerations described here will 63 also be of interest to those working on tunneling. 65 3.1. Terminology 67 This document frequently uses the following terms: 69 Network Access Identifier 70 The Network Access Identifier (NAI) is the userID submitted 71 by the client during the PPP negotiation. In roaming, the 72 purpose of the NAI is to identify the user as well as to 73 assist in the routing of the authentication request. As 74 such, the NAI may be presented either in the form of an 75 authentication route, or a pointer to such a route. Please 76 note that the NAI may not necessarily be the same as the 77 user's e-mail address or the userID submitted in an applica- 78 tion layer authentication (i.e. HTTP authentication). In 79 order to avoid confusion on this point, a new term was 80 coined. 82 Network Access Server 83 The Network Access Server (NAS) is the device that clients 84 dial in order to get access to the network. In PPTP termi- 85 nology this is referred to as the PPTP Access Concentrator 86 (PAC), and in L2TP terminology, it is referred to as the 87 L2TP Access Concentrator (LAC). 89 RADIUS server 90 This is a server which provides for authentication/autho- 91 rization via the protocol described in [3], and for account- 92 ing as described in [4]. 94 RADIUS proxy 95 In order to provide for the routing of RADIUS authentication 96 and accounting requests, a RADIUS proxy may employed. To the 97 NAS, the RADIUS proxy acts as a RADIUS server, and to the 98 RADIUS server, the proxy acts as a RADIUS client. 100 3.2. Purpose 102 As described in[1], there are now at least four services implementing 103 dialup roaming, and the number of Internet Service Providers involved 104 in roaming consortia is increasing rapidly. 106 In order to be able to offer roaming capability, one of the require- 107 ments is to be able to identify the user's home authentication server. 108 For use in roaming, this function is accomplished via the NAI submit- 109 ted by the user to the NAS in the initial PPP authentication. 111 This document proposes syntax and semantics for the NAI. It is 112 expected that this will be of interest for support of roaming as well 113 as tunneling. For example, references [5] and [6] refer to use of the 114 NAI in determining the tunnel endpoint. However, these references do 115 not provide guidelines for how RADIUS or tunnel routing is to be 116 accomplished. In order to avoid the possibility of conflicting and 117 non-interoperable implementations, references [7] and [8] describe how 118 RADIUS and tunneling protocols may be integrated. This document pro- 119 vides guidance in the use of the NAI that is relevant to both the 120 roaming and tunneling communities. 122 4. Formal Definition of the NAI 124 As proposed in this specification, the Network Access Identifer is of 125 the form user@domain, where the domain is a fully qualified domain 126 name (FQDN). The syntax for the NAI is independent of the method used 127 to route the authentication. 129 In order to support the determination of the existence of a business 130 relationship between the local ISP and the home domain, one of two 131 methods may be used. If the number of domains to be served is small, 132 then it is possible to provide business relationship information via 133 the authentication proxy configuration file. If the number of domains 134 to be served is large, then a more scalable mechanism is recommended, 135 such as use of the DNS Roaming Relationship resource record, as 136 described in [10]. However, even if use of the DNS is enabled, an 137 authentication proxy will typically consult its configuration file for 138 information on business relationships, prior to retrieving information 139 via DNS. 141 4.1. BNF for the NAI 143 The grammar for the NAI is given below, using the augmented BNF nota- 144 tion described in reference [9]. 146 NAI = USERNAME "@" FQDN 147 FQDN = token "." token *[ "." token ] 148 USERNAME = token 150 Examples of valid Network Access Identifiers include: 152 fred@bigco.com 153 nancy@howard.edu 155 Examples of invalid Network Access Identifiers include: 157 bigco 158 howard.edu 160 5. Acknowledgements 162 Thanks to Glen Zorn of Microsoft for many useful discussions of this 163 problem space. 165 6. References 167 [1] B. Aboba, J. Lu, J. Alsop, J. Ding. "Review of Roaming Implemen- 168 tations." draft-ietf-roamops-imprev-01.txt, Microsoft, Aimnet, i-Pass 169 Alliance, Asiainfo, January, 1997. 171 [2] B. Aboba, G. Zorn. "Dialup Roaming Requirements." draft-ietf- 172 roamops-roamreq-02.txt, Microsoft, January, 1997. 174 [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- 175 cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, 176 Daydreamer, January, 1997. 178 [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 179 1997. 181 [5] K. Hamzeh, T. Kolar, M. Littlewood, G. S. Pall, J. Taarud, A. J. 182 Valencia, W. Verthein. "Layer Two Tunneling Protocol -- L2TP." draft- 183 ietf-pppext-l2tp-01.txt, Ascend Communications, December, 1996. 185 [6] K. Hamzeh, G. S. Pall, J. Taarud, W. Verthein, W. A. Little. 186 "Point-to-Point Tunneling Protocol -- PPTP." draft-ietf-pppext- 187 pptp-00.txt, Ascend Communications, June, 1996. 189 [7] G. Zorn. "RADIUS Attributes for Tunnel Protocol Support." draft- 190 ietf-radius-tunnel-auth-00.txt, Microsoft Corporation, November, 1996. 192 [8] B. Aboba. "Implementation of Mandatory Tunneling via RADIUS." 193 draft-ietf-radius-tunnel-imp-00.txt, Microsoft Corporation, February, 194 1997. 196 [9] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." 197 draft-ietf-http-v11-spec-07, UC Irvine, August, 1996. 199 [10] B. Aboba. "The Roaming Relationship (RR) Record in the DNS." 200 draft-ietf-roamops-dnsrr-00.txt, Microsoft Corporation, February, 201 1997. 203 7. Authors' Addresses 205 Bernard Aboba 206 Microsoft Corporation 207 One Microsoft Way 208 Redmond, WA 98052 210 Phone: 206-936-6605 211 EMail: bernarda@microsoft.com