[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/