idnits 2.17.1 draft-calhoun-diameter-framework-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 33 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 34 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1352, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1359, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2486 (ref. '3') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2139 (ref. '4') (Obsoleted by RFC 2866) == Outdated reference: A later version (-06) exists of draft-ietf-aaa-acct-00 ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- No information found for draft-arkko-acctreq - is the name correct? ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-05 ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-07 == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-09 ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-14 -- No information found for draft-ietf-mobileip-cellular-requirements- - is the name correct? -- No information found for draft-roamops-acctng - is the name correct? ** Obsolete normative reference: RFC 2560 (ref. '25') (Obsoleted by RFC 6960) == Outdated reference: A later version (-07) exists of draft-calhoun-diameter-strong-crypto-03 == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-07 == Outdated reference: A later version (-08) exists of draft-calhoun-diameter-res-mgmt-03 == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-03 ** Obsolete normative reference: RFC 1825 (ref. '31') (Obsoleted by RFC 2401) Summary: 17 errors (**), 0 flaws (~~), 17 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Informational Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-framework-07.txt Glen Zorn 4 Date: April 2000 Cisco Systems, Inc. 5 Ping Pan 6 Bell Labs 7 Haseeb Akhtar 8 Nortel Networks 10 DIAMETER Framework Document 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 This document is an individual contribution for consideration by the 34 AAA Working Group of the Internet Engineering Task Force. Comments 35 should be submitted to the diameter@diameter.org mailing list. 37 Distribution of this memo is unlimited. 39 Copyright (C) The Internet Society 1999. All Rights Reserved. 41 Abstract 43 Current Internet Service Providers (ISPs) scale their networks by 44 using the RADIUS protocol, which provides user Authentication, 45 Authorization and Accounting (AAA) of Dial-up PPP clients. The recent 46 work done in the Roaming Operations (ROAMOPS) Working Group was to 47 investigate whether RADIUS could be used in a roaming network, and 48 concluded that RADIUS was ill-suited for inter-domain purposes. 50 The IETF has formed a new NAS Requirements Working Group, and part of 51 their charter is to document the next generation NAS' AAA 52 requirements. Recently, the Mobile-IP Working Group also documented 53 their own AAA requirements that would help Mobile IP scale for 54 Inter-Domain mobility. 56 The DIAMETER protocol is a follow-on to the RADIUS protocol. DIAMETER 57 addresses the known RADIUS deficiencies, and is intended for use with 58 the NASREQ, ROAMOPS and Mobile IP application space. 60 Table of Contents 62 1.0 Introduction 63 1.1 Requirements language 64 1.2 Terminology 65 2.0 Problems to be addressed 66 2.1 Strict limitation of attribute data 67 2.2 No documented retransmission procedure 68 2.3 Inability to control flow to servers 69 2.4 End to end message acknowledgment 70 2.5 No retransmission procedure 71 2.6 Heavy processing cost 72 2.7 Silent discarding of packets 73 2.8 No fail-over server support 74 2.9 client/server protocol 75 2.10 No unsolicited messages 76 2.11 Authentication Replay Attacks 77 2.12 Hop-by-Hop security 78 2.13 No support for vendor-specific commands 79 2.14 No alignment requirements 80 3.0 DIAMETER Architecture 81 3.1 DIAMETER Base Protocol 82 3.1.1 Proxy Support 83 3.1.2 Broker Support 84 3.2 Strong Security Extension 85 3.3 Mobile-IP Extension 86 3.4 NASREQ Extension 87 3.5 Accounting Extension 88 3.6 Resource Management 89 3.7 DIAMETER Command Naming Conventions 90 3.7.1 Request/Answer 91 3.7.2 Query/Response 92 3.7.3 Indication 93 4.0 Why not LDAP? 94 5.0 References 95 6.0 Acknowledgements 96 7.0 Author's Addresses 97 8.0 Full Copyright Statement 99 1.0 Introduction 101 Historically, the RADIUS protocol has been used to provide AAA 102 services for dial-up PPP [17] and terminal server access. Over time, 103 routers and network access servers (NAS) have increased in complexity 104 and density, making the RADIUS protocol increasingly unsuitable for 105 use in such networks. 107 The Roaming Operations Working Group (ROAMOPS) has published a set of 108 specifications [19, 20, 21] that define how a PPP user can gain 109 access to the Internet without having to dial into his/her home 110 service provider's modem pool. This is achieved by allowing service 111 providers to cross-authenticate their users. Effectively, a user can 112 dial into any service provider's point of presence (POP) that has a 113 roaming agreement with his/her home Internet service provider (ISP), 114 the benefit being that the user does not have to incur a long 115 distance charge while traveling, which can sometimes be quite 116 expensive. 118 Given the number of ISPs today, ROAMOPS realized that requiring each 119 ISP to set up roaming agreements with all other ISPs did not scale. 120 Therefore, the working group defined a "broker", which acts as an 121 intermediate server, whose sole purpose is to set up these roaming 122 agreements. A collection of ISPs and a broker is called a "roaming 123 consortium". There are many such brokers in existence today; many 124 also provide settlement services for member ISPs. 126 The Mobile-IP Working Group has recently changed its focus to cross- 127 domain mobility, which is a requirement for cellular carriers wishing 128 to deploy IETF-based mobility protocols. The current cellular 129 carriers requirements [22, 23] are very similar to the ROAMOPS model, 130 with the exception that the access protocol is Mobile-IP [2] instead 131 of PPP. 133 The DIAMETER protocol was not designed from the ground up. Instead, 134 the basic RADIUS model was retained while fixing the flaws in the 135 RADIUS protocol itself. DIAMETER does not share a common protocol 136 data unit (PDU) with RADIUS, but does borrow sufficiently from the 137 protocol to ease migration. 139 The basic concept behind DIAMETER is to provide a base protocol that 140 can be extended in order to provide AAA services to new access 141 technologies. Currently, the protocol only concerns itself with 142 Internet access, both in the traditional PPP sense as well as taking 143 into account the ROAMOPS model, and Mobile-IP. 145 Although DIAMETER could be used to solve a wider set of AAA problems, 146 we are currently limiting the scope of the protocol in order to 147 ensure that the effort remains focussed on satisfying the 148 requirements of network access. Note that a truly generic AAA 149 protocol used by many applications might provide functionality not 150 provided by DIAMETER. Therefore, it is imperative that the designers 151 of new applications understand their requirements before using 152 DIAMETER. 154 1.1 Requirements language 156 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 157 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 158 described in [9]. 160 1.2 Terminology 162 Accounting 163 The act of collecting information on resource usage for the 164 purpose of trend analysis, auditing, billing, or cost allocation. 166 Authentication 167 The act of verifying the identity of an entity (subject). 169 Authorization 170 The act of determining whether a requesting entity (subject) will 171 be allowed access to a resource (object). 173 AVP 174 The DIAMETER protocol consists of a header followed by objects. 175 Each object is encapsulated in a header known as an Attribute- 176 Value-Pair. 178 Broker 179 Although a DIAMETER proxy provides routing of DIAMETER 180 authentication, authorization and accounting requests, a broker 181 provides DIAMETER message routing while preserving strong 182 security. A DIAMETER broker can also provide redirect services by 183 providing a requesting DIAMETER server the information necessary 184 to contact a target server directly. 186 DIAMETER Client 187 The DIAMETER Client is the device that users contact in order to 188 get access to the network. An example of a client would be a 189 Network Access Server (NAS) and a Foreign Agent (FA). 191 DIAMETER Server 192 The DIAMETER server is the device that provides for authentication 193 and authorization of a user or node requesting access to the 194 network. The DIAMETER Server also collects accounting information 195 for authenticated sessions. 197 Home Domain 198 This is the Internet service provider or corporate network with 199 whom the user maintains an account relationship. 201 Integrity Check Value (ICV) 202 An Integrity Check Value is an unforgeable or secure hash of the 203 message with a shared secret. 205 Interim accounting 206 An interim accounting message provides a snapshot of usage during 207 a user's session. It is typically implemented in order to provide 208 for partial accounting of a user's session in the event of a 209 device reboot or other network problem that prevents the reception 210 of a session summary message or session record. 212 Session record 213 A session record represents a summary of the resource consumption 214 of a user over the entire session. Accounting gateways creating 215 the session record may do so by processing interim accounting 216 events or accounting events from several devices serving the same 217 user. 219 Local Domain 220 This is the Internet service provider whom the user uses in order 221 to get access. Where roaming is implemented the local ISP may be 222 different from the home ISP. 224 Network Access Identifier 225 In order to provide for the routing of DIAMETER authentication and 226 accounting requests, the userID field used in PPP and Mobile IP 227 (known as the Network Access Identifier or NAI) and in the 228 subsequent DIAMETER authentication and accounting requests, can 229 contain structure. This structure provides a means by which the 230 DIAMETER proxy will locate the DIAMETER server that is to receive 231 the request. The NAI is defined in [3]. 233 Proxy Server 234 In order to provide for the routing of DIAMETER authentication and 235 accounting requests, a DIAMETER proxy can be employed. To the NAS, 236 the DIAMETER proxy appears to act as a DIAMETER server, and to the 237 DIAMETER server, the proxy appears to act as a DIAMETER client. 239 Real-time Accounting 240 Real-time accounting involves the processing of information on 241 resource usage within a defined time window. Time constraints are 242 typically imposed in order to limit financial risk. 244 Redirect Services 245 A DIAMETER broker is said to provide redirect services by 246 returning contact information to a requesting DIAMETER server in 247 order to allow it to communicate directly with another server 248 within a roaming consortium. The roaming consortium that allows 249 for redirect services typically also provides certificate 250 authority services in order to allow the end servers to 251 communicate in a secure fashion. 253 Roaming relationships 254 Roaming relationships include relationships between companies and 255 ISPs, relationships among peer ISPs within a roaming association, 256 and relationships between an ISP and a roaming consortia. 257 Together, the set of relationships forming a path between a local 258 ISP's authentication proxy and the home authentication server is 259 known as the roaming relationship path. 261 Session 262 The DIAMETER protocol is session based. When an authentication 263 request is initially transmitted, it includes a session identifier 264 that is used for the duration of the session. The Session- 265 Identifier AVP contains the identifier and must be globally 266 unique. 268 2.0 Problems to be addressed 270 The RADIUS protocol was designed in the early 1990's as an attempt to 271 solve a scaling problem associated with dial-in and telnet servers. 272 Over time the networks became more complex (e.g. roaming networks) 273 and the Network Access Servers (NAS) increased in complexity and 274 density. These changes combined with a massive deployment of the 275 protocol uncovered some fundamental issues with the protocol that 276 needed to be fixed. The DIAMETER protocol was designed as a next 277 generation RADIUS protocol, designed with roaming and high density 278 NASes in mind. 280 This section will describe the documented, and undocumented, RADIUS 281 problems known today. Further sections will describe how the DIAMETER 282 protocol addresses each one of these problems. 284 2.1 Strict limitation of attribute data 286 One of problems that RADIUS suffers from is its inherent limitation 287 on the length of attribute data. This limitation is imposed by the 288 fact that the protocol's attribute header only reserves one byte for 289 the length field. The RADIUS protocol does specify that larger data 290 can be spanned across multiple attributes, however doing so 291 introduces a new set of problems. The RADIUS protocol also allows 292 multiple attributes of the same type to be included within a message. 293 Therefore, it is difficult for a RADIUS server, or client, to 294 determine whether multiple identical attributes are in fact multiple 295 independent attributes, or a single fragmented attribute. 297 2.2 No documented retransmission procedure 299 The RADIUS protocol states that the identifier field, found within 300 the header, is used to identify retransmissions. This one byte field 301 imposes a strict limitation on the number of requests that can be 302 pending at any given time to 255. In the early 1990's, this number 303 was sufficient, but the increased density of most NASes today make 304 the protocol nearly unusable. Most NASes today have fixed this 305 problem by including information in other attributes to bypass this 306 limitation. However, the RADIUS servers have also had to support this 307 change in protocol since they must be able to properly identify 308 retransmissions. The RADIUS protocol also states that the identifier 309 MUST be changed if any data is changed in a request. 311 For this reason, most RADIUS servers keep a cache of received RADIUS 312 request (e.g. all messages received in the last 60 seconds). The 313 RADIUS servers then attempt to match some attributes within the 314 received requests with all attributes in all messages in the cache. 315 This places a very heavy burden on the RADIUS servers, but 316 unfortunately is the only method of identifying retransmissions given 317 the fact that the RADIUS protocol does not have any good scheme. This 318 hack has proved necessary since some NASes have had to change some 319 information within requests in the retransmission queue (such as 320 session length). 322 2.3 Inability to control flow to servers 324 Given the rather bursty nature of the RADIUS protocol, current 325 servers have no way of properly managing their receive buffers. This 326 is in part due to the fact that RADIUS operates over UDP, and does 327 not include any windowing support. This has been known to cause 328 large bursts of requests to be directed to a server, which can burden 329 a server's ability to respond in a timely manner. This problem is 330 most prevalent in cases where a server becomes unavailable and all 331 requests must be sent to an alternate server, or when an ingress port 332 on the NAS becomes available (e.g. T3 port on NAS). 334 2.4 End to end message acknowledgment 336 The RADIUS protocol requires that a NAS retransmit a request until a 337 successful or failed response is received, and does not permit a 338 RADIUS server to retransmit a response. This is problematic since 339 there are many times when a server does receive a request, but cannot 340 respond before the NAS determines that the request must be 341 retransmitted. This can occur for many reasons, including the fact 342 that processing a RADIUS request, which includes authentication and 343 authorization of the user, a database lookup and logging events, can 344 be lengthy. 346 2.5 No retransmission procedure 348 Another reason why NASes typically retransmit is when a SERVER 349 receives a large number of requests, and cannot process all of them 350 in a timely manner. The side effect here is that if the NAS 351 retransmits requests to the server, it simply causes further damage 352 to the busy server. Since the RADIUS server cannot retransmit, some 353 RADIUS servers keep a cache of responses sent in the past 60 seconds 354 in order to minimize processing should a retransmission be received. 355 As previously discussed, identifying a retransmission is a very CPU 356 intensive tasks, but perhaps not quite as intensive as a database 357 lookup. 359 2.6 Heavy processing cost 361 The introduction of proxy RADIUS network have made this 362 acknowledgement scheme even worse, since the end server must respond 363 in a timely manner. Each intermediate RADIUS server adds additional 364 latency to proxied requests due to the application processing cost. 365 This has been known to cause unnecessary retransmission of requests 366 by NASes, which impose heavy burden on the proxies, and the network. 368 When a NAS retransmits a request a maximum number of times, it 369 assumes that the server is no longer available and transmits the 370 message to an alternate server. If there are many messages in the 371 retransmission queue, all other requests are also transmitted to the 372 new server. Since a burst of requests were sent to the server, the 373 chances that it can satisfy all requests before the retransmission 374 period are very small, which causes unnecessary retransmissions. 376 2.7 Silent discarding of packets 378 The RADIUS protocol states that messages that do not contain the 379 expected information, or messages that have errors are silently 380 discarded. Silently discarding messages can create a serious problem 381 since no response is sent to the NAS, which then has to assume that 382 the server is no longer reachable. Since proxy networks are 383 transparent to a NAS, should a server in a proxy chain silently 384 discard a request, it will cause the NAS to assume that the local 385 (first hop) server is no longer available. 387 2.8 No fail-over server support 389 Most NASes today support a large number of RADIUS servers in an 390 attempt to provide resilience. However, the RADIUS protocol itself 391 makes this very difficult due to the problems described above. Since 392 a NAS does not know a priori whether a specific server is available, 393 when it switches to an alternate server, it must retransmit a message 394 a maximum number of times before determining that the server in 395 question is down, and that the next server in the configuration chain 396 must be tried. Taking an example of a NAS with 8 servers configured, 397 if the next 3 servers in the configuration chain were down, it would 398 take the NAS x number of seconds to reach an available server (where 399 x is equal to the retransmission interval * the maximum number of 400 retransmissions * 3), which is most often longer than the clients are 401 willing to wait. 403 Local ISP Home ISP 404 +--------+ +--------+ 405 | Primary| | Primary| 406 +-------+ | Proxy |----------->| Home | 407 | |----------->| Server | | Server | 408 |Network| +--------+ +--------+ 409 |Access | 410 |Server | +--------+ +--------+ 411 | |----------->| 2 nd | | 2 nd | 412 +-------+ | Proxy |----------->| Home | 413 | Server | | Server | 414 +--------+ +--------+ 416 Figure 1: RADIUS Proxy Network 418 2.9 client/server protocol 420 Given that a RADIUS server cannot know a priori whether a downstream 421 RADIUS server is reachable, and the fact that the NAS must retransmit 422 any messages, the RADIUS protocol is not well suited to proxy 423 environments. Since servers are not aware of a peer's reachability, 424 most RADIUS networks are designed by creating parallel links between 425 primary and alternate servers (see figure 1). In this example the 426 local ISP's primary server communicates with the home ISP's primary 427 server, while the 2nd servers communicate directly. When the NAS 428 issues a request to the primary server, the first hop server attempts 429 to proxy the request to the primary server at the home network. The 430 NAS will attempt to retransmit the request n number of times, and the 431 primary server will simply forward the request to the primary server 432 at the home network. 434 Should no response be received, the primary server could attempt to 435 forward the request to the 2nd server at the home network, but since 436 the NAS is controlling the retransmissions, it may not have the 437 opportunity to do so. Therefore, the NAS will redirect all requests 438 to the local ISP's 2nd server. Given the protocol's limitations, it 439 requires a large number of RADIUS servers in order to provide 440 resilient service. 442 The above problem is further aggravated should the local ISP attempt 443 to proxy to two different administrative network's servers. Take an 444 example where the local ISP issues two authentication requests, one 445 for abc.net and another for xyz.com. Let's also assume that abc.net's 446 primary server is down, while xyz's 2nd server is down. Should such a 447 problem occur, all requests for abc.net would cause the NAS to switch 448 to the local ISP's 2nd server, while all requests to xyz.net would 449 cause the NAS to switch back to the local ISP's primary server. This 450 clearly illustrates that the RADIUS protocol cannot be reliably used 451 in proxy networks. 453 2.10 No unsolicited messages 455 The RADIUS protocol does not allow a server to send unsolicited 456 messages to the NAS. As network services became more complex, this 457 limitation has forced manufacturers to break the RADIUS protocol in 458 this area in order to allow servers to communicate with the client. 459 This is widely used for accounting purposes, and to allow a server to 460 inform a NAS that a session should be terminated. Unfortunately, the 461 lack of a standard method of doing this has caused many non- 462 interoperable implementations to be deployed. 464 2.11 Authentication Replay Attacks 466 In today's PPP world, the NAS provides a challenge to the user, which 467 is then computed by the PPP user to create the challenge response. 468 This is commonly known as CHAP [26], and is a popular PPP 469 authentication scheme. Before roaming networks existed, service 470 providers would own both the NAS and the RADIUS server and this 471 wasn't considered a problem. However, now that the NAS and the RADIUS 472 server are owned by two separate administrative domains, the fact 473 that the non-trusted NAS generates a challenge provides the ability 474 for authentication replay attacks. A NAS, or any RADIUS server in a 475 proxy chain, can have access to a valid challenge/response pair, 476 which can be replayed at a later time. 478 The EAP protocol [10], which will be supported as part of RADIUS 479 extensions can solve this problem, but the fact that EAP is not 480 widely deployed on clients, and that many EAP authentication 481 transforms cannot be used within RADIUS (due to the limitation on 482 attribute data size) makes it difficult to use. Furthermore, given 483 the RADIUS protocol's requirement for end-to-end retransmissions, 484 since some EAP authentication types involve a higher number of round 485 trips than what RADIUS currently supports, RADIUS and EAP cannot be 486 used on networks that exhibit data loss. This is primarily due to the 487 fact that most EAP (PPP) clients timeout before the authentication 488 can be completed. 490 2.12 Hop-by-Hop security 492 The RADIUS protocol uses hop-by-hop security, which means that every 493 hop in a RADIUS proxy network adds authentication data that is used 494 by the next peer in the chain. RADIUS has no facility for strong 495 security, where security is maintained from the requestor and the 496 responder, even though a request is handled by intermediate nodes. 497 This has caused opportunities for fraud in RADIUS networks, since 498 intermediate nodes can easily modify information (e.g. accounting 499 information), and such events are untraceable. 501 2.13 No support for vendor-specific commands 503 Although the RADIUS protocol does support vendor-specific attributes, 504 it does not allow for vendor-specific commands. This has caused 505 serious inter-operability problems since vendors simply choose 506 command identifiers at random, which can collide with other 507 manufacturer's implementation. 509 2.14 No alignment requirements 511 Unlike most newer IETF protocols, the RADIUS protocol does not impose 512 any alignment requirements, which adds an unnecessary burden on most 513 processors. All fields within the header and attributes must be 514 treated as byte aligned characters. 516 3.0 DIAMETER Architecture 518 The DIAMETER architecture consists of a base protocol and a set of 519 protocol extensions (such as strong security, NASREQ, Mobile-IP and 520 accounting). Functionality common to all supported services is 521 implemented in the base protocol, while application-specific 522 functionality may be provided through the extension mechanism. 524 The base protocol [18] must be supported for all DIAMETER 525 applications, and defines the basic PDU format, a few primitives and 526 the basic security services offered by the protocol. Unlike RADIUS, 527 the DIAMETER protocol operates over SCTP [28], which provides 528 reliability and an agressive retransmission and timeout mechanism. 529 Additionally, DIAMETER defines a fail-over strategy, which is lacking 530 in the RADIUS protocol. SCTP provides a windowing scheme, which 531 allows the AAA servers to limit the flow of incoming packets. This 532 can then be used by the AAA clients to distribute the traffic load 533 across multiple servers. The transport layer's aggressive 534 retransmission and timeout timers allow clients and servers to detect 535 the reachability state of peers, allowing for quick transition to 536 back-up servers. 538 As previously discussed, the ROAMOPS model introduces the AAA broker, 539 which acts as an intermediate server redirecting requests to user's 540 home ISPs. ROAMOPS also described a set of attacks that one could 541 mount if such a network was built using the RADIUS protocol [21]. In 542 order to provide secure broker services, strong security is required 543 at the application layer, since messages traverse application 544 gateways (brokers). 546 The DIAMETER Strong Security Extension defines a set of extensions to 547 the base protocol that provide authentication, confidentiality and 548 non-repudiation at the Attribute-Value-Pair (AVP) level. With these 549 extensions, it is possible to secure portions of a DIAMETER message, 550 while other parts of the message are not secured. Secured objects are 551 called protected AVPs; non-secured objects are called unprotected 552 AVPs. Using DIAMETER, brokers can add, delete or modify unprotected 553 AVPs in a message. 555 The RADIUS protocol provides dial-up PPP AAA services by providing 556 three commands and many Attributes. Attributes in RADIUS are 557 analogous to AVPs in DIAMETER. In order to ease migration from RADIUS 558 to DIAMETER, the first 256 AVPs in the DIAMETER AVP space are 559 reserved for RADIUS compatibility. This allows both protocols to 560 share a common dictionary and policy rules for PPP user profiles. 561 Recently, the RADIUS protocol adopted support for the Extensible 562 Authentication Protocol (EAP) [10], but RADIUS' lack of support for 563 large attributes and its inherent unreliability has made the 564 integration of the protocols very difficult. 566 The DIAMETER NASREQ Extension defines a set of 567 authentication/authorization commands, which can be used for CHAP, 568 PAP and EAP. DIAMETER's support for larger AVPs and the SCTP 569 transport properties have made the use of EAP much more palatable, 570 allowing for end-to-end user authentication, which reduces many of 571 authentication replay attacks currently documented. 573 Unlike PPP, Mobile-IP hosts do not have a long-lived "nailed-up" 574 connection to a PPP server, but rather get service from routers that 575 provide service in a particular cell. In the Mobile-IP world, the 576 router is known as a Foreign Agent, while the moving hosts are known 577 as Mobile Nodes. The mobile node's home network has a host that 578 forwards all messages destined to the mobile node through the Foreign 579 Agent. This router is commonly referred to as the Home Agent. 581 Mobile-IP [7] allows the mobile nodes to move from one cell (subnet) 582 to another while retaining the same IP address, minimizing the impact 583 to applications. Although the Mobile-IP protocol could be deployed in 584 a small network with any AAA services, a larger network suffers from 585 many scaling issues such as: 587 - Static mobile node home address 588 - Static mobile node home agent 589 - Requirement to pre-configure mobile node profile on home agents 590 - No inter-domain mobility 592 Both PPP and Mobile-IP require that usage data be collected for uses 593 such as capacity planning and for accounting purposes. The current 594 standard protocol for accounting is SNMP [12], but experience 595 indicates that SNMP often is not the correct protocol for service 596 accounting. Today many applications and services use RADIUS 597 accounting [4] as their accounting protocol, however the RADIUS 598 accounting protocol is not an IETF standard; in addition, it suffers 599 from similar scaling and security problems. The DIAMETER accounting 600 extension [11] is designed to allow accounting information to be sent 601 across administrative domains (optionally through brokers), and has 602 been derived from an accounting requirements document [6, 8]. 604 +-----------+ 605 | Mobile-IP | 606 | | 607 | Extension | 608 +-----------+ 609 +-----------+ ^ +------------+ 610 | NASREQ | | | Accounting | 611 | | | | | 612 | Extension | | | Extension | 613 +-----------+ | +------------+ 614 ^ | ^ 615 | | | 616 v v v 617 +----------------------------------+---------------------+ 618 | | | 619 | DIAMETER Base Protocol | Strong Security | 620 | | | 621 +----------------------------------+---------------------+ 622 Figure 2: DIAMETER Protocol Architecture 624 3.1 DIAMETER Base Protocol 626 The Base Protocol defines the DIAMETER message format, a set of 627 primitives and how the messages are transmitted in a secure fashion. 628 The Base Protocol assumes a peer-to-peer communication model, as 629 opposed to a client-server model. The following goals motivated the 630 design of the base protocol: 632 - lightweight and simple to implement protocol 633 - Large AVP space 634 - Efficient encoding of attributes, similar to RADIUS 635 - Support for vendor specific AVPs and Commands 636 - Support for large number of simultaneous pending requests 637 - Reliability provided by underlying SCTP 638 - Well-defined fail-over scheme 639 - Ability to quickly detect unreachable peers 640 - No silent message discards 641 - Support of unsolicited messages to "clients" 642 - integrity and confidentiality at the AVP level 643 - Hop-by-Hop security 644 - One session per authentication/authorization flow 645 - Provide redirect (referal) services, to allow bypassing of 646 broker 648 The DIAMETER base protocol is intended to simply provide a secure 649 transport for the messages defined in the various application- 650 specific extensions. It is therefore imperative that the base be 651 lightweight and simple to implement. 653 In the DIAMETER protocol, data objects are encapsulated within the 654 Attribute Value Pair (AVP). An AVP consists of three parts: the 655 Identifier, Length and Data. A unique AVP Identifier is assigned to 656 all data objects in order to be able to distinguish the data 657 contained. The AVP Identifier namespace must be sufficiently large to 658 ensure that future protocol extensibility is not limited by the size 659 of the namespace, as in the RADIUS protocol. Furthermore, vendors 660 wishing to add "proprietary" extensions must be allowed to do so by 661 using a vendor-specific namespace, managed by IANA. 663 For many years the question as to whether RADIUS should operate over 664 UDP or TCP has led to heated discussion. It must be determined 665 whether the benefits that UDP provides are worth the implementation 666 complexities. Over time, it has become clear that these benefits are 667 well worth the cost. The issue with TCP is that an AAA protocol 668 requires a quick retransmission and fail-over scheme, which TCP 669 cannot provide. The DIAMETER protocol must be able to operate over a 670 transport that has an aggressive retransmission strategy in order to 671 efficiently switch to an alternate host when the peer in question is 672 no longer reachable. 674 Contrary to RADIUS, the DIAMETER protocol requires that each node in 675 a proxy chain acknowledge a request, or response, at the "transport" 676 layer. Since DIAMETER operates over SCTP, which provides a reliable 677 transport, each node in a proxy chain is responsible for 678 retransmission of unacknowledged messages. 680 The SCTP transport provides retransmission detection, which greatly 681 simplifies server implementations, and consequently allows a given 682 server to support a much larger number of transactions per second. 683 SCTP also provides windowing, which allows the flow of packets to a 684 specific server to be controlled. Clever implementations can then 685 decide to send the packets to an alternate server that can handle the 686 load. 688 With the exception of a few security related errors, the DIAMETER 689 protocol requires that all messages be acknowledged, either with a 690 successful response or one that contains an error code. 692 Where the RADIUS protocol is client-server, the DIAMETER protocol is 693 peer to peer, allowing unsolicited messages to be sent to NASes. 694 There are many benefits to peer-to-peer AAA protocols. One example is 695 the on-demand retrieval of accounting data; another, server-initiated 696 session termination. 698 The Base DIAMETER protocol provides for hop-by-hop security, similar 699 to the scheme employed by RADIUS today. However, the DIAMETER 700 protocol also provides for replay protection through a timestamp 701 mechanism. This security scheme requires a long lived security 702 association to be established by peers, or can make use of keying 703 material negotiated out of band. The Base Protocol also allows the 704 built-in security measure to be turned off, (i.e., in cases where 705 IPSec is in use). 707 The DIAMETER protocol is a session-oriented protocol, meaning that 708 for each user being authenticated, there exists a session between the 709 initiator of the authentication/authorization request and the home 710 DIAMETER server. Sessions are identified through a session 711 identifier, which is globally unique at any given time. All 712 subsequent DIAMETER transactions (e.g. accounting) must include the 713 session identifier to reference the session. A Session termination 714 message exists in order to end a DIAMETER session, and all sessions 715 have a timeout value in order to ensure that they can be cleaned up 716 properly. 718 Since today's processors work more efficiently when objects are 719 aligned on a 32-bit boundary, the DIAMETER protocol requires 32-bit 720 alignment of all headers and the data. This has recently become a 721 common requirement for many new protocols at the IETF. 723 3.1.1 Proxy Support 725 The DIAMETER protocol was designed from the beginning to support 726 roaming networks. This means that every node in the network is 727 responsible for it's own retransmissions, and the protocol does allow 728 each node to know a priori the reachability state of each peer. This 729 allows for a resilient network, and efficient retransmission scheme. 730 Figure 3 depicts a network where each DIAMETER server can communicate 731 with all other servers. 733 Figure 3 depicts an example of a DIAMETER network that includes two 734 proxy servers in the local network for resilience. Once a message has 735 been sent from the NAS to one of its local proxy servers, they are 736 responsible for any retransmissions of the message to one of the home 737 servers. Since the underlying transport provides quick peer failure 738 detection, upon such notification, the local proxies can quickly 739 transmit the message to the alternate peer in the home network. 741 Figure 3 depicts an example of a proxy network that includes 742 alternate servers for resilience. Each node in the proxy chain is 743 responsible for its own retransmissions and fail-over detection. 744 This provides the following benefits: 746 - The number of DIAMETER nodes in the network is greatly reduced 747 - The latency involved in switch-over to an alternate peer is 748 greatly reduced 749 - Reliability is increased 751 local ISP Home ISP 752 +--------+ +--------+ 753 | Primary| | Primary| 754 +-------+ | Proxy |------------>| Home | 755 | |----------->| Server |<-----+----->| Server | 756 |Network| +--------+ | +--------+ 757 |Access | | 758 |Server | +--------+ | +--------+ 759 | |----------->| 2 nd |<-----+----->| 2 nd | 760 +-------+ | Proxy |------------>| Home | 761 | Server | | Server | 762 +--------+ +--------+ 764 Figure 3: DIAMETER Proxy Network 766 3.1.2 Broker Support 768 A broker is a proxy server that provides simple DIAMETER message 769 "routing" functions. Brokers are generally deployed in order to 770 reduce the configuration information that would otherwise be 771 necessary on all servers owned by ISPs within a roaming consortium. 772 Brokers can provide two separate functions depending upon the 773 business model. 775 +------------------+ 776 | DIAMETER | 777 | Broker | 778 +------------------+ 779 ^ ^ 780 | | 781 v v 782 +----------+ +----------+ 783 | Local | | Home | 784 | DIAMETER | | DIAMETER | 785 | Server | | Server | 786 +----------+ +----------+ 788 Figure 4: DIAMETER Roaming Consortium 790 The first where the broker forwards messages to the proper 791 destination based on the NAI information (figure 4). In such a 792 network, when the broker receives a request from a DIAMETER server, 793 it determines the message's destination and can optionally perform 794 some authorization decisions based on local policy. 796 The DIAMETER broker's organization can also provide Certificate 797 Authority services, by issuing certificates to all DIAMETER servers 798 within the consortium, or use existing certificates owned by DIAMETER 799 servers. This allows the broker and the DIAMETER servers to 800 communicate in a secure fashion, without the need for long-lived 801 secrets. Protocols such as IP Security [31] can allow for short-lived 802 session keys to be generated and periodically refreshed. 804 The second broker model allows the end DIAMETER servers to directly 805 communicate (figure 5). In this model the broker simply provides 806 redirect services, which is aimed at reducing the amount of 807 configuration that would otherwise be necessary on all end DIAMETER 808 servers. When a DIAMETER servers sends a request the broker, the 809 broker returns contact information that is then used by the 810 requesting server to re-issue the request directly to the home 811 DIAMETER server. In order for the end DIAMETER servers to be able to 812 communicate in a secure fashion, a pre-established security 813 association is required. This can be in the form of a long-lived 814 shared secret, which has scaling problems, or via certificates when 815 the broker's organization provides CA services. In the event that the 816 broker also provides settlement services, it is possible for the 817 accounting information, signed by both parties, to be transmitted to 818 the broker by the server providing service to the user. 820 When the broker provides the message forwarding functions, it can 821 validate that the source and destination DIAMETER servers are in 822 "good standing", which reduces the processing on the end servers. 823 This can be done by having the broker check the server's certificates 824 against a CRL, via an online certificate status protocol [25], or 825 through local configuration. The broker can optionally attach the 826 source server's certificate if it isn't already present in the 827 message. When a broker receives a request from or destined to a 828 domain that is either unrecognized or no longer part of the roaming 829 consortium, an error will be returned to the requesting server. 831 The very fact that the DIAMETER servers in the roaming network do not 832 have to burden themselves with validating certificates against a CRL, 833 or some other certificate validation infrastructure, is a huge 834 advantage. In cases of inter-consortium roaming, the brokers involved 835 can be responsible for validating any certificates involved. Note 836 that it is also possible for the broker to periodically issue new 837 certificates to the roaming consortium members out-of-band in order 838 to eliminate the need to add certificates to each message, decreasing 839 the message size and the per-message processing penalty. 841 +------------------+ +---------+ 842 | DIAMETER | | CRL DB/ | 843 | Broker | | OCSP | 844 +------------------+ +---------+ 845 ^ 846 Request | Response with 847 | Result Code = 848 | Redirect 849 v 850 +----------+ +----------+ 851 | Local | | Home | 852 | DIAMETER |<------------>| DIAMETER | 853 | Server | | Server | 854 +----------+ Direct +----------+ 855 Communication 856 Figure 5: DIAMETER Broker Returning Redirect Indication 858 When the broker provides redirect services, the broker can return 859 both the source and the destination server's certificates. The 860 certificates are encapsulated within a DIAMETER attribute, and 861 include a timestamp, an expiration time all signed by the broker. 862 Should the end server's policy be setup such that they will trust the 863 certificate returned by the broker, they do not have to make any 864 additional certificate validation checks. However, local policy may 865 require that the end DIAMETER servers validate periodically. 867 Note that even though some broker's do allow direct communication, 868 some will require that all accounting messages be forwarded by the 869 broker. This is typically required when the broker also provides 870 settlement services. In such a network, the broker normally requires 871 some reassurances that the user was in fact authenticated and 872 authorized by the home DIAMETER server prior to accepting accounting 873 records. The document [5] defines a method by which the broker can 874 get such reassurances. 876 3.2 Strong Security Extension 878 The DIAMETER base protocol allows DIAMETER servers to communicate 879 securely, using hop-by-hop authentication. Hop-by-hop authentication 880 means that the requesting server has secure communication with the 881 broker, and the broker has secure communicate with the destination 882 server. 884 The Strong Security extension [27] provides strong authentication of 885 selective AVPs, which MAY be used for repudiation purposes. This 886 extension also allows for secure communication through intermediate 887 DIAMETER proxies. 889 The extension achieves this functionality by allowing the 890 Cryptographic Message Syntax (CMS) S/MIME object to be encapsulated 891 within a DIAMETER AVP. The CMS object MAY be used for authentication, 892 confidentiality and to carry certificates and certificate revocation 893 lists (CRLs). The extension also provides for multi-party signatures, 894 which is useful in environments where two or more parties must sign 895 information, such as an accounting record. 897 DIAMETER clients, such as NASes and routers, aren't expected to 898 implement strong security. This specification is targeted for the 899 first hop proxy servers, and this functionality is normally only 900 required when requests must traverse administrative domain 901 boundaries. 903 The strong security extension MUST only be used in networks that 904 include a Public Key Infrastructure (PKI). 906 3.3 Mobile-IP Extension 908 The Mobile-IP protocol is used to manage mobility of an IP host 909 across IP subnets [7]. Recent activity within the Mobile-IP Working 910 Group has defined the interaction between Mobile-IP and AAA in order 911 to provide: 913 - Better scaling of security associations 914 - Mobility across administrative domain boundaries 915 - Dynamic home agent assignment 917 The Mobile IP protocol [7] works well when all mobile nodes belong to 918 the same administrative domain. Some of the current work within the 919 Mobile IP Working Group is to allow Mobile IP to scale across 920 administrative domains. This work requires modifications to the 921 existing Mobile IP trust model. 923 Figure 6 depicts the DIAMETER trust model for Mobile-IP. In this 924 model each network contains mobile nodes (MN) and a DIAMETER server. 925 Each mobility device shares a security association (SA) with the 926 DIAMETER server within its own home network. This means that none of 927 the mobility devices initially share a security association. The 928 DIAMETER servers in both administrative domains can either share a 929 direct security association, or can have a security association with 930 an intermediate broker. 932 Broker AAA 933 +--------+ 934 | | 935 |DIAMETER| 936 +------->| |<-----+ 937 | +--------+ | 938 Local | SA SA | Home 939 AAA v v AAA 940 +--------+ +--------+ 941 | | SA4 | | 942 |DIAMETER|======================|DIAMETER| 943 | |(in lieu of broker or)| | 944 +--------+(in direct comm model)+--------+ 945 ^ ^ ^ 946 | | | 947 SA1 | SA2 | | SA3 948 | | | 949 v v v 950 +--------+ +--------+ +--------+ 951 | | | | | | 952 | FA | | MN | | HA | 953 | | | | | | 954 +--------+ +--------+ +--------+ 955 Figure 6 - Mobile-IP AAA Trust Model 957 Figure 7 provides an example of a Mobile-IP network that includes 958 DIAMETER. In the integrated Mobile-IP/DIAMETER Network, it is assumed 959 that each mobility agent shares a security association between itself 960 and its local DIAMETER server. Further, the Home and Local DIAMETER 961 servers both share a security association with the broker's DIAMETER 962 server. Lastly, it is assumed that each mobile node shares a trust 963 relationship with its home DIAMETER Server. 965 Local Access Broker Home IP 966 Provider Network Network Network 967 +--------+ +--------+ +--------+ 968 | | | | | | 969 |DIAMETER|<---->|DIAMETER|<---->|DIAMETER| 970 | | | | | | 971 +--------+ +--------+ +--------+ 972 ^ ^ 973 | | 974 AAA | | AAA 975 | | 976 v v 977 +---------+ +---------+ 978 | | | | 979 | FA | | HA | 980 | | | | 981 +---------+ +---------+ 982 ^ 983 | Home Network 984 | -Private Network 985 Mobile | -Home Provider 986 IP | -Home ISP 987 v 988 +--------+ 989 | Mobile | 990 | Node | 991 +--------+ 992 Figure 7 - General Wireless IP Architecture for Mobile-IP AAA 994 In this example, a Mobile Node appears within a local network and 995 issues a registration to the Foreign Agent. Since the Foreign Agent 996 does not share any security association with the Home Agent, it sends 997 a DIAMETER request to its local DIAMETER server, which includes the 998 authentication information and the Mobile-IP registration request. 999 The Mobile Node cannot communicate directly with the home DIAMETER 1000 Server for two reasons: 1002 - It does not have access to the network. The registration 1003 request is sent by the Mobile Node to request access to the 1004 network. 1005 - The Mobile Node may not have an IP address, and may be 1006 requesting that one be assigned to it by its home provider. 1008 The Local DIAMETER Server will determine whether the request can be 1009 satisfied locally through the use of the Network Access Identifier 1010 [3] provided by the Mobile Node. The NAI has the form of user@realm 1011 and the DIAMETER Server uses the realm portion of the NAI to identify 1012 the Mobile Node's home DIAMETER Server. If the Local DIAMETER Server 1013 does not share any security association with the Mobile Node's home 1014 DIAMETER Server, it may forward the request to its broker. If the 1015 broker has a relationship with the home network, it can forward the 1016 request, otherwise a failure indication is sent back to the Local 1017 DIAMETER Server. 1019 When the home DIAMETER Server receives the DIAMETER Request, it 1020 authenticates the user and begins the authorization phase. The 1021 authorization phase includes the generation of: 1023 - Dynamic session keys to be distributed among all mobility agents 1024 - Optional dynamic assignment of a home agent 1025 - Optional dynamic assignment of a home address (note this could 1026 be done by the home agent). 1027 - Optional assignment of QOS parameters for the mobile node [22] 1029 Once authorization is complete, the home DIAMETER Server issues an 1030 unsolicited DIAMETER request to the Home Agent, which includes the 1031 information in the original DIAMETER request as well as the 1032 authorization information generated by the home DIAMETER server. The 1033 Home Agent retrieves the Registration Request from the DIAMETER 1034 request and processes it, then generates a Registration Reply that is 1035 sent back to the home DIAMETER server in a DIAMETER response. The 1036 message is forwarded through the broker back to the Local DIAMETER 1037 server, and finally to the Foreign Agent. 1039 The DIAMETER servers maintain session state information based on the 1040 authorization information. If a Mobile Node moves to another Foreign 1041 Agent within the local domain, a request to the local DIAMETER server 1042 can be done in order to immediately return the keys that were issued 1043 to the previous Foreign Agent. This eliminates an additional round 1044 trip through the internet when micro mobility is involved, and 1045 enables smooth hand-off. In order for the DIAMETER server to be able 1046 to provide the keying information to the new Foreign Agent, they must 1047 have a pre-existing security association. 1049 Note that smooth hand-off is really a mobility function, and it is 1050 not clear that DIAMETER should be involved. However, this example is 1051 provided for completeness. 1053 If the Mobile Node enters a service area owned by a new service 1054 provider, the authentication and authorization request will have to 1055 be sent back to the home DIAMETER server, which will create new 1056 keying information. 1058 3.3.1. Minimized Internet Traversal 1059 Although it would have been possible for the DIAMETER interactions to 1060 be performed for basic authentication and authorization, and the 1061 Registration flow to be sent directly to the Home Agent from the 1062 Foreign Agent, one of the key Mobile-IP DIAMETER requirements is to 1063 minimize Internet traversals. Including the Registration Request and 1064 Replies in the DIAMETER messages allows for a single traversal to 1065 authenticate the user, perform authorization and process the 1066 Registration Request. This streamlined approach is required in order 1067 to minimize the latency involved in getting wireless (cellular) 1068 devices access to the network. New registrations should not increase 1069 the connect time more than what the current cellular networks 1070 provide. 1072 3.3.2. Key Distribution 1074 In order to allow the scaling of wireless data access across 1075 administrative domains, it is necessary to minimize the security 1076 associations required. This means that each Foreign Agent does not 1077 share a security association with each Home Agent on the Internet. 1078 The Mobility Agents share a security association with their local 1079 DIAMETER server, which in turn shares a security association with 1080 other DIAMETER servers. Again, the use of brokers (as defined by 1081 ROAMOPS) allows such services to scale by allowing the number of 1082 relationships established by the providers to be reduced. 1084 After a Mobile Node is authenticated, the authorization phase 1085 includes the generation of Sessions Keys. Specifically, three keys 1086 are generated: 1088 - K1 Key to be shared between the Mobile Node and the Home Agent 1089 - K2 Key to be shared between the Mobile Node and the Foreign 1090 Agent 1091 - K3 Key to be shared between the Foreign Agent and the Home Agent 1093 Each key is encrypted in two separate methods. K1 is encrypted using 1094 SA3 (for the Home Agent), and using SA2 (for the Mobile Node). K2 is 1095 encrypted using SA4 (for the Foreign Agent) and using SA2 (for the 1096 Mobile Node). Lastly, K3 is encrypted using SA4 (for the Foreign 1097 Agent), and using SA3 (for the Home Agent). When the Foreign DIAMETER 1098 Server receives the keys, they are decrypted and re-encrypted using 1099 SA1. All of the Security Associations (SAx) are shown in figure 6. 1100 The keys destined for the foreign and home agent are propagated to 1101 the mobility nodes via the DIAMETER protocol, while the keys destined 1102 for the Mobile Node are sent via the Mobile-IP protocol. 1104 Figure 8 depicts the new security associations used for Mobile-IP 1105 message integrity using the keys derived by the DIAMETER server. 1107 +--------+ +--------+ 1108 | | K3 | | 1109 | FA |<-------------------->| HA | 1110 | | | | 1111 +--------+ +--------+ 1112 ^ ^ 1113 | K2 K1 | 1114 | +--------+ | 1115 | | | | 1116 +------>| MN |<------+ 1117 | | 1118 +--------+ 1119 Figure 8 - Security Association after Key Distribution 1121 Once the session keys have been established and propagated, the 1122 mobility devices can exchange registration information directly 1123 without the need of the DIAMETER infrastructure. However the session 1124 keys have a lifetime, after which the DIAMETER infrastructure must be 1125 used in order to acquire new session keys. 1127 3.4 NASREQ Extension 1129 The NASREQ extension provides authentication and authorization for 1130 dial-in PPP users, terminal server access and tunneling applications, 1131 such as L2TP. The extension makes use of the attributes defined in 1132 the RADIUS protocol to carry the data objects. This was intended to 1133 ease migration of existing RADIUS servers to DIAMETER since they 1134 could share a single dictionary and user profile. Furthermore, this 1135 would reduce the amount of processing required for an inter-working 1136 system that acts as a RADIUS/DIAMETER bridge. 1138 DIAMETER has native EAP support that solves known problems in the 1139 RADIUS protocol. Furthermore, DIAMETER takes end-to-end 1140 authentication one step further by providing for end-to-end 1141 authentication via PPP's CHAP. This allows for a more secure 1142 authentication infrastructure without having to replace or modify the 1143 installed base of clients. 1145 If end-to-end CHAP is used in bridged DIAMETER/RADIUS environments, 1146 the bridge host is responsible for generating the challenge to the 1147 user. 1149 The remaining authentication and authorization logic found in RADIUS 1150 implementations can then be re-used. The basic changes are the 1151 message formats and the transmission mechanism as defined in the 1152 DIAMETER base protocol. This section does not detail RADIUS 1153 authentication and authorization. The interested reader should refer 1154 to RFC 2138. 1156 3.5 Accounting Extension 1158 The Accounting extension provides usage collection to both the 1159 Mobile-IP and the NASREQ extensions. The accounting requirements 1160 specifications [6, 8] define that an accounting protocol must provide 1161 the following functionality: 1163 - Negotiable transfer mechanism. 1164 - Provide general purpose AVPs. 1165 - Flexible to allows new extensions to use the accounting 1166 extension. 1167 - Scalable to allows millions to users and thousands of sites. 1168 - Secure accounting data transfer. 1170 The DIAMETER protocol encodes the actual accounting information using 1171 the Accounting Data Interchange Format (ADIF) [24]. ADIF was intended 1172 to allow a uniform encoding of accounting data to be transferred over 1173 virtually any transport (e.g. DIAMETER, SMTP, HTTP, etc). 1175 The DIAMETER Accounting Extension allows accounting information to be 1176 sent in two modes; real-time and batched. Real-time accounting 1177 transfers are useful in environments where timely arrival of the 1178 information is required, such as when debit cards are used. Batched 1179 accounting transfers are useful in environments that do not need up 1180 to the minute accounting records. However, it is possible that in 1181 inter-domain networks, real-time accounting data delivery will be 1182 more popular since the ISPs involved will want to receive some 1183 guarantees of payment prior to providing service. 1185 The DIAMETER protocol is session oriented, and each session typically 1186 has a finite lifetime. Prior to the timeout of a session, a user 1187 typically needs to be re-authentication and/or re-authorized in order 1188 to extend the life of the session. In the Mobile-IP world, this 1189 equates to the mobility registration lifetime, while in PPP this 1190 means that the PPP authentication must be re-opened [5]. When a re- 1191 authentication and/or re-authorization occurs, a new token is 1192 generated, which is used in the corresponding accounting message. 1194 The DIAMETER Accounting extension combined with the Strong Security 1195 [27] extension (see section 3.2), provides strong authentication of 1196 accounting data, which MAY be used for repudiation purposes. The 1197 strong security extension also allows multiple parties to sign the 1198 accounting information, which is beneficial in environments that 1199 include a referral broker. The foreign and home servers can both 1200 sequentially sign the accounting record, and submit the result to the 1201 broker. The broker can then use the signatures to ensure that both 1202 parties agreed to the contents of the accounting record. 1204 3.6 Resource Management 1206 Many network access services requiring AAA support have a requirement 1207 for servers that maintain session state information. An example of 1208 such a requirement is in the dial-up PPP world. With the introduction 1209 of flat-rate internet access, there has been a surge in fraud where a 1210 user provides his username/password pair to other people. The end 1211 result is that a single username (account) can have simultaneous 1212 concurrent sessions. 1214 Internet Service Providers have had to implement proprietary 1215 extensions to protocol, such as RADIUS, in order to attempt to 1216 identify when such fraud occurs. Unfortunately, since the protocol 1217 does not provide the necessary functionality required to maintain 1218 state information, these solutions have been unreliable. 1220 The DIAMETER Base Protocol [18], the Accounting extension [11], the 1221 Mobile IP [13] and NASREQ [30] extensions provide some of the 1222 functionality that is required for servers to maintain state 1223 information, such as: 1225 - Reliable Transport 1226 - Indication of the termination of a session 1227 - A Reboot message 1228 - Interim Accounting 1229 - Accounting On/Off message 1230 - Ability to re-authorize an existing session 1232 Although the above features do allow nodes to maintain state 1233 information, it is necessary for a DIAMETER node to request a 1234 snapshot of active sessions from a peer. This may be used when state 1235 information is lost, which could occur after a device failure, or 1236 this may be done periodically in order to ensure that the state is 1237 current. 1239 The DIAMETER Resource Management extension [29] provides the messages 1240 that are required for a node to request a snapshot of active sessions 1241 from a peer. State information is exchange via the Resource-Token 1242 AVP, which is used to encapsulate a set of AVPs that describe the 1243 session and resources used. There is one Resource-Token AVP for each 1244 active session. 1246 3.7 DIAMETER Command Naming Conventions 1247 The following conventions are proposed for the naming of Diameter 1248 messages. Diameter commands typically start with an object name, and 1249 end with one of the following verbs: 1251 3.7.1 Request/Answer 1253 Request is used when the command is asking the peer to do something 1254 for it, for example, set up a session, or reconfigure some 1255 parameters. The Answer MUST contain either a positive or negative 1256 result code, telling the requester whether or not the request 1257 successfully occurred. Other information can also be returned in the 1258 Answer. 1260 For example, AA-Request asks the peer device to authorize and/or 1261 authenticate a user in order to set up a session. The request may 1262 fail, thus the answer may be positive or negative. 1264 3.7.2 Query/Response 1266 Query is used when the command is asking for information that it 1267 expects the peer to have. An example would be querying for current 1268 configuration information, or querying for information on resources 1269 or sessions in use. The Response usually contains a positive result 1270 code and the information, or a negative result code with the reason 1271 for not answering the query. 1273 For example, Resource-Query requests the peer device to return 1274 specific information about one or more resources. The answer is 1275 returned in a Resource-Response. 1277 3.7.3 Indication 1279 Indication is used when the command is giving information on 1280 something that is about to or has already occurred. The peer 1281 receiving the message does not respond to the message, but a 1282 transport level acknowledgement must be done in order to ensure that 1283 the message was reliably delivered. 1285 For example the base draft defines a message that is used to ensure 1286 that a peer is still active. The Device-Watchdog-Ind message has no 1287 associated response, but is acknowledged by the underlying transport. 1289 4.0 Why not LDAP? 1290 One common question is whether LDAP would provide the functionality 1291 required. 1293 A Server MAY wish to access policies using LDAP, but the use of LDAP 1294 between the client and the server is not possible. The use of LDAP in 1295 this case would require that all routers have read/write access to 1296 the directory. Most customers would not accept this requirements and 1297 it is not efficient. 1299 In the case of roaming, customers would have to open up their 1300 directory so outside routers have writable access. The security 1301 implications set aside, having 1000's of routers constantly 1302 read/write to the directory would cause some additional problems to 1303 the Directory Service. 1305 Finally, LDAP does not provide server initiated messages which is a 1306 requirement for an AAA protocol. 1308 5.0 References 1310 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1312 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location Protocol", 1313 RFC-2165, June 1997. 1315 [3] Aboba, Beadles, "The Network Access Identifier", RFC 2486, Janu- 1316 ary 1999. 1318 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 1320 [5] G. Zorn, P. Calhoun, "Limiting Fraud in Roaming", draft-ietf- 1321 roamops-fraud-limit-00.txt, IETF work in progress, May 1999. 1323 [6] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting 1324 Management", draft-ietf-aaa-acct-00.txt, IETF work in progress, 1325 January 2000. 1327 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1328 1996. 1330 [8] J. Arkko, "Requirements for Internet-Scale Accounting Manage- 1331 ment", draft-arkko-acctreq-00.txt, IETF work in progress, August 1332 1998. 1334 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 1335 Levels", BCP 14, RFC 2119, March 1997. 1337 [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol 1338 (EAP)", RFC 2284, March 1998. 1340 [11] J. Arkko, P. Calhoun, P. Patel, G. Zorn, "DIAMETER Accounting 1341 Extension", draft-calhoun-diameter-accounting-05.txt, IETF work 1342 in progress, April 2000. 1344 [12] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Message Process- 1345 ing and Dispatching for the Simple Network Management Proto- 1346 col:", RFC 2572, April 1999. 1348 [13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 1349 calhoun-diameter-mobileip-07.txt, IETF work in progress, April 1350 2000. 1352 [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and EDI 1353 Law", Prentice-Hall, ISBN 0-471-53135-9. 1355 [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent 1356 Challenge/Response Extension", draft-ietf-mobileip-challenge- 1357 09.txt, IETF work in progress, February 2000. 1359 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" RFC 1360 1409, November 1998. 1362 [17] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 1363 51, July 1994. 1365 [18] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 1366 Protocol", draft-calhoun-diameter-14.txt, IETF work in progress, 1367 April 2000. 1369 [19] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Protocols", 1370 RFC 2477, January 1999. 1372 [20] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of Roaming 1373 Implementations", RFC 2194, September 1997. 1375 [21] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementa- 1376 tion in Roaming", RFC 2607, June 1999. 1378 [22] T. Hiller and al, "3G Wireless Data Provider Architecture Using 1379 Mobile IP and AAA", draft-hiller-3gwireless-00.txt, IETF work in 1380 progress, March 1999. 1382 [23] E. Gustafsson, A. Jonsson, E. Hubbard, J. Halmkvist, A. Roos, 1383 "Requirements on Mobile IP from a Cellular Perspective", draft- 1384 ietf-mobileip-cellular-requirements- 02.txt, IETF work in 1385 progress, December 1999. 1387 [24] B. Aboba, D. Lidyard, "The Accounting Data Interchange Format 1388 (ADIF)", draft-roamops-acctng-07.txt, IETF work in progress, 1389 August 1999. 1391 [25] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1392 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1393 RFC 2560, June 1999. 1395 [26] W. Simpson, "PPP Challenge Handshake Authentication Protocol 1396 (CHAP)", RFC 1994, August 1996. 1398 [27] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security 1399 Extension", draft-calhoun-diameter-strong-crypto-03.txt, IETF 1400 work in progress, April 2000. 1402 [28] R. Stewart et al., "Simple Control Transmission Protocol", 1403 draft-ietf-sigtran-sctp-07.txt, IETF Work in Progress, March 1404 2000. 1406 [29] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft- 1407 calhoun-diameter-res-mgmt-03.txt, IETF Work in Progress, April 1408 2000. 1410 [30] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ 1411 Extension", draft-calhoun-diameter-nasreq-03.txt, IETF work in 1412 progress, April 2000. 1414 [31] S. Kent, R. Atkinson, "Security Architecture for the Internet 1415 Protocol", RFC 1825, November 1998. 1417 6.0 Acknowledgements 1419 The Authors would like to thanks Bernard Aboba and Jari Arkko for 1420 their Accounting Requirements contribution. Thanks also goes to Erik 1421 Guttman for some very useful comments in helping make this draft more 1422 readable. The Mobile-IP Extension section was text originally writ- 1423 ten by Pat Calhoun for another Internet-Draft, which was subsequently 1424 cleaned up by Dave Spence. The authors would like to thank Nenad 1425 Trifunovic, Tony Johansson and Pankaj Patel for their participation 1426 in the Document Reading Party. A final thanks to Stephen Farrell for 1427 his security review. 1429 7.0 Author's Addresses 1431 Questions about this memo can be directed to: 1433 Pat R. Calhoun 1434 Sun Laboratories, Network and Security 1435 Sun Microsystems, Inc. 1436 15 Network Circle 1437 Menlo Park, California, 94025 1438 USA 1440 Phone: +1 650-786-7733 1441 Fax: +1 650-786-6445 1442 E-mail: pcalhoun@eng.sun.com 1444 Glen Zorn 1445 Cisco Systems, Inc. 1446 500 108th Avenue N.E., Suite 500 1447 Bellevue, WA 98004 1448 USA 1450 Phone: +1 425 438 8218 1451 E-Mail: gwz@cisco.com 1453 Ping Pan 1454 Bell Laboratories 1455 Lucent Technologies 1456 101 Crawfords Corner Road 1457 Holmdel, NJ 07733 1458 USA 1460 Phone: +1 732-332-6744 1461 E-mail: pingpan@dnrc.bell-labs.com 1463 Haseeb Akhtar 1464 Wireless Technology Labs 1465 Nortel Networks 1466 2221 Lakeside Blvd. 1467 Richardson, TX 75082-4399 1468 USA 1470 Phone: +1 972-684-8850 1471 E-Mail: haseeb@nortelnetworks.com 1473 8.0 Full Copyright Statement 1475 Copyright (C) The Internet Society (1999). All Rights Reserved. 1477 This document and translations of it may be copied and furnished to 1478 others, and derivative works that comment on or otherwise explain it 1479 or assist in its implementation may be prepared, copied, published and 1480 distributed, in whole or in part, without restriction of any kind, 1481 provided that the above copyright notice and this paragraph are 1482 included on all such copies and derivative works. However, this 1483 document itself may not be modified in any way, such as by removing the 1484 copyright notice or references to the Internet Society or other Internet 1485 organizations, except as needed for the purpose of developing 1486 Internet standards in which case the procedures for copyrights defined 1487 in the Internet Standards process must be followed, or as required to 1488 translate it into languages other than English. The limited permissions 1489 granted above are perpetual and will not be revoked by the 1490 Internet Society or its successors or assigns. This document and the 1491 information contained herein is provided on an "AS IS" basis and THE 1492 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 1493 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1494 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1495 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1496 PARTICULAR PURPOSE.