Network Working Group J. Bournelle
Internet-Draft M. Laurent-Maknavicius
Expires: novembre 30, 2004 GET/INT
H. Tschofenig
Siemens
Y. El Mghazli
Alcatel
G. Giaretta
TILab
June 2004
Context Transfer for PANA
draft-bournelle-pana-ctp-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 novembre 30, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The PANA protocol offers a way to authenticate clients in IP based
access networks. It carries EAP over UDP which permits ISPs to use
multiple authentication methods. However, in roaming environments IP
clients might change of gateways and new EAP authentication from
scratch may occur. This can considerably degrade performance.
Bournelle, et al. Expires novembre 30, 2004 [Page 1]
Internet-Draft Context Transfer for PANA June 2004
To enhance IP handover in mobile environments, we propose to use the
Context Transfer Protocol. The aim is to recover from previous PANA
Authentication Agent the PANA security context previously
established. For this, we define some ways to trigger the transfer
and the content of what we called a PANA context.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 PANA overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 IPsec based access control . . . . . . . . . . . . . . . . . 5
3.2 Re-authentication of PaC . . . . . . . . . . . . . . . . . . 5
3.2.1 Re-authentication based on EAP . . . . . . . . . . . . . . . 5
3.2.2 Re-authentication based on PANA . . . . . . . . . . . . . . 6
3.2.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Context Transfer for PANA . . . . . . . . . . . . . . . . . 8
4.1 CTP overview . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Extensions to PANA and CTP . . . . . . . . . . . . . . . . . 9
4.3 Conditions to Perform the Transfer . . . . . . . . . . . . . 9
4.4 Transfer of AAA-Key . . . . . . . . . . . . . . . . . . . . 9
4.5 The PANA Session Attributes . . . . . . . . . . . . . . . . 11
4.6 Contacting the AAA server . . . . . . . . . . . . . . . . . 13
4.7 Operations . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.7.1 Operations in the Non-predictive mode . . . . . . . . . . . 14
4.7.2 Operations in the Predictive mode . . . . . . . . . . . . . 16
5. General Issues . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security considerations . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . 23
Bournelle, et al. Expires novembre 30, 2004 [Page 2]
Internet-Draft Context Transfer for PANA June 2004
1. Introduction
In IP based access network, PANA [I-D.ietf-pana-pana] may be used as
a front-end to a AAA architecture in order to authenticate users
before granting them access to the resources. For this purpose, it
uses EAP which offers a variety of authentication methods. In a
shared medium this is typically accomplished with help of
cryptographic mechanisms. Note that this type of cryptographic
mechanism prevents a malicious node from sending packet to the
network and thereby authenticating each data packet. In addition,
encryption is often enabled to prevent eavesdropping.
While roaming, the PANA client might change its access router.
Without extensions to PANA the PaC has to restart a new PANA protocol
exchange to authenticate itself to the network. In some cases it is
necessary to execute the EAP exchange from scratch whereas in other
cases it might be possible to benefit from state stored at the
visited networks AAA server. This procedure is known as fast resume.
In this document, we propose a mechanism to avoid re-authentication
from scratch by using the framework defined in
[I-D.ietf-seamoby-ctp]. State established during the initial
authentication and the key establishment procedure (using PANA) is
transferred between the old and new points of attachment.
Bournelle, et al. Expires novembre 30, 2004 [Page 3]
Internet-Draft Context Transfer for PANA June 2004
2. Terminology
This document uses the following terms or abbreviations:
PANA: Protocol for CArrying Network Authentication for Network
Access
PANA Client (PaC): A mobile node (MN) using a PANA protocol
implementation to authenticate itself to the network.
New Access Router (nAR): The router to which the PaC attaches
after the handover.
Previous Access Router (pAR): The router to which the PaC was
attached before the handover.
New PANA Authentication Agent (nPAA): The PAA in charge of the
subnet to which the PaC was attached before the handover.
Previous PANA Authentication Agent (pPAA): The PaC's default PAA
prior to handover.
EP: Enforcement Point.
Context Transfer Protocol (CTP).
Context Transfer Data (CTD)
Context Transfer Activate Request (CTAR)
Context Transfer Activate Acknowledge (CTAA)
Feature Profile Type (FPT)
Bournelle, et al. Expires novembre 30, 2004 [Page 4]
Internet-Draft Context Transfer for PANA June 2004
3. Motivations
3.1 Background
3.1.1 PANA overview
PANA is a protocol that carries EAP over IP/UDP to authenticate
users. The PAA (PANA Authentication Agent) is the endpoint of the
PANA protocol at the access network. The PAA itself might not be able
to authenticate the user by terminating the EAP protocol. Instead the
PAA might forward the EAP payloads to the backend AAA infrastructure.
The Enforcement Point (EP) is an entity which enforces the result of
the PANA protocol exchange. The EP might be co-located with the PAA
or separated as a stand-alone device. In the latter case, the SNMPv3
protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and
EP.
A successful EAP authentication exchange results in a PANA security
association (PANA SA) if the EAP method was able to derive session
keys. In this case, all further PANA messages between PaC and PAA
will be authenticated, replay and integrity protected thanks to the
MAC AVP.
3.1.2 IPsec based access control
[I-D.ietf-pana-ipsec] describes how PANA could enable IPsec between
PaC and the EP. An IKE pre-shared key is distributed to PaC and EP.
Then, IKE is used to setup an ESP tunnel. Figure 1 describes a
possible architecture, AR/EP is the default router of the PaC and all
its traffic is protected by the ESP tunnel.
+----- PAA
|
|
PaC ================= AR/EP
(ESP tunnel)
Figure 1: PANA IPsec based access control
3.2 Re-authentication of PaC
PANA offers two types of re-authentication.
3.2.1 Re-authentication based on EAP
If the current session lifetime expires, the PAA or the AAA server
Bournelle, et al. Expires novembre 30, 2004 [Page 5]
Internet-Draft Context Transfer for PANA June 2004
may initiate a new EAP authentication. In this case, the PaC enters
in a new authentication phase and should provide credentials. The PaC
may also re-authenticate the access network.
3.2.2 Re-authentication based on PANA
PANA also offers a way to do a re-authentication. The PaC or the PAA
may trigger it by sending a PRAR message (PANA-Reauth-Request) with a
MAC AVP. Thus the responder needs the PANA_MAC_Key to respond. This
mechanism is a very efficient means to detect the aliveness of both
the PaC and the PAA. Figure 2 shows the message exchange which can be
triggered by both nodes.
PaC PAA Message(tseq,rseq)[AVPs]
--------------------------------------------
<----- PANA-Reauth-Request(q,p)[MAC]
-----> PANA-Reauth-Answer(p+1,q)[MAC]
Figure 2: PANA re-authentication
3.2.3 Limitations
PaC ------------ pEP ---- pPAA
| |
| |
| +------ pAR
(roaming) |
|
v
PaC ------------ nEP ---- nPAA
|
|
+------ nAR
Figure 3: Example Scenario
Figure 3 shows an example scenario with a roaming PaC which has been
previously authenticated. The PAA must be at one IP hop away from
PaC; this means that a specific PANA module on a PAA is in charge of
one IP network. After a PaC's IP handover, the PaC changes of IP
subnet and of PAA accordingly. The new PAA (nPAA) does not share any
context with the PaC. The new EP (nEP) will detect the PaC and will
trigger a new PANA authentication phase from scratch. A new
authentication phase involving the AAA infrastructure will then
Bournelle, et al. Expires novembre 30, 2004 [Page 6]
Internet-Draft Context Transfer for PANA June 2004
occur. Such a signaling can seriously degrades handover performance
in term of latency.
Bournelle, et al. Expires novembre 30, 2004 [Page 7]
Internet-Draft Context Transfer for PANA June 2004
4. Context Transfer for PANA
A PaC connected to an access network shares a context with its access
router like e.g. compression type, Quality of service parameters and
security state. As motivated in the previous sections, the goal of
this document is to reduce the overhead of establishing state between
the PaC and the nPAA. CTP [I-D.ietf-seamoby-ctp] permits to avoid
signaling overhead during roaming by enabling authorized context
transfer between access routers
However, CTP only offers a framework and does not define a particular
context. In particular, it appears that PANA is likely to use this
protocol to enhance mobility handling.
In CTP, a context is identified by a context type which is a 32-bit
number. As specified in [I-D.ietf-seamoby-ctp], the meaning of each
context type is determined by a specification document. This is
precisely the purpose of this document: defining a PANA context type
and the PANA-specific context, which comes together.
4.1 CTP overview
Context Transfer Protocol (CTP) [I-D.ietf-seamoby-ctp] enables
context transfers between access routers (ARs). The context transfer
can be either initiated by a request from the mobile node ("mobile
initiated") or at the initiative of either the new or the previous
access router ("network initiated"). Furthermore it can be performed
prior to handover ("predictive mode") or after the handover
("non-predictive mode").
In non-predictive mode, the MN sends a CT Activate Request (CTAR) to
the new AR (nAR). In this message the MN includes an authorization
token: this token is calculated based on a secret shared between the
MN and the previous AR (pAR) and it is used in order to authorize the
transfer. This means that the MN and the AR must share a secret. The
definition of this secret is out of scope of CTP. As soon as the nAR
receives a CTAR message, it generates a CT-Request message which
includes the authorization token and the context to be transferred
(i.e. Feature Profile Types). This message is received by the pAR
that verifies the authorization token and sends a Context Transfer
Data (CTD) message including the context requested.
In the predictive case, the pAR receives a CTAR message from the MN
whose feature contexts are to be transferred. This message provides
the IP address of the nAR and an authorization token. The pAR
predictively transmits to the nAR a Context Transfer Data (CTD) that
contains feature contexts. This message contains also parameters for
the nAR to compute an authorization token in order to verify the MN's
Bournelle, et al. Expires novembre 30, 2004 [Page 8]
Internet-Draft Context Transfer for PANA June 2004
token. Regardless the MN sent the CTAR to the pAR, it sends another
CTAR message to the nAR in order to ascertain that the context
transfer reliably took place. Furthermore in this CTAR the MN
includes tha authorization token so that the nAR verifies it.
CTP messages use Feature Profile Types (FPTs) to identify the way
data is organized for a particular feature context. The FTPs are
registered in a number space that allows a node to unambiguously
determine the type of context and the context parameters present in
the protocol messages.
4.2 Extensions to PANA and CTP
We introduce the PANA Feature Profile Types to handle transfer of
PANA context in CTP. (To be assigned by IANA).
New states are needed in PaC and PAA state machine to handle CTP. For
this we introduce the PANA-CTP-WAITING state for PAA. [TBD: do we
need to introduce a new state for the PaC.]
In addition, a new key is also introduced to compute a token used in
CTP, namely the PANA-CTP-Key. This key could be derived from the
AAA-Key.
Finally a new AVP is needed in PANA to carry the CTP CTAR message.
4.3 Conditions to Perform the Transfer
In this section, we list conditions and recommandations to perform a
PANA context transfer between two PAAs. This list is mostly inherited
from [I-D.aboba-802-context]
o Homogeneous PAA's device deployment within a single administrative
domain.
o Trust between devices engaged in the context transfer. CTP
indicates that IPsec ESP must be used.
o The nPAA should not obtain keys used to encrypt traffic between
PaC and pEP.
4.4 Transfer of AAA-Key
According to EAP [I-D.ietf-eap-keying], the figure below illustrates
the keys hierarchy in the PANA case:
Bournelle, et al. Expires novembre 30, 2004 [Page 9]
Internet-Draft Context Transfer for PANA June 2004
PaC pPAA AAA/EAP
--- ---- -------
MSK MSK MSK
EMSK EMSK
AAA-Key AAA-Key <---------- AAA-Key
PANA_MAC_Key PANA_MAC_Key
For security reasons, after the IP handover, the PaC and nPAA should
derive a new PANA_MAC_Key cryptographically separated from the
previous one. This can be accomplished by deriving a new AAA-Key
cryptographically separated from the previous AAA-Key. The problem is
that this key depends on MSK and EMSK, but EMSK must not be sent to
PAA.
The only solution to have a new PANA_MAC_Key cryptographically
separated from the old one should be to obtained a new one from the
AAA/EAP server.
We propose to use the same solutions as proposed in
[I-D.ietf-pana-pana]. For this, the pPAA provides to nPAA an
intermediate AAA-Key:
AAA-Key-int = The first N bits of
HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID)
If there are two AAA-Keys generated by a NAP/ISP authentication. pPAA
provides the following key:
AAA-Key-int = The first N bits of
HMAC-SHA1(AAA-Key1 | AAA-Key2, DiameterIdentity |
Session-ID)
DiameterIdentity is the identifier of the pPAA and Session-ID is the
identifier of the Session between the pPAA and PaC.
During the PBR/PBA exchange, PaC and nPAA must provide nonces that
are used to derive a new AAA-Key:
AAA-Key-new = The first N bits of
HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce)
The new PANA_MAC_Key used to compute AVP MAC will be calculated from
this key. A new PANA_CTP_Key should also be derived from this key.
Bournelle, et al. Expires novembre 30, 2004 [Page 10]
Internet-Draft Context Transfer for PANA June 2004
4.5 The PANA Session Attributes
The PANA Context is what should be transferred between the two PAAs
to avoid re-authentication from scratch. The attributes described in
[I-D.ietf-pana-pana] list elements that could constitute the PANA
context at PAA. However some of these datas are PAA's specific and as
such does not need to be transferred.
The PANA session attributes are listed below:
Session-Id: The Session-Id is of type UTF8String and is used to
identify a specific session between a PaC and PAA. Length is not
fixed. (type: UTF8String Length: variable)
Device-Id: The first octet (8 bits) of the Device-Id contains the
device type. The rest of the payload contains the device
information. The length depends on the device type (32 bits for
IPv4 address, 128 bits for IPv6 address). (type: UTF8string
Length: 8 + 32 || 64)
Sequence numbers: Note: tseq and rseq are 32-bit sequence number used
in the PANA header. tseq starts from initial sequence number (ISN)
and is monotonically increased by 1.
* ISN_pac: Initial tseq value of PaC. (type: Unsigned32, Length:
4)
* ISN_paa: Initial tseq value of PAA. (type: Unsigned32, Length:
4)
* Last transmitted tseq/rseq. (type: Unsigned32, Length: 4)
Retransmission Interval: PANA layer messages that require an answer
from a communicating peer are retransmitted based on a timer at
PANA-layer until a response is received. This timer should be
calculated as described in [RFC2988] to provide congestion
control. (type: Unsigned32, Length: 4)
Session-Lifetime: The authentication phase also determines the PANA
session lifetime when authorization succeeds. This value is
included in Session-Lifetime AVP. In Diameter [RFC3588], this AVP
(Session-Timeout) is of type Unsigned32 and contains the maximum
number of seconds of service to be provided to the user before
session termination. Note that the value forwarded to the new PAA
needs to reflect the already 'consumed' session lifetime. This
helps to avoid problems where roaming is used to reset the
lifetime when re-attaching at a new PAA. It must be assured that
the sum of the individual session lifetimes is never greater than
Bournelle, et al. Expires novembre 30, 2004 [Page 11]
Internet-Draft Context Transfer for PANA June 2004
the initially communicated lifetime(type: Unsigned32, length: 4)
Protection Capability: This attribute is sent by the PAA in
PANA-Bind-Request. It indicates protection capability of the
network access (L2 protection or IPsec). (type: Unsigned32,
length: 4)
PANA SA Attributes:
AAA-Key: Keying material (64 octets) that is derived from the
MSK (Master Session Key) and EMSK by the EAP server. This key
is distributed to the PAA. (type: xx, Length: 64)
PANA_MAC_Key: Key used to integrity protect PANA messages and
derived from the AAA-Key in the following way:
PANA_MAC_Key = The first N-bit of HMAC_xxx(AAA-Key, ISN_pac |
ISN_paa |Session_Id)
The value of N depends on the integrity algorithm in use (N=128
for HMAC_MD5 and N=160 for HMAC_SHA1).
As noted above, we do not need to transfer all of these fields.
Indeed, it appears that we do not need to transfer the following:
o Session-Id: nPAA will allocate a new one.
o Device-Id: nPAA does need the previous Device-Id of PaC.
o Protection-Capability: transfer occurs in homogeneous environment.
This means that the protection capability must be the same.
o AAA-Key and PANA_MAC_Key are not sent for security reasons.
However, as noted below, a AAA-Key-int is transferred.
Finally, the figure Figure 5 summarizes the PANA Context:
Bournelle, et al. Expires novembre 30, 2004 [Page 12]
Internet-Draft Context Transfer for PANA June 2004
+------------------+------------+----------------------------+
| Data | Type | Length |
+------------------+------------+----------------------------+
| ISN_pac | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| ISN_paa | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| Last tseq sent | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| Last rseq sent | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| Retransmission | | |
| Interval | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| Session-Lifetime | Unsigned32 | Fixed |
| Elapsed | | |
+------------------+------------+----------------------------+
| AAA-Key-int | UTF8String | Fixed (64 octets) |
+------------------+------------+----------------------------+
Figure 5: The PANA Context
4.6 Contacting the AAA server
To handle re-authentication, the AAA server should know new location
of PaC. This means that the nPAA or pPAA must notify new location of
PaC. The AAA protocol may be used for this purpose.
4.7 Operations
The transfer may occur either after or before the handover. From this
standpoint, we define two operating transfer modes:
Non-predictive mode: the PaC has already performed the handover. We
assume that it has already acquired an address.
Predictive mode: the transfer occurs before the handover.
The following section deals successively with both modes:
Bournelle, et al. Expires novembre 30, 2004 [Page 13]
Internet-Draft Context Transfer for PANA June 2004
4.7.1 Operations in the Non-predictive mode
PaC nPAA pPAA
----------------------------------------
PSR
<---------------
PSA(CTAR)
--------------->
CT-Request
-------------->
CTD
<--------------
PBR
<-------------
PBA
------------->
Figure 6: After the IP handover
4.7.1.1 Trigger the transfer
The transfer occurs between PAAs while the handover concerns PaC and
AR. Thus it is necessary to have a way to trigger this transfer. We
consider two variations:
1. the mobile is in charge of alerting the network
2. in the second one, an equipment in the access network triggers
the context transfer. However, in this case the nPAA should send
information that only PaC can know. For this reason, the network
can not initiate the transfer.
While entering in the new network, the PaC will be detected and the
nPAA will send a PSR message. To trigger the transfer we propose to
answer by a PSA message containing a CTAR message in an AVP. The PSA
message should contain the previous allocated Session-Id as proposed
in [I-D.ietf-pana-pana] and a AVP PaC_Nonce.
This CTAR message should contain the following data:
o The previous PaC's address.
o The previous PAA's address.
o An authorization token computed over this message using a shared
key between PaC and pPAA. We propose to introduce a new key for
Bournelle, et al. Expires novembre 30, 2004 [Page 14]
Internet-Draft Context Transfer for PANA June 2004
this purpose: PANA-CTP-Key derive from the AAA-Key. [TBD: how do
we derive this key ?]
4.7.1.2 Exchange between PAA
After receiving the PSA-CTAR message from the PaC, the PANA module
delivers the CTAR message to the PANA-CTP module. We introduce a new
state for this case: PANA-CTP-WAITING. The PAA sends a CT-Request to
request the transfer. As noted in Section 4.3, this message must be
protected by ESP [I-D.ietf-ipsec-esp-v3] as specified in
[I-D.ietf-seamoby-ctp].
The pPAA verifies the authorization token before sending the CTD
message. (If this token is not valid: [TBD: what do we do ? not
specified in CTP draft].) The CTD message contains:
o The Elapsed Time in milliseconds. This value reflects the already
'consumed' session lifetime.
o The PaC previous Care-of address.
o The PANA Context block.
This message must also be protected by ESP.
The CTD message is described in the following figure (ABNF notation):
CTD-PANA ::= < CTD-Header>
< Context Data Block, Ctx-Type: PANA-Context-Transfer, FPT>
{ ISN-pac }
{ ISN-paa }
{ Last tseq sent }
{ Last rseq sent }
{ Retransmission Interval }
{ Session-Lifetime-Elapsed }
{ AAA-Key-int }
Figure 7: CTD-PANA message
where FPT (Feature Profile Type) identifies the way the particular
feature context is organized.
4.7.1.3 After the Context Transfer
After receiving the CTD message, nPAA processes the following task:
o Parses the CTD message.
Bournelle, et al. Expires novembre 30, 2004 [Page 15]
Internet-Draft Context Transfer for PANA June 2004
o Changes state for this PaC: PANA-CTP-WAITING -> WAIT_SUCC_BIND
o Generates the PAA_Nonce
o Computes the AAA-Key-new (from PaC_Nonce, AAA-Key-int and
PAA_Nonce
o Derives the new PANA_MAC_Key
o Sends a PANA-Bind-Request containing:
* The newly allocated Session-ID in a AVP Session-ID.
* The PAA_Nonce.
* An AVP MAC signed with the new PANA_MAC_Key
o Waits a PANA-Bind-Answer from the PaC
4.7.2 Operations in the Predictive mode
4.7.2.1 Triggering the transfer
4.7.2.1.1 Mobile Controlled
To trigger the transfer, PaC/MN sends a CTAR message to pPAA. In this
message, it includes data which permit the pPAA to recover the nPAA's
address. The nAR's address should be this value. An authorization
token is also computed using PANA-CTP-Key.
4.7.2.1.2 Network Controlled
The document [I-D.irtf-aaaarch-handoff] describes an approach where
NAS/AR are able to anticipate movement of the PaC.
4.7.2.2 Exchange between PAA
The pPAA sends the CTD message to the nPAA/AR indicated in the CTAR
message. In this case, it is a predictive CTD message and thus it
must also contain:
o Algorithm, Key length and PANA-CTP-Key: allows the nAR to compute
a token locally and verify against the token present in the CTAR
message.
o The PANA context as described above in Section 4.5
Bournelle, et al. Expires novembre 30, 2004 [Page 16]
Internet-Draft Context Transfer for PANA June 2004
pPAA may set the A flag (see [I-D.ietf-seamoby-ctp])in order to have
a acknowledgment of this message.
Some data in the PANA Context may change before the handover really
take place: the last tseq/rseq and the Session-Lifetime. [TBD: how do
we handle this ?]
4.7.2.3 After the Context Transfer
The nPAA creates an entry for this PaC (state PAA-CTP-WAITING). PaC
performs the handover and sends a PSA-CTAR message. nPAA verifies it
and if it is correct it realizes a PBR/PBA to assign a new session-id
and exchanges Nonces. Then it configures the EP.
Bournelle, et al. Expires novembre 30, 2004 [Page 17]
Internet-Draft Context Transfer for PANA June 2004
5. General Issues
o How do we compute the PANA-CTP-Key ?
o If Session-Lifetime is near its expiration, is it necessary to
perform the transfer ? If yes, how do we manage this ?
o How informs the AAA system of the new PaC's location ?
o new state in the PaC state machine ?
Bournelle, et al. Expires novembre 30, 2004 [Page 18]
Internet-Draft Context Transfer for PANA June 2004
6. Security considerations
This document defines a mechanism to apply the Seamoby Context
Transfer Protocol between PAAs when a PaC changes PAA following up an
IP handover. Therefore, all security considerations described in
[I-D.ietf-seamoby-ctp] and in [I-D.ietf-pana-pana] apply also here.
The approach described in this document considers only the
intra-domain scenario. This means that the PAAs involved in the
context transfer belong to the same administrative domain. Therefore,
at this stage the inter-domain scenario is out of scope.
As described in [I-D.ietf-seamoby-ctp] IPsec ESP must be used to
protect CTP messages between PAAs. In order to avoid the
introduction of additional latency due to the need for establishment
of a secure channel between the context transfer peers, the two PAAs
should establish such a secure channel in advance. The mechanism used
by the PAAs to establish such a channel is out of the scope of this
draft: for example, IKE [RFC2409] with pre-shared key authentication
might be used.
Furthermore, CTP requires that the PaC and the PAA possess a shared
secret to calculate the authorization token: for this purpose, this
document defines a new key (PANA-CTP-Key) that is derived from the
AAA-key. The mechanism used by the nPAA to derivea new AAA-key and
consequently a new PANA-CTP-key is specified in [I-D.ietf-pana-pana].
Bournelle, et al. Expires novembre 30, 2004 [Page 19]
Internet-Draft Context Transfer for PANA June 2004
7. Acknowledgements
The authors would like to thank Jean-Jacques Puig for his valuable
comments
Bournelle, et al. Expires novembre 30, 2004 [Page 20]
Internet-Draft Context Transfer for PANA June 2004
Normative References
[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.
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-04 (work in
progress), May 2004.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-03 (work in progress), May
2004.
[I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in
progress), April 2004.
[I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-10 (work in progress), June 2004.
[I-D.ietf-ipsec-esp-v3]
Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-08 (work in progress), March 2004.
[I-D.aboba-802-context]
Aboba, B. and T. Moore, "A Model for Context Transfer in
IEEE 802", draft-aboba-802-context-02 (work in progress),
April 2002.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[I-D.ietf-eap-keying]
Aboba, B., "EAP Key Management Framework",
draft-ietf-eap-keying-01 (work in progress), October 2003.
Bournelle, et al. Expires novembre 30, 2004 [Page 21]
Internet-Draft Context Transfer for PANA June 2004
Authors' Addresses
Julien Bournelle
GET/INT
9 rue Charles Fourier
Evry 91011
France
EMail: julien.bournelle@int-evry.fr
Maryline Laurent-Maknavicius
GET/INT
9 rue Charles Fourier
Evry 91011
France
EMail: maryline.maknavicius@int-evry.fr
Hannes Tschofenig
Siemens Corporate Technology
Otto-Hahn-Ring 6
81739 Munich
Germany
EMail: Hannes.Tschofenig@siemens.com
Yacine El Mghzali
Alcatel
Route de Nozay
Marcoussis 91460
France
EMail: yacine.el_mghazli@alcatel.fr
Gerardo Giaretta
TILab
via G. Reiss Romoli, 274
TORINO 10148
Italy
EMail: gerardo.giaretta@telecomitalia.it
Bournelle, et al. Expires novembre 30, 2004 [Page 22]
Internet-Draft Context Transfer for PANA June 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Bournelle, et al. Expires novembre 30, 2004 [Page 23]
Internet-Draft Context Transfer for PANA June 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bournelle, et al. Expires novembre 30, 2004 [Page 24]