idnits 2.17.1 draft-ietf-nasreq-criteria-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. ** There are 164 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 254 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '... uments of t...' == Line 14 has weird spacing: '...tribute work-...' == Line 18 has weird spacing: '...cuments at a...' == Line 22 has weird spacing: '... The list...' == Line 25 has weird spacing: '... The list ...' == (159 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (24 June 1999) is 9072 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2277' is mentioned on line 138, but not defined ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2284 (ref. 'EAP') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2486 (ref. 'NAI') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 1510 (ref. 'KERBEROS') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) Summary: 16 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NASREQ Working Group M. Beadles 2 INTERNET-DRAFT UUNET Technologies 3 Category: Informational 4 5 24 June 1999 7 Criteria for Evaluating Network Access Server Protocols 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. Internet-Drafts are working doc- 13 uments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference mate- 20 rial or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 The distribution of this draft is unlimited. It is filed as 29 and expires December 24, 1999. 30 Please send comments to the author. 32 2. Copyright Statement 34 Copyright (C) The Internet Society 1999. All Rights Reserved. 36 3. Abstract 38 This document analyzes and defines requirements for protocols used by 39 Network Access Servers (NAS). Protocols used by NAS's may be divided 40 into four spaces: Access protocols, Network protocols, AAA protocols, 41 and Management protocols. Primary attention is given to setting 42 requirements for AAA protocols, since that space is currently the 43 least well defined. 45 4. Requirements language 47 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 48 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 49 described in [KEYWORDS]. 51 5. Introduction 53 This document analyzes and defines requirements for protocols used by 54 Network Access Servers (NAS). Protocols used by NAS's may be divided 55 into four spaces: Access protocols, Network protocols, AAA protocols, 56 and Device Management protocols. The primary focus of this document 57 is on AAA protocols. The reference model of a NAS used by this docu- 58 ment, and the analysis of the functions of a NAS which led to the 59 development of these requirements, may be found in [NAS-MODEL]. 61 6. Access Protocol Requirements 63 There are three basic types of access protocols used by NAS's. First 64 are the traditional telephony-based access protocols, which interface 65 to the NAS via a modem or terminal adapter or similar device. These 66 protocols typically support asynchronous or synchronous PPP carried 67 over a telephony protocol. Second are broadband pseudo-telephony 68 access protocols, which are carried over xDSL or cable modems, for 69 example. These protocols typically support an encapsulation method 70 such as PPP over Ethernet [PPPOE]. Finally are the virtual access 71 protocols used by NAS's that terminate tunnels. One example of this 72 type of protocol is L2TP [L2TP]. 74 It is a central assumption of the NAS model used here that a NAS 75 accepts multiple point-to-point [PPP] links via one of the above 76 access protocol or protocols. Therefore, at a minimum, any NAS access 77 protocol MUST be able to carry PPP. The exception to this requirement 78 is for NAS's that support legacy text login methods such as telnet 79 [TELNET], rlogin, or LAT. Only these access protocols are exempt from 80 the requirement to support PPP. 82 7. Network Protocol Requirements 84 The network protocols supported by a NAS depend entirely on the kind 85 of network to which a NAS is providing access. This document does not 86 impose any additional requirements on network protocols beyond the 87 protocol specifications themselves. For example, if a NAS that serves 88 a routed network includes internet routing functionality, then that 89 NAS must adhere to [ROUTING-REQUIREMENTS], but there are no additional 90 protocol requirements imposed by virtue of the device being a NAS. 92 8. AAA Protocol Requirements 94 8.1. General protocol characteristics 96 There are certain general characteristics that any AAA protocol used 97 by NAS's must meet. Note that the transport requirements for authen- 98 tication/authorization are not necessarily the same as those for 99 accounting/auditing. An AAA protocol suite MAY use the same transport 100 and protocol for both functions, but this is not strictly required. 102 The accounting and auditing functions of the AAA protocol are used for 103 network planning, resource management, policy decisions, and other 104 functions that require accurate knowledge of the state of the NAS. 105 NAS operators need to be able to engineer their network usage measure- 106 ment systems to a predictable level of accuracy. Therefore, an AAA 107 protocol MUST provide a means of guaranteed delivery of accounting 108 information between the NAS and the AAA Server. 110 Very large scale NAS's that serve up to thousands of simultaneous ses- 111 sions are now being deployed. This means that, in the extreme, there 112 may be an almost constant exchange of many small packets between the 113 NAS and the AAA server. An AAA protocol SHOULD be carried on a trans- 114 port protocol that is optimized for a long-term exchange of small 115 packets in a stream between a pair of hosts. 117 In order to operationally support these large streams of data, load 118 balancing of AAA servers may be required. The AAA protocol MUST allow 119 NAS's to balance AAA sessions between two or more AAA servers. The 120 load balancing mechanism SHOULD be built in to the protocol, but if 121 not, the protocol MUST NOT prevent external load balancing mechanisms 122 from operating. 124 The AAA protocol design cannot allow for a single point of failure 125 during the AAA process. The AAA protocol MUST allow any sessions 126 between a NAS and a given AAA server to fail over to a secondary 127 server without loss of state information. The fail-over mechanism 128 SHOULD be built in to the protocol, but if not, the protocol MUST NOT 129 prevent external fail-over mechanisms from operating. 131 Next-generation NAS's will be built that provide access to IPv6 net- 132 works. Wherever internet protocol addresses are carried within the 133 AAA protocol, the protocol MUST support both IPv4 and IPv6 [IPV6] 134 addresses. 136 Wherever textual information is carried within the AAA protocol, the 137 protocol MUST comply with the IETF Policy on Character Sets and Lan- 138 guages [RFC 2277]. 140 NAS and AAA development is always progressing. In order to prevent 141 the AAA protocol from being a limiting factor in NAS and AAA Server 142 development, the AAA protocol MUST provide a built-in extensibility 143 mechanism. This mechanism MUST include a means for adding new stan- 144 dard extensions, and also MUST include a means for individual vendors 145 to add value through vendor-specific extensions. 147 Dial roaming is now a nearly ubiquitous service. NAS's operated by 148 one authority provide network access services for clients operated by 149 another authority, to network destinations operated by yet another 150 authority. This type of arrangement is of growing importance. There- 151 fore an AAA protocol MUST support AAA services that travel between 152 multiple domains of authority. This document does not specify how 153 this must be implemented (for example, via proxy, via brokering, via a 154 combination of methods), but it does set strict requirements that an 155 AAA protocol MUST NOT use a model that assumes a single domain of 156 authority. The AAA protocol MUST also meet the protocol requirements 157 specified in [ROAMING-REQUIREMENTS]. 159 8.2. Authentication and User Security Requirements 161 End users who are requesting network access through a NAS may present 162 various types of credentials. It is the purpose of the AAA protocol 163 to transport these credentials between the NAS and the AAA server. 164 The AAA protocol MUST also support transport of credentials from the 165 AAA server to the NAS for the purpose of mutual (bi-directional) 166 authentication. 168 The AAA protocol MUST support re-authentication at any time during the 169 course of a session, initiated from either end of the user session. 171 The AAA protocol MUST be able to support multi-phase authentication 172 methods, including support for: 173 -Prompting from the NAS to the user 175 -A series of challenges and responses of arbitrary length 177 -An authentication failure reason to be transmitted from the NAS 178 to the user 180 -Callback to a pre-determined phone number 182 Many authentication protocols are defined within the framework of PPP. 183 The AAA protocol MUST be able to act as an intermediary protocol 184 between the authenticatee and the authenticator for the following 185 authentication protocols: 186 -PPP Password Authentication Protocol [PPP] 188 -PPP Challenge Handshake Authentication Protocol [CHAP] 190 -PPP Extensible Authentication Protocol [EAP] 192 The following are common types of credentials used for user identifi- 193 cation. The AAA protocol MUST be able to carry the following types of 194 identity credentials: 196 -A user name in the form of a Network Access Identifier [NAI]. 198 -An Extensible Authentication Protocol [EAP] Identity Request 199 Type packet. 201 -Telephony dialing information such as Dialed Number Identifica- 202 tion Service (DNIS) and Caller ID. 203 If a particular type of identity credential is not needed for a par- 204 ticular user session, the AAA protocol MUST NOT require that dummy 205 credentials be filled in. 207 The following are common types of credentials used for authentication. 208 The AAA protocol MUST be able to carry the following types of authen- 209 ticating credentials at a minimum: 210 -A secret or password. 212 -A response to a challenge presented by the NAS to the user 214 -A one-time password 216 -An X.509 digital certificate [X.509] 218 -A Kerberos v5 ticket [KERBEROS] 220 Security protocol development is going on constantly as new threats 221 are identified and better cracking methods are developed. Today's 222 secure authentication methods may be proven insecure tomorrow. The 223 AAA protocol MUST provide an extension mechanism so that new authenti- 224 cation credential types can be added. 226 8.3. Authorization, Policy, and Resource management 228 8.3.1. General Authorization Requirements 230 In all cases, authorization data sent from the NAS to the AAA server 231 is to be regarded as information or "hints", and not directives. The 232 AAA protocol MUST be designed so that the AAA server makes all final 233 authorization decisions and does not depend on a certain state being 234 expected by the NAS. 236 The AAA protocol MUST support dynamic re-authorization at any time 237 during a user session. This re-authorization may be initiated in 238 either direction. This dynamic re-authorization capability MUST 239 include the capability to request a NAS to disconnect a user on 240 demand. 242 8.3.2. Policy Requirements - Access Restrictions 244 The AAA protocol serves as a primary means of gathering data used for 245 making Policy decisions for network access. Therefore, the AAA pro- 246 tocol MUST allow network operators to make policy decisions based on 247 the following parameters: 249 -Time/day restrictions. The AAA protocol MUST be able to provide 250 an unambiguous time stamp, NAS time zone indication, and date 251 indication to the AAA server in the Authorization information. 253 -Location restrictions: The AAA protocol MUST be able to provide 254 an unambiguous location code that reflects the geographic loca- 255 tion of the NAS. 257 -Dialing restrictions: The AAA protocol MUST be able to provide 258 accurate dialed and dialing station indications. 260 -Concurrent login limitations: The AAA protocol MUST allow an 261 AAA Server to limit concurrent logins by a particular user or 262 group of users. This mechanism does not need to be explicitly 263 built into the AAA protocol, but the AAA protocol must provide 264 sufficient authorization information for an AAA server to make 265 that determination through an out-of-band mechanism. 267 8.3.3. Policy Requirements - Authorization Profiles 269 The AAA protocol is used to enforce policy at the NAS. Essentially, 270 on granting of access, a particular access profile is applied to the 271 user's session. The AAA protocol MUST at a minimum provide a means of 272 applying profiles containing the following types of information: 274 -IP Address assignment: The AAA protocol MUST provide a means of 275 assigning an IPv4 or IPv6 address to an incoming user. 277 -Protocol Filter application: The AAA protocol MUST provide a 278 means of applying protocol filters to user sessions. Two differ- 279 ent methods MUST be supported. First, the AAA protocol MUST pro- 280 vide a means of selecting a protocol filter by reference to an 281 identifier, with the details of the filter action being specified 282 out of band. Second, the AAA protocol MUST provide a means of 283 passing a protocol filter by value. This means explicit passing 284 of pass/block information by address range, TCP/UDP port number, 285 and IP protocol number at a minimum. 287 -Compulsory Tunneling: The AAA protocol MUST provide a means of 288 directing a NAS to build a tunnel or tunnels to a specified end- 289 point. It MUST support creation of multiple simultaneous tunnels 290 in a specified order. The protocol MUST allow, at a minimum, 291 specification of the tunnel endpoints, tunneling protocol type, 292 underlying tunnel media type, and tunnel authentication 293 credentials (if required by the tunnel type). The AAA protocol 294 MUST support at least the creation of tunnels using the L2TP 295 [L2TP], ESP [ESP], and AH [AH] protocols. The protocol MUST pro- 296 vide means of adding new tunnel types as they are standardized. 298 -Routing: The AAA protocol MUST provide a means of assigning a 299 particular static route to an incoming user session. 301 -Expirations/timeouts: The AAA protocol MUST provide a means of 302 communication session expiration information to a NAS. Types of 303 expirations that MUST be supported are: total session time, idle 304 time, total bytes transmitted, and total bytes received. 306 -Quality of Service: The AAA protocol MUST provide a means of 307 applying Quality of Service parameters to individual user ses- 308 sions. 310 8.3.4. Resource Management Requirements 312 The AAA protocol is a means for network operators to perform manage- 313 ment of network resources. The AAA protocol MUST provide a means of 314 collecting resource state information, and controlling resource allo- 315 cation for the following types of network resources. 317 -Network bandwidth usage per session, including multilink ses- 318 sions. 320 -Access port usage. 322 -IP Addresses and pools. 324 Resource management MUST be supported on demand at any time during the 325 course of a user session. 327 8.4. Accounting and Auditing Requirements 329 NAS operators often require a real time view onto the status of ses- 330 sions served by a NAS. Therefore, the AAA protocol MUST support real- 331 time delivery of accounting and auditing information. In this con- 332 text, real time is defined as accounting information delivery begin- 333 ning within one second of the triggering event. 335 There may be delays associated with the delivery of accounting infor- 336 mation. The NAS operator will desire to know the time an event actu- 337 ally occurred, rather than simply the time when notification of the 338 event was received. Therefore, the AAA protocol MUST carry an unam- 339 biguous time stamp associated with each accounting event. 341 At a minimum, the AAA protocol MUST support delivery of accounting 342 information triggered by the following events: 344 -Start of a user session 346 -End of a user session 348 -Expiration of a predetermined repeating time interval during a 349 user session. The AAA protocol MUST provide a means for the AAA 350 server to request that a NAS use a certain interval accounting 351 time. 353 -Dynamic re-authorization during a user session (e.g., new 354 resources being delivered to the user) 356 -Dynamic re-authentication during a user session 358 NAS operators need to maintain an accurate view onto the status of 359 sessions served by a NAS, even through failure of an AAA server. 360 Therefore, the AAA protocol MUST support a means of requesting current 361 session state from the NAS on demand. 363 At a minimum, the AAA protocol MUST support delivery of the following 364 types of accounting/auditing data: 365 -All parameters used to authenticate a session. 367 -Details of the authorization profile that was applied to the 368 session. 370 -The duration of the session. 372 -The cumulative number of bytes sent by the user during the ses- 373 sion. 375 -The cumulative number of bytes received by the user during the 376 session. 378 -The cumulative number of packets sent by the user during the 379 session. 381 -The cumulative number of packets received by the user during the 382 session. 384 -Details of the access protocol used during the session (port 385 type, connect speeds, etc.) 387 9. Device Management Protocols 389 This document does not currently specify any requirements for device 390 management protocols. 392 10. Security considerations 394 It is poor security practice for a NAS to communicate with an AAA 395 server that is not trusted, and vice versa. At a minimum, the AAA 396 protocol MUST support use of a secret shared pairwise between each NAS 397 and AAA server to mutually verify identity. However, AAA server/NAS 398 identity verification based solely on shared secrets can be difficult 399 to deploy properly at large scale, and it can be tempting for NAS 400 operators to use a single shared secret (that rarely changes) across 401 all NAS's. This can lead to easy compromise of the secret. There- 402 fore, the AAA protocol SHOULD also support verification of identity 403 using a public-key infrastructure that supports expiration and revoca- 404 tion of keys. 406 When passwords are used as authentication credentials by users, the 407 AAA protocol MUST provide a secure means of hiding the password from 408 end to end of the AAA conversation. When a challenge/response mecha- 409 nism is used, the AAA protocol MUST also prevent against replay 410 attacks. 412 When an AAA protocol passes credentials that will be used to authenti- 413 cate compulsory tunnels, the AAA protocol MUST provide a secure means 414 of securing the credentials from end to end of the AAA conversation. 415 The AAA protocol MUST also provide protection against replay attacks 416 in this situation. 418 Note that accounting and auditing data are operationally sensitive 419 information that may require measures to assure integrity and confi- 420 dentiality. 422 Where an AAA architecture spans multiple domains of authority, AAA 423 information may need to cross trust boundaries. In this situation, a 424 NAS may operate as a shared device that services multiple administra- 425 tive domains. Network operators must take this into consideration 426 when deploying NAS's and AAA Servers. 428 11. References 430 [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate 431 Requirement Levels." RFC 2119, Harvard University, March 1997. 433 [NAS-MODEL] D. Mitton, M. Beadles. "Network Access Server Require- 434 ments Next Generation (NASREQNG) NAS Model." Work in progress. 436 [PPPOE] L. Mamakos et al. "A Method for Transmitting PPP Over Ether- 437 net (PPPoE)." RFC 2516, UUNET Technologies, Inc., February 1999. 439 [L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)." 440 Work in progress. 442 [PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661, 443 Daydreamer, July 1994. 445 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specification." 446 STD 8, RFC 854, ISI, May 1983. 448 [ROUTING-REQUIREMENTS] F. Baker. "Requirements for IP Version 4 449 Routers." RFC 1812, Cisco Systems, June 1995. 451 [IPV6] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6) 452 Specification." RFC 2460, Cisco, Nokia, December 1998. 454 [RFC 2277] H. Alvestrand. "IETF Policy on Character Sets and Lan- 455 guages." RFC 2277, UNINETT, January 1998. 457 [CHAP] W. Simpson. "PPP Challenge Handshake Authentication Protocol 458 (CHAP)." RFC 1994, Daydreamer, August 1996. 460 [EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- 461 col (EAP)." RFC 2284, Merit Network, Inc., March 1998. 463 [NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC 464 2486, Microsoft, WorldCom Advanced Networks, January 1999. 466 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 467 Open Systems Interconnection - The Directory: Authentication Frame- 468 work, June 1997. 470 [KERBEROS] J. Kohl, C. Neuman. "The Kerberos Network Authentication 471 Service (V5)." RFC 1510, Digital Equipment Corporation, ISI, Septem- 472 ber 1993. 474 [ESP] S. Kent, R. Atkinson. "IP Encapsulating Security Payload 475 (ESP)." RFC 2406, BBN Corp, @Home Network, November 1998. 477 [AH] S. Kent, R. Atkinson. "IP Authentication Header (AH)." RFC 478 2402, BBN Corp, @Home Network, November 1998. 480 [ROAMING-REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating 481 Roaming Protocols." RFC 2477, Microsoft, January 1999. 483 12. Author's Address 485 Mark Anthony Beadles 486 UUNET, an MCI WorldCom Company 487 5000 Britton Rd. 488 Hilliard, OH 43026 490 Phone: 614-723-1941 491 EMail: mbeadles@wcom.net 492 13. Full Copyright Statement 494 Copyright (C) The Internet Society (1999). All Rights Reserved. 496 This document and translations of it may be copied and furnished to 497 others, and derivative works that comment on or otherwise explain it 498 or assist in its implmentation may be prepared, copied, published and 499 distributed, in whole or in part, without restriction of any kind, 500 provided that the above copyright notice and this paragraph are 501 included on all such copies and derivative works. However, this docu- 502 ment itself may not be modified in any way, such as by removing the 503 copyright notice or references to the Internet Society or other Inter- 504 net organizations, except as needed for the purpose of developing 505 Internet standards in which case the procedures for copyrights defined 506 in the Internet Standards process must be followed, or as required to 507 translate it into languages other than English. The limited permis- 508 sions granted above are perpetual and will not be revoked by the 509 Internet Society or its successors or assigns. This document and the 510 information contained herein is provided on an "AS IS" basis and THE 511 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 512 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 513 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 514 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 515 PARTICULAR PURPOSE." 517 14. Expiration Date 519 This document is filed as , and 520 expires December 24, 1999.