[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09                                 
INTERNET DRAFT                                            Pat R. Calhoun
Category: Standards Track                         Sun Microsystems, Inc.
Title: draft-calhoun-diameter-framework-02.txt                 Glen Zorn
Date: December 1998                                Microsoft Corporation
                                                                Ping Pan
                                                               Bell Labs



                      DIAMETER Framework Document
               <draft-calhoun-diameter-framework-02.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 May 1999                    [Page 1]


INTERNET DRAFT                                             December 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 Brokers
      2.1.3 DIAMETER Security
      2.2   Resource Management Extension
      2.3   Authentication/Authorization Mechanism
      2.4   Accounting Extension
      2.5   DIAMETER Command Naming Conventions
      2.5.1 Request/Response
      2.5.2 Query/Response
      2.5.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.



Calhoun et al.              expires May 1999                    [Page 2]


INTERNET DRAFT                                             December 1998


   DIAMETER offers a common solution by defining a base protocol that
   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.


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



Calhoun et al.              expires May 1999                    [Page 3]


INTERNET DRAFT                                             December 1998


   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.


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.



Calhoun et al.              expires May 1999                    [Page 4]


INTERNET DRAFT                                             December 1998


      - 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.

      - Session Oriented Protocol.

   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.

   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



Calhoun et al.              expires May 1999                    [Page 5]


INTERNET DRAFT                                             December 1998


   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.

   The DIAMETER protocol is a session oriented protocol, meaning that
   each authentication/authorization request must belong to a session,
   which is identified through a Session Identifier. All subsequent
   DIAMETER transactions done on behalf of the session must include the
   Session Identifier.


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
   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



Calhoun et al.              expires May 1999                    [Page 6]


INTERNET DRAFT                                             December 1998


   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 Brokers

   As mentioned in the previous section, the DIAMETER protocol was
   designed to support "proxying" of messages through a set of AAA
   servers. The protocol must also support a new business model that is
   increasing in popularity in the Internet, which is the broker or
   "clearing house". Brokers are settlement agents, and are very similar
   to the EDI Clearing Houses described in [14]. They establish business
   relationships with providers and proxy authentication and accounting
   requests to the appropriate destination. The security requirements of
   this business model can be very different from the previous section,
   since it may require such features as non-repudiation and end-to-end
   integrity.

                +----------+                 +----------+
                |   AAA    |<--------------->|Settlement|
                | ISPA.Net |  server-server  |  Agent   |
                +----------+  communication  +----------+
                            |\-                 /|\
                               \                 | server-server
                                 \               | communication
                                   \            \|/
                      End-to-End     \       +----------+
                       Security        \     |   AAA    |
                                         \|  | ISPB.Net |
                                         -   +----------+
                    Figure 3: DIAMETER Settlement Agent

   It is envisioned that in this environment public key cryptography



Calhoun et al.              expires May 1999                    [Page 7]


INTERNET DRAFT                                             December 1998


   will be used to provide end-to-end security. The Broker, or Settle-
   ment Agent, is in a good position to act as a Certificate Authority.
   Further research is required to determine how secure communication
   can be achieved across more than one broker.


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 secu-
   rity at the application (DIAMETER) level, and rely on some underlying
   security service, such as 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. This method should allow
   both long lived shared secrets, and the use of out-of-band key nego-
   tiation, such as the Internet Key Exchange (IKE) [16]. In order to
   allow the use of IKE for DIAMETER, a a new AAA Domain of Interpreta-
   tion (DOI) must be defined.

   Figure 4 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
   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.

   The third method, called End-to-End security, allows DIAMETER end
   nodes to securely communicate through a proxy chain. This method pro-
   vides end-to-end integrity, confidentiality and non-repudiation on a
   set of AVPs within a message. This method allows that only a portion
   of the AVPs be covered by the authentication, known as the protected
   AVPs, in order to allow proxy DIAMETER nodes to add information in
   transit. This method may be used with the Hop-by-Hop method, where
   this option would provide end to end security and the later would
   allow for the message to be protected through each hop.

   Using the example in figure 4, the message initiator, PS1, would



Calhoun et al.              expires May 1999                    [Page 8]


INTERNET DRAFT                                             December 1998


   digitally sign the DIAMETER message and add the Hop-by-Hop ICV infor-
   mation using the secret it shares with PS2. PS2 would authenticate
   the ICV, and forward the message to PS3, adding its own ICV using the
   secret it shares with PS3. Upon receipt of the message, PS3 would
   authenticate the ICV and the digital signature added by PS1.

                +----------+                 +----------+
                |  policy  |<--------------->|  proxy   | Settlement
                | server 1 |  server-server  | server 2 |   Agent
                +----------+  communication  +----------+
                                                /|\
                                                 | server-server
                                                 | communication
                                                \|/
                                             +----------+
                                             |  policy  |
                                             | server 3 |
                                             +----------+
                   Figure 4: 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.


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 authori-
   zation 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 distri-
   buted 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



Calhoun et al.              expires May 1999                    [Page 9]


INTERNET DRAFT                                             December 1998


   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.

   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



Calhoun et al.              expires May 1999                   [Page 10]


INTERNET DRAFT                                             December 1998


   identifier associated with it that is assigned by the client.


2.3  Authentication/Authorization Mechanism

   DIAMETER was designed to be a flexible AAA protocol that can be used
   for a wide variety of services and applications. Historically, these
   applications and services have designed their own authentication
   mechanisms, ignoring previous IETF work.

   The DIAMETER protocol will support a set of authentication mechanisms
   in hopes that most new protocols will attempt to use one of them. In
   cases where these mechanisms do not fit within the protocol require-
   ments, or framework, a new authentication mechanism will have to be
   defined for the protocol, and a method to carry it within the DIAME-
   TER protocol. The following authentication mechanism must be sup-
   ported by DIAMETER:

      - Extensible Authentication protocol (EAP) [10]
      - Simple Authentication Security Layer (SASL) [11]
      - Generic Security Service Authentication Program Interface
        (GSSAPI) [12]
      - IKE's Extended Authentication (XAUTH) [13] (proposed)

   It is envisioned that when an authentication request is issued to a
   DIAMETER server, it also includes a service/application identifier.
   The DIAMETER server uses the identifier to determine the service or
   application, which is used to look up the authorization information
   for the user.

   This mechanism allows the re-use of existing, standard IETF authenti-
   cation mechanism for multiple services. Any service or application
   that makes use of one of these methods needs to specify its DIAMETER
   Extension identifier as well as the authorization information that
   must be present in the request and the response.

   As previously mentioned, other protocols that must create their own
   authentication mechanisms must define how the authentication is car-
   ried in the DIAMETER protocol, and how it is handled by the server.
   An example is the Mobile IP protocol [7]. A separate authentication
   method was designed for this protocol because it required minimal
   traversals through the internet [15]. The document [13] defines how
   this is carried within the DIAMETER protocol, as well as the authori-
   zation information that is required.


2.4  Accounting Extension




Calhoun et al.              expires May 1999                   [Page 11]


INTERNET DRAFT                                             December 1998


   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
   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.5  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



Calhoun et al.              expires May 1999                   [Page 12]


INTERNET DRAFT                                             December 1998


   one of the following verbs:


2.5.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.5.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.


2.5.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 does not respond to the message, but a transport level
   acknowledgement must be done in order to ensure that the message was
   reliably delivered.

   For example the base draft defines a message that is used to ensure
   that a peer is still active. This is achieve with the Watchdog-Ind
   message, which is acknowledged either by TCP, or using a DIAMETER
   message acknowledgement as defined in [17].


3.0  Why not LDAP?

   One common question is whether LDAP would provide the functionality



Calhoun et al.              expires May 1999                   [Page 13]


INTERNET DRAFT                                             December 1998


   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 read/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. The security implica-
   tions set aside, having 1000's of routers constantly read/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.

   [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based
       Admission Control", draft-ietf-rap-framework-00.txt, IETF
       Work in Progress, November 1997.

   [6] Masinter, "Terminology and Goals for Internet Fax",
       draft-ietf-fax-goals-02.txt, IETF Work in Progress,
       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.

   [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol



Calhoun et al.              expires May 1999                   [Page 14]


INTERNET DRAFT                                             December 1998


        (EAP)", RFC 2284, March 1998.

   [11] J. Meyes, "Simple Authentication and Security Layer (SASL)",
        RFC 2222, October 1997.

   [12] J. Linn, "Generic Security Service Application Program
        Interface, Version 2", RFC 2078, January 1997.

   [13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions",
        draft-calhoun-diameter-mobileip-01.txt, IETF Work in
        Prgress, November 1998.

   [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and
        EDI Law", Prentice-Hall, ISBN 0-471-53135-9.

   [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent
        Challenge/Response Extension",
        draft-ietf-mobileip-challenge-00.txt, IETF Work in progress,
        November 1998.

   [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)"
        RFC 1409, November 1998.

   [17] P. Calhoun, A. Rubens, "Reliable Transport Extensions",
        draft-calhoun-diameter-reliable-00.txt, IETF Work in
        Progress, November 1998.


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 May 1999                   [Page 15]


INTERNET DRAFT                                             December 1998


6.0  Author's Address

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Sun Laboratories, Network and Security
      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
      Bell Laboratories
      Lucent Technologies
      101 Crawfords Corner Road
      Holmdel, NJ 07733
      USA

       Phone:  1-732-332-6744
      E-mail:  pingpan@dnrc.bell-labs.com.fi
















Calhoun et al.              expires May 1999                   [Page 16]


INTERNET DRAFT                                             December 1998


Appendix A.  "Drinks" Policy Extension

   This section is provided as an example only and is intended to provide
   the reader with a better understanding of how DIAMETER could be used
   by services.

   This protocol will provide authentication, authorization and accounting
   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 inserting
   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 authorization
   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 drinking
   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 "suggest" 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 May 1999                   [Page 17]