idnits 2.17.1 draft-ietf-pana-requirements-08.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 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 833. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 846. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 862), 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 : ---------------------------------------------------------------------------- No issues found here. 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 10, 2004) is 7253 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: 'IEEE-802.1X' is defined on line 554, but no explicit reference was found in the text == Unused Reference: 'RFC1661' is defined on line 562, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-pana-threats-eval-04 ** Downref: Normative reference to an Informational draft: draft-ietf-pana-threats-eval (ref. 'I-D.ietf-pana-threats-eval') ** Obsolete normative reference: RFC 2284 (Obsoleted by RFC 3748) == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-01 == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-09 -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 3012 (Obsoleted by RFC 4721) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Yegin, Ed. 2 Internet-Draft Samsung AIT 3 Expires: December 9, 2004 Y. Ohba 4 Toshiba 5 R. Penno 6 Nortel Networks 7 G. Tsirtsis 8 Flarion 9 C. Wang 10 ARO/NCSU 11 June 10, 2004 13 Protocol for Carrying Authentication for Network Access (PANA) 14 Requirements 15 draft-ietf-pana-requirements-08.txt 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 December 9, 2004. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). All Rights Reserved. 46 Abstract 48 It is expected that future IP devices will have a variety of access 49 technologies to gain network connectivity. Currently there are 50 access-specific mechanisms for providing client information to the 51 network for authentication and authorization purposes. In addition 52 to being limited to specific access media (e.g., 802.1X for IEEE 802 53 links), some of these protocols are limited to specific network 54 topologies (e.g., PPP for point-to-point links). The goal of this 55 document is to identify the requirements for a link-layer agnostic 56 protocol that allows a host and a network to authenticate each other 57 for network access. This protocol will run between a client's device 58 and an agent in the network where the agent might be a client of the 59 AAA infrastructure. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 65 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . 6 68 4.1.1 Authentication of Client . . . . . . . . . . . . . . . 6 69 4.1.2 Authorization, Accounting and Access Control . . . . . 7 70 4.1.3 Authentication Backend . . . . . . . . . . . . . . . . 8 71 4.1.4 Identifiers . . . . . . . . . . . . . . . . . . . . . 8 72 4.2 IP Address Assignment . . . . . . . . . . . . . . . . . . 9 73 4.3 EAP Lower Layer Requirements . . . . . . . . . . . . . . . 9 74 4.4 PAA-to-EP Protocol . . . . . . . . . . . . . . . . . . . . 9 75 4.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.5.1 Multi-access . . . . . . . . . . . . . . . . . . . . . 10 77 4.5.2 Disconnect Indication . . . . . . . . . . . . . . . . 10 78 4.5.3 Location of PAA . . . . . . . . . . . . . . . . . . . 10 79 4.5.4 Secure Channel . . . . . . . . . . . . . . . . . . . . 11 80 4.6 Interaction with Other Protocols . . . . . . . . . . . . . 11 81 4.7 Performance . . . . . . . . . . . . . . . . . . . . . . . 11 82 4.8 Congestion Control . . . . . . . . . . . . . . . . . . . . 11 83 4.9 IP Version Independence . . . . . . . . . . . . . . . . . 12 84 4.10 Denial of Service Attacks . . . . . . . . . . . . . . . . 12 85 4.11 Client Identity Privacy . . . . . . . . . . . . . . . . . 12 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 89 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 91 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 93 A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 94 B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21 95 Intellectual Property and Copyright Statements . . . . . . . . 24 97 1. Introduction 99 Secure network access service requires access control based on the 100 authentication and authorization of the clients and the access 101 networks. Initial and subsequent client-to-network authentication 102 provides parameters that are needed to police the traffic flow 103 through the enforcement points. A protocol is needed to carry 104 authentication parameters between the client and the access network. 105 See Appendix for the associated problem statement. 107 The protocol design will be limited to defining a messaging protocol 108 (i.e., a carrier) that will allow authentication payload to be 109 carried between the host/client and an agent/server in the access 110 network for authentication and authorization purposes regardless of 111 the AAA infrastructure that may (or may not) reside on the network. 112 As a network-layer protocol, it will be independent of the underlying 113 access technologies. It will also be applicable to any network 114 topology. 116 The intent is not to invent new security protocols and mechanisms but 117 to reuse existing mechanisms such as EAP [RFC2284] 118 [I-D.ietf-eap-rfc2284bis]. In particular, the requirements do not 119 mandate the need to define new authentication protocols (e.g., 120 EAP-TLS [RFC2716]), key distribution or key agreement protocols, or 121 key derivation methods. The desired protocol can be viewed as the 122 front-end of the AAA protocol or any other protocol/mechanisms the 123 network is running at the background to authenticate its clients. It 124 will act as a carrier for an already defined security protocol or 125 mechanism. 127 As an example, the Mobile IP Working Group has already defined such a 128 carrier for Mobile IPv4 [RFC3344]. A Mobile IPv4 registration 129 request message is used as a carrier for authentication extensions 130 (MN-FA [RFC3344] or MN-AAA [RFC3012]) 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. Requirements notation 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 [RFC2119]. 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 network 159 access authentication. A simple username and NAI [RFC2794] are 160 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 associated 175 with the client and identified by a DI. 177 Enforcement Point (EP) 179 A node on the access network where per-packet enforcement policies 180 (i.e., filters) are applied on the inbound and outbound traffic of 181 client devices. Information such as DI and (optionally) 182 cryptographic keys are provided by PAA per client for constructing 183 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 device 194 or the device itself. PANA MUST only grant network access service to 195 the device identified by the DI, rather than granting separate access 196 to multiple simultaneous users of the device. Once the network 197 access is granted to the device, the methods used by the device on 198 arbitrating which one of its users can access the network is outside 199 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 is a candidate protocol that satisfies 205 many of the requirements for authentication. PANA would be a carrier 206 protocol for EAP. If the PANA Working Group decides that extensions 207 to EAP are needed, it will define requirements for the EAP WG instead 208 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 this 212 protocol. In networks where physical layer security is not present, 213 link-layer or network-layer ciphering (e.g., IPsec) can be used to 214 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 selection. 218 Various EAP methods are capable of generating basic keying material. 219 The keying material produced by EAP methods cannot be directly used 220 with IPsec as it lacks the properties of an IPsec SA (security 221 association) which include secure cipher suite negotiation, mutual 222 proof of possession of keying material, freshness of transient 223 session keys, key naming, etc. These basic (initial) EAP keys can be 224 used with an IPsec key management protocol like IKE to generate the 225 required security associations. A separate protocol, called secure 226 association protocol, is required to generate IPsec SAs based on the 227 basic EAP keys. This protocol MUST be capable of enabling 228 IPsec-based access control on the EPs. IPsec SAs MUST enable 229 authentication, integrity and replay protection of data packets as 230 they are sent between the EP and PaC. 232 Providing a complete secure network access solution by also securing 233 router discovery [RFC1256], neighbor discovery [RFC2461], and 234 address resolution protocols [RFC1982] 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) and 238 ISP before the clients gain network access. NAP is the owner of the 239 access network who provides physical and link-layer connectivity to 240 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 in 250 all of them. For example, clients might not need to authenticate the 251 access network when physical security is available (e.g., dial-up 252 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 260 [I-D.ietf-pana-threats-eval]. PANA MUST have the capability to 261 exchange DI securely between the PAC and PAA where the network is 262 vulnerable to man-in-the-middle attacks. While PANA MUST provide 263 such a capability, its utility relies on the use of an authentication 264 method that can generate keys for cryptographic computations on PaC 265 and PAA. 267 4.1.2 Authorization, Accounting and Access Control 269 After a device is authenticated by using PANA, it MUST be authorized 270 for "network access." That is, the core requirement of PANA is to 271 verify the authorization of a PaC so that PaC's device may send and 272 receive any IP packets. It may also be possible to provide finer 273 granularity authorization, such as authorization for QoS or 274 individual services (e.g., http vs. ssh). However, while a backend 275 authorization infrastructure (e.g., Diameter) might provide such 276 indications to the PAA, explicit support for them is outside the 277 scope of PANA. For instance, PANA is not required to carry any 278 indication of which services are authorized for the authenticated 279 device. 281 Providing access control functionality in the network is outside the 282 scope of PANA. Client access authentication SHOULD be followed by 283 access control to make sure only authenticated and authorized clients 284 can send and receive IP packets via the access network. Access 285 control can involve setting access control lists on the EPs. 286 Identification of clients that are authorized to access the network 287 is done by the PANA protocol exchange. If IPsec-based access control 288 is deployed in an access network, PaC and EPs should have the 289 required IPsec SA in place. Generating the IPsec SAs based on EAP 290 keys is outside the scope of PANA protocol. This transformation MUST 291 be handled by a separate secure association protocol (see section 292 4.1.1). 294 Carrying accounting data is outside the scope of PANA. 296 4.1.3 Authentication Backend 298 PANA protocol MUST NOT make any assumptions on the backend 299 authentication protocol or mechanisms. A PAA MAY interact with 300 backend AAA infrastructures such as RADIUS or Diameter, but it is not 301 a requirement. When the access network does not rely on an 302 IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use 303 a proprietary backend system, or rely on the information locally 304 stored on the authentication agents. 306 The interaction between the PAA and the backend authentication 307 entities is outside the scope of PANA. 309 4.1.4 Identifiers 311 PANA SHOULD allow various types of identifiers to be used as the PaCI 312 (e.g., username, NAI, FQDN, etc.). This requirement generally relies 313 on the client identifiers supported by various EAP methods. 315 PANA SHOULD allow various types of identifiers to be used as the DI 316 (e.g., IP address, link-layer address, port number of a switch, 317 etc.). 319 A PAA MUST be able to create a binding between the PaCI and the 320 associated DI upon successful PANA exchange. This can be achieved by 321 PANA communicating the PaCI and DI to the PAA during the protocol 322 exchange. The DI can be carried either explicitly as part of the 323 PANA payload, or implicitly as the source of the PANA message, or 324 both. Multi-access networks also require use of a cryptographic 325 protection along with DI filtering to prevent unauthorized access 326 [I-D.ietf-pana-threats-eval]. The keying material required by the 327 cryptographic methods needs to be indexed by the DI. The binding 328 between DI and PaCI is used for access control and accounting in the 329 network as described in section 4.1.2. 331 4.2 IP Address Assignment 333 Assigning an IP address to the client is outside the scope of PANA. 334 PaC MUST configure an IP address before running PANA. 336 4.3 EAP Lower Layer Requirements 338 The EAP protocol itself imposes various requirements on its transport 339 protocols. These requirements are based on the nature of the EAP 340 protocol, and they need to be satisfied for correct operation. 341 Please see [I-D.ietf-eap-rfc2284bis] for the generic transport 342 requirements that MUST be satisfied by PANA as well. 344 4.4 PAA-to-EP Protocol 346 PANA does not assume that the PAA is always co-located with the 347 EP(s). Network access enforcement can be provided by one or more 348 nodes on the same IP subnet as the client (e.g., multiple routers), 349 or on another subnet in the access domain (e.g., gateway to the 350 Internet, depending on the network architecture). When the PAA and 351 the EP(s) are separated, there needs to be another transport for 352 client provisioning. This transport is needed to create access 353 control lists to allow authenticated and authorized clients' traffic 354 through the EPs. PANA Working Group will preferably identify an 355 existing protocol solution that allows the PAA to deliver the 356 authorization information to one or more EPs when the PAA is 357 separated from EPs. Possible candidates include but are not limited 358 to COPS, SNMP, Diameter, etc. This task is similar to what the 359 MIDCOM Working Group is trying to achieve, therefore some of that 360 working group's output might be useful here. 362 It is assumed that the communication between PAA and EP(s) is secure. 363 The objective of using a PAA-to-EP protocol is to provide filtering 364 rules to EP(s) for allowing network access of a recently 365 authenticated and authorized PaC. The chosen protocol MUST be 366 capable of carrying DI and cryptographic keys for a given PaC from 367 PAA to EP. Depending on the PANA protocol design, support for either 368 of the pull model (i.e., EP initiating the PAA-to-EP protocol 369 exchange per PaC) or the push model (i.e., PAA initiating the 370 PAA-to-EP protocol exchange per PaC), or both may be required. For 371 example, if the design is such that the EP allows the PANA traffic to 372 pass through even for unauthenticated PaCs, the EP should also allow 373 and expect the PAA to send the filtering information at the end of a 374 successful PANA exchange without the EP ever sending a request. 376 4.5 Network 378 4.5.1 Multi-access 380 PANA MUST support PaCs with multiple interfaces, and networks with 381 multiple routers on multi-access links. In other words, PANA MUST 382 NOT assume the PaC has only one network interface, or the access 383 network has only one first hop router, or the PaC is using a 384 point-to-point link. 386 4.5.2 Disconnect Indication 388 PANA MUST NOT assume that the link is connection-oriented. Links may 389 or may not provide disconnect indication. Such notification is 390 desirable in order for the PAA to cleanup resources when a client 391 moves away from the network (e.g., inform the enforcement points that 392 the client is no longer connected). PANA SHOULD have a mechanism to 393 provide disconnect indication. PANA MUST be capable of securing 394 disconnect messages in order to prevent malicious nodes from 395 leveraging this extension for DoS attacks. 397 This mechanism MUST allow the PAA to be notified about the departure 398 of a PaC from the network. This mechanism MUST also allow a PaC to 399 be notified about the discontinuation of the network access service. 400 Access discontinuation can happen due to various reasons such as 401 network systems going down, or a change in the access policy. 403 In case the clients cannot send explicit disconnect messages to the 404 PAA, PAA can still detect their departure by relying on periodic 405 authentication requests. 407 4.5.3 Location of PAA 409 The PAA and PaC MUST be exactly one IP hop away from each other. 410 That is, there must be no IP routers between the two. Note that this 411 does not mean they are on the same physical link. Bridging 412 techniques can place two nodes just exactly one IP hop away from each 413 other although they might be connected to separate physical links. A 414 PAA can be on the NAS (network access server) or WLAN access point or 415 first hop router. The use of PANA when the PAA is multiple IP hops 416 away from the PaC is outside the scope of PANA. 418 A PaC may or may not be pre-configured with the IP address of PAA. 419 Therefore the PANA protocol MUST define a dynamic discovery method. 420 Given that the PAA is one hop away from the PaC, there are a number 421 of discovery techniques that could be used (e.g., multicast or 422 anycast) by the PaC to find out the address of the PAA. 424 4.5.4 Secure Channel 426 PANA MUST NOT assume presence of a secure channel between the PaC and 427 the PAA. PANA MUST be able to provide authentication especially in 428 networks which are not protected against eavesdropping and spoofing. 429 PANA MUST enable protection against replay attacks on both PaCs and 430 PAAs. 432 This requirement partially relies on the EAP protocol and the EAP 433 methods carried over PANA. Use of EAP methods that provide mutual 434 authentication and key derivation/distribution is essential for 435 satisfying this requirement. EAP does not make a secure channel 436 assumption, and supports various authentication methods that can be 437 used in such environments. Additionally, PANA MUST ensure its design 438 does not contain vulnerabilities that can be exploited when it is 439 used over insecure channels. PANA MAY provide a secure channel by 440 deploying a two-phase authentication. The first phase can be used 441 for creation of the secure channel, and the second phase is for 442 client and network authentication. 444 4.6 Interaction with Other Protocols 446 Mobility management is outside the scope of PANA. However, PANA MUST 447 be able to co-exist and MUST NOT unintentionally interfere with 448 various mobility management protocols, such as Mobile IPv4 [RFC3344], 449 Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols 450 [I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff], 451 and other standard protocols like IPv6 stateless address 452 auto-configuration [RFC2461] (including privacy extensions 453 [RFC3041]), and DHCP [RFC2131][RFC3315]. It MUST NOT make any 454 assumptions on the protocols or mechanisms used for IP address 455 configuration of the PaC. 457 4.7 Performance 459 PANA design SHOULD give consideration to efficient handling of the 460 authentication process. This is important for gaining network access 461 with minimum latency. As an example, a method like minimizing the 462 protocol signaling by creating local security associations can be 463 used for this purpose. 465 4.8 Congestion Control 467 PANA MUST provide congestion control for the protocol messaging. 468 Under certain conditions PaCs might unintentionally get synchronized 469 when sending their requests to the PAA (e.g., upon recovering from a 470 power outage on the access network). The network congestion 471 generated from such events can be avoided by using techniques like 472 delayed initialization and exponential back off. 474 4.9 IP Version Independence 476 PANA MUST work with both IPv4 and IPv6. 478 4.10 Denial of Service Attacks 480 PANA MUST be robust against a class of DoS attacks such as blind 481 masquerade attacks through IP spoofing that would swamp the PAA, 482 causing it to spend resources and prevent network access by 483 legitimate clients. 485 4.11 Client Identity Privacy 487 Some clients might prefer hiding their identity from visited access 488 networks for privacy reasons. Providing identity protection for 489 clients is outside the scope of PANA. Note that some authentication 490 methods may already have this capability. Where necessary, identity 491 protection can be achieved by letting PANA carry such authentication 492 methods. 494 5. IANA Considerations 496 This document has no actions for IANA. 498 6. Security Considerations 500 This document identifies requirements for the PANA protocol design. 501 Due to the nature of this protocol most of the requirements are 502 security related. The actual protocol design is not specified in 503 this document. A thorough discussion on PANA security threats can be 504 found in PANA Threat Analysis and Security Requirements document 505 [I-D.ietf-pana-threats-eval]. Security threats identified in that 506 document are already included in this general PANA requirements 507 document. 509 7. Acknowledgements 511 Authors would like to thank Bernard Aboba, Derek Atkins, Julien 512 Bournelle, Subir Das, Francis Dupont, Dan Forsberg, Pete McCann, 513 Lionel Morand, Thomas Narten, Mohan Parthasarathy, Basavaraj Patil, 514 Hesham Soliman, and the PANA Working Group members for their valuable 515 contributions to the discussions and preparation of this document. 517 8. References 519 8.1 Normative References 521 [I-D.ietf-pana-threats-eval] 522 Parthasarathy, M., "PANA Threat Analysis and security 523 requirements", draft-ietf-pana-threats-eval-04 (work in 524 progress), May 2003. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 530 Authentication Protocol (EAP)", RFC 2284, March 1998. 532 8.2 Informative References 534 [I-D.ietf-eap-rfc2284bis] 535 Blunk, L., "Extensible Authentication Protocol (EAP)", 536 draft-ietf-eap-rfc2284bis-09 (work in progress), February 537 2004. 539 [I-D.ietf-mipshop-fast-mipv6] 540 Koodli, R., "Fast Handovers for Mobile IPv6", 541 draft-ietf-mipshop-fast-mipv6-01 (work in progress), 542 February 2004. 544 [I-D.ietf-mobileip-ipv6] 545 Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 546 in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), 547 July 2003. 549 [I-D.ietf-mobileip-lowlatency-handoff] 550 Malki, K., "Low latency Handoffs in Mobile IPv4", 551 draft-ietf-mobileip-lowlatency-handoffs-v4-09 (work in 552 progress), June 2004. 554 [IEEE-802.1X] 555 Institute of Electrical and Electronics Engineers, "Local 556 and Metropolitan Area Networks: Port-Based Network Access 557 Control", IEEE Standard 802.1X, September 2001. 559 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 560 September 1991. 562 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 563 RFC 1661, July 1994. 565 [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, 566 August 1996. 568 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 569 2131, March 1997. 571 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 572 Discovery for IP Version 6 (IPv6)", RFC 2461, December 573 1998. 575 [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication 576 Protocol", RFC 2716, October 1999. 578 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 579 Identifier Extension for IPv4", RFC 2794, March 2000. 581 [RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/ 582 Response Extensions", RFC 3012, November 2000. 584 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 585 Stateless Address Autoconfiguration in IPv6", RFC 3041, 586 January 2001. 588 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 589 M. Carney, "Dynamic Host Configuration Protocol for IPv6 590 (DHCPv6)", RFC 3315, July 2003. 592 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 593 August 2002. 595 Authors' Addresses 597 Alper E. Yegin (editor) 598 Samsung Advanced Institute of Technology 599 75 West Plumeria Drive 600 San Jose, CA 95134 601 USA 603 Phone: +1 408 544 5656 604 EMail: alper.yegin@samsung.com 605 Yoshihiro Ohba 606 Toshiba America Research, Inc. 607 1 Telcordia Drive 608 Piscataway, NJ 08854 609 USA 611 Phone: +1 732 699 5305 612 EMail: yohba@tari.toshiba.com 614 Reinaldo Penno 615 Nortel Networks 616 600 Technology Park 617 Billerica, MA 01821 618 USA 620 Phone: +1 978 288 8011 621 EMail: rpenno@nortelnetworks.com 623 George Tsirtsis 624 Flarion 625 Bedminster One 626 135 Route 202/206 South 627 Bedminster, NJ 07921 628 USA 630 Phone: +44 20 88260073 631 EMail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 633 Cliff Wang 634 ARO/NCSU 635 316 Riggsbee Farm 636 Morrisville, NC 27560 637 USA 639 Phone: +1 919 548 4207 640 EMail: cliffwangmail@yahoo.com 642 Appendix A. Problem Statement 644 Access networks in most cases require some form of authentication in 645 order to prevent unauthorized usage. In the absence of physical 646 security (and sometimes in addition to it) a higher layer (L2+) 647 access authentication mechanism is needed. Depending on the 648 deployment scenarios, a number of features are expected from the 649 authentication mechanism. For example, support for various 650 authentication methods (e.g., MD5, TLS, SIM, etc.), network roaming, 651 network service provider discovery and selection, separate 652 authentication for access (L1+L2) service provider and ISP (L3), etc. 653 In the absence of a link-layer authentication mechanism that can 654 satisfy these needs, operators are forced to either use non-standard 655 ad-hoc solutions at layers above the link, insert additional shim 656 layers for authentication, or misuse some of the existing protocols 657 in ways that were not intended by design. PANA will be developed to 658 fill this gap by defining a standard network-layer access 659 authentication protocol. As a network-layer access authentication 660 protocol, PANA can be used over any link-layer that supports IP. 662 DSL networks are a specific example where PANA has the potential for 663 addressing some of the deployment scenarios therein. Some DSL 664 deployments do not use PPP as the access link-layer (IP is carried 665 over ATM and the subscriber device is either statically- or 666 DHCP-configured). The operators of these networks are either left 667 with using an application-layer web-based login (captive portal) 668 scheme for subscriber authentication, or providing a best-effort 669 service only as they cannot perform subscriber authentication 670 required for the differentiated services. The captive portal scheme 671 is a non-standard solution that has various limitations and security 672 flaws. 674 PPP-based authentication can provide some of the required 675 functionality. But using PPP only for authentication is not a good 676 choice, as it incurs additional messaging during the connection setup 677 and extra per-packet processing, and it forces the network topology 678 to a point-to-point model. Aside from resistance to incorporating 679 PPP into an architecture unless it is absolutely necessary, there is 680 even interest in the community to remove PPP from some of the 681 existing architectures and deployments (e.g., 3GPP2, DSL). 683 Using Mobile IPv4 authentication with a foreign agent instead of 684 proper network access authentication is an example of protocol 685 misuse. Registration Required flag allows a foreign agent to force 686 authentication even when the agent is not involved in any Mobile IPv4 687 signalling (co-located care-of address case), hence enabling the use 688 of a mobility-specific protocol for an unrelated functionality. 690 PANA will carry EAP above IP in order to enable any authentication 691 method on any link-layer. EAP can already be carried by IEEE 802.1X 692 and PPP. IEEE 802.1X can only be used on unbridged IEEE 802 links, 693 hence it only applies to limited link types. Inserting PPP between 694 IP and a link-layer can be perceived as a way to enable EAP over that 695 particular link-layer, but using PPP for this reason has the 696 aforementioned drawbacks, hence not a good choice. While IEEE 802.1X 697 and PPP can continue to be used in their own domains, they do not 698 take away the need to have a protocol like PANA. 700 Appendix B. Usage Scenarios 702 PANA will be applicable to various types of networks. Based on the 703 presence of lower-layer security prior to running PANA, the following 704 types cover all possibilities: 706 a) Physically secured networks (e.g., DSL networks). Although data 707 traffic is always carried over a physically secured link, the client 708 might need to be authenticated and authorized when accessing the IP 709 services. 711 b) Networks where L1-L2 is already cryptographically secured before 712 enabling IP (e.g., cdma2000 networks). Although the client is 713 authenticated on the radio link before enabling ciphering, it 714 additionally needs to get authenticated and authorized for accessing 715 the IP services. 717 c) No lower-layer security present before enabling IP. PANA is run 718 in an insecure network. PANA-based access authentication is used to 719 bootstrap cryptographic per-packet authentication and integrity 720 protection. 722 PANA is applicable to not only large-scale operator deployments with 723 full AAA infrastructure, but also to small disconnected deployments 724 like home networks and personal area networks. 726 Since PANA enables decoupling AAA from the link-layer procedures, 727 network access authentication does not have to take place during the 728 link establishment. This allows deferring client authentication 729 until the client attempts to access differentiated services (e.g., 730 high bandwidth, unlimited access, etc.) in some deployments. 731 Additionally multiple simultaneous network access sessions over the 732 same link-layer connection can be realized as well. 734 Following scenarios capture the PANA usage model in different network 735 architectures with reference to its placement of logical elements 736 such as the PANA Client (PaC) and the PANA Authentication Agent (PAA) 737 with respect to the Enforcement Point (EP) and the Access Router 738 (AR). Five different scenarios are described in following 739 sub-sections. Note that PAA may or may not use AAA infrastructure to 740 verify the credentials of PaC to authorize network access. 742 Scenario 1: PAA co-located with EP but separated from AR 744 In this scenario (Figure 1), PAA is co-located with the enforcement 745 point on which access control is performed. This might be the case 746 where PAA is co-located with the L2 access device (e.g., an 747 IP-capable switch). 749 PaC -----EP/PAA--+ 750 | 751 +------ AR ----- (AAA) 752 | 753 PaC -----EP/PAA--+ 755 Figure 1: PAA co-located with EP but separated from AR. 757 Scenario 2: PAA co-located with AR but separated from EP 759 In this scenario, PAA is not co-located with EPs but it is placed on 760 the AR. Although we have shown only one AR here there could be 761 multiple ARs, one of which is co-located with the PAA. Access 762 control parameters have to be distributed to the respective 763 enforcement points so that the corresponding device on which PaC is 764 authenticated can access to the network. A separate protocol is 765 needed between PAA and EP to carry access control parameters. 767 PaC ----- EP --+ 768 | 769 +------ AR/PAA --- (AAA) 770 | 771 PaC ----- EP --+ 773 Figure 2: PAA co-located with AR but separated from EP 775 Scenario 3: PAA co-located with EP and AR 777 In this scenario (Figure 3), PAA is co-located with the EP and AR on 778 which access control and routing are performed. 780 PaC ----- EP/PAA/AR--+ 781 | 782 +-------(AAA) 783 | 784 PaC ----- EP/PAA/AR--+ 786 Figure 3: PAA co-located with EP and AR. 788 Scenario 4: Separated PAA, EP, and AR 790 In this scenario, PAA is neither co-located with EPs nor with ARs. 791 It still resides on the same IP link as ARs. After the successful 792 authentication, access control parameters will be distributed to 793 respective enforcement points via a separate protocol and PANA does 794 not play any explicit role in this. 796 PaC ----- EP -----+--- AR ---+ 797 | | 798 PaC ----- EP --- -+ | 799 | | 800 PaC ----- EP -----+--- AR -- + ----(AAA) 801 | 802 +--- PAA 804 Figure 4: PAA, EP and AR separated. 806 Scenario 5: PAA separated from co-located EP and AR 808 In this scenario, EP and AR are co-located with each other bu 809 separated from PAA. PAA still resides on the same IP link as ARs. 810 After the successful authentication, access control parameters will 811 be distributed to respective enforcement points via a separate 812 protocol and PANA does not play any explicit role in this. 814 PaC --------------+--- AR/EP ---+ 815 | | 816 PaC --------------+ | 817 | | 818 PaC --------------+--- AR/EP -- + ----(AAA) 819 | 820 +--- PAA 822 Figure 5: PAA separated from EP and AR. 824 Intellectual Property Statement 826 The IETF takes no position regarding the validity or scope of any 827 Intellectual Property Rights or other rights that might be claimed to 828 pertain to the implementation or use of the technology described in 829 this document or the extent to which any license under such rights 830 might or might not be available; nor does it represent that it has 831 made any independent effort to identify any such rights. Information 832 on the procedures with respect to rights in RFC documents can be 833 found in BCP 78 and BCP 79. 835 Copies of IPR disclosures made to the IETF Secretariat and any 836 assurances of licenses to be made available, or the result of an 837 attempt made to obtain a general license or permission for the use of 838 such proprietary rights by implementers or users of this 839 specification can be obtained from the IETF on-line IPR repository at 840 http://www.ietf.org/ipr. 842 The IETF invites any interested party to bring to its attention any 843 copyrights, patents or patent applications, or other proprietary 844 rights that may cover technology that may be required to implement 845 this standard. Please address the information to the IETF at 846 ietf-ipr@ietf.org. 848 Disclaimer of Validity 850 This document and the information contained herein are provided on an 851 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 852 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 853 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 854 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 855 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 856 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 858 Copyright Statement 860 Copyright (C) The Internet Society (2004). This document is subject 861 to the rights, licenses and restrictions contained in BCP 78, and 862 except as set forth therein, the authors retain all their rights. 864 Acknowledgment 866 Funding for the RFC Editor function is currently provided by the 867 Internet Society.