Internet DRAFT - draft-forsberg-pana-skc
draft-forsberg-pana-skc
Network Working Group D. Forsberg
Internet-Draft Nokia
Expires: April 22, 2006 J. Bournelle
GET/INT
R. Marin Lopez
University of Murcia
October 19, 2005
PANA Mobility Optimizations with Session Keys Context (SKC)
draft-forsberg-pana-skc-00.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 22, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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
HMAC-SHA1(AAA-Key,
Provider-Identifier,
DiameterIdentity)
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
[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.
7.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.irtf-aaaarch-handoff]
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
FIN-00045 NOKIA GROUP
Finland
Phone: +358 50 4839470
Email: dan.forsberg@nokia.com
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
Email: julien.bournelle@int-evry.fr
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
Spain
Email: rafa@dif.um.es
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
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, et al. Expires April 22, 2006 [Page 13]
