idnits 2.17.1 draft-ietf-nasreq-criteria-03.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. ** 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 16 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 17 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 197 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 334 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 ...' == (192 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 (11 October 1999) is 8961 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 2277' is mentioned on line 196, but not defined == Missing Reference: 'IPSEC' is mentioned on line 229, 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: 15 errors (**), 0 flaws (~~), 12 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, an MCI WorldCom Company 3 Category: Informational 4 5 11 October 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 April 11, 2000. Please 30 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 defines requirements for protocols used by Network 39 Access Servers (NAS). Protocols used by NAS's may be divided into 40 four spaces: Access protocols, Network protocols, AAA protocols, and 41 Management protocols. Primary attention is given to setting require- 42 ments for AAA protocols, since that space is currently the least well 43 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 defines requirements for protocols used by Network 54 Access Servers (NAS). Protocols used by NAS's may be divided into 55 four spaces: Access protocols, Network protocols, AAA protocols, and 56 Device Management protocols. The primary focus of this document is on 57 AAA protocols. The reference model of a NAS used by this document, 58 and the analysis of the functions of a NAS which led to the develop- 59 ment 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 telephony-based access protocols, which interface to the NAS 65 via a modem or terminal adapter or similar device. These protocols 66 typically support asynchronous or synchronous PPP [PPP] carried over a 67 telephony network. Included by extension are cellular telephony 68 access protocols. Second are broadband pseudo-telephony access proto- 69 cols, which are carried over xDSL or cable modems, for example. These 70 protocols typically support an encapsulation method such as PPP over 71 Ethernet [PPPOE]. Finally are the virtual access protocols used by 72 NAS's that terminate tunnels. One example of this type of protocol is 73 L2TP [L2TP]. 75 It is a central assumption of the NAS model used here that a NAS 76 accepts multiple point-to-point links via one of the above access pro- 77 tocols. Therefore, at a minimum, any NAS access protocol MUST be able 78 to carry PPP. The exception to this requirement is for NAS's that 79 support legacy text login methods such as telnet [TELNET], rlogin, or 80 LAT. Only these access protocols are exempt from the requirement to 81 support PPP. 83 7. Network Protocol Requirements 85 The network protocols supported by a NAS depend entirely on the kind 86 of network to which a NAS is providing access. This document does not 87 impose any additional requirements on network protocols beyond the 88 protocol specifications themselves. For example, if a NAS that serves 89 a routed network includes internet routing functionality, then that 90 NAS must adhere to [ROUTING-REQUIREMENTS], but there are no additional 91 protocol requirements imposed by virtue of the device being a NAS. 93 8. AAA Protocol Requirements 95 8.1. General protocol characteristics 97 There are certain general characteristics that any AAA protocol used 98 by NAS's must meet. Note that the transport requirements for authen- 99 tication/authorization are not necessarily the same as those for 100 accounting/auditing. An AAA protocol suite MAY use the same transport 101 and protocol for both functions, but this is not strictly required. 103 8.1.1. RADIUS Compatibility 105 It is operationally very important to support the many thousands of 106 devices making up the Internet today, which speak RADIUS. Therefore, 107 devices which implement the AAA protocol SHOULD support some means of 108 compatibility with devices that implement RADIUS. This requirement 109 MAY be met by simply listening on the same port as RADIUS; note that 110 in this case the AAA and RADIUS protocols might be quite different. 111 Alternatively, the requirement MAY be met by creating a gateway 112 between RADIUS and the AAA protocol. Other alternatives are possible; 113 the intent is to ensure the continued operation of the currently- 114 deployed RADIUS infrastructure during deployment of the AAA protocol. 116 8.1.2. Transport requirements 118 8.1.2.1. Fast Fail-over 120 The transport for the AAA protocol MUST support fast (within a matter 121 of milliseconds) fail-over for authentication and authorization 122 requests. 124 8.1.2.2. Reliable Accounting 126 The transport for the accounting data in the AAA protocol MUST be 127 reliable. 129 8.1.2.3. Long-term exchange of small packets 131 Very large scale NAS's that serve up to thousands of simultaneous ses- 132 sions are now being deployed. This means that, in the extreme, there 133 may be an almost constant exchange of many small packets between the 134 NAS and the AAA server. An AAA protocol transport SHOULD support 135 being optimized for a long-term exchange of small packets in a stream 136 between a pair of hosts. 138 8.1.2.4. Support for multiple AAA servers 140 In order to operationally support large loads, load balancing to mul- 141 tiple AAA servers will be required. The AAA protocol MUST provide for 142 NAS's to balance AAA sessions between two or more AAA servers. The 143 load balancing mechanism SHOULD be built in to the AAA protocol 144 itself. The AAA protocol design MUST NOT introduce a single point of 145 failure during the AAA process. The AAA protocol MUST allow any ses- 146 sions between a NAS and a given AAA server to fail over to a secondary 147 server without loss of state information. This fail-over mechanism 148 SHOULD be built in to the AAA protocol itself. 150 8.1.2.5. Flow control 152 In order to support the previous two requirements, the AAA protocol 153 MUST provide a flow control mechanism to avoid flooding a busy server. 155 8.1.2.6. Support for Multiple Administrative Domains 157 NAS's operated by one authority provide network access services for 158 clients operated by another authority, to network destinations oper- 159 ated by yet another authority. This type of arrangement is of growing 160 importance; for example, dial roaming is now a nearly ubiquitous ser- 161 vice. Therefore, the AAA protocol MUST support AAA services that 162 travel between multiple domains of authority. The AAA protocol MUST 163 NOT use a model that assumes a single domain of authority. The AAA 164 protocol MUST NOT dictate particular business models for the relation- 165 ship between the administrative domains. The AAA protocol MUST sup- 166 port proxy, and in addition SHOULD support other multi-domain rela- 167 tionships such as brokering and referral. 169 The AAA protocol MUST also meet the protocol requirements specified in 170 [ROAMING-REQUIREMENTS]. 172 8.1.3. Attribute-Value Protocol Model 174 Years of operational experience with AAA protocols and NAS's has 175 proven that the Attribute-Value protocol model is an optimal represen- 176 tation of AAA data. The protocol SHOULD use an Attribute-Value repre- 177 sentation for AAA data. This document will assume such a model. Even 178 if the AAA protocol does not use this as an on-the-wire data represen- 179 tation, Attribute-Value can serve as abstraction for discussing AAA 180 information. 182 Experience has also shown that attribute space tends to run out 183 quickly. In order to provide room for expansion in the attribute 184 space, the AAA protocol MUST support a minimum of 64K Attributes (MIN- 185 IMUM 16 bits), each with a minimum length of 64K (MINIMUM 16 bits). 187 8.1.3.1. Attribute Data Types 189 The AAA protocol MUST support simple attribute data types, including 190 integer, enumeration, text string, raw octet series, IP address, and 191 date/time. The AAA protocol MUST also provide some support for complex 192 structured data types. Wherever IP addresses are carried within the 193 AAA protocol, the protocol MUST support both IPv4 and IPv6 [IPV6] 194 addresses. Wherever text information is carried within the AAA proto- 195 col, the protocol MUST comply with the IETF Policy on Character Sets 196 and Languages [RFC 2277]. 198 8.1.3.2. Minimum Set of Attributes 200 At a minimum, the AAA protocol MUST support, or be easily extended to 201 support, the set of attributes supported by RADIUS [RADIUS] and RADIUS 202 Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol does not 203 support this complete set of attributes, then an extension to that 204 protocol MUST be defined which supports this set. 206 8.1.3.3. Attribute Extensibility 208 NAS and AAA development is always progressing. In order to prevent 209 the AAA protocol from being a limiting factor in NAS and AAA Server 210 development, the AAA protocol MUST provide a built-in extensibility 211 mechanism, which MUST include a means for adding new standard 212 attribute extensions. This MUST include a method for registering or 213 requesting extensions through IANA, so that long-term working group 214 involvement is not required to create new attribute types. Ideally, 215 the AAA protocol SHOULD separate specification of the transport from 216 specificatoin of the attributes. 218 The AAA protocol MUST include a means for individual vendors to add 219 value through vendor-specific attributes and SHOULD include support 220 for vendor-specific data types and vendor-specific commands. 222 8.1.4. Security Requirements 224 8.1.4.1. Mutual Authentication 226 It is poor security practice for a NAS to communicate with an AAA 227 server that is not trusted, and vice versa. The AAA protocol MUST 228 provide mutual authentication between AAA server and NAS. If a net- 229 work operator has deployed IP Security [IPSEC], the AAA protocol 230 SHOULD allow its use. 232 8.1.4.2. Shared Secrets 234 At a minimum, the AAA protocol SHOULD support use of a secret shared 235 pairwise between each NAS and AAA server to mutually verify identity. 236 This is intended for small-scale deployments. 238 8.1.4.3. Public Key Security 240 AAA server/NAS identity verification based solely on shared secrets 241 can be difficult to deploy properly at large scale, and it can be 242 tempting for NAS operators to use a single shared secret (that rarely 243 changes) across all NAS's. This can lead to easy compromise of the 244 secret. Therefore, the AAA protocol MUST also support mutual verifi- 245 cation of identity using a public-key infrastructure that supports 246 expiration and revocation of keys. 248 8.1.4.4. Encryption of Attributes 250 Some attributes are more operationally sensitive than others. Also, 251 in a multi-domain scenario, attributes may be inserted by servers from 252 different administrative domains. Therefore, the AAA protocol MUST 253 support selective encryption of attributes on an attribute-by- 254 attribute basis, even within the same message. This requirement 255 applies equally to Authentication, Authorization, and Accounting data. 257 8.2. Authentication and User Security Requirements 258 8.2.1. Authentication protocol requirements 260 End users who are requesting network access through a NAS will present 261 various types of credentials. It is the purpose of the AAA protocol 262 to transport these credentials between the NAS and the AAA server. 264 8.2.1.1. Bi-directional Authentication 266 The AAA protocol MUST support transport of credentials from the AAA 267 server to the NAS for the purpose of mutual (bi-directional) authenti- 268 cation between the User and the NAS, and between the NAS and the AAA 269 server. 271 8.2.1.2. Dynamic Authentication 273 The AAA protocol MUST support re-authentication at any time during the 274 course of a session, initiated from either end of the user session. 276 8.2.1.3. Multi-phase Authentication 278 The AAA protocol MUST be able to support multi-phase authentication 279 methods, including but not limited to support for: 280 -Text prompting from the NAS to the user 282 -A series of binary challenges and responses of arbitrary length 284 -An authentication failure reason to be transmitted from the NAS 285 to the user 287 -Callback to a pre-determined phone number 289 8.2.1.4. Extensible Authentication Types 291 Security protocol development is going on constantly as new threats 292 are identified and better cracking methods are developed. Today's 293 secure authentication methods may be proven insecure tomorrow. The 294 AAA protocol MUST provide some support for addition of new authentica- 295 tion credential types. EAP SHOULD be the supported mechanism. 297 8.2.2. Authentication Attribute Requirements 299 In addition to the minimum attribute set, the AAA protocol must sup- 300 port and define attributes that provide the following functions: 302 8.2.2.1. PPP Authentication protocols 304 Many authentication protocols are defined within the framework of PPP. 305 The AAA protocol MUST be able to act as an intermediary protocol 306 between the authenticatee and the authenticator for the following 307 authentication protocols: 309 -PPP Password Authentication Protocol [PPP] 311 -PPP Challenge Handshake Authentication Protocol [CHAP] 313 -PPP Extensible Authentication Protocol [EAP] 315 8.2.2.2. User Identitification 317 The following are common types of credentials used for user identifi- 318 cation. The AAA protocol MUST be able to carry the following types of 319 identity credentials: 320 -A user name in the form of a Network Access Identifier [NAI]. 322 -An Extensible Authentication Protocol [EAP] Identity Request 323 Type packet. 325 -Telephony dialing information such as Dialed Number Identifica- 326 tion Service (DNIS) and Caller ID. 327 If a particular type of identity credential is not needed for a par- 328 ticular user session, the AAA protocol MUST NOT require that dummy 329 credentials be filled in. That is, the AAA protocol MUST support 330 identification without authentication (and vice versa). 332 8.2.2.3. Authentication Credentials 334 The following are common types of credentials used for authentication. 335 The AAA protocol MUST be able to carry the following types of authen- 336 ticating credentials at a minimum: 337 -A secret or password. 339 -A response to a challenge presented by the NAS to the user 341 -A one-time password 343 -An X.509 digital certificate [X.509] 345 -A Kerberos v5 ticket [KERBEROS] 347 8.2.3. Authentication Protocol Security Requirements 349 8.2.3.1. End-to-End Hiding of Credentials 351 Where passwords are used as authentication credentials, the AAA proto- 352 col MUST provide a secure means of hiding the password from end to end 353 of the AAA conversation, or directly perform end-to-end authentica- 354 tion. Where challenge/response mechanisms are used, the AAA protocol 355 MUST also prevent against replay attacks. 357 8.3. Authorization, Policy, and Resource management 359 8.3.1. Authorization Protocol Requirements 361 In all cases, the protocol MUST specify that authorization data sent 362 from the NAS to the AAA server is to be regarded as information or 363 "hints", and not directives. The AAA protocol MUST be designed so 364 that the AAA server makes all final authorization decisions and does 365 not depend on a certain state being expected by the NAS. 367 8.3.1.1. Dynamic Authorization 369 The AAA protocol MUST support dynamic re-authorization at any time 370 during a user session. This re-authorization may be initiated in 371 either direction. This dynamic re-authorization capability MUST 372 include the capability to request a NAS to disconnect a user on 373 demand. 375 8.3.1.2. Resource Management 377 Resource management MUST be supported on demand by the NAS or AAA 378 Server at any time during the course of a user session. 380 8.3.2. Authorization Attribute Requirements 382 8.3.2.1. Authorization Attribute Requirements - Access Restrictions 384 The AAA protocol serves as a primary means of gathering data used for 385 making Policy decisions for network access. Therefore, the AAA 386 protocol MUST allow network operators to make policy decisions based 387 on the following parameters: 389 -Time/day restrictions. The AAA protocol MUST be able to provide 390 an unambiguous time stamp, NAS time zone indication, and date 391 indication to the AAA server in the Authorization information. 393 -Location restrictions: The AAA protocol MUST be able to provide 394 an unambiguous location code that reflects the geographic loca- 395 tion of the NAS (not the user). Note that this is not the same 396 type of thing as either the dialing or dialed station. 398 -Dialing restrictions: The AAA protocol MUST be able to provide 399 accurate dialed and dialing station indications. 401 -Concurrent login limitations: The AAA protocol MUST allow an 402 AAA Server to limit concurrent logins by a particular user or 403 group of users. This mechanism does not need to be explicitly 404 built into the AAA protocol, but the AAA protocol must provide 405 sufficient authorization information for an AAA server to make 406 that determination through an out-of-band mechanism. 408 8.3.2.2. Authorization Attribute Requirements - Authorization Pro- 409 files 411 The AAA protocol is used to enforce policy at the NAS. Essentially, 412 on granting of access, a particular access profile is applied to the 413 user's session. The AAA protocol MUST at a minimum provide a means of 414 applying profiles containing the following types of information: 416 -IP Address assignment: The AAA protocol MUST provide a means of 417 assigning an IPv4 or IPv6 address to an incoming user. 419 -Protocol Filter application: The AAA protocol MUST provide a 420 means of applying IP protocol filters to user sessions. Two dif- 421 ferent methods MUST be supported. 423 First, the AAA protocol MUST provide a means of selecting a pro- 424 tocol filter by reference to an identifier, with the details of 425 the filter action being specified out of band. The AAA protocol 426 MAY define this out-of-band reference mechanism. 428 Second, the AAA protocol MUST provide a means of passing a proto- 429 col filter by value. This means explicit passing of pass/block 430 information by address range, TCP/UDP port number, and IP proto- 431 col number at a minimum. 433 -Compulsory Tunneling: The AAA protocol MUST provide a means of 434 directing a NAS to build a tunnel or tunnels to a specified end- 435 point. It MUST support creation of multiple simultaneous tunnels 436 in a specified order. The protocol MUST allow, at a minimum, 437 specification of the tunnel endpoints, tunneling protocol type, 438 underlying tunnel media type, and tunnel authentication creden- 439 tials (if required by the tunnel type). The AAA protocol MUST 440 support at least the creation of tunnels using the L2TP [L2TP], 441 ESP [ESP], and AH [AH] protocols. The protocol MUST provide 442 means of adding new tunnel types as they are standardized. 444 -Routing: The AAA protocol MUST provide a means of assigning a 445 particular static route to an incoming user session. 447 -Expirations/timeouts: The AAA protocol MUST provide a means of 448 communication session expiration information to a NAS. Types of 449 expirations that MUST be supported are: total session time, idle 450 time, total bytes transmitted, and total bytes received. 452 -Quality of Service: The AAA protocol MUST provide a means of 453 applying Quality of Service parameters to individual user ses- 454 sions. 456 8.3.2.3. Resource Management Requirements 458 The AAA protocol is one means for network operators to perform manage- 459 ment of network resources consumed by users. However, it has been 460 difficult to perform resource management on NAS's with existing SNMP 461 implementations, which are often used for this purpose. The AAA pro- 462 tocol MUST support transmission of large amounts of data in order to 463 support resource management on large-scale NAS's providing complex 464 user services. The AAA protocol MUST provide a means of collecting 465 resource state information, and controlling resource allocation for 466 the following types of network resources. 468 -Network bandwidth usage per user session, including multilink 469 sessions. 471 -Access port usage by users, including concurrent usage and usage 472 pools. 474 -Connect time for individual users. 476 -IP Addresses and pool utilization by users. 478 -Compulsory tunnel limits for users. 480 8.3.3. Authorization Protocol Security Requirements 482 8.3.3.1. Security of Compulsory Tunnel Credentials 484 When an AAA protocol passes a set of credentials that will be used to 485 authenticate compulsory tunnels, the AAA protocol MUST provide a means 486 of securing these credentials from end to end of the AAA conversation. 487 The AAA protocol MUST also provide protection against replay attacks 488 in this situation. 490 8.4. Accounting and Auditing Requirements 492 8.4.1. Accounting Protocol Requirements 494 8.4.1.1. Guaranteed Delivery 496 The accounting and auditing functions of the AAA protocol are used for 497 network planning, resource management, policy decisions, and other 498 functions that require accurate knowledge of the state of the NAS. 499 NAS operators need to be able to engineer their network usage measure- 500 ment systems to a predictable level of accuracy. Therefore, an AAA 501 protocol MUST provide a means of guaranteed delivery of accounting 502 information between the NAS and the AAA Server(s). Note that the 503 requirement for guaranteed delivery is not only a protocol requirement 504 - NAS's might be required to implement certain practices (e.g. non- 505 volatile storage of accounting data) in order to support guaranteed 506 delivery. 508 8.4.1.2. Real Time Accounting 510 NAS operators often require a real time view onto the status of ses- 511 sions served by a NAS. Therefore, the AAA protocol MUST support real- 512 time delivery of accounting and auditing information. In this con- 513 text, real time is defined as accounting information delivery begin- 514 ning within one second of the triggering event. 516 8.4.1.3. Batch Accounting 518 The AAA protocol SHOULD also support delivery of stored accounting and 519 auditing information in batches (non-real time). 521 8.4.1.4. Accounting Time Stamps 523 There may be delays associated with the delivery of accounting infor- 524 mation. The NAS operator will desire to know the time an event actu- 525 ally occurred, rather than simply the time when notification of the 526 event was received. Therefore, the AAA protocol MUST carry an 527 unambiguous time stamp associated with each accounting event. This 528 time stamp MUST be unambiguous with regard to time zone. Note that 529 this assumes that the NAS has access to a correct time source. 531 8.4.1.5. Accounting Events 533 At a minimum, the AAA protocol MUST support delivery of accounting 534 information triggered by the following events: 535 -Start of a user session 537 -End of a user session 539 -Expiration of a predetermined repeating time interval during a 540 user session. The AAA protocol MUST provide a means for the AAA 541 server to request that a NAS use a certain interval accounting 542 time. 544 -Dynamic re-authorization during a user session (e.g., new 545 resources being delivered to the user) 547 -Dynamic re-authentication during a user session 549 8.4.1.6. On-demand Accounting 551 NAS operators need to maintain an accurate view onto the status of 552 sessions served by a NAS, even through failure of the NA or AAA 553 server. Therefore, the AAA protocol MUST support a means of request- 554 ing current session state and accounting from the NAS on demand. The 555 intention is to provide for recovery if, for whatever reason, the nor- 556 mal flow of accounting data is interrupted. 558 8.4.2. Accounting attribute requirements 560 At a minimum, the AAA protocol MUST support delivery of the following 561 types of accounting/auditing data: 562 -All parameters used to authenticate a session. 564 -Details of the authorization profile that was applied to the 565 session. 567 -The duration of the session. 569 -The cumulative number of bytes sent by the user during the ses- 570 sion. 572 -The cumulative number of bytes received by the user during the 573 session. 575 -The cumulative number of packets sent by the user during the 576 session. 578 -The cumulative number of packets received by the user during the 579 session. 581 -Details of the access protocol used during the session (port 582 type, connect speeds, etc.) 584 -Reason for termination of the session. 586 -Error or diagnostic information on the session. 588 8.4.3. Accounting Protocol Security Requirements 590 8.4.3.1. Integrity and Confidentiality 592 Note that accounting and auditing data are operationally sensitive 593 information. The AAA protocol MUST provide a means to assure end-to- 594 end integrity of this data. The AAA protocol SHOULD provide a means 595 of assuring the end-to-end confidentiality of this data. 597 8.4.3.2. Non-repudiation 599 Network operators use accounting data for network planning, resource 600 management, and other business-critical functions that require confi- 601 dence in the correctness of this data. The AAA protocol SHOULD provide 602 a mechanism to ensure that the source and destination of Accounting 603 data cannot repudiate this data after transmission. 605 9. Device Management Protocols 607 This document does not specify any requirements for device management 608 protocols. 610 10. Acknowledgments 612 Many of the requirements in this document first took form in Glen 613 Zorn's "Yet Another Authentication Protocol (YAAP)" document, for 614 which grateful acknowledgment is made. The author would also like to 615 thank Bernard Aboba and Pat Calhoun for their contributions. 617 11. Security considerations 619 See above for security requirements for the NAS AAA protocol. 621 Where an AAA architecture spans multiple domains of authority, AAA 622 information may need to cross trust boundaries. In this situation, a 623 NAS might operate as a shared device that services multiple adminis- 624 trative domains. Network operators are advised take this into consid- 625 eration when deploying NAS's and AAA Servers. 627 12. IANA Considerations 629 This document does not directly specify any IANA considerations. How- 630 ever, the following recommendations are made: 632 Future development and extension of an AAA protocol will be made much 633 easier if new attributes and values can be requested or registered 634 directly through IANA, rather than through an IETF Standardization 635 process. 637 The AAA protocol might use enumerated values for some attributes, 638 which enumerate already-defined IANA types (such as protocol number). 639 In these cases, the AAA protocol SHOULD use the IANA assigned numbers 640 as the enumerated values. 642 13. References 644 [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate 645 Requirement Levels." RFC 2119, Harvard University, March 1997. 647 [NAS-MODEL] D. Mitton, M. Beadles. "Network Access Server Require- 648 ments Next Generation (NASREQNG) NAS Model." Work in progress. 650 [PPPOE] L. Mamakos et al. "A Method for Transmitting PPP Over Ether- 651 net (PPPoE)." RFC 2516, UUNET Technologies, Inc., February 1999. 653 [L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)." 654 RFC 2661, IBM, Cisco, Ascend, Microsoft, August 1999. 656 [PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661, 657 Daydreamer, July 1994. 659 [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specification." 660 STD 8, RFC 854, ISI, May 1983. 662 [ROUTING-REQUIREMENTS] F. Baker. "Requirements for IP Version 4 663 Routers." RFC 1812, Cisco Systems, June 1995. 665 [IPV6] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6) 666 Specification." RFC 2460, Cisco, Nokia, December 1998. 668 [RFC 2277] H. Alvestrand. "IETF Policy on Character Sets and Lan- 669 guages." RFC 2277, UNINETT, January 1998. 671 [CHAP] W. Simpson. "PPP Challenge Handshake Authentication Protocol 672 (CHAP)." RFC 1994, Daydreamer, August 1996. 674 [EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- 675 col (EAP)." RFC 2284, Merit Network, Inc., March 1998. 677 [NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC 678 2486, Microsoft, WorldCom Advanced Networks, January 1999. 680 [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - 681 Open Systems Interconnection - The Directory: Authentication Frame- 682 work, June 1997. 684 [KERBEROS] J. Kohl, C. Neuman. "The Kerberos Network Authentication 685 Service (V5)." RFC 1510, Digital Equipment Corporation, ISI, Septem- 686 ber 1993. 688 [ESP] S. Kent, R. Atkinson. "IP Encapsulating Security Payload 689 (ESP)." RFC 2406, BBN Corp, @Home Network, November 1998. 691 [AH] S. Kent, R. Atkinson. "IP Authentication Header (AH)." RFC 692 2402, BBN Corp, @Home Network, November 1998. 694 [ROAMING-REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating 695 Roaming Protocols." RFC 2477, Microsoft, January 1999. 697 [RADIUS] 699 [RADIUS-ACCOUNTING] 701 14. Author's Address 703 Mark Anthony Beadles 704 UUNET, an MCI WorldCom Company 705 5000 Britton Rd. 706 Hilliard, OH 43026 708 Phone: 614-723-1941 709 EMail: mbeadles@wcom.net 710 15. Full Copyright Statement 712 Copyright (C) The Internet Society (1999). All Rights Reserved. 714 This document and translations of it may be copied and furnished to 715 others, and derivative works that comment on or otherwise explain it 716 or assist in its implmentation may be prepared, copied, published and 717 distributed, in whole or in part, without restriction of any kind, 718 provided that the above copyright notice and this paragraph are 719 included on all such copies and derivative works. However, this docu- 720 ment itself may not be modified in any way, such as by removing the 721 copyright notice or references to the Internet Society or other Inter- 722 net organizations, except as needed for the purpose of developing 723 Internet standards in which case the procedures for copyrights defined 724 in the Internet Standards process must be followed, or as required to 725 translate it into languages other than English. The limited permis- 726 sions granted above are perpetual and will not be revoked by the 727 Internet Society or its successors or assigns. This document and the 728 information contained herein is provided on an "AS IS" basis and THE 729 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 730 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 731 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 732 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 733 PARTICULAR PURPOSE." 735 16. Expiration Date 737 This document is filed as , and 738 expires April 11, 2000.