idnits 2.17.1 draft-calhoun-diameter-framework-00.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-19) 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 13 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 13 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 455, 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-00.txt Glen Zorn 5 Date: May 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 view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Abstract 34 As the number of new internet services has increased in the past cou- 35 ple of years, routers and network access servers (NAS) have had to 36 undergo re-engineering to support them. 38 These new services could often benefit from an Authentication, 39 Authorization and Accounting (AAA) protocol to facilitate off-loading 40 policy information to an external server. 42 The DIAMETER protocol defines a policy protocol used by clients to 43 perform Policy, AAA and Resource Control. This allows a single server 44 to handle policies for many services. 46 Table of Contents 48 1.0 Introduction 49 1.1 Terminology 50 1.2 Specification Language 51 2.0 DIAMETER Architecture 52 2.1 DIAMETER Base Protocol 53 2.1.1 DIAMETER Security 54 2.2 Resource Management Extension 55 2.3 Accounting Extension 56 2.5 QOS Extension 57 2.6 Mobile IP Extension 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 1.2 Specification Language 120 In this document, several words are used to signify the requirements 121 of the specification [8]. These words are often capitalized. 123 MUST This word, or the adjective "required", means that 124 the definition is an absolute requirement of the 125 specification. 127 MUST NOT This phrase means that the definition is an absolute 128 prohibition of the specification. 130 SHOULD This word, or the adjective "recommended", means 131 that, in some circumstances, valid reasons may exist to 132 ignore this item, but the full implications must be 133 understood and carefully weighed before choosing a 134 different course. Unexpected results may result 135 otherwise. 137 MAY This word, or the adjective "optional", means that this 138 item is one of an allowed set of alternatives. An 139 implementation which does not include this option MUST 140 be prepared to interoperate with another implementation 141 which does include the option. 143 2.0 DIAMETER Architecture 145 The Base DIAMETER Architecture consists of three modules, which 146 defines a small set of primitives that MUST be implemented by all 147 DIAMETER entities. 149 Many applications require that the policy server maintain session 150 state information. The Resource Management extension provides this 151 capability between client and a server as well as between two 152 servers. 154 Most services using DIAMETER require accounting. The current IETF's 155 standard protocol for accounting is SNMP, but experience indicates 156 that SNMP often is not the correct protocol for service accounting. 157 Many applications and services use RADIUS Accounting [4] as their 158 accounting protocol, however RADIUS accounting is not a standard pro- 159 tocol and is informational only. A standard accounting protocol is 160 required. 162 The following diagram provides a representation of the DIAMETER 163 Architecture. As an example, a fictional Policy Extension has been 164 added to the architecture. This fictional service is described here 165 in order to to illustrate how a service could make use of DIAMETER. 167 +------------+ 168 | Policy | 169 | | 170 | Extension | 171 +------------+ 172 +------------+ / \ +------------+ 173 | Resource | | | Accounting | 174 | | | | | 175 | Management | | | Extension | 176 +------------+ | +------------+ 177 / \ | / \ 178 | | | 179 \ / \ / \ / 180 +--------------------------------------------------+ 181 | | 182 | DIAMETER Base Protocol | 183 | | 184 +--------------------------------------------------+ 185 Figure 1: DIAMETER Protocol Architecture 187 Design direction for more extensions will be taken from the user (ISP 188 and network operations) community. 190 2.1 DIAMETER Base Protocol 192 The Base Protocol defines a set of primitives and the security model 193 used between DIAMETER peers. The following goals motivate the defini- 194 tion of the base protocol: 196 - Base protocol MUST be lightweight and simple to implement. 198 - Allow unsolicited messages from the Policy Server to the client. 200 - Feature discovery. 202 - Version negotiation. 204 - unsupported extension notification instead of silent discard. 206 - Efficient encoding of Attributes. 208 - The AVP address space MUST be large (i.e. 32 bits) 210 - The protocol MUST ensure that 32 bit alignment is observed. 212 - Support for vendor specific AVPs and Commands. 214 - The protocol MUST support both TCP and UDP. 216 - client to server as well as server to server communication (as 217 in figure 2) is needed. 219 - Authentication and privacy for policy messages. 221 - Communication with a DIAMETER entity through an intermediate 222 DIAMETER entity. 224 Feature Discovery is intended to dramatically reduce the administra- 225 tive overhead associated with Policy Server configuration. A DIAMETER 226 client can use the a DIAMETER service-type request over SLP [2] to 227 locate Policy Servers within the network, and then a set of DIAMETER 228 messages to retrieve the supported extensions. 230 DIAMETER version negotiation will also reduce the administrative 231 overhead in policy server configuration. DIAMETER entities SHOULD 232 agree to use the higher DIAMETER protocol version number that they 233 commonly support. 235 UDP is preferable for policy applications that require "fine tuned" 236 retransmission strategies. For applications that require support for 237 larger messages and are not as concerned with the retransmission 238 policy, TCP can be used. Each individual extension may specify the 239 underlying transport requirements. 241 As mentioned above, DIAMETER supports server to server communication 242 (see figure 2). Servers can either belong to the same administrative 243 domain, or they may belong to different domains. This is commonly 244 called "proxying" DIAMETER requests, where a proxy server is used in 245 order to reach the end policy server. This functionality is described 246 in [3] and has many different applications besides Internet dial-up 247 access. 249 +--------+ +--------+ 250 | proxy | | policy | 251 | policy |<--------------->| | 252 | server | server-server | server | 253 +--------+ communication +--------+ 254 / /|\ 255 / | client-server 256 / | communication 257 |/_ \|/ 258 +--------+ +--------+ 259 | router | | router | 260 +--------+ +--------+ 261 Figure 2: Client through a Proxy Server 263 2.1.1 DIAMETER Security 265 The protocol presents three different security methods. The first and 266 most obvious method requires no security and can be used with IPSEC. 268 The second method is to make use of shared secrets between two enti- 269 ties. In this case the protocol could include an HMAC-MD5-96 [8] 270 Integrity Check Vector (ICV) within an AVP to provide integrity of 271 the message. 273 Figure 3 depicts an example of Hop-by-Hop security where Policy 274 Server 1 (PS1) and Proxy Server 2 (PS2) share a secret as well as PS2 275 and Policy Server 3 (PS3). In this example PS1 sends a message to PS3 276 through PS2 with an ICV that is computed using the secret it shares 277 with PS2. Upon receipt of the message, PS2 validates the ICV, removes 278 it and adds an ICV that is computed using the secret it shares with 279 PS3. This is commonly called Hop-by-Hop security since it does not 280 provide message integrity between PS1 and PS3. 282 The third method, called End-to-End security, allows a DIAMETER 283 entity to communicate with a Server through a set of intermediate 284 Proxies (see figure 3). In this case the initiator MUST sign the 285 message using public key cryptography since it is the only way for 286 the end server to ensure that a proxy has not modified the original 287 message. 289 +----------+ +----------+ 290 | policy |<--------------->| proxy | 291 | server 1 | server-server | server 2 | 292 +----------+ communication +----------+ 293 /|\ 294 | server-server 295 | communication 296 \|/ 297 +----------+ 298 | policy | 299 | server 3 | 300 +----------+ 301 Figure 3: Proxy Server Communication 303 If certificates are not statically configured or retrieved through 304 some other means (i.e. Certificate Authority), it requires that both 305 the client and the server exchange certificates as part of the DIAME- 306 TER bootstrap protocol. 308 For both the second and the third method the base protocol MUST pro- 309 vide replay protection. 311 2.2 Resource Management Extension 313 The Resource Management Extension enables Servers to maintain session 314 state information. Many applications require the policy server to 315 make decisions not only based on a static policy, but also based on 316 network events. 318 The Resource Management Extension allows a client and server to 319 exchange state information as well as two Servers. Some servers may 320 also use a distributed back-end database to share state information. 322 The Resource Management extension does not provide a message to 323 create a session. This is handled through an extension's authoriza- 324 tion response message. 326 An example would be when the server authorizes the allocation of 327 bandwidth through a successful response message. A response message 328 would then create state information within the client and the server 329 that can be handled through the resource management extensions at a 330 later time, using the session identifier assigned to the session. 332 The following abilities supported by the Resource Management exten- 333 sion: 335 - Associating resources with clients. 337 - Identifying when a session is terminated. 339 - Session termination by servers. 341 - State update/refresh from the client or other servers. 343 In order for the server to maintain accurate state information, it 344 MUST be notified when a session is terminated. 346 State update and refresh is very important in the case where the 347 server has lost state information (i.e. reboot). The server MUST be 348 able to request information about a specific session as well as a 349 generic request to retrieve all state information. For services that 350 require fault tolerance, servers SHOULD share state information. 352 The server must be able to request that a client terminate a session. 353 This is required in services where policy can pre-empt a low priority 354 session. 356 Because multiple servers need to share state information, the server 357 MUST generate resource tokens. These resource tokens are returned by 358 the server at authorization time by the appropriate extension. The 359 resource token is sent by the client to the server when it receives a 360 request for a state update, and must contain enough information for 361 the server to rebuild session state information. 363 Furthermore since state information is shared amongst servers it is 364 required that each session have a universally unique session identif- 365 ier associated with it that is assigned by the client. 367 2.3 Accounting Extension 369 The Accounting Extension defines the messages used for service 370 accounting. The accounting extension MUST provide the following func- 371 tionality (a separate effort is in place to define the exact require- 372 ments of the accounting extension): 374 - Negotiable transfer mechanism. 376 - Provide general purpose AVPs. 378 - Flexible to allows new extensions to use the accounting 379 extension. 381 - Scalable to allows millions to users and thousands of sites. 383 - Secure accounting data transfer. 385 The accounting extension must be able to transfer accounting records 386 in an event-driven or batch manner. The selected transfer mechanism 387 must be negotiable, and it must be possible to initiate batch 388 transfer from either peer. 390 The extension MUST Support accounting finite and infinite sessions as 391 well indivisible events. Other detailed requirements call for sup- 392 porting service name/id, amount and length of attributes. 394 It must also be flexible to work in many applications areas. This 395 requires extensibility, application defined level of security, 396 minimal storage and code size requirements, and the ability to work 397 in both real-time and non-real time situations. 399 The accounting protocol must be scalable to the size of global 400 shared-use networks with millions of users and thousands of sites and 401 accounting systems.Transmission, header, and security overhead MUST 402 be amortized over several accounting records. Only a per-entity state 403 needs to be held by the accounting systems (as opposed to a per- 404 session state). 406 The accounting protocol must be secure. End-to-end and hop-by-hop 407 integrity and confidentiality, data-based access control are all 408 needed. Standard Internet security protocols are to be used where 409 possible. 411 3.0 Why not LDAP? 413 Many people have asked whether LDAP would provide the functionality 414 required. 416 A Server MAY wish to access policies using LDAP, but the use of LDAP 417 between the client and the server is not possible. The use of LDAP in 418 this case would require that all routers have write access to the 419 directory. Most customers would not accept this requirements and it 420 is not efficient. 422 In the case of roaming, customers would have to open up their direc- 423 tory so outside routers have writeable access. Moreover, having 424 1000's of routers constantly write to the directory would cause some 425 additional problems to the Directory Service. 427 Finally, LDAP does not provide server initiated messages which is a 428 requirement for an AAA protocol. 430 4.0 References 432 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 434 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location 435 Protocol", RFC-2165, June 1997. 437 [3] Aboba, Zorn, "Roaming Requirements", draft-ietf-roamops- 438 roamreq-08.txt, March 1998. 440 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 442 [5] Yavatkar, Pendarakis, Guerin, "A Framework for Policy-based 443 Admission Control", draft-ietf-rap-framework-00.txt, 444 November 1997. 446 [6] Masinter, "Terminology and Goals for Internet Fax", 447 draft-ietf-fax-goals-02.txt, March 1998. 449 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 450 1996. 452 [8] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for 453 Message Authentication", RFC 2104, January 1997. 455 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 456 Levels", BCP 14, RFC 2119, March 1997. 458 5.0 Acknowledgements 460 The Authors would like to thanks Bernard Aboba and Jari Arkko for 461 their Accounting Requirements contribution. 463 6.0 Author's Address 465 Questions about this memo can be directed to: 467 Pat R. Calhoun 468 Technology Development 469 Sun Microsystems, Inc. 470 15 Network Circle 471 Menlo Park, California, 94025 472 USA 474 Phone: 1-650-786-7733 475 Fax: 1-650-786-6445 476 E-mail: pcalhoun@eng.sun.com 478 Glen Zorn 479 Microsoft Corporation 480 One Microsoft Way 481 Redmond, WA 98052 482 USA 484 Phone: 1-425-703-1559 485 E-Mail: glennz@microsoft.com 487 Ping Pan 488 IBM T. J. Watson Research Center 489 30 Saw Mill River Road, 490 Hawthorne, NY 10532 492 Phone: 1-914-784-6579 493 Fax: 1-914-784-6205 494 E-mail: pan@watson.ibm.com 496 Appendix A. "Drinks" Policy Extension 498 This section is provided as an example only and is intended to pro- 499 vide the reader with a better understanding of how DIAMETER could be 500 used by services. 502 This protocol will provide authentication, authorization and account- 503 ing services for bar customers. Each user will be provided with a 504 smart card that contains the user's identity and private key. 506 When a user enters a bar he may use the automated facility by insert- 507 ing his card into a card slot and wait for the appropriate retina 508 scan to be performed. The user also selects a drink, and may simply 509 hit the "favorite drink" button on the machine. 511 The DIAMETER Client then issues the authentication request to the 512 Server which authenticates the user. The message MUST contain a 513 unique session identifier that will be used while the user is present 514 in the bar. The authentication phase consists of a check that the key 515 and retina scan matches the user's identity and that the user is of 516 age (this is a local decision since each state has different minimum 517 age requirements). 519 If the user is successfully authenticated the server adds authoriza- 520 tion information. Authorization information MAY include the user's 521 favorite drinks, whether the user's martini should be shaken or 522 stirred, any known allergic reactions to peanuts or other assorted 523 snacks, etc. 525 Upon receipt of the response, the DIAMETER client dispenses the drink 526 to the customer and generates and accounting request to the DIAMETER 527 accounting server (which MAY be different from the authentication and 528 authorization server). 530 Since the Policy server adapts itself according to the user's drink- 531 ing habits, it knows how often to send a message to the DIAMETER 532 Client to offer another drink to the customer. Since the policy 533 server also knows about the user's favorite drinks, it may even "sug- 534 gest" a list of drinks to the user periodically. This is achieved 535 using the Resource Management extensions defined earlier. 537 When the user wishes to order a new drink, the same mechanism occurs 538 as defined above, but the Session Identifier is constant. When the 539 user leaves the bar, the DIAMETER Client sends a message to the 540 server stating that it is terminating a session (based on the Session 541 ioni