PANA Working Group J. Bournelle (Ed.) Internet-Draft M. Laurent-Maknavicius Expires: September 7, 2006 GET/INT H. Tschofenig Siemens Y. El Mghazli Alcatel G. Giaretta TILab R. Lopez Univ. of Murcia Y. Ohba Toshiba March 6, 2006 Use of Context Transfer Protocol (CXTP) for PANA draft-ietf-pana-cxtp-01 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 September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Bournelle (Ed.), et al. Expires September 7, 2006 [Page 1] Internet-Draft CXTP for PANA March 2006 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. The present document describes a solution based on the Context Transfer Protocol (CXTP) to enhance IP handover in mobile environments. Note that only the intra-domain case is considered. This protocol can recover the previously established PANA security context from previous PANA Authentication Agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Applicability Statement . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. PANA framework . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Performance limitations in mobile environments . . . . . . 5 2.3. CXTP protocol overview . . . . . . . . . . . . . . . . . . 6 3. CXTP usage in the PANA framework . . . . . . . . . . . . . . . 8 3.1. The Context Transfer Request Message . . . . . . . . . . . 9 3.2. The Context Transfer Data Message . . . . . . . . . . . . 10 4. Conditions to Perform the Transfer . . . . . . . . . . . . . . 13 5. Security considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Bournelle (Ed.), et al. Expires September 7, 2006 [Page 2] Internet-Draft CXTP for PANA March 2006 1. Introduction 1.1. Problem Statement 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. In some cases and without extensions to PANA, the PaC has to restart a new PANA protocol exchange to authenticate itself to the network. This authentication may need to execute the EAP exchange from scratch. In this document, we analyse the interaction between the framework defined in [RFC4067] and PANA. In particular, we define what should be transferred (i.e. the PANA context). Rough consensus in the PANA working group leaded to the solution where the transfer occurs between authentication agents, according to the recommendations in [I-D.ietf-pana-mobopts]. 1.2. Conventions Used in This Document 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 RFC 2119 [RFC2119]. 1.3. Terminology Most of the terms are defined in the PANA [I-D.ietf-pana-pana] and CXTP [RFC4067] 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. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 3] Internet-Draft CXTP for PANA March 2006 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 1.4. Applicability Statement This document defines use of CXTP for the PANA protocol. However, the specification is not fully compliant with CXTP. For this reason, this proposal MUST only be used to transfer PANA context. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 4] Internet-Draft CXTP for PANA March 2006 2. Background This section gives basic information on PANA framework and CXTP protocol. The intent here is to further explain the context being referred to and the terminology used in the remaining of the document. 2.1. PANA framework 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 AUTH AVP. 2.2. Performance limitations in mobile environments PaC ------------ pEP ---- pPAA | | | | | +------ pAR (IP handover) | | v PaC------------ nEP ---- nPAA | | +------ nAR Figure 1: Example Scenario Figure 1 shows an example scenario with a roaming PaC which has been previously authenticated. The PAA is at one IP hop away from PaC; this means that a specific PANA module on a PAA is in charge of one Bournelle (Ed.), et al. Expires September 7, 2006 [Page 5] Internet-Draft CXTP for PANA March 2006 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 degrade handover performance in term of latency. For this reason, we propose to use the Context Transfer Protocol (CXTP) to transfer the PANA context established between the PaC and pPAA to the nPAA. 2.3. CXTP protocol overview Context Transfer Protocol (CXTP) [RFC4067] 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) (cf. Figure 2). 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 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 requested context. MN nAR pAR -- --- --- | | | | CTAR | | +------------->| | | | CT-Request | | +------------->| | | | | | CTD | | |<-------------+ | CTAA | | |<-------------+ | Bournelle (Ed.), et al. Expires September 7, 2006 [Page 6] Internet-Draft CXTP for PANA March 2006 Figure 2: CXTP in reactive mode 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 September 7, 2006 [Page 7] Internet-Draft CXTP for PANA March 2006 3. CXTP usage in the PANA framework The transfer may occur either after or before the handover. From this standpoint, we only consider the reactive mode. This means that the PaC has already performed the handover. Predictive mode is left for further study. The solution described here is based on [I-D.ietf-pana-mobopts]: the transfer is triggered using the PANA signalling and CTD message is used to carry the PANA context. 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 AUTH AVP (cf. Figure 3). This AVP is computed using the PANA_AUTH_KEY shared between the PaC and its pPAA. PaC nPAA pPAA --- ---- ---- PSR[PAA_Nonce] <------------ PSA[oSession-ID][PaC_Nonce][AUTH] --------------> CT-Request [PSA] ----------------> CTD-PANA <---------------- PBR[nSession-Id][AUTH] <-------------- PBA [AUTH] ---------------> Figure 3: 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 and its identity encapsulated in TLVs. 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 Bournelle (Ed.), et al. Expires September 7, 2006 [Page 8] Internet-Draft CXTP for PANA March 2006 3.1. The Context Transfer Request Message While receiving the PSA message containg the old Session-Id, the PaC_Nonce and the AUTH AVP, the nPAA deduces that it must perform a context transfer. For this, it sends a CT-Request message containing its identity and the PSA message. The CT-Request message has the following header (cf. Figure 4)[RFC4067]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MN Authorization Token | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Next Requested Context Data Block (if present) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: CT-Request Header The 'V' flag is normally used to indicate if the packet contains an IPv4 or an IPv6 address in the Mobile Node's Previous IP Address field. In this specification, the PANA Client is identified by the previous PANA Session-ID that it shared with the previous PAA. This information is sent in the PSA message used to trigger the transfer. For this reason, the 'V' flag is not used and MUST be set to '0'. However, in order to match response to request, the nPAA uses the Mobile Node's Previous IP Address as an identifier field. This field MUST have a length of 32 bits. In CXTP, the authorization of the transfer is done through the use of the MN Authorization Token. In this specification, the pPAA authorizes the transfer using the PSA message sent by the nPAA. For this reason, this field is no longer present. As explained above, the nPAA sends its identity and the PSA message. These data are sent in a Context Data Block (CDB). Bournelle (Ed.), et al. Expires September 7, 2006 [Page 9] Internet-Draft CXTP for PANA March 2006 The Context Data Block header is represented Figure 5) [RFC4067]: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Feature Profile Type (FPT) | Length |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Presence Vector (if P = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Context Data Block The FPT indicates the type of data in the data field. The FPT in the case of PANA is TBD. The length field indicates the length of the CDB in 8 octets words, including the first 4 octets starting from FPT. The Presence Vector is not used in this specification. In the CT-Request message, the nPAA gives both its identity (DiameterIdentity) and the PSA message received from the PaC. For this reason, one use Type-Length-Value (TLV) packets format to carry these two informations. The TLV packet header format is shown in Figure 6 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: TLV header The field Type indicates either nPAA's identity (Type=0x01) or the PSA message (Type=0x02). The field Length indicates the length of the Value without padding in TBD octets. The field Value contains nPAA's identity (if Type=Ox01) or the PSA message (if Type=0x02). 3.2. The Context Transfer Data Message The Context Transfer Data Message is the message sent from the pPAA to the nPAA in response to a CT-Request. This message carries the PANA context. The CTD message header (as defined in [RFC4067]) is shown on Figure 7 Bournelle (Ed.), et al. Expires September 7, 2006 [Page 10] Internet-Draft CXTP for PANA March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V|A| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous Care-of Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | Algorithm | Key Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD | Key | only +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V ~ First Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Next Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: CTD header The pPAA MUST copy the identifier sent by the nPAA in the MN's Previous Care-of Address field of the CT-Request message in the corresponding field of the CTD message. As the predictive case is not considered in this current specification, the fields corresponding to PCTD are not used. The Context Data Block contains the PANA context sent from pPAA to the nPAA and is defined below. 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 specific to the pPAA and as such does not need to be transferred. Figure 8 summarizes the PANA Context. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 11] Internet-Draft CXTP for PANA March 2006 +------------------+------------+----------------------------+ | Data | Type | Length | +------------------+------------+----------------------------+ | Session-Lifetime | Unsigned32 | Fixed | | Remaining | | | +------------------+------------+----------------------------+ | AAA-Key-int | UTF8String | Fixed (64 octets) | +------------------+------------+----------------------------+ 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). For this reason, the pPAA provides to the nPAA the remaining Session-Lifetime. AAA-Key-int: cf. [I-D.ietf-pana-mobopts]. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 12] Internet-Draft CXTP for PANA March 2006 4. Conditions to Perform the Transfer In this section, we list conditions and recommendations 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 This solution only considers intradomain scenario. o Entities engaged in the context transfer should authenticate to 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. Thus pPAA and nPAA should have IPsec SAs to protect CXTP messages. 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. o The new key (AAA-Key-new) derived between PaC and nPAA is based on Nonces exchanged during PANA-Start-Exchange. For this reason, the proposed solution only work with PANA Stateful Discovery mechanism. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 13] Internet-Draft CXTP for PANA March 2006 5. Security considerations This document deals with interaction between the Seamoby Context Transfer Protocol and PANA. Therefore, all security considerations described in [RFC4067], in [I-D.ietf-pana-pana] and in [I-D.ietf- pana-mobopts] also apply 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 [RFC4067] 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. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 14] Internet-Draft CXTP for PANA March 2006 6. IANA Considerations TBD for FPT Bournelle (Ed.), et al. Expires September 7, 2006 [Page 15] Internet-Draft CXTP for PANA March 2006 7. Acknowledgements The authors would like to thank Sasikanth Bharadwaj, Vijay Devarapalli, James Kempf, Rajeev Koodli, Nakhjiri Madjid-MNAKHJI, Jean-Jacques Puig, Rene Soltwitsch and Alper Yegin for their valuable comments. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 16] Internet-Draft CXTP for PANA March 2006 8. Changes 8.1. Changes from 00 to 01 Added an Applicability Statement. Changed "Session-Lifetime Elapsed" to "Session-Lifetime Remaining". The nPAA sends its Identity in the CTB. For this purpose, we added TLVs. This identity is used for the AAA-Key-int Key computation. The Context Data Block is specified both for the CT-Request and CTD message. The MN's previous Care-of Address field is filled with an identifier in order to match requests to responses. Changed MAC AVP to AUTH AVP. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 17] Internet-Draft CXTP for PANA March 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-11 (work in progress), March 2006. [I-D.ietf-pana-mobopts] Forsberg, D., "PANA Mobility Optimizations", draft-ietf-pana-mobopts-01 (work in progress), October 2005. [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 9.2. Informative References [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [I-D.ietf-pana-snmp] Mghazli, Y., "SNMP usage for PAA-EP interface", draft-ietf-pana-snmp-05 (work in progress), January 2006. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [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 September 7, 2006 [Page 18] Internet-Draft CXTP for PANA March 2006 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 Mghazli 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 (Ed.), et al. Expires September 7, 2006 [Page 19] Internet-Draft CXTP for PANA March 2006 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 September 7, 2006 [Page 20] Internet-Draft CXTP for PANA March 2006 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 (2006). 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. Bournelle (Ed.), et al. Expires September 7, 2006 [Page 21]