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