idnits 2.17.1 draft-ietf-pana-framework-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 a Security Considerations section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 282 has weird spacing: '...address o ...' == Line 287 has weird spacing: '...address o ...' -- 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 (May 3, 2004) is 7296 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) == Unused Reference: 'I-D.tschofenig-eap-ikev2' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'DSL' is defined on line 1519, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-14 ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) == Outdated reference: A later version (-17) exists of draft-ietf-ipsec-ikev2-13 == Outdated reference: A later version (-06) exists of draft-ietf-pana-snmp-00 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-pana-snmp' == Outdated reference: A later version (-18) exists of draft-ietf-pana-pana-03 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-02 == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-00 ** Downref: Normative reference to an Informational draft: draft-ietf-eap-netsel-problem (ref. 'I-D.ietf-eap-netsel-problem') ** Obsolete normative reference: RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-07 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-requirements (ref. 'I-D.ietf-pana-requirements') == Outdated reference: A later version (-03) exists of draft-yegin-eap-boot-rfc3118-00 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-05 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-07 == Outdated reference: A later version (-05) exists of draft-ietf-pppext-eap-ttls-04 == Outdated reference: A later version (-15) exists of draft-tschofenig-eap-ikev2-03 Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group P. Jayaraman 3 Internet-Draft Net.Com 4 Expires: November 1, 2004 R. Lopez 5 Univ. of Murcia 6 Y. Ohba (Ed.) 7 Toshiba 8 M. Parthasarathy 9 Nokia 10 A. Yegin 11 Samsung 12 May 3, 2004 14 PANA Framework 15 draft-ietf-pana-framework-00 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 1, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 PANA design provides support for various types of deployments. Access 46 networks can differ based on the availability of lower-layer 47 security, placement of PANA entities, choice of client IP 48 configuration and authentication methods, etc. This I-D defines a 49 general framework for describing how these various deployment choices 50 are handled by PANA and the access network architectures. 51 Additionally, two possible deployments are described in detail: using 52 PANA over DSL networks and WLAN networks. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1 Specification of Requirements . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. General PANA Framework . . . . . . . . . . . . . . . . . . 5 60 4. Environments . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. IP Address Configuration . . . . . . . . . . . . . . . . . 11 62 6. Data Traffic Protection . . . . . . . . . . . . . . . . . 14 63 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . 15 64 7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 15 65 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . . . 16 66 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . . . 16 67 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 18 68 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 18 69 8. Network Selection . . . . . . . . . . . . . . . . . . . . 19 70 9. Authentication Method Choice . . . . . . . . . . . . . . . 21 71 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . 22 72 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . . 22 73 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . . . . 22 74 10.1.2 Address Translation (NAPT) Mode . . . . . . . . . . . . . 23 75 10.1.3 Router Mode . . . . . . . . . . . . . . . . . . . . . . . 23 76 10.1.4 PANA and Dynamic Internet Service Provider Selection . . . 24 77 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . . 25 78 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . . . . 26 79 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . . . . 30 80 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . . . . 34 81 11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . 35 82 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 36 83 Normative References . . . . . . . . . . . . . . . . . . . 37 84 Informative References . . . . . . . . . . . . . . . . . . 39 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 40 86 A. Other Possible Cases for PANA with Bootstrapping IPsec 87 in Wireless LAN . . . . . . . . . . . . . . . . . . . . . 41 88 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 89 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 90 Intellectual Property and Copyright Statements . . . . . . 46 92 1. Introduction 94 PANA design provides support for various types of deployments. Access 95 networks can differ based on the availability of lower-layer 96 security, placement of PANA entities, choice of client IP 97 configuration and authentication methods, etc. 99 PANA can be used in any access network regardless of the underlying 100 security. For example, the network might be physically secured, or 101 secured by means of cryptographic mechanisms after the successful 102 client-network authentication. 104 The PANA client, PANA authentication agent, authentication server, 105 and enforcement point are the relevant functional entities in this 106 design. PANA authentication agent and enforcement point(s) can be 107 placed on various elements in the access network (e.g., access point, 108 access router, dedicated host). 110 IP address configuration mechanisms vary as well. Static 111 configuration, DHCP, stateless address autoconfiguration are possible 112 mechanisms to choose from. If the client configures an IPsec tunnel 113 for enabling per-packet security, configuring IP addresses inside the 114 tunnel becomes relevant, for which there are additional choices such 115 as IKE. 117 This I-D defines a general framework for describing how these various 118 deployment choices are handled by PANA and the access network 119 architectures. Additionally, two possible deployments are described 120 in detail: using PANA over DSL networks and WLAN networks. 122 1.1 Specification of Requirements 124 In this document, several words are used to signify the requirements 125 of the specification. These words are often capitalized. The key 126 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 127 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 128 are to be interpreted as described in [RFC2119]. 130 2. Terminology 132 Pre-PANA address (PRPA) 134 This is the address configured before starting the PANA protocol 135 exchange. 137 Post-PANA address (POPA) 139 This is the address (optionally) configured after a successful 140 authentication. 142 IPsec Tunnel Inner Address (IPsec-TIA) 144 This is the address used as the inner address of an IPsec tunnel 145 mode SA. When IPsec protection is used, depending on the 146 deployment scenario used either a PRPA or POPA becomes the 147 IPsec-TIA. 149 IPsec Tunnel Outer Address (IPsec-TOA) 151 This is the address used as the outer address of an IPsec tunnel 152 mode SA. When IPsec protection is used, a PRPA becomes the 153 IPsec-TOA. 155 3. General PANA Framework 157 PANA protocol is designed to facilitate authentication and 158 authorization of client hosts in access networks. PANA is an EAP 159 [I-D.ietf-eap-rfc2284bis] lower-layer that carries EAP authentication 160 methods encapsulated inside EAP between a client host and an agent in 161 the access network. While PANA enables the authentication process 162 between the two entities, it is only a part of an overall AAA and 163 access control framework. A AAA and access control framework using 164 PANA is comprised of four functional entities. 166 PANA Client (PaC): 168 The client implementation of the PANA protocol. This entity 169 resides on the client host that is requesting access to a local 170 area network. Example client hosts can be laptops, PDAs, cell 171 phones, desktops that are connected to a network via wired or 172 wireless networks. A PaC is responsible for requesting network 173 access and engaging in authentication process using the PANA 174 protocol. 176 PANA Authentication Agent (PAA): 178 The server implementation of the PANA protocol. A PAA is in 179 charge of interfacing with the PaCs for authenticating and 180 authorizing them for the network access service. 182 The PAA consults an authentication server in order to verify the 183 credentials and rights of a PaC. If the authentication server 184 resides on the same host as the PAA, an API is sufficient for this 185 interaction. When they are separated (a much more common case in 186 public access networks), a protocol needs to run between the two. 187 LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and 188 Diameter [RFC3588] are commonly used for this purpose. 190 The PAA is also responsible for updating the access control state 191 (i.e., filters) depending on the creation and deletion of the 192 authorization state. The PAA communicates the updated state to 193 the enforcement points in the network. If the PAA and EP are 194 residing on the same host, an API is sufficient for this 195 communication. Otherwise, a protocol is required to carry the 196 authorized client attributes from the PAA to the EP. While not 197 prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] 198 is suggested for this task. 200 The PAA resides on a node that is typically called a NAS (network 201 access server) in the local area network. PAA can be hosted on any 202 IP-enabled node on the same IP subnet as the PaC. For example on 203 a BAS (broadband access server) in DSL networks, or PDSN in 3GPP2 204 networks. 206 Authentication Server (AS): 208 The server implementation that is in charge of verifying the 209 credentials of a PaC that is requesting the network access 210 service. The AS receives requests from the PAA on behalf of the 211 PaCs, and responds with the result of verification together with 212 the authorization parameters (e.g., allowed bandwidth, IP 213 configuration, etc). The AS might be hosted on the same host as 214 the PAA, on a dedicated host on the access network, or on a 215 central server somewhere on the Internet. 217 Enforcement Point (EP): 219 The access control implementation that is in charge of allowing 220 access to authorized clients while preventing access by others. 221 An EP learns the attributes of the authorized clients from the 222 PAA. 224 The EP uses simple or cryptographic filters to selectively allow 225 and discard data packets. These filters may be applied at the 226 link-layer or the IP-layer. When cryptographic access control is 227 used, a secure association protocol needs to run between the PaC 228 and EP. This protocol provides the cryptographic binding between 229 the communication channel and the authorization state. Examples of 230 secure association protocols include the 4-way handshake in IEEE 231 802.11i [802.11i], and IKE in IP-based access control. Link-layer 232 ciphering or IPsec [I-D.ietf-pana-ipsec] is used following the 233 secure association to enable per-packet integrity, authentication 234 and replay protection (and optionally confidentiality). 236 An EP must be located strategically in a local area network to 237 minimize the access of unauthorized clients to the network. For 238 example, the EP can be hosted on the switch that is directly 239 connected to the clients in a wired network. That way the EP can 240 drop unauthorized packets before they reach any other client host 241 or beyond the local area network. 243 Figure 1 illustrates these functional entities and the interfaces 244 (protocols, APIs) among them. 246 RADIUS/ 247 Diameter/ 248 +-----+ PANA +-----+ LDAP/ API +-----+ 249 | PaC |<----------------->| PAA |<---------------->| AS | 250 +-----+ +-----+ +-----+ 251 ^ ^ 252 | | 253 | +-----+ | 254 IKE/ +-------->| EP |<--------+ SNMP/ API 255 4-way handshake +-----+ 257 Figure 1: PANA Functional Model 259 Some of the entities may be co-located depending on the deployment 260 scenario. For example, the PAA and EP would be on the same node 261 (BAS) in DSL networks. In that case a simple API is sufficient 262 between the PAA and EP. In small enterprise deployments the PAA and 263 AS may be hosted on the same node (access router) that eliminates the 264 need for a protocol run between the two. The decision to co-locate 265 these entities or otherwise, and their precise location in the 266 network topology are deployment decisions. 268 Use of IKE or 4-way handshake protocols for secure association is 269 only required in the absence of any lower-layer security prior to 270 running PANA. Physically secured networks (e.g., DSL) or the 271 networks that are already cryptographically secured on the link-layer 272 prior to PANA run (e.g., cdma2000) do not require additional secure 273 association and per-packet ciphering. These networks can bind the 274 PANA authentication and authorization to the lower-layer secure 275 channel that is already available. 277 Figure 2 illustrates the signaling flow for authorizing a client for 278 network access. 280 PaC EP PAA AS 281 | | | | 282 IP address o | | | 283 config. | PANA | | AAA | 284 |<------------------------------>|<-------------->| 285 | | SNMP | | 286 (Optional) | |<-------------->| | 287 IP address o | | | 288 config. | Sec.Assoc. | | | 289 |<------------->| | | 290 | | | | 291 | Data traffic | | | 292 |<-----------------> | | 293 | | | | 294 Figure 2: PANA Signaling Flow 296 The EP on the access network allows general data traffic from any 297 authorized PaC, whereas it allows only limited type of traffic (e.g., 298 PANA, DHCP, router discovery) for the unauthorized PaCs. This 299 ensures that the newly attached clients have the minimum access 300 service to engage in PANA and get authorized for the unlimited 301 service. 303 The PaC MUST configure an IP address prior to running PANA. After the 304 successful PANA authentication, depending on the deployment scenario 305 PaC MAY need to re-configure its IP address or configure additional 306 IP address(es). The additional address configuration MAY be executed 307 as part of the secure association protocol run. 309 An initially unauthorized PaC starts the PANA authentication by 310 discovering the PAA on the access network, followed by the EAP 311 exchange over PANA. The PAA interfaces with the AS during this 312 process. Upon receiving the authentication and authorization result 313 from the AS, the PAA informs the PaC about the result of its network 314 access request. 316 If the PaC is authorized to gain the access to the network, the PAA 317 also sends the PaC-specific attributes (e.g., IP address, 318 cryptographic keys, etc.) to the EP by using SNMP. The EP uses this 319 information to alter its filters for allowing data traffic from and 320 to the PaC to pass through. 322 In case a cryptographic access control needs to be enabled after the 323 PANA authentication, a secure association protocol runs between the 324 PaC and the EP. The PaC should already have the input parameters to 325 this process as a result of the successful PANA exchange. Similarly, 326 the EP should have obtained them from the PAA via SNMP. Secure 327 association exchange produces the required security associations 328 between the PaC and the EP to enable per-packet protection. 330 Finally data traffic can start flowing from and to the newly 331 authorized PaC. 333 4. Environments 335 The PANA protocol can be used on any network environment whether 336 there is a lower-layer secure channel prior to PANA, or one has to be 337 enabled upon successful PANA authentication. The secure channel 338 enabled by PANA may rely on link-layer ciphering or IP-layer 339 ciphering. 341 Two types of networks are: 343 a. Networks where a secure channel is already available prior to 344 running PANA 346 These are the networks where the lower-layer is already providing 347 protection against spoofing and eavesdropping (nevertheless the 348 client is still required to get authenticated and authorized for 349 the network access service). 351 One example is the DSL networks where the lower-layer security is 352 provided by physical means (a.1). Physical protection of the 353 network wiring ensures that practically there is only one client 354 that can send and receive IP packets on the link. Another example 355 is the cdma2000 networks where the lower-layer security is 356 provided by means of cryptographic protection (a.2). By the time 357 the client requests access to the network-layer services, it is 358 already authenticated and authorized for accessing the radio 359 channel, and link-layer ciphering is enabled. 361 The presence of a secure channel before PANA exchange eliminates 362 the need for executing a secure association protocol after PANA. 363 The PANA session can be bound to the communication channel it was 364 carried over. Also, the choice of EAP authentication method 365 depends on the presence of this security during PANA run. Use of 366 some authentication methods outside a secure channel is not 367 recommended (e.g., EAP-MD5). 369 b. Networks where a secure channel is created after running PANA 371 These are the networks where there is no lower-layer protection 372 prior to running PANA. A successful PANA authentication enables 373 generation of cryptographic keys that are used with a secure 374 association protocol to enable per-packet protection. 376 PANA authentication is run on an insecure channel that is 377 vulnerable to eavesdropping and spoofing. The choice of EAP 378 method must be resilient to the possible attacks associated with 379 such an environment. Furthermore, the EAP method must be able to 380 create cryptographic keys that will later be used by the secure 381 association protocol. 383 Whether to use a link-layer per-packet security (b.1) or an 384 IP-layer one (b.2) is a deployment decision. This decision also 385 dictates the choice of the secure association protocol. If 386 link-layer protection is used, the protocol would be link 387 technology specific. If IP-layer protection is used, the secure 388 association protocol would be IKE and the per-packet security 389 would be provided by IPsec regardless of the link type. 391 5. IP Address Configuration 393 PaC configures an IP address before the PANA protocol exchange 394 begins. This address is called a pre-PANA address (PRPA). After a 395 successful authentication, the client may have to configure a 396 post-PANA address (POPA) for communication with other nodes, if PRPA 397 is a local-use (e.g., link-local or private address) or a temporarily 398 allocated IP address. An operator might choose allocating a POPA 399 only after successful PANA authorization either to prevent waste of 400 premium IP resources until the client is authorized, or to enable 401 client identity based address assignment. 403 In case PaC is a IPv4-IPv6 dual-stack host, it may configure more 404 than one PRPA, at least one for each protocol. Nevertheless, the PaC 405 needs only one to run PANA which is executed once regardless of the 406 type and number of IP stacks. After successful PANA authentication, 407 similarly PaC may configure multiple POPAs. 409 There are different methods by which a PRPA can be configured. 411 1. In some deployments (e.g., DSL networks) the PaC may be statically 412 configured with an IP address. This address SHOULD be used as 413 PRPA. 415 2. In IPv4, most clients attempt to configure an address dynamically 416 using DHCP [RFC2131]. If they are unable to configure an address 417 using DHCP, they can configure a link-local address using 418 [I-D.ietf-zeroconf-ipv4-linklocal]. 420 When the network access provider is able to run a DHCP server on 421 the access link, the client would configure the PRPA using DHCP. 422 This address may be from a private address pool [RFC1918]. Also, 423 the lease time on the address may vary. For example, a PRPA 424 configured solely for running PANA can have a short lease time. 425 PRPA may be used for local-use only (i.e., only for on-link 426 communication, such as for PANA and IPsec tunneling with EP), or 427 also for ultimate data communication. 429 In case there is no running DHCP server on the link, the client 430 would fall back to configuring a PRPA via zeroconfiguration 431 technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a 432 long-term address that can only be used for on-link communication. 434 3. In IPv6, clients configure a link-local address [RFC2462] when 435 they initialize an interface. This address SHOULD be used as 436 PRPA. 438 When a PRPA is configured, the client starts the PANA protocol 439 exchange. By that time, a dual-stack client might have configured 440 both an IPv4 address, and one or more IPv6 addresses as PRPAs. When 441 the client successfully authenticates to the network, it may be 442 required to configure POPAs for its subsequent data communication 443 with the other nodes. 445 If the client is already configured with a non-temporary address that 446 can be used with data communication, it is not required to configure 447 a POPA. Otherwise, PAA would indicate PaC the available POPA 448 configuration methods through the PANA-Bind-Request message. PaC can 449 choose one of the methods and execute accordingly. 451 1. If the network relies on physical or link-layer security, PaC can 452 configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6 453 stateless auto-configuration [RFC2461]. If IPv4 is being used, 454 PRPA is likely to be a link-local or private address, or an 455 address with a short DHCP lease. An IPv4 PRPA SHOULD be 456 unconfigured when the POPA is configured to prevent IPv4 address 457 selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is 458 used, the link-local PRPA address SHOULD NOT be unconfigured 459 [RFC3484]. 461 If the PaC is a dual-stack host, it can configure both IPv4 and 462 IPv6 type POPAs. 464 PRPA and the IP address of PAA are assumed to be on the same IP 465 subnet, hence the PaC and PAA can perform on-link communication as 466 required by PANA. When the PaC replaces its IPv4 PRPA with POPA, 467 this assumption may not hold true. In order to maintain the same 468 on-link communication, the PaC and PAA SHOULD create host routes 469 to each other upon PaC's IP address change. The PaC SHOULD create 470 a host route to the PAA, and the PAA SHOULD create a host route to 471 the PaC (POPA). 473 2. If the network uses IPsec for protecting the traffic on the link 474 subsequent to PANA authentication [I-D.ietf-pana-ipsec], PaC would 475 use the PRPA as the outer address of IPsec tunnel mode SA 476 (IPsec-TOA). PaC also needs to configure an inner address 477 (IPsec-TIA). There are different ways to configure IPsec-TIA 478 which are indicated in Pana-Bind-Request message. 480 When an IPv4 PRPA is configured, the same address may be used as 481 both IPsec-TOA and IPsec-TIA. In this case, a POPA is not 482 configured. Alternatively, an IPsec-TIA can be obtained via the 483 configuration method available within [RFC3456] for IPv4, and 484 [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly 485 configured address constitutes a POPA. Please refer to 486 [I-D.ietf-pana-ipsec] for more details. 488 IKEv2 can enable configuration of both IPv4 and IPv6 TIAs for the 489 same IPsec tunnel mode SA. Therefore, IKEv2 is recommended for 490 handling dual-stack PaCs where single execution of PANA and IKE is 491 desired. 493 Although there are potentially a number of different ways to 494 configure a PRPA, and POPA when necessary, it should be noted that 495 the ultimate decision to use one or more of these in a deployment 496 depends on the operator. The decision is dictated by the operator's 497 choice of per-packet protection capability (physical and link-layer 498 vs network-layer), PRPA type (local and temporary vs global and 499 long-term), and POPA configuration mechanisms available in the 500 network. 502 6. Data Traffic Protection 504 Protecting data traffic of authenticated and authorized client from 505 others is another component of providing a complete secure network 506 access solution. Authentication, integrity and replay protection of 507 data packets are needed to prevent spoofing when the underlying 508 network is not physically secured. Encryption is needed when 509 eavesdropping is a concern in the network. 511 When the network is physically secured, or the link-layer ciphering 512 is already enabled prior to PANA, data traffic protection is already 513 in place. In other cases, enabling link-layer ciphering or 514 network-layer ciphering might rely on PANA authentication. The user 515 and network have to make sure an appropriate EAP method that can 516 generate required keying materials is used. Once the keying material 517 is available, it needs to be provided to the EP(s) for use with 518 ciphering. 520 Network-layer ciphering, i.e., IPsec, can be used when data traffic 521 protection is required but link-layer ciphering capability is not 522 available. Note that a simple shared secret generated by an EAP 523 method is not readily usable by IPsec for authentication and 524 encryption of IP packets. Fresh and unique session key derived from 525 the EAP method is still insufficient to produce an IPsec SA since 526 both traffic selectors and other IPsec SA parameters are missing. 527 The shared secret can be used in conjunction with a key management 528 protocol like IKE [RFC2409] to turn a simple shared secret into the 529 required IPsec SA. The details of such a mechanism is outside the 530 scope of PANA protocol and is specified in [I-D.ietf-pana-ipsec]. 531 PANA provides bootstrapping functionality for such a mechanism by 532 carrying EAP methods that can generate initial keying material. 534 Using network-layer ciphers should be regarded as a substitute for 535 link-layer ciphers when the latter is not available. Network-layer 536 ciphering can also be used in addition to link-layer ciphering if the 537 added benefits outweigh its cost to the user and the network. In 538 this case, PANA bootstraps only the network-layer ciphering and 539 link-layer is protected using any of the existing link-layer specific 540 methods. 542 7. PAA-EP Protocol 544 The PANA protocol provides client authentication and authorization 545 functionality for securing network access. The other component of a 546 complete solution is the access control which ensures that only 547 authenticated and authorized clients can gain access to the network. 548 PANA enables access control by identifying legitimate clients and 549 generating filtering information for access control mechanisms. 551 Access control can be achieved by placing EPs (Enforcement Points) in 552 the network for policing the traffic flow. EPs should prevent data 553 traffic from and to any unauthorized client unless it's either PANA 554 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor 555 discovery, DHCP, etc.). 557 When a client is authenticated and authorized, PAA should notify 558 EP(s) and ask for changing filtering rules to allow traffic for a 559 recently authorized client. There needs to be a protocol between PAA 560 and EP(s) when these entities are not co-located. PANA Working Group 561 will not be defining a new protocol for this interaction. Instead, 562 it identifies one of the existing protocols that can fit the 563 requirements. An assessment was made in the PANA Working Group and 564 SNMPv3 has been chosen as the mandatory PAA-EP protocol. 566 This section describes the possible models on the location of PAA and 567 EP, as well as the basic authorization information that needs to be 568 exchanged between PAA and EP. When PAA and EP are not co-located in 569 a single device, there are other issues such as dead or rebooted peer 570 detection and consideration for specific authorization and accounting 571 models. However, these issues are closely related to the PAA-EP 572 protocol solution and thus not discussed in this document. See 573 [I-D.ietf-pana-snmp] for further discussion. 575 7.1 PAA and EP Locations 577 EPs' location in the network topology should be appropriate for 578 performing access control functionality. The closest IP-capable 579 access device to the client devices is the logical choice. PAA and 580 EPs on an access network should be aware of each other as this is 581 necessary for access control. Generally this can be achieved by 582 manual configuration. Dynamic discovery is another possibility, but 583 this is left to implementations and outside the scope of this 584 document. 586 Since PANA allows the separation of EP and PAA, there are several 587 models depending on the number of EPs and PAAs and their locations. 588 This section describes all possible models on the placement of PAA(s) 589 and EP(s). 591 7.1.1 Single PAA, Single EP, Co-located 593 This model corresponds to the legacy NAS model. Since the PAA and 594 the EP are co-located, the PAA-EP communication can be implemented 595 locally by using, e.g., IPC (Inter-Process Communication). The only 596 difference from the legacy NAS model is the case where there are 597 multiple co-located PAA/EP devices on the same IP link and the PAA/EP 598 devices are L2 switches or access points. In this case, for a PaC 599 that attaches to a given PAA/EP device, other PAA/EP devices should 600 not be visible to the PaC even if those devices are on the same IP 601 link. Otherwise, the PaC may result in finding a PAA that is not the 602 closest one to it during the PANA discovery and initial handshake 603 phase and performing PANA with the wrong PAA. To prevent this, each 604 PAA/EP device on an L2 switch or access point should not forward 605 multicast PANA discovery message sent by PaCs attached to it to other 606 devices. 608 7.1.2 Separate PAA and EP 610 When PAA is separated from EP, two cases are possible with regard to 611 whether PAA and EP are located in parallel or serial when viewed from 612 PaC, for each of models described in this section. 614 In the first case, PAA is located behind EP. The EP should be 615 configured to always pass through PANA messages and address 616 configuration protocol messages used for configuring an IP address 617 used for initial PANA messaging. This case can typically happen when 618 the EP is an L2 switch or an access point (the EP also has an IP 619 stack to communicate with PAA via a PAA-EP protocol). 621 +---+ +---+ +---+ 622 |PaC|--------|EP |--------|PAA| 623 +---+ +---+\ +---+ 624 \ 625 +---- Internet 627 Figure 3: PAA and EP in Serial 629 In the other case, PAA is located in parallel to EP. Since the EP is 630 not on the communication path between PaC and PAA, the EP does not 631 have to configure to pass through PANA messages or address 632 configuration protocol messages in this case. This case can 633 typically happen when the EP is a router and the PAA is an 634 authentication gateway without IP routing functionality. 636 +---+ 637 +-----|PAA| 638 / +---+ 639 +---+/ 640 |PaC| 641 +---+\ 642 \ +---+ 643 +-----|EP |---- Internet 644 +---+ 646 Figure 4: PAA and EP in Parallel 648 In the remaining of this section, PaC is not shown in figures and the 649 figures cover both the serial and parallel models. 651 7.1.2.1 Single PAA, Single EP, Separated 653 The model benefits from separation of data traffic handling and AAA. 654 The EP does not need to have a AAA protocol implementation which 655 might be updated relatively more frequently than the per-packet 656 access enforcement implementation. 658 7.1.2.2 Single PAA, Multiple EPs 660 In this model, a single PAA controls multiple EPs. The PAA may be 661 separated from any EP or co-located with a particular EP. This model 662 might be useful where it is preferable to run a AAA protocol at a 663 single, manageable point. This model is particularly useful in an 664 access network that consists of a large number of access points on 665 which per-packet access enforcement is made. When a PaC is 666 authenticated to the PAA, the PAA should install access control 667 filters to each of the EPs under control of the PAA if the PAA cannot 668 tell which EP the PaC is attached to. Even if the PAA can tell which 669 EP the PaC is attached to, the PAA may install access control filters 670 to those EPs if the PaC is a mobile device that can roam among the 671 EPs. Such pre-installation of filters can reduce handoff latency. 672 If different access authorization policies are applied to different 673 EPs, different filter rules for a PaC may be installed on different 674 EPs. 676 +---+ 677 |EP |--+ 678 +---+ \ 679 \ 680 +---+ +---+ 681 |EP |----|PAA| 682 +---+ +---+ 683 / 684 +---+ / 685 |EP |--+ 686 +---+ 688 Figure 5: An example model for a single PAA and multiple EPs 690 7.1.2.3 Multiple PAAs 692 The PANA protocol allows multiple PAAs to exist on the same IP link 693 and to be visible to PaCs on the link. PAAs may or may not be 694 co-located with EPs as long as authorization results do not depend on 695 whichever PAAs are chosen by a PaC [I-D.ietf-pana-pana]. 697 7.2 Notification of PaC Presence 699 When PAA and EP are separated and PAA is configured to be the 700 initiator of the discovery and initial handshake phase of PANA, EP 701 has the responsibility to detect presence of a new PaC and notifies 702 the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a 703 presence notification is carried in a PAA-EP protocol message 704 [I-D.ietf-pana-snmp]. 706 7.3 Filter Rule Installation 708 Filtering rules to be installed on EP generally include a device 709 identifier of PaC, and also cryptographic keying material (such as 710 keys, key pairs, and initialization values) when needed. The keying 711 material is needed when attackers can eavesdrop and spoof on the 712 device identifiers easily. Each keying material is uniquely 713 identified with a keying material name and has a lifetime for key 714 management purpose. The keying material is used with link-layer or 715 network-layer ciphering to provide additional protection. For issues 716 regarding data-origin authentication see Section 6. In addition to 717 the device identifier and keying material, other filter rules, such 718 as the IP filter rules specified in NAS-Filter-Rule AVPs carried in 719 Diameter EAP application [I-D.ietf-aaa-eap] may be installed on EP. 721 8. Network Selection 723 The network selection problem statement is made in 724 [I-D.ietf-eap-netsel-problem]. The PANA protocol 725 [I-D.ietf-pana-pana] provides a way for networks to advertise which 726 ISPs are available and for PaC to choose one ISP from the advertised 727 information. When a PaC chooses an ISP in the PANA protocol 728 exchange, the ultimate destination of the AAA exchange is determined 729 based on the identity of the chosen service provider. It is also 730 possible that the PaC does not choose a specific ISP in the PANA 731 protocol exchange. In this case, both the ISP choice and the AAA 732 destination are determined based on the PaC's identity, where the 733 identity may be an NAI [RFC2486] or the physical port number or L2 734 address of the subscriber. 736 As described in [I-D.ietf-eap-netsel-problem], network selection is 737 not only related to AAA routing but also related to payload routing. 738 Once an ISP is chosen and the PaC is successfully authenticated and 739 authorized, PaC is assigned an address by the ISP whose IP prefix may 740 be different from that of the AR. This affects the routing of the 741 subsequent data traffic between AR and PaC. A suggested solution is 742 to add host route from AR to PaC's POPA address and host route from 743 PaC to AR. 745 Consider a typical DSL network where the AR, EP, and PAA are 746 co-located on a BAS (Broadband Access Server) in the access network 747 operated by a NAP (Network Access Provider). Figure 6 shows a 748 typical model for ISP selection. 750 <---- NAP ----><--------- ISP ---------> 752 +---ISP1 753 / 754 +---+ +---------+/ 755 |PaC|----|AR/EP/PAA| 756 +---+ +---------+\ 757 BAS \ 758 +---ISP2 760 Figure 6: A Network Selection Model 762 When network selection is made at L3 with the use of the PANA 763 protocol instead of L2-specific authentication mechanisms, the IP 764 link between PaC and PAA needs to exist prior to doing PANA (and 765 prior to network selection). In this model, the PRPA is either given 766 by NAP or a link-local address is auto-configured. After the 767 successful authentication with the ISP, PaC may acquire an address 768 (POPA) from the ISP. It also learns the address of the AR, e.g., 769 through DHCP, to be used as its default router. The address of the 770 AR may or may not be in the same IP subnet as that of the PaC's POPA. 771 If they don't share the same prefix, they SHOULD use host routes to 772 reach each other. Note that the physically secured DSL networks do 773 not require IPsec-based access control. Therefore the PaCs use one IP 774 address at a time where POPA replaces PRPA upon configuration. 776 9. Authentication Method Choice 778 Authentication methods' capabilities and therefore applicability to 779 various environments differ among them. Not all methods provide 780 support for mutual authentication, key derivation or distribution, 781 and DoS attack resiliency that are necessary for operating in 782 insecure networks. Such networks might be susceptible to 783 eavesdropping and spoofing, therefore a stronger authentication 784 method needs to be used to prevent attacks on the client and the 785 network. 787 The authentication method choice is a function of the underlying 788 security of the network (e.g., physically secured, shared link, 789 etc.). It is the responsibility of the user and the network operator 790 to pick the right method for authentication. PANA carries EAP 791 regardless of the EAP method used. It is outside the scope of PANA to 792 mandate, recommend, or limit use of any authentication methods. PANA 793 cannot increase the strength of a weak authentication method to make 794 it suitable for an insecure environment. There are some EAP-based 795 approaches to achieve this goal (see 796 [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls] 797 ,[I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating 798 methods but it does not concern itself with how they achieve 799 protection for the weak methods (i.e., their EAP method payloads). 801 10. Example Cases 803 10.1 DSL Access Network 805 In a DSL access network, PANA is seen applicable in the following 806 scenarios. 808 A typical DSL access consists of a NAS device at the DSL-access 809 provider and a DSL-modem (CPE) at the customer premises. The CPE 810 devices support multiple modes of operation and PANA is applicable in 811 each of these modes. 813 Host--+ +-------- ISP1 814 | DSL link | 815 +----- CPE ---------------- NAS ----+-------- ISP2 816 | (Bridge/NAPT/Router) | 817 Host--+ +-------- ISP3 819 <------- customer --> <------- NAP -----> <---- ISP ---> 820 premise 822 Figure 7: DSL Model 824 The devices at the customer premises have been shown as "hosts" in 825 the above network. 827 DSL networks are protected by physical means. Eavesdropping and 828 spoofing attacks are prevented by keeping the unintended users 829 physically away from the network media. Therefore, generally 830 cryptographic protection of data traffic is not necessary. 831 Nevertheless, if enhanced security is deemed necessary for any 832 reason, IPsec-based access control can be enabled on DSL networks as 833 well by using the method described in [I-D.ietf-pana-ipsec]. 835 10.1.1 Bridging Mode 837 In the bridging mode, the CPE acts as a simple layer-2 bridge. The 838 hosts at the customer premises will function as clients to obtain 839 addresses from the NAS device by using DHCP or PPPoE. 841 If PPPoE is used, authentication is typically performed using CHAP or 842 MS-CHAP. 844 PANA will be applicable when the hosts use DHCP to obtain IP address. 845 DHCP does not support authentication of the devices on either side of 846 the DSL access line. In the simplest method of address assignment, 847 the NAS will allocate the IP address to a host with a lease time 848 reasonably sufficient to complete a full PANA based authentication 849 which will be triggered immediately after the address assignment. The 850 hosts will perform the PaC function and the NAS will perform the PAA, 851 EP and AR functions. 853 Host--+ 854 (PaC) | 855 +----- CPE ---------------- NAS ------------- ISP 856 | (Bridge) (PAA,EP,AR) 857 Host--+ 858 (PaC) 860 Figure 8: Bridge Mode 862 The DSL service provider's trunk network should not be accessible to 863 any host that has not successfully completed the PANA authentication 864 phase. 866 10.1.2 Address Translation (NAPT) Mode 868 In the NAPT mode, the CPE is configured with the authentication 869 parameters (i.e. username, password). In this case, the CPE acts as a 870 "client" of the NAS. If the CPE uses DHCP to obtain the IP address, 871 PANA will be necessary to authenticate the CPE and the NAS to each 872 other. 874 Host--+ 875 | 876 +----- CPE ---------------- NAS ------------- ISP 877 | (NAPT, PaC) (PAA,EP,AR) 878 Host--+ 880 Figure 9: NAPT Mode 882 The CPE in this case typically acts as a DHCP server for the devices 883 at the customer premises network. It applies NAPT mechanisms to 884 forward traffic between the customer premises network and the NAS. 886 If the CPE is configured with a static IP address and does not 887 perform DHCP, it will need to initiate a PANA authentication phase 888 before gaining access to the service provider's network. 890 10.1.3 Router Mode 892 In this case, the CPE acts as a full-fledged router for the customer 893 premises network. The CPE itself may obtain the IP address using 894 DHCP or be configured with static IP address. Once the CPE is 895 authenticated using PANA and is provided access to the service 896 provider's network, the NAS should begin exchanging routing updates 897 with the CPE. All devices at the customer premises will then have 898 access to the service provider's network. 900 Host--+ 901 | 902 +----- CPE ---------------- NAS ------------- ISP 903 | (Router, PaC) (PAA,EP,AR) 904 Host--+ 906 Figure 10: Router Mode 908 As in the NAPT mode, it is possible that both ends of the DSL link 909 are configured with static IP addresses. PANA-based mutual 910 authentication of CPE and NAS is desirable before data-traffic is 911 exchanged between the customer premises network and the service 912 provider network. 914 10.1.4 PANA and Dynamic Internet Service Provider Selection 916 In some installations, a NAS device is shared by multiple service 917 providers. Each service provider configures the NAS with a certain IP 918 address space. 920 The devices at the customer premises network indicate their choice of 921 service provider and the NAS chooses the IP address from the 922 appropriate service provider's pool. In many cases, the address is 923 assigned not by the NAS but by the AAA server that is managed fully 924 by the service provider. 926 This simplifies the management of the DSL access network as it is not 927 always necessary to configure each DSL access line with the service 928 provider's identity. The service provider is chosen dynamically by 929 the CPE device. This is typically known as "dynamic Internet Service 930 Provider selection". The AAA function is usually overloaded to 931 perform dynamic ISP selection. 933 If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP 934 is chosen by mapping the username field of a CHAP response to a 935 provider. 937 If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or 938 DHCP-request packet is mapped to the provider. 940 10.1.4.1 Selection as Part of the DHCP protocol or an Attribute of DSL 941 Access Line 943 The ISP selection, therefore the IP address pool, can be conveyed 944 based on the DHCP protocol exchange (as explained earlier), or by 945 associating the DSL access line to the service provider before the 946 PANA authentication begins. When any of these schemes is used, the 947 IP address used during PANA authentication (PRPA) is the ultimate IP 948 address and it does not have to be changed upon successful 949 authorization. 951 10.1.4.2 Selection as Part of the PANA Authentication 953 The ISP selection of the client can be explicitly conveyed during the 954 PANA authentication. In that case, the client can be assigned a 955 temporary IP address (PRPA) prior to PANA authentication. This IP 956 address might be obtained via DHCP with a lease reasonably long to 957 complete PANA authentication, or via the zeroconf technique 958 [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA 959 authentication signalling prompts the client to obtain a new (long 960 term) IP address via DHCP. This new IP address (POPA) replaces the 961 previously allocated temporary IP address. 963 10.2 Wireless LAN Example 965 This section describes how PANA can be used on WLAN networks. In 966 most common WLAN deployments the IP addresses are dynamically 967 configured. Therefore this section does not cover the scenarios 968 where the IP address is statically configured. There are two models 969 depending on which layer security is bootstrapped from PANA 970 authentication, L2 or L3. When PANA authentication is used for 971 bootstrapping L3 security, L2 security is not necessarily to exist 972 even after PANA authentication. Instead, IPsec-based data traffic 973 protection is bootstrapped from PANA. The PAA can indicate the PaC 974 as to whether L2 or L3 protection is needed, by including a 975 Protection-Capability AVP in PANA-Bind-Request message. In both 976 cases, the most common deployment would be illustrated in Figure 11, 977 where EP is typically co-located with AP (access point) when PANA is 978 used for bootstrapping L2 security or with AR when PANA is used for 979 bootstrapping L3 security. 981 +-----+ 982 |AP/EP|----+ 983 +-----+ | 984 | 985 +---+ +-----+ | +---------+ 986 |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet 987 +---+ +-----+ | +---------+ 988 | 989 +-----+ | 990 |AP/EP|----+ 991 +-----+ 993 Figure 11: PANA Wireless LAN Model 995 10.2.1 PANA with Bootstrapping IPsec 997 In this model, data traffic is protected by using IPsec tunnel mode 998 SA and an IP address is used as the device identifier of PaC (see 999 Section 5 for details). Some or all of AP, DHCPv4 Server (including 1000 PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA 1001 and EP may be co-located in a single device. EP is always co-located 1002 with AR and may be co-located with PAA. When EP and PAA are not 1003 co-located, PAA-EP protocol is used for communication between PAA and 1004 EP. 1006 Note that for all of the cases described in this section, PBR 1007 (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA 1008 [I-D.ietf-pana-pana] should occur after installing the authorization 1009 parameter to AR, so that IKE can be performed immediately after PANA 1010 is successfully completed. 1012 10.2.1.1 IPv4 1014 Case A: IPsec-TIA obtained by using DHCPv4 1016 In this case, the IPsec-TIA and IPsec-TOA are the same as the 1017 PRPA, and all configuration information including the IP address 1018 is obtained by using DHCPv4 [RFC2131]. No POPA is configured. 1019 Case A is the simplest compared to other ones and might be used in 1020 a network where IP address depletion attack on DHCP is not a 1021 significant concern. The PRPA needs to be a routable address 1022 unless NAT is performed on AR. 1024 PaC AP DHCPv4 Server PAA EP(AR) 1025 | Link-layer | | | | 1026 | association| | | | 1027 |<---------->| | | | 1028 | | | | | 1029 | DHCPv4 | | | 1030 |<-----------+------------>| | | 1031 | | | | | 1032 |PANA(Discovery and Initial Handshake phase | 1033 | & PAR-PAN exchange in Authentication phase) | 1034 |<-----------+-------------------------->| | 1035 | | | | | 1036 | | | |Authorization| 1037 | | | |[IKE-PSK, | 1038 | | | | PaC-DI, | 1039 | | | | Session-Id] | 1040 | | | |------------>| 1041 | | | | | 1042 |PANA(PBR-PBA exchange in Authentication phase) | 1043 |<-----------+-------------------------->| | 1044 | | | | | 1045 | | IKE | | 1046 |<-----------+---------------------------------------->| 1047 | | | | | 1048 | | | | | 1050 Figure 12: An example case for configuring IPsec-TIA by using 1051 DHCPv4 1053 Case B: IPsec-TIA obtained by using IKE 1055 In this case, the PRPA is obtained by using DHCPv4 and used as 1056 IPsec-TOA. The POPA is obtained by using IKE (via a Configuration 1057 Payload exchange or equivalent) and used as IPsec-TIA. 1059 Case C: IPsec-TIA obtained by using RFC3456 1061 Like Case B, the PRPA is obtained by using DHCPv4. The difference 1062 is that the POPA (eventually used as IPsec-TIA) and other 1063 configuration parameter are configured by running DHCPv4 over a 1064 special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4 1065 Server and IPsec-TIA DHCPv4 Server may be co-located on the same 1066 node. 1068 Note: this case may be used only when IKEv1 is used as the IPsec 1069 key management protocol (IKEv2 does not seem to support RFC3456 1070 equivalent case). 1072 PaC AP DHCPv4 Server PAA EP(AR) 1073 | Link-layer | | | | 1074 | association| | | | 1075 |<---------->| | | | 1076 | | | | | 1077 | DHCPv4 | | | 1078 |<-----------+------------>| | | 1079 | | | | | 1080 |PANA(Discovery and initial handshake phase | 1081 | & PAR-PAN exchange in authentication phase) | 1082 |<-----------+-------------------------->| | 1083 | | | | 1084 | | |Authorization| 1085 | | |[IKE-PSK, | 1086 | | | PaC-DI, | 1087 | | | Session-Id] | 1088 | | |------------>| 1089 | | | | 1090 |PANA(PBR-PBA exchange in authentication phase) | 1091 |<-----------+-------------------------->| | 1092 | | | | 1093 | | IKE | | 1094 | (with Configuration Payload exchange or equivalent) | 1095 |<-----------+---------------------------------------->| 1096 | | | | 1097 | | | | 1099 Figure 13: An example case for IPsec-TIA obtained by using IKE 1100 PRPA 1101 PaC AP DHCPv4 Server PAA 1102 | Link-layer | | | 1103 | association| | | 1104 |<---------->| | | 1105 | | | | 1106 | DHCPv4 | | 1107 |<-----------+-------->| | 1108 | | | 1109 |PANA(Discovery and initial handshake phase 1110 | & PAR-PAN exchange in authentication phase) 1111 |<-----------+-------------------------->| 1112 | | | 1113 | | EP(AR) | 1114 | | |Authorization| 1115 | | |[IKE-PSK, | 1116 | | | PaC-DI, | 1117 | | | Session-Id] | 1118 | | |<------------| 1119 | | | | 1120 |PANA(PBR-PBA exchange in authentication phase) 1121 |<-----------+-------------------------->| 1122 | | | 1123 | IKEv1 phase I & II | 1124 | (to create DHCP SA) | 1125 |<-----------+------------>| 1126 | | | 1127 | DHCP over DHCP SA | 1128 |<-----------+------------>| 1129 | | | 1130 | IKEv1 phase II | 1131 | (to create IPsec SA for data traffic) 1132 |<-----------+------------>| 1134 Figure 14: An example case for configuring IPsec-TIA by using 1135 RFC3456 1137 10.2.1.2 IPv6 1139 In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local 1140 address. IPsec-TIA (POPA) is obtained by using Configuration Payload 1141 exchange of IKE version 2 (Note that there is no standard method for 1142 configuring IPsec-TIA in IKEv1). Other configuration information may 1143 be obtained in the same Configuration Payload exchange or may be 1144 obtained by running an additional DHCPv6. 1146 PaC AP EP(AR) PAA 1147 | Link-layer | | | 1148 | association| | | 1149 |<---------->| | | 1150 | | | | 1151 | | | | 1152 |PANA(Discovery and Initial Handshake phase 1153 | & PAR-PAN exchange in Authentication phase) 1154 |<-----------+-------------------------->| 1155 | | | | 1156 | | | | 1157 | | |Authorization| 1158 | | |[IKE-PSK, | 1159 | | | PaC-DI, | 1160 | | | Session-Id] | 1161 | | |<------------| 1162 | | | | 1163 |PANA(PBR-PBA exchange in authentication phase) 1164 |<-----------+-------------------------->| 1165 | | | | 1166 | IKEv2 | | 1167 |(w/Configuration Payload | | 1168 | exchange to obtain IPsec-TIA) | 1169 |<-----------+------------>| | 1170 | | | | 1172 Figure 15: An example sequence for configuring IPsec-TIA in IPv6 1174 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i 1176 In this model, PANA is used for authentication and authorization, and 1177 L2 ciphering is used for access control, the latter is enabled by the 1178 former. The L2 ciphering is based on using PSK (Pre-Shared Key) mode 1179 of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i], 1180 which is derived from the EAP MSK as a result of successful PANA 1181 authentication. In this document, the pre-shared key shared between 1182 station and AP is referred to as PMK (Pair-wise Master Key). In this 1183 model, MAC address is used as the device identifier in PANA. 1185 A typical purpose of using this model is to reduce AP management cost 1186 by allowing physical separation of RADIUS/Diameter client from access 1187 points, where AP management can be a significant issue when deploying 1188 a large number of access points. 1190 By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is 1191 also possible to improve wireless LAN security by providing protected 1192 disconnection procedure at L3. 1194 This model does not require any change in the current WPA and IEEE 1195 802.11i specifications. This also means that PANA doesn't provide 1196 any L2 security features beyond those already provided for in WPA and 1197 IEEE 802.11i. 1199 10.2.2.1 Separate PAA and AP 1201 When PAA and AP are separated, two (virtual) APs are needed, one is 1202 connected to an unauthenticated VLAN and the other to an 1203 authenticated VLAN. The former and latter APs are referred to as 1204 unauthenticated VLAN AP and authenticated VLAN AP, respectively. If 1205 a PaC does not have a PMK with the authenticated VLAN AP, it runs 1206 PANA on the unauthenticated VLAN to obtain the MAC address of the 1207 authenticated VLAN AP and derive the PMK valid for the AP. Once the 1208 PMK is obtained, the PaC associates with the authenticated VLAN AP 1209 with performing 4-way handshake. It configures an (potentially new) 1210 IP address and starts sending and receiving data traffic. Future 1211 PANA exchanges are carried on the IEEE 802.1X Controlled Port of the 1212 authenticated VLAN AP just like any other data traffic. 1214 Separating PAA and AP may be used in a network where there is a large 1215 number of APs in a single IP subnet and the network administrator 1216 want to avoid setting up RADIUS client on each AP. Note that the 1217 network administrator would still need to set up SNMPv3 security 1218 association between each AP and PAA for secure PAA-EP communication, 1219 however, in the environments where operator can rely on physical 1220 layer security between PAA and EP, this might not be the case. 1222 In a typical usage scenario, a single PAA co-located with DHCP server 1223 is connected to both unauthenticated VLAN and authenticated VLAN and 1224 that the unauthenticated VLAN AP and the authenticated VLAN AP are 1225 co-located in a single physical AP, as shown in Figure 16. Note that 1226 in an environment where virtual AP are not supported, physical APs 1227 can be used instead of virtual APs. 1229 +------------------+ 1230 | Physical AP | 1231 | +--------------+ | 1232 | |Virtual AP1 | | Unauthenticated 1233 | |(open-access) |---- VLAN \ 1234 | | | | \+-------+ 1235 +---+ | +--------------+ | |PAA/AR/| 1236 |PaC| | | |DHCP |--- Internet 1237 +---+ | +--------------+ | |Server | 1238 | |Virtual AP2 | | /+-------+ 1239 | |(WPA PSK mode)|---- Authenticated / 1240 | | | | VLAN 1241 | +--------------+ | 1242 | | 1243 +------------------+ 1245 Figure 16: Separate PAA and AP with two virtual APs 1247 When a PaC does not have a PMK with an authenticated VLAN AP, the 1248 following procedure is taken: 1250 1. The PaC associates with the unauthenticated VLAN AP. 1252 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 1253 configures a link-local address (in the case of IPv6), and then 1254 runs PANA by using the address. 1256 3. Upon successful authentication, the PaC obtains a distinct PMK 1257 for each authenticated VLAN AP controlled by the PAA. 1259 4. The PaC associated with an authenticated VLAN AP, with performing 1260 4-way handshake to establish a PTK (Pair-wise Transient Key) 1261 between the PaC and AP, by using the PMK. 1263 5. If the PaC is required to configure a new IP address (POPA) as 1264 signaled by the PAA at the end of successful authentication, it 1265 should configure POPA by using any method that the client 1266 normally uses. If PRPA is an IPv4 address, it should be 1267 unconfigured before POPA configuration. 1269 Note that switching from one VLAN to another is a commonly used 1270 technique in WPA (even without PANA) where the client that does not 1271 have any valid credentials first accesses the certificate server via 1272 https through the unauthenticated VLAN to perform a sign-in procedure 1273 to obtain a certificate, and then switches to the authenticated VLAN 1274 with the obtained certificate. 1276 When the MSK is updated as a result of EAP re-authentication, a new 1277 PMK is derived for and transfered to each authenticated VLAN AP. 1278 WPA/IEEE 802.11i 4-way handshake is performed between the PaC and its 1279 currently associating authenticated VLAN AP to derive a new PTK. 1281 10.2.2.2 Co-located PAA and AP 1283 The IEEE 802.11 specification [802.11] allows Class 1 data frames to 1284 be received in any state. Also, the latest version of IEEE 802.11i 1285 [802.11i] optionally allows higher-layer data traffic that is 1286 terminated between stations (including AP) are received and processed 1287 on their IEEE 802.1X Uncontrolled Ports. This feature allows 1288 processing IP-based traffic (such as ARP, IPv6 neighbor discovery, 1289 DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to client 1290 authentication. (Note: WPA and its corresponding version of IEEE 1291 802.11i draft do not explicitly define this operation, so it may be 1292 safer not to use this co-located PAA and AP case in WPA). 1294 Until the PaC is successfully authenticated, only a selected type of 1295 IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any 1296 other IP traffic is dropped on the AP without forwarding to the DS 1297 (Distribution System). Upon successful PANA authentication, the 1298 traffic switches to the controlled port. Host configuration, 1299 including obtaining an (potentially new) IP address, takes place on 1300 this port. Usual DHCP-based, and also in the case of IPv6 stateless 1301 autoconfiguration, mechanism is available to the PaC. After this 1302 point, the rest of the IP traffic, including PANA exchanges, are 1303 processed on the controlled port. 1305 Since this case does not require virtual AP switching, the procedure 1306 to bootstrap PSK mode becomes simpler compared to the separate PAA 1307 and EP case, however, with a cost of configuring RADIUS/Diameter 1308 client on each AP. 1310 When a PaC does not have a PMK with an authenticated VLAN AP, the 1311 following procedure is taken: 1313 1. The PaC associates with the AP. 1315 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 1316 configures a link-local address (in the case of IPv6), and then 1317 runs PANA by using the address. 1319 3. Upon successful authentication, the PaC obtains a PMK for each AP 1320 controlled by the PAA. 1322 4. The PaC performs 4-way handshake to establish a PTK (Pair-wise 1323 Transient Key) between the PaC and AP, by using the PMK. 1325 5. The PaC obtains a POPA by using any method that the client 1326 normally uses. 1328 10.2.3 Capability Discovery 1330 When a PaC is a mobile, there may be multiple APs available in its 1331 vicinity. Each AP are connected to one of the following types of 1332 access networks. 1334 a) Free access network 1336 There is no IEEE 802.1X or PANA authentication in this access 1337 network. 1339 b) PANA-secured network 1341 There is PANA authentication in this access network. 1343 c) IEEE 802.1X-secured network 1345 There is IEEE 802.1X authentication in this access network. 1347 Type (c) is distinguished from others by checking the capability 1348 information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i 1349 defines RSN Information Element for this purpose). Types (a) and (b) 1350 are not distinguishable until the PaC associates with the AP, get an 1351 IP address, and engage in PANA discovery. The default PaC behavior 1352 would be to act as if this is a free network and attempt DHCP. This 1353 would be detected by the access network and trigger unsolicited PANA 1354 discovery. A type (b) network would send a PANA-Start-Request to the 1355 client and block general purpose data traffic. This helps the client 1356 discover whether the network is type (a) or type (b). Or if the PaC 1357 is pre-provisioned with the information that this is a PANA enabled 1358 network, it can attempt PAA discovery immediately. 1360 The PaC behavior after connecting to an AP of type (b) network is 1361 described in Section 10.2, Section 10.2.1 and Section 10.2.2. Note 1362 that in case of using PANA for bootstrapping WPA/IEEE 802.11i PSK 1363 mode (see Section 10.2.2), PaC needs to know whether PAA and AP are 1364 separated (see Section 10.2.2.1) or co-located (see Section 10.2.2.2) 1365 due to PaC having to act differently in each mode. This is achieved 1366 by checking the existence of an EP-Device-Id AVP in PANA-Bind-Request 1367 message (if an EP-Device-Id AVP is included then PAA is not 1368 co-located with AP). 1370 11. Open Issue 1372 Certain combination of network environments and timing cases may 1373 require further considerations. 1375 If PaC changes access point right after a successful PANA 1376 authorization but before POPA configuration, it might be confused 1377 whether the new IP address configured via the new access point is the 1378 POPA of the ongoing session or a PRPA of a new session. When the PRPA 1379 and POPA types or configuration mechanisms are different this is not 1380 a problem. One possible combination where such clues are not 1381 available is when PaC moves from a Case A of Section 10.2.1.1 1382 (IPsec-TIA obtained by using DHCPv4) network to a Case D of Appendix 1383 A.1 (IPsec-TIA obtained by using RFC3118) network. 1385 In another example, when PaC switches from one wired Ethernet hub to 1386 another (without the use of bootstrapping IPsec) before configuring 1387 the POPA. In this case, PaC may not able to know whether an obtained 1388 address is the POPA in the same subnet or a PRPA in a new subnet. 1390 For these cases, a mechanism to remove the ambiguity (PRPA vs. POPA) 1391 may need to be defined. 1393 12. Acknowledgments 1395 We would like to thank Bernard Aboba and Yacine El Mghazli for their 1396 valuable comments. 1398 Normative References 1400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1401 Requirement Levels", BCP 14, RFC 2119, March 1997. 1403 [I-D.ietf-eap-rfc2284bis] 1404 Blunk, L., "Extensible Authentication Protocol (EAP)", 1405 draft-ietf-eap-rfc2284bis-09 (work in progress), February 1406 2004. 1408 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1409 Protocol (v3): Technical Specification", RFC 3377, 1410 September 2002. 1412 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1413 "Remote Authentication Dial In User Service (RADIUS)", RFC 1414 2865, June 2000. 1416 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1417 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1419 [I-D.ietf-zeroconf-ipv4-linklocal] 1420 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1421 Addresses", draft-ietf-zeroconf-ipv4-linklocal-14 (work in 1422 progress), April 2004. 1424 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 1425 E. Lear, "Address Allocation for Private Internets", BCP 1426 5, RFC 1918, February 1996. 1428 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1429 Autoconfiguration", RFC 2462, December 1998. 1431 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1432 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1433 1998. 1435 [RFC3484] Draves, R., "Default Address Selection for Internet 1436 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1438 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1439 (IKE)", RFC 2409, November 1998. 1441 [I-D.ietf-ipsec-ikev2] 1442 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1443 draft-ietf-ipsec-ikev2-13 (work in progress), March 2004. 1445 [I-D.ietf-pana-snmp] 1446 Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for 1447 PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in 1448 progress), April 2004. 1450 [I-D.ietf-pana-pana] 1451 Forsberg, D., "Protocol for Carrying Authentication for 1452 Network Access (PANA)", draft-ietf-pana-pana-03 (work in 1453 progress), February 2004. 1455 [I-D.ietf-pana-ipsec] 1456 Parthasarathy, M., "PANA enabling IPsec based Access 1457 Control", draft-ietf-pana-ipsec-02 (work in progress), 1458 March 2004. 1460 [I-D.ietf-eap-netsel-problem] 1461 Arkko, J. and B. Aboba, "Network Discovery and Selection 1462 Problem", draft-ietf-eap-netsel-problem-00 (work in 1463 progress), January 2004. 1465 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1466 RFC 2486, January 1999. 1468 [I-D.ietf-pana-requirements] 1469 Yegin, A. and Y. Ohba, "Protocol for Carrying 1470 Authentication for Network Access (PANA)Requirements", 1471 draft-ietf-pana-requirements-07 (work in progress), June 1472 2003. 1474 [I-D.yegin-eap-boot-rfc3118] 1475 Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping 1476 RFC3118 Delayed DHCP Authentication Using EAP-based 1477 Network Access Authentication", 1478 draft-yegin-eap-boot-rfc3118-00 (work in progress), 1479 February 2004. 1481 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1482 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1483 (DHCPv6)", RFC 3315, July 2003. 1485 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1486 2131, March 1997. 1488 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1489 Messages", RFC 3118, June 2001. 1491 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 1492 Host Configuration Protocol (DHCPv4) Configuration of 1493 IPsec Tunnel Mode", RFC 3456, January 2003. 1495 Informative References 1497 [I-D.ietf-aaa-eap] 1498 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1499 Authentication Protocol (EAP) Application", 1500 draft-ietf-aaa-eap-05 (work in progress), April 2004. 1502 [I-D.josefsson-pppext-eap-tls-eap] 1503 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 1504 "Protected EAP Protocol (PEAP)", 1505 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 1506 October 2003. 1508 [I-D.ietf-pppext-eap-ttls] 1509 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 1510 Authentication Protocol (EAP-TTLS)", 1511 draft-ietf-pppext-eap-ttls-04 (work in progress), April 1512 2004. 1514 [I-D.tschofenig-eap-ikev2] 1515 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 1516 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in 1517 progress), February 2004. 1519 [DSL] DSL Forum Architecture and Transport Working Group, "DSL 1520 Forum TR-058 Multi-Service Architecture and Framework 1521 Requirements", September 2003. 1523 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 1524 supplement to standard for telecommunications and 1525 information exchange between systems - lan/man specific 1526 requirements - part 11: Wireless medium access control 1527 (mac) and physical layer (phy) specifications: 1528 Specification for enhanced security", IEEE 802.11i/D10.0, 1529 2004. 1531 [802.11] Institute of Electrical and Electronics Engineers, 1532 "Information technology - telecommunications and 1533 information exchange between systems - local and 1534 metropolitan area networks - specific requirements part 1535 11: Wireless lan medium access control (mac) and physical 1536 layer (phy) specifications", IEEE Standard 802.11, 1537 1999(R2003). 1539 [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi 1540 WPA v2.0, 2003. 1542 Authors' Addresses 1544 Prakash Jayaraman 1545 Network Equipment Technologies, Inc. 1546 6900 Paseo Padre Parkway 1547 Fremont, CA 94555 1548 USA 1550 Phone: +1 510 574 2305 1551 EMail: prakash_jayaraman@net.com 1553 Rafa Marin Lopez 1554 University of Murcia 1555 30071 Murcia 1556 Spain 1558 EMail: rafa@dif.um.es 1560 Yoshihiro Ohba 1561 Toshiba America Research, Inc. 1562 1 Telcordia Drive 1563 Piscateway, NJ 08854 1564 USA 1566 Phone: +1 732 699 5365 1567 EMail: yohba@tari.toshiba.com 1569 Mohan Parthasarathy 1570 Nokia 1571 313 Fairchild Drive 1572 Mountain View, CA 94043 1573 USA 1575 Phone: +1 408 734 8820 1576 EMail: mohanp@sbcglobal.net 1578 Alper E. Yegin 1579 Samsung Advanced Institute of Technology 1580 75 West Plumeria Drive 1581 San Jose, CA 95134 1582 USA 1584 Phone: +1 408 544 5656 1585 EMail: alper.yegin@samsung.com 1587 Appendix A. Other Possible Cases for PANA with Bootstrapping IPsec in 1588 Wireless LAN 1590 This section describes other possible cases for PANA with 1591 Bootstrapping IPsec in wireless LAN environments. 1593 Appendix A.1 IPv4 1595 Case D: IPsec-TIA obtained by using RFC3118 1597 In this case, the POPA is configured and used as both IPsec-TIA 1598 and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118 1599 (authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK 1600 needed for authenticated DHCP is distributed from the PAA to the 1601 POPA DHCPv4 server by using the method specified in 1602 [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using 1603 DHCPv4 and may be assigned with a short lease period in order to 1604 provide some level of robustness against IP address depletion 1605 attack. The IPsec-TIA is bound to an IPsec SA by using specifying 1606 the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2 1607 CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec]. 1608 Once the IPsec-TIA is obtained, the PANA re-authentication based 1609 on PRAR (PANA Re-Authentication Request) and PRAA (PANA 1610 Re-Authentication Answer) exchange is performed with using the 1611 obtained IPsec-TIA in order to inform PAA of the update of PaC-DI. 1612 The IKE procedure should occur after the PRAR-PRAA exchange 1613 procedure. The PaC unconfigures the PRPA immediately after the 1614 IPsec-TIA is obtained. 1616 PRPA 1617 PaC AP DHCPv4 Server PAA EP(AR) 1618 | Link-layer | | | | 1619 | association| | | | 1620 |<---------->| | | | 1621 | | | | | 1622 | DHCPv4 | | | 1623 |<-----------+--------->| | | 1624 | | | | | 1625 |PANA(Discovery and Initial Handshake phase | 1626 | & PAR-PAN exchange in Authentication phase) | 1627 |<-----------+-------------------------->| | 1628 | | | | 1629 | | | | 1630 | | POPA | | 1631 | | DHCPv4 Server |Authorization| 1632 | | |Authorization|[IKE-PSK, | 1633 | | |[DHCP-PSK, | PaC-DI, | 1634 | | | Session-Id] | Session-Id] | 1635 | | |<------------|------------>| 1636 | | | | | 1637 |PANA(PBR-PBA exchange in Authentication phase) | 1638 |<-----------+-------------------------->| | 1639 | | | | | 1640 | Authenticated DHCPv4 | | | 1641 | (RFC3118) | | | 1642 |<-----------+------------>| | | 1643 | | | | | 1644 | PANA(PRAR-PRAA exchange using POPA as PaC-DI) | 1645 |<-----------+-------------------------->| | 1646 | | | | | 1647 | | IKE | | 1648 |<-----------+---------------------------------------->| 1649 | | | | | 1650 | | | | | 1652 Figure 17: An example case for IPsec-TIA obtained by using RFC3118 1654 Appendix A.2 IPv6 1656 Case A: IPsec-TIA obtained by using DHCPv6 1658 This case is similar to Case A in IPv4, except that a link-local 1659 address is used as the PRPA and IPsec-TOA, and that the DHCPv6 1660 procedure can occur at any time after link-layer association and 1661 before IKE. 1663 This case is not recommended since there is an ambiguity on 1664 whether IPv6 Neighbor Discovery for the POPA should run on the 1665 physical interface or inside the IPsec tunnel or both. 1667 PaC AP DHCPv6 Server PAA EP(AR) 1668 | Link-layer | | | | 1669 | association| | | | 1670 |<---------->| | | | 1671 | | | | | 1672 | DHCPv6 | | | 1673 |<-----------+------------>| | | 1674 | | | | | 1675 |PANA(Discovery and Initial Handshake phase | 1676 | & PAR-PAN exchange in Authentication phase) | 1677 |<-----------+-------------------------->| | 1678 | | | | | 1679 | | | |Authorization| 1680 | | | |[IKE-PSK, | 1681 | | | | PaC-DI, | 1682 | | | | Session-Id] | 1683 | | | |------------>| 1684 | | | | | 1685 |PANA(PBR-PBA exchange in Authentication phase) | 1686 |<-----------+-------------------------->| | 1687 | | | | | 1688 | | IKE | | 1689 |<-----------+---------------------------------------->| 1690 | | | | | 1691 | | | | | 1693 Figure 18: An example case for IPsec-TIA obtained by using DHCPv6 1695 Case B: IPsec-TIA obtained by using IPv6 stateless address 1696 autoconfiguration 1698 In this case, the IPsec-TOA (link-local address) and IPsec-TIA 1699 (global address) are configured through IPv6 stateless address 1700 autoconfiguration before running IKE. Other configuration 1701 information can be obtained by using several methods including 1702 authenticated DHCPv6, Configuration Payload exchange and DHCPv6 1703 over IPsec SA. 1705 This case is not recommended for the same reason as Case A of 1706 IPv6. 1708 PaC AP PAA EP(AR) 1709 | Link-layer | | | 1710 | association| | | 1711 |<---------->| | | 1712 | | | | 1713 | | | | 1714 |PANA(Discovery and Initial Handshake phase | 1715 | & PAR-PAN exchange in Authentication phase) | 1716 |<-----------+-------------------------->| | 1717 | | | | 1718 | | |Authorization| 1719 | | |[IKE-PSK, | 1720 | | | PaC-DI, | 1721 | | | Session-Id] | 1722 | | |------------>| 1723 | | | | 1724 |PANA(PBR-PBA exchange in Authentication phase) | 1725 |<-----------+-------------------------->| | 1726 | | | | 1727 | IPv6 stateless address autoconfiguration | 1728 | (can occur at any time before Association and IKEv2) | 1729 |<-----------+---------------------------------------->| 1730 | | | | 1731 | | IKEv2 | | 1732 |<-----------+---------------------------------------->| 1733 | | | | 1735 Figure 19: An example sequence for IPsec-TIA obtained by using 1736 IPv6 stateless address autoconfiguration 1738 Case C: IPsec-TIA obtained by using authenticated DHCPv6 1740 This case is similar to Case C of IPv4, except that a link-local 1741 address is used as the PRPA, and that there is no need for 1742 additional PRAR-PRAA exchange to update the PaC-DI. 1744 PaC AP DHCPv6 Server PAA EP(AR) 1745 | Link-layer | | | | 1746 | association| | | | 1747 |<---------->| | | | 1748 | | | | | 1749 | | | | | 1750 |PANA(Discovery and Initial Handshake phase | 1751 | & PAR-PAN exchange in Authentication phase) | 1752 |<-----------+-------------------------->| | 1753 | | | | | 1754 | | |Authorization|Authorization| 1755 | | |[DHCP-PSK, |[IKE-PSK, | 1756 | | | Session-Id] | PaC-DI, | 1757 | | | | Session-Id] | 1758 | | |<------------|------------>| 1759 | | | | | 1760 |PANA(PBR-PBA exchange in Authentication phase) | 1761 |<-----------+-------------------------->| | 1762 | | | | | 1763 | Authenticated DHCPv6 | | | 1764 |<-----------+------------>| | | 1765 | | | | | 1766 | PANA(PRAR-PRAA exchange using POPA as PaC-DI) 1767 |<-----------+-------------------------->| | 1768 | | | |Authorization| 1769 | | | | [IKE-PSK, | 1770 | | | | PaC-DI, | 1771 | | | | Session-Id]| 1772 | | | |------------>| 1773 | | IKE | | 1774 |<-----------+---------------------------------------->| 1775 | | | | | 1776 | | | | | 1778 Figure 20: An example case for configuring IPsec-TIA by using 1779 authenticated DHCPv6 1781 Intellectual Property Statement 1783 The IETF takes no position regarding the validity or scope of any 1784 intellectual property or other rights that might be claimed to 1785 pertain to the implementation or use of the technology described in 1786 this document or the extent to which any license under such rights 1787 might or might not be available; neither does it represent that it 1788 has made any effort to identify any such rights. Information on the 1789 IETF's procedures with respect to rights in standards-track and 1790 standards-related documentation can be found in BCP-11. Copies of 1791 claims of rights made available for publication and any assurances of 1792 licenses to be made available, or the result of an attempt made to 1793 obtain a general license or permission for the use of such 1794 proprietary rights by implementors or users of this specification can 1795 be obtained from the IETF Secretariat. 1797 The IETF invites any interested party to bring to its attention any 1798 copyrights, patents or patent applications, or other proprietary 1799 rights which may cover technology that may be required to practice 1800 this standard. Please address the information to the IETF Executive 1801 Director. 1803 Full Copyright Statement 1805 Copyright (C) The Internet Society (2004). All Rights Reserved. 1807 This document and translations of it may be copied and furnished to 1808 others, and derivative works that comment on or otherwise explain it 1809 or assist in its implementation may be prepared, copied, published 1810 and distributed, in whole or in part, without restriction of any 1811 kind, provided that the above copyright notice and this paragraph are 1812 included on all such copies and derivative works. However, this 1813 document itself may not be modified in any way, such as by removing 1814 the copyright notice or references to the Internet Society or other 1815 Internet organizations, except as needed for the purpose of 1816 developing Internet standards in which case the procedures for 1817 copyrights defined in the Internet Standards process must be 1818 followed, or as required to translate it into languages other than 1819 English. 1821 The limited permissions granted above are perpetual and will not be 1822 revoked by the Internet Society or its successors or assignees. 1824 This document and the information contained herein is provided on an 1825 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1826 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1827 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1828 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1829 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1831 Acknowledgment 1833 Funding for the RFC Editor function is currently provided by the 1834 Internet Society.