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]