Internet DRAFT - draft-ietf-pana-mobopts
draft-ietf-pana-mobopts
Network Working Group D. Forsberg (Ed.)
Internet-Draft Nokia
Expires: April 24, 2006 Y. Ohba
Toshiba
B. Patil
Nokia
H. Tschofenig
Siemens
A. Yegin
Samsung
October 21, 2005
PANA Mobility Optimizations
draft-ietf-pana-mobopts-01.txt
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 April 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This specification describes PANA optimizations for handling
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 1]
Internet-Draft PANA MobOpts October 2005
mobility. Proposed optimizations aim reducing protocol latency and
signaling associated with PANA-based network access AAA.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
6. Keying Considerations . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 2]
Internet-Draft PANA MobOpts October 2005
1. Introduction
A PaC using PANA [I-D.ietf-pana-pana] MUST execute full EAP/PANA upon
inter-subnet (inter-PAA) movement. In case seamless mobility is
desirable, having to execute full EAP authentication with a AAA
server would incur undesirable latency. This document outlines the
required extensions to the base PANA specification to eliminate the
need to execute EAP each time the PaC performs an inter-PAA handover.
The scheme described in this document allows creation of a new PANA
session with a new PAA based on an existing session with another PAA.
Generation of the new PANA session does not require executing EAP-
based authentication. Instead, a context-transfer-based scheme is
used to bring in relevant state information from the previous PAA to
the new PAA.
It should be noted that this document is limited to describing AAA
optimizations on the PANA protocol. Additional optimizations aiming
at EAP or specific AAA backend protocols (e.g., RADIUS, Diameter) can
be defined independently. Furthermore, specification of the required
context-transfer mechanism is left to other documents
([I-D.bournelle-pana-ctp]).
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 3]
Internet-Draft PANA MobOpts October 2005
2. Requirements notation
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].
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 4]
Internet-Draft PANA MobOpts October 2005
3. Framework
The call flow depicting mobility-optimized PANA execution is shown
below.
PaC newPAA prePAA
| | |
1 |<---------- live PANA session ----------->|
| | |
2 x move from subnet1 | |
| to subnet2 | |
| | |
| PDI | |
3 |---------------------->| |
| PSR | |
4 |<----------------------| |
| PSA | |
5 |---------------------->| CT-req |
6 | |----------------->|
| | CT-resp |
7 | PBR |<-----------------|
8 |<----------------------| |
| PBA | |
9 |---------------------->| |
In this flow, the PaC is already authorized and connected to subnet1,
where prePAA resides (step 1). Later, the PaC performs a handover
from subnet1 to subnet2 (step 2). Following the movement, PANA
discovery and handshake phases are executed (steps 3-5). In response
to the parameters included in the PSA, PANA session context is
transferred from the prePAA to the newPAA (steps 6,7). Finally,
PANA-Bind exchange signals the successful PANA authorization (steps
8,9). In this flow, EAP authentication does not take place.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 5]
Internet-Draft PANA MobOpts October 2005
4. Protocol Details
A mobile PaC's network access authentication performance can be
enhanced by deploying a context-transfer-based mechanism, where some
session attributes are transferred from the previous PAA to the new
one in order to avoid performing a full EAP authentication (reactive
approach). Additional mechanisms that are based on the proactive AAA
state establishment at one or more candidate PAAs may be developed in
the future (see for example [I-D.irtf-aaaarch-handoff]'). The
details of a context-transfer-based mechanism is provided in this
section.
Upon changing its point of attachment, a PaC that wants to quickly
resume its ongoing PANA session without running EAP MAY send its
unexpired PANA session identifier in its PANA-Start-Answer message.
Along with the Session-Id AVP, a MAC AVP MUST be included in this
message. The MAC AVP is computed by using the PANA_MAC_KEY shared
between the PaC and its previous PAA that has an unexpired PANA
session with the PaC. This action signals the PaC's desire to
perform the mobility optimization. In the absence of a Session-Id
AVP in this message, the PANA session takes its usual course (i.e.,
EAP-based authentication is performed).
If a PAA receives a session identifier in the PANA-Start-Answer
message, and it is configured to enable this optimization, it SHOULD
retrieve the PANA session attributes from the previous PAA. The
identity of the previous PAA is determined by looking at the
DiameterIdentity part of the PANA session identifier. The MAC AVP
can only be verified by the previous PAA, therefore a copy of the
PANA message MUST be provided to the previous PAA. The mechanism
required to send a copy of the PANA-Start-Answer message from current
PAA to the previous PAA, and to retrieve the session attributes is
outside the scope of PANA protocol. The Context Transfer Protocol
[I-D.ietf-seamoby-ctp] might be useful for this purpose.
When the previous or current PAA is not configured to enable this
optimization, the current PAA can not retrieve the PANA session
attributes, or the PANA session has already expired (i.e., session
lifetime is zero), the PAA MUST send the PANA-Auth-Request message
with a new session identifier and let the PANA exchange take its
usual course. As a result the PaC will engage in EAP-based
authentication and create a fresh PANA session from scratch.
In case the current PAA can retrieve the on-going PANA session
attributes from the previous PAA, the PANA session continues with a
PANA-Bind exchange.
As part of the context transfer, an intermediate AAA-Key material is
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 6]
Internet-Draft PANA MobOpts October 2005
provided by the previous PAA to the current PAA.
AAA-Key-int = The first N bits of
HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
The value of N depends on the integrity protection algorithm in use,
i.e., N=160 for HMAC-SHA1. DiameterIdentity is the identifier of the
current (new) PAA. Session-ID is the identifier of the PaC's PANA
session with the previous PAA.
The current PAA and the PaC compute the new AAA-Key by using the
nonce values and the AAA-Key-int.
AAA-Key-new = The first N bits of
HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)
New PANA_MAC_KEY is computed based on the algorithm described in
[I-D.ietf-pana-pana], by using the new AAA-Key and the new Session-ID
assigned by the current PAA. The MAC AVP contained in the PANA-Bind-
Request and PANA-Bind-Answer messages MUST be generated and verified
by using the new PANA_MAC_KEY. The Session-ID AVP MUST include a new
session identifier assigned by the current PAA. A new PANA session
is created upon successful completion of this exchange.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 7]
Internet-Draft PANA MobOpts October 2005
5. Deployment Considerations
Correct operation of this optimization relies on many factors,
including applicability of authorization state from one network
attachment to another. [I-D.ietf-eap-keying] identifies this
operation as "fast handoff" and provides deployment considerations.
Operators are recommended to take those guidelines into account when
using this optimization in their networks.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 8]
Internet-Draft PANA MobOpts October 2005
6. Keying Considerations
Upon PaC's movement to a another PAA (new PAA) and request to perform
a context transfer based optimization, the previous PAA computes a
AAA-Key-int based on the AAA-Key, ID of new PAA, and the session ID.
This AAA-Key-int is delivered to the new PAA, and used in the
computation of the AAA-Key-new, which further takes a pair of nonce
values into account. After this point on, the AAA-Key-new becomes
the AAA-Key between the PaC and the new PAA.
The AAA-Key-int can be deleted as soon as AAA-Key-new is derived.
The lifetime of AAA-Key-new is bounded by the lifetime of AAA-Key.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 9]
Internet-Draft PANA MobOpts October 2005
7. Security Considerations
The mobility optimization described in this document involves the
previous PAA (possessing the AAA-Key) providing a AAA-Key-new to the
current PAA of the PaC. There are security risks stemming from
potential compromise of PAAs. Compromise of the current PAA does not
yield compromise of the previous PAA, as the AAA-Key cannot be
computed from a compromised AAA-Key-new. But a compromised previous
PAA along with the intercepted nonce values on the current link leads
to the compromise of AAA-Key-new. Operators should be aware of the
potential risk of using this optimization.
An operator can reduce the risk exposure by forcing the PaC to
perform an EAP-based authentication immediately after the PaC gains
access to new link via the optimized PANA execution.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 10]
Internet-Draft PANA MobOpts October 2005
8. References
8.1. Normative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-07 (work in
progress), July 2005.
[I-D.ietf-pana-pana]
Forsberg, D., "Protocol for Carrying Authentication for
Network Access (PANA)", draft-ietf-pana-pana-10 (work in
progress), July 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.bournelle-pana-ctp]
Bournelle, J., "Use of Context Transfer Protocol (CxTP)
for PANA", draft-bournelle-pana-ctp-03 (work in progress),
June 2005.
[I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-11 (work in progress), August 2004.
[I-D.irtf-aaaarch-handoff]
Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
to RADIUS", draft-irtf-aaaarch-handoff-04 (work in
progress), November 2003.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 11]
Internet-Draft PANA MobOpts October 2005
Authors' Addresses
Dan Forsberg
Nokia Research Center
P.O. Box 407
FIN-00045 NOKIA GROUP
Finland
Phone: +358 50 4839470
Email: dan.forsberg@nokia.com
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5305
Email: yohba@tari.toshiba.com
Basavaraj Patil
Nokia
6000 Connection Dr.
Irving, TX 75039
USA
Phone: +1 972-894-6709
Email: Basavaraj.Patil@nokia.com
Hannes Tschofenig
Siemens Corporate Technology
Otto-Hahn-Ring 6
81739 Munich
Germany
Email: Hannes.Tschofenig@siemens.com
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 12]
Internet-Draft PANA MobOpts October 2005
Alper E. Yegin
Samsung Advanced Institute of Technology
75 West Plumeria Drive
San Jose, CA 95134
USA
Phone: +1 408 544 5656
Email: alper.yegin@samsung.com
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 13]
Internet-Draft PANA MobOpts October 2005
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 (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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Forsberg (Ed.), et al. Expires April 24, 2006 [Page 14]
