idnits 2.17.1 draft-ietf-pana-requirements-06.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A PaC MAY NOT be pre-configured with the IP address of PAA. Therefore the PANA protocol MUST define a dynamic discovery method. Given that the PAA is one hop away from the PaC, there are a number of discovery techniques that could be used (e.g., multicast or anycast) by the PaC to find out the address of the PAA. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 133, but not defined == Missing Reference: 'NAI' is mentioned on line 163, but not defined == Missing Reference: 'RDISC' is mentioned on line 228, but not defined == Missing Reference: 'ADDRCONF' is mentioned on line 459, but not defined == Missing Reference: 'D1' is mentioned on line 724, but not defined == Missing Reference: 'D2' is mentioned on line 728, but not defined == Unused Reference: '8021X' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 582, 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-03 -- 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 (~~), 16 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Alper E. Yegin, Editor 3 INTERNET-DRAFT Yoshihiro Ohba 4 Date: May 2003 Reinaldo Penno 5 Expires: November 2003 George Tsirtsis 6 Cliff Wang 8 Protocol for Carrying Authentication for 9 Network Access (PANA) Requirements 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 It is expected that future IP devices will have a variety of access 36 technologies to gain network connectivity. Currently there are 37 access-specific mechanisms for providing client information to the 38 network for authentication and authorization purposes. In addition 39 to being limited to specific access media (e.g., 802.1X for IEEE 802 40 links), some of these protocols are limited to specific network 41 topologies (e.g., PPP for point-to-point links). The goal of the 42 PANA is to provide a link-layer agnostic and IPv4/IPv6 compatible 43 client-server protocol that allows a host to be authenticated for 44 network access. The protocol will run between a client's device and 45 an agent device in the network where the agent might be a client of 46 the AAA infrastructure. This document defines the common terminology 47 and identifies the requirements for PANA. 49 Table of Contents 51 Status of this Memo...............................................1 52 Abstract..........................................................1 53 Table of Contents.................................................2 54 1. Introduction...................................................3 55 2. Key Words......................................................4 56 3. Terminology....................................................4 57 4. Requirements...................................................5 58 4.1. Authentication...............................................5 59 4.1.1. Authentication of Client...................................5 60 4.1.2. Authorization, Accounting and Access Control...............6 61 4.1.3. Authentication Backend.....................................6 62 4.1.4. Identifiers................................................7 63 4.2. IP Address Assignment........................................7 64 4.3. EAP Lower Layer Requirements.................................8 65 4.4. PAA-to-EP Protocol...........................................8 66 4.5. Network......................................................8 67 4.5.1. Multi-access...............................................8 68 4.5.2. Disconnect Indication......................................9 69 4.5.3. Location of PAA............................................9 70 4.5.4. Secure Channel.............................................9 71 4.6. Interaction with Other Protocols............................10 72 4.7. Performance.................................................10 73 4.8. Congestion Control..........................................10 74 4.9. IP Version Independence.....................................10 75 4.10. Denial of Service Attacks..................................11 76 4.11. Client Identity Privacy....................................11 77 5. Security Considerations.......................................11 78 6. Change Log....................................................11 79 7. Acknowledgements..............................................12 80 8. References....................................................12 81 8.1. Normative References........................................12 82 8.2. Informative References......................................12 83 9. Authors' Addresses............................................13 84 10. Appendix.....................................................14 85 11. Full Copyright Statement.....................................16 87 1. Introduction 89 Providing secure network access service requires access control 90 based on the authentication and authorization of the clients and the 91 access networks. Initial and subsequent client-to-network 92 authentication provides parameters that are needed to police the 93 traffic flow through the enforcement points. A protocol is needed to 94 carry authentication methods between the client and the access 95 network. The IETF PANA Working Group has been chartered with the 96 goal of designing a network-layer access authentication protocol. 98 Link-layer authentication mechanisms are used as enablers of secure 99 network access. A higher-layer authentication is deemed necessary 100 when link-layer authentication mechanisms are either not available 101 for lack of technology or deployment difficulties; when link-layer 102 authentication mechanisms are not able to meet the overall 103 requirements; or when multi-layer (e.g., link-layer and 104 network-layer) authentication is needed. Currently there is no 105 standard network-layer solution for authenticating clients for 106 network access. In the absence of such a solution, some inadequate 107 standards-based solutions are deployed or non-standard ad-hoc 108 solutions are invented. The usage scenarios Internet-Draft [USAGE] 109 describes the problem statement in detail. 111 The protocol design will be limited to defining a client-server 112 messaging protocol (i.e., a carrier) that will allow authentication 113 payload to be carried between the host/client and an agent/server in 114 the access network for authentication and authorization purposes 115 regardless of the AAA infrastructure that may (or may not) reside on 116 the network. As a network-layer protocol, it will be independent of 117 the underlying access technologies. It will also be applicable to 118 any network topology. 120 The Working Group will not invent new security protocols and 121 mechanisms but instead it will use the existing mechanisms. In 122 particular, the Working Group will not define new authentication 123 protocols (e.g., EAP-TLS [EAPTLS]), key distribution or key 124 agreement protocols, or key derivation methods. The desired protocol 125 can be viewed as the front-end of the AAA protocol or any other 126 protocol/mechanisms the network is running at the background to 127 authenticate its clients. It will act as a carrier for an already 128 defined security protocol or mechanism. 130 As an example, the Mobile IP Working Group has already defined such 131 a carrier for Mobile IPv4 [MIPV4]. A Mobile IPv4 registration 132 request message is used as a carrier for authentication extensions 133 (MN-FA [MIPv4] or MN-AAA [MNAAA]) that allow a foreign agent to 134 authenticate mobile nodes before providing forwarding service. The 135 goal of PANA is similar in that it aims to define a network-layer 136 transport for authentication information; however, PANA will be 137 decoupled from mobility management and it will rely on other 138 specifications for the definition of authentication payloads. 140 This document defines the common terminology and identifies the 141 requirements of a protocol for PANA. These terminology and 142 requirements will be used to define and limit the scope of the work 143 to be done in this group. 145 2. Key Words 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [KEYWORDS]. 151 3. Terminology 153 PANA Client (PaC) 155 The entity wishing to obtain network access from a PANA 156 authentication agent within a network. A PANA client is 157 associated with a network device and a set of credentials to 158 prove its identity for network access authorization. 160 PANA Client Identifier (PaCI) 162 The identifier that is presented by the PaC to the PAA for 163 network access authentication. A simple username and NAI [NAI] 164 are examples of PANA client identifiers. 166 Device Identifier (DI) 168 The identifier used by the network as a handle to control and 169 police the network access of a client. Depending on the access 170 technology, this identifier might contain any of IP address, 171 link-layer address, switch port number, etc. of a connected 172 device. 174 PANA Authentication Agent (PAA) 176 The entity whose responsibility is to authenticate the 177 credentials provided by a PANA client and grant network 178 access service to the device associated with the client 179 and identified by a DI. 181 Enforcement Point (EP) 183 A node on the access network where per-packet enforcement 184 policies (i.e., filters) are applied on the inbound 185 and outbound traffic of client devices. Information such as DI 186 and (optionally) cryptographic keys are provided by PAA per 187 client for constructing filters on the EP. 189 4. Requirements 191 4.1. Authentication 193 4.1.1. Authentication of Client 195 PANA MUST enable authentication of PaCs for network access. A PaC's 196 identity can be authenticated by verifying the credentials (e.g., 197 identifier, authenticator) supplied by one of the users of the 198 device or the device itself. PANA MUST only grant network access 199 service to the device identified by the DI, rather than granting 200 separate access to multiple simultaneous users of the device. Once 201 the network access is granted to the device, the methods used by the 202 device on arbitrating which one of its users can access the network 203 is outside the scope of PANA. 205 PANA MUST NOT define new security protocols or mechanisms. Instead, 206 it MUST be defined as a "carrier" for such protocols. PANA MUST 207 identify which specific security protocol(s) or mechanism(s) it can 208 carry (the "payload"). The current thinking is that a sufficient 209 solution would be for PANA to carry EAP [EAP]. If the PANA WG 210 decides that extensions to EAP are needed, it will define 211 requirements for the EAP WG instead of designing such extensions. 213 Providing authentication, integrity and replay protection for data 214 traffic after a successful PANA exchange is outside the scope of 215 this protocol. In networks where physical layer security is not 216 present, link-layer or network-layer (e.g., IPsec) ciphering can be 217 used to provide such security. These mechanisms require presence of 218 cryptographic keying material at PaC and EP, which can be generated 219 by various EAP methods. Although PANA does not deal with key 220 derivation or distribution, it indirectly enables this by the virtue 221 of carrying EAP. The keying material produced by EAP methods cannot 222 be directly used with IPsec. In that case these initial keys can be 223 used with an IPsec key management protocol like IKE to generate the 224 required security associations. Key distribution from PAA to EP 225 SHOULD be handled by a separate protocol that takes care of 226 provisioning in the network (see section 4.4). Providing a complete 227 secure network access solution by also securing router discovery 228 [RDISC], neighbor discovery [NDISC], and address resolution 229 protocols [ARP] is outside the scope as well. Securing IPv6 router 230 discovery and neighbor discovery protocols are within the scope of 231 the IETF SEND Working Group. 233 Some access networks might require or allow their clients to get 234 authenticated and authorized by the NAP (network access provider) 235 and ISP before the clients gain network access. NAP is the owner of 236 the access network who provides physical and link-layer connectivity 237 to the clients. PANA MUST be capable of enabling two independent 238 authentication operations (i.e., execution of two separate EAP 239 methods) for the same client. Determining the authorization 240 parameters as a result of two separate authentications is an 241 operational issue and therefore it is outside the scope of PANA. 243 Both the PaC and the PAA MUST be able to authenticate each other for 244 network access. Providing only the capability of a PAA 245 authenticating the PaC is not sufficient. Mutual authentication 246 capability is necessary in some environments but not in all of them. 247 For example, clients might not need to authenticate the access 248 network when physical security is available (e.g., dial-up 249 networks). 251 PANA MUST be capable of carrying out both periodic and on-demand 252 re-authentication. Both the PaC and the PAA MUST be able to initiate 253 both the initial authentication and the re-authentication process. 255 Certain types of service theft are possible when the DI is not 256 protected during or after the PANA exchange [SECTHREAT]. PANA MUST 257 have the capability to exchange DI securely between the PAC and PAA 258 where the network is vulnerable to man-in-the-middle attacks. While 259 PANA MUST provide such a capability, its utility relies on the use 260 of an authentication method that can generate keys for cryptographic 261 computations on PaC and PAA. 263 4.1.2. Authorization, Accounting and Access Control 265 After a device is authenticated using PANA, it MUST be authorized 266 for network access. That is, the core requirement of PANA is to 267 verify the authorization of a PaC so that PaC�s device may send and 268 receive any IP packets. It may also be possible to provide finer 269 granularity authorization, such as authorization for QoS or 270 individual services (e.g., http vs. ssh). However, while a backend 271 authorization infrastructure (e.g., Diameter) might provide such 272 indications to the PAA, explicit support for them is outside the 273 scope of PANA. For instance, PANA is not required to carry any 274 indication of which services are authorized to the device. 276 Providing access control functionality in the network is outside the 277 scope of PANA. Client access authentication SHOULD be followed by 278 access control to make sure only authenticated and authorized 279 clients can send and receive IP packets via access network. Access 280 control can involve setting access control lists on the EPs. 281 Identification of clients that are authorized to access the network 282 is done by the PANA protocol exchange. 284 Carrying accounting data is outside the scope of PANA. 286 4.1.3. Authentication Backend 288 PANA protocol MUST NOT make any assumptions on the backend 289 authentication protocol or mechanisms. A PAA MAY interact with 290 backend AAA infrastructures such as RADIUS or Diameter, but it is 291 not a requirement. When the access network does not rely on an 292 IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can 293 still use a proprietary backend system, or rely on the information 294 locally stored on the authentication agents. 296 The interaction between the PAA and the backend authentication 297 entities is outside the scope of PANA. 299 4.1.4. Identifiers 301 PANA SHOULD allow various types of identifiers to be used as the 302 PaCI (e.g., username, NAI, FQDN, etc.). This requirement generally 303 relies on the client identifiers supported by various EAP methods. 305 PANA SHOULD allow various types of identifiers to be used as the DI 306 (e.g., IP address, link-layer address, port number of a switch, 307 etc.). 309 A PAA MUST be able to create a binding between the PaCI and the 310 associated DI upon successful PANA exchange. This can be achieved by 311 PANA communicating the PaCI and DI to the PAA during the protocol 312 exchange. The DI can be carried either explicitly as part of the 313 PANA payload, or implicitly as the source of the PANA message, or 314 both. Multi-access networks also require use of a cryptographic 315 protection along with DI filtering to prevent unauthorized access 316 [SECTHREAT]. The keying material required by the cryptographic 317 methods needs to be indexed by the DI. The binding between DI and 318 PaCI is used for access control and accounting in the network as 319 described in section 4.1.2. 321 4.2. IP Address Assignment 323 Providing address assignment functionality is outside the scope of 324 PANA. PANA protocol design MAY require the PaC to configure an IP 325 address before using this protocol. Allocating an IP address to 326 unauthenticated PaCs may create security vulnerabilities, such as IP 327 address depletion attacks on the access network [SECTHREAT]. IPv4 328 networks with limited address space are the main targets of such 329 attacks. Launching a successful attack that can deplete the 330 addresses in an IPv6 network is relatively harder. 332 This threat can be mitigated by allowing the protocol to run without 333 an IP address configured on the PaC (i.e., using unspecified source 334 address). Such a design choice might limit the re-use of existing 335 security mechanisms, and impose additional implementation 336 complexity. This trade off should be taken into consideration in 337 designing PANA. 339 4.3. EAP Lower Layer Requirements 341 The EAP protocol itself imposes various requirements on its 342 transport protocols. These requirements are based on the nature of 343 the EAP protocol, and need to be satisfied for correct operation. 344 Please see [EAP] for the generic transport requirements that MUST be 345 satisfied by PANA as well. 347 4.4. PAA-to-EP Protocol 349 PANA does not assume that the PAA is always co-located with the 350 EP(s). Network access enforcement can be provided by one or more 351 nodes on the same IP subnet as the client (e.g., multiple routers), 352 or on another subnet in the access domain (e.g., gateway to the 353 Internet, depending on the network architecture). When the PAA and 354 the EP(s) are separated, there needs to be another transport for 355 client provisioning. This transport is needed to create access 356 control lists to allow authenticated and authorized clients' traffic 357 through the EPs. This WG will preferably identify an existing 358 protocol solution that allows the PAA to deliver the authorization 359 information to one or more EPs when the PAA is separated from EPs. 360 Possible candidates include but are not limited to COPS, SNMP, 361 Diameter. This task is similar to what the MIDCOM Working Group is 362 trying to achieve, therefore some of that WG's output might be 363 useful here. 365 It is assumed that the communication between PAA and EP(s) is 366 secure. The objective of using a PAA-to-EP protocol is to provide 367 filtering rules to EP(s) for allowing network access of a recently 368 authenticated and authorized PaC. The chosen protocol MUST be 369 capable of carrying DI and cryptographic keys for a given PaC from 370 PAA to EP. Depending on the PANA protocol design, support for either 371 of the pull model (i.e., EP initiating the PAA-to-EP protocol 372 exchange per PaC) or the push model (i.e., PAA initiating the 373 PAA-to-EP protocol exchange per PaC), or both MAY be required. For 374 example, if the design is such that the EP allows the PANA traffic 375 to pass through even for unauthenticated PaCs, the EP should also 376 allow and expect the PAA to send the filtering information at the 377 end of a successful PANA exchange without the EP ever sending a 378 request. 380 4.5. Network 382 4.5.1. Multi-access 384 PANA MUST support PaCs with multiple interfaces, and networks with 385 multiple routers on multi-access links. In other words, PANA MUST 386 NOT assume the PaC has only one network interface, or the access 387 network has only one first hop router, or the PaC is using a 388 point-to-point link. 390 4.5.2. Disconnect Indication 392 PANA MUST NOT assume that the link is connection-oriented. Links may 393 or may not provide disconnect indication. Such notification is 394 desirable in order for the PAA to cleanup resources when a client 395 moves away from the network (e.g., inform the enforcement points 396 that the client is no longer connected). PANA SHOULD have a 397 mechanism to provide disconnect indication. When such indications 398 are not protected by means of physical or link-layer mechanisms, 399 PANA MUST ensure this protection to prevent attackers from 400 leveraging this extension for DoS attacks. 402 This mechanism MUST allow the PAA to be notified about the departure 403 of a PaC from the network. This mechanism MUST also allow a PaC to 404 be notified about the discontinuation of the network access service. 405 Access discontinuation can happen due to various reasons such as 406 network systems going down, or a change in access policy. 408 In case the clients cannot send explicit disconnect messages to the 409 PAA, PAA can still detect their departure by relying on periodic 410 authentication requests. 412 4.5.3. Location of PAA 414 The PAA and PaC MUST be exactly one IP hop away from each other. 415 That is, there must be no IP routers between the two. Note that this 416 does not mean they are on the same physical link. Bridging 417 techniques can place two nodes just exactly one IP hop away from 418 each other although they might be connected to separate physical 419 links. Furthermore, two nodes on the same IP subnet do not 420 necessarily satisfy this requirement, as they can be more than one 421 hop away from each other [MULTILINK]. A PAA can be on the NAS 422 (network access server) or WLAN access point or first hop router. 423 The use of PANA when the PAA is multiple IP hops away from the PaC 424 is outside the scope of PANA. 426 A PaC MAY NOT be pre-configured with the IP address of PAA. 427 Therefore the PANA protocol MUST define a dynamic discovery method. 428 Given that the PAA is one hop away from the PaC, there are a number 429 of discovery techniques that could be used (e.g., multicast or 430 anycast) by the PaC to find out the address of the PAA. 432 4.5.4. Secure Channel 434 PANA MUST NOT assume presence of a secure channel between the PaC 435 and the PAA. PANA MUST be able to provide authentication especially 436 in networks which are not protected against eavesdropping and 437 spoofing. PANA MUST enable protection against replay attacks on both 438 PaCs and PAAs. 440 This requirement partially relies on the EAP protocol and the EAP 441 methods carried over PANA. Use of EAP methods that provide mutual 442 authentication and key derivation/distribution is essential for 443 satisfying this requirement. EAP does not make a secure channel 444 assumption, and supports various authentication methods that can be 445 used in such environments. Additionally, PANA MUST ensure its design 446 does not contain vulnerabilities that can be exploited when it is 447 used over insecure channels. PANA MAY provide a secure channel by 448 deploying a two-phase authentication. The first phase can be used 449 for creation of the secure channel, and the second phase is for 450 client and network authentication. 452 4.6. Interaction with Other Protocols 454 Mobility management is outside the scope of PANA. However, PANA MUST 455 be able to co-exist and not interfere with various mobility 456 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 457 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other 458 standard protocols like IPv6 stateless address auto-configuration 459 [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP 460 [DHCP]. It MUST NOT make any assumptions on the protocols or 461 mechanisms used for IP address configuration of the PaC. 463 4.7. Performance 465 PANA design SHOULD give consideration to efficient handling of the 466 authentication process. This is important for gaining network access 467 with minimum latency. As an example, a method like minimizing the 468 protocol signaling by creating local security associations can be 469 used for this purpose. 471 4.8. Congestion Control 473 PANA MUST provide congestion control for the protocol messaging. 474 Under certain conditions PaCs might unintentionally get synchronized 475 when sending their requests to the PAA (e.g., upon recovering from a 476 power outage on the access network). The network congestion 477 generated from such events can be avoided by using techniques like 478 delayed initialization and exponential back off. 480 4.9. IP Version Independence 482 PANA MUST work with both IPv4 and IPv6. 484 4.10. Denial of Service Attacks 486 PANA MUST be robust against a class of DoS attacks such as blind 487 masquerade attacks through IP spoofing that would swamp the PAA, 488 causing it to spend resources and prevent network access by 489 legitimate clients. 491 4.11. Client Identity Privacy 493 Some clients might prefer hiding their identity from visited access 494 networks for privacy reasons. Providing identity protection for 495 clients is outside the scope of PANA. Note that some authentication 496 methods may already have this capability. Where necessary, identity 497 protection can be achieved by letting PANA carry such authentication 498 methods. 500 5. Security Considerations 502 This document identifies requirements for the PANA protocol design. 503 Due to the nature of this protocol most of the requirements are 504 security related. The actual protocol design is not specified in 505 this document. 507 6. Change Log 509 Version 06 510 * Location privacy requirements replaced with client identity 511 privacy requirement. 512 * PAC, PAC identifier, device identifier concepts clarified. 514 Version 05 516 * Definition of EP added. 517 * Text is clarified to indicate some of the requirements are 518 satisfied by EAP and EAP methods. 519 * IP address pre-configuration requirement changed. 520 * EAP lower layer requirements section added. 521 * Location of PAA further clarified (link vs. subnet vs. IP hops). 522 * PAA-to-EP protocol section added. 524 Version 04 526 * Minor Editorial corrections. 527 * Inserted the PANA model appendix. 529 Version 03 530 * In section 4.2.2 the requirement for a heartbeat mechanism to 531 provide disconnect indication was removed. Rewording of the 532 section was done. 533 * In section 4.2.3 and 4.1.2 rewording was done to account for the 534 separation of PAA and EP and the protocol between them. 535 * In section 4.2.4 new text was added to account for the possibility 536 to rely on the high layer protocol (EAP) to meet the requirements 537 stated. 538 * In section 4.5 new text was added to allow reliability and 539 congestion control to be provided by the payload protocol, e.g., 540 EAP. 542 7. Acknowledgements 544 We would like to thank Subir Das, Lionel Morand, Mohan 545 Parthasarathy, Basavaraj Patil, Pete McCann, Derek Atkins, Dan 546 Forsberg, and the PANA Working Group members for their valuable 547 contributions to the discussions and preparation of this document. 549 8. References 551 8.1. Normative References 553 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 554 Requirement Levels", RFC 2119, March 1997. 556 [USAGE] Y. Ohba, S. Das, B. Patil, H. Soliman, A. Yegin, "Problem 557 Statement and Usage Scenarios for PANA", 558 draft-ietf-pana-usage-scenarios-06.txt, April 2003. Work in 559 progress. 561 [SECTHREAT] M. Parthasarathy, "PANA Threat Analysis and Security 562 Requirements", draft-ietf-pana-threats-04.txt, May 2003. Work in 563 progress. 565 [EAP] L. Blunk, J. Vollbrecht, B. Aboba, J. Carlson, "Extensible 566 Authentication Protocol (EAP)", draft-ietf-eap-rfc2284bis-03.txt, 567 May 2003. Work in progress. 569 8.2. Informative References 571 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 572 Port Based Network Access Control", IEEE Draft 802.1X/D11, March 573 2001. 575 [EAPTLS] B. Aboba, D. Simon, "PPP EAP TLS Authentication Protocol", 576 RFC 2716, October 1999. 578 [MULTILINK] D. Thaler, C. Huitema, "Multi-link Subnet Support in 579 IPv6", draft-ietf-ipv6-multilink-subnets-00.txt, December 2002. Work 580 in progress. 582 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 583 51, RFC 1661, July 1994. 585 [MIPV4] C. Perkins (editor), "IP Mobility Support for IPv4", RFC 586 3344, August 2002. 588 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 589 draft-ietf-mobileip-ipv6-21.txt, February 2003. Work in progress. 591 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 592 Extensions", RFC3012, November 2000. 594 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 595 for IP Version 6 (IPv6)",RFC 2461, December 1998. 597 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 598 RFC 826, November 1982. 600 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 601 Mobile IPv4", November 2001. Work in progress. 603 [FMIPV6] R. Koodli (editor), et. al., "Fast Handovers for Mobile 604 IPv6", March 2003. Work in progress. 606 [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration 607 Protocol for IPv6", November 2002. Work in progress. 609 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 610 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 612 9. Authors' Addresses 614 Alper E. Yegin 615 DoCoMo USA Labs 616 181 Metro Drive, Suite 300 617 San Jose, CA, 95110 618 USA 619 Phone: +1 408 451 4743 620 Email: alper@docomolabs-usa.com 622 Yoshihiro Ohba 623 Toshiba America Research, Inc. 624 P.O. Box 136 625 Convent Station, NJ, 07961-0136 626 USA 627 Phone: +1 973 829 5174 628 Email: yohba@tari.toshiba.com 629 Reinaldo Penno 630 Nortel Networks 631 600 Technology Park 632 Billerica, MA, 01821 633 USA 634 Phone: +1 978 288 8011 635 Email: rpenno@nortelnetworks.com 637 George Tsirtsis 638 Flarion Technologies 639 Bedminster One 640 135 Route 202/206 South 641 Bedminster, NJ, 07921 642 USA 643 Phone : +44 20 88260073 644 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 646 Cliff Wang 647 Smart Pipes 648 565 Metro Place South 649 Dublin, OH, 43017 650 USA 651 Phone: +1 614 923 6241 652 Email: cwang@smartpipes.com 654 10. Appendix 656 A. PANA Model 658 Following sub-sections capture the PANA usage model in different 659 network architectures with reference to its placement of logical 660 elements such as the PANA Client (PaC) and the PANA Authentication 661 Agent (PAA) with respect to the Enforcement Point (EP) and the 662 Access Router (AR). Four different scenarios are described in 663 following sub-sections. Note that PAA may or may not use AAA 664 infrastructure to verify the credentials of PaC to authorize network 665 access. 667 A.1. PAA Co-located with EP But Separated from AR 669 In this scenario (Figure 1), PAA is co-located with the enforcement 670 point on which access control is performed. PaCs communicate with 671 the PAA for network access on behalf of a device (D1, D2, etc.). 672 PANA in this case provides a means to transport the authentication 673 parameters from the PaC to PAA. PAA knows how to verify the 674 credentials. After verification, PAA sends back the success or 675 failure response to PaC. However, PANA does not play any explicit 676 role in performing access control except that it provides a hook to 677 access control mechanisms. This might be the case where PAA is 678 co-located with the access point (an IP-capable L2 access device). 680 PaC -----EP/PAA-+ 681 [D1] | 682 +- ----- AR ----- (AAA) 683 | 684 PaC -----EP/PAA-+ 685 [D2] 687 Figure 1: PAA co-located with EP but separated from AR. 689 A.2. PAA Co-located with AR but Separated From EP 691 Figure 2 describes this model. In this scenario, PAA is not 692 co-located with EPs but it is placed on the AR. Although we have 693 shown only one AR here there could be multiple ARs, one of which is 694 co-located with the PAA. PaC exchanges the same messages with PAA as 695 discussed earlier. The difference here is when the initial 696 authentication for the PaC succeeds, access control parameters are 697 to be distributed to respective enforcement points so that the 698 corresponding device on which PaC is authenticated must be able to 699 access to the network. Similar to the earlier case, PANA does not 700 play any explicit role in performing access control except that it 701 provides a hook to access control mechanisms. However, a separate 702 protocol is needed between PAA and EP to carry access control 703 parameters. 705 PaC -------- EP --+ 706 [D1] | 707 +--- AR/PAA --- (AAA) 708 | 709 PaC -------- EP --+ 710 [D2] 712 Figure 2: PAA co-located with AR but separated from EP. 714 A.3. PAA Co-located with EP and AR 716 In this scenario (Figure 3), PAA is co-located with the EP and AR on 717 which access control and routing are performed. PaC exchanges the 718 same messages with PAA and PAA performs similar functionalities as 719 before. PANA in this case also does not play any explicit role in 720 performing access control except that it provides a hook to access 721 control mechanisms. 723 PaC ---------- EP/PAA/AR--+ 724 [D1] | 725 + -------(AAA) 726 | 727 PaC ---------- EP/PAA/AR--+ 728 [D2] 730 Figure 3: PAA co-located with EP and AR. 732 A.4. PAA Separated from EP and AR 734 Figure 4 represents this model. In this scenario, PAA is neither 735 co-located with EPs nor with ARs. It still resides on the same IP 736 link as ARs. PaC does similar exchanges with PAA as discussed 737 earlier. Similar to model in A.2, after successful authentication, 738 access control parameters will be distributed to respective 739 enforcement points via a separate protocol and PANA does not play 740 any explicit role in this. 742 PaC ----- EP -----+- AR -----+ 743 | | 744 PaC ----- EP --- -+ | 745 | | 746 PaC ----- EP -----+- AR ---- + ----(AAA) 747 | 748 +- PAA 750 Figure 4: PAA separated from EP and AR. 752 11. Full Copyright Statement 754 "Copyright (C) The Internet Society (2002). All Rights Reserved. 755 This document and translations of it may be copied and furnished to 756 others, and derivative works that comment on or otherwise explain it 757 or assist in its implementation may be prepared, copied, published 758 and distributed, in whole or in part, without restriction of any 759 kind, provided that the above copyright notice and this paragraph 760 are included on all such copies and derivative works. However, this 761 document itself may not be modified in any way, such as by removing 762 the copyright notice or references to the Internet Society or other 763 Internet organizations, except as needed for the purpose of 764 developing Internet standards in which case the procedures for 765 copyrights defined in the Internet Standards process must be 766 followed, or as required to translate it into languages other than 767 English. 769 The limited permissions granted above are perpetual and will not be 770 revoked by the Internet Society or its successors or assigns. 772 This document and the information contained herein is provided on an 773 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 774 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 775 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 776 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 777 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.