INTERNET DRAFT D. Spence draft-spence-aaaarch-objmsg-00.txt Interlink Networks, Inc. January 2001 Data Objects and Message Types in the Generic AAA Architecture Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. This memo describes work in progress within the AAAarch Research Group. Comments are welcome and should be submitted to the RG mailing list at aaaarch@fokus.gmd.de. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society 2001. All Rights Reserved. Abstract This memo specifies the top level data objects to be carried in an AAA Protocol that supports the generic AAA architecture described in RFC 2903. It also specifies the required message types. Data objects and message types are defined in an abstract way without Spence expires July 2001 [Page 1] INTERNET DRAFT Data Objects and Message Types January 2001 regard to encoding. The message types defined could be thought of as the use cases (in the UML sense) for a generic AAA server. They define what can be asked of or provided to a generic AAA server. The data objects specify what kinds of information can be routed among the AAA servers in the generic AAA infrastructure. Suggestions as to which data objects would be carried in each message type are provided. Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 1 Abstract ....................................................... 1 1. Introduction ................................................ 3 2. Top Level Objects ........................................... 4 2.1. Identity ............................................... 4 2.2. Authentication Data .................................... 4 2.3. Authentication Challenge ............................... 5 2.4. Service Data ........................................... 5 2.5. Service Offer .......................................... 5 2.6. Answer ................................................. 5 2.7. Error .................................................. 5 2.8. Policy ................................................. 5 2.9. Policy Reference ....................................... 6 2.10. Policy Data ........................................... 6 2.11. Configuration Data .................................... 6 2.12. Service Management .................................... 6 2.13. Accounting ............................................ 6 2.14. Event ................................................. 6 2.15. Capability ............................................ 7 3. Message Types ............................................... 7 3.1. Service Request/Reply .................................. 7 3.2. Authorization Request/Reply ............................ 8 3.3. Solicit Service Offer Request/Reply .................... 8 3.4. Authentication Request/Reply ........................... 8 3.5. Authentication Challenge Request/Reply ................. 9 3.6. Policy Request/Reply ................................... 9 3.7. Policy Evaluation Request/Reply ........................ 9 3.8. Data Request/Reply ..................................... 9 3.9. Event Log Indication/Confirmation ...................... 10 3.10. Accounting Indication/Confirmation .................... 10 3.11. Service Configuration Indication/Confirmation ......... 10 3.12. Service Management Indication/Confirmation ............ 11 3.13. Capability Request/Reply .............................. 11 4. Security Considerations ..................................... 12 References ..................................................... 12 Author's Address ............................................... 12 Spence expires July 2001 [Page 2] INTERNET DRAFT Data Objects and Message Types January 2001 1. Introduction This memo specifies the top level data objects to be carried in an AAA Protocol that supports the generic AAA architecture described in [2]. It also specifies the required message types. Data objects and message types are defined in an abstract way without regard to encoding. The message types defined could be thought of as the use cases (in the UML sense) for a generic AAA server. They define what can be asked of or provided to a generic AAA server. The data objects specify what kinds of information can be routed among the AAA servers in the generic AAA infrastructure. Suggestions as to which data objects would be carried in each message type are provided. This memo is not meant to constrain the actual message types that may be defined in a specific AAA protocol. The mapping between concrete protocol elements and these abstract types may be quite complex. Similarly this memo does not constrain the data model used for the payload data carried by an actual AAA protocol. Rather it is intended to specify the abstract functionality required of AAA protocols operating in the generic infrastructure. Not all of the capabilities defined in this memo will be needed for every AAA application. Rather the intent is to provide a set of building blocks that together will meet the needs of almost any AAA application. The AAA process begins with a user desiring service. Before the user requests the service, he or she may solicit a list of options available. The user may then send a Service Request to an AAA server. The AAA server receiving a Service Request may forward it to another AAA server for processing. An AAA server that begins to process a Service Request may find that it needs specific assistance from other AAA servers which may reside in different administrative domains. It may need to retrieve a policy or request authorization from another AAA server. It may need to send a policy to another AAA server for evaluation. It may need to retrieve data from another AAA server which it needs to evaluate a policy. The service being provided must be configured and managed. Accounting data must be collected. Authentication may require multiple messages. Events must be known about and logged in various places. AAA server capabilities must be communicated. Some of the messages will have to carry more than one kind of information. For example, a Service Request may convey the identity of the user, information by which the identity assertion can be authenticated, and a description of the service desired. A Policy Evaluation Request may contain both the policy and some of the information needed to evaluate it. Spence expires July 2001 [Page 3] INTERNET DRAFT Data Objects and Message Types January 2001 The message types defined in this memo are those of the Type 1 AAA protocol defined in [2]. Type 1 communications are those between two AAA servers or between an AAA-capable User client and an AAA server. The data objects are those required in Type 1 communications. However, some of the data objects defined here may be passed in other types of communication as well. This does not imply that the object encoding must be the same, but the information content of the objects will need to be preserved between the different types of protocol that must carry it. Section 2 of this memo defines the top level objects. Section 3 defines the message types. Section 4 discusses security considerations. The present version of this memo is very preliminary. This is a work in progress that intends to document ideas and assumptions involved in the AAA Architecture research effort. 2. Top Level Objects The following is a list top level objects that an AAA protocol may carry. AAA messages may carry multiple objects and some objects may be carried in more than one type of message. The object definitions will need to be extensible to meet the needs of a large variety of applications. The realization of these objects in a real AAA protocol is not specified here nor are the extensibility mechanisms. COPS, for instance, is object oriented with new classes being derived from existing classes. Objects may contain other objects as needed. In Diameter the top level objects might be AVPs of the grouped-AVP type. These AVPs would then encapsulate other AVPs as needed. The architecture is concerned only at a high level of abstraction. 2.1. Identity The Identity object contains the identity of the user, e.g., an NAI. 2.2. Authentication Data The Authentication Data object contains data which may be used to authenticate the Identity object. There are many types of Authentication Data objects as required by the different supported authentication algorithms and protocols. The Authentication Data object may or may not be sent in reference to an Authentication Challenge object. Spence expires July 2001 [Page 4] INTERNET DRAFT Data Objects and Message Types January 2001 2.3. Authentication Challenge The Authentication Challenge object contains an authentication challenge as required by some types of authentication protocols. 2.4. Service Data The Service Data object contains data elements specifying the desired service. The contents of Service Data objects are understood by user clients and by AAA servers but may not be understood by service equipment which may only understand Configuration Data objects. 2.5. Service Offer The Service Offer objects contains a description of service options available at a service provider. This could take a couple of forms. In a limited view, it would consist of a list of well-known service attributes with a list of values for each that are supported by or available at the service provider. In a more general view, it would consist of a list of not well-know attributes and their supported values together with human-readable descriptions of each. This more general version of the Service Offer object would support forms of e-commerce where a human user is using the AAA infrastructure to obtain service but doesn't know in advance how to specify the service. 2.6. Answer The Answer Object contains a Yes or No answer. 2.7. Error The Error object is included in a reply or confirmation message to indicate some error in the corresponding request or indication. 2.8. Policy The Policy object contains a policy. Depending on the message type in which the object is included, the policy may be a pushed policy or a pulled policy. Elsewhere [3] there are lists of the types of policies present in the AAA infrastructure. Not all of them, however, would need to be transmitted in AAA messages. The following types of policy are expected to need to be transmitted in AAA messages: Spence expires July 2001 [Page 5] INTERNET DRAFT Data Objects and Message Types January 2001 service specification policy authorization policy provisioning policy configuration policy accounting policy metering policy 2.9. Policy Reference The Policy Reference object contains a reference to a policy stored at a remote AAA server. 2.10. Policy Data The Policy Data object contains attributes against which some policy will be evaluated. The values of the Policy Data attributes will be substituted for the free variables in the policies. Like Policy objects, Policy Data objects may be pushed or pulled. Policy Data objects may be included in an AAA message along with a Policy or Policy Reference object. 2.11. Configuration Data The Configuration Data object contains attributes informing the service equipment how to provide the requested service. Configuration Data objects may describe the service at a lower level of abstraction than Service Data objects. They may be sent from one AAA server to another via the Type 1 protocol [2] or from an AAA server to an Application Service Module (ASM) via the Type 2 protocol [2] or from an ASM to the service equipment via the Type 5 protocol [2]. 2.12. Service Management The Service Management object contains objects to manage an ongoing service (a session). 2.13. Accounting The Accounting object contains Accounting attributes. 2.14. Event The Event object contains an event to be logged [2]. Spence expires July 2001 [Page 6] INTERNET DRAFT Data Objects and Message Types January 2001 2.15. Capability The Capability object contains information concerning the capabilities of an AAA server. This may include a list of AAA applications supported, a list of local ASMs, or a list of service providers represented by or reachable through a broker. 3. Message Types This section describes the basic message types required of an AAA protocol in order to meet the needs of the AAA architecture. Another way to think about it would be that this section describes the "use cases" in the UML sense by which an AAA server may be used by one of the AAA actors -- another AAA server, a user, the service equipment or an ASM. 3.1. Service Request/Reply A Service Request is a request to provide some service. It may be passed through a chain of AAA entities depending on whether the push, pull, or agent model [4] is being used. Implicit in a request for service is a request for authentication and authorization. Typical top level objects carried in a Service Request include: Identity Authentication Data Service Data or Service Specification Policy Policy Data A Service Reply is returned back down the chain. It may be positive or negative. If positive, it might contain objects such as: Answer (= Yes) Service Data (the negotiated service parameters) Configuration Data (to be sent to the service equipment) If the reply is negative it might contain objects such as: Answer (= No) Error Service Offer Spence expires July 2001 [Page 7] INTERNET DRAFT Data Objects and Message Types January 2001 3.2. Authorization Request/Reply An Authorization Request seeks to know if a specified service can be authorized. Typical top level objects include: Identity Service Data or Service Specification Policy Policy Data An Authorization Reply might contain: Answer Error 3.3. Solicit Service Offer Request/Reply A Solicit Service Offer Request is sent to discover what service parameters are supported by a service provider. It may be sent through a broker. It might contain the following object to indicate in broadest terms what type of service is of interest: Service Data The Solicit Service Offer Reply would contain the following object: Service Offer 3.4. Authentication Request/Reply An Authentication Request is sent to an AAA server to request it to authenticate a user or to forward the request to an AAA server that can. The Authentication Request might contain: Identity Authentication Data The Authentication Reply might simply contain: Answer Spence expires July 2001 [Page 8] INTERNET DRAFT Data Objects and Message Types January 2001 3.5. Authentication Challenge Request/Reply The Authentication Challenge Request is sent toward a user to support challenge type authentication algorithms. It would contain the following object: Authentication Challenge The Authentication Challenge Reply would contain: Authentication Data 3.6. Policy Request/Reply The Policy Request is sent to an AAA server to obtain a remote policy. It would contain: Policy Reference The Policy Reply would contain: Policy 3.7. Policy Evaluation Request/Reply The Policy Evaluation Request is sent to an AAA server to request it to evaluate a policy. It would contain: Policy, or Policy Reference, and possibly Policy Data The Policy Evaluation Reply would contain: Answer Service Data (optional) Configuration Data (optional) 3.8. Data Request/Reply A Data Request is sent to retrieve policy data from a remote AAA server. It would contain the following object to specify the data Spence expires July 2001 [Page 9] INTERNET DRAFT Data Objects and Message Types January 2001 elements it wants to retrieve. However, no data values would be given: Policy Data The reply would return the object with the values filled in. Policy Data 3.9. Event Log Indication/Confirmation An Event Log Indication is sent to request another AAA server to log an event. It contains: Event The Event Log Confirmation contains: Answer Error (if Answer=No) 3.10. Accounting Indication/Confirmation An Accounting Indication is sent to an Accounting server. It may be forwarded through a proxy or broker. It contains: Accounting An Accounting Confirmation is returned to indicate that the accounting data has been committed to stable storage. It contains: Answer Error (if Answer=No) 3.11. Service Configuration Indication/Confirmation A Service Configuration Indication may be sent to a Service Provider to suggest configuration parameters for the service to be provided. It contains: Configuration Data Spence expires July 2001 [Page 10] INTERNET DRAFT Data Objects and Message Types January 2001 A Service Configuration Confirmation contains: Answer Error (If Answer=No) 3.12. Service Management Indication/Confirmation The Service Management Indication is sent to the Service Provider AAA Server to manage a service pending or in progress. It may contain the following objects: Service Management Service Data (optional) Configuration Data (optional) Management operations include: Service termination Modifying service parameters The Service Management Confirmation contains: Answer Error (if Answer=No) The Service Management Confirmation contains: Answer Error (if Answer=No) 3.13. Capability Request/Reply The Capability Request seeks to discover the capabilities or roles of an AAA server. It contains: Capability The Capability Reply contains: Capability Spence expires July 2001 [Page 11] INTERNET DRAFT Data Objects and Message Types January 2001 4. Security Considerations AAA protocols have a number of security concerns, and any AAA protocol that is designed to meet the needs of the generic AAA infrastructure will have to meet these concerns. This memo, however, does not attempt to define an AAA protocol. Rather it describes, in an abstract way, the general types of AAA messages and the kinds of information they convey. There are several projects being undertaken by the AAA Architecture Research Group that focus on the security needs of the generic AAA infrastructure. Such concerns are, however, outside the scope of this memo. References [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] de Laat, Cees T.A.M., George M. Gross, Leon Gommans, John R. Vollbrecht, David W. Spence, "Generic AAA Architecture", RFC 2903, August 2000. [3] Salowey, Joseph, Guus Sliepen, Arie Taal, David Spence, "Policy in AAA", draft-irtf-aaaarch-aaa-pol-00.txt, November 2000. [4] Vollbrecht, John, Pat Calhoun, Stephen Farrell, Leon Gommans, George Gross, Betty de Bruijn, Cees de Laat, Matt Holdrege and David Spence, "AAA Authorization Framework", RFC 2904, August 2000. [5] Taal, Arie, Guus Sliepen, David Spence, "Policies in a Generic AAA Environment", draft-taal-aaaarch-generic-pol-00.txt, November 2000. Author's Address David Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA Phone: +1 734 821 1203 Fax: +1 734 821 1235 EMail: dspence@interlinknetworks.com Spence expires July 2001 [Page 12]