idnits 2.17.1 draft-ietf-pana-requirements-00.txt: -(77): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 14 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 an Authors' Addresses Section. ** 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 -- 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 (February 3, 2002) is 8117 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ADDRCONF' is mentioned on line 274, 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) == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-lowlatency-handoffs-v4-03 ** Downref: Normative reference to an Experimental draft: draft-ietf-mobileip-lowlatency-handoffs-v4 (ref. 'FMIPV4') -- No information found for draft-ietf-mobileip-fast-mipv6 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'FMIPV6' == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-22 ** Obsolete normative reference: RFC 3041 (ref. 'PRIVACY') (Obsoleted by RFC 4941) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Alper E. Yegin (Editor) 2 Internet Draft Yoshihiro Ohba 3 draft-ietf-pana-requirements-00.txt Reinaldo Penno 4 Expires: August 3, 2002 George Tsirtsis 5 Cliff Wang 6 February 3, 2002 8 Protocol for Carrying Authentication for 9 Network Access (PANA) 10 Requirements and Terminology 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 It is expected that future IP devices will have a variety of access 36 technologies to gain network connectivity. Currently there are 37 access-specific mechanisms for providing client information to the 38 network for authentication and authorization purposes. In addition 39 to being limited to specific access medias (e.g., 802.1x for IEEE 40 802 links), some of these protocols are also sub-optimal (e.g., PPP 41 due to its mandatory framing which is not always needed). The goal 42 of the PANA Working Group is to design a general network-layer 43 protocol to authenticate clients to the networks. The protocol will 44 run between a client's device and an agent device in the network 45 where the agent might be a client of the AAA infrastructure. The 46 protocol should be independent of the underlying access-type and not 47 overloaded with other aspects of the network access (e.g., framing). 48 This document defines the common terminology and identifies the 49 requirements for PANA. 51 Table of Contents 52 Status of this Memo................................................1 53 Abstract...........................................................1 54 1. Introduction....................................................3 55 2. Key Words.......................................................4 56 3. Terminology.....................................................4 57 4. Requirements....................................................4 58 4.1. Authentication................................................4 59 4.1.1. Authentication of Client....................................4 60 4.1.2. Authorization, Accounting and Access Control................5 61 4.1.3. Authentication Backend......................................5 62 4.1.4. Re-authentication...........................................5 63 4.1.5. Mutual Authentication.......................................6 64 4.1.6. Identifiers.................................................6 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.3. Interaction with Other Protocols..............................6 70 4.4. Performance...................................................7 71 4.5. Miscellaneous.................................................7 72 4.5.1. IP Version Independence.....................................7 73 4.5.2. Reliability and Congestion..................................7 74 4.5.3. Denial of Service Attacks...................................7 75 Acknowledgements...................................................7 76 References.........................................................8 77 Authors� Addresses.................................................9 78 Full Copyright Statement..........................................10 80 1. Introduction 82 Currently there are a variety of access technologies available to 83 the network clients. While most of the clients currently have single 84 interface, it is expected that in the future they will have multiple 85 interfaces of different types to access the network. 87 An authentication mechanism is needed in order to provide secure 88 network access to the legitimate clients. Some of the current 89 authentication mechanisms are access technology specific. For 90 example 802.1x [8021X] only works for IEEE 802 link layers. If a 91 client can have more than one type of interface, using access- 92 specific authentication mechanisms leads to running a collection of 93 protocols on the client for the same purpose. It is clearly 94 advantageous to use a general protocol to authenticate the client 95 for network access on any type of technology. 97 The most widely used protocol for authenticating clients is the PPP 98 [PPP]. This protocol can run on various access types, but it is not 99 limited to authenticating the clients. It also provides mandatory 100 PPP framing. Since framing is already supported by certain link 101 types, having to use this extra framing creates sub-optimal network 102 access solutions. 104 There is currently no general protocol to be used by a client for 105 gaining network access, and the PANA Working Group will attempt to 106 fill that hole. The Working Group will design a protocol between a 107 client's device and an agent device in the network where the agent 108 might be a client of the AAA infrastructure. As a network-layer 109 protocol, it will be independent of the underlying access 110 technologies. The protocol design will also be limited to defining a 111 messaging protocol (i.e., a carrier) for providing the clients' 112 information to the network for authentication and authorization 113 purposes. It will not deal with the other aspects of network access 114 such as framing. 116 The Working Group will not invent new security protocols and 117 mechanisms but instead will use the existing mechanisms. In 118 particular, the Working Group will not define authentication 119 protocols, key distribution or key agreement protocols, or key 120 derivation. The desired protocol can be viewed as the front-end of 121 the AAA protocol or any other protocol/mechanisms the network is 122 running at the background to authenticate its clients. It will act 123 as a carrier for an already defined security protocol or mechanism. 125 As an example, Mobile IP Working Group has already defined such a 126 carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request 127 message is used as the carrier for authentication extensions (MN-FA 128 [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the 129 foreign agents. In that sense, designing the equivalent of Mobile 130 IPv4 registration request messages for general network access is the 131 goal of this work, but not defining the equivalent of MN-FA or MN- 132 AAA extensions. 134 This document defines the common terminology and identifies the 135 requirements of a protocol for PANA. These terminology and 136 requirements will be used to define and limit the scope of the work 137 to be done in this group. 139 2. Key Words 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [KEYWORDS]. 145 3. Terminology 147 Device Identifier (DI) 149 The identifier used by the network as a handle to control and 150 police the network access of a client. Depending on the access 151 technology, identifier might contain any of IP address, link- 152 layer address, switch port number, etc. of a device. PANA 153 authentication agent keeps a table for binding device 154 identifiers to the PANA clients. At most one PANA client 155 should be associated with a DI on a PANA authentication agent. 157 PANA Client (PaC) 159 The entity wishing to obtain network access from a PANA 160 authentication agent within a network. A PANA client is 161 associated with a network device and a set of credentials to 162 prove its identity within the scope of PANA. 164 PANA Authentication Agent (PAA) 166 The entity whose responsibility is to authenticate the 167 credentials provided by a PANA client and grant network 168 access service to the device associated with the client 169 and identified by a DI. 171 4. Requirements 173 4.1. Authentication 175 4.1.1. Authentication of Client 177 PANA MUST authenticate a PaC for network access. A PaC can be 178 identified by the credentials (identifier, authenticator) supplied 179 by one of the users of the device or the device itself. PANA MUST 180 only grant network access service to the device identified by the 181 DI, rather than granting separate access to multiple simultaneous 182 users of the device. Once the network access is granted to the 183 device, the methods used by the device on arbitrating which one of 184 its users can access the network is outside the scope of PANA. 186 PANA MUST NOT define new security protocols or mechanisms. Instead 187 it must be defined as a "carrier" for such protocols. PANA MUST 188 identify which specific security protocol(s) or mechanism(s) it can 189 carry (the "payload"). An example of a carrier would be the 190 registration request message of Mobile IPv4 [MIPV4] that carries MN- 191 FA authentication extension. 193 Authentication and encryption of data traffic sent to and from an 194 authenticated PaC is outside the scope of PANA. Providing a complete 195 secure network access solution by also securing router discovery 196 [RDISC], neighbor discovery [NDISC], and address resolution 197 protocols [ARP] is outside the scope as well. 199 4.1.2. Authorization, Accounting and Access Control 201 In addition to carrying authentication information, PANA MUST also 202 carry a binary result (i.e., success or failure) of authorization 203 for network access to the PaC. Providing finer granularity 204 authorization is outside the scope of PANA. 206 Providing access control functionality in the network is outside the 207 scope of PANA. PAA MAY communicate the DI associated with a PaC to 208 other entities in the network to setup packet filters and access 209 control state. This interaction is outside the scope of PANA as 210 well. 212 Carrying accounting data is outside the scope of PANA. 214 4.1.3. Authentication Backend 216 PAA MAY use either a AAA backend, some other mechanism or a local 217 database to authenticate the PaC. PANA protocol MUST NOT make any 218 assumptions on the backend authentication protocol or mechanisms. 219 The interaction between the PAA and the backend authentication 220 entities is outside the scope of PANA. 222 4.1.4. Re-authentication 224 PANA MUST be capable of carrying out both periodic and on-demand re- 225 authentication. Both the PaC and the PAA MUST be able to initiate 226 both the initial authentication and the re-authentication process. 228 4.1.5. Mutual Authentication 230 Both the PaC and the PAA MUST be able to authenticate each other for 231 network access. Providing capability of only PAA authenticating the 232 PaC is not sufficient. 234 4.1.6. Identifiers 236 PANA SHOULD allow various types of identifiers to be used for the 237 PaC (e.g., NAI, IP address, FQDN, etc.) 239 PANA SHOULD allow various types of identifiers to be used as the DI 240 (IP address, link-layer address, port number of a switch, etc.) 242 PAA MUST be able to create a binding between the PaC and the 243 associated DI upon successful PANA exchange. This binding is used 244 for access control and accounting in the network as described 245 in section 4.1.2. 247 4.2. Network 249 4.2.1. Multi-access 251 Protocol MUST support PaCs with multiple interfaces, and networks 252 with multiple routers on multi-access links. 254 4.2.2. Disconnect Indication 256 PANA MUST NOT assume connection-oriented links. Links may or may not 257 provide disconnect indication. PANA SHOULD define a "disconnect" 258 indication to allow PaCs to notify the PAA of their departure from 259 the network. A similar indication SHOULD also be used to let PAA 260 notify a PaC about the discontinuation of the network access. Access 261 discontinuation can happen due to various reasons such as network 262 systems going down, or a change in access policy. 264 4.2.3. Location of PAA 266 PAA MAY be one or more hop away from the PaC. 268 4.3. Interaction with Other Protocols 270 PANA MUST NOT handle mobility management of the PaC. But, it MUST be 271 able to co-exist and not interfere with various mobility management 272 protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 [MIPV6], fast 273 handover protocols [FMIPV4, FMIPV6], and other standard protocols 274 like IPv6 stateless address auto-configuration [ADDRCONF] (including 275 privacy extensions [PRIVACY]), and DHCP [DHCP]. It MUST NOT make any 276 assumptions on the protocols or mechanisms used for IP address 277 configuration of the PaC. 279 4.4. Performance 281 PANA design SHOULD give consideration to efficient handling of 282 authentication process. This is important for gaining network access 283 with minimum latency. As an example, a method like minimizing the 284 protocol signaling by creating local security associations can be 285 used for this purpose. 287 4.5. Miscellaneous 289 4.5.1. IP Version Independence 291 PANA MUST work for both IPv4 and IPv6. 293 4.5.2. Reliability and Congestion 295 PANA MUST provide reliability and congestion control. It can do so 296 by using techniques like re-transmissions, cyclic redundancy check, 297 delayed initialization and exponential back-off. 299 4.5.3. Denial of Service Attacks 301 PANA MUST be robust against a class of DoS attacks such as blind 302 masquerade attacks through IP spoofing that swamp the PAA in 303 spending much resources and prevent legitimate clients� attempts of 304 network access. The required robustness is no worse than that for 305 TCP SYN attack. 307 Acknowledgements 309 We would like to thank Basavaraj Patil and Subir Das for their 310 valuable contributions to the discussions and preparation of this 311 document. 313 References 315 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 316 Requirement Levels", RFC 2119, March 1997. 318 [8021X] �IEEE Standards for Local and Metropolitan Area Networks: 319 Port Based Network Access Control�, IEEE Draft 802.1X/D11, March 320 2001. 322 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 323 51, RFC 1661, July 1994. 325 [MIPV4] C. Perkins (editor), �IP Mobility Support�, RFC 2002, 326 October 1996. 328 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 329 draft-ietf-mobileip-ipv6-15.txt, July 2001. 331 [MNAAA] C. Perkins, P. Calhoun, �Mobile IPv4 Challenge/Response 332 Extensions�, RFC3012, November 2000. 334 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 335 September 1991. 337 [NDISC] T. Narten, E. Nordmark, and W. Simpson, �Neighbor Discovery 338 for IP Version 6 (IPv6)�,RFC 2461, December 1998. 340 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 341 37, RFC 826, November 1982. 343 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 344 Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-03, 345 November 2001. 347 [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile 348 IPv6", draft-ietf-mobileip-fast-mipv6-03.txt, July 2001. 350 [DHCP] R. Droms (editor), et. al., �Dynamic Host Configuration 351 Protocol for IPv6�, draft-ietf-dhc-dhcpv6-22.txt, December 2001. 353 [PRIVACY] T. Narten, R. Draves, �Privacy Extensions for Stateless 354 Address Autoconfiguration in IPv6�, RFC 3041, January 2001. 356 Authors� Addresses 358 Alper E. Yegin 359 DoCoMo USA Labs 360 181 Metro Drive, Suite 300 361 San Jose, CA, 95110 362 USA 363 Phone: +1 408 451 4743 364 Email: alper@docomolabs-usa.com 366 Yoshihiro Ohba 367 Toshiba America Research, Inc. 368 P.O. Box 136 369 Convent Station, NJ, 07961-0136 370 USA 371 Phone: +1 973 829 5174 372 Email: yohba@tari.toshiba.com 374 Reinaldo Penno 375 Nortel Networks 376 2305 Mission College Boulevard 377 Santa Clara, CA, 95054 378 USA 379 Phone: +1 408 565 3023 380 Email: rpenno@nortelnetworks.com 382 George Tsirtsis 383 Flarion Technologies 384 Bedminster One 385 135 Route 202/206 South 386 Bedminster, NJ, 07921 387 USA 388 Phone : +44 20 88260073 389 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 391 Cliff Wang 392 Smart Pipes 393 565 Metro Place South 394 Dublin, OH, 43017 395 USA 396 Phone: +1 614 923 6241 397 Email: cwang@smartpipes.com 399 Full Copyright Statement 401 "Copyright (C) The Internet Society (2001). All Rights Reserved. 402 This document and translations of it may be copied and furnished to 403 others, and derivative works that comment on or otherwise explain it 404 or assist in its implementation may be prepared, copied, published 405 and distributed, in whole or in part, without restriction of any 406 kind, provided that the above copyright notice and this paragraph 407 are included on all such copies and derivative works. However, this 408 document itself may not be modified in any way, such as by removing 409 the copyright notice or references to the Internet Society or other 410 Internet organizations, except as needed for the purpose of 411 developing Internet standards in which case the procedures for 412 copyrights defined in the Internet Standards process must be 413 followed, or as required to translate it into languages other than 414 English. 416 The limited permissions granted above are perpetual and will not be 417 revoked by the Internet Society or its successors or assigns. 419 This document and the information contained herein is provided on an 420 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 421 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 422 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 423 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 424 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.