Internet DRAFT - draft-forsberg-pana-skc


Network Working Group                                        D. Forsberg
Internet-Draft                                                     Nokia
Expires: April 22, 2006                                     J. Bournelle
                                                          R. Marin Lopez
                                                    University of Murcia
                                                        October 19, 2005

      PANA Mobility Optimizations with Session Keys Context (SKC)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   This specification describes an extension to the PANA protocol that
   enables usage of a AAA Proxy acting as a Key Distribution Center
   (KDC) for multiple local PANA Authentication Agents.  The AAA Proxy
   acts as the contact point towards the AAA home server (single SA) and
   a AAA server and KDC towards the PAAs.  This document assumes that

Forsberg, et al.         Expires April 22, 2006                 [Page 1]
Internet-Draft            PANA MobOpts with SKC             October 2005

   the local network has multiple PAAs.  To avoid signalling between
   PAAs and the KDC, a Session Key Context is also defined which permits
   to the KDC to proactively provide a set of keys to a PAA.  Session
   Keys can then be fetched using CXTP.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Framework  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Details . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Session Keys Context . . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     7.1   Normative References . . . . . . . . . . . . . . . . . . . 11
     7.2   Informative References . . . . . . . . . . . . . . . . . . 11
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
       Intellectual Property and Copyright Statements . . . . . . . . 13

Forsberg, et al.         Expires April 22, 2006                 [Page 2]
Internet-Draft            PANA MobOpts with SKC             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 and architecture
   to eliminate the need to execute EAP each time the PaC performs an
   inter-PAA handover.

   The solution described in this document is based on a key derivation
   scheme where the AAA-Key is used as the root key to derive PAA
   specific session keys, namely PAA-Keys.  The key derivation procedure
   happens in a AAA Proxy acting as a Key Distribution Center (KDC) for
   the PAAs.  The KDC must have a separate security association (SA)
   with every PAA it is deriving keys for.  These SAs are used to
   encrypt the derived PAA-Keys.  A set of PAA-Keys (named SKC) can then
   be sent to the current PAA.

Forsberg, et al.         Expires April 22, 2006                 [Page 3]
Internet-Draft            PANA MobOpts with SKC             October 2005

2.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Forsberg, et al.         Expires April 22, 2006                 [Page 4]
Internet-Draft            PANA MobOpts with SKC             October 2005

3.  Framework

   The proposed architecture with KDC is depicted below (Figure 1).

             PaC         |prePAA +--------------+
              |          +-------+              |
              |                               +-+-+     +----+
              |                               |KDC+-----|AAAH|
              |                               +-+-+     +----+
              |          +-------+              |
              v          |newPAA +--------------+

                          Figure 1: PANA with KDC

   The PaC is authenticated by the prePAA which forwards AAA traffic to
   its KDC.  The KDC acts as a AAA proxy during the authentication phase
   and thus relays traffic to the AAAH.  When KDC has received the
   authentication result and in case of successful authentication the
   AAA-Key, it derives PAA-Keys.  Having a SA per PAA, it encrypts PAA-
   Keys with corresponding SAs and sends the whole set of keys to
   prePAA.  This set of keys is called Session Key Context.

   The key framework is shown on the figure below (Figure 2).  In this
   figure, one assume that EAP server is colocated in the AAA.

             PaC            PAA          KDC           AAA
             ---            ---          ---           ---
             MSK, EMSK                                 MSK, EMSK
             AAA-Key                     AAA-Key <---- AAA-Key
             PAA-Key        PAA-Key <--- PAA-Key

                    Figure 2: Keying Framework with KDC

   The message flow chart depicting mobility-optimized PANA execution is
   shown below (Figure 3).

Forsberg, et al.         Expires April 22, 2006                 [Page 5]
Internet-Draft            PANA MobOpts with SKC             October 2005

               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  |---------------------->|                  |

               Figure 3: Mobility optimized PANA call flow.

   In this flow, the PaC is already authorized and connected to PAA
   (prePAA) (step 1).  Later, the PaC performs a handover from prePAA to
   newPAA (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 new PAA (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, et al.         Expires April 22, 2006                 [Page 6]
Internet-Draft            PANA MobOpts with SKC             October 2005

4.  Protocol Details

   The AAA Proxy has single SA to the AAA home servers, which realizes
   more efficient SA management in cases where the local AAA Proxy is
   managed by different entity than the AAA home server(s).  Using a
   local AAA Proxy it is possible to localize inter-PAA movements and
   thus not burden the AAA home server unnecessarily (possible multiple
   hops away from the AAA proxy).

   PAA-Key derivation is based on multiple identities for channel
   binding and authentication purposes.  AAA-Key (PANA Key-Id AVP) and
   NAP/ISP (PANA Provider-Identifier AVP) identifiers are used in the
   key derivation process.  To bind the PAA-Key to a specific PAA, the
   DiameterIdentity of the PAA is used.  In this document we assume that
   the NAP/ISP owns the AAA Proxy and that the AAA home server provides
   subscriber authentication service for the NAP/ISP.  The extensions
   described in this document provide also mutual authentication between
   the PAAs and the PaCs, based on the AAA-Key.

   The KDC derives keys for one or multiple PAAs at a time, encrypts the
   keys and PAA DiameterIdentifiers with corresponding SAs.  There are
   multiple possibilities for the PAA to get it's corresponding key from
   the KDC.  Upon a mobility event the PAA could ask a key for the PaC
   from the KDC.  This method is called key-request.  On the other hand
   the KDC could pre-distribute the keys to some number of PAAs.  This
   method is called (pre-emptive) pre-distribution.  In this document we
   describe a mechanism that uses pre-distribution as the basis but
   bundles the PAA keys into a single PaC specific context.  This
   context is called Session Keys Context (SKC) and is transferred
   between PAAs as is described in the PANA context-transfer document
   [I-D.bournelle-pana-ctp].  The mechanisms of how the KDC selects the
   PAAs to be included into the SKC are out of the scope of this
   document and for further study.

   For all the different key distribution mechanisms, the PaC must know
   the AAA-Key and use it with the additional PAA identifier information
   for the PAA-Key derivation.  This provides mutual authentication
   between PaC and PAA (based on the PAA-Key).  During initial
   authentication phase PaC gets the AAA Key-Id and Provider-Identifier
   AVPs.  In addition to these, a serving PAA needs to send its PAA-
   Identifier AVP to the PaC.  When PaC is moving from one PAA to
   another, this AVP must be transferred to the PaC before the PaC is
   able to derive corresponding PAA-Key and authenticate the PAA.

   The optimizations described in this document require a AAA Proxy
   acting also as a KDC that knows the the PAA identifiers and its own
   Provider-Identifier.  However, in smaller deployments and where the
   singaling between PAAs and AAA home server (including also the EAP

Forsberg, et al.         Expires April 22, 2006                 [Page 7]
Internet-Draft            PANA MobOpts with SKC             October 2005

   Server) is localized, this kind of KDC is not needed.

   A mobile PaC's network access authentication performance can be
   enhanced by deploying a context transfer based mechanism like
   described in the [I-D.bournelle-pana-ctp], where some session
   attributes are transferred from the prevPAA to the newPAA 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]).

   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.

   PAA-Key is calculated in the KDC and PaC with the following formula:

          PAA-Key = The first N bits of

   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.

   New PANA_MAC_KEY is computed based on the algorithm described in
   [I-D.ietf-pana-pana], by using the new PAA-Key.  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.

Forsberg, et al.         Expires April 22, 2006                 [Page 8]
Internet-Draft            PANA MobOpts with SKC             October 2005

5.  Session Keys Context

   The SKC contains one or multiple entries.  SKC is PaC specific and
   identified with a Session-Id.  Every entry in the SKC contains PAA
   DiameterIdentity and a PAA-Key encrypted with the shared secret
   between PAA and the KDC.  The whole entry is integrity protected with
   the shared secret between PAA and KDC.

Forsberg, et al.         Expires April 22, 2006                 [Page 9]
Internet-Draft            PANA MobOpts with SKC             October 2005

6.  Security Considerations

   Only KDC and PaC can derive PAA-Keys.  Only PaC and PAA can derive
   PANA_MAC_KEYs, but also the KDC if it can intercept the nonce
   exchange between PaC and PAA.  These ensure that a single PAA-Key,
   AAA-Key, or PANA_MAC_KEY is not be used in multiple PAAs at any given
   time.  The nonce exchange provides fresh keys, even if the PaC
   revisits the same PAA during the lifetime of a AAA-Key.

Forsberg, et al.         Expires April 22, 2006                [Page 10]
Internet-Draft            PANA MobOpts with SKC             October 2005

7.  References

7.1  Normative References

              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.

7.2  Informative References

              Bournelle, J., "Use of Context Transfer Protocol (CxTP)
              for PANA", draft-bournelle-pana-ctp-03 (work in progress),
              June 2005.

              Arbaugh, W. and B. Aboba, "Experimental Handoff Extension
              to RADIUS", draft-irtf-aaaarch-handoff-04 (work in
              progress), November 2003.

Authors' Addresses

   Dan Forsberg
   Nokia Research Center
   P.O. Box 407

   Phone: +358 50 4839470

   Julien Bournelle
   9 rue Charles Fourier
   Evry 91011


Forsberg, et al.         Expires April 22, 2006                [Page 11]
Internet-Draft            PANA MobOpts with SKC             October 2005

   Rafa Marin Lopez
   University of Murcia
   Murcia  30071


Forsberg, et al.         Expires April 22, 2006                [Page 12]
Internet-Draft            PANA MobOpts with SKC             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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Forsberg, et al.         Expires April 22, 2006                [Page 13]