idnits 2.17.1 draft-ietf-pana-requirements-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MIPv4' is mentioned on line 130, but not defined == Missing Reference: 'NAI' is mentioned on line 159, but not defined == Missing Reference: 'RDISC' is mentioned on line 233, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 467, but not defined == Missing Reference: 'D1' is mentioned on line 703, but not defined == Missing Reference: 'D2' is mentioned on line 707, but not defined == Unused Reference: '8021X' is defined on line 549, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 559, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-pana-usage-scenarios (ref. 'USAGE') -- No information found for draft-ietf-pana-threats - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SECTHREAT' == Outdated reference: A later version (-09) exists of draft-ietf-eap-rfc2284bis-04 -- Obsolete informational reference (is this intentional?): RFC 2716 (ref. 'EAPTLS') (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. 'MIPV4') (Obsoleted by RFC 5944) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-21 -- Obsolete informational reference (is this intentional?): RFC 3012 (ref. 'MNAAA') (Obsoleted by RFC 4721) -- Obsolete informational reference (is this intentional?): RFC 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF PANA Working Group Alper E. Yegin, Editor 3 INTERNET-DRAFT Yoshihiro Ohba 4 Expires: December 2003 Reinaldo Penno 5 George Tsirtsis 6 Cliff Wang 7 June 2003 9 Protocol for Carrying Authentication for 10 Network Access (PANA) Requirements 11 draft-ietf-pana-requirements-07.txt 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 It is expected that future IP devices will have a variety of access 37 technologies to gain network connectivity. Currently there are 38 access-specific mechanisms for providing client information to the 39 network for authentication and authorization purposes. In addition 40 to being limited to specific access media (e.g., 802.1X for IEEE 802 41 links), some of these protocols are limited to specific network 42 topologies (e.g., PPP for point-to-point links). The goal of this 43 document is to identify the requirements for a link-layer agnostic 44 protocol that allows a host and a network to authenticate each other 45 for network access. This protocol will run between a client's device 46 and an agent in the network where the agent might be a client of the 47 AAA infrastructure. 49 Table of Contents 51 Abstract..........................................................1 52 Table of Contents.................................................2 53 1. Introduction...................................................3 54 2. Key Words......................................................4 55 3. Terminology....................................................4 56 4. Requirements...................................................5 57 4.1. Authentication...............................................5 58 4.1.1. Authentication of Client...................................5 59 4.1.2. Authorization, Accounting and Access Control...............6 60 4.1.3. Authentication Backend.....................................7 61 4.1.4. Identifiers................................................7 62 4.2. IP Address Assignment........................................7 63 4.3. EAP Lower Layer Requirements.................................8 64 4.4. PAA-to-EP Protocol...........................................8 65 4.5. Network......................................................9 66 4.5.1. Multi-access...............................................9 67 4.5.2. Disconnect Indication......................................9 68 4.5.3. Location of PAA............................................9 69 4.5.4. Secure Channel............................................10 70 4.6. Interaction with Other Protocols............................10 71 4.7. Performance.................................................10 72 4.8. Congestion Control..........................................11 73 4.9. IP Version Independence.....................................11 74 4.10. Denial of Service Attacks..................................11 75 4.11. Client Identity Privacy....................................11 76 5. Security Considerations.......................................11 77 6. Acknowledgements..............................................11 78 7. References....................................................12 79 7.1. Normative References........................................12 80 7.2. Informative References......................................12 81 8. Authors' Addresses............................................13 82 9. Appendix......................................................14 83 10. Full Copyright Statement.....................................16 84 1. Introduction 86 Providing secure network access service requires access control 87 based on the authentication and authorization of the clients and the 88 access networks. Initial and subsequent client-to-network 89 authentication provides parameters that are needed to police the 90 traffic flow through the enforcement points. A protocol is needed to 91 carry authentication parameters between the client and the access 92 network. 94 Link-layer authentication mechanisms are used as enablers of secure 95 network access. A higher-layer authentication protocol is deemed 96 necessary when link-layer authentication mechanisms either do not 97 exist in terms of specifications/standards for a specific technology 98 or present deployment difficulties; when link-layer mechanisms are 99 not able to meet the overall authentication and security 100 requirements; or when multi-layer (e.g., link-layer and 101 network-layer) authentication is needed. Currently there is no 102 standard network-layer solution for authenticating clients for 103 network access. In the absence of such a solution, some inadequate 104 standards-based solutions are deployed or non-standard ad-hoc 105 solutions are invented. The usage scenarios Internet-Draft [USAGE] 106 describes the problem statement in detail. 108 The protocol design will be limited to defining a messaging protocol 109 (i.e., a carrier) that will allow authentication payload to be 110 carried between the host/client and an agent/server in the access 111 network for authentication and authorization purposes regardless of 112 the AAA infrastructure that may (or may not) reside on the network. 113 As a network-layer protocol, it will be independent of the 114 underlying access technologies. It will also be applicable to any 115 network topology. 117 The intent is not to invent new security protocols and mechanisms 118 but to reuse existing mechanisms such as EAP [EAP]. In particular, 119 the requirements do not mandate the need to define new 120 authentication protocols (e.g., EAP-TLS [EAPTLS]), key distribution 121 or key agreement protocols, or key derivation methods. The desired 122 protocol can be viewed as the front-end of the AAA protocol or any 123 other protocol/mechanisms the network is running at the background 124 to authenticate its clients. It will act as a carrier for an already 125 defined security protocol or mechanism. 127 As an example, the Mobile IP Working Group has already defined such 128 a carrier for Mobile IPv4 [MIPV4]. A Mobile IPv4 registration 129 request message is used as a carrier for authentication extensions 130 (MN-FA [MIPv4] or MN-AAA [MNAAA]) that allow a foreign agent to 131 authenticate mobile nodes before providing forwarding service. The 132 goal of PANA is similar in that it aims to define a network-layer 133 transport for authentication information; however, PANA will be 134 decoupled from mobility management and it will rely on other 135 specifications for the definition of authentication payloads. 137 This document defines the common terminology and identifies the 138 requirements of a protocol for PANA. These terminology and 139 requirements will be used to define and limit the scope of the work 140 to be done in this group. 142 2. Key Words 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [KEYWORDS]. 148 3. Terminology 150 PANA Client (PaC) 152 The client side of the protocol that resides in the host device 153 which is responsible for providing the credentials to prove its 154 identity for network access authorization. 156 PANA Client Identifier (PaCI) 158 The identifier that is presented by the PaC to the PAA for 159 network access authentication. A simple username and NAI [NAI] 160 are examples of PANA client identifiers. 162 Device Identifier (DI) 164 The identifier used by the network as a handle to control and 165 police the network access of a client. Depending on the access 166 technology, this identifier might contain any of IP address, 167 link-layer address, switch port number, etc. of a connected 168 device. 170 PANA Authentication Agent (PAA) 172 The access network side entity of the protocol whose 173 responsibility is to verify the credentials provided by a PANA 174 client and grant network access service to the device 175 associated with the client and identified by a DI. 177 Enforcement Point (EP) 179 A node on the access network where per-packet enforcement 180 policies (i.e., filters) are applied on the inbound 181 and outbound traffic of client devices. Information such as DI 182 and (optionally) cryptographic keys are provided by PAA per 183 client for constructing filters on the EP. 185 4. Requirements 187 4.1. Authentication 189 4.1.1. Authentication of Client 191 PANA MUST enable authentication of PaCs for network access. A PaC's 192 identity can be authenticated by verifying the credentials (e.g., 193 identifier, authenticator) supplied by one of the users of the 194 device or the device itself. PANA MUST only grant network access 195 service to the device identified by the DI, rather than granting 196 separate access to multiple simultaneous users of the device. Once 197 the network access is granted to the device, the methods used by the 198 device on arbitrating which one of its users can access the network 199 is outside the scope of PANA. 201 PANA MUST NOT define new security protocols or mechanisms. Instead, 202 it MUST be defined as a "carrier" for such protocols. PANA MUST 203 identify which specific security protocol(s) or mechanism(s) it can 204 carry (the "payload"). EAP [EAP] is a candidate protocol that 205 satisfies many of the requirements for authentication. PANA would be 206 a carrier protocol for EAP. If the PANA Working Group decides that 207 extensions to EAP are needed, it will define requirements for the 208 EAP WG instead of designing such extensions. 210 Providing authentication, integrity and replay protection for data 211 traffic after a successful PANA exchange is outside the scope of 212 this protocol. In networks where physical layer security is not 213 present, link-layer or network-layer ciphering (e.g., IPsec) can be 214 used to provide such security. These mechanisms require presence of 215 cryptographic keying material at PaC and EP. Although PANA does not 216 deal with key derivation or distribution, it enables this by the 217 virtue of carrying EAP and allowing appropriate EAP method 218 selection. Various EAP methods are capable of generating basic 219 keying material. The keying material produced by EAP methods cannot 220 be directly used with IPsec as it lacks the properties of an IPsec 221 SA (security association) which include secure cipher suite 222 negotiation, mutual proof of possession of keying material, 223 freshness of transient session keys, key naming, etc. These basic 224 (initial) EAP keys can be used with an IPsec key management protocol 225 like IKE to generate the required security associations. A separate 226 protocol, called secure association protocol, is required to 227 generate IPsec SAs based on the basic EAP keys. This protocol MUST 228 be capable of enabling IPsec-based access control on the EPs. IPsec 229 SAs MUST enable authentication, integrity and replay protection of 230 data packets as they are sent between the EP and PaC. 232 Providing a complete secure network access solution by also securing 233 router discovery [RDISC], neighbor discovery [NDISC], and address 234 resolution protocols [ARP] is outside the scope as well. 236 Some access networks might require or allow their clients to get 237 authenticated and authorized by the NAP (network access provider) 238 and ISP before the clients gain network access. NAP is the owner of 239 the access network who provides physical and link-layer connectivity 240 to the clients. PANA MUST be capable of enabling two independent 241 authentication operations (i.e., execution of two separate EAP 242 methods) for the same client. Determining the authorization 243 parameters as a result of two separate authentications is an 244 operational issue and therefore it is outside the scope of PANA. 246 Both the PaC and the PAA MUST be able to perform mutual 247 authentication for network access. Providing only the capability of 248 a PAA authenticating the PaC is not sufficient. Mutual 249 authentication capability is required in some environments but not 250 in all of them. For example, clients might not need to authenticate 251 the access network when physical security is available (e.g., 252 dial-up networks). 254 PANA MUST be capable of carrying out both periodic and on-demand 255 re-authentication. Both the PaC and the PAA MUST be able to initiate 256 both the initial authentication and the re-authentication process. 258 Certain types of service theft are possible when the DI is not 259 protected during or after the PANA exchange [SECTHREAT]. PANA MUST 260 have the capability to exchange DI securely between the PAC and PAA 261 where the network is vulnerable to man-in-the-middle attacks. While 262 PANA MUST provide such a capability, its utility relies on the use 263 of an authentication method that can generate keys for cryptographic 264 computations on PaC and PAA. 266 4.1.2. Authorization, Accounting and Access Control 268 After a device is authenticated using PANA, it MUST be authorized 269 for "network access." That is, the core requirement of PANA is to 270 verify the authorization of a PaC so that PaC's device may send and 271 receive any IP packets. It may also be possible to provide finer 272 granularity authorization, such as authorization for QoS or 273 individual services (e.g., http vs. ssh). However, while a backend 274 authorization infrastructure (e.g., Diameter) might provide such 275 indications to the PAA, explicit support for them is outside the 276 scope of PANA. For instance, PANA is not required to carry any 277 indication of which services are authorized for the authenticated 278 device. 280 Providing access control functionality in the network is outside the 281 scope of PANA. Client access authentication SHOULD be followed by 282 access control to make sure only authenticated and authorized 283 clients can send and receive IP packets via access network. Access 284 control can involve setting access control lists on the EPs. 285 Identification of clients that are authorized to access the network 286 is done by the PANA protocol exchange. If IPsec-based access control 287 is deployed in an access network, PaC and EPs should have the 288 required IPsec SA in place. Generating the IPsec SAs based on EAP 289 keys is outside the scope of PANA protocol. This transformation MUST 290 be handled by a separate secure association protocol (see section 291 4.1.1). 293 Carrying accounting data is outside the scope of PANA. 295 4.1.3. Authentication Backend 297 PANA protocol MUST NOT make any assumptions on the backend 298 authentication protocol or mechanisms. A PAA MAY interact with 299 backend AAA infrastructures such as RADIUS or Diameter, but it is 300 not a requirement. When the access network does not rely on an 301 IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use 302 a proprietary backend system, or rely on the information locally 303 stored on the authentication agents. 305 The interaction between the PAA and the backend authentication 306 entities is outside the scope of PANA. 308 4.1.4. Identifiers 310 PANA SHOULD allow various types of identifiers to be used as the 311 PaCI (e.g., username, NAI, FQDN, etc.). This requirement generally 312 relies on the client identifiers supported by various EAP methods. 314 PANA SHOULD allow various types of identifiers to be used as the DI 315 (e.g., IP address, link-layer address, port number of a switch, 316 etc.). 318 A PAA MUST be able to create a binding between the PaCI and the 319 associated DI upon successful PANA exchange. This can be achieved by 320 PANA communicating the PaCI and DI to the PAA during the protocol 321 exchange. The DI can be carried either explicitly as part of the 322 PANA payload, or implicitly as the source of the PANA message, or 323 both. Multi-access networks also require use of a cryptographic 324 protection along with DI filtering to prevent unauthorized access 325 [SECTHREAT]. The keying material required by the cryptographic 326 methods needs to be indexed by the DI. The binding between DI and 327 PaCI is used for access control and accounting in the network as 328 described in section 4.1.2. 330 4.2. IP Address Assignment 332 Assigning an IP address to the client is outside the scope of PANA. 333 PANA protocol design MAY require the PaC to configure an IP address 334 before using this protocol. Allocating IP addresses to 335 unauthenticated PaCs may create security vulnerabilities, such as IP 336 address depletion attacks on the access network [SECTHREAT]. IPv4 337 networks with limited address space are the main targets of such 338 attacks. Launching a successful attack that can deplete the 339 addresses in an IPv6 network is relatively harder. 341 This threat can be mitigated by allowing the protocol to run without 342 an IP address configured on the PaC (i.e., using unspecified source 343 address). Such a design choice might limit the re-use of existing 344 security mechanisms, and impose additional implementation 345 complexity. This trade off should be taken into consideration in 346 designing PANA. 348 4.3. EAP Lower Layer Requirements 350 The EAP protocol itself imposes various requirements on its 351 transport protocols. These requirements are based on the nature of 352 the EAP protocol, and they need to be satisfied for correct 353 operation. Please see [EAP] for the generic transport requirements 354 that MUST be satisfied by PANA as well. 356 4.4. PAA-to-EP Protocol 358 PANA does not assume that the PAA is always co-located with the 359 EP(s). Network access enforcement can be provided by one or more 360 nodes on the same IP subnet as the client (e.g., multiple routers), 361 or on another subnet in the access domain (e.g., gateway to the 362 Internet, depending on the network architecture). When the PAA and 363 the EP(s) are separated, there needs to be another transport for 364 client provisioning. This transport is needed to create access 365 control lists to allow authenticated and authorized clients' traffic 366 through the EPs. PANA Working Group will preferably identify an 367 existing protocol solution that allows the PAA to deliver the 368 authorization information to one or more EPs when the PAA is 369 separated from EPs. Possible candidates include but are not limited 370 to COPS, SNMP, Diameter, etc. This task is similar to what the 371 MIDCOM Working Group is trying to achieve, therefore some of that 372 working group's output might be useful here. 374 It is assumed that the communication between PAA and EP(s) is 375 secure. The objective of using a PAA-to-EP protocol is to provide 376 filtering rules to EP(s) for allowing network access of a recently 377 authenticated and authorized PaC. The chosen protocol MUST be 378 capable of carrying DI and cryptographic keys for a given PaC from 379 PAA to EP. Depending on the PANA protocol design, support for either 380 of the pull model (i.e., EP initiating the PAA-to-EP protocol 381 exchange per PaC) or the push model (i.e., PAA initiating the 382 PAA-to-EP protocol exchange per PaC), or both may be required. For 383 example, if the design is such that the EP allows the PANA traffic 384 to pass through even for unauthenticated PaCs, the EP should also 385 allow and expect the PAA to send the filtering information at the 386 end of a successful PANA exchange without the EP ever sending a 387 request. 389 4.5. Network 391 4.5.1. Multi-access 393 PANA MUST support PaCs with multiple interfaces, and networks with 394 multiple routers on multi-access links. In other words, PANA MUST 395 NOT assume the PaC has only one network interface, or the access 396 network has only one first hop router, or the PaC is using a 397 point-to-point link. 399 4.5.2. Disconnect Indication 401 PANA MUST NOT assume that the link is connection-oriented. Links may 402 or may not provide disconnect indication. Such notification is 403 desirable in order for the PAA to cleanup resources when a client 404 moves away from the network (e.g., inform the enforcement points 405 that the client is no longer connected). PANA SHOULD have a 406 mechanism to provide disconnect indication. PANA MUST be capable of 407 securing disconnect messages in order to prevent malicious nodes 408 from leveraging this extension for DoS attacks. 410 This mechanism MUST allow the PAA to be notified about the departure 411 of a PaC from the network. This mechanism MUST also allow a PaC to 412 be notified about the discontinuation of the network access service. 413 Access discontinuation can happen due to various reasons such as 414 network systems going down, or a change in access policy. 416 In case the clients cannot send explicit disconnect messages to the 417 PAA, PAA can still detect their departure by relying on periodic 418 authentication requests. 420 4.5.3. Location of PAA 422 The PAA and PaC MUST be exactly one IP hop away from each other. 423 That is, there must be no IP routers between the two. Note that this 424 does not mean they are on the same physical link. Bridging 425 techniques can place two nodes just exactly one IP hop away from 426 each other although they might be connected to separate physical 427 links. Furthermore, two nodes on the same IP subnet do not 428 necessarily satisfy this requirement, as they can be more than one 429 hop away from each other [MULTILINK]. A PAA can be on the NAS 430 (network access server) or WLAN access point or first hop router. 431 The use of PANA when the PAA is multiple IP hops away from the PaC 432 is outside the scope of PANA. 434 A PaC may or may not be pre-configured with the IP address of PAA. 435 Therefore the PANA protocol MUST define a dynamic discovery method. 436 Given that the PAA is one hop away from the PaC, there are a number 437 of discovery techniques that could be used (e.g., multicast or 438 anycast) by the PaC to find out the address of the PAA. 440 4.5.4. Secure Channel 442 PANA MUST NOT assume presence of a secure channel between the PaC 443 and the PAA. PANA MUST be able to provide authentication especially 444 in networks which are not protected against eavesdropping and 445 spoofing. PANA MUST enable protection against replay attacks on both 446 PaCs and PAAs. 448 This requirement partially relies on the EAP protocol and the EAP 449 methods carried over PANA. Use of EAP methods that provide mutual 450 authentication and key derivation/distribution is essential for 451 satisfying this requirement. EAP does not make a secure channel 452 assumption, and supports various authentication methods that can be 453 used in such environments. Additionally, PANA MUST ensure its design 454 does not contain vulnerabilities that can be exploited when it is 455 used over insecure channels. PANA MAY provide a secure channel by 456 deploying a two-phase authentication. The first phase can be used 457 for creation of the secure channel, and the second phase is for 458 client and network authentication. 460 4.6. Interaction with Other Protocols 462 Mobility management is outside the scope of PANA. However, PANA MUST 463 be able to co-exist and MUST NOT unintentionally interfere with 464 various mobility management protocols, such as Mobile IPv4 [MIPV4], 465 Mobile IPv6 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and 466 other standard protocols like IPv6 stateless address 467 auto-configuration [ADDRCONF] (including privacy extensions 468 [PRIVACY]), and DHCP [DHCPV4, DHCPV6]. It MUST NOT make any 469 assumptions on the protocols or mechanisms used for IP address 470 configuration of the PaC. 472 4.7. Performance 474 PANA design SHOULD give consideration to efficient handling of the 475 authentication process. This is important for gaining network access 476 with minimum latency. As an example, a method like minimizing the 477 protocol signaling by creating local security associations can be 478 used for this purpose. 480 4.8. Congestion Control 482 PANA MUST provide congestion control for the protocol messaging. 483 Under certain conditions PaCs might unintentionally get synchronized 484 when sending their requests to the PAA (e.g., upon recovering from a 485 power outage on the access network). The network congestion 486 generated from such events can be avoided by using techniques like 487 delayed initialization and exponential back off. 489 4.9. IP Version Independence 491 PANA MUST work with both IPv4 and IPv6. 493 4.10. Denial of Service Attacks 495 PANA MUST be robust against a class of DoS attacks such as blind 496 masquerade attacks through IP spoofing that would swamp the PAA, 497 causing it to spend resources and prevent network access by 498 legitimate clients. 500 4.11. Client Identity Privacy 502 Some clients might prefer hiding their identity from visited access 503 networks for privacy reasons. Providing identity protection for 504 clients is outside the scope of PANA. Note that some authentication 505 methods may already have this capability. Where necessary, identity 506 protection can be achieved by letting PANA carry such authentication 507 methods. 509 5. Security Considerations 511 This document identifies requirements for the PANA protocol design. 512 Due to the nature of this protocol most of the requirements are 513 security related. The actual protocol design is not specified in 514 this document. A thorough discussion on PANA security threats can be 515 found in PANA Threat Analysis and Security Requirements document 516 [SECTHREAT]. Security threats identified in that document are 517 already included in this general PANA requirements document. 519 6. Acknowledgements 521 We would like to thank Subir Das, Lionel Morand, Mohan 522 Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan 523 Forsberg, Francis Dupont, Bernard Aboba and the PANA Working Group 524 members for their valuable contributions to the discussions and 525 preparation of this document. 527 7. References 529 7.1. Normative References 531 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 532 Requirement Levels", RFC 2119, March 1997. 534 [USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem 535 Statement and Usage Scenarios for PANA", 536 draft-ietf-pana-usage-scenarios-06.txt, April 2003. Work in 537 progress. 539 [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security 540 Requirements", draft-ietf-pana-threats-04.txt, May 2003. Work in 541 progress. 543 [EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, H. Levkowetz, 544 "Extensible Authentication Protocol (EAP)", 545 draft-ietf-eap-rfc2284bis-04.txt, June 2003. Work in progress. 547 7.2. Informative References 549 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 550 Port Based Network Access Control", IEEE Std 802.1X-2001. 552 [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", 553 RFC 2716, October 1999. 555 [MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in 556 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work 557 in progress. 559 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 560 51, RFC 1661, July 1994. 562 [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC 563 3344, August 2002. 565 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 566 draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress. 568 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 569 Extensions", RFC3012, November 2000. 571 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 572 for IP Version 6 (IPv6)",RFC 2461, December 1998. 574 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 575 RFC 826, November 1982. 577 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 578 Mobile IPv4", November 2001. Work in progress. 580 [FMIPV6] R. Koodli (editor), et. al., "Fast Handovers for Mobile 581 IPv6", March 2003. Work in progress. 583 [DHCPV4] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 584 March 1997. 586 [DHCPV6] R. Droms (editor), et. al., "Dynamic Host Configuration 587 Protocol for IPv6 (DHCPv6)", November 2002. Work in progress. 589 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 590 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 592 8. Authors' Addresses 594 Alper E. Yegin 595 DoCoMo USA Labs 596 181 Metro Drive, Suite 300 597 San Jose, CA, 95110 598 USA 599 Phone: +1 408 451 4743 600 Email: alper@docomolabs-usa.com 602 Yoshihiro Ohba 603 Toshiba America Research, Inc. 604 P.O. Box 136 605 Convent Station, NJ, 07961-0136 606 USA 607 Phone: +1 973 829 5174 608 Email: yohba@tari.toshiba.com 610 Reinaldo Penno 611 Nortel Networks 612 600 Technology Park 613 Billerica, MA, 01821 614 USA 615 Phone: +1 978 288 8011 616 Email: rpenno@nortelnetworks.com 618 George Tsirtsis 619 Flarion Technologies 620 Bedminster One 621 135 Route 202/206 South 622 Bedminster, NJ, 07921 623 USA 624 Phone : +44 20 88260073 625 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 626 Cliff Wang 627 Smart Pipes 628 565 Metro Place South 629 Dublin, OH, 43017 630 USA 631 Phone: +1 614 923 6241 632 Email: cwang@smartpipes.com 634 9. Appendix 636 A. PANA Model 638 Following sub-sections capture the PANA usage model in different 639 network architectures with reference to its placement of logical 640 elements such as the PANA Client (PaC) and the PANA Authentication 641 Agent (PAA) with respect to the Enforcement Point (EP) and the 642 Access Router (AR). Four different scenarios are described in 643 following sub-sections. Note that PAA may or may not use AAA 644 infrastructure to verify the credentials of PaC to authorize network 645 access. 647 A.1. PAA Co-located with EP but Separated from AR 649 In this scenario (Figure 1), PAA is co-located with the enforcement 650 point on which access control is performed. PaCs communicate with 651 the PAA for network access on behalf of a device (D1, D2, etc.). 652 PANA in this case provides a means to transport the authentication 653 parameters from the PaC to PAA. PAA knows how to verify the 654 credentials. After verification, PAA sends back the success or 655 failure response to PaC. However, PANA does not play any explicit 656 role in performing access control except that it provides a hook to 657 access control mechanisms. This might be the case where PAA is 658 co-located with the access point (an IP-capable L2 access device). 660 PaC -----EP/PAA--+ 661 [D1] | 662 +------ AR ----- (AAA) 663 | 664 PaC -----EP/PAA--+ 665 [D2] 667 Figure 1: PAA co-located with EP but separated from AR. 669 A.2. PAA Co-located with AR but Separated from EP 671 Figure 2 describes this model. In this scenario, PAA is not 672 co-located with EPs but it is placed on the AR. Although we have 673 shown only one AR here there could be multiple ARs, one of which is 674 co-located with the PAA. PaC exchanges the same messages with PAA as 675 discussed earlier. The difference here is when the initial 676 authentication for the PaC succeeds, access control parameters have 677 to be distributed to respective enforcement points so that the 678 corresponding device on which PaC is authenticated can access to the 679 network. Similar to the earlier case, PANA does not play any 680 explicit role in performing access control except that it provides a 681 hook to access control mechanisms. However, a separate protocol is 682 needed between PAA and EP to carry access control parameters. 684 PaC ----- EP --+ 685 [D1] | 686 +------ AR/PAA --- (AAA) 687 | 688 PaC ----- EP --+ 689 [D2] 691 Figure 2: PAA co-located with AR but separated from EP. 693 A.3. PAA Co-located with EP and AR 695 In this scenario (Figure 3), PAA is co-located with the EP and AR on 696 which access control and routing are performed. PaC exchanges the 697 same messages with PAA and PAA performs similar functionalities as 698 before. PANA in this case also does not play any explicit role in 699 performing access control except that it provides a hook to access 700 control mechanisms. 702 PaC ----- EP/PAA/AR--+ 703 [D1] | 704 +-------(AAA) 705 | 706 PaC ----- EP/PAA/AR--+ 707 [D2] 709 Figure 3: PAA co-located with EP and AR. 711 A.4. PAA Separated from EP and AR 713 Figure 4 represents this model. In this scenario, PAA is neither 714 co-located with EPs nor with ARs. It still resides on the same IP 715 link as ARs. PaC does similar exchanges with PAA as discussed 716 earlier. Similar to model in A.2, after successful authentication, 717 access control parameters will be distributed to respective 718 enforcement points via a separate protocol and PANA does not play 719 any explicit role in this. 721 PaC ----- EP -----+--- AR ---+ 722 | | 723 PaC ----- EP --- -+ | 724 | | 725 PaC ----- EP -----+--- AR -- + ----(AAA) 726 | 727 +--- PAA 729 Figure 4: PAA separated from EP and AR. 731 10. Full Copyright Statement 733 "Copyright (C) The Internet Society (2003). All Rights Reserved. 734 This document and translations of it may be copied and furnished to 735 others, and derivative works that comment on or otherwise explain it 736 or assist in its implementation may be prepared, copied, published 737 and distributed, in whole or in part, without restriction of any 738 kind, provided that the above copyright notice and this paragraph 739 are included on all such copies and derivative works. However, this 740 document itself may not be modified in any way, such as by removing 741 the copyright notice or references to the Internet Society or other 742 Internet organizations, except as needed for the purpose of 743 developing Internet standards in which case the procedures for 744 copyrights defined in the Internet Standards process must be 745 followed, or as required to translate it into languages other than 746 English. 748 The limited permissions granted above are perpetual and will not be 749 revoked by the Internet Society or its successors or assigns. 751 This document and the information contained herein is provided on an 752 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 753 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 754 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 755 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 756 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.