Network Working Group F. Adrangi
Internet-Draft V. Lortz
Expires: February 6, 2005 Intel
F. Bari
AT&T Wireless
P. Eronen
Nokia
M. Watson
Nortel
August 8, 2004
Identity selection hints for Extensible Authentication Protocol (EAP)
draft-adrangi-eap-network-discovery-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 6, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a mechanism that allows an access network to
Adrangi, et al. Expires February 6, 2005 [Page 1]
Internet-Draft Identity selection hints for EAP August 2004
provide identity selection hints to an EAP client. The purpose is to
help the client in selecting the most appropriate identity and NAI
decoration to use. This solution is especially useful in roaming
scenarios where the access network does not have a direct
relationship with the client's home network, but instead a mediating
network, such as a roaming consortium or broker, is used.
1. Introduction
In many roaming situations, an access network can have several
roaming relationship, either with several home networks, or mediating
networks such as roaming consortiums and brokers, or both. A client
can also have several sets of credentials, and its home network may
have roaming relationships with several mediating networks.
This document defines a mechanism that allows the access network to
provide identity selection hints, and more specifically information
about its roaming relationships, to an EAP client. This information
is sent to the client in an EAP Identity Request message by appending
it after the displayable message and a NUL character.
Exactly how the identity hint information is used by the client
depends largely on the client's local policy and configuration, and
is outside the scope of this document.
One possible application for this mechanism is to help in selecting
what kind of NAI decoration [1] must be applied to allow proper
routing of AAA messages to the home AAA server. If there are several
possible mediating networks, the client can choose which one to use.
However, exactly how the selection is made is beyond the scope of
this document. See [6] for more detailed discussion about this
problem space.
1.1 Applicability
Although the proposed solution here is discussed in the context of
public IEEE 802.11 access networks, it is applicable to other access
networks that use EAP [2] for authentication and use the NAI format
[1] for identifying users.
This document assumes that the AAA protocol in use is RADIUS [8].
Diameter [7] could also be used instead of RADIUS without introducing
significant architectural differences.
1.2 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Adrangi, et al. Expires February 6, 2005 [Page 2]
Internet-Draft Identity selection hints for EAP August 2004
document are to be interpreted as described in [3].
Network Access Identifier (NAI)
An identifier that represents a client or user identity. The
basic structure of a NAI is user@realm, where the realm part of
the NAI indicates the domain responsible for interpretation and
resolution of the user name. See [1] for more details on NAI
format.
2. Packet format
Identity hint information is placed after the displayable string and
a NUL character in the EAP Identity Request. The following ABNF [4]
defines a "NAIRealms" attribute for presenting the identity hint
information. The attribute's value consists of a set of realm names
separated by a semicolon.
identity-request-data = [ displayable-string ]
[ %x00 "NAIRealms=" realm-list ]
displayable-string = *OCTET
realm-list = realm /
( realm-list ";" realm )
The "OCTET" rule is defined in [4] and the "realm" rule is defined in
[1].
A sample hex dump of an EAP Identity Request packet is shown below.
01 ; Code: Request
00 ; Identifier: 0
00 43 ; Length: 67 octets
01 ; Type: Identity
48 65 6c 6c 6f 21 00 4e ; "Hello\0NAIRealms=example.com;mnc014.
41 49 52 65 61 6c 6d 73 ; mcc310.3gppnetwork.org"
3d 69 73 70 2e 65 78 61
6d 70 6c 65 2e 63 6f 6d
3b 6d 6e 63 30 31 34 2e
6d 63 63 33 31 30 2e 33
67 70 70 6e 65 74 77 6f
72 6b 2e 6f 72 67
EAP does not support fragmentation for Identity Request messages, so
the size of identity hint information is limited by the link MTU.
The exact limit depends on the lower layer in question, but it is at
least 1020 octets.
Some existing systems are known to use Identity Request messages to
Adrangi, et al. Expires February 6, 2005 [Page 3]
Internet-Draft Identity selection hints for EAP August 2004
send proprietary information to the client. This proprietary
information is considered to be part of the displayable-string in the
ABNF shown above. In other words, the NUL character followed by the
NAIRealms list MUST be placed at the end.
3. Delivery mechanisms
This section describes three different options for delivering the
identity hint information to the client. The main difference is
which entity in the access network creates the EAP Identity Request:
this could be either the access point or a RADIUS server.
Access network operators can choose to deploy any of the options.
Client implementation MUST support all three options.
3.1 Option 1: Initial request from access point
In typical IEEE 802.11 wireless LANs, the initial EAP Identity
Request is sent by the access point. In the simplest case, the
identity hint information is simply included in this request, as
shown below.
Wireless AP AN RADIUS next RADIUS
client server server
| | | |
| 1. Association | | |
|------------------->| | |
| 2. EAP Id.Req. | | |
| (NAIRealms) | | |
|<-------------------| | |
| 3. EAP Id.Resp. | | |
|------------------->| | |
| | 4. Access-Request | |
| | (EAP Id.Resp.) | |
| |------------------->| |
| | | 5. Access-Request |
| | | (EAP Id.Resp.) |
| | |------------------->|
| | | |
| <-- EAP conversation --> |
Current access points do not support this mechanism, so other options
may be preferable. This option can also require configuring the
identity hint information in a potentially large number of access
points, which may be problematic if the information changes often.
Adrangi, et al. Expires February 6, 2005 [Page 4]
Internet-Draft Identity selection hints for EAP August 2004
3.2 Option 2: Initial request from access network RADIUS server
This is similar to Option 1, but the initial EAP Identity Request is
created by the access network RADIUS server instead of the access
point. Once a client associates with an access network AP using IEEE
802.11 procedures, the AP sends an EAP-Start message [5] within a
RADIUS Access-Request. The access network RADIUS server can then
send the EAP Identity Request containing the identity hint
information.
Wireless AP AN RADIUS next RADIUS
client server server
| | | |
| 1. Association | | |
|------------------->| | |
| | 2. Access-Request | |
| | (EAP-Start) | |
| |------------------->| |
| | 3.Access-Challenge | |
| | (EAP Id.Req. with | |
| | NAIRealms) | |
| |<-------------------| |
| 4. EAP Id.Req. | | |
| (NAIRealms) | | |
|<-------------------| | |
| 5. EAP Id.Resp. | | |
|------------------->| | |
| | 6. Access-Request | |
| | (EAP Id.Resp.) | |
| |------------------->| |
| | | 7. Access-Request |
| | | (EAP Id.Resp.) |
| | |------------------->|
| | | |
| <-- EAP conversation --> |
This option can work with current access points if they support the
EAP-Start message.
3.3 Option 3: Subsequent request from access network RADIUS server
In the third option, the access point sends the initial EAP Idntity
Request without any hint information. The client then responds with
an Identity Response, which is forwarded to the local RADIUS server.
If the RADIUS server cannot route the message based on the identity
provided by the client, it sends a second EAP Identity Request
containing the identity hint information.
Adrangi, et al. Expires February 6, 2005 [Page 5]
Internet-Draft Identity selection hints for EAP August 2004
Wireless AP AN RADIUS next RADIUS
client server server
| | | |
| 1. Association | | |
|------------------->| | |
| 2. EAP Id.Req. | | |
| (w/o NAIRealms) | | |
|<-------------------| | |
| 3. EAP Id.Resp. | | |
|------------------->| | |
| | 4. Access-Request | |
| | (EAP Id.Resp.) | |
| |------------------->| |
| | 5.Access-Challenge | |
| | (EAP Id.Req. with | |
| | NAIRealms) | |
| |<-------------------| |
| 6. EAP Id.Req. | | |
| (NAIRealms) | | |
|<-------------------| | |
| 7. EAP Id.Resp. | | |
|------------------->| | |
| | 8. Access-Request | |
| | (EAP Id.Resp.) | |
| |------------------->| |
| | | 9. Access-Request |
| | | (EAP Id.Resp.) |
| | |------------------->|
| | | |
| <-- EAP conversation --> |
When the initial RADIUS Access-Request is received, if the access
network RADIUS proxy cannot route the RADIUS packet to the next AAA
hop, it SHOULD send identity hint information to the client (via
Access-Challenge encapsulating an EAP Identity Request). When a
subsequent RADIUS Access-Request is received, if the access network
RADIUS proxy still cannot route the RADIUS packet to the next AAA
hop, then it SHOULD discard the packet. Optionally, the access
network RADIUS server can also send an error notification (via
Access-Challenge encapsulating an EAP Notification) with an
appropriate error message.
This option does not require changes to existing NASes, so it may be
preferable in many environments.
4. IANA Considerations
This document does not define any new namespaces to be managed by
Adrangi, et al. Expires February 6, 2005 [Page 6]
Internet-Draft Identity selection hints for EAP August 2004
IANA, and does not require any assignments in existing namespaces.
5. Security considerations
Identity hint information is delivered inside an EAP Identity Request
before the user authenticates to the network, and before the network
is authenticated to the user. This information can be modified by an
attacker. Therefore, is MUST be considered just an unauthenticated
hint that does not override any local policies at the client.
In case the identity hint information is used to select a mediating
network for NAI decoration, it should be noted that at least with
some EAP methods, there is no way for the home network RADIUS server
to verify that the mediating network used was actually the same one
that the client had requested.
6. Acknowledgements
The authors would specially like to thank Jari Arkko and Bernard
Aboba for their help in scoping the problem, for reviewing the draft
work in progress and for suggesting improvements to it.
The authors would also like to acknowledge and thank Adrian Buckley,
Blair Bullock, Jose Puthenkulam, Johanna Wild, Joe Salowey, Marco
Spini, Simone Ruffino, Mark Grayson, and Avi Lior for their support,
feedback and guidance during the various stages of this work.
7. References
7.1 Normative references
[1] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network
Access Identifier", draft-arkko-roamops-rfc2486bis-02 (work in
progress), July 2004.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
7.2 Informative references
[5] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In
Adrangi, et al. Expires February 6, 2005 [Page 7]
Internet-Draft Identity selection hints for EAP August 2004
User Service) Support For Extensible Authentication Protocol
(EAP)", RFC 3579, September 2003.
[6] Arkko, J. and B. Aboba, "Network Discovery and Selection
Problem", draft-ietf-eap-netsel-problem-01 (work in progress),
July 2004.
[7] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
[8] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
Authors' Addresses
Farid Adrangi
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503-712-1791
EMail: farid.adrangi@intel.com
Victor Lortz
Intel Corporation
2111 N.E. 25th Avenue
Hillsboro, OR 97124
USA
Phone: +1 503-264-3253
EMail: victor.lortz@intel.com
Farooq Bari
AT&T Wireless
7277 164th Avenue N.E.
Redmond, WA 98052
USA
Phone: +1 425-580-5526
EMail: farooq.bari@attws.com
Adrangi, et al. Expires February 6, 2005 [Page 8]
Internet-Draft Identity selection hints for EAP August 2004
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Mark Watson
Nortel Networks
2221 Lakeside Blvd
Richardson, TX 75082
USA
EMail: mwatson@nortel.com
Adrangi, et al. Expires February 6, 2005 [Page 9]
Internet-Draft Identity selection hints for EAP August 2004
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Adrangi, et al. Expires February 6, 2005 [Page 10]