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 Tunneling
Show full document text