Network Working Group J. Bournelle (Ed.)
Internet-Draft M. Laurent-Maknavicius
Expires: August 19, 2005 GET/INT
H. Tschofenig
Siemens
Y. El Mghazli
Alcatel
G. Giaretta
TILab
R. Lopez
Univ. of Murcia
Y. Ohba
Toshiba
February 18, 2005
Use of Context Transfer Protocol (CxTP) for PANA
draft-bournelle-pana-ctp-02
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 19, 2005.
Copyright Notice
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 1]
Copyright (C) The Internet Society (2005).
Internet-Draft CxTP for PANA February 2005
Abstract
The PANA protocol offers a way to authenticate clients in IP based
access networks. However, in roaming environments IP clients might
change of gateways and new EAP authentication from scratch may occur.
To enhance IP handover in mobile environments, the Context Transfer
Protocol (CxTP) could be used. This protocol could recover from
previous PANA Authentication Agent the PANA security context
previously established. The aim of this document is to analyze and
to describe the different approaches to perfom the transfer.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 PANA overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 IPsec based access control . . . . . . . . . . . . . . 5
3.1.2 Limitations . . . . . . . . . . . . . . . . . . . . . 6
3.2 CxTP overview . . . . . . . . . . . . . . . . . . . . . . 6
4. General considerations in the use of CxTP for PANA . . . . . . 8
4.1 Conditions to Perform the Transfer . . . . . . . . . . . . 8
4.2 Context Identification . . . . . . . . . . . . . . . . . . 8
4.3 Transfer of AAA-Key . . . . . . . . . . . . . . . . . . . 9
4.4 Interaction with the AAA infrastructure . . . . . . . . . 10
4.5 The PANA Context . . . . . . . . . . . . . . . . . . . . . 12
5. First approach: use of CxTP between PAAs . . . . . . . . . . . 15
5.1 PANA solution . . . . . . . . . . . . . . . . . . . . . . 15
5.2 CxTP friendly approach . . . . . . . . . . . . . . . . . . 16
5.2.1 Operations in reactive mode . . . . . . . . . . . . . 16
5.2.2 Operations in predictive mode . . . . . . . . . . . . 18
5.3 Optimized approach . . . . . . . . . . . . . . . . . . . . 19
5.3.1 Operations in the Reactive mode . . . . . . . . . . . 19
5.3.2 Operations in the Predictive mode . . . . . . . . . . 21
5.4 PANA with CxTP between PAAs interactions . . . . . . . . . 21
5.5 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. Second approach: use of CxTP between ARs . . . . . . . . . . . 23
6.1 Predictive case . . . . . . . . . . . . . . . . . . . . . 23
6.2 Reactive case . . . . . . . . . . . . . . . . . . . . . . 25
6.3 Considerations on the AR-PAA communications . . . . . . . 26
7. Security considerations . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 31
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 2]
Internet-Draft CxTP for PANA February 2005
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 the 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 analyse the interaction between the framework
defined in [I-D.ietf-seamoby-ctp] and PANA. In particular, we define
what should be transferred (i.e. the PANA context) and the
interactions with the AAA infrastructure.
We can envision two different approaches: in the first one, the
transfer occurs between authentication agents whereas, in the second
one, we perform the transfer between access routers. In the latter,
we need a protocol or an API for the AR-PAA communications.
For the first approach, three possible solutions are explained. The
first one is the solution given in the PANA specification
[I-D.ietf-pana-mobopts]. In the second solution, a CxTP friendly is
proposed while the third solution is an optimized version of the
previous one.
For the second approach, the transfer occurs between access routers
as specified by CxTP. PANA contexts are stored in PAA, thus ARs will
need an interface to collect context. The reactive mode and
predictive mode are presented.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 3]
Internet-Draft CxTP for PANA February 2005
2. Terminology
Most of the terms are defined in the PANA [I-D.ietf-pana-pana] and
CxTP [I-D.ietf-seamoby-ctp] specifications:
nAR New Access Router. The router to which the PaC attaches after
the handover.
pAR Previous Access Router. The router to which the PaC was attached
before the handover.
CTAA Context Transfer Activate Acknowledge.
CTAR Context Transfer Activate Request.
CTD Context Transfer Data.
CxTP Context Transfer Protocol.
EP Enforcement Point. (PANA term)
FPT Feature Profile Type (CxTP term).
PaC PANA Client. A mobile node (MN) using a PANA protocol
implementation to authenticate itself to the network.
PAA PANA Authentication Agent. The access network (server) side
entity of the PANA protocol. A PAA is in charge of interfacing
with the PaCs for authenticating and authorizing them for the
network access service.
nPAA New PANA Authentication Agent. The PAA in charge of the subnet
to which the PaC is attached after the handover.
pPAA Previous PANA Authentication Agent. The PaC's default PAA prior
to handover.
PANA Protocol for Carrying Network Authentication for Network Access
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 4]
Internet-Draft CxTP for PANA February 2005
3. Background
3.1 PANA overview
PANA is a protocol that carries EAP over IP/UDP to authenticate
users. The PANA Authentication Agent (PAA) 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.1 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 the EP and
locally derived from the AAA-Key for the PANA client. 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
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 5]
Internet-Draft CxTP for PANA February 2005
3.1.2 Limitations
PaC ------------ pEP ---- pPAA
| |
| |
| +------ pAR
(roaming) |
|
v
PaC ------------ nEP ---- nPAA
|
|
+------ nAR
Figure 2: Example Scenario
Figure 2 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
occur. Such a signaling can seriously degrades handover performance
in term of latency.
For this reason, we propose to use the Context Transfer Protocol
(CxTP) to transfer PANA context established with the PaC from pPAA to
the nPAA.
3.2 CxTP overview
Context Transfer Protocol (CxTP) [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
("reactive mode").
In reactive 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 pAR must share a secret.
The definition of this secret is out of scope of CxTP. As soon as
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 6]
Internet-Draft CxTP for PANA February 2005
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
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 the authorization token so that the nAR verifies it.
CxTP messages use Feature Profile Types (FPTs) to identify the way
data is organized for a particular feature context. The FPTs 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.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 7]
Internet-Draft CxTP for PANA February 2005
4. General considerations in the use of CxTP 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. CxTP [I-D.ietf-seamoby-ctp] permits to avoid
signaling overhead during roaming by enabling authorized context
transfer between access routers.
However, CxTP 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.
The aim of this section is to give general considerations on the use
of CxTP for PANA.
4.1 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 Entities engaged in the context transfer should authenticate each
other. For this purpose, CxTP indicates that IPsec ESP must be
used in order to provide connectionless integrity, data origin
authentication and confidentiality protection.
o The nPAA should not obtain keys used to encrypt traffic between
PaC and pEP. This traffic may be encrypted at layer 2 or at layer
3.
4.2 Context Identification
The context is, a priori, stored in the PAA and the CTP module needs
a way to collect it. For this, the current CxTP specification
proposes to use the IP address.
In the reactive mode, the MN sends a CTAR message to the nAR
including the previous MN's address. The problem is that this
address can be allocated after the MN's handover to someone else.
To avoid conflict, the pAR should defend an address allocated to a
PaC until its context transfer has occured.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 8]
Internet-Draft CxTP for PANA February 2005
4.3 Transfer of AAA-Key
According to EAP [I-D.ietf-eap-keying], the figure below illustrates
the keys hierarchy in the PANA case:
PaC pPAA AAA/EAP
--- ---- -------
MSK MSK MSK
EMSK EMSK
AAA-Key AAA-Key <---------- AAA-Key
PANA_MAC_Key PANA_MAC_Key
MSK and EMSK are derived from the EAP method used between the PaC and
the AAA/EAP server. Those keys must not be exported from the EAP
module. The AAA-Key is computed from MSK and EMSK. This key is
exported to the pPAA. The PANA_MAC_KEY, used to protect PANA
messages, is derived from the AAA-Key as follows:
PANA_MAC_KEY = The first N bits of
HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID)
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.
An obvious solution to have a new PANA_MAC_Key cryptographically
separated from the old one should be to obtain a new one from the
AAA/EAP server.
We propose to use the same solutions as proposed in
[I-D.ietf-pana-mobopts]. 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)
DiameterIdentity is the identifier of the pPAA and Session-ID is the
identifier of the Session between the pPAA and PaC.
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 |
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 9]
Internet-Draft CxTP for PANA February 2005
Session-ID)
During the PSR/PSA exchange, PaC and nPAA 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.
4.4 Interaction with the AAA infrastructure
PAAs may use AAA infrastructure to authenticate PaC. This means that
the PAA contacts a (local) AAA server and relay the EAP messages in
order to authenticate a PaC. The PANA protocol introduces a separate
authentication for Network Access Provider (NAP) and Internet Service
Provider (ISP), please read [I-D.ietf-pana-pana] for more
information. For simplicity, we will assume in the rest of this
document that NAP will not perform AAA operations.
We have two possible situations depending on roaming situation. We
only consider use of RADIUS [RFC2865] or Diameter EAP application
[I-D.ietf-aaa-eap].
+-----+ +-----+ +-----+
| PaC |<------->| PAA |<----->| AAA |
+-----+ +-----+ +-----+
Figure 4: Local authentication
In Figure 4, the PaC is authenticated in its home domain. The PAA
contacts its local AAA server.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 10]
Internet-Draft CxTP for PANA February 2005
+-----+ +-----+ +------+
| PaC |<------->| PAA |<----->| AAAL |
+-----+ +-----+ +--+---+
^
|
v
+--+---+
| AAAH |
+------+
Figure 5: PaC in a visited domain
In Figure 5, the PaC is in a visited domain. It can not be
authenticated by the local AAA server (AAAL). In this case, the PAA
contacts a local AAA entity which will contact the home AAA server.
In the first situation, the PAA shares a session with only one AAA
server. This server keeps information on the authenticated PaC such
as session-lifetime, PAA's identity, authorized services...In some
cases, the AAA server may have to contact the PaC (e.g.
re-authentication) and thus if the PaC changes of PAAs, it seems
necessary to contact the AAA server to inform it of the new PAA in
charge of the PaC.
The second situation is a little bit more complex since the PAA does
not know the AAAH's identity. We can however state that it is
necessary for the PAA to inform its local AAA entity of PaC's new
location. Depending on policy, the AAAL server should inform the
AAAH server.
+----------+
| AAA(L/H) |
+----------+
^
| nPAA's identity
|
|
+---+--+ +------+
| pPAA |----------------->| nPAA |
+------+ +------+
AAA's identity
Figure 6: The pPAA contacts the AAA infrastructure
To inform the AAA server of PaC's new location, two solutions are
available. In the first one (cf. Figure 6), the pPAA is in charge
of contacting the AAA server to inform it of the nPAA.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 11]
Internet-Draft CxTP for PANA February 2005
+----------+
| AAA(L/H) +<-----------------+
+----------+ |
I'm in |
charge of PaC |
|
|
+------+ +--+---+
| pPAA |----------------->| nPAA |
+------+ +------+
AAA's identity
Figure 7: The nPAA contacts AAA infrastructure
In the second one (cf. Figure 7), the nPAA informs the AAA server.
It also seems necessary to inform the nPAA of the AAA server's
identity.
4.5 The PANA Context
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 data are PAA specific and as
such does not need to be transferred.
Figure 8 summarizes the PANA Context.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 12]
Internet-Draft CxTP for PANA February 2005
+------------------+------------+----------------------------+
| Data | Type | Length |
+------------------+------------+----------------------------+
| Session-Lifetime | Unsigned32 | Fixed |
| Elapsed | | |
+------------------+------------+----------------------------+
| AAA-Key-int | UTF8String | Fixed (64 octets) |
+------------------+------------+----------------------------+
| AAA server | UTF8String | Variable |
| Identity | | |
+------------------+------------+----------------------------+
| ISP-Identifier | Unsigned32 | Fixed |
+------------------+------------+----------------------------+
| ISP-Name | UTF8String | Variable |
+------------------+------------+----------------------------+
| NAP/ISP Separate | Unsigned32 | Fixed |
| Authentication | | |
+------------------+------------+----------------------------+
Figure 8: The PANA Context
Data have the following meanings:
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
the initially communicated lifetime (type: Unsigned32, length: 4)
AAA-Key-int: cf. Section 4.3.
AAA server identify: Identity of the AAA server used to authenticate
the PaC.
ISP-Identifier IANA assigned "SMI Network Management Private
Enterprise Codes" of the provider.
ISP-Name UTF8-encoded name of the provider.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 13]
Internet-Draft CxTP for PANA February 2005
Separate NAP/ISP authentication This variable indicates if a separate
NAP/ISP authentication has been performed at pPAA.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 14]
Internet-Draft CxTP for PANA February 2005
5. First approach: use of CxTP between PAAs
The transfer may occur either after or before the handover. From
this standpoint, we define two operating transfer modes:
o Reactive mode: the PaC has already performed the handover. We
assume that it has acquired an address.
o Predictive mode: the transfer occurs before the handover.
Different approaches exist to perform PANA context transfer using
CxTP. In this document, we describe three of them and we discuss
interaction between CxTP specification and PANA.
In each of these 3 solutions, the transfer occurs between PAAs and
they use a CTD message containing the PANA context.
The CTD message is described in the following figure (ABNF notation):
CTD-PANA ::= < CTD-Header>
< Context Data Block, Ctx-Type: PANA-Context-Transfer, FPT>
{ Session-Lifetime-Elapsed }
{ AAA-Key-int }
{ AAA server's identity }
{ ISP-Identifier }
{ ISP-Name }
{ Double Authentication NAP/ISP information }
Figure 9: CTD-PANA message
where FPT (Feature Profile Type) identifies the way the particular
feature context is organized.
5.1 PANA solution
In the solution proposed by PANA [I-D.ietf-pana-mobopts], the PaC
does not use CTAR message to request and activate the context.
Instead, it replies to PSR message with a PSA message containing the
unexpired previous PANA session identifier and a MAC AVP (cf. Figure
10). This AVP is computed using the PANA_MAC_KEY shared between the
PaC and its pPAA.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 15]
Internet-Draft CxTP for PANA February 2005
PaC nPAA pPAA
--- ---- ----
PSR[PAA_Nonce]
<------------
PSA[oSession-ID][PaC_Nonce][MAC]
-------------->
CT-Request [PSA]
---------------->
CTD-PANA
<----------------
PBR[nSession-Id][MAC]
<--------------
PBA [MAC]
--------------->
Figure 10: The PANA approach
The nPAA receives this PSA message and it deduces that it must
perform CxTP (because of the Session-Id AVP). It determines the
identity of pPAA by looking at the DiameterIdentity part of the PANA
session identifier. It sends a CT-Request to the pPAA containing the
PSA message. The pPAA checks the validity of the PSA message and
transfers the PANA context in the CTD message. Then the PANA session
continues with a PANA-Bind exchange.
This procedure has the following issues:
o It does not support predictive mode since we do not have a CTAR
message.
o CxTP does not define a way to carry PSA message in CT-Request.
o The CxTP module can not validate the transfer since the CT-Request
does not provide any authorization token.
5.2 CxTP friendly approach
5.2.1 Operations in reactive mode
As described in the previous paragraph, in order to handle PaC
mobility in the reactive case, the approach based on
[I-D.ietf-pana-mobopts] has some unsolved issues: these issues
concern the usage of CxTP to perform the context transfer between
PAAs. A possible alternative approach is to perform the context
transfer relying completely on CxTP as specified in
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 16]
Internet-Draft CxTP for PANA February 2005
[I-D.ietf-seamoby-ctp]. Figure 11 shows the message flow if this
CxTP-friendly approach is used.
PaC nPAA pPAA
--- ---- ----
PSR [PAA_Nonce] (handoff)
<--------------
CTAR
--------------->
CT-Request
--------------->
CTD-PANA
<----------------
CTAA
<---------------
PSA[(old Session-ID,) PaC_Nonce]
--------------->
PBR[nSession-Id]
<-------------
PBA
------------->
Figure 11: CxTP friendly approach: non predictive mode
When the PaC performs a change of the point of attachment to the
network, it receives a trigger indicating that a handoff has occured
and consequently a context transfer should be performed. This
trigger might be a PSR message sent by the nPAA (as depicted in
Figure 11) or an internal DNA trigger (e.g. L2 "link-up" trigger).
Based on this event notification, the PaC begins the CxTP procedure
sending to the nPAA a CTAR message to trigger the context transfer.
Based on [I-D.ietf-seamoby-ctp] this message MUST include the
previous address of the PaC, the address of the pPAA and an
authorization token needed to authorize the transfer. This
authorization token is computed using a key that we called
PANA_CxTP_KEY. The nPAA sends a CT-Request to the pPAA including the
previous address of the PaC and the authorization token. These data
are needed to the pPAA in order to identify the PaC and to retrieve
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 17]
Internet-Draft CxTP for PANA February 2005
the associated PANA state. If the authorization token is verified
successfully, the pPAA sends to the nPAA the PANA context of the PaC
through a CTD-PANA message. Finally the nPAA sends a CTAA message to
the PaC as a confirm that the context transfer has been completed.
Upon the receipt of the CTAA, the PaC sends to the nPAA a PSA
message: the protocol operation continues as specified in section
4.11 of [I-D.ietf-pana-pana].
Even if it is compliant to CxTP specification, this approach has
several open issues:
o [I-D.ietf-seamoby-ctp] specifies that the context transfer is
performed between Access Routers, while in this scenario it is
performed between PAAs;
o in CxTP the transfer is authorized through the authorization
token: it should be defined the key (called PANA_CxTP_KEY in this
document) needed to calculate this authorization token;
o if CxTP operations are triggered by a PSR message (i.e. it is not
provided by layer 2 or by a DNA solution), the nPAA keeps on
sending PSR messages waiting to receive a PSA message; indeed the
PaC sends the PSA message only once the context transfer is
accomplished. This implies an inefficiency in PANA protocol
operations.
o in order to send a CTAR message, the PaC must know the nPAA IP
address. This could be an issue if CxTP is triggered by DNA,
since a DNA solution might not provide the IP address of the nPAA.
For this reason, the PaC might be forced to perform a new
discovery phase to get the nPAA's address.
5.2.2 Operations in predictive mode
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-CxTP-Key.
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-CxTP-Key: allows the nPAA to
compute a token locally and verify against the token present in
the CTAR message.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 18]
Internet-Draft CxTP for PANA February 2005
o The PANA context as described above in Section 4.5
o The (previous) IP address of PaC.
pPAA may set the A flag (see [I-D.ietf-seamoby-ctp]) in order to have
an acknowledgment of this message.
The nPAA creates an entry for this PaC. PaC performs the handover
and sends CTAR message (after receiving a PSR message). nPAA
recovers the context using PaC's address indicated in the CTAR
message. It verifies the authorization token and if it is correct it
activates the context. Then they perform a PBR/PBA exchange. Thus
the nPAA can allocate a new session-id.
This predictive mode raises the following issue:
o After receiving the CTD message from pPAA, the nPAA creates an
entry for the PaC. But in which state is it for this PaC ? Do a
new state is needed ?
5.3 Optimized approach
In this approach, the CTAR message is embedded in the PSA message.
Thus, we reduce the number of messages.
5.3.1 Operations in the Reactive mode
PaC nPAA pPAA
--- ---- ----
PSR [PAA_Nonce]
<---------------
PSA [CTAR][PaC_Nonce]
--------------->
CT-Request
-------------->
CTD
<--------------
PBR[nSession-Id]
<-------------
PBA
------------->
While entering in the new network, the PaC will be detected and the
nPAA will send a PSR message. To trigger the transfer the PaC can
answer with a PSA message containing a CTAR message in an AVP. The
PSA message contain an AVP PaC_Nonce.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 19]
Internet-Draft CxTP for PANA February 2005
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 (the PANA_CxTP_KEY).
After receiving the PSA-CTAR message from the PaC, the PANA module
delivers the CTAR message to the PANA-CxTP module. The PAA sends a
CT-Request to request the transfer. As noted in Section 4.1, 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. The CTD message contains:
o The Elapsed Time in milliseconds. This value reflects the already
'consumed' session lifetime.
o The PaC's previous address.
o The PANA Context block.
This message must also be protected by ESP.
After receiving and processing the CTD message, the nPAA eventually
change the state of the PaC. It computes the AAA-Key-new (using
PaC_Nonce, AAA-Key-int and PAA_Nonce) and derives a new PANA_MAC_Key.
Then it can send the PANA-Bind-Request containing the newly allocated
Session-ID. This message is authenticated by a MAC AVP computed with
the new PANA_MAC_Key. After receiving a PANA-Bind-Answer from the
PaC, it changes its state to OPEN.
Issues:
o New state to handle the period of time where the nPAA is waiting
the PaC's context from pPAA ?
o Generation the PANA-CxTP-Key ?
o Piggyback of a CxTP message in PANA.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 20]
Internet-Draft CxTP for PANA February 2005
5.3.2 Operations in the Predictive mode
The operations here are quite similar than in Section 5.2.2. The
difference is that the PaC embeds the CTAR message in the PSA after
the IP handover.
5.4 PANA with CxTP between PAAs interactions
The table below summarizes issues in using CxTP between PAAs to carry
PANA context.
+----------+------------+-------------+
| PANA | CxTP | Optimized |
+------------------+----------+------------+-------------+
| Transfer | no | no | no |
| between ARs | | | |
+------------------+----------+------------+-------------+
| CTAR message | no | yes | yes |
+------------------+----------+------------+-------------+
| predictive mode | no | yes | yes |
| supported | | | |
+------------------+----------+------------+-------------+
| Transfer | | | |
| authorized by | PANA | CxTP | CxTP |
+------------------+----------+------------+-------------+
| Trigger | PSR | PSR/DNA | PSR |
+------------------+----------+------------+-------------+
| State Machine | ? | yes | yes |
| Issue | | | |
+------------------+----------+------------+-------------+
Figure 13: PANA-CxTP interactions
5.5 Issues
This section lists the different issues raised in previous section.
o PAAs are not Access Routers. CxTP states that context transfer
occurs between ARs.
o CT-request does not define a way to carry PSA message.
o Which protocol can be used to inform the AAA server of the nPAA in
charge of the PaC ? A AAA extension ?
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 21]
Internet-Draft CxTP for PANA February 2005
o Who informs the local AAA entity of the new PAA in charge of the
PaC ? (pPAA or nPAA ?)
o Computation of the PANA-CxTP-Key ?
o If Session-Lifetime is near its expiration, is it necessary to
perform the transfer ?
o State machine modification in PaC and PAA ?
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 22]
Internet-Draft CxTP for PANA February 2005
6. Second approach: use of CxTP between ARs
If CxTP is used between PAAs, two CxTP exchange in parallel in the
access network may occur: one between ARs (e.g. for QoS) and one
between PAAs. For this reason, we analyze in this section use of
CxTP between ARs for PANA.
As specified in PANA [I-D.ietf-pana-pana], PAA may be colocated with
AR. In this case, an API for the AR-PAA communication is sufficient.
If PAA and AR are not colocated, a protocol is needed for our
purpose. One of the goal of this work is also to investigate which
protocol could be used for this.
In the next two sections, predictive and reactive cases are
described.
6.1 Predictive case
In this case, the PaC sends a CTAR message to its AR. This CTAR
message indicates that PaC wants its PANA context to be transferred.
This message is protected with an authorization token computed with a
key. CxTP does not define how to obtain this key. A possible
approach could be to use the EAP key hierachy but this is not the
purpose of this document.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 23]
Internet-Draft CxTP for PANA February 2005
PaC pAR pPAA nAR nPAA
--- --- ---- --- ----
CTAR
------------->
Get
------->
Send
<-------
CTD [PANA-ctx]
------------------------>
(nAR waits for CTAR to validate it)
(IP handover)
CTAR
------------------------------------->
(nAR validates CTAR)
Set
----------->
Ack
<-----------
CTAA
<--------------------------------------
PANA-Start-Exchange
<------------------------------------------------->
PANA-Bind-Exchange
<------------------------------------------------->
The PaC sends a CTAR message protected by an authorization token.
The pAR checks this token and if valid, requests the PANA context to
the pPAA. The pPAA provides the corresponding context to the pAR.
This context is identified using PaC's IP address. The pAR may
retrieve other contexts. Then it sends the CTD message to the nAR.
This nAR is specified in the CTAR message. The nAR keeps it but wait
for CTAR message before setting the context.
After its IP handover, the PANA client sends the CTAR message to the
new AR. This message contains a token. The pAR has provided the nAR
with the necessary keying material in order to verify this token.
After the validation, the nAR can set contexts. For PANA, it sends a
message containing the context to the nPAA which will create an entry
for the PaC. The nPAA should be able to acknowledge this message if
PaC has requested an acknowledgement.
After this, the nPAA may start with a PANA-start exchange followed by
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 24]
Internet-Draft CxTP for PANA February 2005
a PANA-Bind-Exchange in order to create a new PANA session-id, new
PANA keying material and configure nEP. This implies that:
o EPs are configured to allow CxTP traffic (CTAR/CTAA message).
o The PaC must not try to discover PAA before receiving CTAA message
except for the first authentication.
6.2 Reactive case
In the reactive case, the PANA client has already performed its IP
handover.
PaC nAR nPAA pAR pPAA
--- --- ---- --- ----
CTAR
-------------->
CT-Request
------------------------>
validate message
GetContext
----------->
(pPAA provides context,
manages state, contacts
AAA ?)
SendContext
<----------
CTD [PANA-Ctx]
<------------------------
SetContext
----------->
Ack
<---------
CTAA
<--------------
PANA-Start-Exchange
<------------------------------------------------->
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 25]
Internet-Draft CxTP for PANA February 2005
PANA-Bind-Exchange
<------------------------------------------------->
The PANA client sends a CTAR message to the nAR requesting for the
PANA context. This message contains the IP address of the pAR and an
authorization token. nAR sends a CT-Request to the pAR containing
the CTAR message. After validating the CTAR message, the pAR
collects requested contexts and forward them to the nAR in the CTD
message. The nAR sends the PANA context to the local PAA and
possibly wait for an acknowledgement. If requested by the PaC, the
nAR sends a CTAA message.
After this, a classic PANA-Start-Exchange occurs but then they
directly perform a PANA-Bind-exchange. This exchange permits to
terminate the configuration of the PANA client: the nPAA allocates a
new session-id and may allocate an IP adress.
To avoid conflicts, PANA authentication should not be triggered
before context transfer has been completed. For this purpose, the
following points must be respected:
o PANA client should not send a PSR message before receiving the
CTAA message.
o The nEP should not trigger PANA authentication while receiving
CTAR/CTAA messages.
6.3 Considerations on the AR-PAA communications
If CxTP is used between ARs, a protocol is needed between AR and PAA.
This protocol is used in the previous access network by the AR to
collect the PANA context from the PAA. The context located at the
PAA should be identified by the IP address of the PaC. In the new
access network, the AR must send the context to the PAA and the
former must be able to acknowledge this message.
This is a list of requirements about this protocol:
o The AR and the PAA must be able to authenticate each other.
o The AR and the PAA must provide integrity protection.
o The AR and the PAA must provide confidentiality.
o The PANA context should be identified by IP address at the PAA.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 26]
Internet-Draft CxTP for PANA February 2005
7. Security considerations
This document deals with interaction between the Seamoby Context
Transfer Protocol and PANA. 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 CxTP 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, CxTP 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-CxTP-Key probably derived from the
AAA-Key. The mechanism used by the nPAA to derive a new AAA-key and
consequently a new PANA-CxTP-key is specified in
[I-D.ietf-pana-pana].
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 27]
Internet-Draft CxTP for PANA February 2005
8. Acknowledgements
The authors would like to thank Vijay Devarapalli, James Kempf,
Rajeev Koodli, Nakhjiri Madjid-MNAKHJI, Jean-Jacques Puig, Ren?
Soltwitsch and Alper Yegin for their valuable comments.
9 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-07 (work in
progress), December 2004.
[I-D.ietf-pana-ipsec]
Parthasarathy, M., "PANA enabling IPsec based Access
Control", draft-ietf-pana-ipsec-05 (work in progress),
December 2004.
[I-D.ietf-pana-snmp]
Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for
PAA-2-EP interface", draft-ietf-pana-snmp-02 (work in
progress), October 2004.
[I-D.ietf-pana-mobopts]
Forsberg, D., "PANA Mobility Optimizations",
draft-ietf-pana-mobopts-00 (work in progress), January
2005.
[I-D.ietf-seamoby-ctp]
Loughney, J., "Context Transfer Protocol",
draft-ietf-seamoby-ctp-11 (work in progress), August 2004.
[I-D.ietf-ipsec-esp-v3]
Kent, S., "IP Encapsulating Security Payload (ESP)",
draft-ietf-ipsec-esp-v3-09 (work in progress), October
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.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 28]
Internet-Draft CxTP for PANA February 2005
[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., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-04 (work in
progress), November 2004.
[I-D.ietf-aaa-eap]
Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application",
draft-ietf-aaa-eap-10 (work in progress), November 2004.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
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
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 29]
Internet-Draft CxTP for PANA February 2005
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
Rafa Marin Lopez
University of Murcia
30071 Murcia
Spain
EMail: rafa@dif.um.es
Yoshihiro Ohba
Toshiba America Research, Inc.
1 Telcordia Drive
Piscateway, NJ 08854
USA
Phone: +1 732 699 5365
EMail: yohba@tari.toshiba.com
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 30]
Internet-Draft CxTP for PANA February 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.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
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.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 31]
Internet-Draft CxTP for PANA February 2005
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bournelle (Ed.), et al. Expires August 19, 2005 [Page 32]