idnits 2.17.1 draft-ietf-pana-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1705. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1682. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1689. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1695. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1711), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 24) being 69 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 46 pages 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 300 has weird spacing: '...address o ...' == Line 305 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 (July 16, 2004) is 7223 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 1412, but no explicit reference was found in the text == Unused Reference: 'DSL' is defined on line 1417, but no explicit reference was found in the text ** 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-14 == 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-04 == Outdated reference: A later version (-07) exists of draft-ietf-pana-ipsec-03 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-00 -- Obsolete informational reference (is this intentional?): RFC 2486 (Obsoleted by RFC 4282) == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-08 == Outdated reference: A later version (-10) exists of draft-ietf-aaa-eap-08 == Outdated reference: A later version (-03) exists of draft-yegin-eap-boot-rfc3118-00 == 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 (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PANA Working Group P. Jayaraman 2 Internet-Draft Net.Com 3 Expires: January 14, 2005 R. Lopez 4 Univ. of Murcia 5 Y. Ohba (Ed.) 6 Toshiba 7 M. Parthasarathy 8 Nokia 9 A. Yegin 10 Samsung 11 July 16, 2004 13 PANA Framework 14 draft-ietf-pana-framework-01 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 14, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 PANA design provides support for various types of deployments. 48 Access networks can differ based on the availability of lower-layer 49 security, placement of PANA entities, choice of client IP 50 configuration and authentication methods, etc. This I-D defines a 51 general framework for describing how these various deployment choices 52 are handled by PANA and the access network architectures. 53 Additionally, two possible deployments are described in detail: using 54 PANA over DSL networks and WLAN networks. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Specification of Requirements . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. General PANA Framework . . . . . . . . . . . . . . . . . . . 6 62 4. Environments . . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. IP Address Configuration . . . . . . . . . . . . . . . . . . 13 64 6. Data Traffic Protection . . . . . . . . . . . . . . . . . . 16 65 7. PAA-EP Protocol . . . . . . . . . . . . . . . . . . . . . . 17 66 7.1 PAA and EP Locations . . . . . . . . . . . . . . . . . . . 17 67 7.1.1 Single PAA, Single EP, Co-located . . . . . . . . . . 18 68 7.1.2 Separate PAA and EP . . . . . . . . . . . . . . . . . 18 69 7.2 Notification of PaC Presence . . . . . . . . . . . . . . . 20 70 7.3 Filter Rule Installation . . . . . . . . . . . . . . . . . 20 71 8. Network Selection . . . . . . . . . . . . . . . . . . . . . 21 72 9. Authentication Method Choice . . . . . . . . . . . . . . . . 23 73 10. Example Cases . . . . . . . . . . . . . . . . . . . . . . . 24 74 10.1 DSL Access Network . . . . . . . . . . . . . . . . . . . 24 75 10.1.1 Bridging Mode . . . . . . . . . . . . . . . . . . . 24 76 10.1.2 Router Mode . . . . . . . . . . . . . . . . . . . . 25 77 10.1.3 PANA and Dynamic Internet Service Provider 78 Selection . . . . . . . . . . . . . . . . . . . . . 25 79 10.2 Wireless LAN Example . . . . . . . . . . . . . . . . . . 26 80 10.2.1 PANA with Bootstrapping IPsec . . . . . . . . . . . 28 81 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i . . . . . . 32 82 10.2.3 Capability Discovery . . . . . . . . . . . . . . . . 34 83 11. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 36 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 86 13.1 Normative References . . . . . . . . . . . . . . . . . . . 37 87 13.2 Informative References . . . . . . . . . . . . . . . . . . 38 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40 89 A. Other Possible Cases for PANA with Bootstrapping IPsec in 90 Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . 41 91 A.1 IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 92 A.2 IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 93 Intellectual Property and Copyright Statements . . . . . . . 46 95 1. Introduction 97 PANA is a link-layer agnostic network access authentication protocol 98 that runs between a node that wants to gain access to the network and 99 a server on the network side. PANA defines a new EAP [RFC3748] lower 100 layer that uses IP between the protocol end points. 102 The motivation to define such a protocol and the requirements are 103 described in [I-D.ietf-pana-requirements]. Protocol details are 104 documented in [I-D.ietf-pana-pana]. [I-D.ietf-pana-ipsec] describes 105 use of IPsec for access control following PANA-based authentication. 106 IPsec can be used for per-packet access control, but nevertheless it 107 is not the only way to achieve this functionality. Alternatives 108 include reliance on physical security and link-layer ciphering. 109 Separation of PANA server from the entity enforcing the access 110 control is envisaged as an optional deployment choice. SNMP 111 [I-D.ietf-pana-snmp] is chosen as the protocol to carry associated 112 information between the separate nodes. 114 PANA design provides support for various types of deployments. 115 Access networks can differ based on the availability of lower-layer 116 security, placement of PANA entities, choice of client IP 117 configuration and authentication methods, etc. 119 PANA can be used in any access network regardless of the underlying 120 security. For example, the network might be physically secured, or 121 secured by means of cryptographic mechanisms after the successful 122 client-network authentication. 124 The PANA client, PANA authentication agent, authentication server, 125 and enforcement point are the relevant functional entities in this 126 design. PANA authentication agent and enforcement point(s) can be 127 placed on various elements in the access network (e.g., access point, 128 access router, dedicated host). 130 IP address configuration mechanisms vary as well. Static 131 configuration, DHCP, stateless address autoconfiguration are possible 132 mechanisms to choose from. If the client configures an IPsec tunnel 133 for enabling per-packet security, configuring IP addresses inside the 134 tunnel becomes relevant, for which there are additional choices such 135 as IKE. 137 This I-D defines a general framework for describing how these various 138 deployment choices are handled by PANA and the access network 139 architectures. Additionally, two possible deployments are described 140 in detail: PANA over DSL networks and WLAN networks. 142 1.1 Specification of Requirements 144 In this document, several words are used to signify the requirements 145 of the specification. These words are often capitalized. The key 146 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 147 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 148 are to be interpreted as described in [RFC2119]. 150 2. Terminology 152 Pre-PANA address (PRPA) 154 This is an IP address configured on a PANA client before starting 155 the PANA protocol exchange. 157 Post-PANA address (POPA) 159 This is an IP address (optionally) configured on a PANA client 160 after a successful authentication. 162 IPsec Tunnel Inner Address (IPsec-TIA) 164 This is an IP address configured on a PANA client as the inner 165 address of an IPsec tunnel mode SA. 167 IPsec Tunnel Outer Address (IPsec-TOA) 169 This is the address configured on a PANA client as the outer 170 address of an IPsec tunnel mode SA. 172 Secure Association Protocol 174 A protocol that provides a cryptographic binding between the 175 initial entity authentication (and authorization) exchange to the 176 subsequent exchange of data packets. Examples of secure 177 association protocols include the 4-way handshake in IEEE 802.11i 178 [802.11i], and IKE [RFC2409] in IP-based access control. 180 3. General PANA Framework 182 PANA protocol is designed to facilitate authentication and 183 authorization of clients in access networks. PANA is an EAP 184 [RFC3748] lower-layer that carries EAP authentication methods 185 encapsulated inside EAP between a client host and an agent in the 186 access network. While PANA enables the authentication process 187 between the two entities, it is only a part of an overall AAA and 188 access control framework. A AAA and access control framework using 189 PANA is comprised of four functional entities. 191 PANA Client (PaC): 193 The PaC is the client implementation of the PANA protocol. This 194 entity resides on the end host that is requesting network access. 195 The end hosts are, for example, laptops, PDAs, cell phones, 196 desktop pcs that are connected to a network via a wired or 197 wireless interface. A PaC is responsible for requesting network 198 access and engaging in the authentication process using the PANA 199 protocol 201 PANA Authentication Agent (PAA): 203 The PAA is the server implementation of the PANA protocol. A PAA 204 is in charge of interfacing with the PaCs for authenticating and 205 authorizing them for the network access service. 206 The PAA consults an authentication server in order to verify the 207 credentials and rights of a PaC. If the authentication server 208 resides on the same host as the PAA, an API is sufficient for this 209 interaction. When they are separated (a much more common case in 210 public access networks), a protocol needs to run between the two. 211 LDAP [RFC3377] and AAA protocols like RADIUS [RFC2865] and 212 Diameter [RFC3588] are commonly used for this purpose. 213 The PAA is also responsible for updating the access control state 214 (i.e., filters) depending on the creation and deletion of the 215 authorization state. The PAA communicates the updated state to 216 the enforcement points in the network. If the PAA and EP are 217 residing on the same host, an API is sufficient for this 218 communication. Otherwise, a protocol is required to carry the 219 authorized client attributes from the PAA to the EP. While not 220 prohibiting other protocols, currently SNMP [I-D.ietf-pana-snmp] 221 is suggested for this task. 222 The PAA resides on a node that is typically called a NAS (network 223 access server) in the local area network. PAA can be hosted on 224 any IP-enabled node on the same IP subnet as the PaC. For example 225 on a BAS (broadband access server) in DSL networks, or PDSN in 226 3GPP2 networks. 228 Authentication Server (AS): 230 The server implementation that is in charge of verifying the 231 credentials of a PaC that is requesting the network access 232 service. The AS receives requests from the PAA on behalf of the 233 PaCs, and responds with the result of verification together with 234 the authorization parameters (e.g., allowed bandwidth, IP 235 configuration, etc). The AS might be hosted on the same host as 236 the PAA, on a dedicated host on the access network, or on a 237 central server somewhere on the Internet. 239 Enforcement Point (EP): 241 The access control implementation that is in charge of allowing 242 access to authorized clients while preventing access by others. 243 An EP learns the attributes of the authorized clients from the 244 PAA. 245 The EP uses non-cryptographic or cryptographic filters to 246 selectively allow and discard data packets. These filters may be 247 applied at the link-layer or the IP-layer. When cryptographic 248 access control is used, a secure association protocol needs to run 249 between the PaC and EP. Link or network layer protection (for 250 example TKIP, IPsec ESP) is used after the secure association 251 protocol established the necessary security association to enable 252 integrity protection, data origin authentication, replay 253 protection and optionally confidentiality protection. 254 An EP must be located strategically in a local area network to 255 minimize the access of unauthorized clients to the network. For 256 example, the EP can be hosted on the switch that is directly 257 connected to the clients in a wired network. That way the EP can 258 drop unauthorized packets before they reach any other client host 259 or beyond the local area network. 261 Figure 1 illustrates these functional entities and the interfaces 262 (protocols, APIs) among them. 264 RADIUS/ 265 Diameter/ 266 +-----+ PANA +-----+ LDAP/ API +-----+ 267 | PaC |<----------------->| PAA |<---------------->| AS | 268 +-----+ +-----+ +-----+ 269 ^ ^ 270 | | 271 | +-----+ | 272 IKE/ +-------->| EP |<--------+ SNMP/ API 273 4-way handshake +-----+ 275 Figure 1: PANA Functional Model 277 Some of the entities may be co-located depending on the deployment 278 scenario. For example, the PAA and EP would be on the same node 279 (BAS) in DSL networks. In that case a simple API is sufficient 280 between the PAA and EP. In small enterprise deployments the PAA and 281 AS may be hosted on the same node (access router) that eliminates the 282 need for a protocol run between the two. The decision to co-locate 283 these entities or otherwise, and their precise location in the 284 network topology are deployment decisions. 286 Use of IKE or 4-way handshake protocols for secure association is 287 only required in the absence of any lower-layer security prior to 288 running PANA. Physically secured networks (e.g., DSL) or the 289 networks that are already cryptographically secured on the link-layer 290 prior to PANA run (e.g., cdma2000) do not require additional secure 291 association and per-packet ciphering. These networks can bind the 292 PANA authentication and authorization to the lower-layer secure 293 channel that is already available. 295 Figure 2 illustrates the signaling flow for authorizing a client for 296 network access. 298 PaC EP PAA AS 299 | | | | 300 IP address o | | | 301 config. | PANA | | AAA | 302 |<------------------------------>|<-------------->| 303 | | SNMP | | 304 (Optional) | |<-------------->| | 305 IP address o | | | 306 config. | Sec.Assoc. | | | 307 |<------------->| | | 308 | | | | 309 | Data traffic | | | 310 |<-----------------> | | 311 | | | | 313 Figure 2: PANA Signaling Flow 315 The EP on the access network allows general data traffic from any 316 authorized PaC, whereas it allows only limited type of traffic (e.g., 317 PANA, DHCP, router discovery) for the unauthorized PaCs. This 318 ensures that the newly attached clients have the minimum access 319 service to engage in PANA and get authorized for the unlimited 320 service. 322 The PaC MUST configure an IP address prior to running PANA. After 323 the successful PANA authentication, depending on the deployment 324 scenario the PaC MAY need to re-configure its IP address or configure 325 additional IP address(es). The additional address configuration MAY 326 be executed as part of the secure association protocol run. 328 An initially unauthorized PaC starts the PANA authentication by 329 discovering the PAA on the access network, followed by the EAP 330 exchange over PANA. The PAA interacts with the AS during this 331 process. Upon receiving the authentication and authorization result 332 from the AS, the PAA informs the PaC about the result of its network 333 access request. 335 If the PaC is authorized to gain the access to the network, the PAA 336 also sends the PaC-specific attributes (e.g., IP address, 337 cryptographic keys, etc.) to the EP by using SNMP. The EP uses this 338 information to alter its filters for allowing data traffic from and 339 to the PaC to pass through. 341 In case cryptographic access control needs to be enabled after the 342 PANA authentication, a secure association protocol runs between the 343 PaC and the EP. The PaC should already have the input parameters to 344 this process as a result of the successful PANA exchange. Similarly, 345 the EP should have obtained them from the PAA via SNMP. Secure 346 association exchange produces the required security associations 347 between the PaC and the EP to enable cryptographic data traffic 348 protection. Per-packet cryptographic data traffic protection 349 introduces additional per-packet overhead but the overhead exists 350 only between the PaC and EP and will not affect communications beyond 351 the EP. In this sense it is important to place the EP as close to 352 the edge of the network as possible. 354 Finally data traffic can start flowing from and to the newly 355 authorized PaC. 357 4. Environments 359 The PANA protocol can be used on any network environment whether 360 there is a lower-layer secure channel prior to PANA, or one has to be 361 enabled upon successful PANA authentication. 363 With regard to network access authentication two types of networks 364 need to be considered: 366 a. Networks where a secure channel is already available prior to 367 running PANA 369 This type of network is characterized by the existence of 370 protection against spoofing and eavesdropping. Nevertheless, user 371 authentication and authorization is required for network 372 connectivity. 373 One example is a DSL network where the lower-layer security is 374 provided by physical means (a.1). Physical protection of the 375 network wiring ensures that practically there is only one client 376 that can send and receive IP packets on the link. Another example 377 is a cdma2000 network where the lower-layer security is provided 378 by means of cryptographic protection (a.2). By the time the 379 client requests access to the network-layer services, it is 380 already authenticated and authorized for accessing the radio 381 channel, and link-layer ciphering is enabled. 382 The presence of a secure channel before PANA exchange eliminates 383 the need for executing a secure association protocol after PANA. 384 The PANA session can be bound to the communication channel it was 385 carried over. Also, the choice of EAP authentication method 386 depends on the presence of this security during PANA run. Use of 387 some authentication methods outside a secure channel is not 388 recommended (e.g., EAP-MD5). 390 b. Networks where a secure channel is created after running PANA 392 These are the networks where there is no lower-layer protection 393 prior to running PANA. A successful PANA authentication enables 394 generation of cryptographic keys that are used with a secure 395 association protocol to enable per-packet cryptographic 396 protection. 397 PANA authentication is run on an insecure channel that is 398 vulnerable to eavesdropping and spoofing. The choice of EAP 399 method must be resilient to the possible attacks associated with 400 such an environment. Furthermore, the EAP method must be able to 401 create cryptographic keys that will later be used by the secure 402 association protocol. 404 Whether to use a link-layer per-frame security (b.1) or a network 405 layer security (b.2) is a deployment decision. This decision also 406 dictates the choice of the secure association protocol. If 407 link-layer protection is used, the protocol would be link-layer 408 specific. If IP-layer protection is used, the secure association 409 protocol would be IKE and the per-packet security would be 410 provided by IPsec AH/ESP regardless of the underlying link-layer 411 technology. 413 5. IP Address Configuration 415 The PaC configures an IP address before the PANA protocol exchange 416 begins. This address is called a pre-PANA address (PRPA). After a 417 successful authentication, the client may have to configure a 418 post-PANA address (POPA) for communication with other nodes, if PRPA 419 is a local-use (e.g., link-local or private address) or a temporarily 420 allocated IP address. An operator might choose allocating a POPA 421 only after successful PANA authorization either to prevent waste of 422 premium IP resources until the client is authorized, or to enable 423 client identity based address assignment. 425 In case the PaC is a IPv4/IPv6 dual-stacked host, it may configure 426 more than one PRPA. After a successful PANA authentication the PaC 427 may configure multiple POPAs. 429 There are different methods by which a PRPA can be configured. 431 1. In some deployments (e.g., DSL networks) the PaC may be 432 statically configured with an IP address. This address SHOULD be 433 used as PRPA. 435 2. In IPv4, most clients attempt to configure an address dynamically 436 using DHCP [RFC2131]. If they are unable to configure an address 437 using DHCP, they can configure a link-local address using 438 [I-D.ietf-zeroconf-ipv4-linklocal]. 440 When the network access provider is able to run a DHCP server on 441 the access link, the client would configure the PRPA using DHCP. 442 This address may be from a private address pool [RFC1918]. Also, 443 the lease time on the address may vary. For example, a PRPA 444 configured solely for running PANA can have a short lease time. 445 PRPA may be used for local-use only (i.e., only for on-link 446 communication, such as for PANA and IPsec tunneling with EP), or 447 also for ultimate data communication. 449 In case there is no running DHCP server on the link, the client 450 would fall back to configuring a PRPA via zeroconfiguration 451 technique [I-D.ietf-zeroconf-ipv4-linklocal]. This yields a 452 long-term address that can only be used for on-link communication. 454 3. In IPv6, clients configure a link-local address [RFC2462] when 455 they initialize an interface. This address SHOULD be used as a 456 PRPA. 458 When a PRPA is configured, the client starts the PANA protocol 459 exchange. By that time, a dual-stacked client might have configured 460 both an IPv4 address, and one or more IPv6 addresses as PRPAs. When 461 the client successfully authenticates to the network, it may be 462 required to configure POPAs for its subsequent data communication 463 with the other nodes. 465 If the client is already configured with a non-temporary address that 466 can be used with data communication, it is not required to configure 467 a POPA. Otherwise, the PANA-Bind-Request message allows the PAA to 468 indicate the available configuration methods to the PaC. The PaC can 469 choose one of the methods and act accordingly. 471 1. If the network relies on physical or link-layer security, the PaC 472 can configure a POPA using DHCP [RFC2131][RFC3315] or using IPv6 473 stateless auto-configuration [RFC2461]. If IPv4 is being used, a 474 PRPA is likely to be a link-local or private address, or an 475 address with a short DHCP lease. An IPv4 PRPA SHOULD be 476 unconfigured when the POPA is configured to prevent IPv4 address 477 selection problem [I-D.ietf-zeroconf-ipv4-linklocal]. If IPv6 is 478 used, the link-local PRPA SHOULD NOT be unconfigured [RFC3484]. 480 If the PaC is a dual-stacked host, it can configure both IPv4 and 481 IPv6 type POPAs. 483 The PaC with a PRPA and the PAA with IP address X can perform 484 on-link communication as required by PANA. In IPv4, the PRPA and 485 IP address X have the same on-link prefix. In IPv6, the two 486 addresses are link-local addresses. When the PaC replaces its 487 IPv4 PRPA with an IPv4 POPA, the PaC and PAA SHOULD create host 488 routes to each other, as they do not share the same on-link prefix 489 any more. This is needed for the PaC with the IPv4 POPA and the 490 PAA with IP address X to continue on-link communication. In this 491 case, the PaC SHOULD create a host route to IP address X, and the 492 PAA SHOULD create a host route to the IPv4 POPA. PANA defines a 493 mechanism for the PaC to report the POPA to the PAA. 495 2. If the network uses IPsec for protecting the traffic on the link 496 subsequent to PANA authentication [I-D.ietf-pana-ipsec], the PaC 497 would use the PRPA as the outer address of IPsec tunnel mode SA 498 (IPsec-TOA). The PaC also needs to configure an inner address 499 (IPsec-TIA). There are different ways to configure an IPsec-TIA 500 which are indicated in a PANA-Bind-Request message. 502 When an IPv4 PRPA is configured, the same address may be used as 503 both IPsec-TOA and IPsec-TIA. In this case, a POPA is not 504 configured. Alternatively, an IPsec-TIA can be obtained via the 505 configuration method available within [RFC3456] for IPv4, and 506 [I-D.ietf-ipsec-ikev2] for both IPv4 and IPv6. This newly 507 configured address constitutes a POPA. Please refer to 508 [I-D.ietf-pana-ipsec] for more details. 510 IKEv2 can enable configuration of one IPv4 IPsec-TIA and one IPv6 511 IPsec-TIA for the same IPsec tunnel mode SA. Therefore, IKEv2 is 512 recommended for handling dual-stacked PaCs where single execution 513 of PANA and IKE is desired. 515 Although there are potentially a number of different ways to 516 configure a PRPA, and POPA when necessary, it should be noted that 517 the ultimate decision to use one or more of these in a deployment 518 depends on the operator. The decision is dictated by the operator's 519 choice of per-packet protection capability (physical and link-layer 520 vs network-layer), PRPA type (local and temporary vs global and 521 long-term), and POPA configuration mechanisms available in the 522 network. 524 6. Data Traffic Protection 526 Protecting data traffic of authenticated and authorized client from 527 others is another component of providing a complete secure network 528 access solution. Authentication, integrity and replay protection of 529 data packets is needed to prevent spoofing when the underlying 530 network is not physically secured. Encryption is needed when 531 eavesdropping is a concern in the network. 533 When the network is physically secured, or the link-layer ciphering 534 is already enabled prior to PANA, data traffic protection is already 535 in place. In other cases, enabling link-layer ciphering or 536 network-layer ciphering might rely on PANA authentication. The user 537 and network have to make sure that an appropriate EAP method which 538 generates keying materials is used. Once the keying material is 539 available, it needs to be provided to the EP(s) for use with data 540 traffic protection. 542 Network-layer protection, i.e., IPsec, can be used when data traffic 543 protection is required but link-layer protection is not available. 544 Note that the keying material generated by an EAP method is not 545 readily usable by IPsec AH/ESP or most link layer mechanisms. A 546 fresh and unique session key derived from the EAP method is still 547 insufficient to produce an IPsec SA since both traffic selectors and 548 other IPsec SA parameters are missing. The shared secret can be used 549 in conjunction with a key management protocol like IKE [RFC2409] to 550 turn a session key into the required IPsec SA. The details of such a 551 mechanism is outside the scope of PANA protocol and is specified in 552 [I-D.ietf-pana-ipsec]. PANA provides bootstrapping functionality for 553 such a mechanism by carrying EAP methods that can generate initial 554 keying material. 556 Using network-layer ciphers should be regarded as a substitute for 557 link-layer ciphers when the latter is not available. Network-layer 558 ciphering can also be used in addition to link-layer ciphering if the 559 added benefits outweigh its cost to the user and the network. In 560 this case, PANA bootstraps only the network-layer ciphering and 561 link-layer is protected using any of the existing link-layer specific 562 methods. 564 7. PAA-EP Protocol 566 The PANA protocol provides client authentication and authorization 567 functionality for securing network access. The other component of a 568 complete solution is the access control which ensures that only 569 authenticated and authorized clients can gain access to the network. 570 PANA enables access control by distinguishing authenticated and 571 authorized clients from others and generating filtering information 572 for access control mechanisms. 574 Access control can be achieved by placing EPs (Enforcement Points) in 575 the network for policing the traffic flow. EPs should prevent data 576 traffic from and to any unauthorized client unless it's either PANA 577 or one of the other allowed traffic types (e.g., ARP, IPv6 neighbor 578 discovery, DHCP, etc.). 580 When a PaC is authenticated and authorized, the PAA should notify 581 EP(s) and ask for installing filtering rules to allow the PaC to sent 582 and receive data traffic. SNMP is used between PAA and EP(s) for 583 this purpose when these entities are not co-located 584 [I-D.ietf-pana-snmp]. 586 This section describes the possible models on the location of PAA and 587 EP, as well as the basic authorization information that needs to be 588 exchanged between PAA and EP. When PAA and EP are not co-located in 589 a single device, there are other issues such as dead or rebooted peer 590 detection and consideration for specific authorization and accounting 591 models. However, these issues are closely related to the PAA-EP 592 protocol solution and thus not discussed in this document. See 593 [I-D.ietf-pana-snmp] for further discussion. 595 7.1 PAA and EP Locations 597 EPs' location in the network topology should be appropriate for 598 performing access control functionality. The closest IP-capable 599 access device to the client devices is the logical choice. PAA and 600 EPs on an access network should be aware of each other as this is 601 necessary for access control. Generally this can be achieved by 602 manual configuration. Dynamic discovery is another possibility, but 603 this is left to implementations and outside the scope of this 604 document. 606 Since PANA allows the separation of EP and PAA, there are several 607 models depending on the number of EPs and PAAs and their locations. 608 This section describes all possible models on the placement of PAA(s) 609 and EP(s). 611 7.1.1 Single PAA, Single EP, Co-located 613 This model corresponds to the legacy NAS model. Since the PAA and 614 the EP are co-located, the PAA-EP communication can be implemented 615 locally by using, e.g., IPC (Inter-Process Communication). The only 616 difference from the legacy NAS model is the case where there are 617 multiple co-located PAA/EP devices on the same IP link and the PAA/EP 618 devices are L2 switches or access points. In this case, for a PaC 619 that attaches to a given PAA/EP device, other PAA/EP devices should 620 not be discovered by the PaC even if those devices are on the same IP 621 link. Otherwise, the PaC may result in finding a PAA that is not the 622 closest one to it during the PANA discovery and initial handshake 623 phase and performing PANA with the PAA, which does not correspond to 624 the legacy NAS model. To prevent this, each PAA/EP device on an L2 625 switch or access point should not forward multicast PANA discovery 626 message sent by PaCs attached to it to other devices. 628 7.1.2 Separate PAA and EP 630 When PAA is separated from EP, two cases are possible with regard to 631 whether PAA and EP are located in parallel or serial when viewed from 632 PaC, for each of models described in this section. 634 In the first case, PAA is located behind EP. The EP should be 635 configured to always pass through PANA messages and address 636 configuration protocol messages used for configuring an IP address 637 used for initial PANA messaging. This case can typically happen when 638 the EP is an L2 switch or an access point (the EP also has an IP 639 stack to communicate with PAA via a PAA-EP protocol). 641 +---+ +---+ +---+ 642 |PaC|--------|EP |--------|PAA| 643 +---+ +---+\ +---+ 644 \ 645 +---- Internet 647 Figure 3: PAA and EP in Serial 649 In the other case, PAA is located in parallel to EP. Since the EP is 650 not on the communication path between PaC and PAA, the EP does not 651 have to configure to pass through PANA messages or address 652 configuration protocol messages in this case. This case can 653 typically happen when the EP is a router and the PAA is an 654 authentication gateway without IP routing functionality. 656 +---+ 657 +-----|PAA| 658 / +---+ 659 +---+/ 660 |PaC| 661 +---+\ 662 \ +---+ 663 +-----|EP |---- Internet 664 +---+ 666 Figure 4: PAA and EP in Parallel 668 In the remaining of this section, PaC is not shown in figures and the 669 figures cover both the serial and parallel models. 671 7.1.2.1 Single PAA, Single EP, Separated 673 The model benefits from separation of data traffic handling and AAA. 674 The EP does not need to have a AAA protocol implementation which 675 might be updated relatively more frequently than the per-packet 676 access enforcement implementation. 678 7.1.2.2 Single PAA, Multiple EPs 680 In this model, a single PAA controls multiple EPs. The PAA may be 681 separated from any EP or co-located with a particular EP. This model 682 might be useful where it is preferable to run a AAA protocol at a 683 single, manageable point. This model is particularly useful in an 684 access network that consists of a large number of access points on 685 which per-packet access enforcement is made. When a PaC is 686 authenticated to the PAA, the PAA should install access control 687 filters to each of the EPs under control of the PAA if the PAA cannot 688 tell which EP the PaC is attached to. Even if the PAA can tell which 689 EP the PaC is attached to, the PAA may install access control filters 690 to those EPs if the PaC is a mobile device that can roam among the 691 EPs. Such pre-installation of filters can reduce handoff latency. 692 If different access authorization policies are applied to different 693 EPs, different filter rules for a PaC may be installed on different 694 EPs. 696 +---+ 697 |EP |--+ 698 +---+ \ 699 \ 700 +---+ +---+ 701 |EP |----|PAA| 702 +---+ +---+ 703 / 704 +---+ / 705 |EP |--+ 706 +---+ 708 Figure 5: An example model for a single PAA and multiple EPs 710 7.1.2.3 Multiple PAAs 712 The PANA protocol allows multiple PAAs to exist on the same IP link 713 and to be visible to PaCs on the link. PAAs may or may not be 714 co-located with EPs as long as authorization results do not depend on 715 whichever PAAs are chosen by a PaC [I-D.ietf-pana-pana]. 717 7.2 Notification of PaC Presence 719 When PAA and EP are separated and PAA is configured to be the 720 initiator of the discovery and initial handshake phase of PANA, EP 721 has the responsibility to detect presence of a new PaC and notifies 722 the PAA(s) of the presence [I-D.ietf-pana-requirements]. Such a 723 presence notification is carried in a PAA-EP protocol message 724 [I-D.ietf-pana-snmp]. 726 7.3 Filter Rule Installation 728 Filtering rules to be installed on EP generally include a device 729 identifier of PaC, and also cryptographic keying material (e.g., IKE 730 pre-shared key [RFC2409]) when cryptographic data traffic protection 731 is needed (See Section 6). Each keying material is uniquely 732 identified with a keying material name (e.g., ID_KEY_ID in IKE 733 [RFC2409]) and has a lifetime for key management, accounting, access 734 control and security reasons in general. In addition to the device 735 identifier and keying material, other filter rules, such as the IP 736 filter rules specified in NAS-Filter-Rule AVPs carried in Diameter 737 EAP application [I-D.ietf-aaa-eap] may be installed on EP. 739 8. Network Selection 741 The network selection problem statement is made in 742 [I-D.ietf-eap-netsel-problem]. The PANA protocol 743 [I-D.ietf-pana-pana] provides a way for networks to advertise which 744 ISPs are available and for PaC to choose one ISP from the advertised 745 information. When a PaC chooses an ISP in the PANA protocol 746 exchange, the ultimate destination of the AAA exchange is determined 747 based on the identity of the chosen service provider. It is also 748 possible that the PaC does not choose a specific ISP in the PANA 749 protocol exchange. In this case, both the ISP choice and the AAA 750 destination are determined based on the PaC's identity, where the 751 identity may be an NAI [RFC2486] or the physical port number or L2 752 address of the subscriber. 754 As described in [I-D.ietf-eap-netsel-problem], network selection is 755 not only related to AAA routing but also related to payload routing. 756 Once an ISP is chosen and the PaC is successfully authenticated and 757 authorized, PaC is assigned an address by the ISP whose IP prefix may 758 be different from that of the AR. This affects the routing of the 759 subsequent data traffic between AR and PaC. A suggested solution is 760 to add host route from AR to PaC's POPA address and host route from 761 PaC to AR. 763 Consider a typical DSL network where the AR, EP, and PAA are 764 co-located on a BAS (Broadband Access Server) in the access network 765 operated by a NAP (Network Access Provider). Figure 6 shows a 766 typical model for ISP selection. 768 <---- NAP ----><--------- ISP ---------> 770 +---ISP1 771 / 772 +---+ +---------+/ 773 |PaC|----|AR/EP/PAA| 774 +---+ +---------+\ 775 BAS \ 776 +---ISP2 778 Figure 6: A Network Selection Model 780 When network selection is made at L3 with the use of the PANA 781 protocol instead of L2-specific authentication mechanisms, the IP 782 link between PaC and PAA needs to exist prior to doing PANA (and 783 prior to network selection). In this model, the PRPA is either given 784 by NAP or a link-local address is auto-configured. After the 785 successful authentication with the ISP, PaC may acquire an address 786 (POPA) from the ISP. It also learns the address of the AR, e.g., 787 through DHCP, to be used as its default router. The address of the 788 AR may or may not be in the same IP subnet as that of the PaC's POPA. 789 If they don't share the same prefix, they SHOULD use host routes to 790 reach each other. Note that the physically secured DSL networks do 791 not require IPsec-based access control. Therefore the PaCs use one 792 IP address at a time where POPA replaces PRPA upon configuration. 794 9. Authentication Method Choice 796 Authentication methods' capabilities and therefore applicability to 797 various environments differ among them. Not all methods provide 798 support for mutual authentication, key derivation or distribution, 799 and DoS attack resiliency that are necessary for operating in 800 insecure networks. Such networks might be susceptible to 801 eavesdropping and spoofing, therefore a stronger authentication 802 method needs to be used to prevent attacks on the client and the 803 network. 805 The authentication method choice is a function of the underlying 806 security of the network (e.g., physically secured, shared link, 807 etc.). It is the responsibility of the user and the network operator 808 to pick the right method for authentication. PANA carries EAP 809 regardless of the EAP method used. It is outside the scope of PANA 810 to mandate, recommend, or limit use of any authentication methods. 811 PANA cannot increase the strength of a weak authentication method to 812 make it suitable for an insecure environment. There are some 813 EAP-based approaches to achieve this goal (see 814 [I-D.josefsson-pppext-eap-tls-eap],[I-D.ietf-pppext-eap-ttls] 815 ,[I-D.tschofenig-eap-ikev2]). PANA can carry these EAP encapsulating 816 methods but it does not concern itself with how they achieve 817 protection for the weak methods (i.e., their EAP method payloads). 819 10. Example Cases 821 10.1 DSL Access Network 823 In a DSL access network, PANA is seen applicable in the following 824 scenarios. 826 A typical DSL access consists of a NAS device at the DSL-access 827 provider and a DSL-modem (CPE) at the customer premises. The CPE 828 devices support multiple modes of operation and PANA is applicable in 829 each of these modes. 831 Host--+ +-------- ISP1 832 | DSL link | 833 +----- CPE ---------------- NAS ----+-------- ISP2 834 | (Bridge/NAPT/Router) | 835 Host--+ +-------- ISP3 837 <------- customer --> <------- NAP -----> <---- ISP ---> 838 premise 840 Figure 7: DSL Model 842 The devices at the customer premises have been shown as "hosts" in 843 the above network. 845 DSL networks are protected by physical means. Eavesdropping and 846 spoofing attacks are prevented by keeping the unintended users 847 physically away from the network media. Therefore, generally 848 cryptographic protection of data traffic is not necessary. 849 Nevertheless, if enhanced security is deemed necessary for any 850 reason, IPsec-based access control can be enabled on DSL networks as 851 well by using the method described in [I-D.ietf-pana-ipsec]. 853 10.1.1 Bridging Mode 855 In the bridging mode, the CPE acts as a simple layer-2 bridge. The 856 hosts at the customer premises will function as clients to obtain 857 addresses from the NAS device by using DHCP or PPPoE. 859 If PPPoE is used, authentication is typically performed using CHAP or 860 MS-CHAP. 862 PANA will be applicable when the hosts use DHCP to obtain IP address. 863 DHCP does not support authentication of the devices on either side of 864 the DSL access line. In the simplest method of address assignment, 865 the NAS will allocate the IP address to a host with a lease time 866 reasonably sufficient to complete a full PANA based authentication 867 which will be triggered immediately after the address assignment. 868 The hosts will perform the PaC function and the NAS will perform the 869 PAA, EP and AR functions. 871 Host--+ 872 (PaC) | 873 +----- CPE ---------------- NAS ------------- ISP 874 | (Bridge) (PAA,EP,AR) 875 Host--+ 876 (PaC) 878 Figure 8: Bridge Mode 880 The DSL service provider's trunk network should not be accessible to 881 any host that has not successfully completed the PANA authentication 882 phase. 884 10.1.2 Router Mode 886 In this mode, the CPE acts as a router for the customer premises 887 network. The CPE itself may obtain the IP address using DHCP or be 888 configured with a static IP address. Once the CPE is authenticated 889 using PANA and is provided access to the service provider's network, 890 the NAS should begin exchanging routing updates with the CPE. All 891 devices at the customer premises will then have access to the service 892 provider's network. 894 Host--+ 895 | 896 +----- CPE ---------------- NAS ------------- ISP 897 | (Router, PaC) (PAA,EP,AR) 898 Host--+ 900 Figure 9: Router Mode 902 It is possible that both ends of the DSL link are configured with 903 static IP addresses. PANA-based mutual authentication of CPE and NAS 904 is desirable before data-traffic is exchanged between the customer 905 premises network and the service provider network. The CPE router 906 may also use NAPT (Network Address Port Tranlation). 908 10.1.3 PANA and Dynamic Internet Service Provider Selection 910 In some installations, a NAS device is shared by multiple service 911 providers. Each service provider configures the NAS with a certain 912 IP address space. 914 The devices at the customer premises network indicate their choice of 915 service provider and the NAS chooses the IP address from the 916 appropriate service provider's pool. In many cases, the address is 917 assigned not by the NAS but by the AAA server that is managed fully 918 by the service provider. 920 This simplifies the management of the DSL access network as it is not 921 always necessary to configure each DSL access line with the service 922 provider's identity. The service provider is chosen dynamically by 923 the CPE device. This is typically known as "dynamic Internet Service 924 Provider selection". The AAA function is usually overloaded to 925 perform dynamic ISP selection. 927 If the CPE device uses a PPP based protocol (PPP or PPPoE), the ISP 928 is chosen by mapping the username field of a CHAP response to a 929 provider. 931 If the CPE uses DHCP, the 'client-id' field of the DHCP-discover or 932 DHCP-request packet is mapped to the provider. 934 10.1.3.1 Selection as Part of the DHCP protocol or an Attribute of DSL 935 Access Line 937 The ISP selection, therefore the IP address pool, can be conveyed 938 based on the DHCP protocol exchange (as explained earlier), or by 939 associating the DSL access line to the service provider before the 940 PANA authentication begins. When any of these schemes is used, the 941 IP address used during PANA authentication (PRPA) is the ultimate IP 942 address and it does not have to be changed upon successful 943 authorization. 945 10.1.3.2 Selection as Part of the PANA Authentication 947 The ISP selection of the client can be explicitly conveyed during the 948 PANA authentication. In that case, the client can be assigned a 949 temporary IP address (PRPA) prior to PANA authentication. This IP 950 address might be obtained via DHCP with a lease reasonably long to 951 complete PANA authentication, or via the zeroconf technique 952 [I-D.ietf-zeroconf-ipv4-linklocal]. In either case, successful PANA 953 authentication signalling prompts the client to obtain a new (long 954 term) IP address via DHCP. This new IP address (POPA) replaces the 955 previously allocated temporary IP address. 957 10.2 Wireless LAN Example 959 This section describes how PANA can be used on WLAN networks. In 960 most common WLAN deployments the IP addresses are dynamically 961 configured. Therefore this section does not cover the scenarios 962 where the IP address is statically configured. There are two models 963 depending on which layer security is bootstrapped from PANA 964 authentication, L2 or L3. When PANA authentication is used for 965 bootstrapping L3 security, L2 security is not necessarily to exist 966 even after PANA authentication. Instead, IPsec-based data traffic 967 protection is bootstrapped from PANA. The PAA can indicate the PaC 968 as to whether L2 or L3 protection is needed, by including a 969 Protection-Capability AVP in PANA-Bind-Request message. In both 970 cases, the most common deployment would be illustrated in Figure 10, 971 where EP is typically co-located with AP (access point) when PANA is 972 used for bootstrapping L2 security or with AR when PANA is used for 973 bootstrapping L3 security. 975 +-----+ 976 |AP/EP|----+ 977 +-----+ | 978 | 979 +---+ +-----+ | +---------+ 980 |PaC| |AP/EP|----+----|AR/PAA/EP|----- Internet 981 +---+ +-----+ | +---------+ 982 | 983 +-----+ | 984 |AP/EP|----+ 985 +-----+ 987 Figure 10: PANA Wireless LAN Model 989 10.2.1 PANA with Bootstrapping IPsec 991 In this model, data traffic is protected by using IPsec tunnel mode 992 SA and an IP address is used as the device identifier of PaC (see 993 Section 5 for details). Some or all of AP, DHCPv4 Server (including 994 PRPA DHCPv4 Server and IPsec-TIA DHCPv4 Server), DHCPv6 Server, PAA 995 and EP may be co-located in a single device. EP is always co-located 996 with AR and may be co-located with PAA. When EP and PAA are not 997 co-located, PAA-EP protocol is used for communication between PAA and 998 EP. 1000 Note that for all of the cases described in this section, PBR 1001 (PANA-Bind-Request) and PBA (PANA-Bind-Answer) exchange in PANA 1002 [I-D.ietf-pana-pana] should occur after installing the authorization 1003 parameter to AR, so that IKE can be performed immediately after PANA 1004 is successfully completed. 1006 10.2.1.1 IPv4 1008 Case A: IPsec-TIA obtained by using DHCPv4 1010 In this case, the IPsec-TIA and IPsec-TOA are the same as the 1011 PRPA, and all configuration information including the IP address 1012 is obtained by using DHCPv4 [RFC2131]. No POPA is configured. 1013 Case A is the simplest compared to other ones and might be used in 1014 a network where IP address depletion attack on DHCP is not a 1015 significant concern. The PRPA needs to be a routable address 1016 unless NAT is performed on AR. 1018 PaC AP DHCPv4 Server PAA EP(AR) 1019 | Link-layer | | | | 1020 | association| | | | 1021 |<---------->| | | | 1022 | | | | | 1023 | DHCPv4 | | | 1024 |<-----------+------------>| | | 1025 | | | | | 1026 |PANA(Discovery and Initial Handshake phase | 1027 | & PAR-PAN exchange in Authentication phase) | 1028 |<-----------+-------------------------->| | 1029 | | | | | 1030 | | | |Authorization| 1031 | | | |[IKE-PSK, | 1032 | | | | PaC-DI, | 1033 | | | | Session-Id] | 1034 | | | |------------>| 1035 | | | | | 1036 |PANA(PBR-PBA exchange in Authentication phase) | 1037 |<-----------+-------------------------->| | 1038 | | | | | 1039 | | IKE | | 1040 |<-----------+---------------------------------------->| 1041 | | | | | 1042 | | | | | 1044 Figure 11: An example case for configuring IPsec-TIA by using 1045 DHCPv4 1047 Case B: IPsec-TIA obtained by using IKE 1049 In this case, the PRPA is obtained by using DHCPv4 and used as 1050 IPsec-TOA. The POPA is obtained by using IKE (via a Configuration 1051 Payload exchange or equivalent) and used as IPsec-TIA. 1053 Case C: IPsec-TIA obtained by using RFC3456 1055 Like Case B, the PRPA is obtained by using DHCPv4. The difference 1056 is that the POPA (eventually used as IPsec-TIA) and other 1057 configuration parameter are configured by running DHCPv4 over a 1058 special IPsec tunnel mode SA [RFC3456]. Note that the PRPA DHCPv4 1059 Server and IPsec-TIA DHCPv4 Server may be co-located on the same 1060 node. 1061 Note: this case may be used only when IKEv1 is used as the IPsec 1062 key management protocol (IKEv2 does not seem to support RFC3456 1063 equivalent case). 1065 PaC AP DHCPv4 Server PAA EP(AR) 1066 | Link-layer | | | | 1067 | association| | | | 1068 |<---------->| | | | 1069 | | | | | 1070 | DHCPv4 | | | 1071 |<-----------+------------>| | | 1072 | | | | | 1073 |PANA(Discovery and initial handshake phase | 1074 | & PAR-PAN exchange in authentication phase) | 1075 |<-----------+-------------------------->| | 1076 | | | | 1077 | | |Authorization| 1078 | | |[IKE-PSK, | 1079 | | | PaC-DI, | 1080 | | | Session-Id] | 1081 | | |------------>| 1082 | | | | 1083 |PANA(PBR-PBA exchange in authentication phase) | 1084 |<-----------+-------------------------->| | 1085 | | | | 1086 | | IKE | | 1087 | (with Configuration Payload exchange or equivalent) | 1088 |<-----------+---------------------------------------->| 1089 | | | | 1090 | | | | 1092 Figure 12: An example case for IPsec-TIA obtained by using IKE 1093 PRPA 1094 PaC AP DHCPv4 Server PAA 1095 | Link-layer | | | 1096 | association| | | 1097 |<---------->| | | 1098 | | | | 1099 | DHCPv4 | | 1100 |<-----------+-------->| | 1101 | | | 1102 |PANA(Discovery and initial handshake phase 1103 | & PAR-PAN exchange in authentication phase) 1104 |<-----------+-------------------------->| 1105 | | | 1106 | | EP(AR) | 1107 | | |Authorization| 1108 | | |[IKE-PSK, | 1109 | | | PaC-DI, | 1110 | | | Session-Id] | 1111 | | |<------------| 1112 | | | | 1113 |PANA(PBR-PBA exchange in authentication phase) 1114 |<-----------+-------------------------->| 1115 | | | 1116 | IKEv1 phase I & II | 1117 | (to create DHCP SA) | 1118 |<-----------+------------>| 1119 | | | 1120 | DHCP over DHCP SA | 1121 |<-----------+------------>| 1122 | | | 1123 | IKEv1 phase II | 1124 | (to create IPsec SA for data traffic) 1125 |<-----------+------------>| 1127 Figure 13: An example case for configuring IPsec-TIA by using 1128 RFC3456 1130 10.2.1.2 IPv6 1132 In the case of IPv6, the IPsec-TOA (PRPA) is the IPv6 link-local 1133 address. IPsec-TIA (POPA) is obtained by using Configuration Payload 1134 exchange of IKE version 2 (Note that there is no standard method for 1135 configuring IPsec-TIA in IKEv1). Other configuration information may 1136 be obtained in the same Configuration Payload exchange or may be 1137 obtained by running an additional DHCPv6. 1139 PaC AP EP(AR) PAA 1140 | Link-layer | | | 1141 | association| | | 1142 |<---------->| | | 1143 | | | | 1144 | | | | 1145 |PANA(Discovery and Initial Handshake phase 1146 | & PAR-PAN exchange in Authentication phase) 1147 |<-----------+-------------------------->| 1148 | | | | 1149 | | | | 1150 | | |Authorization| 1151 | | |[IKE-PSK, | 1152 | | | PaC-DI, | 1153 | | | Session-Id] | 1154 | | |<------------| 1155 | | | | 1156 |PANA(PBR-PBA exchange in authentication phase) 1157 |<-----------+-------------------------->| 1158 | | | | 1159 | IKEv2 | | 1160 |(w/Configuration Payload | | 1161 | exchange to obtain IPsec-TIA) | 1162 |<-----------+------------>| | 1163 | | | | 1165 Figure 14: An example sequence for configuring IPsec-TIA in IPv6 1167 10.2.2 PANA with Bootstrapping WPA/IEEE 802.11i 1169 In this model, PANA is used for authentication and authorization, and 1170 L2 ciphering is used for access control, the latter is enabled by the 1171 former. The L2 ciphering is based on using PSK (Pre-Shared Key) mode 1172 of WPA (Wi-Fi Protected Access) [WPA] or IEEE 802.11i [802.11i], 1173 which is derived from the EAP MSK as a result of successful PANA 1174 authentication. In this document, the pre-shared key shared between 1175 station and AP is referred to as PMK (Pair-wise Master Key). In this 1176 model, MAC address is used as the device identifier in PANA. 1178 This model allows the separation of PAA from APs (EPs). A typical 1179 purpose of using this model is to reduce AP management cost by 1180 allowing physical separation of RADIUS/Diameter client from access 1181 points, where AP management can be a significant issue when deploying 1182 a large number of access points. 1184 By bootstrapping PSK mode of WPA and IEEE 802.11i from PANA it is 1185 also possible to improve wireless LAN security by providing protected 1186 disconnection procedure at L3. 1188 This model does not require any change in the current WPA and IEEE 1189 802.11i specifications. This also means that PANA doesn't provide 1190 any L2 security features beyond those already provided for in WPA and 1191 IEEE 802.11i. 1193 The IEEE 802.11 specification [802.11] allows Class 1 data frames to 1194 be received in any state. Also, the latest version of IEEE 802.11i 1195 [802.11i] optionally allows higher-layer data traffic to be received 1196 and processed on their IEEE 802.1X Uncontrolled Ports. This feature 1197 allows processing IP-based traffic (such as ARP, IPv6 neighbor 1198 discovery, DHCP, and PANA) on IEEE 802.1X Uncontrolled Port prior to 1199 client authentication. (Note: WPA and its corresponding version of 1200 IEEE 802.11i draft do not explicitly define this operation, so it may 1201 be safer not to use this in WPA). 1203 Until the PaC is successfully authenticated, only a selected type of 1204 IP traffic is allowed over the IEEE 802.1X Uncontrolled Port. Any 1205 other IP traffic is dropped on the AP without being forwarded to the 1206 DS (Distribution System). Upon successful PANA authentication, the 1207 traffic switches to the controlled port. Host configuration, 1208 including obtaining an (potentially new) IP address, takes place on 1209 this port. Usual DHCP-based, and also in the case of IPv6 stateless 1210 autoconfiguration, mechanism is available to the PaC. After this 1211 point, the rest of the IP traffic, including PANA exchanges, are 1212 processed on the controlled port. 1214 When a PaC does not have a PMK for the AP, the following procedure is 1215 taken: 1217 1. The PaC associates with the AP. 1219 2. The PaC configures a PRPA by using DHCP (in the case of IPv4) or 1220 configures a link-local address (in the case of IPv6), and then 1221 runs PANA by using the address. 1223 3. Upon successful authentication, the PaC obtains a PMK for each AP 1224 controlled by the PAA. 1226 4. The AP initiates IEEE 802.11i 4-way handshake to establish a PTK 1227 (Pair-wise Transient Key) with the PaC, by using the PMK. 1229 5. The PaC obtains a POPA by using any method that the client 1230 normally uses. 1232 10.2.3 Capability Discovery 1234 When a PaC is a mobile, there may be multiple APs available in its 1235 vicinity. Each AP are connected to one of the following types of 1236 access networks. 1238 a) Free access network 1240 There is no IEEE 802.1X or PANA authentication in this access 1241 network. 1243 b) PANA-secured network 1245 There is PANA authentication in this access network. 1247 c) IEEE 802.1X-secured network 1249 There is IEEE 802.1X authentication in this access network. 1251 Type (c) is distinguished from others by checking the capability 1252 information advertised in IEEE 802.11 Beacon frames (IEEE 802.11i 1253 defines RSN Information Element for this purpose). Types (a) and (b) 1254 are not distinguishable until the PaC associates with the AP, get an 1255 IP address, and engage in PANA discovery. The default PaC behavior 1256 would be to act as if this is a free network and attempt DHCP. This 1257 would be detected by the access network and trigger unsolicited PANA 1258 discovery. A type (b) network would send a PANA-Start-Request to the 1259 client and block general purpose data traffic. This helps the client 1260 discover whether the network is type (a) or type (b). Or if the PaC 1261 is pre-provisioned with the information that this is a PANA enabled 1262 network, it can attempt PAA discovery immediately. The PaC behavior 1263 after connecting to an AP of type (b) network is described in Section 1264 10.2, Section 10.2.1 and Section 10.2.2. 1266 11. Open Issue 1268 Certain combination of network environments and timing cases may 1269 require further considerations. 1271 If PaC changes access point right after a successful PANA 1272 authorization but before POPA configuration, it might be confused 1273 whether the new IP address configured via the new access point is the 1274 POPA of the ongoing session or a PRPA of a new session. When the 1275 PRPA and POPA types or configuration mechanisms are different this is 1276 not a problem. One possible combination where such clues are not 1277 available is when PaC moves from a Case A of Section 10.2.1.1 1278 (IPsec-TIA obtained by using DHCPv4) network to a Case D of Appendix 1279 A.1 (IPsec-TIA obtained by using RFC3118) network. 1281 In another example, when PaC switches from one wired Ethernet hub to 1282 another (without the use of bootstrapping IPsec) before configuring 1283 the POPA. In this case, PaC may not able to know whether an obtained 1284 address is the POPA in the same subnet or a PRPA in a new subnet. 1286 For these cases, a mechanism to remove the ambiguity (PRPA vs. POPA) 1287 may need to be defined. 1289 12. Acknowledgments 1291 We would like to thank Bernard Aboba, Yacine El Mghazli, Randy Turner 1292 and Hannes Tschofenig for their valuable comments. 1294 13. References 1296 13.1 Normative References 1298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1299 Requirement Levels", BCP 14, RFC 2119, March 1997. 1301 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. 1302 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1303 3748, June 2004. 1305 [I-D.ietf-zeroconf-ipv4-linklocal] 1306 Aboba, B., "Dynamic Configuration of Link-Local IPv4 1307 Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in 1308 progress), July 2004. 1310 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1311 Autoconfiguration", RFC 2462, December 1998. 1313 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1314 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1315 1998. 1317 [RFC3484] Draves, R., "Default Address Selection for Internet 1318 Protocol version 6 (IPv6)", RFC 3484, February 2003. 1320 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1321 (IKE)", RFC 2409, November 1998. 1323 [I-D.ietf-ipsec-ikev2] 1324 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1325 draft-ietf-ipsec-ikev2-14 (work in progress), June 2004. 1327 [I-D.ietf-pana-snmp] 1328 Mghazli, Y., Ohba, Y. and J. Bournelle, "SNMP usage for 1329 PAA-2-EP interface", draft-ietf-pana-snmp-00 (work in 1330 progress), April 2004. 1332 [I-D.ietf-pana-pana] 1333 Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 1334 Yegin, "Protocol for Carrying Authentication for Network 1335 Access (PANA)", draft-ietf-pana-pana-04 (work in 1336 progress), May 2004. 1338 [I-D.ietf-pana-ipsec] 1339 Parthasarathy, M., "PANA enabling IPsec based Access 1340 Control", draft-ietf-pana-ipsec-03 (work in progress), May 1341 2004. 1343 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1344 M. Carney, "Dynamic Host Configuration Protocol for IPv6 1345 (DHCPv6)", RFC 3315, July 2003. 1347 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 1348 2131, March 1997. 1350 [RFC3456] Patel, B., Aboba, B., Kelly, S. and V. Gupta, "Dynamic 1351 Host Configuration Protocol (DHCPv4) Configuration of 1352 IPsec Tunnel Mode", RFC 3456, January 2003. 1354 13.2 Informative References 1356 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 1357 Protocol (v3): Technical Specification", RFC 3377, 1358 September 2002. 1360 [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, 1361 "Remote Authentication Dial In User Service (RADIUS)", RFC 1362 2865, June 2000. 1364 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. 1365 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 1367 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 1368 E. Lear, "Address Allocation for Private Internets", BCP 1369 5, RFC 1918, February 1996. 1371 [I-D.ietf-eap-netsel-problem] 1372 Arkko, J. and B. Aboba, "Network Discovery and Selection 1373 Problem", draft-ietf-eap-netsel-problem-00 (work in 1374 progress), January 2004. 1376 [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", 1377 RFC 2486, January 1999. 1379 [I-D.ietf-pana-requirements] 1380 Yegin, A. and Y. Ohba, "Protocol for Carrying 1381 Authentication for Network Access (PANA)Requirements", 1382 draft-ietf-pana-requirements-08 (work in progress), June 1383 2004. 1385 [I-D.ietf-aaa-eap] 1386 Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible 1387 Authentication Protocol (EAP) Application", 1388 draft-ietf-aaa-eap-08 (work in progress), June 2004. 1390 [I-D.yegin-eap-boot-rfc3118] 1391 Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping 1392 RFC3118 Delayed DHCP Authentication Using EAP-based 1393 Network Access Authentication", 1394 draft-yegin-eap-boot-rfc3118-00 (work in progress), 1395 February 2004. 1397 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 1398 Messages", RFC 3118, June 2001. 1400 [I-D.josefsson-pppext-eap-tls-eap] 1401 Josefsson, S., Palekar, A., Simon, D. and G. Zorn, 1402 "Protected EAP Protocol (PEAP)", 1403 draft-josefsson-pppext-eap-tls-eap-07 (work in progress), 1404 October 2003. 1406 [I-D.ietf-pppext-eap-ttls] 1407 Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS 1408 Authentication Protocol (EAP-TTLS)", 1409 draft-ietf-pppext-eap-ttls-04 (work in progress), April 1410 2004. 1412 [I-D.tschofenig-eap-ikev2] 1413 Tschofenig, H. and D. Kroeselberg, "EAP IKEv2 Method 1414 (EAP-IKEv2)", draft-tschofenig-eap-ikev2-03 (work in 1415 progress), February 2004. 1417 [DSL] DSL Forum Architecture and Transport Working Group, "DSL 1418 Forum TR-058 Multi-Service Architecture and Framework 1419 Requirements", September 2003. 1421 [802.11i] Institute of Electrical and Electronics Engineers, "Draft 1422 supplement to standard for telecommunications and 1423 information exchange between systems - lan/man specific 1424 requirements - part 11: Wireless medium access control 1425 (mac) and physical layer (phy) specifications: 1426 Specification for enhanced security", IEEE 802.11i/D10.0, 1427 2004. 1429 [802.11] Institute of Electrical and Electronics Engineers, 1430 "Information technology - telecommunications and 1431 information exchange between systems - local and 1432 metropolitan area networks - specific requirements part 1433 11: Wireless lan medium access control (mac) and physical 1434 layer (phy) specifications", IEEE Standard 802.11, 1435 1999(R2003). 1437 [WPA] The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-Fi 1438 WPA v2.0, 2003. 1440 Authors' Addresses 1442 Prakash Jayaraman 1443 Network Equipment Technologies, Inc. 1444 6900 Paseo Padre Parkway 1445 Fremont, CA 94555 1446 USA 1448 Phone: +1 510 574 2305 1449 EMail: prakash_jayaraman@net.com 1451 Rafa Marin Lopez 1452 University of Murcia 1453 30071 Murcia 1454 Spain 1456 EMail: rafa@dif.um.es 1458 Yoshihiro Ohba 1459 Toshiba America Research, Inc. 1460 1 Telcordia Drive 1461 Piscateway, NJ 08854 1462 USA 1464 Phone: +1 732 699 5365 1465 EMail: yohba@tari.toshiba.com 1467 Mohan Parthasarathy 1468 Nokia 1469 313 Fairchild Drive 1470 Mountain View, CA 94043 1471 USA 1473 Phone: +1 408 734 8820 1474 EMail: mohanp@sbcglobal.net 1476 Alper E. Yegin 1477 Samsung Advanced Institute of Technology 1478 75 West Plumeria Drive 1479 San Jose, CA 95134 1480 USA 1482 Phone: +1 408 544 5656 1483 EMail: alper.yegin@samsung.com 1485 Appendix A. Other Possible Cases for PANA with Bootstrapping IPsec in 1486 Wireless LAN 1488 This section describes other possible cases for PANA with 1489 Bootstrapping IPsec in wireless LAN environments. 1491 Appendix A.1 IPv4 1493 Case D: IPsec-TIA obtained by using RFC3118 1495 In this case, the POPA is configured and used as both IPsec-TIA 1496 and IPsec-TOA. The IPsec-TIA is assigned by using RFC3118 1497 (authenticated DHCP) [RFC3118] before running IKE. The DHCP-PSK 1498 needed for authenticated DHCP is distributed from the PAA to the 1499 POPA DHCPv4 server by using the method specified in 1500 [I-D.yegin-eap-boot-rfc3118]. The PRPA is assigned by using 1501 DHCPv4 and may be assigned with a short lease period in order to 1502 provide some level of robustness against IP address depletion 1503 attack. The IPsec-TIA is bound to an IPsec SA by using specifying 1504 the IPsec-TIA as the SA Identification in IKEv1 phase II or IKEv2 1505 CREATE_CHILD_SA exchange as specified in [I-D.ietf-pana-ipsec]. 1506 Once the IPsec-TIA is obtained, the PANA re-authentication based 1507 on PUR (PANA-Update-Rquest) and PUA (PANA-Update-Answer) exchange 1508 is performed with using the obtained IPsec-TIA in order to inform 1509 PAA of the update of PaC-DI. The IKE procedure should occur after 1510 the PUR-PUA exchange procedure. The PaC unconfigures the PRPA 1511 immediately after the IPsec-TIA is obtained. 1513 PRPA 1514 PaC AP DHCPv4 Server PAA EP(AR) 1515 | Link-layer | | | | 1516 | association| | | | 1517 |<---------->| | | | 1518 | | | | | 1519 | DHCPv4 | | | 1520 |<-----------+--------->| | | 1521 | | | | | 1522 |PANA(Discovery and Initial Handshake phase | 1523 | & PAR-PAN exchange in Authentication phase) | 1524 |<-----------+-------------------------->| | 1525 | | | | 1526 | | | | 1527 | | POPA | | 1528 | | DHCPv4 Server |Authorization| 1529 | | |Authorization|[IKE-PSK, | 1530 | | |[DHCP-PSK, | PaC-DI, | 1531 | | | Session-Id] | Session-Id] | 1532 | | |<------------|------------>| 1533 | | | | | 1534 |PANA(PBR-PBA exchange in Authentication phase) | 1535 |<-----------+-------------------------->| | 1536 | | | | | 1537 | Authenticated DHCPv4 | | | 1538 | (RFC3118) | | | 1539 |<-----------+------------>| | | 1540 | | | | | 1541 | PANA(PUR-PUA exchange using POPA as PaC-DI) | 1542 |<-----------+-------------------------->| | 1543 | | | | | 1544 | | IKE | | 1545 |<-----------+---------------------------------------->| 1546 | | | | | 1547 | | | | | 1549 Figure 15: An example case for IPsec-TIA obtained by using RFC3118 1551 Appendix A.2 IPv6 1553 Case A: IPsec-TIA obtained by using DHCPv6 1555 This case is similar to Case A in IPv4, except that a link-local 1556 address is used as the PRPA and IPsec-TOA, and that the DHCPv6 1557 procedure can occur at any time after link-layer association and 1558 before IKE. 1560 This case is not recommended since there is an ambiguity on 1561 whether IPv6 Neighbor Discovery for the POPA should run on the 1562 physical interface or inside the IPsec tunnel or both. 1564 PaC AP DHCPv6 Server PAA EP(AR) 1565 | Link-layer | | | | 1566 | association| | | | 1567 |<---------->| | | | 1568 | | | | | 1569 | DHCPv6 | | | 1570 |<-----------+------------>| | | 1571 | | | | | 1572 |PANA(Discovery and Initial Handshake phase | 1573 | & PAR-PAN exchange in Authentication phase) | 1574 |<-----------+-------------------------->| | 1575 | | | | | 1576 | | | |Authorization| 1577 | | | |[IKE-PSK, | 1578 | | | | PaC-DI, | 1579 | | | | Session-Id] | 1580 | | | |------------>| 1581 | | | | | 1582 |PANA(PBR-PBA exchange in Authentication phase) | 1583 |<-----------+-------------------------->| | 1584 | | | | | 1585 | | IKE | | 1586 |<-----------+---------------------------------------->| 1587 | | | | | 1588 | | | | | 1590 Figure 16: An example case for IPsec-TIA obtained by using DHCPv6 1592 Case B: IPsec-TIA obtained by using IPv6 stateless address 1593 autoconfiguration 1595 In this case, the IPsec-TOA (link-local address) and IPsec-TIA 1596 (global address) are configured through IPv6 stateless address 1597 autoconfiguration before running IKE. Other configuration 1598 information can be obtained by using several methods including 1599 authenticated DHCPv6, Configuration Payload exchange and DHCPv6 1600 over IPsec SA. 1601 This case is not recommended for the same reason as Case A of 1602 IPv6. 1604 PaC AP PAA EP(AR) 1605 | Link-layer | | | 1606 | association| | | 1607 |<---------->| | | 1608 | | | | 1609 | | | | 1610 |PANA(Discovery and Initial Handshake phase | 1611 | & PAR-PAN exchange in Authentication phase) | 1612 |<-----------+-------------------------->| | 1613 | | | | 1614 | | |Authorization| 1615 | | |[IKE-PSK, | 1616 | | | PaC-DI, | 1617 | | | Session-Id] | 1618 | | |------------>| 1619 | | | | 1620 |PANA(PBR-PBA exchange in Authentication phase) | 1621 |<-----------+-------------------------->| | 1622 | | | | 1623 | IPv6 stateless address autoconfiguration | 1624 | (can occur at any time before Association and IKEv2) | 1625 |<-----------+---------------------------------------->| 1626 | | | | 1627 | | IKEv2 | | 1628 |<-----------+---------------------------------------->| 1629 | | | | 1631 Figure 17: An example sequence for IPsec-TIA obtained by using 1632 IPv6 stateless address autoconfiguration 1634 Case C: IPsec-TIA obtained by using authenticated DHCPv6 1635 This case is similar to Case C of IPv4, except that a link-local 1636 address is used as the PRPA, and that there is no need for 1637 additional PUR-PUA exchange to update the PaC-DI. 1639 PaC AP DHCPv6 Server PAA EP(AR) 1640 | Link-layer | | | | 1641 | association| | | | 1642 |<---------->| | | | 1643 | | | | | 1644 | | | | | 1645 |PANA(Discovery and Initial Handshake phase | 1646 | & PAR-PAN exchange in Authentication phase) | 1647 |<-----------+-------------------------->| | 1648 | | | | | 1649 | | |Authorization|Authorization| 1650 | | |[DHCP-PSK, |[IKE-PSK, | 1651 | | | Session-Id] | PaC-DI, | 1652 | | | | Session-Id] | 1653 | | |<------------|------------>| 1654 | | | | | 1655 |PANA(PBR-PBA exchange in Authentication phase) | 1656 |<-----------+-------------------------->| | 1657 | | | | | 1658 | Authenticated DHCPv6 | | | 1659 |<-----------+------------>| | | 1660 | | | |Authorization| 1661 | | | | [IKE-PSK, | 1662 | | | | PaC-DI, | 1663 | | | | Session-Id]| 1664 | | | |------------>| 1665 | | IKE | | 1666 |<-----------+---------------------------------------->| 1667 | | | | | 1668 | | | | | 1670 Figure 18: An example case for configuring IPsec-TIA by using 1671 authenticated DHCPv6 1673 Intellectual Property Statement 1675 The IETF takes no position regarding the validity or scope of any 1676 Intellectual Property Rights or other rights that might be claimed to 1677 pertain to the implementation or use of the technology described in 1678 this document or the extent to which any license under such rights 1679 might or might not be available; nor does it represent that it has 1680 made any independent effort to identify any such rights. Information 1681 on the procedures with respect to rights in RFC documents can be 1682 found in BCP 78 and BCP 79. 1684 Copies of IPR disclosures made to the IETF Secretariat and any 1685 assurances of licenses to be made available, or the result of an 1686 attempt made to obtain a general license or permission for the use of 1687 such proprietary rights by implementers or users of this 1688 specification can be obtained from the IETF on-line IPR repository at 1689 http://www.ietf.org/ipr. 1691 The IETF invites any interested party to bring to its attention any 1692 copyrights, patents or patent applications, or other proprietary 1693 rights that may cover technology that may be required to implement 1694 this standard. Please address the information to the IETF at 1695 ietf-ipr@ietf.org. 1697 Disclaimer of Validity 1699 This document and the information contained herein are provided on an 1700 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1701 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1702 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1703 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1704 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1705 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1707 Copyright Statement 1709 Copyright (C) The Internet Society (2004). This document is subject 1710 to the rights, licenses and restrictions contained in BCP 78, and 1711 except as set forth therein, the authors retain all their rights. 1713 Acknowledgment 1715 Funding for the RFC Editor function is currently provided by the 1716 Internet Society.