idnits 2.17.1 draft-calhoun-diameter-framework-02.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-27) 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 16 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 17 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. ** There are 16 instances of too long lines in the document, the longest one being 5 characters in excess of 72. 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 648, 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') ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) ** Obsolete normative reference: RFC 2222 (ref. '11') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2078 (ref. '12') (Obsoleted by RFC 2743) == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-01 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-00 ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) == Outdated reference: A later version (-01) exists of draft-calhoun-diameter-reliable-00 -- Possible downref: Normative reference to a draft: ref. '17' Summary: 21 errors (**), 0 flaws (~~), 10 warnings (==), 5 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-02.txt Glen Zorn 5 Date: December 1998 Microsoft Corporation 6 Ping Pan 7 Bell Labs 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 Brokers 52 2.1.3 DIAMETER Security 53 2.2 Resource Management Extension 54 2.3 Authentication/Authorization Mechanism 55 2.4 Accounting Extension 56 2.5 DIAMETER Command Naming Conventions 57 2.5.1 Request/Response 58 2.5.2 Query/Response 59 2.5.3 Indication 60 3.0 Why not LDAP? 61 4.0 References 62 5.0 Acknowledgements 63 6.0 Author's Address 64 Appendix A. "Drinks" Policy Extension 66 1.0 Introduction 68 As the number of new internet services has increased in the past cou- 69 ple of years, routers and network access servers (NAS) have had to 70 undergo re-engineering to support them. 72 These new services could often benefit from an Authentication, 73 Authorization and Accounting (AAA) protocol to facilitate off-loading 74 policy information to an external server. 76 An example of such a service is dial-up PPP Internet access. Large 77 ISPs cannot bear the administrative burden to configure all of their 78 users on each NAS everytime a new device is deployed. In this case 79 RADIUS [1] has been used successfully by many such ISPs. 81 New services such as Voice over IP, Fax over IP [6], Mobile IP [7] 82 and RAP [5] also require similar services in order to be able to 83 authenticate, retrieve authorization information, and generate 84 accounting records for billing purposes. 86 The current trend is for each working groups to define its own policy 87 protocol for a specific service, each with their own nuances. This 88 requires requires customers to deploy several policy servers, which 89 increases the cost of administration and complicates deployment. 91 DIAMETER offers a common solution by defining a base protocol that 92 defines the header formats, security extensions and requirements as 93 well as a small number of mandatory commands and AVPs. A new service 94 can extend DIAMETER by extending the base protocol to support new 95 functionality. 97 1.1 Terminology 99 AAA 101 Authentication, Authorization and Accounting. 103 AVP 105 The DIAMETER protocol consists of a header followed by objects. 106 Each object is encapsulated in a header known as an Attribute- 107 Value-Pair. 109 Commands 111 The DIAMETER Protocol is a request/response protocol. Each DIAME- 112 TER message includes a Command AVP that is used to identify the 113 type of request or response. 115 Integrity Check Vector (ICV) 117 An Integrity Check Vector is an unforgeable or secure hash of the 118 packet with a shared secret. 120 2.0 DIAMETER Architecture 122 The Base DIAMETER Architecture consists of three modules, which 123 defines a small set of primitives that MUST be implemented by all 124 DIAMETER entities. 126 Many applications require that the policy server maintain session 127 state information. The Resource Management extension provides this 128 capability between client and a server as well as between two 129 servers. 131 Most services using DIAMETER require accounting. The current IETF's 132 standard protocol for accounting is SNMP, but experience indicates 133 that SNMP often is not the correct protocol for service accounting. 134 Many applications and services use RADIUS Accounting [4] as their 135 accounting protocol, however RADIUS accounting is not a standard pro- 136 tocol and is informational only. A standard accounting protocol is 137 required. 139 The following diagram provides a representation of the DIAMETER 140 Architecture. As an example, a fictional Policy Extension has been 141 added to the architecture. This fictional service is described here 142 in order to to illustrate how a service could make use of DIAMETER. 144 +------------+ 145 | Policy | 146 | | 147 | Extension | 148 +------------+ 149 +------------+ / \ +------------+ 150 | Resource | | | Accounting | 151 | | | | | 152 | Management | | | Extension | 153 +------------+ | +------------+ 154 / \ | / \ 155 | | | 156 \ / \ / \ / 157 +--------------------------------------------------+ 158 | | 159 | DIAMETER Base Protocol | 160 | | 161 +--------------------------------------------------+ 162 Figure 1: DIAMETER Protocol Architecture 164 Design direction for more extensions will be taken from the user (ISP 165 and network operations) community. 167 2.1 DIAMETER Base Protocol 169 The Base Protocol defines a set of primitives and the security model 170 used between DIAMETER peers. The following goals motivate the defini- 171 tion of the base protocol: 173 - lightweight and simple to implement. 175 - Support unsolicited messages. 177 - Feature discovery. 179 - Version negotiation. 181 - unsupported extension notification. 183 - Efficient encoding of Attributes. 185 - Large AVP address space. 187 - Support for vendor specific AVPs and Commands. 189 - The protocol MUST support both TCP and UDP. 191 - Reliable over non-reliable protocols. 193 - Inter-Server communication. 195 - Authentication and privacy for policy messages. 197 - End-to-End Security. 199 - Session Oriented Protocol. 201 The DIAMETER base protocol is intended to provide a transport for all 202 extensions. It is therefore imperative that the protocol be light- 203 weight and simple to implement. 205 One design goal behind DIAMETER is to allow a "server" to send unsol- 206 icited messages to a "client". DIAMETER's predecessor, RADIUS, was a 207 client/server protocol that required the client to initiate a 208 request. This limitation restricted RADIUS to a small set of applica- 209 tions and will be handled in DIAMETER. 211 Feature Discovery is intended to dramatically reduce the administra- 212 tive overhead associated with Policy Server configuration. A DIAMETER 213 client can use the a DIAMETER service-type request over SLP [2] to 214 locate Policy Servers within the network, and then a set of DIAMETER 215 messages to retrieve the supported extensions. 217 DIAMETER version negotiation will also reduce the administrative 218 overhead in policy server configuration. DIAMETER entities SHOULD 219 agree to use the higher DIAMETER protocol version number that they 220 commonly support. 222 In order to ensure future extensibility does not break current imple- 223 mentations, the protocol must provide a mechanism that allows an 224 indication to be sent to a peer when a DIAMETER message with an 225 unrecognized command is received. 227 Information is carried in a DIAMETER message through the use of AVPs. 228 These AVPs consists of three parts; The AVP Identifier, the length 229 and the data. The AVP Identifier which assigns a unique value to 230 each object. The AVP Identifier address space must be sufficiently 231 large to ensure that future extensibility is not limited to the size 232 of the address space. Vendors wishing to add "proprietary" extensions 233 to the protocol must be allowed to do so by using a vendor specific 234 address space. 236 The AVP data (or object) length must be large enough to carry infor- 237 mation without requiring that the object be fragmented across many 238 AVPs. In order to ensure that AVP encoding/decoding is processor 239 efficient, the protocol will require 32-bit alignment which is con- 240 sistent with most new IETF protocols. 242 UDP is preferable for policy applications that require "fine tuned" 243 retransmission strategies. For applications that require support for 244 larger messages and are not as concerned with the retransmission pol- 245 icy, TCP can be used. Each individual extension may specify the 246 underlying transport requirements. 248 For implementations using DIAMETER over UDP, the DIAMETER protocol 249 MUST provide a reliable transport and a well defined retransmission 250 scheme. This include support of windowing as well as a mechanism to 251 detect that communication with the peer is still possible. 253 The DIAMETER protocol is a session oriented protocol, meaning that 254 each authentication/authorization request must belong to a session, 255 which is identified through a Session Identifier. All subsequent 256 DIAMETER transactions done on behalf of the session must include the 257 Session Identifier. 259 2.1.1 Proxy Support 261 One key differentiator with DIAMETER is its inherent support for 262 Inter-Server communication. Although this can be achieved in a 263 variety of ways, the most useful feature is the ability to "proxy" 264 messages across a set of DIAMETER servers (known as a proxy chain). 266 One key application for DIAMETER is ROAMOPS [3], which defines a 267 method for Service Providers to provide inter-domain Dial-Up Internet 268 access. An example would be a user has an internet account with some 269 local provider in the San Francisco bay area and the user travels to 270 Rome. This user would like to be able to access the internet, but the 271 cost of International long distance prohibits the user from doing so. 273 If the user's ISP provides roaming capabilities, the user can dial 274 any one of many ISPs that have a roaming agreement with his home ISP. 275 If there are such ISPs in Rome, the user will be able to access the 276 Internet through a local call and keep the costs down significantly. 278 Although all DIAMETER servers in the proxy chain may belong to the 279 same administrative domain, the protocol must be designed to allow 280 these servers to reside within different domains. 282 Rome ISP Bay-Area ISP 283 +--------+ +--------+ 284 | proxy | | policy | 285 | policy |<--------------->| | 286 | server | server-server | server | 287 +--------+ communication +--------+ 288 / /|\ 289 / | client-server 290 / | communication 291 |/_ \|/ 292 +--------+ +--------+ 293 | Dial-Up| | Dial-Up| 294 | router | | router | 295 +--------+ +--------+ 296 Figure 2: Client communication through a proxy server 298 2.1.2 DIAMETER Brokers 300 As mentioned in the previous section, the DIAMETER protocol was 301 designed to support "proxying" of messages through a set of AAA 302 servers. The protocol must also support a new business model that is 303 increasing in popularity in the Internet, which is the broker or 304 "clearing house". Brokers are settlement agents, and are very similar 305 to the EDI Clearing Houses described in [14]. They establish business 306 relationships with providers and proxy authentication and accounting 307 requests to the appropriate destination. The security requirements of 308 this business model can be very different from the previous section, 309 since it may require such features as non-repudiation and end-to-end 310 integrity. 312 +----------+ +----------+ 313 | AAA |<--------------->|Settlement| 314 | ISPA.Net | server-server | Agent | 315 +----------+ communication +----------+ 316 |\- /|\ 317 \ | server-server 318 \ | communication 319 \ \|/ 320 End-to-End \ +----------+ 321 Security \ | AAA | 322 \| | ISPB.Net | 323 - +----------+ 324 Figure 3: DIAMETER Settlement Agent 326 It is envisioned that in this environment public key cryptography 327 will be used to provide end-to-end security. The Broker, or Settle- 328 ment Agent, is in a good position to act as a Certificate Authority. 329 Further research is required to determine how secure communication 330 can be achieved across more than one broker. 332 2.1.2 DIAMETER Security 334 There are two different requirements for security. One is the case 335 where two DIAMETER peers communicate directly, also known as hop-by- 336 hop and one where two DIAMETER entities need to communicate through a 337 proxy chain. 339 In the case of hop-by-hop security, two different methods are defined 340 in DIAMETER. One, and the most obvious method, is to provide no secu- 341 rity at the application (DIAMETER) level, and rely on some underlying 342 security service, such as IP Security. 344 The second method, which is backward compatible with RADIUS and 345 requires no changes to the infrastructure, is to make use of shared 346 secrets between two DIAMETER entities. In this case the protocol 347 could include an HMAC-MD5-96 [8] Integrity Check Vector (ICV) within 348 an AVP to provide integrity of the message. This method should allow 349 both long lived shared secrets, and the use of out-of-band key nego- 350 tiation, such as the Internet Key Exchange (IKE) [16]. In order to 351 allow the use of IKE for DIAMETER, a a new AAA Domain of Interpreta- 352 tion (DOI) must be defined. 354 Figure 4 depicts an example of Hop-by-Hop security where Policy 355 Server 1 (PS1) and Proxy Server 2 (PS2) share a secret as well as PS2 356 and Policy Server 3 (PS3). In this example PS1 sends a message to PS3 357 through PS2 with an ICV that is computed using the secret it shares 358 with PS2. Upon receipt of the message, PS2 validates the ICV, removes 359 it and adds an ICV that is computed using the secret it shares with 360 PS3. This is commonly called Hop-by-Hop security since it does not 361 provide message integrity between PS1 and PS3. 363 The third method, called End-to-End security, allows DIAMETER end 364 nodes to securely communicate through a proxy chain. This method pro- 365 vides end-to-end integrity, confidentiality and non-repudiation on a 366 set of AVPs within a message. This method allows that only a portion 367 of the AVPs be covered by the authentication, known as the protected 368 AVPs, in order to allow proxy DIAMETER nodes to add information in 369 transit. This method may be used with the Hop-by-Hop method, where 370 this option would provide end to end security and the later would 371 allow for the message to be protected through each hop. 373 Using the example in figure 4, the message initiator, PS1, would 374 digitally sign the DIAMETER message and add the Hop-by-Hop ICV infor- 375 mation using the secret it shares with PS2. PS2 would authenticate 376 the ICV, and forward the message to PS3, adding its own ICV using the 377 secret it shares with PS3. Upon receipt of the message, PS3 would 378 authenticate the ICV and the digital signature added by PS1. 380 +----------+ +----------+ 381 | policy |<--------------->| proxy | Settlement 382 | server 1 | server-server | server 2 | Agent 383 +----------+ communication +----------+ 384 /|\ 385 | server-server 386 | communication 387 \|/ 388 +----------+ 389 | policy | 390 | server 3 | 391 +----------+ 392 Figure 4: Proxy Server Communication 394 If certificates are not statically configured or retrieved through 395 some other means (i.e. Certificate Authority), it requires that both 396 the client and the server exchange certificates as part of the DIAME- 397 TER bootstrap protocol. 399 2.2 Resource Management Extension 401 The Resource Management extension allows two DIAMETER entities to 402 share session information. When the server grants authorization of 403 some resources to a DIAMETER node on behalf of some user, the server 404 maintains state information about the session which is identified 405 through the use of a session identifier (aka Session-Id). 407 The Session-Id is generated by the DIAMETER node requesting authori- 408 zation and is used in subsequent Resource Management messages to keep 409 the server up to date on the current state of the session. However 410 the Resource Management extension also provides messages for distri- 411 buted back-end servers to share session state information. 413 The Resource Management extension does not provide the ability to 414 create a session. This is handled through another extension's author- 415 ization message. 417 An example of the use of Resource Management is in the Quality of 418 Service area. In the case where a router receives a request from a 419 user to reserve bandwidth on the network, a DIAMETER Bandwidth 420 request is issued to the DIAMETER Server. In the request is a 421 Session-Id along with information about the reservation being 422 requested. 424 The server first authenticates the user, then authorizes the request. 425 If successfully authorized the server keeps a snapshot of the session 426 and generates a token. Then token contains information about the 427 resources allocated and is signed by the server. The token is essen- 428 tially an opaque blob and is not meant to be interpreted by the 429 client. 431 When the user decides to free the bandwidth, the router issues a 432 request to the DIAMETER server to release the resources associated 433 with the Session Identifier. 435 The following capabilities are required for a robust Resource Manage- 436 ment extension: 438 - Associating resources with clients. 440 - Identifying when a session is terminated. 442 - Session termination request by servers. 444 - State update/refresh from the client or other servers. 446 Since the server must keep an accurate state of each active session, 447 it is necessary to have a messages that is sent by the DIAMETER 448 client to notify the server when a session is terminated. 450 State update and refresh is very important in the case where the 451 server has lost state information (i.e. reboot). The server must be 452 able to request information about a specific session as well as a 453 generic request to retrieve all state information. For services that 454 require fault tolerance, servers should share state information. 456 The server must be able to request that a client terminate a session. 457 This is required in services where policy can pre-empt a low priority 458 session. 460 As discussed above, upon authorization of a session the server gen- 461 erates and returns to the DIAMETER client a resource token. Upon 462 receipt of a state update request by the server, the client must send 463 resource tokens for the requested sessions. Therefore the token must 464 contain enough information about the session to allow the server to 465 rebuild session state information. 467 Furthermore since state information is shared amongst servers it is 468 required that each session have a universally unique session 469 identifier associated with it that is assigned by the client. 471 2.3 Authentication/Authorization Mechanism 473 DIAMETER was designed to be a flexible AAA protocol that can be used 474 for a wide variety of services and applications. Historically, these 475 applications and services have designed their own authentication 476 mechanisms, ignoring previous IETF work. 478 The DIAMETER protocol will support a set of authentication mechanisms 479 in hopes that most new protocols will attempt to use one of them. In 480 cases where these mechanisms do not fit within the protocol require- 481 ments, or framework, a new authentication mechanism will have to be 482 defined for the protocol, and a method to carry it within the DIAME- 483 TER protocol. The following authentication mechanism must be sup- 484 ported by DIAMETER: 486 - Extensible Authentication protocol (EAP) [10] 487 - Simple Authentication Security Layer (SASL) [11] 488 - Generic Security Service Authentication Program Interface 489 (GSSAPI) [12] 490 - IKE's Extended Authentication (XAUTH) [13] (proposed) 492 It is envisioned that when an authentication request is issued to a 493 DIAMETER server, it also includes a service/application identifier. 494 The DIAMETER server uses the identifier to determine the service or 495 application, which is used to look up the authorization information 496 for the user. 498 This mechanism allows the re-use of existing, standard IETF authenti- 499 cation mechanism for multiple services. Any service or application 500 that makes use of one of these methods needs to specify its DIAMETER 501 Extension identifier as well as the authorization information that 502 must be present in the request and the response. 504 As previously mentioned, other protocols that must create their own 505 authentication mechanisms must define how the authentication is car- 506 ried in the DIAMETER protocol, and how it is handled by the server. 507 An example is the Mobile IP protocol [7]. A separate authentication 508 method was designed for this protocol because it required minimal 509 traversals through the internet [15]. The document [13] defines how 510 this is carried within the DIAMETER protocol, as well as the authori- 511 zation information that is required. 513 2.4 Accounting Extension 514 The Accounting Extension defines the messages used for service 515 accounting. The accounting extension MUST provide the following func- 516 tionality (a separate effort is in place to define the exact require- 517 ments of the accounting extension): 519 - Negotiable transfer mechanism. 521 - Provide general purpose AVPs. 523 - Flexible to allows new extensions to use the accounting exten- 524 sion. 526 - Scalable to allows millions to users and thousands of sites. 528 - Secure accounting data transfer. 530 The accounting extension must be able to transfer accounting records 531 in an event-driven or batch manner. The selected transfer mechanism 532 must be negotiable, and it must be possible to initiate batch 533 transfer from either peer. 535 Other detailed requirements call for supporting service name/id, 536 amount and length of attributes. 538 It must also be flexible to work in many applications areas. This 539 requires extensibility, application defined level of security, 540 minimal storage and code size requirements, and the ability to work 541 in both real-time and non-real time situations. 543 The accounting protocol must be scalable to the size of global 544 shared-use networks with millions of users and thousands of sites and 545 accounting systems. Transmission, header, and security overhead MUST 546 be amortized over several accounting records. Only a per-entity state 547 needs to be held by the accounting systems (as opposed to a per- 548 session state). 550 The accounting protocol must be secure. End-to-end and hop-by-hop 551 integrity and confidentiality, data-based access control are all 552 needed. Standard Internet security protocols are to be used where 553 possible. 555 2.5 DIAMETER Command Naming Conventions 557 The following conventions are proposed for the naming of Diameter 558 messages. 560 Diameter commands typically start with an object name, and end with 561 one of the following verbs: 563 2.5.1 Request/Response 565 Request is used when the command is asking the peer to do something 566 for it, for example, set up a session, or reconfigure some parame- 567 ters. The Response usually contains either a positive or negative 568 result code, telling the requester whether or not the request suc- 569 cessfully occurred. Other information can also be returned in the 570 Response. 572 For example, AA-Request asks the peer device to authorize and/or 573 authenticate a user in order to set up a session. The request may 574 fail, thus the response may be positive or negative. 576 2.5.2 Query/Response 578 Query is used when the command is asking for information that it 579 expects the peer to have. An example would be querying for current 580 configuration information, or querying for information on resources 581 or sessions in use. The Response usually contains a positive result 582 code and the information, or a negative result code with the reason 583 for not answering the query. 585 For example, Resource-Query requests the peer device to return 586 specific information about one or more resources. The answer is 587 returned in a Resource-Response. 589 2.5.3 Indication 591 Indication is used when the command is giving information on some- 592 thing that is about to or has already occurred. The peer receiving 593 the message does not respond to the message, but a transport level 594 acknowledgement must be done in order to ensure that the message was 595 reliably delivered. 597 For example the base draft defines a message that is used to ensure 598 that a peer is still active. This is achieve with the Watchdog-Ind 599 message, which is acknowledged either by TCP, or using a DIAMETER 600 message acknowledgement as defined in [17]. 602 3.0 Why not LDAP? 604 One common question is whether LDAP would provide the functionality 605 required. 607 A Server MAY wish to access policies using LDAP, but the use of LDAP 608 between the client and the server is not possible. The use of LDAP in 609 this case would require that all routers have read/write access to 610 the directory. Most customers would not accept this requirements and 611 it is not efficient. 613 In the case of roaming, customers would have to open up their direc- 614 tory so outside routers have writeable access. The security implica- 615 tions set aside, having 1000's of routers constantly read/write to 616 the directory would cause some additional problems to the Directory 617 Service. 619 Finally, LDAP does not provide server initiated messages which is a 620 requirement for an AAA protocol. 622 4.0 References 624 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 626 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location 627 Protocol", RFC-2165, June 1997. 629 [3] Aboba, Zorn, "Roaming Requirements", draft-ietf-roamops- 630 roamreq-08.txt, March 1998. 632 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 634 [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based 635 Admission Control", draft-ietf-rap-framework-00.txt, IETF 636 Work in Progress, November 1997. 638 [6] Masinter, "Terminology and Goals for Internet Fax", 639 draft-ietf-fax-goals-02.txt, IETF Work in Progress, 640 March 1998. 642 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 643 1996. 645 [8] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 646 Message Authentication", RFC 2104, January 1997. 648 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 649 Levels", BCP 14, RFC 2119, March 1997. 651 [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol 652 (EAP)", RFC 2284, March 1998. 654 [11] J. Meyes, "Simple Authentication and Security Layer (SASL)", 655 RFC 2222, October 1997. 657 [12] J. Linn, "Generic Security Service Application Program 658 Interface, Version 2", RFC 2078, January 1997. 660 [13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", 661 draft-calhoun-diameter-mobileip-01.txt, IETF Work in 662 Prgress, November 1998. 664 [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and 665 EDI Law", Prentice-Hall, ISBN 0-471-53135-9. 667 [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent 668 Challenge/Response Extension", 669 draft-ietf-mobileip-challenge-00.txt, IETF Work in progress, 670 November 1998. 672 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" 673 RFC 1409, November 1998. 675 [17] P. Calhoun, A. Rubens, "Reliable Transport Extensions", 676 draft-calhoun-diameter-reliable-00.txt, IETF Work in 677 Progress, November 1998. 679 5.0 Acknowledgements 681 The Authors would like to thanks Bernard Aboba and Jari Arkko for 682 their Accounting Requirements contribution. Thanks also goes to Erik 683 Guttman for some very useful comments in helping make this draft more 684 readable. 686 6.0 Author's Address 688 Questions about this memo can be directed to: 690 Pat R. Calhoun 691 Sun Laboratories, Network and Security 692 Sun Microsystems, Inc. 693 15 Network Circle 694 Menlo Park, California, 94025 695 USA 697 Phone: 1-650-786-7733 698 Fax: 1-650-786-6445 699 E-mail: pcalhoun@eng.sun.com 701 Glen Zorn 702 Microsoft Corporation 703 One Microsoft Way 704 Redmond, WA 98052 705 USA 707 Phone: 1-425-703-1559 708 E-Mail: glennz@microsoft.com 710 Ping Pan 711 Bell Laboratories 712 Lucent Technologies 713 101 Crawfords Corner Road 714 Holmdel, NJ 07733 715 USA 717 Phone: 1-732-332-6744 718 E-mail: pingpan@dnrc.bell-labs.com.fi 720 Appendix A. "Drinks" Policy Extension 722 This section is provided as an example only and is intended to provide 723 the reader with a better understanding of how DIAMETER could be used 724 by services. 726 This protocol will provide authentication, authorization and accounting 727 services for bar customers. Each user will be provided with a smart card 728 that contains the user's identity and private key. 730 When a user enters a bar he may use the automated facility by inserting 731 his card into a card slot and wait for the appropriate retina scan to be 732 performed. The user also selects a drink, and may simply hit the "favorite 733 drink" button on the machine. 735 The DIAMETER Client then issues the authentication request to the Server 736 which authenticates the user. The message MUST contain a unique session 737 identifier that will be used while the user is present in the bar. The 738 authentication phase consists of a check that the key and retina scan 739 matches the user's identity and that the user is of age (this is a local 740 decision since each state has different minimum age requirements). 742 If the user is successfully authenticated the server adds authorization 743 information. Authorization information MAY include the user's favorite 744 drinks, whether the user's martini should be shaken or stirred, any 745 known allergic reactions to peanuts or other assorted snacks, etc. 747 Upon receipt of the response, the DIAMETER client dispenses the drink 748 to the customer and generates and accounting request to the DIAMETER 749 accounting server (which MAY be different from the authentication and 750 authorization server). 752 Since the Policy server adapts itself according to the user's drinking 753 habits, it knows how often to send a message to the DIAMETER Client to 754 offer another drink to the customer. Since the policy server also knows 755 about the user's favorite drinks, it may even "suggest" a list of 756 drinks to the user periodically. This is achieved using the Resource 757 Management extensions defined earlier. 759 When the user wishes to order a new drink, the same mechanism occurs as 760 defined above, but the Session Identifier is constant. When the user 761 leaves the bar, the DIAMETER Client sends a message to the server 762 stating that it is terminating a session (based on the Session Id).