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