Network Working Group J. Bournelle (Ed.) Internet-Draft M. Laurent-Maknavicius Expires: April 20, 2006 GET/INT R. Marin Lopez University of Murcia D. Forsberg Nokia J-M. Combes France Telecom R&D October 17, 2005 PANA Mobility Optimizations Analysis draft-bournelle-pana-mobopts-analysis-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 Bournelle (Ed.), et al. Expires April 20, 2006 [Page 1] Internet-Draft PANA Mobopts Analysis October 2005 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. To solve this problem, the PANA WG is currently working on a solution based on context transfer between PANA Authentication Agents. The aim of this document is to analyze how this proposal works in a WLAN environment considering various deployment scenarios. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. PANA overview . . . . . . . . . . . . . . . . . . . . . . . . 6 5. IP traffic security . . . . . . . . . . . . . . . . . . . . . 7 6. Intermediary key transfer and Domino effect . . . . . . . . . 8 7. Deployment scenarios in WLAN . . . . . . . . . . . . . . . . . 10 7.1 EP in AP and PAA in AP . . . . . . . . . . . . . . . . . . 10 7.1.1 Layer 2 filtering . . . . . . . . . . . . . . . . . . 10 7.1.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 10 7.2 EP in AP and PAA in AR . . . . . . . . . . . . . . . . . . 10 7.2.1 L2 filtering . . . . . . . . . . . . . . . . . . . . . 11 7.2.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 11 7.3 EP in AP and PAA > AR . . . . . . . . . . . . . . . . . . 11 7.3.1 L2 filtering . . . . . . . . . . . . . . . . . . . . . 11 7.3.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 11 7.4 EP in AR and PAA in AR . . . . . . . . . . . . . . . . . . 12 7.4.1 Without IPsec . . . . . . . . . . . . . . . . . . . . 12 7.4.2 With IPsec . . . . . . . . . . . . . . . . . . . . . . 12 7.5 EP in AR and PAA > AR . . . . . . . . . . . . . . . . . . 14 7.5.1 Without IPsec . . . . . . . . . . . . . . . . . . . . 14 7.5.2 With IPsec . . . . . . . . . . . . . . . . . . . . . . 16 8. AAA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 8.1 Reauthentication . . . . . . . . . . . . . . . . . . . . . 19 8.2 Session Termination . . . . . . . . . . . . . . . . . . . 20 8.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 20 8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . 25 Bournelle (Ed.), et al. Expires April 20, 2006 [Page 2] Internet-Draft PANA Mobopts Analysis October 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. The PANA mobility optimization [I-D.ietf-pana-mobopts] and its companion document [I-D.bournelle-pana-ctp] propose to transfer previous established context from the previous PAA to the new PAA. The goal is to avoid a reauthentication from scratch. This document analyses this proposal in WLAN environment depending on PANA deployment. The interaction with the AAA infrastructure is also considered. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 3] Internet-Draft PANA Mobopts Analysis October 2005 2. Terminology This document uses the following terms or abbreviations: AR Access Router. The router to which the PaC is attached . PaC PANA Client. A mobile node (MN) using a PANA protocol implementation to authenticate itself to the network. PAA PANA Authentication Agent. PANA Protocol for Carrying Network Authentication for Network Access Bournelle (Ed.), et al. Expires April 20, 2006 [Page 4] Internet-Draft PANA Mobopts Analysis October 2005 3. Notations In this document, the notations PAA > AR means that the PAA is located behind the Access Router (AR). The access router is the default router for the PaC. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 5] Internet-Draft PANA Mobopts Analysis October 2005 4. 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. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 6] Internet-Draft PANA Mobopts Analysis October 2005 5. IP traffic security We only consider here PANA deployment in a Wireless LAN environment. The first hop router of the PaC is the Access Router (AR). As noted above, the EP is the equipment on which security policies are applied to secure PaC's traffic. Depending on its location, the traffic will be protected at the layer 2 or at the layer 3. If the EP is colocated with the Access Point (L2), either the PAA configures L2 filtering based on MAC address or the PAA may bootstrap 802.11i [802.11i] security. If the EP is colocated in the AR, the PAA configures L3 filtering based on PaC's IP address or it provides IKE material to the EP to setup an IPsec tunnel between PaC and EP. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 7] Internet-Draft PANA Mobopts Analysis October 2005 6. Intermediary key transfer and Domino effect The pana-mobopts approach proposes to transfer an intermediary key between pPAA to the nPAA. This key AAA-Key-int is derived from the AAA-Key located at the pPAA. A new PANA_MAC_Key is then computed between the nPAA and the PaC based on Nonces exchanged during PANA- Start-Exchange. 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 EAP client (PaC) and the EAP server. 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) The document [I-D.ietf-pana-mobopts] proposes to provide to the nPAA an intermediary AAA-Key-int [I-D.ietf-pana-mobopts]. This key is computed as follows: 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. During the PANA-Start-Exchange (PSR/PSA), 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. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 8] Internet-Draft PANA Mobopts Analysis October 2005 The issue with this approach is that it does not completely fulfill one of the requirements described in [I-D.housley-aaa-key-mgmt] also known as Preventing the Domino effect: "Compromise of a single authenticator MUST NOT compromise any other part of the system, especially session keys and long-term keys. There are many implications of this requirement; however, two implications deserve highlighting. First, an authenticator MUST NOT share any keying material with another authenticator. Second, the scope of the authenticator needs to be defined and understood by all parties that communicate with it." In our case, if the pPAA is compromised and if the attacker gets the exchanged Nonces between PaC and nPAA, it can derive the new PANA_MAC_Key. However, even if the pPAA is compromised, only the PaC linked to the pPAA has security issues with nPAA and the attacker has to follow closed the PaC to take advantage of this security hole. It is also important to note that a PaC attached to the nPAA and having no links with the pPAA does not have security issues. One can also argue that if we suppose homogeneous deployment of PAAs, if the attacker can compromise the pPAA, it could also compromised the nPAA. This issue is currently not solved and further discussions are needed. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 9] Internet-Draft PANA Mobopts Analysis October 2005 7. Deployment scenarios in WLAN In this document, we only consider intra-domain case. This means that all equipments belong to the same administrative domain. PAAs may rely on the AAA infrastructure in order to authenticate PaCs. 7.1 EP in AP and PAA in AP In this case, EP and PAA are located in the AP. Normally, this will not be typical deployment of PAA however it is worth mentioning it due to this case is also considered in PANA framework [I-D.ietf-pana- framework]. As the EP is located in the AP , only layer 2 security will be considered. If no security on the link is needed, enable L2 filters for PaC's MAC address would be enough. Otherwise, some kind of L2 security association will be established. 7.1.1 Layer 2 filtering To be done. 7.1.2 802.11i To be done. 7.2 EP in AP and PAA in AR In this section, the EP is located in the AP and the PAA is in AR. The Figure 2 represents the architecture considered. We consider here two types of security: L2 filtering or 802.11i [802.11i]. Note that 802.11i is normally the combination of 802.1X [802.1X] for authentication, 4-way handshake to establish keying material at the supplicant (PaC) and authenticator (AP/EP) and CCMP/TKIP to protect the traffic at layer 2. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 10] Internet-Draft PANA Mobopts Analysis October 2005 +-------+ PaC |AP/EP_1+--------------+ | +-------+ | | +---+----+ | |AR/PAA_1| | +---+----+ | +-------+ | v |AP/EP_2+--------------+ | +-------+ | | +-------+ v |AP/EP_3+--------------+ +-------+ | +---+----+ |AR/PAA_2| +---+----+ +-------+ | |AP/EP_4+--------------+ +-------+ Figure 2: EP in AP and PAA in AR 7.2.1 L2 filtering To be done. 7.2.2 802.11i At this time, the PANA WG does not define any solution to bootstrap layer 2 security using PANA. For this reason, this section is left for future consideration. 7.3 EP in AP and PAA > AR In this section, we consider the case where the EP is located in AP and PAA are located inside the network (PANA multihop). 7.3.1 L2 filtering To Be Done. 7.3.2 802.11i At this time, the PANA WG does not define any solution to bootstrap layer 2 security using PANA. For this reason, this section is for future consideration. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 11] Internet-Draft PANA Mobopts Analysis October 2005 7.4 EP in AR and PAA in AR In this scenario, PAA and EP are colocated in the access router (AR). We only consider use of pana-mobopts in reactive case. 7.4.1 Without IPsec After the authentication phase, the PAA locally configures the EP for the PaC. We assume here that only IP filtering is applied on the EP. After an IP handover to the next AR, the PaC is detected by the EP and a new authentication is triggered. The PaC may also detect its handover and sends a PANA-Discovery message. In both cases, the nPAA sends a PSR message to the PaC. If pana- mobopts is enabled, the PAA must be stateful and the PSR carries a Nonce (PAA_Nonce). If the PaC replies with the correct PSA, the nPAA requests the PANA context to the pPAA and then runs a PANA-Bind- Exchange with the PaC. In case of success, the nPAA configures the nEP for the PaC. After this, the nPAA could reauthenticate from scratch the PaC. This procedure is depicted in the Figure 3. PaC nPAA pPAA --- ---- ---- PSR[PAA_Nonce] <------------ PSA[oSession-ID][PaC_Nonce][MAC] --------------> CT-Request [PSA] ----------------> CTD-PANA <---------------- PBR[nSession-Id][MAC] <-------------- PBA [MAC] ---------------> Figure 3: PANA mobopts without IPsec 7.4.2 With IPsec In this case, IPsec is used between the PaC and the EP to secure the Bournelle (Ed.), et al. Expires April 20, 2006 [Page 12] Internet-Draft PANA Mobopts Analysis October 2005 communication. For this, the PAA communicates the following information to the EP (cf. [I-D.ietf-pana-ipsec]) PaC-EP Master Key Key-Id Device-Identifier of the PaC Session-Id Thus, after the authentication phase, the PAA binds the session with the PaC (PANA-Bind-Exchange) and in the same time provides above information to the EP. Right after, PaC and EP initiate an IKE session to configure IPsec SAs. Then, the PaC uses its IPsec tunnel to send its IP traffic to the Internet. After an IP handover, the PaC is detected by the nEP and must be reauthenticated. If pana-mobopts is used, after a context transfer and a PANA-Bind exchange, the PaC and nPAA share a new session. Then nPAA provides necessary information to nEP to run IKE with the PaC. Then PaC and nEP use IKE to setup an IPsec tunnel. PaC pPAA/EP nPAA/EP --- ------ ------ PANA-Start <---------------> PANA-Auth <---------------> PANA-Bind <---------------> IKE <---------------> IP handover PANA-Start-mobopts <--------------------------------> PANA-Bind-mobopts <--------------------------------> IKE <--------------------------------> Bournelle (Ed.), et al. Expires April 20, 2006 [Page 13] Internet-Draft PANA Mobopts Analysis October 2005 Figure 4: PANA mobopts with IPsec Even if pana-mobopts is used, the re-establishment of the IKE session creates a latency after the handover. 7.5 EP in AR and PAA > AR In this scenario, we consider that EP is located in AR whereas the PAA is more than one IP hop away from the PaC (PANA multihop case). This scenario is described on the Figure 5. AR/EP_1 and AR/EP_2 are connected to PAA_1 and AR/EP_3 and AR/EP_4 are connected to PAA_2. +-------+ PaC |AR/EP_1+--------------+ | +-------+ | | +-+---+ | |PAA_1| | +-+---+ | +-------+ | v |AR/EP_2+--------------+ | +-------+ | | +-------+ v |AR/EP_3+--------------+ +-------+ | +-+---+ |PAA_2| +-+---+ +-------+ | |AR/EP_4+--------------+ +-------+ Figure 5: EP in AR and PAA > AR 7.5.1 Without IPsec First, the PAA_1 authenticates to PaC through AR/EP_1. After the authentication phase, PAA_1 configures AR/EP_1 to authorize network access of the PaC. Then the PaC moves to AR/EP_2. Note: A possible optimization could be that the AR/EP_2 is preconfigured by the PAA_1. This would however imply that the PAA_1 knows the PaC's address on AR/EP_2's network. If the AR/EP_2 is not preconfigured by PAA_1, the PaC obtains a new Bournelle (Ed.), et al. Expires April 20, 2006 [Page 14] Internet-Draft PANA Mobopts Analysis October 2005 address and is detected by the AR/EP_2 which triggers a reauthentication. Then two situations are possible. In the first one, the PAA_1 uses the same IP source address for the PSR message (i.e. the address that was used during the authentication through AR/EP_1). In this case, the PaC detects this and sends a PUR message containing its new IP address to update the Device- Identifier. The PAA configures the AR/EP_2 with the correct Device- Identifier. This is depicted in Figure 6. Note that this procedure is currently not handled in PANA state machine. PaC AR/EP_2 PAA_1 --- ------- ---- Trigger o ----------------> PSR <------------------------------------ PUR [nDevice-Id][MAC] --------------------------------------> Configuration <----------------- PUA [MAC] <------------------------------------ Figure 6: PAA_1 uses same IP address In the second one, the PAA uses a different address. Thus the PaC thinks that it is a different PAA and if pana-mobopts is enabled it sends the corresponding PSA message. PAA_1 detects that it was the previous PAA (in fact itself) and locally recovers corresponding PANA context. Then it derives new keying material as described in pana- mobopts and it runs a PANA-Bind exchange with the PaC reallocating a new PANA session. After this exchange, the PAA configures AR/EP_2 and the PaC can access to the Internet through it. PaC AR/EP_2 PAA_1 --- ------- ---- Trigger o ----------------> PANA-Start-Mobopts-Exchange <------------------------------------> PANA-Bind-Mobopts-Exchange <------------------------------------> Configuration <------------------ Bournelle (Ed.), et al. Expires April 20, 2006 [Page 15] Internet-Draft PANA Mobopts Analysis October 2005 In a second step, the PaC moves to AR/EP_3. In this case, the PaC can not recognize a known PAA and pana-mobopts/pana-ctp can be used here to retrieve PANA context from PAA_1. 7.5.2 With IPsec In this case, IPsec is used between PaC and EP. The PAA provides necessary information to the EP using SNMPv3 as specified in [I-D.ietf-pana-snmp]. At the beginning, the PaC is detected by AR/EP_1 and a PANA authentication phase occurs with PAA_1. After the authentication phase, PAA_1 derives necessary keying material, binds the session with the PaC and sends to AR/EP_1 the information. The PaC and AR/ EP_1 uses IKE to setup an IPsec tunnel as specified in [I-D.ietf- pana-ipsec]. Figure 8 presents the procedure. PaC AR/EP_1 PAA_1 --- ------- ---- Trigger o ----------------> PANA <------------------------------------> Configuration <------------------ IKE <---------------> Figure 8: PAA_1 uses the same IP address After this, the PaC moves to the AR/EP_2. It is detected by AR/EP_2 which triggers an authentication phase. A possible optimization could be to preconfigure the AR/EP_2. In this case, only IKE could be needed. If this optimization possible, PAA_1 can fallback in negotiation specified by [I-D.ietf-pana-mobopts] and depicted in Figure 9. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 16] Internet-Draft PANA Mobopts Analysis October 2005 PaC nPAA pPAA --- ---- ---- | | | 1 |<---------- live PANA session ----------->| | | | 2 x move from subnet1 | | | to subnet2 | | | | | | PDI | | 3 |---------------------->| | | PSR | | 4 |<----------------------| | | PSA | | 5 |---------------------->| CT-req | 6 | |----------------->| | | CT-resp | 7 | PBR |<-----------------| 8 |<----------------------| | | PBA | | 9 |---------------------->| | Figure 9: PANA mobopts with CxTP However, in this case nPAA and pPAA are the same entity but working on different IP address. Thus, CT-req and CT-resp could be done through an API. The PaC does not know that it is the same PAA and thus, if pana-mobopts is enabled, it sends a PSA-mobopts. The PAA_1 receives the PSA and detects that it can locally recover the context. It computes necessary keying material and binds the PANA session with the PaC. After this, it provides the AR/EP_2 with IKE material. Note that another alternative could also be considered. Taking into account the same PAA is attached to EPs and use the same IP address for both of them, PaC can detect this somehow (for example checking IP address included in PSR) and update the current PANA session with new PaC's IP address. This alternative is depicted on Figure 10. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 17] Internet-Draft PANA Mobopts Analysis October 2005 PaC AR/EP_2 PAA_1 --- ------- ---- Trigger o ----------------> PSR <------------------------------------ PUR [nDevice-Id][MAC] --------------------------------------> Configuration <----------------- PUA [MAC] <------------------------------------ IKE <--------------> Figure 10: PAA_1 uses the same IP address The PaC detects that it knows this PAA and responds with a PUR to update its Device-IDentifier (here the IP address). The PAA_1 replies with a PUA and sends necessary information to AR/EP_2 for IKE. Then PaC and EP run IKE to setup IPsec SAs. Unfortunately this solution needs some modifications in PANA state machine mainly because PaC would react discarding PSR because it is in OPEN state and source IP address of the PANA PSR message is the same. Nonetheless this solution reduces signalling with respect to previous version. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 18] Internet-Draft PANA Mobopts Analysis October 2005 8. AAA Considerations PAAs may rely on the AAA infrastructure in order to authenticate PaC. The interaction between PANA and AAA protocols (RADIUS and Diameter) is described in [I-D.ieft-pana-aaa-interworking]. The figure below is extracted from [I-D.ieft-pana-aaa-interworking]. +------------------------------+ +-----+ | +-----+ +---------------+ | +---------------+ | | | | | | | | | | | PaC +---+--+ PAA +--+ AAA client |--+-----+ AAA server | | | | | | | | | | | +-----+ | +-----+ +---------------+ | +---------------+ | Network Access Server(NAS) | +------------------------------+ Figure 11: PANA with AAA We assume here that the EAP server is colocated with the AAA server. In the roaming scenario, the EAP server is located in the home domain. Depending on operator's deployment, the AAA traffic is routed through a local AAA server or directly sent from the NAS to the AAAH (using redirection functionality). Considering Diameter, the NAS shares a session-id with the AAA server per PaC. This session-id is used in each AAA message concerning a PaC (e.g. for accounting). 8.1 Reauthentication The home AAA server may need to contact a PaC in order to reauthenticate him or to close a session. The reauthentication mechanism is described in [RFC4005]. The AAA server sends a Re-Auth- Request (RAR) message to the NAS containing the session-id. We consider here two distinct scenarios. In non-roaming scenario, the local AAA server needs to know the NAS in charge of the PaC. This implies that if the PaC moves during the session between different PAAs, the local AAA server must be informed of this. For this purpose, a new session must be shared between the nPAA and the AAA server. In roaming scenario, two cases appeared. In the first case, we have a direct communication between PAA and AAAH. This case is similar Bournelle (Ed.), et al. Expires April 20, 2006 [Page 19] Internet-Draft PANA Mobopts Analysis October 2005 than above and the AAAH must be informed of the current PAAs. In the second case, the AAA traffic is routed through the local AAA server. In this case, we may consider that only the local AAA server needs to keep track of the current PAA. 8.2 Session Termination While a user's session is being terminated, the NAS sends a message to the AAA server. Thus, the nPAA must know the AAA server used to authenticate the PaC and it must share a session with it. 8.3 Accounting The accounting is an important part of the AAA architecture. For this purpose, the NAS sends accounting report to an accounting server (probably colocated with the AAA server used for authentication). The accounting process should handle PaC's handover. This means that the Accounting server should receive accouting report from the nPAA and should be able to know that it is the same PaC. 8.4 Conclusion Considering the whole network access authentication architecture, it appears that we also need to reestablish a context between the nPAA and the AAA infrastructure to handle PaC's handover. In particular, the nPAA must re-establish a session with the AAA server that was used by pPAA. For this purpose, the pPAA could send context information to the nPAA, which can then re-establish AAA session for the PaC. Another alternative would be to have a local AAA Proxy that hides the AAA session mobility between PAAs from the AAAH. This implies that the AAA infrastructure must also be considered while defining a solution for mobility optimization in PANA environment. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 20] Internet-Draft PANA Mobopts Analysis October 2005 9. Conclusion The goal of this document is to analyze pana-mobopts in WLAN environment in order to raise discussions. The 802.11i bootstrapping is not analyzed since the document is not yet submitted. It appears that considering PANA multihop, some optimizations may be possible by proactively distributing some information to EP. The PANA preauthentication is not yet analyzed in this document. It appears that the AAA infrastructure must be considered while defining a global optimization for mobility. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 21] Internet-Draft PANA Mobopts Analysis October 2005 10. Security Considerations This document does not define a new protocol nor mechanism. For this reason, this section is left empty. 11. References [802.11i] Institute of Electrical and Electronics Engineer, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", IEEE std. 802.11i, July 2004. [802.1X] Institute of Electrical and Electronics Engineer, "IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control", IEEE std. 802.1X-2004. [I-D.ietf-eap-keying] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-07 (work in progress), July 2005. [I-D.housley-aaa-key-mgmt] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-aaa-key-mgmt-00 (work in progress), June 2005. [I-D.ietf-pana-mobopts] Forsberg, D., "PANA Mobility Optimizations", draft-ietf-pana-mobopts-00 (work in progress), January 2005. [I-D.ietf-pana-pana] Forsberg, D., "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-10 (work in progress), July 2005. [I-D.ietf-pana-ipsec] Parthasarathy, M., "PANA Enabling IPsec based Access Control", draft-ietf-pana-ipsec-07 (work in progress), July 2005. [I-D.ietf-pana-snmp] Mghazli, Y., "SNMP usage for PAA-EP interface", draft-ietf-pana-snmp-04 (work in progress), July 2005. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 22] Internet-Draft PANA Mobopts Analysis October 2005 [I-D.ietf-pana-framework] Jayaraman, P., "PANA Framework", draft-ietf-pana-framework-05 (work in progress), July 2005. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. [I-D.ieft-pana-aaa-interworking] Lior, A. and A. Yegin, "PANA AAA Interworking.", draft-ieft-pana-aaa-interworking-00 (work in progress), July 2005. [I-D.bournelle-pana-ctp] Bournelle, J., "Use of Context Transfer Protocol (CxTP) for PANA", draft-bournelle-pana-ctp-03 (work in progress), June 2005. 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 Rafa Marin Lopez University of Murcia Murcia 30071 Spain Email: rafa@dif.um.es Bournelle (Ed.), et al. Expires April 20, 2006 [Page 23] Internet-Draft PANA Mobopts Analysis October 2005 Dan Forsberg Nokia P.O Box 407 NOKIA GROUP FIN-0045 Finland Email: dan.forsberg@nokia.com Jean-Michel Combes France Telecom R&D 38/40 rue du General Leclerc Issy-les-Moulineaux 92794 France Email: jeanmichel.combes@francetelecom.com Bournelle (Ed.), et al. Expires April 20, 2006 [Page 24] Internet-Draft PANA Mobopts Analysis October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 April 20, 2006 [Page 25] Internet-Draft PANA Mobopts Analysis October 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bournelle (Ed.), et al. Expires April 20, 2006 [Page 26]