INTERNET DRAFT J. Vollbrecht draft-ietf-aaa-authorization-reqs-00.txt Merit Network, Inc. P. Calhoun Sun Microsystems, Inc. S. Farrell SSE Ltd. L. Gommans Cabletron Systems EMEA G. Gross Lucent Technologies B. de Bruijn Interpay Nederland B.V. M. Holdrege Ascend Communications D. Spence Merit Network, Inc. June 1999 AAA Authorization Architecture and Requirements 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 AAA Working Group. Comments are welcome and should be submitted to aaa-wg@merit.edu. Distribution of this memo is unlimited. Vollbrecht et al. expires December 1999 [Page 1] INTERNET DRAFT June 1999 Copyright Notice Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. The authorization needs of several different applications are considered in a lengthy appendix. Table of Contents Status of this Memo ............................................ 1 Copyright Notice ............................................... 2 Abstract ....................................................... 2 1. Introduction ................................................ 3 2. Architecture ................................................ 4 2.1. Single Domain Case ..................................... 7 2.1.1. The Push Sequence ............................... 7 2.1.2. The Pull Sequence ............................... 8 2.1.3. The Indirect Sequence ........................... 9 2.2. Roaming ................................................ 10 2.3. Distributed Services ................................... 13 2.4. Combining Roaming and Distributed Services ............. 15 2.5. Use of Policy to Store Authorization Data .............. 16 2.6. Use of Attribute Certificates .......................... 18 2.7. Resource Management .................................... 21 2.7.1. Session Management .............................. 21 2.7.2. The Resource Manager ............................ 22 2.8. AAA Message Forwarding and Delivery .................... 24 2.9. End-to-End Security .................................... 25 2.10. Streamlined Authorization Process ..................... 26 2.11. Summary of the Architecture ........................... 26 3. Requirements for Authorization Protocol ..................... 27 3.1. Requirements for Authorization Attribute Handling ...... 27 3.1.1. Basic Requirements .............................. 27 3.1.2. Requirements for Attribute Certificates ......... 28 4. Security Considerations ..................................... 29 4.1. Security Considerations in Existing Systems ............ 29 4.2. Security Considerations of Proposed Architecture ....... 29 Appendix -- Examples of Authorization Applications ............. 30 A.1. PPP Dialin with Roaming ................................ 30 A.1.1. Descriptive Model ............................... 30 Vollbrecht et al. expires December 1999 [Page 2] INTERNET DRAFT June 1999 A.1.2. Authorization Requirements ...................... 32 A.2. Mobile-IP .............................................. 32 A.2.1. Relationship to the Architecture ................ 35 A.2.2. Minimized Internet Traversal .................... 36 A.2.3. Key Distribution ................................ 36 A.2.4. Mobile-IP Authorization Requirements ............ 37 A.3. Bandwidth Broker ....................................... 38 A.3.1. Model Description ............................... 38 A.3.2. Components of the Two-Tier Model ................ 38 A.3.3. Identification of Contractual Relationships ..... 39 A.3.3.1. Single-Domain Case ....................... 39 A.3.3.2. Multi-Domain Case ........................ 40 A.3.4. Identification of Trust Relationships ........... 40 A.3.5. Communication Models and Trust .................. 43 A.3.6. Bandwidth Broker Communication Models ........... 44 A.3.6.1. Concepts ................................. 44 A.3.6.2. Bandwidth Broker Work Phases ............. 45 A.3.6.3. Inter-Domain Signalling .................. 45 A.3.6.4. Communication Architecture ............... 47 A.3.6.5. Two-Tier Inter-Domain Model .............. 48 A.3.7. Requirements .................................... 49 A.4. Internet Printing ...................................... 50 A.4.1. Trust Relationships ............................. 51 A.4.2. Use of Attribute Certificates ................... 52 A.4.3. IPP and the Authorization Descriptive Model ..... 53 A.5. Electronic Commerce .................................... 54 A.5.1. Model Description ............................... 55 A.5.1.1. Components ............................... 55 A.5.1.2. Contractual Relationships ................ 56 A.5.1.3. Trust Relationships ...................... 57 A.5.1.4. Communication Model ...................... 60 A.5.2. Multi Domain Model .............................. 62 A.5.3. Requirements .................................... 63 Glossary ....................................................... 66 References ..................................................... 67 Authors' Addresses ............................................. 68 1. Introduction There is a demonstrated need for a common scheme which covers all Internet services which offer Authorization. This common scheme will address various functional architectures which meet the requirements of basic services. We attempt to describe these architectures and functions along with the requirements that drive them. These architectures include Policy structures, Certificate Authorities, Resource Managers, Inter-Domain & Multi-Domain schemes, Vollbrecht et al. expires December 1999 [Page 3] INTERNET DRAFT June 1999 and Distributed Services. The requirements are for the expected use of Authorization services across these architectures. This document's purpose is to identify the generic Authorization requirements that are found within the Authentication, Authorization, and Accounting (AAA) problem domain. The requirements are extracted from a representative cross section of AAA applications. It is acknowledged that the selected AAA application set is not exhaustive, but it is hoped to be sufficiently broad to support this document's goal. In general, it is assumed that the parties who are participating in the authorization process have already gone through an authentication phase. The authentication method used by those parties is outside the scope of this document except to the extent that it influences the requirements found in a subsequent authorization process. Likewise, accounting requirements are outside the scope of this document other than recording accounting data or establishing trust relationships during an authorization that will facilitate a subsequent accounting phase. This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [2]. 2. Architecture The following architecture is being presented in order to provide a framework for discussing authorization requirements for a large number of applications. The intent is to provide some common vocabulary for the discussion. Terminology is introduced for basic elements in the authorization transaction and for concepts that appear to be common to all (or at least many) authorization proposals. Figure 1, below, identifies the basic conceptual entities that may be participants in an authorization: 1. A User who wants access to a service or resource. 2. A User Home Organization (UHO) that has an agreement with the user and checks whether the user is allowed to obtain the requested service or resource. This entity may carry information required to authorize the User, which might not be known to the Service Provider (such as a credit limit). 3. A Service Provider's AAA Server which authorizes a service based on an agreement with the User Home Organization without specific Vollbrecht et al. expires December 1999 [Page 4] INTERNET DRAFT June 1999 knowledge about the individual User. This agreement may contain elements that are not relevant to an individual user (e.g., the total agreed bandwidth between the User Home Organization and the Service Provider). 4. A Service Provider's Service Equipment which provides the service itself. This might, for example, be a NAS in dial service, or a Router in the QoS service, or a print server in the Internet Printing service. +------+ +-------------------------+ | | | User Home Organization | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 1 -- The Basic Authorization Entities These entities will be referenced in the authorization requirements. There may be bilateral agreements between pairs of organizations involved in an authorization transaction. Agreements between organizations may take the form of formal contracts or Service Level Agreements. Figure 2 uses double lines to show relationships that may exist between the User and the User Home Organization and between the User Home Organization and the Service Provider. Vollbrecht et al. expires December 1999 [Page 5] INTERNET DRAFT June 1999 +------+ +-------------------------+ | | | User Home Organization | | |======| +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | || | | || | | || | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 2 -- Service Agreements Authorization is based on these bilateral agreements between entities. Agreements may be chained, as shown in figure 2. The User has an agreement with the User Home Organization (e.g., the User may have access to the service between 9:00 a.m. and 11:00 a.m. daily). The User Home Organization has an agreement with the Service Provider (e.g., that all requests for access will be granted, except between 5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User's request depends on both agreements being honored. Note that these agreements may be implemented by hand configuration or by evaluation of Policy data stored in a Policy database. The point is that there must be a set of known rules in place between entities in order for authorization transactions to be executed. Trust is necessary to allow each entity to "know" that the policy it is authorizing is correct. This is a business issue as well as a protocol issue. Trust is often established through third party authentication servers (such as Kerberos), via a certificate Vollbrecht et al. expires December 1999 [Page 6] INTERNET DRAFT June 1999 authority, by configuring shared secrets or passwords, or by sharing a common facility (such as a connecting wire between processors). These "static" trust relationships are necessary for authorization transactions to take place. Static trust relationships are used in an authorization sequence to establish a "dynamic" relationship between the User and the Service Equipment. Several possible authorization sequences are possible, each of which use the static trust "chain" to have the user first be approved by the User Home Organization, and then have the Service Provider accept the request based on its trust of the User Home Organization. In general, the User Home Organization and the Service Provider are different entities or different "administrative domains". In the simplest case, however, the User Home Organization and the Service Provider may be combined as a single entity. This case will be used to describe three authorization sequences possible with the simple case. In following sections these concepts will be applied to more complicated cases involving separate User Home Organization and Service Provider entities (as in roaming) and multiple Service Providers each with their own AAA Servers and Service Equipment (as in distributed services). 2.1. Single Domain Case This case includes the User, the Service Provider's AAA Server, and the Service Provider's Service Equipment. Examples of this case include a NAS supported by a standalone RADIUS server, or a QoS Router supported by a local bandwidth broker. The sequences considered in the following figures are the "push", "pull", and "indirect" sequences for the single domain case. 2.1.1. The Push Sequence The push sequence (see figure 3) pushes authorization information to the Service Equipment from the Service Provider's AAA Server. In this model, the User sends a request to the Service Provider's AAA Server (1), which will apply a policy associated with the User and the particular service being requested. The AAA Server sends a request to the Service Equipment, and the Service Equipment sets up whatever is requested (2). The Service Equipment then responds to the AAA Server acknowledging that it has set up the Service for the user (3). The AAA Server replies to the User telling it that the Service is set up (4). Depending on the nature of the service, further communication may Vollbrecht et al. expires December 1999 [Page 7] INTERNET DRAFT June 1999 take place between the User and the Service Equipment. For this to occur, there needs to be a binding between the User and the authorized service. This requires further study. +-------------------------+ +------+ | Service Provider | | | 1 | +-------------------+ | | |------+->| AAA Server | | | |<-----+--| | | | | 4 | +-------------------+ | | User | | | /|\ | | | | |2 |3 | | | | \|/ | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | +------+ | | +-------------------------+ Fig. 3 -- Push Sequence Example: A regular user may ask for 1 Mb/s bandwidth (1). The bandwidth broker (AAA Server) tells the router (Service Equipment) to set this user into the 1Mb/s "queue" (2). The router responds that it has done so (3), and the bandwidth broker tells the User the bandwidth is set up (4). 2.1.2. The Pull Sequence The pull sequence (figure 4) is what is typically used in the Dialin application, in the Mobile-IP proposal, and in some QoS proposals. The User sends a request to the Service Equipment (1), which forwards it to the Service Provider's AAA Server (2), which evaluates the request and returns an appropriate response to the Service Equipment (3), which sets up the service and tells the User it is ready (4). Vollbrecht et al. expires December 1999 [Page 8] INTERNET DRAFT June 1999 +-------------------------+ +------+ | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | User | | /|\ | | | | | |2 |3 | | | | | \|/ | | | 1 | +-------------------+ | | |------+->| Service | | | |<-----+--| Equipment | | | | 4 | +-------------------+ | +------+ | | +-------------------------+ Fig. 4 -- Pull sequence 2.1.3. The Indirect Sequence The indirect sequence (figure 5) requires that the User get from the Service Provider's AAA Server a ticket or certificate verifying that it is o.k. for the User to have access to the service (1,2). The User includes the ticket in the request (3) to the Service Equipment. The Service Equipment uses the ticket to verify that the request is approved by the Service Provider's AAA Server. The Service Equipment then sends an o.k. to the User (4). The ticket the user gets from the Service Provider's AAA Server will typically have some time limit on it. It may contain an indication of service location, and in some applications, it might be used for more than one request. This is called indirect because the communication between the AAA Server and the Service Equipment is relayed through the User rather than directly between themselves. Vollbrecht et al. expires December 1999 [Page 9] INTERNET DRAFT June 1999 +-------------------------+ +------+ | Service Provider | | | 1 | +-------------------+ | | |------+->| AAA Server | | | |<-----+--| | | | | 2 | +-------------------+ | | User | | | | | | | | | | | | | 3 | +-------------------+ | | |------+->| Service | | | |<-----+--| Equipment | | | | 4 | +-------------------+ | +------+ | | +-------------------------+ Fig. 5 -- Indirect Sequence 2.2. Roaming -- the User Home Organization is not the Service Provider In many interesting situations, the organization that authorizes and authenticates the User is different from the organization providing the service. This situation has been explored in the Roaming Operations (roamops) Working Group. For purposes of this discussion, any situation in which the User Home Organization is different from the Service Provider is considered to be roaming. Examples of roaming include an ISP selling dialin ports to other organizations or a Mobile-IP provider allowing access to a user from another domain. The same push, pull and indirect sequences are possible with roaming. If the Service Provider's AAA Server and the Service Equipment are grouped as a logical entity for purposes of description, then the following figures illustrate these cases. Vollbrecht et al. expires December 1999 [Page 10] INTERNET DRAFT June 1999 +------+ +-------------------------+ | | 1 | User Home Organization | | |----->| +-------------------+ | | | | | AAA Server | | | |<-----| | | | | | 4 | +-------------------+ | | | | | | | +-------------------------+ | | | /|\ | | |2 |3 | | \|/ | | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 6 -- Roaming Push Sequence Vollbrecht et al. expires December 1999 [Page 11] INTERNET DRAFT June 1999 +------+ +-------------------------+ | | | User Home Organization | | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | | | | +-------------------------+ | | /|\ | | | |2 |3 | | | \|/ | | +-------------------------+ | | | Service Provider | | User | | +-------------------+ | | | | | AAA Server | | | | 1 | | | | | |----->| +-------------------+ | | | | | | |<-----| +-------------------+ | | | 4 | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 7 -- Roaming Pull Sequence Vollbrecht et al. expires December 1999 [Page 12] INTERNET DRAFT June 1999 +------+ +-------------------------+ | | 1 | User Home Organization | | |----->| +-------------------+ | | | | | AAA Server | | | |<-----| | | | | | 2 | +-------------------+ | | | | | | | +-------------------------+ | | | | | | | User | +-------------------------+ | | | Service Provider | | | | +-------------------+ | | | | | AAA Server | | | | 3 | | | | | |----->| +-------------------+ | | | | | | |<-----| +-------------------+ | | | 4 | | Service | | | | | | Equipment | | | | | +-------------------+ | | | | | +------+ +-------------------------+ Fig. 8 -- Roaming Indirect Sequence 2.3. Distributed Services To provide a complete service to a user, offerings from several service providers may need to be combined. An example would be a user who requires a QoS service for a session that crosses multiple ISPs. Any service that is provided by more than one Service Provider acting in concert is a distributed service. Figure 9 illustrates distributed services. Vollbrecht et al. expires December 1999 [Page 13] INTERNET DRAFT June 1999 +-------------------+ +-------------------+ +------+ | Org1 | | Org2 | | | | +-------------+ | | +-------------+ | | | | | AAA Server | | | | AAA Server | | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | User |======| |======| | | | | +-------------+ | | +-------------+ | | | | | Service | | | | Service | | | | | | Equipment | | | | Equipment | | | | | +-------------+ | | +-------------+ | +------+ | | | | +-------------------+ +-------------------+ Fig. 9 -- Distributed Services The agreements between entities in figure 9 imply that the request from the User will be authenticated and authorized by the first organization, then forwarded to the second organization. Note that the sequence between User and Org1 may be different than between Org1 and Org2. The first might use a push sequence and the second might use a pull. This example is illustrated in figure 10. +-------------------+ +-------------------+ +------+ | Org1 | | Org2 | | | | +-------------+ | 3 | +-------------+ | | | | | AAA Server |--+------+->| AAA Server | | | | | | |<-+------+--| | | | | | +-------------+ | 6 | +-------------+ | | User | | /|\ | | | | /|\ | | | | |2 |7 | | |4 |5 | | | | | \|/ | | \|/ | | | | 1 | +-------------+ | | +-------------+ | | |------+->| Service | | | | Service | | | |<-----+--| Equipment | | | | Equipment | | | | 8 | +-------------+ | | +-------------+ | +------+ | | | | +-------------------+ +-------------------+ Fig. 10 -- A Possible Distributed Sequence There are a number of other ways that authorization sequences for distributed services can be set up. For example, it is possible Vollbrecht et al. expires December 1999 [Page 14] INTERNET DRAFT June 1999 that, in order to reduce delay time in setting up a session, Org1 could send a response to the user before receiving a verification that Org2 has authorized the service. In that case Org1 would need to be able to revoke the authorization sent earlier if Org2 does not send the authorization in some amount of time. 2.4. Combining Roaming and Distributed Services Figure 11 shows a combination of Roaming and Distributed Services. Contract and trust relationships may be set up in number of ways, depending on a variety of factors, especially the business model. +------+ +-------------------+ +-------------------+ | | | User Home Org | | SuperOrg | | | | +-------------+ | | +-------------+ | | | | | AAA Server | | | | AAA Server | | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | +-------------------+ +-------------------+ | | | | | | +-------------------+ +-------------------+ | User | | Org1 | | Org2 | | | | +-------------+ | | +-------------+ | | | | | AAA Server | | | | AAA Server | | | | | | | | | | | | | | | +-------------+ | | +-------------+ | | | | | | | | | | +-------------+ | | +-------------+ | | | | | Service | | | | Service | | | | | | Equipment | | | | Equipment | | | | | +-------------+ | | +-------------+ | | | | | | | +------+ +-------------------+ +-------------------+ Fig. 11 -- Roaming and Distributed Services New entities that combine or add capabilities can be created to meet business needs. In figure 11, one such possibility, a SuperOrg entity is shown. The idea is that this entity would provide authentication and authorization for organizations that are providing services to end-users. It could be considered to be a wholesaler or broker. While not all authorization will require having a broker, authorization protocols should allow such entities to be created to meet legitimate requirements. Vollbrecht et al. expires December 1999 [Page 15] INTERNET DRAFT June 1999 Having considered the basic players and how they interact, we will now consider different ways that authorization data may be stored in the network. 2.5. Use of Policy to Store Authorization Data The Policy Framework (policy) Working Group is seeking to provide a framework to represent, manage, and share policies and policy information in a vendor-independent, interoperable, scalable manner. [3],[4] This section explores the intersection of policy and authorization, and sets the stage for defining protocol requirements for supporting policy when included as part of authorization. A major part of authorization is validating that the authorization request meets policy requirements. In this document the assumption is that each administration may have policies which may be indexed by user, by service, or by other attributes of the request. The policies of each administration are defined independently of other administrations. For each administration, policy must be stored, evaluated, and enforced. Storage is typically in the administration that defines the policy. Thus a policy defining the times of day that a particular User is allowed to connect to the network is maintained and stored by the User Organization. A policy defining a time that ports will be unusable because of maintenance is created and stored by the Service Provider. Evaluation of policy may be done in several places. Often the information required to do the evaluation is not in the administration where the policy is stored. For example, checking that a user is allowed to login at the current time can readily be done by the User Home Organization. But authorizing a user requiring a 2Mb/s path with less than 4 hops requires information not directly available to the UHO, so the UHO must either 1) have a way to query a remote administration for the needed information or 2) forward the policy to the remote administration and have the remote administration do the actual evaluation or 3) attempt somehow to "shadow" the authoritative source of the information. If one assumes that applications exist for which either 1) or 2) above are most appropriate, then a general authorization protocol should allow both. In many instances of case 2), for example, the remote administration can retrieve a policy using a directory access protocol. But directory access protocols do not have all the features that are sometimes required for AAA. Suppose the remote administration and the home administration communicate via a broker which proxies their communications. It may be necessary for the home Vollbrecht et al. expires December 1999 [Page 16] INTERNET DRAFT June 1999 administration to retrieve the policy from the directory and then forward it to the remote administration through the proxy chain. Generally, any of the AAA Servers involved in an authorization transaction may contain a Policy Decision Point (PDP), and any of the Service Equipment may contain a Policy Enforcement Point (PEP). Policy Stores may reside on any of the AAA Servers or be located elsewhere in the network. Data against which policy conditions are evaluated (Policy Data) may reside anywhere. The interesting questions in any authorization application that uses policy are, where are the PDPs and PEPs, where are the policy stores, and where are the Policy Data located? Figure 12 shows which policy elements may be available at different points in the model. In distributed services, there may be multiple Service Providers involved in the authorization transaction, and each may maintain the policy elements shown below. +------+ +---------------------------------------+ | | | User Home Organization | | | | +-------------------+ Policy Store | | | | | AAA Server | Policy Data | | | | | | PDP | | | | +-------------------+ | | | | | | | +---------------------------------------+ | | | | | | +---------------------------------------+ | User | | Service Provider | | | | +-------------------+ Policy Store | | | | | AAA Server | Policy Data | | | | | | PDP | | | | +-------------------+ | | | | | | | | +-------------------+ | | | | | Service | Policy Data | | | | | Equipment | PEP | | | | +-------------------+ | | | | | +------+ +---------------------------------------+ Fig. 12 -- Where Different Policy Elements May be Located Vollbrecht et al. expires December 1999 [Page 17] INTERNET DRAFT June 1999 2.6. Use of Attribute Certificates to Store Authorization Data This section outlines another mechanism that could be used for securely transporting the attributes on which an authorization decision is to be made. Work on X.509 Attribute Certificates is currently being undertaken in the Public Key Infrastructure (PKIX) Working Group [5]. This proposal is largely based on that work. When considering authorization using certificate-based mechanisms, one is often less interested in the identity of the entity than in some other attributes, (e.g. roles, account limits etc.), which should be used to make an authorization decision. In many such cases, it is better to separate this information from the identity for management, security, interoperability or other reasons. However, this authorization information may also need to be protected in a fashion similar to a public key certificate. The name used here for such a structure is an Attribute Certificate (AC) which is a digitally signed (certified) set of attributes. An AC is a structure that is similar to an X.509 public key certificate [6] with the main difference being that it contains no public key. The AC typically contains group membership, role, clearance and other access control information associated with the AC owner. A syntax for ACs is also defined in the X.509 standard. When making an access decision based on an AC, an access decision function (in a PEP, PDP or elsewhere) may need to ensure that the appropriate AC owner is the entity that has requested access. The linkage between the request and the AC can be achieved if the AC has a "pointer" to a Public Key Certificate (PKC) for the requester and that the PKC has been used to authenticate the request. Other forms of linkage can be defined which work with other authentication schemes. As there is often confusion about the difference between public key certificates (PKC's) and attribute certificates (ACs), an analogy may help. A PKC can be considered to be like a passport: it identifies the owner, it tends to be valid for a long period, it is difficult to forge, and it has a strong authentication process to establish the owner's identity. An AC is more like an entry visa in that it is typically issued by a different authority than the passport issuing authority, and it doesn't have as long a validity period as a passport. Acquiring an entry visa typically requires presenting a passport that authenticates that owner's identity. As a consequence, acquiring the entry visa becomes a simpler procedure. The entry visa will refer to the passport as a part of how that visa specifies the terms under which the passport owner is authorized to enter a Vollbrecht et al. expires December 1999 [Page 18] INTERNET DRAFT June 1999 country. In conjunction with authentication services, ACs provide a means to transport authorization information securely to applications. However, there are a number of possible communication paths that an AC may take. In some environments, it is suitable for a client to "push" an AC to a server. This means that no new connections between the client and server domains are required. It also means that no search burden is imposed on servers, which improves performance. In other cases, it is more suitable for a client simply to authenticate to the server and for the server to request the client's AC from an AC issuer or a repository. A major benefit of the this model is that it can be implemented without changes to the client and client/server protocol. It is also more suitable for some inter- domain cases where the client's rights should be assigned within the server's domain, rather than within the client's "home" domain. There are a number of possible exchanges that can occur, and there are three entities involved: client, server, and AC issuer. In addition the use of a directory service as a repository for AC retrieval may be supported. Figure 13 shows an abstract view of the exchanges that may involve ACs. Note that the lines in the diagram represent protocols which must be defined, not data flows. The PKIX working group will define the required acquisition protocols. One candidate for the lookup protocols is LDAP (once an LDAP schema exists which states where an AC is to be found). Vollbrecht et al. expires December 1999 [Page 19] INTERNET DRAFT June 1999 +--------------+ +---------------+ | AAA Server/ | | | | AC Issuer +----+ | Directory | | | | | | +--+-----------+ | Server +-------+-------+ | | Acquisition | |Client | |Server |Acquisition +----------------------+ |Lookup | | | +--+-----------+ +--+----+-------+ | | AC in application | Service | | User +------------------------+ Equipment/ | | | protocol | AAA Server | +--+-----------+ +---------------+ | | Client Lookup +--+-----------+ | | | Directory | | | +--------------+ Fig. 13 -- AC Exchanges Figure 14 shows the data flows which may occur in one particular case, that termed "indirect" above (section 2.1.3). +--------------+ | AAA Server/ | | AC Issuer | | | +--+-----------+ | |Client |Acquisition (1) | +--+-----------+ +---------------+ | | AC in application | Service | | User +------------------------+ Equipment/ | | | protocol (2) | AAA Server | +--------------+ +---------------+ Fig. 14 -- One example of an AC exchange Vollbrecht et al. expires December 1999 [Page 20] INTERNET DRAFT June 1999 In the diagram, the user first contacts the AC Issuer and then incorporates the AC into the application protocol. The Service Equipment must then validate the AC and use it as the basis for the access decision (this functionality may be distributed between a PEP and PDP). 2.7. Resource Management Authorization requests may be chained through a set of servers, as described in previous sections. Each of the servers may have a contractual relationship with servers on either side of it in the chain. In many of the applications being considered, the authorization results in establishing of an ongoing service which we call a session. Each of the servers involved in the authorization may also want to keep track of the state of the session, and be able to effect changes to the session if required. To make it simple to discuss this capability, we assume that each AAA Server MAY have a Resource Manager component. Resource Managers tracking the same session need to be able to initiate changes to the session, and to inform other Resource Managers when changes occur. Communication between Resource Managers creates requirements for an authorization protocol. An example of the use of resource management might be a user which sets up a QoS path through two ISPs, and while this path is active, one of the ISPs gets a request for more bandwidth from a higher priority user. The ISP may need to take some bandwidth from a the lower priority user's previously allocated session and give it to the new request. To do this, each of the administrations in the authorization path must be informed and agree to the change (this could be considered to be "authorizing the new value"). 2.7.1. Session Management and State Synchronization When an AAA Server grants authorization of some resource to an AAA requester (either a User or another AAA Server), the server may need to maintain session state information. This is used to make decisions about new sessions based on the state of current sessions, and to allow monitoring of sessions by all interested AAA Servers. Each session is identified by a session identifier, which must be unique within each AAA Server. Communication between AAA Servers must include the session identifier. It is desirable that the session identifier is the same across all AAA servers, otherwise each server will have to map identifiers from other servers to its own identifiers. A single session identifier significantly simplifies auditing and session control functions. Vollbrecht et al. expires December 1999 [Page 21] INTERNET DRAFT June 1999 Maintaining session state across AAA administrative boundaries increases the complexity of the problem, especially if each AAA Server in the trust chain must keep state as well. This can be viewed as an interdomain database replication problem. The protocol must include tools to help manage replicated state. Some of the problems to be addressed are: a) Service Equipment must be able to notify its Resource Manager when a session terminates or changes state in some other way. The Resource Manager must inform other Resource Managers which keep state for this session. b) The Resource Manager will need to set a time limit for each session which must be refreshed by having the Resource Manager query for authoritative status or by having the authoritative source send periodic keep alive messages that are forwarded to all Resource Managers in the authorization chain. Determining the appropriate session lifetime may be application specific and depends on the acceptable level of risk. If the service being offered is billed based on time, the session lifetime may need to be relatively small; if the service is billed on usage, the lifetime may be relatively large. c) Any Resource Manager in the chain must have the ability to terminate a session. This requires the Resource Manager to have knowledge of at least the adjacent AAA Servers in the authorization chain. An example of how resource management can be used is in the PPP dialin application. A home ISP may wish to restrict the number of concurrent sessions that a user can have at any given time. This is particularly important when service providers give all-you-can-eat Internet access. The possibility for fraud is quite large, since a user could provide his or her username/password to many people, causing a loss of revenue. Resource management would allow the home ISP AAA server to identify when a user is active and to reject any authorization request for the user until termination indication is received from the NAS or until the session expires. 2.7.2. The Resource Manager This section describes the functions of the Resource Manager in more detail. The Resource Manager is the component which tracks the state of sessions associated with an AAA Server or Service Equipment. It also may allocate resources to a session (e.g. IP addresses) and may track use of resources allocated by peer resource managers to a session Vollbrecht et al. expires December 1999 [Page 22] INTERNET DRAFT June 1999 (e.g. bandwidth in a foreign administrative domain). The resource manager also provides interfaces to allow the User to acquire or release authorized sessions. The Resource Manager maintains all session specific AAA state information required by the AAA Server. That state information may include pointers to peer Resource Managers in other administrative domains that possess additional AAA state information that refers to the same session. The Resource Manager is the anchor point in the AAA Server from which a session can be controlled, monitored, and coordinated even if that session is consuming network resources or services across multiple Service Provider administrative domains. The Resource Manager has several important functions: a) It allows a Service Provider operations staff to inspect the status of any of the allocated resources and services including resources that span foreign Service Provider administrative boundaries. The peer Resource Managers will cooperatively share only the state information subset that is required to assist in diagnosing cross-domain trouble tickets. The network operator may also modify or altogether cancel one of the User's active authorizations. b) It is the process contacted by other Resource Managers to inform the AAA Server that a specific session has been cancelled. This information is relayed to the other peer Resource Managers that also know about that session and hence must cancel it. c) The Resource Manager conceals the identity and location of its private internal AAA components from other administrative domains and from the User, while at the same time facilitating cooperation between those domains. d) The Resource Manager cooperates with "policy servers" or Policy Decision Points (PDPs). The Resource Manager maintains internal state information, possibly complex cross-administrative domain information, supported by dialogues with its peer Resource Managers. A policy server can use the state information when evaluating a particular policy. e) The separation of the Resource Manager and the policy server into two distinct architectural components allows a single session to span multiple administrative domains, where each administrative domain has one or more policy server cooperating with its Resource Manager. AAA resource managers will normally use the same trust relationships Vollbrecht et al. expires December 1999 [Page 23] INTERNET DRAFT June 1999 needed for authorization sequences. It is possible for independent relationships to be established, but that is discouraged. 2.8. AAA Message Forwarding and Delivery An AAA Server is responsible for securely forwarding AAA messages to the correct destination system or process in the AAA infrastructure. Two well known examples are forwarding AAA messages for a roaming AAA service, and forwarding AAA messages for a distributed AAA service. The same principle can also be applied to intra-domain communications. The message forwarding is done in one of two modes. The first mode is when an AAA server needs to forward a message to a peer AAA server that has a known "logical destination address" that must be resolved by an application-specific procedure into its actual network address. Typically the forwarding procedure indexes into a database by an application-specific identifier to discover the peer's network address. For example, in the roaming dialin application, the application-specific identifier may be an NAI. A bandwidth brokerage application would use other search indices unique to its problem domain to select the addressed peer AAA server. After the address resolution procedure has completed successfully, then the AAA server transmits the message to its peer over the connection associated with that destination network address. The second mode is when the AAA server already has an established session representing an authorization. The session's state contains the addressing and context used to direct the message to its destination peer AAA server, PDP, PEP, or User. The message is sent over the AAA server's connection to that destination peer, multiplexed with other session's messages. The message must be qualified by a session identifier that is understood by both end points. The AAA message's destination may be either intra- administrative domain, or inter-administrative domain. In the former case, the destination process may reside on the same system as the AAA server. In addition to the above message forwarding processing, the underlying message delivery service must meet the following requirements: - Unicast capability -- An end system can send a message to any other end system with minimal latency of session setup/disconnect overhead messages, and no end system overhead of keeping state information about every potential peer. - Data integrity and error detection -- This data transport protocol assumes an underlying datagram network layer service that includes Vollbrecht et al. expires December 1999 [Page 24] INTERNET DRAFT June 1999 packet discard on error detection, and data integrity protection against third party modifications. - Reliable data transport assurance -- When an end system successfully receives a message marked receipt requested, it must acknowledge that message to the sending system by either piggybacking the acknowledgement on an application-specific reply message, or else as a standalone acknowledgement message. The sending system maintains a retry timer; when the timer expires, the sending system retransmits a copy of its original message. It gives up after a configurable number of unsuccessful retries. - Sequenced data delivery -- If multiple messages are sent between a pair of end systems, those messages are delivered to the addressed application in the same order as they were transmitted. Duplicates are silently suppressed. - Responsive to network congestion feedback -- When the network enters into congestion, the end systems must detect that condition, and they must back off their transmission rate until the congestion subsides. The back off and recovery algorithms must avoid oscillations. 2.9. End-to-End Security When AAA servers communicate through intermediate AAA servers, such as brokers, it may be necessary that a part of the payload be secure between the originator and the target AAA server. The security requirement may consist of one or more of the following: end-to-end message integrity, confidentiality, replay protection, and nonrepudiation. Furthermore, it is a requirement that intermediate AAA servers be able to append information such as local policy to a message before forwarding the message to its intended destination. It may also be required that an intermediate AAA Server sign such appended information. This requirement has been clearly documented in [7], which describes many current weaknesses of the RADIUS protocol [8] in roaming networks since RADIUS does not provide such functionality. One well-known attack is the ability for the intermediate nodes to modify critical accounting information, such as a session time. Most popular security protocols (e.g. IPSec, SSL, etc) do not provide the ability to secure a portion of the payload. Therefore, it may be necessary for the AAA protocol to implement its own security extensions to provide end-to-end security. Vollbrecht et al. expires December 1999 [Page 25] INTERNET DRAFT June 1999 2.10. Streamlined Authorization Process The techniques described above allow for great flexibility in distributing the components required for authentication and authorization. However, working groups such as Roamops and MobileIP have identified requirements to minimize Internet traversals in order to reduce latency. To support these requirements, data fields necessary for both authentication and authorization SHOULD be able to be carried in a single message set. This is especially important when there are intermediate servers (such as Brokers) in the AAA chain. Furthermore, it should be possible for the Brokers to allow end-to- end (direct) authentication and authorization. This can be done as follows. The User Home Organization generates a ticket which is signed using the UHO's private key. The ticket is carried in the accounting messages. The accounting messages must flow through the Broker since the Broker is acting as the settlement agent and requires this information. There are Brokers that will require to be in the authentication and authorization path as well since they will use this information to detect fraudulent activity, so the above should be optional. In order for end-to-end authentication and authorization to occur, it may be necessary for the Broker to act as a certificate authority. All members of the roaming consortium would be able to trust each other (to an extent) using the certificates. A Service Provider's AAA server that sends a request to the Broker should be able to receive a redirect message which would allow the two peers (Service Provider and UHO) to interact directly. The redirect message from the Broker should include the UHO's certificate, which eliminates the Service Provider from accessing the certificate archive. The request from the Service Provider could include its own certificate, and a token from the Broker's redirect message that is timestamped and guarantees that the Service Provider is in good standing with the Broker. This eliminates the home domain from accessing the Certificate Revocation List (CRL). 2.11. Summary of the Architecture The above has introduced the basic players in an authorization transaction as User, User Home Organization, Service Provider's AAA Server, and Service Equipment. It has discussed relationships between entities based on agreements or contracts, and on "trust". Examples of authorization sequences have been given. Concepts of roaming and distributed services have been briefly described. Combination of roaming and distributed services was also Vollbrecht et al. expires December 1999 [Page 26] INTERNET DRAFT June 1999 considered and the concept of a "wholesaler" or Broker was introduced. We have considered the use of policies and attribute certificates to store and transmit authorization data. We discussed the problem of managing the resources to which access has been authorized including the problem of tracking state information for session-oriented services, and we defined the Resource Manager component of a AAA Server. We considered the problem of forwarding AAA messages among servers in possibly different administrative domains. We considered the need for end-to-end security of portions of the payload of authorization messages that pass through intermediate AAA Servers. Finally we stressed the need for support of a streamlined authorization process that minimizes delay for latency-sensitive applications. The intent is that this will provide support for discussing and understanding requirements of specific applications that need authorization services. 3. Requirements for Authorization Protocol The question of requirements for an authorization protocol is actively being studied as this draft goes to publication. The authorization requirements of various applications are listed in the appendix. These need to be collected and discussed before they can be presented here as general requirements. Section 3.1, below lists requirements that have been identified for the use of attribute certificates. Many of these are actually much more general in nature. We have retained them in section 3.1 for safe-keeping. The intention of the authors is to develop a comprehensive set of authorization protocol requirements for inclusion in the next revision of this document based on the material in the preceding section and the appendix. 3.1. Requirements for Authorization Attribute Handling 3.1.1. Basic Requirements 1. Authorization decisions are made on the basis of (sets of) attributes associated with the requester of a service. 2. A secure format for transporting (sets of) attributes to an authorization decision function (at a PDP or elsewhere) is required. Vollbrecht et al. expires December 1999 [Page 27] INTERNET DRAFT June 1999 3. A set of attributes may have an associated validity period - such that that the set should only be used for authorization decisions during that period. 4. The validity period may be relatively long, (e.g. months) or short (hours, minutes). 5. A method for securely transporting (sets of) attributes is required. Although the details of attribute administration may not be in scope, support for the concept of an attribute authority (AA) which issues (sets of) attributes in a standard format (an Attribute Certificate or AC) is required. 3.1.2. Requirements for the Use of Attribute Certificates The remainder of the requirements are phrased in terms of ACs, AC Issuers, etc. 1. Issuers of ACs should be able to define their own attribute types for use within closed domains. 2. It should be possible to define service-specific attribute types so that service implementors and AC issuers can deploy an authorization solution. 3. Some standard attribute types should be defined with wide applicability, which can be contained within ACs and which can be used across many services, for example "access identity", "group", "role", "clearance", "audit identity", "charging id" etc. 4. Standard attribute types should be defined so that it is possible for an AC verifier to distinguish between, e.g., the "Administrators group" as defined by SSE and the "Administrators group" as defined by Widgets Inc. 5. ACs should support the encryption of some, or all, attributes (e.g. passwords for legacy applications). It should be possible for such an encrypted attribute to be deciphered by an appropriate AC verifier even where the AC has not been received directly from the AC owner (i.e. where the AC is proxied). This is required as some attributes may be considered sensitive, e.g., clearance, etc. 6. It should be possible to "target" an AC. This means that a given AC may be "targeted" at one, or a number of, servers/services in the sense that a trustworthy non-target will reject the AC for authorization decisions. Vollbrecht et al. expires December 1999 [Page 28] INTERNET DRAFT June 1999 7. It should be possible for a server to proxy an AC when it acts as a client (for another server) on behalf of the AC owner. 8. Proxying should be under the AC issuer's control, so that not every AC is proxiable and so that a given proxiable AC can be proxied in a targeted fashion. 9. Support for chains of proxies (with more than one intermediate server) is required. 10. ACs may either be "pushed" by the client to the server, or "pulled" by the server from a network service (whether the AC issuer or a directory service). 11. To date, no requirements have been identified for meaning of a chain of ACs (which would be analogous to a certificate path) or AC translation. However, it may be that some AAA applications do require such functionality. 4. Security Considerations 4.1. Security Considerations in Existing Systems 4.2. Security Considerations of the Proposed Architecture Vollbrecht et al. expires December 1999 [Page 29] INTERNET DRAFT June 1999 Appendix -- Examples of Authorization Applications In this section, we examine several important applications that require authorization. The material in these sections is not contributed by the working groups responsible for the applications. Nor should it be considered prescriptive for how those applications will meet their authorization needs. The intent, rather, is to explore the fundamental needs of a variety of quite different applications with the view of compiling a set of basic requirements that an authorization protocol would need to meet in order to be generally useful. For each application, we present a model showing how it might do authorization and then map that model back to the architecture presented in section 2. We then present the authorization requirements of that application as best we can presently understand them. The union of these requirements are then generalized and listed in section 3. A.1. PPP Dialin with Roaming A.1.1. Descriptive Model The PPP dialin application uses the pull sequence as discussed in section 2.1.2, above. The roaming case uses the roaming pull sequence as diagrammed in figure 7, above. This figure is redrawn using dialin roaming terminology in figure 15, below. Vollbrecht et al. expires December 1999 [Page 30] INTERNET DRAFT June 1999 +------+ +-------------------------+ | | | Home ISP | | | | (User Home Organization)| | | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | /|\ | | | | +--------------+---+------+ | | | | | | |3 |4 | | | | | | +--------------+---+------+ | | | Visited ISP | | | | | | | \|/ | | User | | +-------------------+ | | | | | AAA Server | | | | | | | | | | | +-------------------+ | | | | /|\ | | | | | |2 |5 | | | | | \|/ | | | 1 | +-------------------+ | | |------+->| NAS (Service | | | |<-----+--| Equipment) | | | | 6 | +-------------------+ | | | | (Service Provider) | +------+ PPP +-------------------------+ Fig. 15 -- Dialin Authorization Based on Roaming Pull Sequence In this model, the User dials in to a Network Access Server (NAS) provided by the visited (or foreign) ISP (the Service Provider in the general model). The User is authenticated using a protocol such as PAP, CHAP, or EAP which is encapsulated in PPP frames (1). Because the User has not yet gained access to the network, he or she cannot send IP datagrams to a AAA server. At this point, the User can only communicate with the NAS (Service Equipment). The NAS forwards the User's authentication/ authorization request including the Network Access Identifier (NAI) [9] to a AAA server in its own domain via RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA server examines the realm from the NAI and forwards the request to the User's home domain AAA server (3). The home domain AAA server Vollbrecht et al. expires December 1999 [Page 31] INTERNET DRAFT June 1999 authenticates the user and authorizes access according to a roaming agreement. The home domain AAA server may return service parameters (e.g. Idle-Timeout) to the visited ISP's AAA server (4) which forwards them to the NAS, possibly adding additional service parameters (5). The NAS completes PPP session initialization (6). In the future, this model may be expanded in several ways [10]. For instance, Authentication and Authorization may be done in separate passes using different servers in order to support specialized forms of authentication. Or to better support roaming, a broker may be inserted between the visited ISP and the home ISP. Or authorization may be supported based on other identifiers such as the caller ID and called ID obtained from the PSTN (e.g., using ANI and DNIS). A.1.2. Authorization Requirements The following requirements are identified in [10] for authorizing PPP dialin service using roaming. - Authorization separate from authentication should be allowed when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization. - The AAA protocol MUST be "proxyable", meaning that a AAA Server or PDP MUST be able to forward the request to another AAA Server or PDP, which may or may not be within the same administrative domain. - The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response. - When a broker is involved, the protocol MUST provide end to end security. - The broker MUST be able to return a forwarding address to a requester, allowing two nodes to communicate together. - The protocol MUST provide the following features (per user session): 1. One Authentication, One Authorization 2. One Authentication, Multiple Authorization 3. Multiple Authentication, Multiple Authorization A.2. Mobile-IP The Mobile-IP protocol is used to manage mobility of an IP host across IP subnets [11]. Recent activity within the Mobile-IP Working Group has defined the interaction between Mobile-IP and AAA in order Vollbrecht et al. expires December 1999 [Page 32] INTERNET DRAFT June 1999 to provide: - Better scaling of security associations - Mobility across administrative domain boundaries - Dynamic assignment of Home Agent The Mobile IP protocol, as defined in [11], works well when all mobile nodes belong to the same administrative domain. Some of the current work within the Mobile IP Working Group is to allow Mobile IP to scale across administrative domains. This changes the trust model that is currently defined in [11]. Figure 16 depicts the new AAA trust model for Mobile-IP. In this model each network contains mobile nodes (MN) and a AAA server (AAA). Each mobility device shares a security association (SA) with the AAA server within its own home network. This means that none of the mobility devices initially share a security association. Both administrative domains' AAA servers can either share a security association, or can have a security association with an intermediate broker. Broker AAA +--------+ | | | AAA | /=====| |=====\ // +--------+ \\ Foreign // SA SA \\ Home AAA // \\ AAA +--------+ +--------+ | | SA | | | AAA |======================| AAA | | | (in lieu of broker) | | +--------+ +--------+ || || || || || || SA || SA || || SA || || || || || || +---------+ +---------+ +---------+ | | | | | | | FA | | HA | | MN | | | | | | | +---------+ +---------+ +---------+ Fig. 16 -- Mobile-IP AAA Trust Model Vollbrecht et al. expires December 1999 [Page 33] INTERNET DRAFT June 1999 Figure 17 provides an example of a Mobile-IP network that includes AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each mobility agent shares a security association between itself and its local AAA server. Further, the Home and Foreign AAA servers both share a security association with the broker's AAA server. Lastly, it is assumed that each mobile node shares a trust relationship with its home AAA Server. Visited Access Broker Home IP Provider Network Network Network +--------+ +--------+ +--------+ | | | | | | | AAA |------| AAA |------| AAA | | | | | | | +--------+ +--------+ +--------+ | | | | AAA | | AAA | | | | +---------+ +---------+ | | | | | FA | | HA | | | | | +---------+ +---------+ | | Visited Access Home Network | Provider Network -Private Network Mobile | -Home Provider IP | -Home ISP | +--------+ | Mobile | | Node | +--------+ Fig. 17 -- General Wireless IP Architecture for Mobile-IP AAA In this example, a Mobile Node appears within a foreign network and issues a registration to the Foreign Agent. Since the Foreign Agent does not share any security association with the Home Agent, it sends a AAA request to its local AAA server, which includes the authentication information and the Mobile-IP registration request. The Mobile Node cannot communicate directly with the home AAA Server for two reasons: Vollbrecht et al. expires December 1999 [Page 34] INTERNET DRAFT June 1999 - It does not have access to the network. The registration request is sent by the Mobile Node to request access to the network. - The Mobile Node may not have an IP address, and may be requesting that one be assigned to it by its home provider. The Foreign AAA Server will determine whether the request can be satisfied locally through the use of the Network Access Identifier [9] provided by the Mobile Node. The NAI has the format of user@realm and the AAA Server uses the realm portion of the NAI to identify the Mobile Node's home AAA Server. If the Foreign AAA Server does not share any security association with the Mobile Node's home AAA Server, it may forward the request to its broker. If the broker has a relationship with the home network, it can forward the request, otherwise a failed response is sent back to the Foreign AAA Server. When the home AAA Server receives the AAA Request, it authenticates the user and begins the authorization phase. The authorization phase includes the generation of: - Dynamic Session Keys to be distributed among all Mobility Agents - Optional Dynamic assignment of a Home Agent - Optional Dynamic assignment of a Home Address (note this could be done by the Home Agent). - Optional Assignment of QOS parameters for the Mobile Node [12] Once authorization is complete, the home AAA Server issues an unsolicited AAA request to the Home Agent, which includes the information in the original AAA request as well as the authorization information generated by the home AAA server. The Home Agent retrieves the Registration Request from the AAA request and processes it, then generates a Registration Reply that is sent back to the home AAA server in a AAA response. The message is forwarded through the broker back to the Foreign AAA server, and finally to the Foreign Agent. The AAA servers maintain session state information based on the authorization information. If a Mobile Node moves to another Foreign Agent within the foreign domain, a request to the foreign AAA server can immediately be done in order to immediately return the keys that were issued to the previous Foreign Agent. This minimizes an additional round trip through the internet when micro mobility is involved, and enables smooth hand-off. A.2.1. Relationship to the Architecture Mobile-IP uses the roaming pull model (section 2.2, figure 7). The Vollbrecht et al. expires December 1999 [Page 35] INTERNET DRAFT June 1999 Mobile Node is the User. The Foreign Network is the Service Provider with the Foreign Agent as the Service Equipment. The Home Network is the User Home Organization. Note that the User Home Organization operates not only a AAA Server, but also the Home Agent. Note, also, that a broker has been inserted between the Service Provider and the User Home Organization. A.2.2. Minimized Internet Traversal Although it would have been possible for the AAA interactions to be performed for basic authentication and authorization, and the Registration flow to be sent directly to the Home Agent from the Foreign Agent, one of the key Mobile-IP AAA requirements is to minimize Internet Traversals. Including the Registration Request and Replies in the AAA messages allows for a single traversal to authenticate the user, perform authorization and process the Registration Request. This streamlined approach is required in order to minimize the latency involved in getting wireless (cellular) devices access to the network. New registrations should not increase the connect time more than what the current cellular networks provide. A.2.3. Key Distribution In order to allow the scaling of wireless data access across administrative domains, it is necessary to minimize the security associations required. This means that each Foreign Agent does not share a security association with each Home Agent on the Internet. The Mobility Agents share a security association with their local AAA server, which in turn shares a security association with other AAA servers. Again, the use of brokers, as defined by the Roaming Operations (roamops) Working Group, allows such services to scale by allowing the number of relationships established by the providers to be reduced. After a Mobile Node is authenticated, the authorization phase includes the generation of Sessions Keys. Specifically, three keys are generated: - k1 - Key to be shared between the Mobile Node and the Home Agent - k2 - Key to be shared between the Mobile Node and the Foreign Agent - k3 - Key to be shared between the Foreign Agent and the Home Agent Each Key is propagated to each mobility device through the AAA protocol (for the Foreign and Home Agent) and via Mobile-IP for the Vollbrecht et al. expires December 1999 [Page 36] INTERNET DRAFT June 1999 Mobile Node (since the Mobile Node does not interface directly with the AAA servers). Figure 18 depicts the new security associations used for Mobile-IP message integrity using the keys derived by the AAA server. +--------+ +--------+ | | k3 | | | FA |======================| HA | | | | | +--------+ +--------+ \\ // \\ k2 k1 // \\ +--------+ // \\ | | // \=====| MN |=====/ | | +--------+ Fig. 18 -- Security Association after Key Distribution Once the session keys have been established and propagated, the mobility devices can exchange registration information directly without the need of the AAA infrastructure. However the session keys have a lifetime, after which the AAA infrastructure must be used in order to acquire new session keys. A.2.4. Mobile-IP Authorization Requirements To summarize, Mobile-IP has the following authorization requirements: - Uses the roaming pull model (figure 7). - Requires broker support. - Authorization includes resource management. - Authentication and authorization are included in a single AAA request. - Mobile-IP Registration messages are embedded in the AAA messages to minimize internet traversals. - User Authorization includes Session Key Generation (KDC). - User Authorization includes Assignment of Home Agent and Home Address. - User Authorization includes Diff-Serv QOS Profile [12]. - An Unsolicited AAA message is sent to the Home Agent. Vollbrecht et al. expires December 1999 [Page 37] INTERNET DRAFT June 1999 A.3. Bandwidth Broker This section describes authorization aspects derived from the Bandwidth Broker architecture as discussed within the Internet2 Qbone BB Advisory Council. We use authorization model concepts to identify contract relationships and trust relationships, and we present possible message exchanges. We will derive a set of authorization requirements for Bandwidth Brokers from our architectural model. The Internet 2 Qbone BB Advisory Council researches a single and multi- domain implementation based on 2-tier authorization concepts. A 3- tier model is considered as a future work item and therefore not part of this description. Information concerning the Internet 2 Bandwidth Broker work and its concepts can be found at: http://www.merit.edu/working.groups/i2-qbone-bb The material in this section is based on [13] which is a work in progress of the Internet2 Qbone BB Advisory Council. A.3.1. Model Description The establishment of a model involves four steps: 1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components. A.3.2. Components of the Two-Tier Model for Bandwidth Brokerage We will consider the components of a bandwidth broker transaction in the context of the conceptual entities defined in section 2, above. The bandwidth broker two-tier model recognizes a User and the Service Provider controlling the Service Equipment. The components are as follows: - The Service User (User) -- A person or process willing to use certain level of QoS by requesting the allocation of a quantifiable amount of resource between a selected destination and itself. In bandwidth broker terms, the User is called a Service User, capable of generating a Resource Allocation Request (RAR). - The Bandwidth Broker (Service Provider) -- a function that Vollbrecht et al. expires December 1999 [Page 38] INTERNET DRAFT June 1999 authorizes allocation of a specified amount of bandwidth resource between an identified source and destination based on a set of policies. In this context we refer to this function as the Bandwidth Broker. A Bandwidth Broker is capable of managing the resource availability within a network domain it controls. Note: a 3-tier model involving a User Home Organization is recognized (see section 3.2.3 of [13]), however its development is left for future study and therefore it is not discussed in this document. A.3.3. Identification of Contractual Relationships Authorizations to obtain bandwidth are based on contractual relationships. In both the single and muli-domain cases, the current Bandwidth Broker model assumes that a User always has a contractual relationship with the service domain to which it is connected. A.3.3.1. Single-Domain Case In the single-domain case, the User has a contract with a single Service Provider in a single service domain. +-------------+ | | | +---------+ | | |Bandwidth| | +-------+ | |Broker | | | | | | | | |Service| | +---------+ | |User |=========| | | | | +---------+ | | | | | Network | | +-------+ | | Routing | | | | Devices | | | +---------+ | | Autonomous | | Service | | Domain | +-------------+ ==== contractual relationship Fig. 19 -- Two-Tier Single Domain Contractual Relationships Vollbrecht et al. expires December 1999 [Page 39] INTERNET DRAFT June 1999 A.3.3.2. Multi-Domain Case In the multi-domain case, the User has a contract with a single Service Provider. This Service Provider has a contract with neighboring Service Providers. This model is used when independent autonomous networks establish contracts with each other. +-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |Bandwidth| | | |Bandwidth| | +-------+ | |Broker | | | |Broker | | | | | | | | | | | | |Service| | +---------+ | | +---------+ | |User |=========| |========| | | | | +---------+ | | +---------+ | | | | | Network | | | | Network | | +-------+ | | Routing | | | | Routing | | | | Devices | | | | Devices | | | +---------+ | | +---------+ | | Autonomous | | Autonomous | | Service | | Service | | Domain A | | Domain B | +-------------+ +-------------+ ==== contractual relationship Fig. 20 -- Two-Tier Multi-Domain Contractual Relationships A.3.4. Identification of Trust Relationships Contractual relationships may be independent of how trust, which is necessary to facilitate authenticated and possibly secure communication, is implemented. There are several alternatives in the Bandwidth Broker environment to create trusted relationships. Figures 21 and 22 show two alternatives that are options in the two- tier Bandwidth Broker model. Vollbrecht et al. expires December 1999 [Page 40] INTERNET DRAFT June 1999 +-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |Bandwidth| | | |Bandwidth| | +-------+ | |Broker | | | |Broker | | | O***********O O************O | | |Service| | +----O----+ | | +----O----+ | |User |=========| * |========| * | | | | +----0----+ | | +----O----+ | | | | |Network | | | |Network | | +-------+ | |Routing | | | |Routing | | | |Devices | | | |Devices | | | +---------+ | | +---------+ | | Autonomous | | Autonomous | | Service | | Service | | Domain A | | Domain B | +-------------+ +-------------+ ==== contractual relationship O**O trust relationship Fig. 21 -- Two-Tier Multi-Domain Trust Relationships, alt 1 Vollbrecht et al. expires December 1999 [Page 41] INTERNET DRAFT June 1999 +-------------+ +-------------+ | | | | | +---------+ | | +---------+ | | |Bandwidth| | | |Bandwidth| | +-------+ | |Broker | | | |Broker | | | | | | | | | | | | |Service| | +----O----+ | | +----O----+ | |User |=========| * |========| * | | | | +----O----+ | | +----O----+ | | O***********O Network O************O Network | | +-------+ | | Routing | | | | Routing | | | | Devices | | | | Devices | | | +---------+ | | +---------+ | | Autonomous | | Autonomous | | Service | | Service | | Domain A | | Domain B | +-------------+ +-------------+ ==== contractual relationship O**O trust relationship Fig. 22 -- Two-Tier Multi-Domain Trust Relationships, alt 2 Although [13] does not recommend specifics regarding this question (see section 3.2.4 of [13]), the document recognizes the need for trust relationships. In the first model, a trust relationship, based on some form of authentication method, is created between the User and the Bandwidth Broker and among Bandwidth Brokers. In the second model, which enjoys some popularity in enterprise networks, the trust relationship may be established via the wiring closet and the knowledge of which physical router port or MAC address is connected to which user. The router-Bandwidth Broker relationship may be established physically or by some other authentication method or secure channel. A Certificate Authority (CA) based trust relationship is shown in figure 23. In this figure, a CA signs public key certificates, which then can be used in encrypted message exchanges using public keys that are trusted by all involved. As a first step, each involved party must register with the CA so it can join a trust domain. The Router-Bandwidth Broker relationship may be established as described in the two previous figures. An interesting observation regarding this kind of model is that the bandwidth broker in domain B may route information to the user via the bandwidth broker in domain A without BB1 being able to read the information (using end-to-end security). Vollbrecht et al. expires December 1999 [Page 42] INTERNET DRAFT June 1999 This model creates a meshed trust relationship via a tree like CA structure. +-------------------+ | Certificate | ....................| Authority | : ..| |.. : : +-------------------+ : : : : : : : : ***************:*********************** : : * +---:---------+ +---*--:------+ : * | : | | * : | : * | +-:-------+ | | +-O--:----+ | : * | |{C} | | | | {C} | | +---:--O+ | |Bandwidth| | | |Bandwidth| | | {C} O***********O Broker O************O Broker | | |Service| | +----O----+ | | +----O----+ | |User |=========| * |========| * | | | | +----0----+ | | +----O----+ | | | | |Network | | | |Network | | +-------+ | |Routing | | | |Routing | | | |Devices | | | |Devices | | | +---------+ | | +---------+ | | Autonomous | | Autonomous | | Service | | Service | | Domain A | | Domain B | +-------------+ +-------------+ ==== contractual relationship O**O trust relationship {C}. certification process Fig. 23 -- Two-Tier Multi-Domain Trust Relationships, alt 3 A.3.5. Communication Models and Trust Relationships When describing the Bandwidth Broker communication model, it is important to recognize that trust relationships between components must ensure secure and authenticated communication between the involved components. As the Internet 2 Qbone Bandwidth Broker work does not recommend any particular trust relationship model, we make the same assumptions as section 3.2.4 of [13]. In theory, the trust model and communication model can be independent, however Vollbrecht et al. expires December 1999 [Page 43] INTERNET DRAFT June 1999 communication efficiency will determine the most logical approach. A.3.6. Bandwidth Broker Communication Models A.3.6.1. Concepts The current Internet 2 Qbone Bandwidth Broker discussion describes a two-tier model, where a Bandwidth Broker accepts Resource Allocation Requests (RAR's) from users belonging to its domain or RAR's generated by upstream Bandwidth Brokers from adjacent domains. Each Bandwidth Broker will manage one service domain and subsequently provide authorization based on a policy that decides whether a request can be honored. A.3.6.1.1. Intra-Domain Authorization Admission Authorization or Connection Admission Control (CAC) for intra-domain communication is performed using whatever method is appropriate for determining availability of resources within the domain. Generally a Bandwidth Broker configures its service domain to certain levels of service. RAR's are subsequently accommodated using a policy-based decision. A.3.6.1.2. Inter-Domain Authorization Service Level Specifications (SLS's) provide the basis for handling inter-domain bandwidth authorization requests. A Bandwidth Broker monitors both the state of its network components and the state of its connections to neighboring networks. SLS's are translations of SLA's established between Autonomous Service Domains. Each Bandwidth Broker will initialize itself so it is aware of existing SLS's. SLS's are established in a unidirectional sense. Two SLS's must govern a bi-directional connection. SLS's are established on the level of aggregate data-flows and the resources (bandwidth) provisioned for these flows. A Bandwidth Broker may honor an inter-domain RAR by applying policy decisions determining that a particular RAR does fit into a pre- established SLS. If successful, the Bandwidth Broker will authorize the usage of the bandwidth. If unsuccessful, the Bandwidth Broker may deny the request or approve the request after it has re- negotiated the SLS with its downstream Bandwidth Broker. A separate Policy Manager may be involved in the CAC decision. The Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal environment where Bandwidth Brokers and Policy Managers work together to provide CAC using integrated policy services (section 2 of [13]). Vollbrecht et al. expires December 1999 [Page 44] INTERNET DRAFT June 1999 A.3.6.2. Bandwidth Broker Work Phases The Internet 2 Qbone Bandwidth Broker discussion proposes development of the Bandwidth Broker model in several phases: - Phase 0: Local Admission. RAR's are only handled within a local domain. SLS's are pre-established using manual methods (fax, e- mail). - Phase 1: Informed Admission. RAR's spanning multiple domains are authorized based on information obtained from one or more Bandwidth Brokers along the path. - Phase 2: Guaranteed admission. This is the first step towards a model that allows SLS's to be dynamic. It attempts to provide some "guarantee" that packets within a flow will not be dropped due to transient bursts that would otherwise lead to a state of over-subscription. The intent is to do this relying on the statistical nature of the traffic by a combination of intelligent provisioning and by making the available resources to a service somewhat flexible within a single large SLS. - Phase N: Dynamic SLS admission. Bandwidth Brokers can dynamically set up new SLS's. Although the local admission case is addressed, the current Internet 2 Qbone Bandwidth Broker work is currently concerned with solving multi-domain problems in order to allow individual Bandwidth Brokers to inter-operate as identified in phase 0 or 1. A.3.6.3. Inter-Domain Signaling A.3.6.3.1. Phase 0 In phase 0 implementations, no electronic signaling between Bandwidth Brokers is performed and SLS negotiation will be performed manually (phone, email etc) by network operators. An RAR is only handled within the domain and may originate from a User or ingress router. A.3.6.3.2. Phase 1 Here a CAC decision is made on information obtained from downstream Bandwidth Brokers. This information could come from the next hop Bandwidth Broker or all Bandwidth Brokers downstream to the destination. Two fundamental signaling approaches between Bandwidth Brokers have been identified for the Informed Admission case. These are Vollbrecht et al. expires December 1999 [Page 45] INTERNET DRAFT June 1999 illustrated in figure 24. +-------+ +-------+ +-------+ +-------+ | | | | | | | | | |RAR | | 1 | | 2 | | | User |-------->| |-------->| |-------->| | | | RAA | BB1 | 4 | BB2 | 3 | BB3 | | |<--------| |<--------| |<--------| | | | | | | | | | | | | | | | | | +-------+ +-------+ +-------+ +-------+ A)End-to-end signaling +-------+ +-------+ +-------+ +-------+ | | | | | | | | | |RAR | | 1 | | 3 | | | User |-------->| |-------->| |-------->| | | | RAA | BB1 | 2 | BB2 | 4 | BB3 | | |<--------| |<--------| |<--------| | | | 7 | | 6 | | 5 | | | |<--------| |<--------| |<--------| | +-------+ +-------+ +-------+ +-------+ B) Immediate response signaling. Fig. 24 -- Fundamental Signalling Approaches - End to End signaling. An RAR from a User to BB1 is forwarded to BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is the destination of the request, BB3 will authorize the request and reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1 will send a Resource Allocation Answer (RAA) back to the User to complete the authorization. - Immediate response signaling. This is the case where BB1 will want to authorize an RAR from its domain and forwards the authorization request to BB2 (1). If BB2 approves, the response is immediately returned to BB1 (2). BB1 will send an RAA back to the User. If the authorization was positive BB2 will forward subsequently a request to the next BB, BB3 (3). BB3 authorizes the request and responds to BB2 (4). If the response is negative (5), BB2 will cancel the authorization it previously issued to BB1 (6) and this will result in a cancellation from BB1 to the user (7). In this case the RAA authorization is valid until revoked by 7. Vollbrecht et al. expires December 1999 [Page 46] INTERNET DRAFT June 1999 A.3.6.4. Bandwidth Broker Communication Architecture Figure 25 shows components of the discussed Bandwidth Broker architecture with its interfaces. - An intra-domain interface allows communication with all the service components within the network that the Bandwidth Broker controls. - An inter-domain interface allows communication between Bandwidth Brokers of different autonomous networks. - A user/application interface allows the Bandwidth Broker to be managed manually. Requests can be sent from the User or a host application. - A policy manager interface allows implementation of complex policy management or admission control. - A routing table interface allows the Bandwidth Broker to understand the network topology. - An NMS interface allows coordination of network provisioning and monitoring. Vollbrecht et al. expires December 1999 [Page 47] INTERNET DRAFT June 1999 adjacent BB <---------------------------> adjacent BB | V +------------------------------+ | | inter-domain | | | -------------- ------| application | | PM | server \ | |iface | \ |------- ---------+ ------| ->| user/ | | simple | ------| user/host-->| app | | policy | | NMS | ->| iface | | services| |iface | / |------- ---------+ ------| network / | | operator | ------- ------- | | | data | |routing| | | | store | |info | | | | | | | | | ------- ------- | | | | ---------------- | | | intra-domain | | +------------------------------+ ^ | edge router(s) <---------------------------> edge router(s) Fig. 25 -- Bandwidth Broker Architecture A.3.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication Model A.3.6.5.1. Session Initialization Before Bandwidth Brokers can configure services between two adjacent domains, they have to establish and initialize a relationship. No authentication is used; therefore any trust relationship is implicit. Part of the initialization is an exchange of topology information (list of adjacent Bandwidth Brokers). A.3.6.5.2. Service Setup The Bandwidth Broker must first be configured in regard to agreed bi-lateral service levels. All resources allocated to a particular level of provisioned service must be reserved in each domain. Vollbrecht et al. expires December 1999 [Page 48] INTERNET DRAFT June 1999 A Service Setup Request (SSR) is generated (on demand by the operator or at startup of the system) and forwarded to a downstream Bandwidth Broker. The downstream Bandwidth Broker will check the consistency with its own service level specifications and respond with Setup Answer message (SA) agreements. This message exchange confirms and identifies pre-established service authorization levels. A.3.6.5.3. Service Cancellation A Service Cancellation (SC) message may cancel a service authorization. This message may be initiated by the operator or by an expiration date. A Cancellation Answer (CA) is returned. A.3.6.5.4. Service Re-negotiation An (optional) Service-Renegotiation message (SR) may allow a Bandwidth Broker to re-negotiate an existing service. This message may be initiated by the operator or automatically when a certain threshold is reached. Re-negotiations happen within the margins of a pre-established authorization. A.3.6.5.5. Resource Allocation Request and Resource Allocation Answer An RAR allocates a requested level of service on behalf of the User and when available it will decide on the admittance of a certain User to the service. A Bandwidth Broker may receive an RAR via either the intra-domain or inter-domain interface. The RAR must refer to the Service SetUp Identification (SSU_ID), which binds a request to a certain authorization. A Resource Allocation Answer (RAA) confirms or rejects a request or it may indicate an "in progress" state. A.3.6.5.6. Session Maintenance A certain level of session maintenance is required to keep Bandwidth Brokers aware of each other. This must be implemented using time- outs and keep-alive messages. This will help Bandwidth Brokers to notice when other Bandwidth Brokers disappear. A.3.6.5.7. Intra-domain Interface Protocol The Intra-domain interface protocol used between a Bandwidth Broker and the routers it controls may be COPS, SNMP, or Telnet Command Line Interface. A.3.7. Requirements From the above descriptions we derive the following requirements. Vollbrecht et al. expires December 1999 [Page 49] INTERNET DRAFT June 1999 - The Authorization mechanism may require trust relationships to be established before any requests can be made from the User to the Service Provider. Currently trust relationship establishment is implicit. - A confirmation of authorization is required in order to initialize the system. - A negation of static authorization is required to shut down certain services. - A re-negotiation of static authorization is required to alter services (SLS's). - Dynamic authorization requests (RAR) must fit into pre-established static authorizations (SLS's). - Dynamic authorization requests (RAR) may be answered by an "in progress state" answer. - Provisions must be made to allow reconstruction of authorization states after a Bandwidth Broker re-initializes. A.4. Internet Printing The Internet Printing Protocol, IPP [14], has some potentially complex authorization requirements, in particular with the "print- by-reference" model. The following attempts to describe some possible ways in which an authorization solution for this aspect of IPP might work, and to relate these to the architecture model described in earlier sections. This is not a product of the IPP working group, and is meant only to illustrate some issues in authorization in order to establish requirements for a "generic" protocol to support AAA functions across many applications. IPP print-by-reference allows a user to request a print service to print a particular file. The user creates a request to print a particular file on a printer (or one of a group of printers). The key aspect is that the request includes only the file name and not the file content. The print service must then read the file from a file server prior to printing. Both the file server and the print server must authorize the request. Once initiated, printing will be done without intervention of the user; i.e., the file will be sent directly to the print service rather than through the user to the printer. Vollbrecht et al. expires December 1999 [Page 50] INTERNET DRAFT June 1999 A.4.1. Trust Relationships The assumption is that the Printer and File Server may be owned and operated by different organizations. There appear to be two models for how "agreements" can be set up. 1. User has agreement with Print Server; Print Server has agreement with File Server. 2. User has agreements with both File and Print Server directly. In case 1, the user has a trust relationship with the Print Service AAA Server. The Printer forwards the request to the File Server. The File Server authorizes the Printer and determines if the Printer is allowed access to the file. Note that while there may be some cases where a Print Server may on its own be allowed access to files (perhaps some "public files", or that can only be printed on certain "secure" printers), it is normally the case that files are associated with users and not with printers. This is not a good "generic" model as it tends to make the print service an attractive point of attack. +------+ +----------------------+ | | | File Service |----+ | | | AAA Server |<-+ | | | +----------------------+ | | | | | | | | | | | File Server | | | | | | | | | | User | +----------------------+ | | | | | | | | | | | | | | | | +----------------------+ | | | |------>| Print Service |--+ | | |<------| AAA Server |<---+ | | +----------------------+ | | | Print Server | | | | and Printer | +------+ +----------------------+ Fig. 26 -- Case 1 User authorizes with Print Service. Printer authorizes with File Service. In case 2, the user must have a trust relationship with both the file and print services so that each can verify the service appropriate to Vollbrecht et al. expires December 1999 [Page 51] INTERNET DRAFT June 1999 the User. In this case, the User first contacts the File Service AAA Server and requests that it enable authorization for the Print Service to access the file. This might be done in various ways, for example the File Service AAA Server may return a token to the User which can (via the Print Service) be presented to the File Server to enable access. +------+ +----------------------+ | |------>| File Service | | |<------| AAA Server | | | +----------------------+ | | | | +----------------------+ | | | File Server | | User | +----------------------+ | | /|\ | | | | | | | | \|/ | | +----------------------+ | |------>| Print Service | | |<------| AAA Server | | | +----------------------+ | | | Print Server | | | | and Printer | +------+ +----------------------+ Fig. 27 -- Case 2 User authorizes File and Print Service. Must create binding for session between Print Service and File Service. A.4.2. Use of Attribute Certificates in print-by-reference The print-by-reference case provides a good example of the use of attribute certificates (see section 2.6, above). If we describe case 2 above in terms of attribute certificates (ACs) we get the diagram shown in figure 28. Vollbrecht et al. expires December 1999 [Page 52] INTERNET DRAFT June 1999 +------+ +----------------------+ | |------>| File Service | | |<------| AAA Server | | |Get AC +----------------------+ | | | | +----------------------+ | | | File Server |----+ | | | |<-+ | | User | +----------------------+ | | | | | | | | +---authorize passing AC | |<---Create session | | | | | Using AC | | V +----------------------+ | | | |------>| Print Service | | | | |<------| AAA Server | | | | | +----------------------+ | | | | | Print Server |--+ | | | | and Printer |<---+ +------+ +----------------------+ Fig. 28 -- Using Attribute Certificates in IPP Authorization In this case, the User gets an AC from the File Service's AAA Server which is signed by the File Service AAA Server and contains a set of attributes describing what the holder of the AC is allowed to do. The User then authorizes with the Print Service AAA Server and passes the AC in the authorization request. The Printer establishes a session with the File Server, passing it the AC. The File Server trusts the AC because it is signed by the File Service AAA Server and allows (or disallows) the session. It is interesting to note that an AC could also be created and signed by the User, and passed from the Print Server to the File Server. The File Server would need to be able to recognize the User's signature. Yet another possibility is that the Print Service AAA Server could simply authenticate the User and then request an AC from the File Service AAA Server. A.4.3. IPP and the Authorization Descriptive Model The descriptive model presented in section 2, above, includes four basic elements: User, User Home Organization, Service Provider AAA Server, and Service Equipment. Mapping these to IPP, the User is the same, the User Home Vollbrecht et al. expires December 1999 [Page 53] INTERNET DRAFT June 1999 Organization (if included) is the same. The Service Provider AAA Server and the Service Equipment are expected to be closely coupled on the same processor. In other words, the interface between the Print Service AAA Server and the Printer as well as that between the File Service AAA Server and the File Server is an internal one that will not require a formal protocol (although some standard API might be useful). The concept of a Resource Manager (see section 2.7.2) has some interesting twists relative to IPP. Once started, the user is not involved in the service, but until printing is complete it seems useful that any of the parties in the authorization process be allowed to query for status or to cancel the print session. The user needs a way to "bind" to a particular session, and may have to reauthorize to be allowed to access Resource Manager information. A.5. Electronic Commerce This section describes the authorization aspects of an e-commerce architecture typically used in Europe. We will use this model to identify contractual and trust relationships and message exchanges. We will then identify a set of authorization requirements for e- commerce. Whereas most e-commerce protocols focus on authentication and message integrity, e-commerce exchanges as described by the Internet Open Trading Protocol (trade) Working Group in [15] also involve authorization. This section will examine one e-commerce protocol called SET (Secure Electronic Transaction) that provides for credit and debit card payments. We will analyze the authorization aspects from an architectural viewpoint. We will apply concepts and terms defined in section 2, above. We are not here proposing SET as a standard authorization protocol. Rather, we are examining the SET model as a way of understanding the e-commerce problem domain so that we can derive requirements that an authorization protocol would have to meet in order to be used in that domain. E-commerce protocols and mechanisms such as those described in [16] may not only be important to allow customers to shop safely in Cyberspace, but may also be important for purchases of Internet services as well. With emerging technologies allowing Internet transport services to be differentiated, an inherently more complex pricing model will be required as well as additional payment methods. Flexible authorization of services will be an important aspect to allow, for example, globally roaming users ad hoc allocation of premium bandwidth with an ISP who is authorized to accept certain Vollbrecht et al. expires December 1999 [Page 54] INTERNET DRAFT June 1999 credit card brands. A.5.1. Model Description The establishment of a model involves four steps: 1. identification of the components that are involved and what they are called in this specific environment, 2. identification of the relationships between the involved parties that are based on some form of agreement, 3. identification of the relationships that are based on trust, and 4. consideration of the sequence of messages exchanged between components. A.5.1.1. Identification of Components We will consider the components of an electronic commerce transaction in the context of the conceptual entities defined in section 2, above. - The Cardholder (User) -- the person or organization that is to receive and pay for the goods or services after a request to purchase has been received. In SET terms this is called a Cardholder. - The Issuer (User Home Organization) -- the financial organization that guarantees to pay for authorized transactions to purchase goods or services on behalf of the User when using a debit or credit card it issues. The financial organization (typically a bank or Brand Organization) will transfer money from the user account to the account the party to which the User instructs it to send the payment. The issued card authorizes the User to use the card for payments to merchants who are authorized to accept the card. In SET terms this organization is called the Issuer. This organization is considered "home" to the Cardholder. - The Merchant (Service Provider) -- the organization from whom the purchase is being made and who is legally responsible for providing the goods or services and receives the benefit of the payment made. In SET terms this organization is called a Merchant. The Cardholder is considered to be "foreign" to the Merchant. - The Acquirer (Broker) -- the organization that processes credit or debit card transactions. Although in reality this function may be rather complex and may span several organizations, we will simply assume this organization to be a Brand Organization fulfilling the Vollbrecht et al. expires December 1999 [Page 55] INTERNET DRAFT June 1999 role of the Acquirer as defined in SET. The Acquirer establishes an account with the Merchant. The Acquirer operates a Payment Gateway that will accept payment authorization requests from authorized merchants and provide responses from the issuer. The Acquirer will forward an authorization request to the Issuer. The Acquirer is considered "home" to the Merchant. As the SET document [16] notes, a Brand Organization (credit card organization) may handle both the Issuer function and Acquirer function that operates a Payment Gateway. For simplicity, we therefore assume that the authorization role of Broker (Acquirer) and User Home Organization (Issuer) both belong to the Brand Organization. In order to be more descriptive we now use the SET terms. In the requirements section these terms are mapped back into the authorization architecture terms again. A.5.1.2. Identification of Contractual Relationships Contractual relationships are illustrated in figure 29, below. - The Cardholder has a contractual relationship with the card Issuer. The Cardholder holds an account with the Issuer and obtains an account number. - The Merchant has a contractual relationship with the Acquirer. The Merchant obtains a Merchant ID from the Acquirer. - In the real world there may be no direct contractual relationship between the Issuer and the Acquirer. The contractual relationships allowing an Acquirer to relay a payment authorization request to an Issuer may be very complex and distributed over multiple organizations. For simplicity, however, we assume there are contracts in place allowing an Acquirer to request payment authorization from an Issuer. These contracts are facilitated by the Brand Organization. Therefore, in our simplified example, the Acquirer and Issuer belong to the same Brand Organization. The Acquirer operates a Payment Gateway for which it needs a Bank Identification Number (BIN). Vollbrecht et al. expires December 1999 [Page 56] INTERNET DRAFT June 1999 +----------------+ +------------------------+ | Issuer | | Acquirer | | (User Home | | (Broker) | | Organization) | | +------------------+ | | |=======| | Payment | | | | | | Gateway | | | | | +------------------+ | | | | | +----------------+ +------------------------+ || || || || || || +----------------+ +--------------------+ | Cardholder | | Merchant | | (User) | | (Service Provider) |---+ | | | | | | | | | | | | +--------------------+ | | | | | | | | Fulfillment | | | | | +----------------+ +----------------------+ Fig. 29 -- SET Contractual Relationships A.5.1.3. Identification of Trust Relationships It is important to recognize that there are two kinds of trust relationships: static and dynamic trust relationships. Static trust relationships in SET are established by means of a registration process that will request a certificate to be issued to the party that needs to be trusted and authorized to be part of a SET transaction. Dynamic trust is created at the time of a payment transaction and its subsequent authorization request. Note that at the issue phase of a certificate, based on identification and registration, the user of the certificate gets an implicit static authorization and a means of authenticating and securing messages. For this purpose a Certificate Authority (CA) will issue certificates that are used to sign and/or encrypt messages exchanged according to the SET protocol. A.5.1.3.1. Static Trust Relationships In the discussion that follows, refer to figure 30, below. Vollbrecht et al. expires December 1999 [Page 57] INTERNET DRAFT June 1999 +-------+ | Root | | CA | +-------+ CA = Certificate Authority | {C} = Certificate | +-----------------+ | Brand | | CA | +-----------------+ | | | | | +-------+ | | |Payment| +----------------+ | | |Gateway| +----------------------+ | Issuer | | | | CA | | Acquirer | | (User Home | +----------+ | +-------+ | (Broker) | | Organization) | |Cardholder| | | | +----------------+ | | | | CA | | +------+--+-{C} Payment | | | | +----------+ | 3 | | Gateway | | | | | | | +----------------+ | | | | +---------+ | | +----------------+ | | Merchant| +----------------------+ | | CA | | +---------+ | | +----------------+ | | +--------------------+ | Cardholder | | | | Merchant | | (User) | | | | (Service Provider) |--+ | {C}-+-----+ | | | | | | 1 +-----------+-{C} | | | | 2 | | | | | | | | | | +--------------------+ | | | | | | | | Fulfillment | | | | | +----------------+ +---------------------+ Fig. 30 -- SET Trust Relationships within a Brand Domain - The Brand Organization operates a Brand CA and is therefore the holder of the common trust within the described domain. All involved parties (Cardholder, Issuer, Merchant and Acquirer) are members of the same trust domain. We will identify three separate CA's which issue a certificate on behalf of the Issuer, the Vollbrecht et al. expires December 1999 [Page 58] INTERNET DRAFT June 1999 Acquirer and the Brand Organization. The Brand CA, according to a tree like hierarchy, certifies all underlying CA's. The Brand CA obtains its trust from a single Root Certificate Authority. Before any party can obtain a Certificate from a CA, the party must have some form of contractual relationship. - After an account has been established with the Issuer, the Cardholder has to register with a Cardholder CA (CCA) through a series of registration steps (1) as defined in the SET protocol. If the CCA approves the registration, the Cardholder will obtain a Cardholder Certificate. The CCA may be operated by the Brand Organization on behalf of the Issuer. The Cardholder Certificate is an electronic representation of the payment card. This process creates a trust relationship between the Cardholder and the Brand. After the cardholder has received the Cardholder Certificate, the Cardholder is authorized to perform payments to an authorized Merchant. - After the Merchant has obtained a Merchant ID from the Acquirer, the Merchant has to register with the Merchant CA (MCA) through a series of registration steps (2) as defined in the SET protocol. If the MCA approves the registration, the Merchant will obtain a Merchant Certificate. This process creates a trust relationship between the Merchant and the Brand. The MCA may be operated by the Brand Organization on behalf of the Acquirer. After registration, the Merchant is authorized to accept payment requests from Cardholders and to send authorization requests to the Acquirer's Payment Gateway. - After the Acquirer has obtained a valid Bank Identification Number (BIN), the Acquirer must register with the Payment Gateway CA (PCA) in order to obtain a Payment Gateway Certificate (3). The Payment Gateway Certificate authorizes the Gateway to accept payment authorization requests originating from Merchants within its trust domain. - The Acquirer and Issuer have a trust relationship via the Brand Organization. The trust relationship is not ensured by procedures or a mechanism defined by SET, as this is a problem solved by agreements between financial organizations facilitating the payment service. Again, for simplicity, we assume that the relationship ensures that payment authorization requests received by the Acquirer's gateway will be forwarded in a secure and efficient way to the Issuer and its response is handled in the same way. Vollbrecht et al. expires December 1999 [Page 59] INTERNET DRAFT June 1999 A.5.1.3.2. Dynamic Trust Relationships Note that there is no prior established static trust relationship between the Cardholder and the Merchant, as a Cardholder does not have to register with a Merchant or vice versa. The trust relationship is dynamically created during the communication process and is based on the common relationship with the Brand. By means of digital signatures using public key cryptography, the Cardholder's software is able to verify that the Merchant is authorized to accept the Brand Organization's credit card. The merchant is able to verify that the Cardholder has been authorized to use the Brand Organization's credit card. A.5.1.4. Communication Model The purchase request from Cardholder to Merchant and subsequent payment authorization exchange between Merchant and Acquirer is illustrated in figure 31 and described below. Vollbrecht et al. expires December 1999 [Page 60] INTERNET DRAFT June 1999 +----------------+ +------------------------+ | Issuer | | Acquirer | | (User Home | | (Broker) | | Organization) | | +------------------+ | | |<------+--| Payment | | | | 5 | | Gateway | | | |-------+->| | | | | 6 | +------------------+ | | | | /|\ | | +----------------+ +---------+---+----------+ | | |4 |7 | \|/ +----------------+ +--------------------+ | Cardholder | | Merchant | | (User) | | (Service Provider) |---+ | |------>| | | | | 1 | | | | |<------| | | | | 2 | | | | |------>| | | | | 3 | | | | |<------| | | | | 8 | | | | | | | | | | | +-----------------+--+ | | | | |9 | | |<--------| Fulfillment \|/ | | | 10 | | +----------------+ +----------------------+ Fig. 31 -- Communication Sequence 1. The Cardholder shops and decides to purchase some goods at merchant.com. The Cardholder has selected a list of goods and the Merchant's software has subsequently prepared an order form for the Cardholder indicating the price, the terms and conditions, and the accepted payment methods. The SET transaction starts at the moment the Cardholder indicates that he or she wants to pay for the goods using a certain payment brand. The Cardholder software sends a request to the Merchant that initiates the payment process. 2. The Merchant checks the order and signs it and returns it to the Cardholder including a certificate from the Acquirer's Gateway Vollbrecht et al. expires December 1999 [Page 61] INTERNET DRAFT June 1999 that allows the Cardholder to encrypt payment instructions that are only relevant to the Gateway and not to the Merchant (e.g., the Cardholder's credit card information). The Cardholder also includes his or her own certificate. 3. The Cardholder now verifies both certificates (the software has the CA's root certificate). The Cardholder software generates a message containing the order information and the payment instructions that is signed by the Cardholder. Using the Gateway Certificate, it will encrypt the Payment Instruction so that it will only be readable by the Gateway. The Cardholder will include his or her certificate. 4. The Merchant verifies the Cardholder certificate and checks the message integrity. He or she will now process the payment and issue a payment authorization request to the gateway. The payment authorization request contains the Cardholder's certificate and both Merchant certificates. 5. The Gateway verifies the Merchant's signature certificate and that the Merchant signed the authorization request. Next it will obtain the account information and payment instructions and will check the message integrity and the Cardholder's certificate. If everything is in proper order it will send an authorization request to the Issuer via a secure bank network. 6. The issuer returns the authorization. 7. The Acquirer's Gateway generates an authorization response which includes the gateway's certificate. 8. The Merchant checks the authorization response and completes the process by forwarding a purchase response to the Cardholder. 9. The Merchant software authorizes the delivery of the purchased goods. 10. The Cardholder receives the purchased goods. A.5.2. Multi Domain Model In the previous "single" domain case we already assume that there are multiple Cardholders, Merchants, Issuers and Acquirers. However all these parties belong to a single trust domain as there is only a single CCA, MCA and PCA. The trust relationship between multiple cardholders and multiple Issuers go via a single CCA in the same way as the trust relationship between an Acquirer and a Merchant uses the same MCA. The multi-domain case arises when there are multiple Vollbrecht et al. expires December 1999 [Page 62] INTERNET DRAFT June 1999 domains of CCA's, MCA's and PCA's. In SET these domains reside under a particular Geopolitical CA (GCA) which is illustrated in figure 32. +-----------+ | Root CA | | | +-----------+ | | +----------------------|-------------------------------+ +-----------------------------------------------------+ | | Brand CA | | | |-+ +-----------------------------------------------------+ | | +----------------------|-------------------------------+ +-----------------------------------------------------+ | | Geopolitical CA | | | |-+ +-----------------------------------------------------+ | | | | | | +----|--------+ +---|-------+ +-------|----------+ +------------+ | +----------+ | +-----------------+ | | Cardholder | | | Merchant | | | Payment Gateway | | | CA |-+ | CA |-+ | CA |-+ +------------+ +----------+ +-----------------+ Fig. 32 -- SET Certificate Management Architecture A GCA may represent a country or region. The architecture defines a trust hierarchy needed to manage and verify SET Certificates as these need to be issued, renewed or revoked. Each geopolitical region may have different policies for issuing, renewing or revoking certificates. However once certificates have been issued, Cardholders and Merchants belonging to different GCA's can still be recognized as belonging to the same Brand. This will allow a European Cardholder to purchase goods in the U.S. The U.S. Acquirer's gateway will recognize that the Cardholder belongs to the same Brand and will therefore accept a payment authorization request. A.5.3. Requirements Many e-commerce environments do not use SET. Other mechanisms exist based on SSL, XML, and S/MIME. Also a mechanism that uses SET only Vollbrecht et al. expires December 1999 [Page 63] INTERNET DRAFT June 1999 for the payment authorization to the Gateway exists and is known as half SET. However, using the model described in this document, we can derive a fairly comprehensive set of protocol requirements for e-commerce. In these requirements, the SET terms are replaced again by the descriptive model terms: Cardholder = User Merchant = Service Provider Issuer = User Organization Acquirer = Broker 1. The Authorization mechanism must allow trust relationships to be established before any requests can be made from the User to the Service Provider and from the Service Provider via a Broker to the User Organization. This process will enable the parties to communicate securely by creating an authenticated channel and, by so doing, implicitly authorizing its usage. 2. Upon receipt of any request or response, entities need to be able to verify whether the transmitting party is still authorized to send this request or response. 3. The User must be able to authorize the Service Provider to request an authorization from the User Home Organization. 4. The User must be able to authorize fulfillment of a proposed service offer from the Service Provider. Other requirements related to the authorization process: Integrity 5. For any authorization request or response, the receiving party needs to verify that the content of the message has not been altered. Confidentiality/Privacy 6. The User must be able to pass information relevant to the session authorization process to the User Home Organization via a Broker and the Service Provider without allowing the Broker or the Service Provider to examine its content. 7. The User Home Organization must be able to communicate information relevant to the session authorization via the Broker and the Service Provider to the User without allowing the Broker or the Service Provider to examine its content. Vollbrecht et al. expires December 1999 [Page 64] INTERNET DRAFT June 1999 Nonrepudiation 8. There is a need for a recorded, authenticated and authorized agreement about the request for and delivery of service. Vollbrecht et al. expires December 1999 [Page 65] INTERNET DRAFT June 1999 Glossary Attribute Certificate -- structure containing authorization attributes which is digitally signed using public key cryptography. Contract Relationship -- Distributed Service -- a service that is provided by more than one Service Provider acting in concert. Dynamic Trust Relationship -- Policy Decision Point (PDP) -- The point where policy decisions are made. Policy Enforcement Point (PEP) -- The point where the policy decisions are actually enforced. Resource Manager -- the component of an AAA Server which tracks the state of sessions associated with the AAA Server or its associated Service Equipment and provides an anchor point from which a session can be controlled, monitored, and coordinated. Roaming -- An authorization transaction in which the Service Provider and the User Home Organization are two different organizations. (Note that the dialin application is one for which roaming has been actively considered, but this definition encompasses other applications as well.) Security Association -- Service Equipment -- the equipment which provides a service. Service Provider -- an organization which provides a service. Static Trust Relationship -- User -- the entity seeking authorization to use a resource or a service. User Home Organization (UHO) -- An organization with whom the User has a contractual relationship which can authenticate the User and may be able to authorize access to resources or services. Vollbrecht et al. expires December 1999 [Page 66] INTERNET DRAFT June 1999 References [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] Bradner, Scott, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Framework Core Information Model", draft-ietf-policy-core-schema-03.txt, May 1999. [4] Strassner, John, Stephen Schleimer, "Policy Framework Definition Language", draft-ietf-policy-framework-pfdl-00.txt, November 1998. [5] Farrell, Stephen and Russell Housley, "An Internet AttributeCertificate Profile for Authorization", draft-ietf- pkix-ac509prof-00.txt, April 1999. [6] Housley, Russell et al, "Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile", RFC 2459, January 1999. [7] Aboba, Bernard and John R. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [8] Rigney, Carl, Allan C. Rubens, William Allen Simpson, and Steve Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [9] Aboba, Bernard and Mark Beadles, "The Network Access Identifier", RFC 2486, January 1999. [10] Calhoun, Pat R. and Glen Zorn, "Roamops Authentication/Authorization Requirements" draft-ietf-aaa- roamops-auth-req-00.txt, March 1999. [11] Perkins, Charles, Editor: "IP Mobility Support", RFC 2002, October 1996. [12] Hiller et al., "3G Wireless Data Provider Architecture Using Mobile IP and AAA", draft-hiller-3gwireless-00.txt, March 1999. [13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares, "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment", ver. 0.5, March 1999, http://www.merit.edu/working.groups/i2-qbone- Vollbrecht et al. expires December 1999 [Page 67] INTERNET DRAFT June 1999 bb/doc/BB_Requirements5.pdf. [14] deBry, Roger, "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999. [15] Burdett, David, "Internet Open Trading Protocol - IOTP", draft- ietf-trade-iotp-v1.0-protocol-03.txt, February 1999. [16] "SET Secure Electronic Transaction Specification Book 1: Business Description", Version 1.0, May 31, 1997, http://www.setco.org/download/set_bk1.pdf. [17] Yavatkar, Raj, Dimitrios Pendarakis, and Roch Guerin, "A Framework for Policy-based Admission Control", draft-ietf-rap- framework-03.txt, April 1999. Authors' Addresses John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105 USA Phone: (734) 763-1206 EMail: jrv@merit.edu Pat R. Calhoun Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: (650) 786-7733 Fax: (650) 786-6445 EMail: pcalhoun@eng.sun.com Vollbrecht et al. expires December 1999 [Page 68] INTERNET DRAFT June 1999 Stephen Farrell SSE Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND Phone: +353-1-216-2900 EMail: stephen.farrell@sse.ie Leon Gommans Cabletron Systems EMEA Kerkplein 24 2841 XM Moordrecht The Netherlands Phone: + 31 182 379278 Email: gommans@cabletron.com George M. Gross Lucent Technologies 184 Liberty Corner Road, m.s. LC3N-E04 Warren, NJ 07059 USA Phone: (908) 580-4589 Fax: (908) 580-4721 Email: gmgross@lucent.com Betty de Bruijn Interpay Nederland B.V. Eendrachtlaan 315 3526 LB Utrecht The Netherlands Phone: +31 30 2835104 Email: betty@euronet.nl Vollbrecht et al. expires December 1999 [Page 69] INTERNET DRAFT June 1999 Matt Holdrege Ascend Communications 1750 Harbor Bay Pkwy. Alameda, CA 94502 USA Phone: (510) 747-2711 Email: matt@ascend.com David W. Spence Merit Network, Inc. 4251 Plymouth Rd., Suite C Ann Arbor, MI 48105 USA Phone: (734) 615-2630 EMail: dwspence@merit.edu Vollbrecht et al. expires December 1999 [Page 70]