The Network Access Identifier
RFC 4282
Document | Type |
RFC - Proposed Standard
(December 2005; Errata)
Obsoleted by RFC 7542
Obsoletes RFC 2486
|
|
---|---|---|---|
Authors | Mark Beadles , Jari Arkko , Bernard Aboba , Pasi Eronen | ||
Last updated | 2020-01-21 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4282 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | David Kessens | ||
Send notices to | dnelson@enterasys.com |
Network Working Group B. Aboba Request for Comments: 4282 Microsoft Obsoletes: 2486 M. Beadles Category: Standards Track ENDFORCE J. Arkko Ericsson P. Eronen Nokia December 2005 The Network Access Identifier Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract In order to provide roaming services, it is necessary to have a standardized method for identifying users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client during network authentication. "Roaming" may be loosely defined as the ability to use any one of multiple Internet Service Providers (ISPs), while maintaining a formal, customer-vendor relationship with only one. Examples of where roaming capabilities might be required include ISP "confederations" and ISP-provided corporate network access support. This document is a revised version of RFC 2486, which originally defined NAIs. Enhancements include international character set and privacy support, as well as a number of corrections to the original RFC. Aboba, et al. Standards Track [Page 1] RFC 4282 The Network Access Identifier December 2005 Table of Contents 1. Introduction ....................................................2 1.1. Terminology ................................................3 1.2. Requirements Language ......................................4 1.3. Purpose ....................................................4 2. NAI Definition ..................................................4 2.1. Formal Syntax ..............................................4 2.2. NAI Length Considerations ..................................6 2.3. Support for Username Privacy ...............................6 2.4. International Character Sets ...............................7 2.5. Compatibility with E-Mail Usernames ........................8 2.6. Compatibility with DNS .....................................8 2.7. Realm Construction .........................................8 2.8. Examples ..................................................10 3. Security Considerations ........................................10 4. IANA Considerations ............................................11 5. References .....................................................11 5.1. Normative References ......................................11 5.2. Informative References ....................................12 Appendix A. Changes from RFC 2486 ................................14 Appendix B. Acknowledgements .....................................14 1. Introduction Considerable interest exists for a set of features that fit within the general category of "roaming capability" for network access, including dialup Internet users, Virtual Private Network (VPN) usage, wireless LAN authentication, and other applications. Interested parties have included the following: o Regional Internet Service Providers (ISPs) operating within a particular state or province, looking to combine their efforts with those of other regional providers to offer dialup service over a wider area. o National ISPs wishing to combine their operations with those of one or more ISPs in another nation to offer more comprehensive dialup service in a group of countries or on a continent. o Wireless LAN hotspots providing service to one or more ISPs. o Businesses desiring to offer their employees a comprehensive package of dialup services on a global basis. Those services may include Internet access as well as secure access to corporate intranets via a VPN, enabled by tunneling protocols such as the Aboba, et al. Standards Track [Page 2] RFC 4282 The Network Access Identifier December 2005 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], the Layer 2 Forwarding (L2F) protocol [RFC2341], the Layer 2 TunnelingShow full document text