INTERNET DRAFT Pat R. Calhoun Category: Standards Track Sun Microsystems, Inc. Title: draft-calhoun-diameter-framework-01.txt Glen Zorn Date: August 1998 Microsoft Corporation Ping Pan IBM T. J. Watson Research Center DIAMETER Framework Document <draft-calhoun-diameter-framework-01.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``work- ing draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract As the number of new internet services has increased in the past cou- ple of years, routers and network access servers (NAS) have had to undergo re-engineering to support them. These new services could often benefit from an Authentication, Authorization and Accounting (AAA) protocol to facilitate off-loading policy information to an external server. The DIAMETER protocol defines a policy protocol used by clients to perform Policy, AAA and Resource Control. This allows a single server to handle policies for many services. Calhoun et al. expires February 1999 [Page 1]
INTERNET DRAFT August 1998 Table of Contents 1.0 Introduction 1.1 Terminology 2.0 DIAMETER Architecture 2.1 DIAMETER Base Protocol 2.1.1 Proxy Support 2.1.2 DIAMETER Security 2.2 Resource Management Extension 2.3 Accounting Extension 2.4 DIAMETER Command Naming Conventions 2.4.1 Request/Response 2.4.2 Query/Response 2.4.3 Indication 3.0 Why not LDAP? 4.0 References 5.0 Acknowledgements 6.0 Author's Address Appendix A. "Drinks" Policy Extension 1.0 Introduction As the number of new internet services has increased in the past cou- ple of years, routers and network access servers (NAS) have had to undergo re-engineering to support them. These new services could often benefit from an Authentication, Authorization and Accounting (AAA) protocol to facilitate off-loading policy information to an external server. An example of such a service is dial-up PPP Internet access. Large ISPs cannot bear the administrative burden to configure all of their users on each NAS everytime a new device is deployed. In this case RADIUS [1] has been used successfully by many such ISPs. New services such as Voice over IP, Fax over IP [6], Mobile IP [7] and RAP [5] also require similar services in order to be able to authenticate, retrieve authorization information, and generate accounting records for billing purposes. The current trend is for each working groups to define its own policy protocol for a specific service, each with their own nuances. This requires requires customers to deploy several policy servers, which increases the cost of administration and complicates deployment. DIAMETER offers a common solution by defining a base protocol that Calhoun et al. expires February 1999 [Page 2]
INTERNET DRAFT August 1998 defines the header formats, security extensions and requirements as well as a small number of mandatory commands and AVPs. A new service can extend DIAMETER by extending the base protocol to support new functionality. 1.1 Terminology AAA Authentication, Authorization and Accounting. AVP The DIAMETER protocol consists of a header followed by objects. Each object is encapsulated in a header known as an Attribute- Value-Pair. Commands The DIAMETER Protocol is a request/response protocol. Each DIAME- TER message includes a Command AVP that is used to identify the type of request or response. Integrity Check Vector (ICV) An Integrity Check Vector is an unforgeable or secure hash of the packet with a shared secret. Calhoun et al. expires February 1999 [Page 3]
INTERNET DRAFT August 1998 2.0 DIAMETER Architecture The Base DIAMETER Architecture consists of three modules, which defines a small set of primitives that MUST be implemented by all DIAMETER entities. Many applications require that the policy server maintain session state information. The Resource Management extension provides this capability between client and a server as well as between two servers. Most services using DIAMETER require accounting. The current IETF's standard protocol for accounting is SNMP, but experience indicates that SNMP often is not the correct protocol for service accounting. Many applications and services use RADIUS Accounting [4] as their accounting protocol, however RADIUS accounting is not a standard pro- tocol and is informational only. A standard accounting protocol is required. The following diagram provides a representation of the DIAMETER Architecture. As an example, a fictional Policy Extension has been added to the architecture. This fictional service is described here in order to to illustrate how a service could make use of DIAMETER. +------------+ | Policy | | | | Extension | +------------+ +------------+ / \ +------------+ | Resource | | | Accounting | | | | | | | Management | | | Extension | +------------+ | +------------+ / \ | / \ | | | \ / \ / \ / +--------------------------------------------------+ | | | DIAMETER Base Protocol | | | +--------------------------------------------------+ Figure 1: DIAMETER Protocol Architecture Design direction for more extensions will be taken from the user (ISP and network operations) community. Calhoun et al. expires February 1999 [Page 4]
INTERNET DRAFT August 1998 2.1 DIAMETER Base Protocol The Base Protocol defines a set of primitives and the security model used between DIAMETER peers. The following goals motivate the defini- tion of the base protocol: - lightweight and simple to implement. - Support unsolicited messages. - Feature discovery. - Version negotiation. - unsupported extension notification. - Efficient encoding of Attributes. - Large AVP address space. - Support for vendor specific AVPs and Commands. - The protocol MUST support both TCP and UDP. - Reliable over non-reliable protocols. - Inter-Server communication. - Authentication and privacy for policy messages. - End-to-End Security. The DIAMETER base protocol is intended to provide a transport for all extensions. It is therefore imperative that the protocol be light- weight and simple to implement. One design goal behind DIAMETER is to allow a "server" to send unsol- icited messages to a "client". DIAMETER's predecessor, RADIUS, was a client/server protocol that required the client to initiate a request. This limitation restricted RADIUS to a small set of applica- tions and will be handled in DIAMETER. Feature Discovery is intended to dramatically reduce the administra- tive overhead associated with Policy Server configuration. A DIAMETER client can use the a DIAMETER service-type request over SLP [2] to locate Policy Servers within the network, and then a set of DIAMETER messages to retrieve the supported extensions. Calhoun et al. expires February 1999 [Page 5]
INTERNET DRAFT August 1998 DIAMETER version negotiation will also reduce the administrative overhead in policy server configuration. DIAMETER entities SHOULD agree to use the higher DIAMETER protocol version number that they commonly support. In order to ensure future extensibility does not break current imple- mentations, the protocol must provide a mechanism that allows an indication to be sent to a peer when a DIAMETER message with an unrecognized command is received. Information is carried in a DIAMETER message through the use of AVPs. These AVPs consists of three parts; The AVP Identifier, the length and the data. The AVP Identifier which assigns a unique value to each object. The AVP Identifier address space must be sufficiently large to ensure that future extensibility is not limited to the size of the address space. Vendors wishing to add "proprietary" extensions to the protocol must be allowed to do so by using a vendor specific address space. The AVP data (or object) length must be large enough to carry infor- mation without requiring that the object be fragmented across many AVPs. In order to ensure that AVP encoding/decoding is processor efficient, the protocol will require 32-bit alignment which is con- sistent with most new IETF protocols. UDP is preferable for policy applications that require "fine tuned" retransmission strategies. For applications that require support for larger messages and are not as concerned with the retransmission pol- icy, TCP can be used. Each individual extension may specify the underlying transport requirements. For implementations using DIAMETER over UDP, the DIAMETER protocol MUST provide a reliable transport and a well defined retransmission scheme. This include support of windowing as well as a mechanism to detect that communication with the peer is still possible. 2.1.1 Proxy Support One key differentiator with DIAMETER is its inherent support for Inter-Server communication. Although this can be achieved in a variety of ways, the most useful feature is the ability to "proxy" messages across a set of DIAMETER servers (known as a proxy chain). One key application for DIAMETER is ROAMOPS [3], which defines a method for Service Providers to provide inter-domain Dial-Up Internet access. An example would be a user has an internet account with some local provider in the San Francisco bay area and the user travels to Calhoun et al. expires February 1999 [Page 6]
INTERNET DRAFT August 1998 Rome. This user would like to be able to access the internet, but the cost of International long distance prohibits the user from doing so. If the user's ISP provides roaming capabilities, the user can dial any one of many ISPs that have a roaming agreement with his home ISP. If there are such ISPs in Rome, the user will be able to access the Internet through a local call and keep the costs down significantly. Although all DIAMETER servers in the proxy chain may belong to the same administrative domain, the protocol must be designed to allow these servers to reside within different domains. Rome ISP Bay-Area ISP +--------+ +--------+ | proxy | | policy | | policy |<--------------->| | | server | server-server | server | +--------+ communication +--------+ / /|\ / | client-server / | communication |/_ \|/ +--------+ +--------+ | Dial-Up| | Dial-Up| | router | | router | +--------+ +--------+ Figure 2: Client communication through a proxy server 2.1.2 DIAMETER Security There are two different requirements for security. One is the case where two DIAMETER peers communicate directly, also known as hop-by- hop and one where two DIAMETER entities need to communicate through a proxy chain. In the case of hop-by-hop security, two different methods are defined in DIAMETER. One, and the most obvious method, is to provide no DIAM- ETER security and rely on IP Security. The second method, which is backward compatible with RADIUS and requires no changes to the infrastructure, is to make use of shared secrets between two DIAMETER entities. In this case the protocol could include an HMAC-MD5-96 [8] Integrity Check Vector (ICV) within an AVP to provide integrity of the message. Figure 3 depicts an example of Hop-by-Hop security where Policy Server 1 (PS1) and Proxy Server 2 (PS2) share a secret as well as PS2 Calhoun et al. expires February 1999 [Page 7]
INTERNET DRAFT August 1998 and Policy Server 3 (PS3). In this example PS1 sends a message to PS3 through PS2 with an ICV that is computed using the secret it shares with PS2. Upon receipt of the message, PS2 validates the ICV, removes it and adds an ICV that is computed using the secret it shares with PS3. This is commonly called Hop-by-Hop security since it does not provide message integrity between PS1 and PS3. In the case of End-to-End security, a DIAMETER entity communicates with another through a proxy chain. In this case end-to-end integrity, confidentiality and non-repudiation is required on a set of AVPs within a message. This is necessary since some AVPs (known as unprotected AVPs) may be modified in transit by the intermediate proxy servers. In this case the initiator must sign the messages using public key cryptography since it is the only way for the end server to ensure that a proxy has not modified any protected AVPs in the message. +----------+ +----------+ | policy |<--------------->| proxy | | server 1 | server-server | server 2 | +----------+ communication +----------+ /|\ | server-server | communication \|/ +----------+ | policy | | server 3 | +----------+ Figure 3: Proxy Server Communication If certificates are not statically configured or retrieved through some other means (i.e. Certificate Authority), it requires that both the client and the server exchange certificates as part of the DIAME- TER bootstrap protocol. It is a requirement that any DIAMETER Security extension also address 2.2 Resource Management Extension The Resource Management extension allows two DIAMETER entities to share session information. When the server grants authorization of some resources to a DIAMETER node on behalf of some user, the server maintains state information about the session which is identified through the use of a session identifier (aka Session-Id). The Session-Id is generated by the DIAMETER node requesting Calhoun et al. expires February 1999 [Page 8]
INTERNET DRAFT August 1998 authorization and is used in subsequent Resource Management messages to keep the server up to date on the current state of the session. However the Resource Management extension also provides messages for distributed back-end servers to share session state information. The Resource Management extension does not provide the ability to create a session. This is handled through another extension's author- ization message. An example of the use of Resource Management is in the Quality of Service area. In the case where a router receives a request from a user to reserve bandwidth on the network, a DIAMETER Bandwidth request is issued to the DIAMETER Server. In the request is a Session-Id along with information about the reservation being requested. The server first authenticates the user, then authorizes the request. If successfully authorized the server keeps a snapshot of the session and generates a token. Then token contains information about the resources allocated and is signed by the server. The token is essen- tially an opaque blob and is not meant to be interpreted by the client. When the user decides to free the bandwidth, the router issues a request to the DIAMETER server to release the resources associated with the Session Identifier. The following capabilities are required for a robust Resource Manage- ment extension: - Associating resources with clients. - Identifying when a session is terminated. - Session termination request by servers. - State update/refresh from the client or other servers. Since the server must keep an accurate state of each active session, it is necessary to have a messages that is sent by the DIAMETER client to notify the server when a session is terminated. State update and refresh is very important in the case where the server has lost state information (i.e. reboot). The server must be able to request information about a specific session as well as a generic request to retrieve all state information. For services that require fault tolerance, servers should share state information. Calhoun et al. expires February 1999 [Page 9]
INTERNET DRAFT August 1998 The server must be able to request that a client terminate a session. This is required in services where policy can pre-empt a low priority session. As discussed above, upon authorization of a session the server gen- erates and returns to the DIAMETER client a resource token. Upon receipt of a state update request by the server, the client must send resource tokens for the requested sessions. Therefore the token must contain enough information about the session to allow the server to rebuild session state information. Furthermore since state information is shared amongst servers it is required that each session have a universally unique session identif- ier associated with it that is assigned by the client. 2.3 Accounting Extension The Accounting Extension defines the messages used for service accounting. The accounting extension MUST provide the following func- tionality (a separate effort is in place to define the exact require- ments of the accounting extension): - Negotiable transfer mechanism. - Provide general purpose AVPs. - Flexible to allows new extensions to use the accounting exten- sion. - Scalable to allows millions to users and thousands of sites. - Secure accounting data transfer. The accounting extension must be able to transfer accounting records in an event-driven or batch manner. The selected transfer mechanism must be negotiable, and it must be possible to initiate batch transfer from either peer. Other detailed requirements call for supporting service name/id, amount and length of attributes. It must also be flexible to work in many applications areas. This requires extensibility, application defined level of security, minimal storage and code size requirements, and the ability to work in both real-time and non-real time situations. The accounting protocol must be scalable to the size of global Calhoun et al. expires February 1999 [Page 10]
INTERNET DRAFT August 1998 shared-use networks with millions of users and thousands of sites and accounting systems.Transmission, header, and security overhead MUST be amortized over several accounting records. Only a per-entity state needs to be held by the accounting systems (as opposed to a per- session state). The accounting protocol must be secure. End-to-end and hop-by-hop integrity and confidentiality, data-based access control are all needed. Standard Internet security protocols are to be used where possible. 2.4 DIAMETER Command Naming Conventions The following conventions are proposed for the naming of Diameter messages. Diameter commands typically start with an object name, and end with one of the following verbs: 2.4.1 Request/Response Request is used when the command is asking the peer to do something for it, for example, set up a session, or reconfigure some parame- ters. The Response usually contains either a positive or negative result code, telling the requester whether or not the request suc- cessfully occurred. Other information can also be returned in the Response. For example, AA-Request asks the peer device to authorize and/or authenticate a user in order to set up a session. The request may fail, thus the response may be positive or negative. 2.4.2 Query/Response Query is used when the command is asking for information that it expects the peer to have. An example would be querying for current configuration information, or querying for information on resources or sessions in use. The Response usually contains a positive result code and the information, or a negative result code with the reason for not answering the query. For example, Resource-Query requests the peer device to return specific information about one or more resources. The answer is returned in a Resource-Response. Calhoun et al. expires February 1999 [Page 11]
INTERNET DRAFT August 1998 2.4.3 Indication Indication is used when the command is giving information on some- thing that is about to or has already occurred. The peer receiving the message can do no more than acknowledge that it has received it. A particular command that is an Indication does not have a corresponding Ack command defined since it is handled by the reliable DIAMETER transport or by a reliable underlying transport. For example the base draft defines a message that is used to ensure that a peer is still active. This is done with the use of the Watchdog-Ind message, which is acknowledged through the use of a DIAMETER ack as defined in the base draft, or through the underlying transport itself. 3.0 Why not LDAP? One common question is whether LDAP would provide the functionality required. A Server MAY wish to access policies using LDAP, but the use of LDAP between the client and the server is not possible. The use of LDAP in this case would require that all routers have write access to the directory. Most customers would not accept this requirements and it is not efficient. In the case of roaming, customers would have to open up their direc- tory so outside routers have writeable access. Moreover, having 1000's of routers constantly write to the directory would cause some additional problems to the Directory Service. Finally, LDAP does not provide server initiated messages which is a requirement for an AAA protocol. 4.0 References [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location Protocol", RFC-2165, June 1997. [3] Aboba, Zorn, "Roaming Requirements", draft-ietf-roamops- roamreq-08.txt, March 1998. [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. Calhoun et al. expires February 1999 [Page 12]
INTERNET DRAFT August 1998 [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based Admission Control", draft-ietf-rap-framework-00.txt, November 1997. [6] Masinter, "Terminology and Goals for Internet Fax", draft-ietf-fax-goals-02.txt, March 1998. [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [8] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, January 1997. [9] Bradner, "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997. 5.0 Acknowledgements The Authors would like to thanks Bernard Aboba and Jari Arkko for their Accounting Requirements contribution. Thanks also goes to Erik Guttman for some very useful comments in helping make this draft more readable. Calhoun et al. expires February 1999 [Page 13]
INTERNET DRAFT August 1998 6.0 Author's Address Questions about this memo can be directed to: Pat R. Calhoun Technology Development Sun Microsystems, Inc. 15 Network Circle Menlo Park, California, 94025 USA Phone: 1-650-786-7733 Fax: 1-650-786-6445 E-mail: pcalhoun@eng.sun.com Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: 1-425-703-1559 E-Mail: glennz@microsoft.com Ping Pan IBM T. J. Watson Research Center 30 Saw Mill River Road, Hawthorne, NY 10532 Phone: 1-914-784-6579 Fax: 1-914-784-6205 E-mail: pan@watson.ibm.com Calhoun et al. expires February 1999 [Page 14]
INTERNET DRAFT August 1998 Appendix A. "Drinks" Policy Extension This section is provided as an example only and is intended to pro- vide the reader with a better understanding of how DIAMETER could be used by services. This protocol will provide authentication, authorization and account- ing services for bar customers. Each user will be provided with a smart card that contains the user's identity and private key. When a user enters a bar he may use the automated facility by insert- ing his card into a card slot and wait for the appropriate retina scan to be performed. The user also selects a drink, and may simply hit the "favorite drink" button on the machine. The DIAMETER Client then issues the authentication request to the Server which authenticates the user. The message MUST contain a unique session identifier that will be used while the user is present in the bar. The authentication phase consists of a check that the key and retina scan matches the user's identity and that the user is of age (this is a local decision since each state has different minimum age requirements). If the user is successfully authenticated the server adds authoriza- tion information. Authorization information MAY include the user's favorite drinks, whether the user's martini should be shaken or stirred, any known allergic reactions to peanuts or other assorted snacks, etc. Upon receipt of the response, the DIAMETER client dispenses the drink to the customer and generates and accounting request to the DIAMETER accounting server (which MAY be different from the authentication and authorization server). Since the Policy server adapts itself according to the user's drink- ing habits, it knows how often to send a message to the DIAMETER Client to offer another drink to the customer. Since the policy server also knows about the user's favorite drinks, it may even "sug- gest" a list of drinks to the user periodically. This is achieved using the Resource Management extensions defined earlier. When the user wishes to order a new drink, the same mechanism occurs as defined above, but the Session Identifier is constant. When the user leaves the bar, the DIAMETER Client sends a message to the server stating that it is terminating a session (based on the Session Id). Calhoun et al. expires February 1999 [Page 15]