idnits 2.17.00 (12 Aug 2021) /tmp/idnits44814/draft-bournelle-pana-mobopts-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 214: '...le authenticator MUST NOT compromise a...' RFC 2119 keyword, line 217: '...ing. First, an authenticator MUST NOT...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6059 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MAC' is mentioned on line 585, but not defined == Missing Reference: 'PSA' is mentioned on line 351, but not defined == Unused Reference: 'I-D.ietf-pana-framework' is defined on line 742, but no explicit reference was found in the text == Outdated reference: draft-ietf-eap-keying has been published as RFC 5247 == Outdated reference: draft-housley-aaa-key-mgmt has been published as RFC 4962 == Outdated reference: A later version (-01) exists of draft-ietf-pana-mobopts-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-mobopts' == Outdated reference: draft-ietf-pana-pana has been published as RFC 5191 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-snmp' == Outdated reference: draft-ietf-pana-framework has been published as RFC 5193 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-framework (ref. 'I-D.ietf-pana-framework') ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) -- No information found for draft-ieft-pana-aaa-interworking - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ieft-pana-aaa-interworking' -- Possible downref: Normative reference to a draft: ref. 'I-D.bournelle-pana-ctp' Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Bournelle (Ed.) 3 Internet-Draft M. Laurent-Maknavicius 4 Expires: April 20, 2006 GET/INT 5 R. Marin Lopez 6 University of Murcia 7 D. Forsberg 8 Nokia 9 J-M. Combes 10 France Telecom R&D 11 October 17, 2005 13 PANA Mobility Optimizations Analysis 14 draft-bournelle-pana-mobopts-analysis-00 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on April 20, 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 The PANA protocol offers a way to authenticate clients in IP based 48 access networks. It carries EAP over UDP which permits ISPs to use 49 multiple authentication methods. However, in roaming environments IP 50 clients might change of gateways and new EAP authentication from 51 scratch may occur. This can considerably degrade performance. To 52 solve this problem, the PANA WG is currently working on a solution 53 based on context transfer between PANA Authentication Agents. The 54 aim of this document is to analyze how this proposal works in a WLAN 55 environment considering various deployment scenarios. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. PANA overview . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5. IP traffic security . . . . . . . . . . . . . . . . . . . . . 7 64 6. Intermediary key transfer and Domino effect . . . . . . . . . 8 65 7. Deployment scenarios in WLAN . . . . . . . . . . . . . . . . . 10 66 7.1 EP in AP and PAA in AP . . . . . . . . . . . . . . . . . . 10 67 7.1.1 Layer 2 filtering . . . . . . . . . . . . . . . . . . 10 68 7.1.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.2 EP in AP and PAA in AR . . . . . . . . . . . . . . . . . . 10 70 7.2.1 L2 filtering . . . . . . . . . . . . . . . . . . . . . 11 71 7.2.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 11 72 7.3 EP in AP and PAA > AR . . . . . . . . . . . . . . . . . . 11 73 7.3.1 L2 filtering . . . . . . . . . . . . . . . . . . . . . 11 74 7.3.2 802.11i . . . . . . . . . . . . . . . . . . . . . . . 11 75 7.4 EP in AR and PAA in AR . . . . . . . . . . . . . . . . . . 12 76 7.4.1 Without IPsec . . . . . . . . . . . . . . . . . . . . 12 77 7.4.2 With IPsec . . . . . . . . . . . . . . . . . . . . . . 12 78 7.5 EP in AR and PAA > AR . . . . . . . . . . . . . . . . . . 14 79 7.5.1 Without IPsec . . . . . . . . . . . . . . . . . . . . 14 80 7.5.2 With IPsec . . . . . . . . . . . . . . . . . . . . . . 16 81 8. AAA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 82 8.1 Reauthentication . . . . . . . . . . . . . . . . . . . . . 19 83 8.2 Session Termination . . . . . . . . . . . . . . . . . . . 20 84 8.3 Accounting . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 90 Intellectual Property and Copyright Statements . . . . . . . . 25 92 1. Introduction 94 In IP based access network, PANA [I-D.ietf-pana-pana] may be used as 95 a front-end to a AAA architecture in order to authenticate users 96 before granting them access to the resources. For this purpose, it 97 uses EAP which offers a variety of authentication methods. 99 The PANA mobility optimization [I-D.ietf-pana-mobopts] and its 100 companion document [I-D.bournelle-pana-ctp] propose to transfer 101 previous established context from the previous PAA to the new PAA. 102 The goal is to avoid a reauthentication from scratch. This document 103 analyses this proposal in WLAN environment depending on PANA 104 deployment. The interaction with the AAA infrastructure is also 105 considered. 107 2. Terminology 109 This document uses the following terms or abbreviations: 111 AR Access Router. The router to which the PaC is attached . 113 PaC PANA Client. A mobile node (MN) using a PANA protocol 114 implementation to authenticate itself to the network. 116 PAA PANA Authentication Agent. 118 PANA Protocol for Carrying Network Authentication for Network Access 120 3. Notations 122 In this document, the notations PAA > AR means that the PAA is 123 located behind the Access Router (AR). The access router is the 124 default router for the PaC. 126 4. PANA overview 128 PANA is a protocol that carries EAP over IP/UDP to authenticate 129 users. The PANA Authentication Agent (PAA) is the endpoint of the 130 PANA protocol at the access network. The PAA itself might not be 131 able to authenticate the user by terminating the EAP protocol. 132 Instead the PAA might forward the EAP payloads to the backend AAA 133 infrastructure. 135 The Enforcement Point (EP) is an entity which enforces the result of 136 the PANA protocol exchange. The EP might be co-located with the PAA 137 or separated as a stand-alone device. In the latter case, the SNMPv3 138 protocol [I-D.ietf-pana-snmp] is used to communicate between PAA and 139 EP. 141 A successful EAP authentication exchange results in a PANA security 142 association (PANA SA) if the EAP method was able to derive session 143 keys. In this case, all further PANA messages between PaC and PAA 144 will be authenticated, replay and integrity protected thanks to the 145 MAC AVP. 147 5. IP traffic security 149 We only consider here PANA deployment in a Wireless LAN environment. 150 The first hop router of the PaC is the Access Router (AR). 152 As noted above, the EP is the equipment on which security policies 153 are applied to secure PaC's traffic. Depending on its location, the 154 traffic will be protected at the layer 2 or at the layer 3. 156 If the EP is colocated with the Access Point (L2), either the PAA 157 configures L2 filtering based on MAC address or the PAA may bootstrap 158 802.11i [802.11i] security. 160 If the EP is colocated in the AR, the PAA configures L3 filtering 161 based on PaC's IP address or it provides IKE material to the EP to 162 setup an IPsec tunnel between PaC and EP. 164 6. Intermediary key transfer and Domino effect 166 The pana-mobopts approach proposes to transfer an intermediary key 167 between pPAA to the nPAA. This key AAA-Key-int is derived from the 168 AAA-Key located at the pPAA. A new PANA_MAC_Key is then computed 169 between the nPAA and the PaC based on Nonces exchanged during PANA- 170 Start-Exchange. 172 According to EAP [I-D.ietf-eap-keying], the figure below illustrates 173 the keys hierarchy in the PANA case: 175 PaC pPAA AAA/EAP 176 --- ---- ------- 177 MSK MSK MSK 178 EMSK EMSK 179 AAA-Key AAA-Key <---------- AAA-Key 181 PANA_MAC_Key PANA_MAC_Key 183 MSK and EMSK are derived from the EAP method used between the EAP 184 client (PaC) and the EAP server. The AAA-Key is computed from MSK 185 and EMSK. This key is exported to the pPAA. The PANA_MAC_KEY, used 186 to protect PANA messages, is derived from the AAA-Key as follows: 188 PANA_MAC_KEY = The first N bits of 189 HMAC_SHA1(AAA-Key, PaC_nonce | PAA_nonce | Session-ID) 191 The document [I-D.ietf-pana-mobopts] proposes to provide to the nPAA 192 an intermediary AAA-Key-int [I-D.ietf-pana-mobopts]. This key is 193 computed as follows: 195 AAA-Key-int = The first N bits of 196 HMAC-SHA1(AAA-Key, DiameterIdentity | Session-ID) 198 DiameterIdentity is the identifier of the pPAA and Session-ID is the 199 identifier of the Session between the pPAA and PaC. 201 During the PANA-Start-Exchange (PSR/PSA), PaC and nPAA provide nonces 202 that are used to derive a new AAA-Key: 204 AAA-Key-new = The first N bits of 205 HMAC-SHA1(AAA-Key-int, PaC_nonce | PAA_nonce) 207 The new PANA_MAC_Key used to compute AVP MAC will be calculated from 208 this key. 210 The issue with this approach is that it does not completely fulfill 211 one of the requirements described in [I-D.housley-aaa-key-mgmt] also 212 known as Preventing the Domino effect: 214 "Compromise of a single authenticator MUST NOT compromise any other 215 part of the system, especially session keys and long-term keys. 216 There are many implications of this requirement; however, two 217 implications deserve highlighting. First, an authenticator MUST NOT 218 share any keying material with another authenticator. Second, the 219 scope of the authenticator needs to be defined and understood by all 220 parties that communicate with it." 222 In our case, if the pPAA is compromised and if the attacker gets the 223 exchanged Nonces between PaC and nPAA, it can derive the new 224 PANA_MAC_Key. 226 However, even if the pPAA is compromised, only the PaC linked to the 227 pPAA has security issues with nPAA and the attacker has to follow 228 closed the PaC to take advantage of this security hole. It is also 229 important to note that a PaC attached to the nPAA and having no links 230 with the pPAA does not have security issues. 232 One can also argue that if we suppose homogeneous deployment of PAAs, 233 if the attacker can compromise the pPAA, it could also compromised 234 the nPAA. 236 This issue is currently not solved and further discussions are 237 needed. 239 7. Deployment scenarios in WLAN 241 In this document, we only consider intra-domain case. This means 242 that all equipments belong to the same administrative domain. PAAs 243 may rely on the AAA infrastructure in order to authenticate PaCs. 245 7.1 EP in AP and PAA in AP 247 In this case, EP and PAA are located in the AP. Normally, this will 248 not be typical deployment of PAA however it is worth mentioning it 249 due to this case is also considered in PANA framework [I-D.ietf-pana- 250 framework]. 252 As the EP is located in the AP , only layer 2 security will be 253 considered. If no security on the link is needed, enable L2 filters 254 for PaC's MAC address would be enough. Otherwise, some kind of L2 255 security association will be established. 257 7.1.1 Layer 2 filtering 259 To be done. 261 7.1.2 802.11i 263 To be done. 265 7.2 EP in AP and PAA in AR 267 In this section, the EP is located in the AP and the PAA is in AR. 268 The Figure 2 represents the architecture considered. We consider 269 here two types of security: L2 filtering or 802.11i [802.11i]. Note 270 that 802.11i is normally the combination of 802.1X [802.1X] for 271 authentication, 4-way handshake to establish keying material at the 272 supplicant (PaC) and authenticator (AP/EP) and CCMP/TKIP to protect 273 the traffic at layer 2. 275 +-------+ 276 PaC |AP/EP_1+--------------+ 277 | +-------+ | 278 | +---+----+ 279 | |AR/PAA_1| 280 | +---+----+ 281 | +-------+ | 282 v |AP/EP_2+--------------+ 283 | +-------+ 284 | 285 | +-------+ 286 v |AP/EP_3+--------------+ 287 +-------+ | 288 +---+----+ 289 |AR/PAA_2| 290 +---+----+ 291 +-------+ | 292 |AP/EP_4+--------------+ 293 +-------+ 295 Figure 2: EP in AP and PAA in AR 297 7.2.1 L2 filtering 299 To be done. 301 7.2.2 802.11i 303 At this time, the PANA WG does not define any solution to bootstrap 304 layer 2 security using PANA. For this reason, this section is left 305 for future consideration. 307 7.3 EP in AP and PAA > AR 309 In this section, we consider the case where the EP is located in AP 310 and PAA are located inside the network (PANA multihop). 312 7.3.1 L2 filtering 314 To Be Done. 316 7.3.2 802.11i 318 At this time, the PANA WG does not define any solution to bootstrap 319 layer 2 security using PANA. For this reason, this section is for 320 future consideration. 322 7.4 EP in AR and PAA in AR 324 In this scenario, PAA and EP are colocated in the access router (AR). 325 We only consider use of pana-mobopts in reactive case. 327 7.4.1 Without IPsec 329 After the authentication phase, the PAA locally configures the EP for 330 the PaC. We assume here that only IP filtering is applied on the EP. 331 After an IP handover to the next AR, the PaC is detected by the EP 332 and a new authentication is triggered. The PaC may also detect its 333 handover and sends a PANA-Discovery message. 335 In both cases, the nPAA sends a PSR message to the PaC. If pana- 336 mobopts is enabled, the PAA must be stateful and the PSR carries a 337 Nonce (PAA_Nonce). If the PaC replies with the correct PSA, the nPAA 338 requests the PANA context to the pPAA and then runs a PANA-Bind- 339 Exchange with the PaC. In case of success, the nPAA configures the 340 nEP for the PaC. After this, the nPAA could reauthenticate from 341 scratch the PaC. This procedure is depicted in the Figure 3. 343 PaC nPAA pPAA 344 --- ---- ---- 345 PSR[PAA_Nonce] 346 <------------ 348 PSA[oSession-ID][PaC_Nonce][MAC] 349 --------------> 351 CT-Request [PSA] 352 ----------------> 353 CTD-PANA 354 <---------------- 355 PBR[nSession-Id][MAC] 356 <-------------- 357 PBA [MAC] 358 ---------------> 360 Figure 3: PANA mobopts without IPsec 362 7.4.2 With IPsec 364 In this case, IPsec is used between the PaC and the EP to secure the 365 communication. For this, the PAA communicates the following 366 information to the EP (cf. [I-D.ietf-pana-ipsec]) 368 PaC-EP Master Key 370 Key-Id 372 Device-Identifier of the PaC 374 Session-Id 376 Thus, after the authentication phase, the PAA binds the session with 377 the PaC (PANA-Bind-Exchange) and in the same time provides above 378 information to the EP. Right after, PaC and EP initiate an IKE 379 session to configure IPsec SAs. Then, the PaC uses its IPsec tunnel 380 to send its IP traffic to the Internet. 382 After an IP handover, the PaC is detected by the nEP and must be 383 reauthenticated. If pana-mobopts is used, after a context transfer 384 and a PANA-Bind exchange, the PaC and nPAA share a new session. Then 385 nPAA provides necessary information to nEP to run IKE with the PaC. 386 Then PaC and nEP use IKE to setup an IPsec tunnel. 388 PaC pPAA/EP nPAA/EP 389 --- ------ ------ 390 PANA-Start 391 <---------------> 392 PANA-Auth 393 <---------------> 394 PANA-Bind 395 <---------------> 396 IKE 397 <---------------> 399 IP handover 401 PANA-Start-mobopts 402 <--------------------------------> 403 PANA-Bind-mobopts 404 <--------------------------------> 405 IKE 406 <--------------------------------> 407 Figure 4: PANA mobopts with IPsec 409 Even if pana-mobopts is used, the re-establishment of the IKE session 410 creates a latency after the handover. 412 7.5 EP in AR and PAA > AR 414 In this scenario, we consider that EP is located in AR whereas the 415 PAA is more than one IP hop away from the PaC (PANA multihop case). 416 This scenario is described on the Figure 5. AR/EP_1 and AR/EP_2 are 417 connected to PAA_1 and AR/EP_3 and AR/EP_4 are connected to PAA_2. 419 +-------+ 420 PaC |AR/EP_1+--------------+ 421 | +-------+ | 422 | +-+---+ 423 | |PAA_1| 424 | +-+---+ 425 | +-------+ | 426 v |AR/EP_2+--------------+ 427 | +-------+ 428 | 429 | +-------+ 430 v |AR/EP_3+--------------+ 431 +-------+ | 432 +-+---+ 433 |PAA_2| 434 +-+---+ 435 +-------+ | 436 |AR/EP_4+--------------+ 437 +-------+ 439 Figure 5: EP in AR and PAA > AR 441 7.5.1 Without IPsec 443 First, the PAA_1 authenticates to PaC through AR/EP_1. After the 444 authentication phase, PAA_1 configures AR/EP_1 to authorize network 445 access of the PaC. Then the PaC moves to AR/EP_2. 447 Note: A possible optimization could be that the AR/EP_2 is 448 preconfigured by the PAA_1. This would however imply that the PAA_1 449 knows the PaC's address on AR/EP_2's network. 451 If the AR/EP_2 is not preconfigured by PAA_1, the PaC obtains a new 452 address and is detected by the AR/EP_2 which triggers a 453 reauthentication. Then two situations are possible. 455 In the first one, the PAA_1 uses the same IP source address for the 456 PSR message (i.e. the address that was used during the authentication 457 through AR/EP_1). In this case, the PaC detects this and sends a PUR 458 message containing its new IP address to update the Device- 459 Identifier. The PAA configures the AR/EP_2 with the correct Device- 460 Identifier. This is depicted in Figure 6. Note that this procedure 461 is currently not handled in PANA state machine. 463 PaC AR/EP_2 PAA_1 464 --- ------- ---- 465 Trigger 466 o ----------------> 467 PSR 468 <------------------------------------ 469 PUR [nDevice-Id][MAC] 470 --------------------------------------> 471 Configuration 472 <----------------- 473 PUA [MAC] 474 <------------------------------------ 476 Figure 6: PAA_1 uses same IP address 478 In the second one, the PAA uses a different address. Thus the PaC 479 thinks that it is a different PAA and if pana-mobopts is enabled it 480 sends the corresponding PSA message. PAA_1 detects that it was the 481 previous PAA (in fact itself) and locally recovers corresponding PANA 482 context. Then it derives new keying material as described in pana- 483 mobopts and it runs a PANA-Bind exchange with the PaC reallocating a 484 new PANA session. After this exchange, the PAA configures AR/EP_2 485 and the PaC can access to the Internet through it. 487 PaC AR/EP_2 PAA_1 488 --- ------- ---- 489 Trigger 490 o ----------------> 491 PANA-Start-Mobopts-Exchange 492 <------------------------------------> 493 PANA-Bind-Mobopts-Exchange 494 <------------------------------------> 495 Configuration 496 <------------------ 498 In a second step, the PaC moves to AR/EP_3. In this case, the PaC 499 can not recognize a known PAA and pana-mobopts/pana-ctp can be used 500 here to retrieve PANA context from PAA_1. 502 7.5.2 With IPsec 504 In this case, IPsec is used between PaC and EP. The PAA provides 505 necessary information to the EP using SNMPv3 as specified in 506 [I-D.ietf-pana-snmp]. 508 At the beginning, the PaC is detected by AR/EP_1 and a PANA 509 authentication phase occurs with PAA_1. After the authentication 510 phase, PAA_1 derives necessary keying material, binds the session 511 with the PaC and sends to AR/EP_1 the information. The PaC and AR/ 512 EP_1 uses IKE to setup an IPsec tunnel as specified in [I-D.ietf- 513 pana-ipsec]. Figure 8 presents the procedure. 515 PaC AR/EP_1 PAA_1 516 --- ------- ---- 517 Trigger 518 o ----------------> 519 PANA 520 <------------------------------------> 521 Configuration 522 <------------------ 523 IKE 524 <---------------> 526 Figure 8: PAA_1 uses the same IP address 528 After this, the PaC moves to the AR/EP_2. It is detected by AR/EP_2 529 which triggers an authentication phase. 531 A possible optimization could be to preconfigure the AR/EP_2. In 532 this case, only IKE could be needed. 534 If this optimization possible, PAA_1 can fallback in negotiation 535 specified by [I-D.ietf-pana-mobopts] and depicted in Figure 9. 537 PaC nPAA pPAA 538 --- ---- ---- 539 | | | 540 1 |<---------- live PANA session ----------->| 541 | | | 542 2 x move from subnet1 | | 543 | to subnet2 | | 544 | | | 545 | PDI | | 546 3 |---------------------->| | 547 | PSR | | 548 4 |<----------------------| | 549 | PSA | | 550 5 |---------------------->| CT-req | 551 6 | |----------------->| 552 | | CT-resp | 553 7 | PBR |<-----------------| 554 8 |<----------------------| | 555 | PBA | | 556 9 |---------------------->| | 558 Figure 9: PANA mobopts with CxTP 560 However, in this case nPAA and pPAA are the same entity but working 561 on different IP address. Thus, CT-req and CT-resp could be done 562 through an API. The PaC does not know that it is the same PAA and 563 thus, if pana-mobopts is enabled, it sends a PSA-mobopts. The PAA_1 564 receives the PSA and detects that it can locally recover the context. 565 It computes necessary keying material and binds the PANA session with 566 the PaC. After this, it provides the AR/EP_2 with IKE material. 568 Note that another alternative could also be considered. Taking into 569 account the same PAA is attached to EPs and use the same IP address 570 for both of them, PaC can detect this somehow (for example checking 571 IP address included in PSR) and update the current PANA session with 572 new PaC's IP address. This alternative is depicted on Figure 10. 574 PaC AR/EP_2 PAA_1 575 --- ------- ---- 576 Trigger 577 o ----------------> 578 PSR 579 <------------------------------------ 580 PUR [nDevice-Id][MAC] 581 --------------------------------------> 582 Configuration 583 <----------------- 585 PUA [MAC] 586 <------------------------------------ 587 IKE 588 <--------------> 590 Figure 10: PAA_1 uses the same IP address 592 The PaC detects that it knows this PAA and responds with a PUR to 593 update its Device-IDentifier (here the IP address). The PAA_1 594 replies with a PUA and sends necessary information to AR/EP_2 for 595 IKE. Then PaC and EP run IKE to setup IPsec SAs. 597 Unfortunately this solution needs some modifications in PANA state 598 machine mainly because PaC would react discarding PSR because it is 599 in OPEN state and source IP address of the PANA PSR message is the 600 same. Nonetheless this solution reduces signalling with respect to 601 previous version. 603 8. AAA Considerations 605 PAAs may rely on the AAA infrastructure in order to authenticate PaC. 606 The interaction between PANA and AAA protocols (RADIUS and Diameter) 607 is described in [I-D.ieft-pana-aaa-interworking]. 609 The figure below is extracted from [I-D.ieft-pana-aaa-interworking]. 611 +------------------------------+ 612 +-----+ | +-----+ +---------------+ | +---------------+ 613 | | | | | | | | | | 614 | PaC +---+--+ PAA +--+ AAA client |--+-----+ AAA server | 615 | | | | | | | | | | 616 +-----+ | +-----+ +---------------+ | +---------------+ 617 | Network Access Server(NAS) | 618 +------------------------------+ 620 Figure 11: PANA with AAA 622 We assume here that the EAP server is colocated with the AAA server. 623 In the roaming scenario, the EAP server is located in the home 624 domain. Depending on operator's deployment, the AAA traffic is 625 routed through a local AAA server or directly sent from the NAS to 626 the AAAH (using redirection functionality). 628 Considering Diameter, the NAS shares a session-id with the AAA server 629 per PaC. This session-id is used in each AAA message concerning a 630 PaC (e.g. for accounting). 632 8.1 Reauthentication 634 The home AAA server may need to contact a PaC in order to 635 reauthenticate him or to close a session. The reauthentication 636 mechanism is described in [RFC4005]. The AAA server sends a Re-Auth- 637 Request (RAR) message to the NAS containing the session-id. We 638 consider here two distinct scenarios. 640 In non-roaming scenario, the local AAA server needs to know the NAS 641 in charge of the PaC. This implies that if the PaC moves during the 642 session between different PAAs, the local AAA server must be informed 643 of this. For this purpose, a new session must be shared between the 644 nPAA and the AAA server. 646 In roaming scenario, two cases appeared. In the first case, we have 647 a direct communication between PAA and AAAH. This case is similar 648 than above and the AAAH must be informed of the current PAAs. In the 649 second case, the AAA traffic is routed through the local AAA server. 650 In this case, we may consider that only the local AAA server needs to 651 keep track of the current PAA. 653 8.2 Session Termination 655 While a user's session is being terminated, the NAS sends a message 656 to the AAA server. Thus, the nPAA must know the AAA server used to 657 authenticate the PaC and it must share a session with it. 659 8.3 Accounting 661 The accounting is an important part of the AAA architecture. For 662 this purpose, the NAS sends accounting report to an accounting server 663 (probably colocated with the AAA server used for authentication). 664 The accounting process should handle PaC's handover. This means that 665 the Accounting server should receive accouting report from the nPAA 666 and should be able to know that it is the same PaC. 668 8.4 Conclusion 670 Considering the whole network access authentication architecture, it 671 appears that we also need to reestablish a context between the nPAA 672 and the AAA infrastructure to handle PaC's handover. In particular, 673 the nPAA must re-establish a session with the AAA server that was 674 used by pPAA. For this purpose, the pPAA could send context 675 information to the nPAA, which can then re-establish AAA session for 676 the PaC. Another alternative would be to have a local AAA Proxy that 677 hides the AAA session mobility between PAAs from the AAAH. 679 This implies that the AAA infrastructure must also be considered 680 while defining a solution for mobility optimization in PANA 681 environment. 683 9. Conclusion 685 The goal of this document is to analyze pana-mobopts in WLAN 686 environment in order to raise discussions. The 802.11i bootstrapping 687 is not analyzed since the document is not yet submitted. It appears 688 that considering PANA multihop, some optimizations may be possible by 689 proactively distributing some information to EP. The PANA 690 preauthentication is not yet analyzed in this document. It appears 691 that the AAA infrastructure must be considered while defining a 692 global optimization for mobility. 694 10. Security Considerations 696 This document does not define a new protocol nor mechanism. For this 697 reason, this section is left empty. 699 11. References 701 [802.11i] Institute of Electrical and Electronics Engineer, 702 "Supplement to Standard for Telecommunications and 703 Information Exchange Between Systems - LAN/MAN Specific 704 Requirements - Part 11:Wireless LAN Medium Access Control 705 (MAC) and Physical Layer (PHY) Specifications: 706 Specification for Enhanced Security", IEEE std. 802.11i, 707 July 2004. 709 [802.1X] Institute of Electrical and Electronics Engineer, "IEEE 710 Standards for Local and Metropolitan Area Networks: Port 711 based Network Access Control", IEEE std. 802.1X-2004. 713 [I-D.ietf-eap-keying] 714 Aboba, B., "Extensible Authentication Protocol (EAP) Key 715 Management Framework", draft-ietf-eap-keying-07 (work in 716 progress), July 2005. 718 [I-D.housley-aaa-key-mgmt] 719 Housley, R. and B. Aboba, "AAA Key Management", 720 draft-housley-aaa-key-mgmt-00 (work in progress), 721 June 2005. 723 [I-D.ietf-pana-mobopts] 724 Forsberg, D., "PANA Mobility Optimizations", 725 draft-ietf-pana-mobopts-00 (work in progress), 726 January 2005. 728 [I-D.ietf-pana-pana] 729 Forsberg, D., "Protocol for Carrying Authentication for 730 Network Access (PANA)", draft-ietf-pana-pana-10 (work in 731 progress), July 2005. 733 [I-D.ietf-pana-ipsec] 734 Parthasarathy, M., "PANA Enabling IPsec based Access 735 Control", draft-ietf-pana-ipsec-07 (work in progress), 736 July 2005. 738 [I-D.ietf-pana-snmp] 739 Mghazli, Y., "SNMP usage for PAA-EP interface", 740 draft-ietf-pana-snmp-04 (work in progress), July 2005. 742 [I-D.ietf-pana-framework] 743 Jayaraman, P., "PANA Framework", 744 draft-ietf-pana-framework-05 (work in progress), 745 July 2005. 747 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 748 "Diameter Network Access Server Application", RFC 4005, 749 August 2005. 751 [I-D.ieft-pana-aaa-interworking] 752 Lior, A. and A. Yegin, "PANA AAA Interworking.", 753 draft-ieft-pana-aaa-interworking-00 (work in progress), 754 July 2005. 756 [I-D.bournelle-pana-ctp] 757 Bournelle, J., "Use of Context Transfer Protocol (CxTP) 758 for PANA", draft-bournelle-pana-ctp-03 (work in progress), 759 June 2005. 761 Authors' Addresses 763 Julien Bournelle 764 GET/INT 765 9 rue Charles Fourier 766 Evry 91011 767 France 769 Email: julien.bournelle@int-evry.fr 771 Maryline Laurent-Maknavicius 772 GET/INT 773 9 rue Charles Fourier 774 Evry 91011 775 France 777 Email: maryline.maknavicius@int-evry.fr 779 Rafa Marin Lopez 780 University of Murcia 781 Murcia 30071 782 Spain 784 Email: rafa@dif.um.es 785 Dan Forsberg 786 Nokia 787 P.O Box 407 788 NOKIA GROUP FIN-0045 789 Finland 791 Email: dan.forsberg@nokia.com 793 Jean-Michel Combes 794 France Telecom R&D 795 38/40 rue du General Leclerc 796 Issy-les-Moulineaux 92794 797 France 799 Email: jeanmichel.combes@francetelecom.com 801 Intellectual Property Statement 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org. 825 The IETF has been notified of intellectual property rights claimed in 826 regard to some or all of the specification contained in this 827 document. For more information consult the online list of claimed 828 rights. 830 Disclaimer of Validity 832 This document and the information contained herein are provided on an 833 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 834 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 835 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 836 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 837 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 838 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 840 Copyright Statement 842 Copyright (C) The Internet Society (2005). This document is subject 843 to the rights, licenses and restrictions contained in BCP 78, and 844 except as set forth therein, the authors retain all their rights. 846 Acknowledgment 848 Funding for the RFC Editor function is currently provided by the 849 Internet Society.