idnits 2.17.1 draft-calhoun-diameter-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 553, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-10) exists of draft-ietf-roamops-roamreq-08 ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-roamreq (ref. '3') ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '5') == Outdated reference: A later version (-04) exists of draft-ietf-fax-goals-02 ** Downref: Normative reference to an Informational draft: draft-ietf-fax-goals (ref. '6') ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '8') Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-framework-01.txt Glen Zorn 5 Date: August 1998 Microsoft Corporation 6 Ping Pan 7 IBM T. J. Watson Research Center 9 DIAMETER Framework Document 10 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working docu- 15 ments of the Internet Engineering Task Force (IETF), its areas, and 16 its working groups. Note that other groups may also distribute work- 17 ing documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet- 22 Drafts as reference material or to cite them other than as a ``work- 23 ing draft'' or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 28 munnari.oz.au. 30 Abstract 32 As the number of new internet services has increased in the past cou- 33 ple of years, routers and network access servers (NAS) have had to 34 undergo re-engineering to support them. 36 These new services could often benefit from an Authentication, 37 Authorization and Accounting (AAA) protocol to facilitate off-loading 38 policy information to an external server. 40 The DIAMETER protocol defines a policy protocol used by clients to 41 perform Policy, AAA and Resource Control. This allows a single server 42 to handle policies for many services. 44 Table of Contents 46 1.0 Introduction 47 1.1 Terminology 48 2.0 DIAMETER Architecture 49 2.1 DIAMETER Base Protocol 50 2.1.1 Proxy Support 51 2.1.2 DIAMETER Security 52 2.2 Resource Management Extension 53 2.3 Accounting Extension 54 2.4 DIAMETER Command Naming Conventions 55 2.4.1 Request/Response 56 2.4.2 Query/Response 57 2.4.3 Indication 58 3.0 Why not LDAP? 59 4.0 References 60 5.0 Acknowledgements 61 6.0 Author's Address 62 Appendix A. "Drinks" Policy Extension 64 1.0 Introduction 66 As the number of new internet services has increased in the past cou- 67 ple of years, routers and network access servers (NAS) have had to 68 undergo re-engineering to support them. 70 These new services could often benefit from an Authentication, 71 Authorization and Accounting (AAA) protocol to facilitate off-loading 72 policy information to an external server. 74 An example of such a service is dial-up PPP Internet access. Large 75 ISPs cannot bear the administrative burden to configure all of their 76 users on each NAS everytime a new device is deployed. In this case 77 RADIUS [1] has been used successfully by many such ISPs. 79 New services such as Voice over IP, Fax over IP [6], Mobile IP [7] 80 and RAP [5] also require similar services in order to be able to 81 authenticate, retrieve authorization information, and generate 82 accounting records for billing purposes. 84 The current trend is for each working groups to define its own policy 85 protocol for a specific service, each with their own nuances. This 86 requires requires customers to deploy several policy servers, which 87 increases the cost of administration and complicates deployment. 89 DIAMETER offers a common solution by defining a base protocol that 90 defines the header formats, security extensions and requirements as 91 well as a small number of mandatory commands and AVPs. A new service 92 can extend DIAMETER by extending the base protocol to support new 93 functionality. 95 1.1 Terminology 97 AAA 99 Authentication, Authorization and Accounting. 101 AVP 103 The DIAMETER protocol consists of a header followed by objects. 104 Each object is encapsulated in a header known as an Attribute- 105 Value-Pair. 107 Commands 109 The DIAMETER Protocol is a request/response protocol. Each DIAME- 110 TER message includes a Command AVP that is used to identify the 111 type of request or response. 113 Integrity Check Vector (ICV) 115 An Integrity Check Vector is an unforgeable or secure hash of the 116 packet with a shared secret. 118 2.0 DIAMETER Architecture 120 The Base DIAMETER Architecture consists of three modules, which 121 defines a small set of primitives that MUST be implemented by all 122 DIAMETER entities. 124 Many applications require that the policy server maintain session 125 state information. The Resource Management extension provides this 126 capability between client and a server as well as between two 127 servers. 129 Most services using DIAMETER require accounting. The current IETF's 130 standard protocol for accounting is SNMP, but experience indicates 131 that SNMP often is not the correct protocol for service accounting. 132 Many applications and services use RADIUS Accounting [4] as their 133 accounting protocol, however RADIUS accounting is not a standard pro- 134 tocol and is informational only. A standard accounting protocol is 135 required. 137 The following diagram provides a representation of the DIAMETER 138 Architecture. As an example, a fictional Policy Extension has been 139 added to the architecture. This fictional service is described here 140 in order to to illustrate how a service could make use of DIAMETER. 142 +------------+ 143 | Policy | 144 | | 145 | Extension | 146 +------------+ 147 +------------+ / \ +------------+ 148 | Resource | | | Accounting | 149 | | | | | 150 | Management | | | Extension | 151 +------------+ | +------------+ 152 / \ | / \ 153 | | | 154 \ / \ / \ / 155 +--------------------------------------------------+ 156 | | 157 | DIAMETER Base Protocol | 158 | | 159 +--------------------------------------------------+ 160 Figure 1: DIAMETER Protocol Architecture 162 Design direction for more extensions will be taken from the user (ISP 163 and network operations) community. 165 2.1 DIAMETER Base Protocol 167 The Base Protocol defines a set of primitives and the security model 168 used between DIAMETER peers. The following goals motivate the defini- 169 tion of the base protocol: 171 - lightweight and simple to implement. 173 - Support unsolicited messages. 175 - Feature discovery. 177 - Version negotiation. 179 - unsupported extension notification. 181 - Efficient encoding of Attributes. 183 - Large AVP address space. 185 - Support for vendor specific AVPs and Commands. 187 - The protocol MUST support both TCP and UDP. 189 - Reliable over non-reliable protocols. 191 - Inter-Server communication. 193 - Authentication and privacy for policy messages. 195 - End-to-End Security. 197 The DIAMETER base protocol is intended to provide a transport for all 198 extensions. It is therefore imperative that the protocol be light- 199 weight and simple to implement. 201 One design goal behind DIAMETER is to allow a "server" to send unsol- 202 icited messages to a "client". DIAMETER's predecessor, RADIUS, was a 203 client/server protocol that required the client to initiate a 204 request. This limitation restricted RADIUS to a small set of applica- 205 tions and will be handled in DIAMETER. 207 Feature Discovery is intended to dramatically reduce the administra- 208 tive overhead associated with Policy Server configuration. A DIAMETER 209 client can use the a DIAMETER service-type request over SLP [2] to 210 locate Policy Servers within the network, and then a set of DIAMETER 211 messages to retrieve the supported extensions. 213 DIAMETER version negotiation will also reduce the administrative 214 overhead in policy server configuration. DIAMETER entities SHOULD 215 agree to use the higher DIAMETER protocol version number that they 216 commonly support. 218 In order to ensure future extensibility does not break current imple- 219 mentations, the protocol must provide a mechanism that allows an 220 indication to be sent to a peer when a DIAMETER message with an 221 unrecognized command is received. 223 Information is carried in a DIAMETER message through the use of AVPs. 224 These AVPs consists of three parts; The AVP Identifier, the length 225 and the data. The AVP Identifier which assigns a unique value to 226 each object. The AVP Identifier address space must be sufficiently 227 large to ensure that future extensibility is not limited to the size 228 of the address space. Vendors wishing to add "proprietary" extensions 229 to the protocol must be allowed to do so by using a vendor specific 230 address space. 232 The AVP data (or object) length must be large enough to carry infor- 233 mation without requiring that the object be fragmented across many 234 AVPs. In order to ensure that AVP encoding/decoding is processor 235 efficient, the protocol will require 32-bit alignment which is con- 236 sistent with most new IETF protocols. 238 UDP is preferable for policy applications that require "fine tuned" 239 retransmission strategies. For applications that require support for 240 larger messages and are not as concerned with the retransmission pol- 241 icy, TCP can be used. Each individual extension may specify the 242 underlying transport requirements. 244 For implementations using DIAMETER over UDP, the DIAMETER protocol 245 MUST provide a reliable transport and a well defined retransmission 246 scheme. This include support of windowing as well as a mechanism to 247 detect that communication with the peer is still possible. 249 2.1.1 Proxy Support 251 One key differentiator with DIAMETER is its inherent support for 252 Inter-Server communication. Although this can be achieved in a 253 variety of ways, the most useful feature is the ability to "proxy" 254 messages across a set of DIAMETER servers (known as a proxy chain). 256 One key application for DIAMETER is ROAMOPS [3], which defines a 257 method for Service Providers to provide inter-domain Dial-Up Internet 258 access. An example would be a user has an internet account with some 259 local provider in the San Francisco bay area and the user travels to 260 Rome. This user would like to be able to access the internet, but the 261 cost of International long distance prohibits the user from doing so. 263 If the user's ISP provides roaming capabilities, the user can dial 264 any one of many ISPs that have a roaming agreement with his home ISP. 265 If there are such ISPs in Rome, the user will be able to access the 266 Internet through a local call and keep the costs down significantly. 268 Although all DIAMETER servers in the proxy chain may belong to the 269 same administrative domain, the protocol must be designed to allow 270 these servers to reside within different domains. 272 Rome ISP Bay-Area ISP 273 +--------+ +--------+ 274 | proxy | | policy | 275 | policy |<--------------->| | 276 | server | server-server | server | 277 +--------+ communication +--------+ 278 / /|\ 279 / | client-server 280 / | communication 281 |/_ \|/ 282 +--------+ +--------+ 283 | Dial-Up| | Dial-Up| 284 | router | | router | 285 +--------+ +--------+ 286 Figure 2: Client communication through a proxy server 288 2.1.2 DIAMETER Security 290 There are two different requirements for security. One is the case 291 where two DIAMETER peers communicate directly, also known as hop-by- 292 hop and one where two DIAMETER entities need to communicate through a 293 proxy chain. 295 In the case of hop-by-hop security, two different methods are defined 296 in DIAMETER. One, and the most obvious method, is to provide no DIAM- 297 ETER security and rely on IP Security. 299 The second method, which is backward compatible with RADIUS and 300 requires no changes to the infrastructure, is to make use of shared 301 secrets between two DIAMETER entities. In this case the protocol 302 could include an HMAC-MD5-96 [8] Integrity Check Vector (ICV) within 303 an AVP to provide integrity of the message. 305 Figure 3 depicts an example of Hop-by-Hop security where Policy 306 Server 1 (PS1) and Proxy Server 2 (PS2) share a secret as well as PS2 307 and Policy Server 3 (PS3). In this example PS1 sends a message to PS3 308 through PS2 with an ICV that is computed using the secret it shares 309 with PS2. Upon receipt of the message, PS2 validates the ICV, removes 310 it and adds an ICV that is computed using the secret it shares with 311 PS3. This is commonly called Hop-by-Hop security since it does not 312 provide message integrity between PS1 and PS3. 314 In the case of End-to-End security, a DIAMETER entity communicates 315 with another through a proxy chain. In this case end-to-end 316 integrity, confidentiality and non-repudiation is required on a set 317 of AVPs within a message. This is necessary since some AVPs (known as 318 unprotected AVPs) may be modified in transit by the intermediate 319 proxy servers. In this case the initiator must sign the messages 320 using public key cryptography since it is the only way for the end 321 server to ensure that a proxy has not modified any protected AVPs in 322 the message. 324 +----------+ +----------+ 325 | policy |<--------------->| proxy | 326 | server 1 | server-server | server 2 | 327 +----------+ communication +----------+ 328 /|\ 329 | server-server 330 | communication 331 \|/ 332 +----------+ 333 | policy | 334 | server 3 | 335 +----------+ 336 Figure 3: Proxy Server Communication 338 If certificates are not statically configured or retrieved through 339 some other means (i.e. Certificate Authority), it requires that both 340 the client and the server exchange certificates as part of the DIAME- 341 TER bootstrap protocol. 343 It is a requirement that any DIAMETER Security extension also address 345 2.2 Resource Management Extension 347 The Resource Management extension allows two DIAMETER entities to 348 share session information. When the server grants authorization of 349 some resources to a DIAMETER node on behalf of some user, the server 350 maintains state information about the session which is identified 351 through the use of a session identifier (aka Session-Id). 353 The Session-Id is generated by the DIAMETER node requesting 354 authorization and is used in subsequent Resource Management messages 355 to keep the server up to date on the current state of the session. 356 However the Resource Management extension also provides messages for 357 distributed back-end servers to share session state information. 359 The Resource Management extension does not provide the ability to 360 create a session. This is handled through another extension's author- 361 ization message. 363 An example of the use of Resource Management is in the Quality of 364 Service area. In the case where a router receives a request from a 365 user to reserve bandwidth on the network, a DIAMETER Bandwidth 366 request is issued to the DIAMETER Server. In the request is a 367 Session-Id along with information about the reservation being 368 requested. 370 The server first authenticates the user, then authorizes the request. 371 If successfully authorized the server keeps a snapshot of the session 372 and generates a token. Then token contains information about the 373 resources allocated and is signed by the server. The token is essen- 374 tially an opaque blob and is not meant to be interpreted by the 375 client. 377 When the user decides to free the bandwidth, the router issues a 378 request to the DIAMETER server to release the resources associated 379 with the Session Identifier. 381 The following capabilities are required for a robust Resource Manage- 382 ment extension: 384 - Associating resources with clients. 386 - Identifying when a session is terminated. 388 - Session termination request by servers. 390 - State update/refresh from the client or other servers. 392 Since the server must keep an accurate state of each active session, 393 it is necessary to have a messages that is sent by the DIAMETER 394 client to notify the server when a session is terminated. 396 State update and refresh is very important in the case where the 397 server has lost state information (i.e. reboot). The server must be 398 able to request information about a specific session as well as a 399 generic request to retrieve all state information. For services that 400 require fault tolerance, servers should share state information. 402 The server must be able to request that a client terminate a session. 403 This is required in services where policy can pre-empt a low priority 404 session. 406 As discussed above, upon authorization of a session the server gen- 407 erates and returns to the DIAMETER client a resource token. Upon 408 receipt of a state update request by the server, the client must send 409 resource tokens for the requested sessions. Therefore the token must 410 contain enough information about the session to allow the server to 411 rebuild session state information. 413 Furthermore since state information is shared amongst servers it is 414 required that each session have a universally unique session identif- 415 ier associated with it that is assigned by the client. 417 2.3 Accounting Extension 419 The Accounting Extension defines the messages used for service 420 accounting. The accounting extension MUST provide the following func- 421 tionality (a separate effort is in place to define the exact require- 422 ments of the accounting extension): 424 - Negotiable transfer mechanism. 426 - Provide general purpose AVPs. 428 - Flexible to allows new extensions to use the accounting exten- 429 sion. 431 - Scalable to allows millions to users and thousands of sites. 433 - Secure accounting data transfer. 435 The accounting extension must be able to transfer accounting records 436 in an event-driven or batch manner. The selected transfer mechanism 437 must be negotiable, and it must be possible to initiate batch 438 transfer from either peer. 440 Other detailed requirements call for supporting service name/id, 441 amount and length of attributes. 443 It must also be flexible to work in many applications areas. This 444 requires extensibility, application defined level of security, 445 minimal storage and code size requirements, and the ability to work 446 in both real-time and non-real time situations. 448 The accounting protocol must be scalable to the size of global 449 shared-use networks with millions of users and thousands of sites and 450 accounting systems.Transmission, header, and security overhead MUST 451 be amortized over several accounting records. Only a per-entity state 452 needs to be held by the accounting systems (as opposed to a per- 453 session state). 455 The accounting protocol must be secure. End-to-end and hop-by-hop 456 integrity and confidentiality, data-based access control are all 457 needed. Standard Internet security protocols are to be used where 458 possible. 460 2.4 DIAMETER Command Naming Conventions 462 The following conventions are proposed for the naming of Diameter 463 messages. 465 Diameter commands typically start with an object name, and end with 466 one of the following verbs: 468 2.4.1 Request/Response 470 Request is used when the command is asking the peer to do something 471 for it, for example, set up a session, or reconfigure some parame- 472 ters. The Response usually contains either a positive or negative 473 result code, telling the requester whether or not the request suc- 474 cessfully occurred. Other information can also be returned in the 475 Response. 477 For example, AA-Request asks the peer device to authorize and/or 478 authenticate a user in order to set up a session. The request may 479 fail, thus the response may be positive or negative. 481 2.4.2 Query/Response 483 Query is used when the command is asking for information that it 484 expects the peer to have. An example would be querying for current 485 configuration information, or querying for information on resources 486 or sessions in use. The Response usually contains a positive result 487 code and the information, or a negative result code with the reason 488 for not answering the query. 490 For example, Resource-Query requests the peer device to return 491 specific information about one or more resources. The answer is 492 returned in a Resource-Response. 494 2.4.3 Indication 496 Indication is used when the command is giving information on some- 497 thing that is about to or has already occurred. The peer receiving 498 the message can do no more than acknowledge that it has received it. 499 A particular command that is an Indication does not have a 500 corresponding Ack command defined since it is handled by the reliable 501 DIAMETER transport or by a reliable underlying transport. 503 For example the base draft defines a message that is used to ensure 504 that a peer is still active. This is done with the use of the 505 Watchdog-Ind message, which is acknowledged through the use of a 506 DIAMETER ack as defined in the base draft, or through the underlying 507 transport itself. 509 3.0 Why not LDAP? 511 One common question is whether LDAP would provide the functionality 512 required. 514 A Server MAY wish to access policies using LDAP, but the use of LDAP 515 between the client and the server is not possible. The use of LDAP in 516 this case would require that all routers have write access to the 517 directory. Most customers would not accept this requirements and it 518 is not efficient. 520 In the case of roaming, customers would have to open up their direc- 521 tory so outside routers have writeable access. Moreover, having 522 1000's of routers constantly write to the directory would cause some 523 additional problems to the Directory Service. 525 Finally, LDAP does not provide server initiated messages which is a 526 requirement for an AAA protocol. 528 4.0 References 530 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 532 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location 533 Protocol", RFC-2165, June 1997. 535 [3] Aboba, Zorn, "Roaming Requirements", draft-ietf-roamops- 536 roamreq-08.txt, March 1998. 538 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 540 [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based 541 Admission Control", draft-ietf-rap-framework-00.txt, 542 November 1997. 544 [6] Masinter, "Terminology and Goals for Internet Fax", 545 draft-ietf-fax-goals-02.txt, March 1998. 547 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 548 1996. 550 [8] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 551 Message Authentication", RFC 2104, January 1997. 553 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 554 Levels", BCP 14, RFC 2119, March 1997. 556 5.0 Acknowledgements 558 The Authors would like to thanks Bernard Aboba and Jari Arkko for 559 their Accounting Requirements contribution. Thanks also goes to Erik 560 Guttman for some very useful comments in helping make this draft more 561 readable. 563 6.0 Author's Address 565 Questions about this memo can be directed to: 567 Pat R. Calhoun 568 Technology Development 569 Sun Microsystems, Inc. 570 15 Network Circle 571 Menlo Park, California, 94025 572 USA 574 Phone: 1-650-786-7733 575 Fax: 1-650-786-6445 576 E-mail: pcalhoun@eng.sun.com 578 Glen Zorn 579 Microsoft Corporation 580 One Microsoft Way 581 Redmond, WA 98052 582 USA 584 Phone: 1-425-703-1559 585 E-Mail: glennz@microsoft.com 587 Ping Pan 588 IBM T. J. Watson Research Center 589 30 Saw Mill River Road, 590 Hawthorne, NY 10532 592 Phone: 1-914-784-6579 593 Fax: 1-914-784-6205 594 E-mail: pan@watson.ibm.com 596 Appendix A. "Drinks" Policy Extension 598 This section is provided as an example only and is intended to pro- 599 vide the reader with a better understanding of how DIAMETER could be 600 used by services. 602 This protocol will provide authentication, authorization and account- 603 ing services for bar customers. Each user will be provided with a 604 smart card that contains the user's identity and private key. 606 When a user enters a bar he may use the automated facility by insert- 607 ing his card into a card slot and wait for the appropriate retina 608 scan to be performed. The user also selects a drink, and may simply 609 hit the "favorite drink" button on the machine. 611 The DIAMETER Client then issues the authentication request to the 612 Server which authenticates the user. The message MUST contain a 613 unique session identifier that will be used while the user is present 614 in the bar. The authentication phase consists of a check that the key 615 and retina scan matches the user's identity and that the user is of 616 age (this is a local decision since each state has different minimum 617 age requirements). 619 If the user is successfully authenticated the server adds authoriza- 620 tion information. Authorization information MAY include the user's 621 favorite drinks, whether the user's martini should be shaken or 622 stirred, any known allergic reactions to peanuts or other assorted 623 snacks, etc. 625 Upon receipt of the response, the DIAMETER client dispenses the drink 626 to the customer and generates and accounting request to the DIAMETER 627 accounting server (which MAY be different from the authentication and 628 authorization server). 630 Since the Policy server adapts itself according to the user's drink- 631 ing habits, it knows how often to send a message to the DIAMETER 632 Client to offer another drink to the customer. Since the policy 633 server also knows about the user's favorite drinks, it may even "sug- 634 gest" a list of drinks to the user periodically. This is achieved 635 using the Resource Management extensions defined earlier. 637 When the user wishes to order a new drink, the same mechanism occurs 638 as defined above, but the Session Identifier is constant. When the 639 user leaves the bar, the DIAMETER Client sends a message to the 640 server stating that it is terminating a session (based on the Session 641 Id).