idnits 2.17.1 draft-ietf-nasreq-criteria-04.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: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 19 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 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 == Line 28 has weird spacing: '...The distribut...' == Line 399 has weird spacing: '...ization infor...' == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-ietf-nasreq-nas-model - is the name correct? ** 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) ** Obsolete normative reference: RFC 2138 (ref. 'RADIUS') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2139 (ref. 'RADIUS-ACCOUNTING') (Obsoleted by RFC 2866) Summary: 16 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NASREQ Working Group M. Beadles 2 INTERNET-DRAFT SmartPipes, Inc. 3 Category: Informational D. Mitton 4 2 March 2000 Nortel Networks 6 Criteria for Evaluating Network Access Server Protocols 7 draft-ietf-nasreq-criteria-04.txt 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 docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and its 14 working groups. Note that other groups may also distribute working doc- 15 uments 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 material 20 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 and expires September 2000. Please send 30 comments to the authors. 32 2. Copyright Statement 34 Copyright (C) The Internet Society 2000. All Rights Reserved. 36 3. Abstract 38 This document defines requirements for protocols used by Network Access 39 Servers (NAS). Protocols used by NAS's may be divided into four spaces: 40 Access protocols, Network protocols, AAA protocols, and Management pro- 41 tocols. Primary attention is given to setting requirements for AAA 42 protocols, since that space is currently the least well defined. 44 4. Requirements language 46 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 47 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 48 described in [KEYWORDS]. 50 5. Introduction 52 This document defines requirements for protocols used by Network Access 53 Servers (NAS). Protocols used by NAS's may be divided into four spaces: 54 Access protocols, Network protocols, AAA protocols, and Device Manage- 55 ment protocols. The primary focus of this document is on AAA protocols. 56 The reference model of a NAS used by this document, and the analysis of 57 the functions of a NAS which led to the development of these require- 58 ments, may be found in [NAS-MODEL]. 60 6. Access Protocol Requirements 62 There are three basic types of access protocols used by NAS's. First are 63 the traditional telephony-based access protocols, which interface to the 64 NAS via a modem or terminal adapter or similar device. These protocols 65 typically support asynchronous or synchronous PPP [PPP] carried over a 66 telephony protocol. Second are broadband pseudo-telephony access proto- 67 cols, which are carried over xDSL or cable modems, for example. These 68 protocols typically support an encapsulation method such as PPP over 69 Ethernet [PPPOE]. Finally are the virtual access protocols used by 70 NAS's that terminate tunnels. One example of this type of protocol is 71 L2TP [L2TP]. 73 It is a central assumption of the NAS model used here that a NAS accepts 74 multiple point-to-point links via one of the above access protocols. 75 Therefore, at a minimum, any NAS access protocol MUST be able to carry 76 PPP. The exception to this requirement is for NAS's that support legacy 77 text login methods such as telnet [TELNET], rlogin, or LAT. Only these 78 access protocols are exempt from the requirement to support PPP. 80 7. Network Protocol Requirements 82 The network protocols supported by a NAS depend entirely on the kind of 83 network to which a NAS is providing access. This document does not 84 impose any additional requirements on network protocols beyond the pro- 85 tocol specifications themselves. For example, if a NAS that serves a 86 routed network includes internet routing functionality, then that NAS 87 must adhere to [ROUTING-REQUIREMENTS], but there are no additional pro- 88 tocol requirements imposed by virtue of the device being a NAS. 90 8. AAA Protocol Requirements 92 8.1. General protocol characteristics 94 There are certain general characteristics that any AAA protocol used by 95 NAS's must meet. Note that the transport requirements for authentica- 96 tion/authorization are not necessarily the same as those for account- 97 ing/auditing. An AAA protocol suite MAY use the same transport and pro- 98 tocol for both functions, but this is not strictly required. 100 8.1.1. Transport requirements 102 8.1.1.1. Transport independence 104 The AAA protocol MUST be transport independent, and MUST be capable of 105 using both TCP and UDP as a transport. Additionally, the AAA protocol 106 SHOULD be designed to easily support any new transport protocols devel- 107 oped by the Internet standards community. 109 8.1.1.2. Scalability 111 Very large scale NAS's that serve up to thousands of simultaneous ses- 112 sions are now being deployed. And a single server system may service a 113 large number of ports. This means that, in the extreme, there may be an 114 almost constant exchange of many small packets between the NASes and the 115 AAA server. An AAA protocol transport SHOULD support being optimized 116 for a long-term exchange of small packets in a stream between a pair of 117 hosts. 119 The protocol MUST be designed to support a large number of ports, 120 clients, and concurrent sessions. Examples of poor design would include 121 message identifiers which values are so small that queues and reception 122 windows wrap under load, unique session identifier ranges that are so 123 small that they wrap within the lifetime of potential long sessions, 124 counter values that cannot accomodate reasonable current and future 125 bandwidth usage, and computational processes with high overhead that 126 must be performed frequently. 128 8.1.1.3. Support for Multiple AAA Servers and Failure Recovery 130 In order to operationally support large loads, load balancing and fail- 131 over to multiple AAA servers will be required. The AAA protocol MUST 132 provide for NAS's to balance individual AAA requests between two or more 133 AAA servers. The load balancing mechanism SHOULD be built in to the AAA 134 protocol itself. 136 The AAA protocol MUST be able to detect a failure of the transport pro- 137 tocol to deliver a message or messages within a known and controllable 138 time period, so it can engage retransmission or server fail-over pro- 139 cesses. The reliability and robustness of authentication requests MUST 140 be predicable and configurable. 142 The AAA protocol design MUST NOT introduce a single point of failure 143 during the AAA process. The AAA protocol MUST allow any sessions 144 between a NAS and a given AAA server to fail-over to a secondary server 145 without loss of state information. This fail-over mechanism SHOULD be 146 built in to the AAA protocol itself. 148 8.1.1.4. Support for Multiple Administrative Domains 150 NAS's operated by one authority provide network access services for 151 clients operated by another authority, to network destinations operated 152 by yet another authority. This type of arrangement is of growing impor- 153 tance; for example, dial roaming is now a nearly ubiquitous service. 154 Therefore, the AAA protocol MUST support AAA services that travel 155 between multiple domains of authority. The AAA protocol MUST NOT use a 156 model that assumes a single domain of authority. 158 The AAA protocol MUST NOT dictate particular business models for the 159 relationship between the administrative domains. The AAA protocol MUST 160 support proxy, and in addition SHOULD support other multi-domain rela- 161 tionships such as brokering and referral. 163 The AAA protocol MUST also meet the protocol requirements specified in 164 [ROAMING-REQUIREMENTS]. 166 8.1.2. Attribute-Value Protocol Model 168 Years of operational experience with AAA protocols and NAS's has proven 169 that the Attribute-Value protocol model is an optimal representation of 170 AAA data. The protocol SHOULD use an Attribute-Value representation for 171 AAA data. This document will assume such a model. Even if the AAA pro- 172 tocol does not use this as an on-the-wire data representation, 173 Attribute-Value can serve as abstraction for discussing AAA information. 175 Experience has also shown that attribute space tends to run out quickly. 176 In order to provide room for expansion in the attribute space, the AAA 177 protocol MUST support a minimum of 64K Attributes (16 bits), each with a 178 minimum length of 64K (16 bits). 180 8.1.2.1. Attribute Data Types 182 The AAA protocol MUST support simple attribute data types, including 183 integer, enumeration, text string, IP address, and date/time. The AAA 184 protocol MUST also provide some support for complex structured data 185 types. Wherever IP addresses are carried within the AAA protocol, the 186 protocol MUST support both IPv4 and IPv6 [IPV6] addresses. Wherever text 187 information is carried within the AAA protocol, the protocol MUST comply 188 with the IETF Policy on Character Sets and Languages [RFC 2277]. 190 8.1.2.2. Minimum Set of Attributes 192 At a minimum, the AAA protocol MUST support, or be easily extended to 193 support, the set of attributes supported by RADIUS [RADIUS] and RADIUS 194 Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol does not sup- 195 port this complete set of attributes, then an extension to that protocol 196 MUST be defined which supports this set. 198 8.1.2.3. Attribute Extensibility 200 NAS and AAA development is always progressing. In order to prevent the 201 AAA protocol from being a limiting factor in NAS and AAA Server develop- 202 ment, the AAA protocol MUST provide a built-in extensibility mechanism, 203 which MUST include a means for adding new standard attribute extensions. 204 This MUST include a method for registering or requesting extensions 205 through IANA, so that long-term working group involvement is not 206 required to create new attribute types. Ideally, the AAA protocol 207 SHOULD separate specification of the transport from specification of the 208 attributes. 210 The AAA protocol MUST include a means for individual vendors to add 211 value through vendor-specific attributes and SHOULD include support for 212 vendor-specific data types. 214 8.1.3. Security Requirements 216 8.1.3.1. Mutual Authentication 218 It is poor security practice for a NAS to communicate with an AAA server 219 that is not trusted, and vice versa. The AAA protocol MUST provide 220 mutual authentication between AAA server and NAS. 222 8.1.3.2. Shared Secrets 224 At a minimum, the AAA protocol SHOULD support use of a secret shared 225 pairwise between each NAS and AAA server to mutually verify identity. 226 This is intended for small-scale deployments. The protocol MAY provide 227 stronger mutual security techniques. 229 8.1.3.3. Public Key Security 231 AAA server/NAS identity verification based solely on shared secrets can 232 be difficult to deploy properly at large scale, and it can be tempting 233 for NAS operators to use a single shared secret (that rarely changes) 234 across all NAS's. This can lead to an easy compromise of the secret. 235 Therefore, the AAA protocol MUST also support mutual verification of 236 identity using a public-key infrastructure that supports expiration and 237 revocation of keys. 239 8.1.3.4. Encryption of Attributes 241 Some attributes are more operationally sensitive than others. Also, in 242 a multi-domain scenario, attributes may be inserted by servers from dif- 243 ferent administrative domains. Therefore, the AAA protocol MUST support 244 selective encryption of attributes on an attribute-by-attribute basis, 245 even within the same message. This requirement applies equally to 246 Authentication, Authorization, and Accounting data. 248 8.2. Authentication and User Security Requirements 250 8.2.1. Authentication protocol requirements 252 End users who are requesting network access through a NAS will present 253 various types of credentials. It is the purpose of the AAA protocol to 254 transport these credentials between the NAS and the AAA server. 256 8.2.1.1. Bi-directional Authentication 258 The AAA protocol MUST support transport of credentials from the AAA 259 server to the NAS, between the User and the NAS, and between the NAS and 260 the AAA server. 262 8.2.1.2. Periodic Re-Authentication 264 The AAA protocol MUST support re-authentication at any time during the 265 course of a session, initiated from either the NAS or the AAA server. 266 This is a requirement of CHAP. [CHAP] 268 8.2.1.3. Multi-phase Authentication 270 The AAA protocol MUST be able to support multi-phase authentication 271 methods, including but not limited to support for: 273 -Text prompting from the NAS to the user 275 -A series of binary challenges and responses of arbitrary length 277 -An authentication failure reason to be transmitted from the NAS to 278 the user 280 -Callback to a pre-determined phone number 282 8.2.1.4. Extensible Authentication Types 284 Security protocol development is going on constantly as new threats are 285 identified and better cracking methods are developed. Today's secure 286 authentication methods may be proven insecure tomorrow. The AAA proto- 287 col MUST provide some support for addition of new authentication creden- 288 tial types. 290 8.2.2. Authentication Attribute Requirements 292 In addition to the minimum attribute set, the AAA protocol must support 293 and define attributes that provide the following functions: 295 8.2.2.1. PPP Authentication protocols 297 Many authentication protocols are defined within the framework of PPP. 298 The AAA protocol MUST be able to act as an intermediary protocol between 299 the authenticatee and the authenticator for the following authentication 300 protocols: 302 -PPP Password Authentication Protocol [PPP] 304 -PPP Challenge Handshake Authentication Protocol [CHAP] 306 -PPP Extensible Authentication Protocol [EAP] 308 8.2.2.2. User Identification 310 The following are common types of credentials used for user identifica- 311 tion. The AAA protocol MUST be able to carry the following types of 312 identity credentials: 314 -A user name in the form of a Network Access Identifier [NAI]. 316 -An Extensible Authentication Protocol [EAP] Identity Request Type 317 packet. 319 -Telephony dialing information such as Dialed Number Identification 320 Service (DNIS) and Caller ID. 322 If a particular type of authentication credential is not needed for a 323 particular user session, the AAA protocol MUST NOT require that dummy 324 credentials be filled in. That is, the AAA protocol MUST support autho- 325 rization by identification or assertion only. 327 8.2.2.3. Authentication Credentials 329 The following are common types of credentials used for authentication. 330 The AAA protocol MUST be able to carry the following types of authenti- 331 cating credentials at a minimum: 333 -A secret or password. 335 -A response to a challenge presented by the NAS to the user 337 -A one-time password 339 -An X.509 digital certificate [X.509] 341 -A Kerberos v5 ticket [KERBEROS] 343 8.2.3. Authentication Protocol Security Requirements 345 8.2.3.1. End-to-End Hiding of Credentials 347 Where passwords are used as authentication credentials, the AAA protocol 348 MUST provide a secure means of hiding the password from intermediates in 349 the AAA conversation. Where challenge/response mechanisms are used, the 350 AAA protocol MUST also prevent against replay attacks. 352 8.3. Authorization, Policy, and Resource management 354 8.3.1. Authorization Protocol Requirements 356 In all cases, the protocol MUST specify that authorization data sent 357 from the NAS to the AAA server is to be regarded as information or 358 "hints", and not directives. The AAA protocol MUST be designed so that 359 the AAA server makes all final authorization decisions and does not 360 depend on a certain state being expected by the NAS. 362 8.3.1.1. Dynamic Authorization 364 The AAA protocol MUST support dynamic re-authorization at any time dur- 365 ing a user session. This re-authorization may be initiated in either 366 direction. This dynamic re-authorization capability MUST include the 367 capability to request a NAS to disconnect a user on demand. 369 8.3.1.2. Resource Management 371 Resource management MUST be supported on demand by the NAS or AAA Server 372 at any time during the course of a user session. 374 8.3.2. Authorization Attribute Requirements 376 8.3.2.1. Authorization Attribute Requirements - Access Restrictions 378 The AAA protocol serves as a primary means of gathering data used for 379 making Policy decisions for network access. Therefore, the AAA protocol 380 MUST allow network operators to make policy decisions based on the fol- 381 lowing parameters: 383 -Time/day restrictions. The AAA protocol MUST be able to provide 384 an unambiguous time stamp, NAS time zone indication, and date indi- 385 cation to the AAA server in the Authorization information. 387 -Location restrictions: The AAA protocol MUST be able to provide 388 an unambiguous location code that reflects the geographic location 389 of the NAS. Note that this is not the same type of thing as either 390 the dialing or dialed station. 392 -Dialing restrictions: The AAA protocol MUST be able to provide 393 accurate dialed and dialing station indications. 395 -Concurrent login limitations: The AAA protocol MUST allow an AAA 396 Server to limit concurrent logins by a particular user or group of 397 users. This mechanism does not need to be explicitly built into 398 the AAA protocol, but the AAA protocol must provide sufficient 399 authorization information for an AAA server to make that determi- 400 nation through an out-of-band mechanism. 402 8.3.2.2. Authorization Attribute Requirements - Authorization Profiles 404 The AAA protocol is used to enforce policy at the NAS. Essentially, on 405 granting of access, a particular access profile is applied to the user's 406 session. The AAA protocol MUST at a minimum provide a means of applying 407 profiles containing the following types of information: 409 -IP Address assignment: The AAA protocol MUST provide a means of 410 assigning an IPv4 or IPv6 address to an incoming user. 412 -Protocol Filter application: The AAA protocol MUST provide a 413 means of applying IP protocol filters to user sessions. Two dif- 414 ferent methods MUST be supported. 416 First, the AAA protocol MUST provide a means of selecting a proto- 417 col filter by reference to an identifier, with the details of the 418 filter action being specified out of band. The AAA protocol SHOULD 419 define this out-of-band reference mechanism. 421 Second, the AAA protocol MUST provide a means of passing a protocol 422 filter by value. This means explicit passing of pass/block infor- 423 mation by address range, TCP/UDP port number, and IP protocol num- 424 ber at a minimum. 426 -Compulsory Tunneling: The AAA protocol MUST provide a means of 427 directing a NAS to build a tunnel or tunnels to a specified end- 428 point. It MUST support creation of multiple simultaneous tunnels 429 in a specified order. The protocol MUST allow, at a minimum, 430 specification of the tunnel endpoints, tunneling protocol type, 431 underlying tunnel media type, and tunnel authentication credentials 432 (if required by the tunnel type). The AAA protocol MUST support at 433 least the creation of tunnels using the L2TP [L2TP], ESP [ESP], and 434 AH [AH] protocols. The protocol MUST provide means of adding new 435 tunnel types as they are standardized. 437 -Routing: The AAA protocol MUST provide a means of assigning a 438 particular static route to an incoming user session. 440 -Expirations/timeouts: The AAA protocol MUST provide a means of 441 communication session expiration information to a NAS. Types of 442 expirations that MUST be supported are: total session time, idle 443 time, total bytes transmitted, and total bytes received. 445 -Quality of Service: The AAA protocol MUST provide a means for 446 supplying Quality of Service parameters to the NAS for individual 447 user sessions. 449 8.3.2.3. Resource Management Requirements 451 The AAA protocol is a means for network operators to perform management 452 of network resources. The AAA protocol MUST provide a means of collect- 453 ing resource state information, and controlling resource allocation for 454 the following types of network resources. 456 -Network bandwidth usage per session, including multilink sessions. 458 -Access port usage, including concurrent usage and usage pools. 460 -Connect time. 462 -IP Addresses and pools. 464 -Compulsory tunnel limits. 466 8.3.3. Authorization Protocol Security Requirements 468 8.3.3.1. Security of Compulsory Tunnel Credentials 470 When an AAA protocol passes credentials that will be used to authenti- 471 cate compulsory tunnels, the AAA protocol MUST provide a means of secur- 472 ing the credentials from end-to-end of the AAA conversation. The AAA 473 protocol MUST also provide protection against replay attacks in this 474 situation. 476 8.4. Accounting and Auditing Requirements 478 8.4.1. Accounting Protocol Requirements 480 8.4.1.1. Guaranteed Delivery 482 The accounting and auditing functions of the AAA protocol are used for 483 network planning, resource management, policy decisions, and other func- 484 tions that require accurate knowledge of the state of the NAS. NAS 485 operators need to be able to engineer their network usage measurement 486 systems to a predictable level of accuracy. Therefore, an AAA protocol 487 MUST provide a means of guaranteed delivery of accounting information 488 between the NAS and the AAA Server(s). 490 8.4.1.2. Real Time Accounting 492 NAS operators often require a real time view onto the status of sessions 493 served by a NAS. Therefore, the AAA protocol MUST support real-time 494 delivery of accounting and auditing information. In this context, real 495 time is defined as accounting information delivery beginning within one 496 second of the triggering event. 498 8.4.1.3. Batch Accounting 500 The AAA protocol SHOULD also support delivery of stored accounting and 501 auditing information in batches (non-real time). 503 8.4.1.4. Accounting Time Stamps 505 There may be delays associated with the delivery of accounting informa- 506 tion. The NAS operator will desire to know the time an event actually 507 occurred, rather than simply the time when notification of the event was 508 received. Therefore, the AAA protocol MUST carry an unambiguous time 509 stamp associated with each accounting event. This time stamp MUST be 510 unambiguous with regard to time zone. Note that this assumes that the 511 NAS has access to a reliable time source. 513 8.4.1.5. Accounting Events 515 At a minimum, the AAA protocol MUST support delivery of accounting 516 information triggered by the following events: 518 -Start of a user session 520 -End of a user session 522 -Expiration of a predetermined repeating time interval during a 523 user session. The AAA protocol MUST provide a means for the AAA 524 server to request that a NAS use a certain interval accounting 525 time. 527 -Dynamic re-authorization during a user session (e.g., new 528 resources being delivered to the user) 530 -Dynamic re-authentication during a user session 532 8.4.1.6. On-Demand Accounting 534 NAS operators need to maintain an accurate view onto the status of ses- 535 sions served by a NAS, even through failure of an AAA server. There- 536 fore, the AAA protocol MUST support a means of requesting current ses- 537 sion state and accounting from the NAS on demand. 539 8.4.2. Accounting Attribute Requirements 541 At a minimum, the AAA protocol MUST support delivery of the following 542 types of accounting/auditing data: 544 -All parameters used to authenticate a session. 546 -Details of the authorization profile that was applied to the ses- 547 sion. 549 -The duration of the session. 551 -The cumulative number of bytes sent by the user during the ses- 552 sion. 554 -The cumulative number of bytes received by the user during the 555 session. 557 -The cumulative number of packets sent by the user during the ses- 558 sion. 560 -The cumulative number of packets received by the user during the 561 session. 563 -Details of the access protocol used during the session (port type, 564 connect speeds, etc.) 566 8.4.3. Accounting Protocol Security Requirements 568 8.4.3.1. Integrity and Confidentiality 570 Note that accounting and auditing data are operationally sensitive 571 information. The AAA protocol MUST provide a means to assure end-to-end 572 integrity of this data. The AAA protocol SHOULD provide a means of 573 assuring the end-to-end confidentiality of this data. 575 8.4.3.2. Auditibility 577 Network operators use accounting data for network planning, resource 578 management, and other business-critical functions that require confi- 579 dence in the correctness of this data. The AAA protocol SHOULD provide a 580 mechanism to ensure that the source of accounting data cannot easily 581 repudiate this data after transmission. 583 9. Device Management Protocols 585 This document does not specify any requirements for device management 586 protocols. 588 10. Acknowledgments 590 Many of the requirements in this document first took form in Glen Zorn's 591 "Yet Another Authentication Protocol (YAAP)" document, for which grate- 592 ful acknowledgment is made. 594 11. Security considerations 596 See above for security requirements for the NAS AAA protocol. 598 Where an AAA architecture spans multiple domains of authority, AAA 599 information may need to cross trust boundaries. In this situation, a 600 NAS might operate as a shared device that services multiple administra- 601 tive domains. Network operators are advised take this into considera- 602 tion when deploying NAS's and AAA Servers. 604 12. IANA Considerations 606 This document does not directly specify any IANA considerations. How- 607 ever, the following recommendations are made: 609 Future development and extension of an AAA protocol will be made much 610 easier if new attributes and values can be requested or registered 611 directly through IANA, rather than through an IETF Standardization pro- 612 cess. 614 The AAA protocol might use enumerated values for some attributes, which 615 enumerate already-defined IANA types (such as protocol number). In these 616 cases, the AAA protocol SHOULD use the IANA assigned numbers as the enu- 617 merated values. 619 13. References 621 [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate Require- 622 ment Levels." RFC 2119, March 1997. 624 [NAS-MODEL] D. Mitton, M. Beadles. "Network Access Server Requirements 625 Next Generation (NASREQNG) NAS Model." draft-ietf-nasreq-nas- 626 model-01.txt, Work in progress. 628 [PPPOE] L. Mamakos, et al. "A Method for Transmitting PPP Over Ethernet 629 (PPPoE)." RFC 2516, February 1999. 631 [L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)." 632 RFC 2661, August 1999. 634 [PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661, Day- 635 dreamer, July 1994. 637 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specification." STD 638 8, RFC 854, May 1983. 640 [ROUTING-REQUIREMENTS] F. Baker. "Requirements for IP Version 4 641 Routers." RFC 1812, June 1995. 643 [IPV6] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6) 644 Specification." RFC 2460, December 1998. 646 [RFC 2277] H. Alvestrand. "IETF Policy on Character Sets and Lan- 647 guages." RFC 2277, January 1998. 649 [CHAP] W. Simpson. "PPP Challenge Handshake Authentication Protocol 650 (CHAP)." RFC 1994, August 1996. 652 [EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Protocol 653 (EAP)." RFC 2284, March 1998. 655 [NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC 2486, 656 January 1999. 658 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 659 Open Systems Interconnection - The Directory: Authentication Framework, 660 June 1997. 662 [KERBEROS] J. Kohl, C. Neuman. "The Kerberos Network Authentication 663 Service (V5)." RFC 1510, September 1993. 665 [ESP] S. Kent, R. Atkinson. "IP Encapsulating Security Payload (ESP)." 666 RFC 2406, November 1998. 668 [AH] S. Kent, R. Atkinson. "IP Authentication Header (AH)." RFC 2402, 669 November 1998. 671 [ROAMING-REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating 672 Roaming Protocols." RFC 2477, January 1999. 674 [RADIUS] C. Rigney, et al., "Remote Authentication Dial In User Service 675 (RADIUS)" RFC 2138, April 1997 677 [RADIUS-ACCOUNTING] C. Rigney, "RADIUS Accounting", RFC 2139, April 678 1997 679 14. Author's Addresses 681 Mark Anthony Beadles 682 SmartPipes, Inc. 683 565 Metro Place South 684 Suite 300 685 Dublin, OH 43017 687 Phone: 614-327-8046 688 EMail: mbeadles@smartpipes.com 690 David Mitton 691 Nortel Networks 692 8 Federal St 693 Billerica, MA 01821 695 Phone: 978-288-4570 696 EMail: dmitton@nortelnetworks.com 698 15. Full Copyright Statement 700 Copyright (C) The Internet Society (2000). All Rights Reserved. 702 This document and translations of it may be copied and furnished to oth- 703 ers, and derivative works that comment on or otherwise explain it or 704 assist in its implmentation may be prepared, copied, published and dis- 705 tributed, in whole or in part, without restriction of any kind, provided 706 that the above copyright notice and this paragraph are included on all 707 such copies and derivative works. However, this document itself may not 708 be modified in any way, such as by removing the copyright notice or ref- 709 erences to the Internet Society or other Internet organizations, except 710 as needed for the purpose of developing Internet standards in which case 711 the procedures for copyrights defined in the Internet Standards process 712 must be followed, or as required to translate it into languages other 713 than English. The limited permissions granted above are perpetual and 714 will not be revoked by the Internet Society or its successors or 715 assigns. This document and the information contained herein is provided 716 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEER- 717 ING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 718 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 719 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABIL- 720 ITY OR FITNESS FOR A PARTICULAR PURPOSE." 721 16. Expiration Date 723 This document is filed as , and 724 expires September 2000.