(user)@example.net
<nancy>@example.net
3. Security Considerations
Since an NAI reveals the home affiliation of a user, it may assist an
attacker in further probing the username space. Typically, this
problem is of most concern in protocols that transmit the username in
clear-text across the Internet, such as in RADIUS, described in
[RFC2865] and [RFC2866]. In order to prevent snooping of the
username, protocols may use confidentiality services provided by
protocols transporting them, such as RADIUS protected by IPsec
[RFC3579] or Diameter protected by TLS [RFC3588].
This specification adds the possibility of hiding the username part
in the NAI, by omitting it. As discussed in Section 2.3, this is
possible only when NAIs are used together with a separate
authentication method that can transfer the username in a secure
manner. In some cases, application-specific privacy mechanism have
also been used with NAIs. For instance, some Extensible
Authentication Protocol (EAP) methods apply method-specific
pseudonyms in the username part of the NAI [RFC3748]. While neither
of these approaches can protect the realm part, their advantage over
transport protection is that privacy of the username is protected,
even through intermediate nodes such as NASes.
4. IANA Considerations
In order to avoid creating any new administrative procedures,
administration of the NAI realm namespace piggybacks on the
administration of the DNS namespace.
NAI realm names are required to be unique, and the rights to use a
given NAI realm for roaming purposes are obtained coincident with
acquiring the rights to use a particular Fully Qualified Domain Name
(FQDN). Those wishing to use an NAI realm name should first acquire
the rights to use the corresponding FQDN. Using an NAI realm without
ownership of the corresponding FQDN creates the possibility of
conflict and therefore is to be discouraged.
Note that the use of an FQDN as the realm name does not require use
of the DNS for location of the authentication server. While Diameter
[RFC3588] supports the use of DNS for location of authentication
servers, existing RADIUS implementations typically use proxy
configuration files in order to locate authentication servers within
a domain and perform authentication routing. The implementations
described in [RFC2194] did not use DNS for location of the
authentication server within a domain. Similarly, existing
implementations have not found a need for dynamic routing protocols
or propagation of global routing information. Note also that there
is no requirement that the NAI represent a valid email address.
5. References
5.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October
2005.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
5.2. Informative References
[RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, August 1982.
[RFC2194] Aboba, B., Lu, J., Alsop, J., Ding, J., and W. Wang,
"Review of Roaming Implementations", RFC 2194,
September 1997.
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco
Layer Two Forwarding (Protocol) "L2F"", RFC 2341,
May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC 2486, January 1999.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J.,
Little, W., and G. Zorn, "Point-to-Point Tunneling
Protocol", RFC 2637, July 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling
Protocol "L2TP"", RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June
2000.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G.,
and J. Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
and H. Levkowetz, "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.
[netsel-problem] Arkko, J. and B. Aboba, "Network Discovery and
Selection Problem", Work in Progress, October 2005.
Appendix A. Changes from RFC 2486
This document contains the following updates with respect to the
original NAI definition in RFC 2486 [RFC2486]:
o International character set support has been added for both
usernames and realms. Note that this implies character codes 128
- 255 may be used in the username portion, which may be
unacceptable to nodes that only support RFC 2486. Many devices
already allow this behaviour, however.
o Username privacy support has been added. Note that NAIs without a
username (for privacy) may not be acceptable to RFC 2486-compliant
nodes. Many devices already allow this behaviour, however.
o A recommendation to support NAI length of at least 253 octets has
been added, and compatibility considerations among NAI lengths in
this specification and various AAA protocols are discussed. Note
that long NAIs may not be acceptable to RFC 2486-compliant nodes.
o The mediating network syntax and its implications have been fully
described and not given only as an example. Note that this syntax
is not intended to be a full solution to network discovery and
selection needs as defined in [netsel-problem]. Rather, it is
intended as a clarification of RFC 2486.
However, as discussed in Section 2.7, this specification requires
that this syntax be applied only when there is explicit knowledge
that the peer system supports such syntax.
o The realm BNF entry definition has been changed to avoid an error
(infinite recursion) in the original specification.
o Several clarifications and improvements have been incorporated
into the ABNF specification for NAIs.
Appendix B. Acknowledgements
Thanks to Glen Zorn for many useful discussions of this problem
space, and to Farid Adrangi for suggesting the representation of
mediating networks in NAIs. Jonathan Rosenberg reported the BNF
error. Dale Worley suggested clarifications of the x and special BNF
entries. Arne Norefors reported the length differences between RFC
2486 and RFC 2865. Paul Hoffman helped with the international
character set issues. Kalle Tammela, Stefaan De Cnodder, Nagi
Jonnala, Bert Wijnen, Blair Bullock, Yoshihiro Ohba, Ignacio Goyret,
John Loughney, Henrik Levkowetz, Ted Hardie, Bill Fenner, Sam
Hartman, and Richard Perlman provided many useful comments on this
document. The ABNF validator at http://www.apps.ietf.org/abnf.html
was used to verify the syntactic correctness of the ABNF in
Section 2.1.
Authors’ Addresses
Bernard Aboba
Microsoft
One Microsoft Way
Redmond, WA 98052
USA
EMail: bernarda@microsoft.com
Mark A. Beadles
ENDFORCE
565 Metro Place South Suite 300
Dublin OH 43017
USA
EMail: mbeadles@endforce.com
Jari Arkko
Ericsson
Jorvas 02420
Finland
EMail: jari.arkko@ericsson.com
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.