One document matched: draft-nakhjiri-preauth-aaa-req-00.txt
Network Working Group M. Nakhjiri
Internet-Draft Huawei USA
Intended status: Informational Y. Ohba
Expires: March 19, 2007 Toshiba
September 15, 2006
Pre-Authentication AAA requirements
draft-nakhjiri-preauth-aaa-req-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 March 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Nakhjiri & Ohba Expires March 19, 2007 [Page 1]
Internet-Draft Preauth-AAA requirements September 2006
Abstract
Pre-authentication as a solution for providing expedited
authenticataion service as part of handover is being considered
within a potentially new working group. This draft intends to
describe the requirements set forth by Pre-authentication procedure
on AAA protocols and attributes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . . . . 3
3. Problem Description . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative references . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Nakhjiri & Ohba Expires March 19, 2007 [Page 2]
Internet-Draft Preauth-AAA requirements September 2006
1. Introduction
When the mobile changes attaches to the network, it is often required
that the mobile authenticates to the network and receives
authorization for the services it is requesting. During handover,
i.e. when the mobile changes its point of attachment to the network,
it is typically required of the mobile to perform the authentication
and authorization process through the new point of attachment. It is
becoming more and more common that the authentication and
authorization process includes an EAP authentication process
[RFC3748], which is typically both delay and message intensive. Pre-
authentication is defined as a handover optimization technique that
is based on executing EAP between a mobile node and a target
authenticator via the serving authenticator before the mobile node
handovers to the target authenticator, so that the delay involved in
performing EAP signaling is eliminated from the handover critical
path to the extent possible. The motivation and problem statement
for pre-authentication is described in details in
[I-D.ohba-hokeyp-preauth-ps]. However, both the authentication and
the authorization process is typically performed between a mobile
entity (peer) and a central AAA server, it is important to describe
the functionality required from the AAA protocols and servers to
support the pre-authentication process. This document intends to
tackle the latter problem beyond what is described in the
documentations describing encapsulation of EAP messaging inside AAA
protocol messages (RADIUS [RFC3579] or Diameter [RFC4072]).
2. Terminology and Assumptions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Most of the terminology found in this document uses the EAP keying
document [I-D.ietf-eap-keying].
AAA server: The entity that is the main point of trust and
authorization (AAA) in the administrative domain, and maintains
peer information and possibly keying information. The AAA server
relies on EAP server for execution of EAP-method authentications.
EAP server: The EAP server in pre-authentication has the same
functionality of a backend EAP server in [RFC3748] and
[I-D.ietf-eap-keying], i.e, the EAP server terminates the EAP
authentication method with peer through a pass-through
authenticator and can perform keying functions.
Nakhjiri & Ohba Expires March 19, 2007 [Page 3]
Internet-Draft Preauth-AAA requirements September 2006
EAP pass-through authenticator: The pass-through authenticator is
the entity between a peer and a backend EAP server that is passing
through EAP Request and Response messages ([RFC3748]) without
understanding their data content. It can understand EAP success
and failure messages. The role of pass-through authenticator
during EAP authentication is defined in [RFC3748].
3. Problem Description
Most of the AAA documentations today do not distinguish between a
full authentication and a pre-authentication and this creates a set
of open issues:
Pre-authentication authorization: Many users may not be allowed to
have more than one logon session at the time. This means, when
such users actively engage in an active session (as a result of a
previously valid authentication), they will not be able to perform
pre-authentication. The AAA server currently has no way of
distinguishing between a full authentication request and a pre-
authentication request.
Pre-authentication life time : Currently AAA protocols define
attributes (AVPs) carrying life time information for a full
authentication session. Even when a user profile and the AAA
server support pre-authentication function, after the pre-
authentication of a peer is complete, since the pre-authentication
may be accompanied with a pre-authorization, the pre-
authentication is typically valid only for a short amount of time.
It is currently not possible for a AAA server to indicate to the
AAA client/ NAS or a peer what the life time of the pre-
authenticated session is. In other words, it is not clear to the
peer or the NAS, when the pre-authentication will expire.
Pre-authentication retries: It is typically expected that shortly
following the pre-authentication process, the mobile entity moves
to the new point of attachment and converts the pre-authentication
state to a full authentication state (the procedure for which is
not the topic of this particular subsection). However, if the
peer has yet not moved to the new location and realizes that the
pre-authentication is expiring, it may perform another pre-
authentication. In order to avoid unlimited number of pre-
authentication tries, it is quite possible that the network policy
sets a limit on the maximum number of pre-authentication attempts.
Nakhjiri & Ohba Expires March 19, 2007 [Page 4]
Internet-Draft Preauth-AAA requirements September 2006
Completion of network attachment: Once the peer has successfully
attached to the new point of attachment, it needs to convert its
authentication state from pre-authenticated to fully attached and
authenticated. There may need to be a mechanism within the AAA
protocol to provide this indication to the AAA server.
Session Resumption In case the peer ping pongs between a network N1
with which it has a full authentication state to another network
N2 and then back to N1, it should possible to simply convert the
full authentication state to a pre-authenticated state. The
problems around handling session life time and keying material
caching needs to be dealt with.
multiple candidate authenticators: There may be situations where the
mobile node may need to make a selection between a number of
candidate attachment points. In such cases it is desirable for
the mobile to perform pre-authentication with multiple
authenticators. In such cases the AAA server may need to be aware
of the situation.
roaming support In case the pre-authentication is being performed
through a serving network that is foreign to the MN's home AAA
server, the AAA server needs to obtain information about the
serving network, so that the AAA server can make authorization
decisions accordingly (Madjid: I am not sure I understand what
this is all about?? need more details).
Inter-technology support Current specifications on pre-
authentication mostly deal with homogeneous 802.11 networks. The
AAA attributes such as Calling-Station-ID [I-D.aboba-radext-wlan]
may need to be expanded to cover other access technologies.
Furthermore, heterogeneous handovers may require change of the MN
identifier as part of the handover. Investigation on the best
type of identifiers for multi-access technology MNs is required.
Network controlled handovers It is becoming quite common for the
network operators to maintain the control over the handovers for
among other thing load balancing and performance reasons. Hence
the network may need to direct the MN to perform pre-
authentication to one a set of candidate authenticators in an
anticipation for a handover. The AAA protocol extensions for
carrying out such procedures needs to be provided.
Nakhjiri & Ohba Expires March 19, 2007 [Page 5]
Internet-Draft Preauth-AAA requirements September 2006
4. Security Considerations
This document discusses the requirements of the pre-authentication
solution for a AAA protocol. Signaling of pre-authentication
specific data carried over AAA messages through AAA attributes will
have security implications and will place specific requirements on
the AAA entities and the AAA protocol, which may or may not be
natively met by the AAA protocol, depending on what protocol is
chosen. Therefore, the choice of the AAA protocol will effect the
security considerations. Some examples are as follows
Key Management: Guidance on parameters required, caching, storage
and deletion procedures for the keying material to ensure adequate
security and authorization provisioning may need to be defined in
a solution document or in this document.
AAA proxies: One important issue arises from the way the
authorization decisions might be handled at the AAA server during
network access authentication. For example, if AAA proxies are
involved, they may also influence in the authorization decision.
Channel Binding TBD
More details are TBD.
5. IANA consideration
This document may later on require allocation of specific RADIUS
attributes or Diameter AVPs, which require IANA assignments. The
specifics are currently TBD.
6. Acknowledgements
The authors would like to thank Alper Yegin for initiation of this
work.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
Nakhjiri & Ohba Expires March 19, 2007 [Page 6]
Internet-Draft Preauth-AAA requirements September 2006
RFC 3748, June 2004.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-14 (work in
progress), June 2006.
[I-D.ohba-hokeyp-preauth-ps]
Ohba, Y., "Pre-authentication Problem Statement",
draft-ohba-hokeyp-preauth-ps-00 (work in progress),
April 2006.
[I-D.aboba-radext-wlan]
Aboba, B., "RADIUS Attributes for WLAN",
draft-aboba-radext-wlan-03 (work in progress), June 2006.
7.2. Informative references
[802.11r] Institute of Electrical and Electronics Engineer, "Draft
Amendment to STANDARD FOR Information Technology -
Telecommunications and Information Exchange Between
Systems - LAN/MAN Specific Requirements. Part 11:Wireless
LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications: Amendment 8: Fast BSS Transition", IEEE
std. 802.11r/D2.0.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-03 (work in
progress), July 2006.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
Nakhjiri & Ohba Expires March 19, 2007 [Page 7]
Internet-Draft Preauth-AAA requirements September 2006
Authors' Addresses
Madjid Nakhjiri
Huawei USA
12040 98th AVE NE, Suite 200B
Kirkland, WA 98034
USA
Email: mnakhjiri@Huawei.com
Yoshihiro Ohba
Toshiba America Research,Inc
1 Telcordia Dr.
Piscataway, NJ 08854
USA
Email: yohba@tari.toshiba.com
Nakhjiri & Ohba Expires March 19, 2007 [Page 8]
Internet-Draft Preauth-AAA requirements September 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nakhjiri & Ohba Expires March 19, 2007 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-23 03:37:58 |