NASREQ Working Group M. Beadles INTERNET-DRAFT UUNET, an MCI WorldCom Company Category: Informational 11 October 1999 Criteria for Evaluating Network Access Server Protocols 1.. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference mate- rial or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this draft is unlimited. It is filed as and expires April 11, 2000. Please send comments to the author. 2. Copyright Statement Copyright (C) The Internet Society 1999. All Rights Reserved. 3. Abstract This document defines requirements for protocols used by Network Access Servers (NAS). Protocols used by NAS's may be divided into four spaces: Access protocols, Network protocols, AAA protocols, and Management protocols. Primary attention is given to setting require- ments for AAA protocols, since that space is currently the least well defined. Beadles Category: Informational [Page 1] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 4. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [KEYWORDS]. 5. Introduction This document defines requirements for protocols used by Network Access Servers (NAS). Protocols used by NAS's may be divided into four spaces: Access protocols, Network protocols, AAA protocols, and Device Management protocols. The primary focus of this document is on AAA protocols. The reference model of a NAS used by this document, and the analysis of the functions of a NAS which led to the develop- ment of these requirements, may be found in [NAS-MODEL]. 6. Access Protocol Requirements There are three basic types of access protocols used by NAS's. First are the telephony-based access protocols, which interface to the NAS via a modem or terminal adapter or similar device. These protocols typically support asynchronous or synchronous PPP [PPP] carried over a telephony network. Included by extension are cellular telephony access protocols. Second are broadband pseudo-telephony access proto- cols, which are carried over xDSL or cable modems, for example. These protocols typically support an encapsulation method such as PPP over Ethernet [PPPOE]. Finally are the virtual access protocols used by NAS's that terminate tunnels. One example of this type of protocol is L2TP [L2TP]. It is a central assumption of the NAS model used here that a NAS accepts multiple point-to-point links via one of the above access pro- tocols. Therefore, at a minimum, any NAS access protocol MUST be able to carry PPP. The exception to this requirement is for NAS's that support legacy text login methods such as telnet [TELNET], rlogin, or LAT. Only these access protocols are exempt from the requirement to support PPP. 7. Network Protocol Requirements The network protocols supported by a NAS depend entirely on the kind of network to which a NAS is providing access. This document does not impose any additional requirements on network protocols beyond the protocol specifications themselves. For example, if a NAS that serves a routed network includes internet routing functionality, then that NAS must adhere to [ROUTING-REQUIREMENTS], but there are no additional protocol requirements imposed by virtue of the device being a NAS. Beadles Category: Informational [Page 2] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8. AAA Protocol Requirements 8.1. General protocol characteristics There are certain general characteristics that any AAA protocol used by NAS's must meet. Note that the transport requirements for authen- tication/authorization are not necessarily the same as those for accounting/auditing. An AAA protocol suite MAY use the same transport and protocol for both functions, but this is not strictly required. 8.1.1. RADIUS Compatibility It is operationally very important to support the many thousands of devices making up the Internet today, which speak RADIUS. Therefore, devices which implement the AAA protocol SHOULD support some means of compatibility with devices that implement RADIUS. This requirement MAY be met by simply listening on the same port as RADIUS; note that in this case the AAA and RADIUS protocols might be quite different. Alternatively, the requirement MAY be met by creating a gateway between RADIUS and the AAA protocol. Other alternatives are possible; the intent is to ensure the continued operation of the currently- deployed RADIUS infrastructure during deployment of the AAA protocol. 8.1.2. Transport requirements 8.1.2.1. Fast Fail-over The transport for the AAA protocol MUST support fast (within a matter of milliseconds) fail-over for authentication and authorization requests. 8.1.2.2. Reliable Accounting The transport for the accounting data in the AAA protocol MUST be reliable. Beadles Category: Informational [Page 3] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8.1.2.3. Long-term exchange of small packets Very large scale NAS's that serve up to thousands of simultaneous ses- sions are now being deployed. This means that, in the extreme, there may be an almost constant exchange of many small packets between the NAS and the AAA server. An AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts. 8.1.2.4. Support for multiple AAA servers In order to operationally support large loads, load balancing to mul- tiple AAA servers will be required. The AAA protocol MUST provide for NAS's to balance AAA sessions between two or more AAA servers. The load balancing mechanism SHOULD be built in to the AAA protocol itself. The AAA protocol design MUST NOT introduce a single point of failure during the AAA process. The AAA protocol MUST allow any ses- sions between a NAS and a given AAA server to fail over to a secondary server without loss of state information. This fail-over mechanism SHOULD be built in to the AAA protocol itself. 8.1.2.5. Flow control In order to support the previous two requirements, the AAA protocol MUST provide a flow control mechanism to avoid flooding a busy server. 8.1.2.6. Support for Multiple Administrative Domains NAS's operated by one authority provide network access services for clients operated by another authority, to network destinations oper- ated by yet another authority. This type of arrangement is of growing importance; for example, dial roaming is now a nearly ubiquitous ser- vice. Therefore, the AAA protocol MUST support AAA services that travel between multiple domains of authority. The AAA protocol MUST NOT use a model that assumes a single domain of authority. The AAA protocol MUST NOT dictate particular business models for the relation- ship between the administrative domains. The AAA protocol MUST sup- port proxy, and in addition SHOULD support other multi-domain rela- tionships such as brokering and referral. The AAA protocol MUST also meet the protocol requirements specified in [ROAMING-REQUIREMENTS]. Beadles Category: Informational [Page 4] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8.1.3. Attribute-Value Protocol Model Years of operational experience with AAA protocols and NAS's has proven that the Attribute-Value protocol model is an optimal represen- tation of AAA data. The protocol SHOULD use an Attribute-Value repre- sentation for AAA data. This document will assume such a model. Even if the AAA protocol does not use this as an on-the-wire data represen- tation, Attribute-Value can serve as abstraction for discussing AAA information. Experience has also shown that attribute space tends to run out quickly. In order to provide room for expansion in the attribute space, the AAA protocol MUST support a minimum of 64K Attributes (MIN- IMUM 16 bits), each with a minimum length of 64K (MINIMUM 16 bits). 8.1.3.1. Attribute Data Types The AAA protocol MUST support simple attribute data types, including integer, enumeration, text string, raw octet series, IP address, and date/time. The AAA protocol MUST also provide some support for complex structured data types. Wherever IP addresses are carried within the AAA protocol, the protocol MUST support both IPv4 and IPv6 [IPV6] addresses. Wherever text information is carried within the AAA proto- col, the protocol MUST comply with the IETF Policy on Character Sets and Languages [RFC 2277]. 8.1.3.2. Minimum Set of Attributes At a minimum, the AAA protocol MUST support, or be easily extended to support, the set of attributes supported by RADIUS [RADIUS] and RADIUS Accounting [RADIUS-ACCOUNTING]. If the base AAA protocol does not support this complete set of attributes, then an extension to that protocol MUST be defined which supports this set. 8.1.3.3. Attribute Extensibility NAS and AAA development is always progressing. In order to prevent the AAA protocol from being a limiting factor in NAS and AAA Server development, the AAA protocol MUST provide a built-in extensibility mechanism, which MUST include a means for adding new standard attribute extensions. This MUST include a method for registering or requesting extensions through IANA, so that long-term working group involvement is not required to create new attribute types. Ideally, the AAA protocol SHOULD separate specification of the transport from specificatoin of the attributes. The AAA protocol MUST include a means for individual vendors to add Beadles Category: Informational [Page 5] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 value through vendor-specific attributes and SHOULD include support for vendor-specific data types and vendor-specific commands. 8.1.4. Security Requirements 8.1.4.1. Mutual Authentication It is poor security practice for a NAS to communicate with an AAA server that is not trusted, and vice versa. The AAA protocol MUST provide mutual authentication between AAA server and NAS. If a net- work operator has deployed IP Security [IPSEC], the AAA protocol SHOULD allow its use. 8.1.4.2. Shared Secrets At a minimum, the AAA protocol SHOULD support use of a secret shared pairwise between each NAS and AAA server to mutually verify identity. This is intended for small-scale deployments. 8.1.4.3. Public Key Security AAA server/NAS identity verification based solely on shared secrets can be difficult to deploy properly at large scale, and it can be tempting for NAS operators to use a single shared secret (that rarely changes) across all NAS's. This can lead to easy compromise of the secret. Therefore, the AAA protocol MUST also support mutual verifi- cation of identity using a public-key infrastructure that supports expiration and revocation of keys. 8.1.4.4. Encryption of Attributes Some attributes are more operationally sensitive than others. Also, in a multi-domain scenario, attributes may be inserted by servers from different administrative domains. Therefore, the AAA protocol MUST support selective encryption of attributes on an attribute-by- attribute basis, even within the same message. This requirement applies equally to Authentication, Authorization, and Accounting data. 8.2. Authentication and User Security Requirements Beadles Category: Informational [Page 6] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8.2.1. Authentication protocol requirements End users who are requesting network access through a NAS will present various types of credentials. It is the purpose of the AAA protocol to transport these credentials between the NAS and the AAA server. 8.2.1.1. Bi-directional Authentication The AAA protocol MUST support transport of credentials from the AAA server to the NAS for the purpose of mutual (bi-directional) authenti- cation between the User and the NAS, and between the NAS and the AAA server. 8.2.1.2. Dynamic Authentication The AAA protocol MUST support re-authentication at any time during the course of a session, initiated from either end of the user session. 8.2.1.3. Multi-phase Authentication The AAA protocol MUST be able to support multi-phase authentication methods, including but not limited to support for: -Text prompting from the NAS to the user -A series of binary challenges and responses of arbitrary length -An authentication failure reason to be transmitted from the NAS to the user -Callback to a pre-determined phone number 8.2.1.4. Extensible Authentication Types Security protocol development is going on constantly as new threats are identified and better cracking methods are developed. Today's secure authentication methods may be proven insecure tomorrow. The AAA protocol MUST provide some support for addition of new authentica- tion credential types. EAP SHOULD be the supported mechanism. 8.2.2. Authentication Attribute Requirements In addition to the minimum attribute set, the AAA protocol must sup- port and define attributes that provide the following functions: Beadles Category: Informational [Page 7] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8.2.2.1. PPP Authentication protocols Many authentication protocols are defined within the framework of PPP. The AAA protocol MUST be able to act as an intermediary protocol between the authenticatee and the authenticator for the following authentication protocols: -PPP Password Authentication Protocol [PPP] -PPP Challenge Handshake Authentication Protocol [CHAP] -PPP Extensible Authentication Protocol [EAP] 8.2.2.2. User Identitification The following are common types of credentials used for user identifi- cation. The AAA protocol MUST be able to carry the following types of identity credentials: -A user name in the form of a Network Access Identifier [NAI]. -An Extensible Authentication Protocol [EAP] Identity Request Type packet. -Telephony dialing information such as Dialed Number Identifica- tion Service (DNIS) and Caller ID. If a particular type of identity credential is not needed for a par- ticular user session, the AAA protocol MUST NOT require that dummy credentials be filled in. That is, the AAA protocol MUST support identification without authentication (and vice versa). 8.2.2.3. Authentication Credentials The following are common types of credentials used for authentication. The AAA protocol MUST be able to carry the following types of authen- ticating credentials at a minimum: -A secret or password. -A response to a challenge presented by the NAS to the user -A one-time password -An X.509 digital certificate [X.509] -A Kerberos v5 ticket [KERBEROS] Beadles Category: Informational [Page 8] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 8.2.3. Authentication Protocol Security Requirements 8.2.3.1. End-to-End Hiding of Credentials Where passwords are used as authentication credentials, the AAA proto- col MUST provide a secure means of hiding the password from end to end of the AAA conversation, or directly perform end-to-end authentica- tion. Where challenge/response mechanisms are used, the AAA protocol MUST also prevent against replay attacks. 8.3. Authorization, Policy, and Resource management 8.3.1. Authorization Protocol Requirements In all cases, the protocol MUST specify that authorization data sent from the NAS to the AAA server is to be regarded as information or "hints", and not directives. The AAA protocol MUST be designed so that the AAA server makes all final authorization decisions and does not depend on a certain state being expected by the NAS. 8.3.1.1. Dynamic Authorization The AAA protocol MUST support dynamic re-authorization at any time during a user session. This re-authorization may be initiated in either direction. This dynamic re-authorization capability MUST include the capability to request a NAS to disconnect a user on demand. 8.3.1.2. Resource Management Resource management MUST be supported on demand by the NAS or AAA Server at any time during the course of a user session. 8.3.2. Authorization Attribute Requirements 8.3.2.1. Authorization Attribute Requirements - Access Restrictions The AAA protocol serves as a primary means of gathering data used for making Policy decisions for network access. Therefore, the AAA Beadles Category: Informational [Page 9] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 protocol MUST allow network operators to make policy decisions based on the following parameters: -Time/day restrictions. The AAA protocol MUST be able to provide an unambiguous time stamp, NAS time zone indication, and date indication to the AAA server in the Authorization information. -Location restrictions: The AAA protocol MUST be able to provide an unambiguous location code that reflects the geographic loca- tion of the NAS (not the user). Note that this is not the same type of thing as either the dialing or dialed station. -Dialing restrictions: The AAA protocol MUST be able to provide accurate dialed and dialing station indications. -Concurrent login limitations: The AAA protocol MUST allow an AAA Server to limit concurrent logins by a particular user or group of users. This mechanism does not need to be explicitly built into the AAA protocol, but the AAA protocol must provide sufficient authorization information for an AAA server to make that determination through an out-of-band mechanism. 8.3.2.2. Authorization Attribute Requirements - Authorization Pro- files The AAA protocol is used to enforce policy at the NAS. Essentially, on granting of access, a particular access profile is applied to the user's session. The AAA protocol MUST at a minimum provide a means of applying profiles containing the following types of information: -IP Address assignment: The AAA protocol MUST provide a means of assigning an IPv4 or IPv6 address to an incoming user. -Protocol Filter application: The AAA protocol MUST provide a means of applying IP protocol filters to user sessions. Two dif- ferent methods MUST be supported. First, the AAA protocol MUST provide a means of selecting a pro- tocol filter by reference to an identifier, with the details of the filter action being specified out of band. The AAA protocol MAY define this out-of-band reference mechanism. Second, the AAA protocol MUST provide a means of passing a proto- col filter by value. This means explicit passing of pass/block information by address range, TCP/UDP port number, and IP proto- col number at a minimum. -Compulsory Tunneling: The AAA protocol MUST provide a means of directing a NAS to build a tunnel or tunnels to a specified end- point. It MUST support creation of multiple simultaneous tunnels in a specified order. The protocol MUST allow, at a minimum, specification of the tunnel endpoints, tunneling protocol type, Beadles Category: Informational [Page 10] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 underlying tunnel media type, and tunnel authentication creden- tials (if required by the tunnel type). The AAA protocol MUST support at least the creation of tunnels using the L2TP [L2TP], ESP [ESP], and AH [AH] protocols. The protocol MUST provide means of adding new tunnel types as they are standardized. -Routing: The AAA protocol MUST provide a means of assigning a particular static route to an incoming user session. -Expirations/timeouts: The AAA protocol MUST provide a means of communication session expiration information to a NAS. Types of expirations that MUST be supported are: total session time, idle time, total bytes transmitted, and total bytes received. -Quality of Service: The AAA protocol MUST provide a means of applying Quality of Service parameters to individual user ses- sions. 8.3.2.3. Resource Management Requirements The AAA protocol is one means for network operators to perform manage- ment of network resources consumed by users. However, it has been difficult to perform resource management on NAS's with existing SNMP implementations, which are often used for this purpose. The AAA pro- tocol MUST support transmission of large amounts of data in order to support resource management on large-scale NAS's providing complex user services. The AAA protocol MUST provide a means of collecting resource state information, and controlling resource allocation for the following types of network resources. -Network bandwidth usage per user session, including multilink sessions. -Access port usage by users, including concurrent usage and usage pools. -Connect time for individual users. -IP Addresses and pool utilization by users. -Compulsory tunnel limits for users. 8.3.3. Authorization Protocol Security Requirements 8.3.3.1. Security of Compulsory Tunnel Credentials When an AAA protocol passes a set of credentials that will be used to Beadles Category: Informational [Page 11] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 authenticate compulsory tunnels, the AAA protocol MUST provide a means of securing these credentials from end to end of the AAA conversation. The AAA protocol MUST also provide protection against replay attacks in this situation. 8.4. Accounting and Auditing Requirements 8.4.1. Accounting Protocol Requirements 8.4.1.1. Guaranteed Delivery The accounting and auditing functions of the AAA protocol are used for network planning, resource management, policy decisions, and other functions that require accurate knowledge of the state of the NAS. NAS operators need to be able to engineer their network usage measure- ment systems to a predictable level of accuracy. Therefore, an AAA protocol MUST provide a means of guaranteed delivery of accounting information between the NAS and the AAA Server(s). Note that the requirement for guaranteed delivery is not only a protocol requirement - NAS's might be required to implement certain practices (e.g. non- volatile storage of accounting data) in order to support guaranteed delivery. 8.4.1.2. Real Time Accounting NAS operators often require a real time view onto the status of ses- sions served by a NAS. Therefore, the AAA protocol MUST support real- time delivery of accounting and auditing information. In this con- text, real time is defined as accounting information delivery begin- ning within one second of the triggering event. 8.4.1.3. Batch Accounting The AAA protocol SHOULD also support delivery of stored accounting and auditing information in batches (non-real time). 8.4.1.4. Accounting Time Stamps There may be delays associated with the delivery of accounting infor- mation. The NAS operator will desire to know the time an event actu- ally occurred, rather than simply the time when notification of the event was received. Therefore, the AAA protocol MUST carry an Beadles Category: Informational [Page 12] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 unambiguous time stamp associated with each accounting event. This time stamp MUST be unambiguous with regard to time zone. Note that this assumes that the NAS has access to a correct time source. 8.4.1.5. Accounting Events At a minimum, the AAA protocol MUST support delivery of accounting information triggered by the following events: -Start of a user session -End of a user session -Expiration of a predetermined repeating time interval during a user session. The AAA protocol MUST provide a means for the AAA server to request that a NAS use a certain interval accounting time. -Dynamic re-authorization during a user session (e.g., new resources being delivered to the user) -Dynamic re-authentication during a user session 8.4.1.6. On-demand Accounting NAS operators need to maintain an accurate view onto the status of sessions served by a NAS, even through failure of the NA or AAA server. Therefore, the AAA protocol MUST support a means of request- ing current session state and accounting from the NAS on demand. The intention is to provide for recovery if, for whatever reason, the nor- mal flow of accounting data is interrupted. 8.4.2. Accounting attribute requirements At a minimum, the AAA protocol MUST support delivery of the following types of accounting/auditing data: -All parameters used to authenticate a session. -Details of the authorization profile that was applied to the session. -The duration of the session. -The cumulative number of bytes sent by the user during the ses- sion. -The cumulative number of bytes received by the user during the session. Beadles Category: Informational [Page 13] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 -The cumulative number of packets sent by the user during the session. -The cumulative number of packets received by the user during the session. -Details of the access protocol used during the session (port type, connect speeds, etc.) -Reason for termination of the session. -Error or diagnostic information on the session. 8.4.3. Accounting Protocol Security Requirements 8.4.3.1. Integrity and Confidentiality Note that accounting and auditing data are operationally sensitive information. The AAA protocol MUST provide a means to assure end-to- end integrity of this data. The AAA protocol SHOULD provide a means of assuring the end-to-end confidentiality of this data. 8.4.3.2. Non-repudiation Network operators use accounting data for network planning, resource management, and other business-critical functions that require confi- dence in the correctness of this data. The AAA protocol SHOULD provide a mechanism to ensure that the source and destination of Accounting data cannot repudiate this data after transmission. 9. Device Management Protocols This document does not specify any requirements for device management protocols. 10. Acknowledgments Many of the requirements in this document first took form in Glen Zorn's "Yet Another Authentication Protocol (YAAP)" document, for which grateful acknowledgment is made. The author would also like to thank Bernard Aboba and Pat Calhoun for their contributions. Beadles Category: Informational [Page 14] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 11. Security considerations See above for security requirements for the NAS AAA protocol. Where an AAA architecture spans multiple domains of authority, AAA information may need to cross trust boundaries. In this situation, a NAS might operate as a shared device that services multiple adminis- trative domains. Network operators are advised take this into consid- eration when deploying NAS's and AAA Servers. 12. IANA Considerations This document does not directly specify any IANA considerations. How- ever, the following recommendations are made: Future development and extension of an AAA protocol will be made much easier if new attributes and values can be requested or registered directly through IANA, rather than through an IETF Standardization process. The AAA protocol might use enumerated values for some attributes, which enumerate already-defined IANA types (such as protocol number). In these cases, the AAA protocol SHOULD use the IANA assigned numbers as the enumerated values. 13. References [KEYWORDS] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March 1997. [NAS-MODEL] D. Mitton, M. Beadles. "Network Access Server Require- ments Next Generation (NASREQNG) NAS Model." Work in progress. [PPPOE] L. Mamakos et al. "A Method for Transmitting PPP Over Ether- net (PPPoE)." RFC 2516, UUNET Technologies, Inc., February 1999. [L2TP] W. M. Townsley, et al. "Layer Two Tunneling Protocol (L2TP)." RFC 2661, IBM, Cisco, Ascend, Microsoft, August 1999. [PPP] W. Simpson. "The Point-to-Point Protocol (PPP)." RFC 1661, Daydreamer, July 1994. [TELNET] J. Postel, J. Reynolds. "Telnet Protocol Specification." STD 8, RFC 854, ISI, May 1983. [ROUTING-REQUIREMENTS] F. Baker. "Requirements for IP Version 4 Routers." RFC 1812, Cisco Systems, June 1995. Beadles Category: Informational [Page 15] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 [IPV6] S. Deering, R. Hinden. "Internet Protocol, Version 6 (IPv6) Specification." RFC 2460, Cisco, Nokia, December 1998. [RFC 2277] H. Alvestrand. "IETF Policy on Character Sets and Lan- guages." RFC 2277, UNINETT, January 1998. [CHAP] W. Simpson. "PPP Challenge Handshake Authentication Protocol (CHAP)." RFC 1994, Daydreamer, August 1996. [EAP] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Proto- col (EAP)." RFC 2284, Merit Network, Inc., March 1998. [NAI] B. Aboba, M. Beadles. "The Network Access Identifier." RFC 2486, Microsoft, WorldCom Advanced Networks, January 1999. [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Frame- work, June 1997. [KERBEROS] J. Kohl, C. Neuman. "The Kerberos Network Authentication Service (V5)." RFC 1510, Digital Equipment Corporation, ISI, Septem- ber 1993. [ESP] S. Kent, R. Atkinson. "IP Encapsulating Security Payload (ESP)." RFC 2406, BBN Corp, @Home Network, November 1998. [AH] S. Kent, R. Atkinson. "IP Authentication Header (AH)." RFC 2402, BBN Corp, @Home Network, November 1998. [ROAMING-REQUIREMENTS] B. Aboba, G. Zorn. "Criteria for Evaluating Roaming Protocols." RFC 2477, Microsoft, January 1999. [RADIUS] [RADIUS-ACCOUNTING] 14. Author's Address Mark Anthony Beadles UUNET, an MCI WorldCom Company 5000 Britton Rd. Hilliard, OH 43026 Phone: 614-723-1941 EMail: mbeadles@wcom.net Beadles Category: Informational [Page 16] INTERNET-DRAFT Criteria for NAS Protocols 11 October 1999 15. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Inter- net organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permis- sions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 16. Expiration Date This document is filed as , and expires April 11, 2000. Beadles Category: Informational [Page 17]