idnits 2.17.1 draft-ietf-pana-requirements-01.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 are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: PANA MUST not assume a secure channel between the PaC and the PAA. PANA MUST be able to provide authentication especially in networks which are not protected against eavesdropping and spoofing. PANA MUST provide protection against replay attacks on both PaCs and PAAs. -- 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: 'ADDRCONF' is mentioned on line 291, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '8021X' ** Obsolete normative reference: RFC 2002 (ref. 'MIPV4') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-15 ** Obsolete normative reference: RFC 3012 (ref. 'MNAAA') (Obsoleted by RFC 4721) ** Obsolete normative reference: RFC 2461 (ref. 'NDISC') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV4' -- Possible downref: Non-RFC (?) normative reference: ref. 'FMIPV6' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP' ** Obsolete normative reference: RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 6 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: March 2002 Reinaldo Penno 5 Expires: September 2002 George Tsirtsis 6 Cliff Wang 8 Protocol for Carrying Authentication for 9 Network Access (PANA) 10 Requirements and Terminology 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 It is expected that future IP devices will have a variety of access 37 technologies to gain network connectivity. Currently there are 38 access-specific mechanisms for providing client information to the 39 network for authentication and authorization purposes. In addition 40 to being limited to specific access media (e.g., 802.1x for IEEE 802 41 links), some of these protocols are limited to specific network 42 topologies (e.g., PPP for point-to-point links). The goal of the 43 PANA Working Group is to design a general network-layer protocol to 44 authenticate clients to the networks. The protocol will run between 45 a client's device and an agent device in the network where the agent 46 might be a client of the AAA infrastructure. The protocol should be 47 independent of the underlying access-type and not be limited to 48 specific network topologies. This document defines the common 49 terminology and identifies the requirements for PANA. 51 Table of Contents 53 Status of this Memo...............................................1 54 Abstract..........................................................1 55 Table of Contents.................................................2 56 1. Introduction...................................................2 57 2. Key Words......................................................3 58 3. Terminology....................................................4 59 4. Requirements...................................................4 60 4.1. Authentication...............................................4 61 4.1.1. Authentication of Client...................................4 62 4.1.2. Authorization, Accounting and Access Control...............5 63 4.1.3. Authentication Backend.....................................5 64 4.1.4. Identifiers................................................5 65 4.2. Network......................................................6 66 4.2.1. Multi-access...............................................6 67 4.2.2. Disconnect Indication......................................6 68 4.2.3. Location of PAA............................................6 69 4.2.4. Secure Channel.............................................6 70 4.3. Interaction with Other Protocols.............................6 71 4.4. Performance..................................................7 72 4.5. Reliability and Congestion Control...........................7 73 4.6. Miscellaneous................................................7 74 4.6.1. IP Version Independence....................................7 75 4.6.2. Denial of Service Attacks..................................7 76 4.6.3. Location Privacy...........................................7 77 Acknowledgements..................................................7 78 References........................................................8 79 Authors� Addresses................................................9 80 Full Copyright Statement.........................................10 82 1. Introduction 84 Currently there are a variety of access technologies available to 85 the network clients. While most of the clients currently have single 86 interface, it is expected that in the future they will have multiple 87 interfaces of different types to access the network. 89 An authentication mechanism is needed in order to provide secure 90 network access to the legitimate clients. Some of the current 91 authentication mechanisms are access technology specific. For 92 example 802.1x [8021X] works for only IEEE 802 link layers. If a 93 client can have more than one type of interface, using access- 94 specific authentication mechanisms leads to running a collection of 95 protocols on the client for the same purpose. It is clearly 96 advantageous to use a general protocol to authenticate the client 97 for network access on any type of technology. 99 The most widely used protocol for authenticating clients is the PPP 100 [PPP]. This protocol can run on various access types, but it 101 provides an inherently point-to-point interface. While it can 102 efficiently be applied to such topologies, using PPP with a multi- 103 access network creates sub-optimal solutions. Such multi-access 104 networks require either a full mesh of PPP links among clients, or a 105 designated router as the end-point of PPP links. 107 There is currently no general protocol to be used by a client for 108 gaining network access, and the PANA Working Group will attempt to 109 fill that hole. The Working Group will design a protocol between a 110 client's device and an agent device in the network where the agent 111 might be a client of the AAA infrastructure. As a network-layer 112 protocol, it will be independent of the underlying access 113 technologies. It will also be applicable to any network topology. 115 The protocol design will be limited to defining a messaging protocol 116 (i.e., a carrier) for providing the clients' information to the 117 network for authentication and authorization purposes. The Working 118 Group will not invent new security protocols and mechanisms but 119 instead will use the existing mechanisms. In particular, the Working 120 Group will not define authentication protocols, key distribution or 121 key agreement protocols, or key derivation. The desired protocol can 122 be viewed as the front-end of the AAA protocol or any other 123 protocol/mechanisms the network is running at the background to 124 authenticate its clients. It will act as a carrier for an already 125 defined security protocol or mechanism. 127 As an example, Mobile IP Working Group has already defined such a 128 carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request 129 message is used as the carrier for authentication extensions (MN-FA 130 [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the 131 foreign agents. In that sense, designing the equivalent of Mobile 132 IPv4 registration request messages for general network access is the 133 goal of this work, but not defining the equivalent of MN-FA or MN- 134 AAA extensions. 136 This document defines the common terminology and identifies the 137 requirements of a protocol for PANA. These terminology and 138 requirements will be used to define and limit the scope of the work 139 to be done in this group. 141 2. Key Words 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [KEYWORDS]. 147 3. Terminology 149 Device Identifier (DI) 151 The identifier used by the network as a handle to control and 152 police the network access of a client. Depending on the access 153 technology, identifier might contain any of IP address, link- 154 layer address, switch port number, etc. of a device. PANA 155 authentication agent keeps a table for binding device 156 identifiers to the PANA clients. At most one PANA client 157 should be associated with a DI on a PANA authentication agent. 159 PANA Client (PaC) 161 The entity wishing to obtain network access from a PANA 162 authentication agent within a network. A PANA client is 163 associated with a network device and a set of credentials to 164 prove its identity within the scope of PANA. 166 PANA Authentication Agent (PAA) 168 The entity whose responsibility is to authenticate the 169 credentials provided by a PANA client and grant network 170 access service to the device associated with the client 171 and identified by a DI. 173 4. Requirements 175 4.1. Authentication 177 4.1.1. Authentication of Client 179 PANA MUST authenticate a PaC for network access. A PaC can be 180 identified by the credentials (identifier, authenticator) supplied 181 by one of the users of the device or the device itself. PANA MUST 182 only grant network access service to the device identified by the 183 DI, rather than granting separate access to multiple simultaneous 184 users of the device. Once the network access is granted to the 185 device, the methods used by the device on arbitrating which one of 186 its users can access the network is outside the scope of PANA. 188 PANA MUST NOT define new security protocols or mechanisms. Instead 189 it must be defined as a "carrier" for such protocols. PANA MUST 190 identify which specific security protocol(s) or mechanism(s) it can 191 carry (the "payload"). An example of a carrier would be the 192 registration request message of Mobile IPv4 [MIPV4] that carries MN- 193 FA authentication extension. 195 Authentication and encryption of data traffic sent to and from an 196 authenticated PaC is outside the scope of PANA. Providing a complete 197 secure network access solution by also securing router discovery 198 [RDISC], neighbor discovery [NDISC], and address resolution 199 protocols [ARP] is outside the scope as well. 201 Both the PaC and the PAA MUST be able to authenticate each other for 202 network access. Providing capability of only PAA authenticating the 203 PaC is not sufficient. 205 PANA MUST be capable of carrying out both periodic and on-demand re- 206 authentication. Both the PaC and the PAA MUST be able to initiate 207 both the initial authentication and the re-authentication process. 209 When the DI is carried explicitly as part of the PANA payload, the 210 authentication computation MUST also include this field to provide 211 integrity protection for the DI. When the DI is carried implicitly 212 as the source of the PANA message, the protocol has to make sure 213 that the DI's integrity is protected by some other means (e.g., 214 physical verification of incoming port number of the PANA message in 215 the case of switch port number as a DI and PAA co-located with the 216 link-layer access device). Protecting PaCs against DI theft is 217 outside the scope of PANA. 219 4.1.2. Authorization, Accounting and Access Control 221 In addition to carrying authentication information, PANA MUST also 222 carry a binary result (i.e., success or failure) of authorization 223 for network access to the PaC. Providing finer granularity 224 authorization is outside the scope of PANA. 226 Providing access control functionality in the network is outside the 227 scope of PANA. PAA MAY communicate the DI associated with a PaC to 228 other entities in the network to setup access control and accounting 229 state. This interaction is outside the scope of PANA as well. 231 Carrying accounting data is outside the scope of PANA. 233 4.1.3. Authentication Backend 235 PAA MAY use either a AAA backend, some other mechanism or a local 236 database to authenticate the PaC. PANA protocol MUST NOT make any 237 assumptions on the backend authentication protocol or mechanisms. 238 The interaction between the PAA and the backend authentication 239 entities is outside the scope of PANA. 241 4.1.4. Identifiers 243 PANA SHOULD allow various types of identifiers to be used for the 244 PaC (e.g., NAI, IP address, FQDN, etc.) 245 PANA SHOULD allow various types of identifiers to be used as the DI 246 (IP address, link-layer address, port number of a switch, etc.) 248 PAA MUST be able to create a binding between the PaC and the 249 associated DI upon successful PANA exchange. The DI MUST be carried 250 either explicitly as part of the PANA payload, or implicitly as the 251 source of the PANA message, or both. This binding is used for access 252 control and accounting in the network as described in section 4.1.2. 254 4.2. Network 256 4.2.1. Multi-access 258 Protocol MUST support PaCs with multiple interfaces, and networks 259 with multiple routers on multi-access links. 261 4.2.2. Disconnect Indication 263 PANA MUST NOT assume connection-oriented links. Links may or may not 264 provide disconnect indication. PANA SHOULD define a "disconnect" 265 indication to allow PaCs to notify the PAA of their departure from 266 the network. A similar indication SHOULD also be used to let PAA 267 notify a PaC about the discontinuation of the network access. Access 268 discontinuation can happen due to various reasons such as network 269 systems going down, or a change in access policy. 271 4.2.3. Location of PAA 273 PAA MAY be one or more hop away from the PaC. PANA MUST define a 274 method used by PaCs for locating the PAAs in a network. 276 4.2.4. Secure Channel 278 PANA MUST not assume a secure channel between the PaC and the PAA. 279 PANA MUST be able to provide authentication especially in networks 280 which are not protected against eavesdropping and spoofing. PANA 281 MUST provide protection against replay attacks on both PaCs and 282 PAAs. 284 4.3. Interaction with Other Protocols 286 Mobility management is outside the scope of PANA. Though, PANA MUST 287 be able to co-exist and not interfere with various mobility 288 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 289 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other 290 standard protocols like IPv6 stateless address auto-configuration 291 [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP 293 [DHCP]. It MUST NOT make any assumptions on the protocols or 294 mechanisms used for IP address configuration of the PaC. 296 4.4. Performance 298 PANA design SHOULD give consideration to efficient handling of 299 authentication process. This is important for gaining network access 300 with minimum latency. As an example, a method like minimizing the 301 protocol signaling by creating local security associations can be 302 used for this purpose. 304 4.5. Reliability and Congestion Control 306 PANA MUST provide reliability and congestion control. It can do so 307 by using techniques like re-transmissions, cyclic redundancy check, 308 delayed initialization and exponential back-off. 310 4.6. Miscellaneous 312 4.6.1. IP Version Independence 314 PANA MUST work for both IPv4 and IPv6. 316 4.6.2. Denial of Service Attacks 318 PANA MUST be robust against a class of DoS attacks such as blind 319 masquerade attacks through IP spoofing that swamp the PAA in 320 spending much resources and prevent legitimate clients� attempts of 321 network access. The required robustness is no worse than that for 322 TCP SYN attack. 324 4.6.3. Location Privacy 326 Location privacy is outside the scope of PANA. 328 Acknowledgements 330 We would like to thank Basavaraj Patil, Subir Das, and the PANA 331 Working Group members for their valuable contributions to the 332 discussions and preparation of this document. 334 References 336 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 337 Requirement Levels", RFC 2119, March 1997. 339 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 340 Port Based Network Access Control", IEEE Draft 802.1X/D11, March 341 2001. 343 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 344 51, RFC 1661, July 1994. 346 [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002, 347 October 1996. 349 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 350 draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress. 352 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 353 Extensions", RFC3012, November 2000. 355 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 356 September 1991. 358 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 359 for IP Version 6 (IPv6)",RFC 2461, December 1998. 361 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 362 RFC 826, November 1982. 364 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 365 Mobile IPv4", November 2001. Work in progress. 367 [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile 368 IPv6", July 2001. Work in progress. 370 [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration 371 Protocol for IPv6", December 2001. Work in progress. 373 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 374 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 376 Authors' Addresses 378 Alper E. Yegin 379 DoCoMo USA Labs 380 181 Metro Drive, Suite 300 381 San Jose, CA, 95110 382 USA 383 Phone: +1 408 451 4743 384 Email: alper@docomolabs-usa.com 386 Yoshihiro Ohba 387 Toshiba America Research, Inc. 388 P.O. Box 136 389 Convent Station, NJ, 07961-0136 390 USA 391 Phone: +1 973 829 5174 392 Email: yohba@tari.toshiba.com 394 Reinaldo Penno 395 Nortel Networks 396 2305 Mission College Boulevard 397 Santa Clara, CA, 95054 398 USA 399 Phone: +1 408 565 3023 400 Email: rpenno@nortelnetworks.com 402 George Tsirtsis 403 Flarion Technologies 404 Bedminster One 405 135 Route 202/206 South 406 Bedminster, NJ, 07921 407 USA 408 Phone : +44 20 88260073 409 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 411 Cliff Wang 412 Smart Pipes 413 565 Metro Place South 414 Dublin, OH, 43017 415 USA 416 Phone: +1 614 923 6241 417 Email: cwang@smartpipes.com 418 Full Copyright Statement 420 "Copyright (C) The Internet Society (2002). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph 426 are included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.