idnits 2.17.1 draft-ietf-pana-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 == Line 117 has weird spacing: '... reside on th...' == 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 345, but not defined == Unused Reference: '8021X' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'PPP' is defined on line 395, but no explicit reference was found in the text -- 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 (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group Reinaldo Penno, Editor 3 INTERNET-DRAFT Alper E. Yegin 4 Date: June 2002 Yoshihiro Ohba 5 Expires: December 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 is to provide a layer two agnostic and IPv4/IPv6 compatible 44 client-server protocol that allows a host to be authenticated for 45 network access. The protocol will run between a client's device 46 and an agent device in the network where the agent might be a client 47 of the AAA infrastructure. This document defines the common 48 terminology and identifies the requirements for PANA. 50 Table of Contents 52 Status of this Memo...............................................1 53 Abstract..........................................................1 54 Table of Contents.................................................2 55 1. Introduction...................................................2 56 2. Key Words......................................................3 57 3. Terminology....................................................4 58 4. Requirements...................................................4 59 4.1. Authentication...............................................4 60 4.1.1. Authentication of Client...................................4 61 4.1.2. Authorization, Accounting and Access Control...............5 62 4.1.3. Authentication Backend.....................................5 63 4.1.4. Identifiers................................................5 64 4.2. Network......................................................6 65 4.2.1. Multi-access...............................................6 66 4.2.2. Disconnect Indication......................................6 67 4.2.3. Location of PAA............................................6 68 4.2.4. Secure Channel.............................................6 69 4.3. Interaction with Other Protocols.............................6 70 4.4. Performance..................................................7 71 4.5. Reliability and Congestion Control...........................7 72 4.6. Miscellaneous................................................7 73 4.6.1. IP Version Independence....................................7 74 4.6.2. Denial of Service Attacks..................................7 75 4.6.3. Location Privacy...........................................7 76 Acknowledgements..................................................7 77 References........................................................8 78 Authors' Addresses................................................9 79 Full Copyright Statement.........................................10 81 1. Introduction 83 Network access technologies for wired and wireless media are 84 evolving rapidly. With the rapid growth in the number and type of 85 devices and terminals that support IP stacks and can access the 86 Internet, users can potentially use a single device having the 87 capability of attaching via different multiple access media and 88 technologies to interface to the network. 90 If a client can have more than one type of interface, using 91 access-specific authentication mechanisms leads to running a 92 collection of protocols on the client for the same purpose. 94 For example, the authentication mechanisms in PPP are being used 95 for many wired access scenarios as well as some wireless access, 96 which requires using PPP encapsulation for the data packets. Using 97 PPP just for client authentication is viewed as a sub-optimal 98 solution as it causes extra round-trips, overhead of encapsulation 99 and processing, 100 and forces the network topology into a point-to-point 101 model. A point in case is PPPoE which is used over multi-access 102 networks primarily for the purpose of exploiting the authentication 103 scheme provided by PPP. Also, IEEE 802 relies on 802.1X which 104 provides EAP authentication that is limited to IEEE 802 link layers. 106 It is clearly advantageous to use a general protocol to authenticate 107 the client for network access on any type of technology. There is 108 currently no general protocol to be used by a client for gaining 109 network access, and the PANA Working Group will attempt to 110 fill that hole. 112 The protocol design will be limited to defining a client-server 113 messaging protocol (i.e., a carrier) that will allow authentication 114 payload to be carried between the host/client (PaC) and an 115 agent/server (PAA) in the access network for authentication and 116 authorization purposes regardless of the AAA infrastructure that 117 may (or may not) reside on the network. As a network-layer 118 protocol, it will be independent of the underlying access 119 technologies. It will also be applicable to any network topology. 121 The Working Group will not invent new security protocols and 122 mechanisms but instead will use the existing mechanisms. In 123 particular, the Working Group will not define authentication 124 protocols, key distribution or key agreement protocols, or key 125 derivation. The desired protocol can be viewed as the front-end 126 of the AAA protocol or any other protocol/mechanisms the network 127 is running at the background to authenticate its clients. It will 128 act as a carrier for an already defined security protocol or 129 mechanism. 131 As an example, Mobile IP Working Group has already defined such a 132 carrier for Mobile IPv4 [MIPV4]. Mobile IPv4 registration request 133 message is used as the carrier for authentication extensions (MN-FA 134 [MIPV4], or MN-AAA [MNAAA]) to receive forwarding service from the 135 foreign agents. In that sense, designing the equivalent of Mobile 136 IPv4 registration request messages for general network access is the 137 goal of this work, but not defining the equivalent of MN-FA or MN- 138 AAA extensions. 140 This document defines the common terminology and identifies the 141 requirements of a protocol for PANA. These terminology and 142 requirements will be used to define and limit the scope of the work 143 to be done in this group. 145 2. Key Words 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [KEYWORDS]. 151 3. Terminology 153 Device Identifier (DI) 155 The identifier used by the network as a handle to control and 156 police the network access of a client. Depending on the access 157 technology, identifier might contain any of IP address, link- 158 layer address, switch port number, etc. of a device. PANA 159 authentication agent keeps a table for binding device 160 identifiers to the PANA clients. At most one PANA client 161 should be associated with a DI on a PANA authentication agent. 163 PANA Client (PaC) 165 The entity wishing to obtain network access from a PANA 166 authentication agent within a network. A PANA client is 167 associated with a network device and a set of credentials to 168 prove its identity within the scope of PANA. 170 PANA Authentication Agent (PAA) 172 The entity whose responsibility is to authenticate the 173 credentials provided by a PANA client and grant network 174 access service to the device associated with the client 175 and identified by a DI. 177 4. Requirements 179 4.1. Authentication 181 4.1.1. Authentication of Client 183 PANA MUST authenticate a PaC for network access. A PaC can be 184 identified by the credentials (identifier, authenticator) supplied 185 by one of the users of the device or the device itself. PANA MUST 186 only grant network access service to the device identified by the 187 DI, rather than granting separate access to multiple simultaneous 188 users of the device. Once the network access is granted to the 189 device, the methods used by the device on arbitrating which one of 190 its users can access the network is outside the scope of PANA. 192 PANA MUST NOT define new security protocols or mechanisms. Instead 193 it must be defined as a "carrier" for such protocols. PANA MUST 194 identify which specific security protocol(s) or mechanism(s) it can 195 carry (the "payload"). The current thinking is that a sufficient 196 solution would be for PANA to carry EAP. If PANA WG decides that 197 extensions to EAP are needed, it will define requirements for an 198 EAP WG instead of defining these extensions. 200 Authentication and encryption of data traffic sent to and from an 201 authenticated PaC is outside the scope of PANA. Providing a complete 202 secure network access solution by also securing router discovery 203 [RDISC], neighbor discovery [NDISC], and address resolution 204 protocols [ARP] is outside the scope as well. 206 Both the PaC and the PAA MUST be able to authenticate each other for 207 network access. Providing capability of only PAA authenticating the 208 PaC is not sufficient. 210 PANA MUST be capable of carrying out both periodic and on-demand re- 211 authentication. Both the PaC and the PAA MUST be able to initiate 212 both the initial authentication and the re-authentication process. 214 When the DI is carried explicitly as part of the PANA payload, the 215 authentication computation MUST also include this field to provide 216 integrity protection for the DI. When the DI is carried implicitly 217 as the source of the PANA message, the protocol has to make sure 218 that the DI's integrity is protected by some other means (e.g., 219 physical verification of incoming port number of the PANA message in 220 the case of switch port number as a DI and PAA co-located with the 221 link-layer access device). Protecting PaCs against DI theft is 222 outside the scope of PANA. 224 4.1.2. Authorization, Accounting and Access Control 226 In addition to carrying authentication information, PANA MUST also 227 provides only a binary authorization to indicate whether the PaC 228 is allowed to access full IP services on the network. Providing 229 finer granularity authorization, such as negotiating QoS parameters, 230 authorizing individual services (http vs. ssh), individual users 231 sharing the same device, etc. is outside the scope of PANA. 233 Providing access control functionality in the network is outside the 234 scope of PANA. Client access authentication should be followed by 235 access control to make sure only authenticated and authorized 236 clients can send and receive IP packets via access network. Access 237 control can involve setting access control lists on the enforcement 238 points. Identification of clients which are authorized to access 239 the network is done by the PANA protocol exchange. Though, 240 transporting the required information to the enforcement points in 241 the network is outside the scope of PANA as well since PANA assumes 242 the PAA is co-located with the enforcement point. 244 Carrying accounting data is outside the scope of PANA. 246 4.1.3. Authentication Backend 248 PANA protocol MUST NOT make any assumptions on the backend 249 authentication protocol or mechanisms. PAA may interact with 250 backend AAA infrastructures such as RADIUS or Diameter, but it is 251 not a requirement. When the access network doesn't rely on a 252 IETF-defined AAA protocol (e.g., RADIUS, Diameter), then it can 253 still use a proprietary backend system, or rely on the information 254 locally stored on the authentication agents. 256 The interaction between the PAA and the backend authentication 257 entities is outside the scope of PANA. 259 4.1.4. Identifiers 261 PANA SHOULD allow various types of identifiers to be used for the 262 PaC (e.g., NAI, IP address, FQDN, etc.) 264 PANA SHOULD allow various types of identifiers to be used as the DI 265 (IP address, link-layer address, port number of a switch, etc.) 267 PAA MUST be able to create a binding between the PaC and the 268 associated DI upon successful PANA exchange. The DI MUST be carried 269 either explicitly as part of the PANA payload, or implicitly as the 270 source of the PANA message, or both. This binding is used for access 271 control and accounting in the network as described in section 4.1.2. 273 4.1.5. IP Address Assignment 275 PANA does not perform any address assignment functions but MUST 276 only be invoked after the client has a usable IP address 277 (e.g., a link-local address in IPv6 or a DHCP-learned address 278 in IPv4) 280 4.2. Network 282 4.2.1. Multi-access 284 Protocol MUST support PaCs with multiple interfaces, and networks 285 with multiple routers on multi-access links. 287 4.2.2. Disconnect Indication 289 PANA MUST NOT assume connection-oriented links. Links may or may not 290 provide disconnect indication. Such notification is desirable in 291 order for the PAA to cleanup resources when a client moves away 292 from the network (e.g., inform the enforcement points that the 293 client is no longer connected). PANA will need to provide a 294 hearbeat-type mechanism to provide this functionality. It's 295 usage will be optional, depending on the specific L2. 297 PANA SHOULD provide a hearbeat-type mechanism to allow PaCs to 298 notify the PAA of their departure from the network. A similar 299 indication SHOULD also be used to let PAA notify a PaC about the 300 discontinuation of the network access. Access discontinuation 301 can happen due to various reasons such as network systems going 302 down, or a change in access policy. 304 4.2.3. Location of PAA 306 The PAA must be on an IP capable network element on the same 307 IP link as the PaC. Hence it can be on the NAS or WLAN AP or first 308 hop router (most likely scenario). The use of PANA when the PAA is 309 not on the same link as the PAA is outside the scope of PANA. 311 Since a PaC maynot be pre-configured with the IP address of PAA, 312 but may have to dynamically discover instead. Therefore PANA 313 protocol must define a dynamic discovery method. Given that 314 the PAA is on the same link as the PaC, there are number 315 of discovery techniques that could be used (e.g., multicast or 316 anycast) by the PaC to find out the address of the PAA. 318 Also, PANA assumes the PAA is co-located with the enforcement 319 point. Network access enforcement can be provided by one or more 320 nodes on the same IP subnet as the client (e.g., multiple routers), 321 or on another subnet in the access domain (e.g., gateway to the 322 Internet, depending on the network architecture). When the PAA and 323 the enforcement point(s) are separated, there needs to be another 324 transport for client provisioning. This transport is needed to 325 create access control lists to allow authenticated and authorized 326 clients on the enforcement points. This transport is outside the 327 scope of PANA. 329 4.2.4. Secure Channel 331 PANA MUST not assume a secure channel between the PaC and the PAA. 332 PANA MUST be able to provide authentication especially in networks 333 which are not protected against eavesdropping and spoofing. PANA 334 MUST provide protection against replay attacks on both PaCs and 335 PAAs. 337 4.3. Interaction with Other Protocols 339 Mobility management is outside the scope of PANA. Though, PANA MUST 340 be able to co-exist and not interfere with various mobility 341 management protocols, such as Mobile IPv4 [MIPV4], Mobile IPv6 342 [MIPV6], fast handover protocols [FMIPV4, FMIPV6], and other 343 standard protocols like IPv6 stateless address auto-configuration 345 [ADDRCONF] (including privacy extensions [PRIVACY]), and DHCP 346 [DHCP]. It MUST NOT make any assumptions on the protocols or 347 mechanisms used for IP address configuration of the PaC. 349 4.4. Performance 351 PANA design SHOULD give consideration to efficient handling of 352 authentication process. This is important for gaining network access 353 with minimum latency. As an example, a method like minimizing the 354 protocol signaling by creating local security associations can be 355 used for this purpose. 357 4.5. Reliability and Congestion Control 359 PANA MUST provide reliability and congestion control. It can do so 360 by using techniques like re-transmissions, cyclic redundancy check, 361 delayed initialization and exponential back-off. 363 4.6. Miscellaneous 365 4.6.1. IP Version Independence 367 PANA MUST work for both IPv4 and IPv6. 369 4.6.2. Denial of Service Attacks 371 PANA MUST be robust against a class of DoS attacks such as blind 372 masquerade attacks through IP spoofing that swamp the PAA in 373 spending much resources and prevent legitimate clients� attempts of 374 network access. 376 4.6.3. Location Privacy 378 Location privacy is outside the scope of PANA. 380 Acknowledgements 382 We would like to thank Basavaraj Patil, Subir Das, and the PANA 383 Working Group members for their valuable contributions to the 384 discussions and preparation of this document. 386 References 388 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 389 Requirement Levels", RFC 2119, March 1997. 391 [8021X] "IEEE Standards for Local and Metropolitan Area Networks: 392 Port Based Network Access Control", IEEE Draft 802.1X/D11, March 393 2001. 395 [PPP] W. Simpson (editor), "The Point-To-Point Protocol (PPP)", STD 396 51, RFC 1661, July 1994. 398 [MIPV4] C. Perkins (editor), "IP Mobility Support", RFC 2002, 399 October 1996. 401 [MIPV6] D. Johnson and C. Perkins, "Mobility Support in IPv6", 402 draft-ietf-mobileip-ipv6-15.txt, July 2001. Work in progress. 404 [MNAAA] C. Perkins, P. Calhoun, "Mobile IPv4 Challenge/Response 405 Extensions", RFC3012, November 2000. 407 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 408 September 1991. 410 [NDISC] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery 411 for IP Version 6 (IPv6)",RFC 2461, December 1998. 413 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 414 RFC 826, November 1982. 416 [FMIPV4] K. ElMalki (editor), et. al., "Low latency Handoffs in 417 Mobile IPv4", November 2001. Work in progress. 419 [FMIPV6] G. Dommety (editor), et. al., "Fast Handovers for Mobile 420 IPv6", July 2001. Work in progress. 422 [DHCP] R. Droms (editor), et. al., "Dynamic Host Configuration 423 Protocol for IPv6", December 2001. Work in progress. 425 [PRIVACY] T. Narten, R. Draves, "Privacy Extensions for Stateless 426 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 428 Authors' Addresses 430 Alper E. Yegin 431 DoCoMo USA Labs 432 181 Metro Drive, Suite 300 433 San Jose, CA, 95110 434 USA 435 Phone: +1 408 451 4743 436 Email: alper@docomolabs-usa.com 438 Yoshihiro Ohba 439 Toshiba America Research, Inc. 440 P.O. Box 136 441 Convent Station, NJ, 07961-0136 442 USA 443 Phone: +1 973 829 5174 444 Email: yohba@tari.toshiba.com 445 Reinaldo Penno 446 Nortel Networks 447 4555 Great America Parkway 448 Santa Clara, CA, 95054 449 USA 450 Phone: +1 408 565 3023 451 Email: rpenno@nortelnetworks.com 453 George Tsirtsis 454 Flarion Technologies 455 Bedminster One 456 135 Route 202/206 South 457 Bedminster, NJ, 07921 458 USA 459 Phone : +44 20 88260073 460 E-mail: G.Tsirtsis@Flarion.com, gtsirt@hotmail.com 462 Cliff Wang 463 Smart Pipes 464 565 Metro Place South 465 Dublin, OH, 43017 466 USA 467 Phone: +1 614 923 6241 468 Email: cwang@smartpipes.com 470 Full Copyright Statement 472 "Copyright (C) The Internet Society (2002). All Rights Reserved. 473 This document and translations of it may be copied and furnished to 474 others, and derivative works that comment on or otherwise explain it 475 or assist in its implementation may be prepared, copied, published 476 and distributed, in whole or in part, without restriction of any 477 kind, provided that the above copyright notice and this paragraph 478 are included on all such copies and derivative works. However, this 479 document itself may not be modified in any way, such as by removing 480 the copyright notice or references to the Internet Society or other 481 Internet organizations, except as needed for the purpose of 482 developing Internet standards in which case the procedures for 483 copyrights defined in the Internet Standards process must be 484 followed, or as required to translate it into languages other than 485 English. 487 The limited permissions granted above are perpetual and will not be 488 revoked by the Internet Society or its successors or assigns. 490 This document and the information contained herein is provided on an 491 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 492 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 493 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 494 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 495 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.