idnits 2.17.1 draft-ietf-pana-requirements-09.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (August 30, 2004) is 7177 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 ** 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-02 == 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: 9 errors (**), 0 flaws (~~), 6 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: February 28, 2005 Y. Ohba 4 Toshiba 5 R. Penno 6 Nortel Networks 7 G. Tsirtsis 8 Flarion 9 C. Wang 10 ARO/NCSU 11 August 30, 2004 13 Protocol for Carrying Authentication for Network Access (PANA) 14 Requirements 15 draft-ietf-pana-requirements-09.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 February 28, 2005. 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 91 A. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 19 92 B. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 21 93 Intellectual Property and Copyright Statements . . . . . . . . 24 95 1. Introduction 97 Secure network access service requires access control based on the 98 authentication and authorization of the clients and the access 99 networks. Initial and subsequent client-to-network authentication 100 provides parameters that are needed to police the traffic flow 101 through the enforcement points. A protocol is needed to carry 102 authentication parameters between the client and the access network. 103 See Appendix for the associated problem statement. 105 The protocol design will be limited to defining a messaging protocol 106 (i.e., a carrier) that will allow authentication payload to be 107 carried between the host/client and an agent/server in the access 108 network for authentication and authorization purposes regardless of 109 the AAA infrastructure that may (or may not) reside on the network. 110 As a network-layer protocol, it will be independent of the underlying 111 access technologies. It will also be applicable to any network 112 topology. 114 The intent is not to invent new security protocols and mechanisms but 115 to reuse existing mechanisms such as EAP [RFC2284] 116 [I-D.ietf-eap-rfc2284bis]. In particular, the requirements do not 117 mandate the need to define new authentication protocols (e.g., 118 EAP-TLS [RFC2716]), key distribution or key agreement protocols, or 119 key derivation methods. The desired protocol can be viewed as the 120 front-end of the AAA protocol or any other protocol/mechanisms the 121 network is running at the background to authenticate its clients. It 122 will act as a carrier for an already defined security protocol or 123 mechanism. 125 As an example, the Mobile IP Working Group has already defined such a 126 carrier for Mobile IPv4 [RFC3344]. A Mobile IPv4 registration 127 request message is used as a carrier for authentication extensions 128 (MN-FA [RFC3344] or MN-AAA [RFC3012]) that allow a foreign agent to 129 authenticate mobile nodes before providing forwarding service. The 130 goal of PANA is similar in that it aims to define a network-layer 131 transport for authentication information; however, PANA will be 132 decoupled from mobility management and it will rely on other 133 specifications for the definition of authentication payloads. 135 This document defines the common terminology and identifies the 136 requirements of a protocol for PANA. These terminology and 137 requirements will be used to define and limit the scope of the work 138 to be done in this group. 140 2. Requirements notation 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 3. Terminology 148 PANA Client (PaC) 150 The client side of the protocol that resides in the host device 151 which is responsible for providing the credentials to prove its 152 identity for network access authorization. 154 PANA Client Identifier (PaCI) 156 The identifier that is presented by the PaC to the PAA for network 157 access authentication. A simple username and NAI [RFC2794] are 158 examples of PANA client identifiers. 160 Device Identifier (DI) 162 The identifier used by the network as a handle to control and 163 police the network access of a client. Depending on the access 164 technology, this identifier might contain any of IP address, 165 link-layer address, switch port number, etc. of a connected 166 device. 168 PANA Authentication Agent (PAA) 170 The access network side entity of the protocol whose 171 responsibility is to verify the credentials provided by a PANA 172 client and grant network access service to the device associated 173 with the client and identified by a DI. 175 Enforcement Point (EP) 177 A node on the access network where per-packet enforcement policies 178 (i.e., filters) are applied on the inbound and outbound traffic of 179 client devices. Information such as DI and (optionally) 180 cryptographic keys are provided by PAA per client for constructing 181 filters on the EP. 183 4. Requirements 185 4.1 Authentication 187 4.1.1 Authentication of Client 189 PANA MUST enable authentication of PaCs for network access. A PaC's 190 identity can be authenticated by verifying the credentials (e.g., 191 identifier, authenticator) supplied by one of the users of the device 192 or the device itself. PANA MUST only grant network access service to 193 the device identified by the DI, rather than granting separate access 194 to multiple simultaneous users of the device. Once the network 195 access is granted to the device, the methods used by the device on 196 arbitrating which one of its users can access the network is outside 197 the scope of PANA. 199 PANA MUST NOT define new security protocols or mechanisms. Instead, 200 it MUST be defined as a "carrier" for such protocols. PANA MUST 201 identify which specific security protocol(s) or mechanism(s) it can 202 carry (the "payload"). EAP is a candidate protocol that satisfies 203 many of the requirements for authentication. PANA would be a carrier 204 protocol for EAP. If the PANA Working Group decides that extensions 205 to EAP are needed, it will define requirements for the EAP WG instead 206 of designing such extensions. 208 Providing authentication, integrity and replay protection for data 209 traffic after a successful PANA exchange is outside the scope of this 210 protocol. In networks where physical layer security is not present, 211 link-layer or network-layer ciphering (e.g., IPsec) can be used to 212 provide such security. These mechanisms require presence of 213 cryptographic keying material at PaC and EP. Although PANA does not 214 deal with key derivation or distribution, it enables this by the 215 virtue of carrying EAP and allowing appropriate EAP method selection. 216 Various EAP methods are capable of generating basic keying material. 217 The keying material produced by EAP methods cannot be directly used 218 with IPsec as it lacks the properties of an IPsec SA (security 219 association) which include secure cipher suite negotiation, mutual 220 proof of possession of keying material, freshness of transient 221 session keys, key naming, etc. These basic (initial) EAP keys can be 222 used with an IPsec key management protocol like IKE to generate the 223 required security associations. A separate protocol, called secure 224 association protocol, is required to generate IPsec SAs based on the 225 basic EAP keys. This protocol MUST be capable of enabling 226 IPsec-based access control on the EPs. IPsec SAs MUST enable 227 authentication, integrity and replay protection of data packets as 228 they are sent between the EP and PaC. 230 Providing a complete secure network access solution by also securing 231 router discovery [RFC1256], neighbor discovery [RFC2461], and 232 address resolution protocols [RFC1982] is outside the scope as well. 234 Some access networks might require or allow their clients to get 235 authenticated and authorized by the NAP (network access provider) and 236 ISP before the clients gain network access. NAP is the owner of the 237 access network who provides physical and link-layer connectivity to 238 the clients. PANA MUST be capable of enabling two independent 239 authentication operations (i.e., execution of two separate EAP 240 methods) for the same client. Determining the authorization 241 parameters as a result of two separate authentications is an 242 operational issue and therefore it is outside the scope of PANA. 244 Both the PaC and the PAA MUST be able to perform mutual 245 authentication for network access. Providing only the capability of 246 a PAA authenticating the PaC is not sufficient. Mutual 247 authentication capability is required in some environments but not in 248 all of them. For example, clients might not need to authenticate the 249 access network when physical security is available (e.g., dial-up 250 networks). 252 PANA MUST be capable of carrying out both periodic and on-demand 253 re-authentication. Both the PaC and the PAA MUST be able to initiate 254 both the initial authentication and the re-authentication process. 256 Certain types of service theft are possible when the DI is not 257 protected during or after the PANA exchange 258 [I-D.ietf-pana-threats-eval]. PANA MUST have the capability to 259 exchange DI securely between the PAC and PAA where the network is 260 vulnerable to man-in-the-middle attacks. While PANA MUST provide 261 such a capability, its utility relies on the use of an authentication 262 method that can generate keys for cryptographic computations on PaC 263 and PAA. 265 4.1.2 Authorization, Accounting and Access Control 267 After a device is authenticated by using PANA, it MUST be authorized 268 for "network access." That is, the core requirement of PANA is to 269 verify the authorization of a PaC so that PaC's device may send and 270 receive any IP packets. It may also be possible to provide finer 271 granularity authorization, such as authorization for QoS or 272 individual services (e.g., http vs. ssh). However, while a backend 273 authorization infrastructure (e.g., Diameter) might provide such 274 indications to the PAA, explicit support for them is outside the 275 scope of PANA. For instance, PANA is not required to carry any 276 indication of which services are authorized for the authenticated 277 device. 279 Providing access control functionality in the network is outside the 280 scope of PANA. Client access authentication SHOULD be followed by 281 access control to make sure only authenticated and authorized clients 282 can send and receive IP packets via the access network. Access 283 control can involve setting access control lists on the EPs. 284 Identification of clients that are authorized to access the network 285 is done by the PANA protocol exchange. If IPsec-based access control 286 is deployed in an access network, PaC and EPs should have the 287 required IPsec SA in place. Generating the IPsec SAs based on EAP 288 keys is outside the scope of PANA protocol. This transformation MUST 289 be handled by a separate secure association protocol (see section 290 4.1.1). 292 Carrying accounting data is outside the scope of PANA. 294 4.1.3 Authentication Backend 296 PANA protocol MUST NOT make any assumptions on the backend 297 authentication protocol or mechanisms. A PAA MAY interact with 298 backend AAA infrastructures such as RADIUS or Diameter, but it is not 299 a requirement. When the access network does not rely on an 300 IETF-defined AAA protocol (e.g., RADIUS, Diameter), it can still use 301 a proprietary backend system, or rely on the information locally 302 stored on the authentication agents. 304 The interaction between the PAA and the backend authentication 305 entities is outside the scope of PANA. 307 4.1.4 Identifiers 309 PANA SHOULD allow various types of identifiers to be used as the PaCI 310 (e.g., username, NAI, FQDN, etc.). This requirement generally relies 311 on the client identifiers supported by various EAP methods. 313 PANA SHOULD allow various types of identifiers to be used as the DI 314 (e.g., IP address, link-layer address, port number of a switch, 315 etc.). 317 A PAA MUST be able to create a binding between the PaCI and the 318 associated DI upon successful PANA exchange. This can be achieved by 319 PANA communicating the PaCI and DI to the PAA during the protocol 320 exchange. The DI can be carried either explicitly as part of the 321 PANA payload, or implicitly as the source of the PANA message, or 322 both. Multi-access networks also require use of a cryptographic 323 protection along with DI filtering to prevent unauthorized access 324 [I-D.ietf-pana-threats-eval]. The keying material required by the 325 cryptographic methods needs to be indexed by the DI. The binding 326 between DI and PaCI is used for access control and accounting in the 327 network as described in section 4.1.2. 329 4.2 IP Address Assignment 331 Assigning an IP address to the client is outside the scope of PANA. 332 PaC MUST configure an IP address before running PANA. 334 4.3 EAP Lower Layer Requirements 336 The EAP protocol itself imposes various requirements on its transport 337 protocols. These requirements are based on the nature of the EAP 338 protocol, and they need to be satisfied for correct operation. 339 Please see [I-D.ietf-eap-rfc2284bis] for the generic transport 340 requirements that MUST be satisfied by PANA as well. 342 4.4 PAA-to-EP Protocol 344 PANA does not assume that the PAA is always co-located with the 345 EP(s). Network access enforcement can be provided by one or more 346 nodes on the same IP subnet as the client (e.g., multiple routers), 347 or on another subnet in the access domain (e.g., gateway to the 348 Internet, depending on the network architecture). When the PAA and 349 the EP(s) are separated, there needs to be another transport for 350 client provisioning. This transport is needed to create access 351 control lists to allow authenticated and authorized clients' traffic 352 through the EPs. PANA Working Group will preferably identify an 353 existing protocol solution that allows the PAA to deliver the 354 authorization information to one or more EPs when the PAA is 355 separated from EPs. Possible candidates include but are not limited 356 to COPS, SNMP, Diameter, etc. This task is similar to what the 357 MIDCOM Working Group is trying to achieve, therefore some of that 358 working group's output might be useful here. 360 The communication between PAA and EP(s) MUST be secure. The 361 objective of using a PAA-to-EP protocol is to provide filtering rules 362 to EP(s) for allowing network access of a recently authenticated and 363 authorized PaC. The chosen protocol MUST be capable of carrying DI 364 and cryptographic keys for a given PaC from PAA to EP. Depending on 365 the PANA protocol design, support for either of the pull model (i.e., 366 EP initiating the PAA-to-EP protocol exchange per PaC) or the push 367 model (i.e., PAA initiating the PAA-to-EP protocol exchange per PaC), 368 or both may be required. For example, if the design is such that the 369 EP allows the PANA traffic to pass through even for unauthenticated 370 PaCs, the EP should also allow and expect the PAA to send the 371 filtering information at the end of a successful PANA exchange 372 without the EP ever sending a request. 374 4.5 Network 376 4.5.1 Multi-access 378 PANA MUST support PaCs with multiple interfaces, and networks with 379 multiple routers on multi-access links. In other words, PANA MUST 380 NOT assume the PaC has only one network interface, or the access 381 network has only one first hop router, or the PaC is using a 382 point-to-point link. 384 4.5.2 Disconnect Indication 386 PANA MUST NOT assume that the link is connection-oriented. Links may 387 or may not provide disconnect indication. Such notification is 388 desirable in order for the PAA to cleanup resources when a client 389 moves away from the network (e.g., inform the enforcement points that 390 the client is no longer connected). PANA SHOULD have a mechanism to 391 provide disconnect indication. PANA MUST be capable of securing 392 disconnect messages in order to prevent malicious nodes from 393 leveraging this extension for DoS attacks. 395 This mechanism MUST allow the PAA to be notified about the departure 396 of a PaC from the network. This mechanism MUST also allow a PaC to 397 be notified about the discontinuation of the network access service. 398 Access discontinuation can happen due to various reasons such as 399 network systems going down, or a change in the access policy. 401 In case the clients cannot send explicit disconnect messages to the 402 PAA, PAA can still detect their departure by relying on periodic 403 authentication requests. 405 4.5.3 Location of PAA 407 The PAA and PaC MUST be exactly one IP hop away from each other. 408 That is, there must be no IP routers between the two. Note that this 409 does not mean they are on the same physical link. Bridging and 410 tunneling (e.g., IP-in-IP, GRE, L2TP, etc.) techniques can place two 411 nodes just exactly one IP hop away from each other although they 412 might be connected to separate physical links. A PAA can be on the 413 NAS (network access server) or WLAN access point or first hop router. 414 The use of PANA when the PAA is multiple IP hops away from the PaC is 415 outside the scope of PANA. 417 A PaC may or may not be pre-configured with the IP address of PAA. 418 Therefore the PANA protocol MUST define a dynamic discovery method. 419 Given that the PAA is one hop away from the PaC, there are a number 420 of discovery techniques that could be used (e.g., multicast or 421 anycast) by the PaC to find out the address of the PAA. 423 4.5.4 Secure Channel 425 PANA MUST NOT assume presence of a secure channel between the PaC and 426 the PAA. PANA MUST be able to provide authentication especially in 427 networks which are not protected against eavesdropping and spoofing. 428 PANA MUST enable protection against replay attacks on both PaCs and 429 PAAs. 431 This requirement partially relies on the EAP protocol and the EAP 432 methods carried over PANA. Use of EAP methods that provide mutual 433 authentication and key derivation/distribution is essential for 434 satisfying this requirement. EAP does not make a secure channel 435 assumption, and supports various authentication methods that can be 436 used in such environments. Additionally, PANA MUST ensure its design 437 does not contain vulnerabilities that can be exploited when it is 438 used over insecure channels. PANA MAY provide a secure channel by 439 deploying a two-phase authentication. The first phase can be used 440 for creation of the secure channel, and the second phase is for 441 client and network authentication. 443 4.6 Interaction with Other Protocols 445 Mobility management is outside the scope of PANA. However, PANA MUST 446 be able to co-exist and MUST NOT unintentionally interfere with 447 various mobility management protocols, such as Mobile IPv4 [RFC3344], 448 Mobile IPv6 [I-D.ietf-mobileip-ipv6], fast handover protocols 449 [I-D.ietf-mipshop-fast-mipv6][I-D.ietf-mobileip-lowlatency-handoff], 450 and other standard protocols like IPv6 stateless address 451 auto-configuration [RFC2461] (including privacy extensions [RFC3041]), 452 and DHCP [RFC2131][RFC3315]. It MUST NOT make any assumptions on the 453 protocols or mechanisms used for IP address configuration of the PaC. 455 4.7 Performance 457 PANA design SHOULD give consideration to efficient handling of the 458 authentication process. This is important for gaining network access 459 with minimum latency. As an example, a method like minimizing the 460 protocol signaling by creating local security associations can be 461 used for this purpose. 463 4.8 Congestion Control 465 PANA MUST provide congestion control for the protocol messaging. 466 Under certain conditions PaCs might unintentionally get synchronized 467 when sending their requests to the PAA (e.g., upon recovering from a 468 power outage on the access network). The network congestion 469 generated from such events can be avoided by using techniques like 470 delayed initialization and exponential back off. 472 4.9 IP Version Independence 474 PANA MUST work with both IPv4 and IPv6. 476 4.10 Denial of Service Attacks 478 PANA MUST be robust against a class of DoS attacks such as blind 479 masquerade attacks through IP spoofing that would swamp the PAA, 480 causing it to spend resources and prevent network access by 481 legitimate clients. 483 4.11 Client Identity Privacy 485 Some clients might prefer hiding their identity from visited access 486 networks for privacy reasons. Providing identity protection for 487 clients is outside the scope of PANA. Note that some authentication 488 methods may already have this capability. Where necessary, identity 489 protection can be achieved by letting PANA carry such authentication 490 methods. 492 5. IANA Considerations 494 This document has no actions for IANA. 496 6. Security Considerations 498 This document identifies requirements for the PANA protocol design. 499 Due to the nature of this protocol most of the requirements are 500 security related. The actual protocol design is not specified in 501 this document. A thorough discussion on PANA security threats can be 502 found in PANA Threat Analysis and Security Requirements document 503 [I-D.ietf-pana-threats-eval]. Security threats identified in that 504 document are already included in this general PANA requirements 505 document. 507 7. Acknowledgements 509 Authors would like to thank Bernard Aboba, Derek Atkins, Steven 510 Bellovin, Julien Bournelle, Subir Das, Francis Dupont, Dan Forsberg, 511 Pete McCann, Lionel Morand, Thomas Narten, Mohan Parthasarathy, 512 Basavaraj Patil, Hesham Soliman, and the PANA Working Group members 513 for their valuable contributions to the discussions and preparation 514 of this document. 516 8. References 518 8.1 Normative References 520 [I-D.ietf-pana-threats-eval] 521 Parthasarathy, M., "Protocol for Carrying Authentication 522 and Network Access Threat Analysis and Security 523 Requirements", draft-ietf-pana-threats-eval-07 (work in 524 progress), August 2004. 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-02 (work in progress), July 542 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.