Internet Draft Hormuzd Khosravi Expiration: December 2000 David Durham File: draft-durham-aaa-cops-reqments-00.txt Jesse Walker Intel Comparison of COPS Against AAA Network Access Requirements Last Updated: May 31, 2000 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 documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract The AAA Working Group has completed a document that itemizes their requirements for Network Access Applications (NASREQ, Mobile IP, and ROAMOPS). This specification compares the COPS protocol against the requirements, and is provided to the AAA Working Group as an official submission for an AAA protocol. 1.0 Introduction The AAA Working Group has completed a document that itemizes their requirements for Network Access Applications (NASREQ, Mobile IP, and ROAMOPS). This specification compares the COPS protocol against the requirements, and is provided to the AAA Working Group as an official submission for an AAA protocol. Author et al. Expires December 2000 [Page 1] Internet Draft Comparison of COPS and AAA Requirements May 2000 1.1 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 [1]. Please note that the requirements specified in this document are to be used in evaluating AAA protocol submissions. As such, the requirements language refers to capabilities of these protocols; the protocol documents will specify whether these features are required, recommended, or optional. For example, requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST, MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant." 2.0 Requirements Summary This section contains the same four sections as found in the AAA Network Access requirements. Each section contains a new column, named COPS. For each requirement, it is noted whether the COPS protocol meets (T), Partially meets (P), or does not meet (F) the stated requirement. Furthermore, each requirement has a footnote, which contains additional justification. 2.1 General requirements These requirements apply to all aspects of AAA and thus are considered general requirements. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | General | NASREQ | ROAMOPS | MOBILE | COPS | | Reqts. | | | IP | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Scalability | M | M | M | T | | | | | | a | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Failover | M | | M | T | Author et al. Expires December 2000 [Page 2] Internet Draft Comparison of COPS and AAA Requirements May 2000 | | | | | b | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Mutual auth | M | | M | T | | AAA client/server | | | | c | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Transmission level | | M | S | T | | security | | | | d | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Data object | M | M | S | T | | Confidentiality | | | | e | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Data object | M | M | M | T | | Integrity | | | | f | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Certificate transport | M | | S | T | | | | | | g | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Reliable AAA transport | M | | M | T | | mechanism | | | | h | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Run Over IPv4 | M | M | M | T | | | | | | i | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Run Over IPv6 | M | | S | T | | | | | | j | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Support Proxy and | M | | M | T | | Routing Brokers | | | | k | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Auditability | S | | | T | | | | | | l | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Author et al. Expires December 2000 [Page 3] Internet Draft Comparison of COPS and AAA Requirements May 2000 | | | | | | | Shared secret not | S | O | O/M | T | | required | | | | m | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Ability to carry | M | | S | T | | service-specific attr. | | | | n | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT T = Meets Requirement P = Partly Meets Requirement F = Does Not Meet Requirement Clarifications [a] The COPS protocol provides the following features that help scaling: [1] supports very large number of pending requests since the request handle is unbounded [2] support for message forwarding and redirect servers [3] can create COPS server hierarchies that will help increase scalability [b] The COPS Protocol [3] defines the failover and synchronization mechanisms that can be used in event of failure of the primary COPS server to switch to the secondary or backup server. [c] The COP Protocol [3] defines three different authenti- cation mechanisms: [1] None - When the local policy demands that no security is needed or when an underlying security service is used. [2] Hop-by-Hop - The COPS Protocol [3] provides a security mechanism using the Integrity Object to provide authentication, replay protection, and message integrity. [3] End-to-End - COPS object-level integrity using CMS. Author et al. Expires December 2000 [Page 4] Internet Draft Comparison of COPS and AAA Requirements May 2000 [d] The COPS Protocol [3] provides message authentication, integrity and confidentiality using the security mechanism defined in the protocol or uses other underlying mechanisms such as IPSec and TLS. [e] COPS uses CMS [5] to provide object level confidentiality. See COPS Usage for AAA [6] for details and See RFC 2797. [f] COPS uses CMS[5] to provide object level integrity. COPS uses RFC 1510 Certificate Management Messages over CMS to provide object level integrity. See COPS Usage for AAA [6] for details. [g] This MUST be part of the Information Model that is carried with the COPS messages. [h] The COPS Protocol [3] runs over TCP which provides reliable transport and addresses the AAA requirements. [i] The COPS Protocol [3] has no reliance on the underlying IP version, and is capable of running over IPv4. [j] The COPS Protocol [3] has no reliance on the underlying IP version, and is capable of running over IPv6. [k] The COPS Protocol supports proxies and brokers in both transparent forwarding, as well as in the redirect mode. See COPS Usage for AAA [6] for details. [l] The Information Model such as a History PIB MUST be used to carry information about how the COPS messages are audited by proxies/brokers as they travel from the home server to the network device. [m] All COPS security mechanisms are based on local policies and only used as required. [n] The COPS Protocol [3] is highly extensible in two ways, it supports new Client Types which can define Client Specific Info. objects and COPS-PR [4] separates the Information Model from the protocol allowing third parties to define service-specific Data (a.k.a. PIBs), that are carried over the protocol. 2.2 Authentication Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Authentication | NASREQ | ROAMOPS | MOBILE | COPS | | Reqts. | | | IP | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Author et al. Expires December 2000 [Page 5] Internet Draft Comparison of COPS and AAA Requirements May 2000 | | | | | | | NAI Support | M | M | S | T | | | | | | a | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | CHAP Support | M | M | O | T | | | | | | b | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | EAP Support | M | S | O | T | | | | | | c | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | PAP/Clear-Text Support | M | B | O | T | | | | | | d | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Re-authentication | M | | S | T | | on demand | | | | e | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Authorization Only | M | | O | T | | without Authentication | | | | f | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT T = Meets Requirement P = Partly Meets Requirement F = Does Not Meet Requirement Clarifications [a] The Information Model MUST define NAI attributes which are then carried in the COPS messages. Note that when using certificate based authentication, the naming scheme MUST conform to RFC 2459 naming conventions for subjectAltName and/or Subject name. This is more restrictive than NAI. Author et al. Expires December 2000 [Page 6] Internet Draft Comparison of COPS and AAA Requirements May 2000 [b] The Information Model MUST define CHAP attributes which are then carried in the COPS messages. [c] The Information Model MUST define EAP attributes which are then carried in the COPS messages. [d] The Information Model MUST define PAP which are then carried in the COPS messages. [e] The COPS Protocol being Stateful supports unsolicited Decision and Request messages that can be used to trigger re-authentica- tion. The Authentication time limit MUST be specified in the Information Model. [f] The COPS protocol allows the authentication and authorization information to be carried in separate Request messages. There- fore, it is possible to send a request for authorization only. Please note: with existing algorithms, any authorization scheme not based on a prior authentication is meaningless. 2.2 Authorization Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Authorization | NASREQ | ROAMOPS | MOBILE | COPS | | Reqts. | | | IP | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Static and Dynamic | | | | | | IPv4/6 Address Assign. | M | M | M | T | | | | | | a | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | RADIUS gateway | M | M | O | T | | capability | | | | b | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Reject | M | M | M | T | | capability | | | | c | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Precludes layer 2 | N | N | | T | | tunneling | | | | d | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Re-Authorization on | M | | S | T | Author et al. Expires December 2000 [Page 7] Internet Draft Comparison of COPS and AAA Requirements May 2000 | demand | | | | e | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Support for Access Rules,| M | | O | T | | Restrictions, Filters | | | | f | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | State Reconciliation | M | | | T | | | | | | g | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Unsolicited Disconnect | M | | | T | | | | | | h | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT T = Meets Requirement P = Partly Meets Requirement F = Does Not Meet Requirement Clarifications [a] The Information Model MUST define the static & dynamic addresses which can be carried in the COPS messages during the authorization phase. [b] The Information Model can define RADIUS attributes which can be carried in the COPS messages and used for protocol compatibility. Additionally, COPS can carry RADIUS AVPs directly without modification using its Client Specific Information object. [c] A forwarding agent, be it a Proxy or Broker, MAY reject a COPS Request by sending a Decision message with the appropriate Error Object. [d] The COPS information model MUST define support for L2TP configuration. [e] The COPS Protocol being Stateful supports unsolicited Decision and Request messages that can be used to trigger re-authoriza- Author et al. Expires December 2000 [Page 8] Internet Draft Comparison of COPS and AAA Requirements May 2000 tion. The Authorization time limit MUST be specified in the Authorization Information Model. [f] The Data/Information Model like the PIB MUST define the Access Rules and Filters that are carried in the COPS messages. [g] The AAA network access requirements describe State Reconcilia- tion as requiring: [1] Re-authorization capabilities - This is described in 2.2[e]. [2] Session disconnect message - The COPS Client Handle is used to maintain the session state. The Client can remove the session state by sending COPS Delete Request with the same Client Handle. This message thus acts as a session disconnect message. The COPS connection can also be closed. [3] Transport and application-layer reliability - COPS uses TCP which satisfies this requirement as well as its own session Keep-Alive mechanism. [4] An interim message - The COPS protocol supports unsolicited Report messages that can be used for this purpose. The Accounting Timer is used to set the interval for the accounting Reports or interim messages. [5] A mechanism for the AAA server to retrieve state informa- tion from the NAS. This mechanism will provide timely information though a complete state dump may not be immedi- ately available. - The COPS failover and synchronization mechanism can be used for this purpose. [6] A NAS reboot message - This MUST be part of the Information Model. [7] Accounting On/Off messages - This MUST be part of the Information Model. (The COPS Accounting Timer can also be used for this purpose.) [h] The COPS Base Protocol defines the Client Close message that can be used by either the COPS client or server to terminate the session. If the state is a subset of the TCP connection, then this could also be part of the Client-Handle signaling (Decision message and Delete Handle message). 2.3 Accounting Requirements +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Accounting | NASREQ | ROAMOPS | MOBILE | COPS | | Reqts. | | | IP | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Author et al. Expires December 2000 [Page 9] Internet Draft Comparison of COPS and AAA Requirements May 2000 | | | | | | | Real-time accounting | M | M | M | T | | | | | | a | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Mandatory Compact | | M | M | T | | Encoding | | | | b | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Accounting Record | M | M | M | T | | Extensibility | | | | c | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Batch Accounting | S | | | T | | | | | | d | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Guaranteed Delivery | M | | M | T | | | | | | e | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Accounting Time Stamps | M | | S | T | | | | | | f | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Dynamic Accounting | M | | S | T | | | | | | g | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT T = Meets Requirement P = Partly Meets Requirement F = Does Not Meet Requirement Clarifications [a] The COPS Protocol has provisions for sending unsolicited Report messages that can be used to send real-time accounting data. Author et al. Expires December 2000 [Page 10] Internet Draft Comparison of COPS and AAA Requirements May 2000 [b] The COPS-PR ClientSI objects can be used to carry ADIF records directly. The AAA Accounting Record and Attributes specification states "[ROAM-ADIF] proposes a standard accounting record format, the Accounting Data Interchange Format (ADIF), which is designed to compactly represent accounting data in a protocol-independent manner." Likewise, this format can also be stored within a PIB structure. [c] The ADIF Accounting Data Format MAY be extended by assign- ing new keywords for new accounting data objects by IANA. Likewise, new PIBs (which are fully described data structures) can be easily developed to represent future accounting records. [d] In COPS, the Report messages are used to carry Accounting data. The Accounting Timer object can be used to set the interval at which periodic accounting updates are sent to the COPS server. [e] COPS runs over TCP that provides guaranteed delivery at the application layer. The application layer can acknowledge Reports using a COPS Decision message if needed (all acknowledged accounting records on the client can be marked as acknowledged by the server). [f] This MUST be defined as an attribute in the Accounting Data Model (a.k.a. PIB) that will be carried in the COPS Report messages. [g] The COPS-PR uses PIBs which use the PRID to identify separate instances of the same data structure for a single session. 2.4 Unique Mobile IP requirements In addition Mobile IP also has the following requirements: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Unique Mobile IP | NASREQ | ROAMOPS | MOBILE | COPS | | requirements | | | IP | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Encoding of Mobile IP | | | M | T | | registration messages | | | | a | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | Firewall friendly | | | M | T | | | | | | b | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Author et al. Expires December 2000 [Page 11] Internet Draft Comparison of COPS and AAA Requirements May 2000 | | | | | | | Allocation of local Home | | | S/M | T | | agent | | | | c | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Key M = MUST S = SHOULD O = MAY N = MUST NOT B = SHOULD NOT T = Meets Requirement P = Partly Meets Requirement F = Does Not Meet Requirement Clarifications [a] The Information/Data Model or PIB like structure MUST be defined for Mobile IP Registration messages, which can be used to carry the Registration messages over COPS. [b] The COPS Protocol [3] runs over TCP and uses a fixed port number defined by IANA, which is why it is considered firewall friendly. Additionally, COPS proxy servers can easily be supported. [c] This MUST be part of the Information Model which can be extended to support a Mobile IP Home Agent on any platform. 3.0 Conclusion The COPS Protocol [3], when used with the appropriate Information Model, is unconditionally compliant with the AAA Network Access requirements [2]. 4.0 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Aboba et al, "Network Access AAA Evaluation Criteria", IETF workin progress, draft-ietf-aaa-na-reqts-02.txt, March 2000. [3] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., Sastry, A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, August 1999. Author et al. Expires December 2000 [Page 12] Internet Draft Comparison of COPS and AAA Requirements May 2000 [4] Reichmeyer, F., Herzog, S., Chan, K.H., Seligson, J., Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., Smith, A., "COPS Usage for Policy Provisioning", IETF , March 2000. [5] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. [6] D. Durham, H. Khosravi, W. Weiss, A. Doria, "COPS Usage for AAA", IETF, June 2000. 5.0 Security Considerations This document, being a protocol evaluation document, does not have any security concerns. The security requirements on protocols to be evaluated using this document are described in the referenced documents. 6.0 IANA Considerations This draft does not create any new number spaces for IANA administration. 7.0 Acknowledgements Special thanks to the authors and contributors to the various COPS documents. Thanks also to the authors of the AAA Network Access Evaluation Criteria document from which this document was formed. 8.0 Authors Addresses David Durham Intel 2111 N.E. 25th Avenue JF3-206 Hillsboro OR 97124-5961 1 503 264 6232 david.durham@intel.com Hormuzd M Khosravi Intel 2111 N.E. 25th Avenue JF3-206 Hillsboro OR 97124-5961 1 503 264 0334 hormuzd.m.khosravi@intel.com Jesse R. Walker Intel Corporation 2111 N.E. 25th Avenue Hillsboro, OR 97214 USA Author et al. Expires December 2000 [Page 13] Internet Draft Comparison of COPS and AAA Requirements May 2000 jesse.walker@intel.com 9.0 Full Copyright Statement Copyright (C) The Internet Society (2000). 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 implementation 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 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet 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 permissions 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 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Author et al. Expires December 2000 [Page 14]