idnits 2.17.1 draft-calhoun-diameter-framework-04.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 32 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 33 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 3 instances of too long lines in the document, the longest one being 1 character 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1334, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1341, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1346, 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) -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-02) exists of draft-aboba-acct-01 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- No information found for draft-arkko-acctreq - is the name correct? -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2284 (ref. '10') (Obsoleted by RFC 3748) == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-00 -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-02 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-02 ** Obsolete normative reference: RFC 1409 (ref. '16') (Obsoleted by RFC 1416) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-08 -- Possible downref: Normative reference to a draft: ref. '18' ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '19') ** Downref: Normative reference to an Informational RFC: RFC 2194 (ref. '20') ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '21') -- Possible downref: Normative reference to a draft: ref. '22' -- Possible downref: Normative reference to a draft: ref. '23' -- No information found for draft-roamops-acctng - is the name correct? -- Possible downref: Normative reference to a draft: ref. '24' ** Obsolete normative reference: RFC 2560 (ref. '25') (Obsoleted by RFC 6960) Summary: 19 errors (**), 0 flaws (~~), 13 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-framework-04.txt Glen Zorn 4 Date: October 1999 Microsoft Corporation 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@ipass.com mailing list. 37 Distribution of this memo is unlimited. 39 Abstract 41 As the number of new internet services has increased in the past 42 couple of years, routers and network access servers (NAS) have had to 43 undergo re-engineering to support them. 45 These new services could often benefit from an Authentication, 46 Authorization and Accounting (AAA) protocol to facilitate off-loading 47 policy information to an external server. 49 The DIAMETER protocol defines a policy protocol used by clients to 50 perform Policy, AAA and resource control for Internet Access 51 technologies such as PPP and Mobile-IP. 53 Table of Contents 55 1.0 Introduction 56 1.1 Copyright Statement 57 1.2 Requirements language 58 1.3 Terminology 59 1.4 Changes in version -04 60 2.0 Problems to be addressed 61 2.1 Strict limitation of attribute data 62 2.2 No documented retransmission procedure 63 2.3 Inability to control flow to servers 64 2.4 End to end message acknowledgment 65 2.5 No retransmission procedure 66 2.6 Heavy processing cost 67 2.7 Silent discarding of packets 68 2.8 No fail-over server support 69 2.9 client/server protocol 70 2.10 No unsolicited messages 71 2.11 Authentication Replay Attacks 72 2.12 Hop-by-Hop security 73 2.13 No support for user-specific commands 74 2.14 No alignment requirements 75 3.0 DIAMETER Architecture 76 3.1 DIAMETER Base Protocol 77 3.1.1 Proxy Support 78 3.1.2 Broker Support 79 3.2 End-to-End Security Extension 80 3.3 Mobile-IP Extension 81 3.4 PPP (ROAMOPS) Extension 82 3.5 Accounting Extension 83 3.6 DIAMETER Command Naming Conventions 84 3.6.1 Request/Response 85 3.6.2 Query/Response 86 3.6.3 Indication 87 4.0 Why not LDAP? 88 5.0 References 89 6.0 Acknowledgements 90 7.0 Author's Address 92 1.0 Introduction 94 Historically, the RADIUS protocol has been used to provide AAA 95 services for dial-up PPP [17] and terminal server access. Over time, 96 routers and network access servers (NAS) have increased in complexity 97 and density, making the RADIUS protocol increasingly unsuitable for 98 use in such networks. 100 The Roaming Operations Working Group (ROAMOPS) has published a set of 101 specifications [19, 20, 21] that define how a PPP user can gain 102 access to the Internet without having to dial into his/her home 103 service provider's modem pool. This is achieved by allowing service 104 providers to cross-authenticate their users. Effectively, a user can 105 dial into any service provider's point of presence (POP) that has a 106 roaming agreement with his/her home Internet service provider (ISP), 107 the benefit being that the user does not have to incur a long 108 distance charge while traveling, which can sometimes be quite 109 expensive. 111 Given the number of ISPs today, ROAMOPS realized that requiring each 112 ISP to set up roaming agreements with all other ISPs did not scale. 113 Therefore, the working group defined a "broker", which acts as an 114 intermediate server, whose sole purpose is to set up these roaming 115 agreements. A collection of ISPs and a broker is called a "roaming 116 consortium". There are many such brokers in existence today; many 117 also provide settlement services for member ISPs. 119 The Mobile-IP Working Group has recently changed its focus to cross- 120 domain mobility, which is a requirement for cellular carriers wishing 121 to deploy IETF-based mobility protocols. The current cellular 122 carriers requirements [22, 23] are very similar to the ROAMOPS model, 123 with the exception that the access protocol is Mobile-IP [2] instead 124 of PPP. 126 The DIAMETER protocol was not designed from the ground up. Instead, 127 the basic RADIUS model was retained while fixing the flaws in the 128 RADIUS protocol itself. DIAMETER does not share a common protocol 129 data unit (PDU) with RADIUS, but does borrow sufficiently from the 130 protocol to ease migration. 132 The basic concept behind DIAMETER is to provide a base protocol that 133 can be extended in order to provide AAA services to new access 134 technologies. Currently, the protocol only concerns itself with PPP 135 access, both in the traditional sense as well as taking into account 136 the ROAMOPS model, and Mobile-IP. 138 Although DIAMETER could be used to solve a wider set of AAA problems, 139 we are currently limiting the scope of the protocol in order to 140 ensure that the effort remains focussed on satisfying the 141 requirements of network access. Note that a truly generic AAA 142 protocol used by many applications might provide functionality not 143 provided by DIAMETER. Therefore, it is imperative that the designers 144 of new applications understand their requirements before using 145 DIAMETER. 147 1.1 Copyright Statement 149 Copyright (C) The Internet Society 1999. All Rights Reserved. 151 1.2 Requirements language 153 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 154 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 155 described in [9]. 157 1.3 Terminology 159 Accounting 160 The act of collecting information on resource usage for the 161 purpose of trend analysis, auditing, billing, or cost allocation. 163 Authentication 164 The act of verifying the identity of an entity (subject). 166 Authorization 167 The act of determining whether a requesting entity (subject) will 168 be allowed access to a resource (object). 170 AVP 171 The DIAMETER protocol consists of a header followed by objects. 172 Each object is encapsulated in a header known as an Attribute- 173 Value-Pair. 175 Broker 176 Although a DIAMETER proxy provides routing of DIAMETER 177 authentication, authorization and accounting requests, a broker 178 provides DIAMETER message routing while preserving end-to-end 179 security. A DIAMETER broker can also provide redirect services by 180 providing a requesting DIAMETER server the information necessary 181 to contact a target server directly. 183 DIAMETER Client 184 The DIAMETER Client is the device that users contact in order to 185 get access to the network. An example of a client would be a 186 Network Access Server (NAS) and a Foreign Agent (FA). 188 DIAMETER Server 189 The DIAMETER server is the device that provides for authentication 190 and authorization of a user or node requesting access to the 191 network. The DIAMETER Server also collects accounting information 192 for authenticated sessions. 194 Home Domain 195 This is the Internet service provider or corporate network with 196 whom the user maintains an account relationship. 198 Integrity Check Value (ICV) 200 An Integrity Check Value is an unforgeable or secure hash of the 201 message with a shared secret. 203 Interim accounting 204 An interim accounting message provides a snapshot of usage during 205 a user's session. It is typically implemented in order to provide 206 for partial accounting of a user's session in the event of a 207 device reboot or other network problem that prevents the reception 208 of a session summary message or session record. 210 Session record 211 A session record represents a summary of the resource consumption 212 of a user over the entire session. Accounting gateways creating 213 the session record may do so by processing interim accounting 214 events or accounting events from several devices serving the same 215 user. 217 Local Domain 218 This is the Internet service provider whom the user uses in order 219 to get access. Where roaming is implemented the local ISP may be 220 different from the home ISP. 222 Network Access Identifier 223 In order to provide for the routing of DIAMETER authentication and 224 accounting requests, the userID field used in PPP and Mobile IP 225 (known as the Network Access Identifier or NAI) and in the 226 subsequent DIAMETER authentication and accounting requests, can 227 contain structure. This structure provides a means by which the 228 DIAMETER proxy will locate the DIAMETER server that is to receive 229 the request. The NAI is defined in [3]. 231 Proxy Server 232 In order to provide for the routing of DIAMETER authentication and 233 accounting requests, a DIAMETER proxy can be employed. To the NAS, 234 the DIAMETER proxy appears to act as a DIAMETER server, and to the 235 DIAMETER server, the proxy appears to act as a DIAMETER client. 237 Real-time Accounting 238 Real-time accounting involves the processing of information on 239 resource usage within a defined time window. Time constraints are 240 typically imposed in order to limit financial risk. 242 Redirect Services 243 A DIAMETER broker is said to provide redirect services by 244 returning contact information to a requesting DIAMETER server in 245 order to allow it to communicate directly with another server 246 within a roaming consortium. The roaming consortium that allows 247 for redirect services typically also provides certificate 248 authority services in order to allow the end servers to 249 communicate in a secure fashion. 251 Roaming relationships 252 Roaming relationships include relationships between companies and 253 ISPs, relationships among peer ISPs within a roaming association, 254 and relationships between an ISP and a roaming consortia. 255 Together, the set of relationships forming a path between a local 256 ISP's authentication proxy and the home authentication server is 257 known as the roaming relationship path. 259 Session 260 The DIAMETER protocol is session based. When an authentication 261 request is initially transmitted, it includes a session identifier 262 that is used for the duration of the session. The Session- 263 Identifier AVP contains the identifier and must be globally 264 unique. 266 1.4 Changes in version -04 268 This version of the framework document contains new items in the 269 terminology section and some minor editorial changes as a result of 270 the DIAMETER Document Reading Party. 272 2.0 Problems to be addressed 274 The RADIUS protocol was designed in the early 1990's as an attempt to 275 solve a scaling problem associated with dial-in and telnet servers. 276 Over time the networks became more complex (e.g. roaming networks) 277 and the Network Access Servers (NAS) increased in complexity and 278 density. These changes combined with a massive deployment of the 279 protocol uncovered some fundamental issues with the protocol that 280 needed to be fixed. The DIAMETER protocol was designed as a next 281 generation RADIUS protocol, designed with roaming and high density 282 NASes in mind. 284 This section will describe the documented, and undocumented, RADIUS 285 problems known today. Further sections will describe how the DIAMETER 286 protocol addresses each one of these problems. 288 2.1 Strict limitation of attribute data 290 One of problems that RADIUS suffers from is its inherent limitation 291 on the length of attribute data. This limitation is imposed by the 292 fact that the protocol's attribute header only reserves one byte for 293 the length field. The RADIUS protocol does specify that larger data 294 can be spanned across multiple attributes, however doing so 295 introduces a new set of problems. The RADIUS protocol also allows 296 multiple attributes of the same type to be included within a message. 297 Therefore, it is difficult for a RADIUS server, or client, to 298 determine whether multiple identical attributes are in fact multiple 299 independent attributes, or a single fragmented attribute. 301 2.2 No documented retransmission procedure 303 The RADIUS protocol states that the identifier field, found within 304 the header, is used to identify retransmissions. This one byte field 305 imposes a strict limitation on the number of requests that can be 306 pending at any given time to 255. In the early 1990's, this number 307 was sufficient, but the increased density of most NASes today make 308 the protocol nearly unusable. Most NASes today have fixed this 309 problem by including information in other attributes to bypass this 310 limitation. However, the RADIUS servers have also had to support this 311 change in protocol since they must be able to properly identify 312 retransmissions. The RADIUS protocol also states that the identifier 313 MUST be changed if any data is changed in a request. 315 For this reason, most RADIUS servers keep a cache of received RADIUS 316 request (e.g. all messages received in the last 60 seconds). The 317 RADIUS servers then attempt to match some attributes within the 318 received requests with all attributes in all messages in the cache. 319 This places a very heavy burden on the RADIUS servers, but 320 unfortunately is the only method of identifying retransmissions given 321 the fact that the RADIUS protocol does not have any good scheme. This 322 hack has proved necessary since some NASes have had to change some 323 information within requests in the retransmission queue (such as 324 session length). 326 2.3 Inability to control flow to servers 328 Given the rather bursty nature of the RADIUS protocol, current 329 servers have no way of properly managing their receive buffers. This 330 is in part due to the fact that RADIUS operates over UDP, and does 331 not include any windowing support. This has been known to cause 332 large bursts of requests to be directed to a server, which can burden 333 a server's ability to respond in a timely manner. This problem is 334 most prevalent in cases where a server becomes unavailable and all 335 requests must be sent to an alternate server, or when an ingress port 336 on the NAS becomes available (e.g. T3 port on NAS). 338 2.4 End to end message acknowledgment 340 The RADIUS protocol requires that a NAS retransmit a request until a 341 successful or failed response is received, and does not permit a 342 RADIUS server to retransmit a response. This is problematic since 343 there are many times when a server does receive a request, but cannot 344 respond before the NAS determines that the request must be 345 retransmitted. This can occur for many reasons, including the fact 346 that processing a RADIUS request, which includes authentication and 347 authorization of the user, a database lookup and logging events, can 348 be lengthy. 350 2.5 No retransmission procedure 352 Another reason why NASes typically retransmit is when a SERVER 353 receives a large number of requests, and cannot process all of them 354 in a timely manner. The side effect here is that if the NAS 355 retransmits requests to the server, it simply causes further damage 356 to the busy server. Since the RADIUS server cannot retransmit, some 357 RADIUS servers keep a cache of responses sent in the past 60 seconds 358 in order to minimize processing should a retransmission be received. 359 As previously discussed, identifying a retransmission is a very CPU 360 intensive tasks, but perhaps not quite as intensive as a database 361 lookup. 363 2.6 Heavy processing cost 365 The introduction of proxy RADIUS network have made this 366 acknowledgement scheme even worse, since the end server must respond 367 in a timely manner. Each intermediate RADIUS server adds additional 368 latency to proxied requests due to the application processing cost. 369 This has been known to cause unnecessary retransmission of requests 370 by NASes, which impose heavy burden on the proxies, and the network. 372 When a NAS retransmits a request a maximum number of times, it 373 assumes that the server is no longer available and transmits the 374 message to an alternate server. If there are many messages in the 375 retransmission queue, all other requests are also transmitted to the 376 new server. Since a burst of requests were sent to the server, the 377 chances that it can satisfy all requests before the retransmission 378 period are very small, which causes unnecessary retransmissions. 380 2.7 Silent discarding of packets 382 The RADIUS protocol states that messages that do not contain the 383 expected information, or messages that have errors are silently 384 discarded. Silently discarding messages can create a serious problem 385 since no response is sent to the NAS, which then has to assume that 386 the server is no longer reachable. Since proxy networks are 387 transparent to a NAS, should a server in a proxy chain silently 388 discard a request, it will cause the NAS to assume that the local 389 (first hop) server is no longer available. 391 2.8 No fail-over server support 393 Most NASes today support a large number of RADIUS servers in an 394 attempt to provide resilience. However, the RADIUS protocol itself 395 makes this very difficult due to the problems described above. Since 396 a NAS does not know a priori whether a specific server is available, 397 when it switches to an alternate server, it must retransmit a message 398 a maximum number of times before determining that the server in 399 question is down, and that the next server in the configuration chain 400 must be tried. Taking an example of a NAS with 8 servers configured, 401 if the next 3 servers in the configuration chain were down, it would 402 take the NAS x number of seconds to reach an available server (where 403 x is equal to the retransmission interval * the maximum number of 404 retransmissions * 3), which is most often longer than the clients are 405 willing to wait. 407 Local ISP Home ISP 408 +--------+ +--------+ 409 | Primary| | Primary| 410 +-------+ | Proxy |----------->| Home | 411 | |----------->| Server | | Server | 412 |Network| +--------+ +--------+ 413 |Access | 414 |Server | +--------+ +--------+ 415 | |----------->| 2 nd | | 2 nd | 416 +-------+ | Proxy |----------->| Home | 417 | Server | | Server | 418 +--------+ +--------+ 420 Figure 1: RADIUS Proxy Network 422 2.9 client/server protocol 424 Given that a RADIUS server cannot know a priori whether a downstream 425 RADIUS server is reachable, and the fact that the NAS must retransmit 426 any messages, the RADIUS protocol is not well suited to proxy 427 environments. Since servers are not aware of a peer's reachability, 428 most RADIUS networks are designed by creating parallel links between 429 primary and alternate servers (see figure 1). In this example the 430 local ISP's primary server communicates with the home ISP's primary 431 server, while the 2nd servers communicate directly. When the NAS 432 issues a request to the primary server, the first hop server attempts 433 to proxy the request to the primary server at the home network. The 434 NAS will attempt to retransmit the request n number of times, and the 435 primary server will simply forward the request to the primary server 436 at the home network. 438 Should no response be received, the primary server could attempt to 439 forward the request to the 2nd server at the home network, but since 440 the NAS is controlling the retransmissions, it may not have the 441 opportunity to do so. Therefore, the NAS will redirect all requests 442 to the local ISP's 2nd server. Given the protocol's limitations, it 443 requires a large number of RADIUS servers in order to provide 444 resilient service. 446 The above problem is further aggravated should the local ISP attempt 447 to proxy to two different administrative network's servers. Take an 448 example where the local ISP issues two authentication requests, one 449 for abc.net and another for xyz.com. Let's also assume that abc.net's 450 primary server is down, while xyz's 2nd server is down. Should such a 451 problem occur, all requests for abc.net would cause the NAS to switch 452 to the local ISP's 2nd server, while all requests to xyz.net would 453 cause the NAS to switch back to the local ISP's primary server. This 454 clearly illustrates that the RADIUS protocol cannot be reliably used 455 in proxy networks. 457 2.10 No unsolicited messages 459 The RADIUS protocol does not allow a server to send unsolicited 460 messages to the NAS. As network services became more complex, this 461 limitation has forced manufacturers to break the RADIUS protocol in 462 this area in order to allow servers to communicate with the client. 463 This is widely used for accounting purposes, and to allow a server to 464 inform a NAS that a session should be terminated. Unfortunately, the 465 lack of a standard method of doing this has caused many non- 466 interoperable implementations to be deployed. 468 2.11 Authentication Replay Attacks 470 In today's PPP world, the NAS provides a challenge to the user, which 471 is then computed by the PPP user to create the challenge response. 472 This is commonly known as CHAP [26], and is a popular PPP 473 authentication scheme. Before roaming networks existed, service 474 providers would own both the NAS and the RADIUS server and this 475 wasn't considered a problem. However, now that the NAS and the RADIUS 476 server are owned by two separate administrative domains, the fact 477 that the non-trusted NAS generates a challenge provides the ability 478 for authentication replay attacks. A NAS, or any RADIUS server in a 479 proxy chain, can have access to a valid challenge/response pair, 480 which can be replayed at a later time. 482 The EAP protocol [10], which will be supported as part of RADIUS 483 extensions can solve this problem, but the fact that EAP is not 484 widely deployed on clients, and that many EAP authentication 485 transforms cannot be used within RADIUS (due to the limitation on 486 attribute data size) makes it difficult to use. Furthermore, given 487 the RADIUS protocol's requirement for end-to-end retransmissions, 488 since some EAP authentication types involve a higher number of round 489 trips than what RADIUS currently supports, RADIUS and EAP cannot be 490 used on networks that exhibit data loss. This is primarily due to the 491 fact that most EAP (PPP) clients timeout before the authentication 492 can be completed. 494 2.12 Hop-by-Hop security 496 The RADIUS protocol uses hop-by-hop security, which means that every 497 hop in a RADIUS proxy network adds authentication data that is used 498 by the next peer in the chain. RADIUS has no facility for end-to-end 499 security, where security is maintained from the requestor and the 500 responder, even though a request is handled by intermediate nodes. 501 This has caused opportunities for fraud in RADIUS networks, since 502 intermediate nodes can easily modify information (e.g. accounting 503 information), and such events are untraceable. 505 2.13 No support for user-specific commands 507 Although the RADIUS protocol does support vendor-specific attributes, 508 it does not allow for vendor-specific commands. This has caused 509 serious inter-operability problems since vendors simply choose 510 command identifiers at random, which can collide with other 511 manufacturer's implementation. 513 2.14 No alignment requirements 515 Unlike most newer IETF protocols, the RADIUS protocol does not impose 516 any alignment requirements, which adds an unnecessary burden on most 517 processors. All fields within the header and attributes must be 518 treated as word aligned characters. 520 3.0 DIAMETER Architecture 522 The DIAMETER architecture consists of a base protocol and a set of 523 protocol extensions (such as end-to-end security, PPP, Mobile-IP and 524 accounting). Functionality common to all supported services is 525 implemented in the base protocol, while application-specific 526 functionality may be provided through the extension mechanism. 528 The base protocol [18] must be supported for all DIAMETER 529 applications, and defines the basic PDU format, a few primitives and 530 the basic security services offered by the protocol. Like RADIUS, the 531 DIAMETER protocol operates over UDP but it does define a good 532 retransmission and fail-over strategy that was lacking in RADIUS. The 533 base protocol also defines a windowing scheme, which allows the AAA 534 servers to limit the flow of incoming requests. This can then be used 535 by the AAA clients to distribute the traffic load across multiple 536 servers. The fail-over strategy and the windowing capabilities allow 537 clients and servers to detect the reachability state of peers within 538 the network, allowing for quick transition to back-up servers. 540 As previously discussed, the ROAMOPS model introduces the AAA broker, 541 which acts as an intermediate server redirecting requests to user's 542 home ISPs. ROAMOPS also described a set of attacks that one could 543 mount if such a network was built using the RADIUS protocol [21]. In 544 order to provide secure broker services, end-to-end security is 545 required at the application layer, since messages traverse 546 application gateways (brokers). 548 The DIAMETER End-to-End Security Extension defines a set of 549 extensions to the base protocol that provide end-to-end integrity, 550 confidentiality and non-repudiation at the Attribute-Value-Pair (AVP) 551 level. With these extensions, it is possible to secure portions of a 552 DIAMETER message, while other parts of the message are not secured. 553 Secured objects are called protected AVPs; non-secured objects are 554 called unprotected AVPs. Using DIAMETER, brokers can add, delete or 555 modify unprotected AVPs in a message. 557 The RADIUS protocol provides dial-up PPP AAA services by providing 558 three commands and many Attributes. Attributes in RADIUS are 559 analogous to AVPs in DIAMETER. In order to ease migration from RADIUS 560 to DIAMETER, the first 256 attributes in the DIAMETER AVP space are 561 reserved for RADIUS compatibility. This allows both protocols to 562 share a common dictionary and policy rules for PPP user profiles. 563 Recently, the RADIUS protocol adopted support for the Extensible 564 Authentication Protocol (EAP) [10], but RADIUS' lack of support for 565 large attributes and its inherent unreliability has made the 566 integration of the protocols very difficult. 568 The DIAMETER PPP Extension defines a set of 569 authentication/authorization commands, which can be used for CHAP, 570 PAP and EAP. DIAMETER's support for larger AVPs and its 571 retransmission strategy has made the use of EAP much more palatable, 572 allowing for end-to-end user authentication, which reduces many of 573 authentication replay attacks currently documented. 575 Unlike PPP, Mobile-IP hosts do not have a long-lived "nailed-up" 576 connection to a PPP server, but rather get service from routers that 577 provide service in a particular cell. In the Mobile-IP world, the 578 router is known as a Foreign Agent, while the moving hosts are known 579 as Mobile Nodes. The mobile node's home network has a host that 580 forwards all messages destined to the mobile node through the Foreign 581 Agent. This router is commonly referred to as the Home Agent. 583 Mobile-IP [7] allows the mobile nodes to move from one cell (subnet) 584 to another while retaining the same IP address, minimizing the impact 585 to applications. Although the Mobile-IP protocol could be deployed in 586 a small network with any AAA services, a larger network suffers from 587 many scaling issues such as: 589 - Static mobile node home address 591 - Static mobile node home agent 592 - Requirement to pre-configure mobile node profile on home agents 594 - No inter-domain mobility 596 Both PPP and Mobile-IP require that usage data be collected for uses 597 such as capacity planning and for accounting purposes. The current 598 standard protocol for accounting is SNMP [12], but experience 599 indicates that SNMP often is not the correct protocol for service 600 accounting. Today many applications and services use RADIUS 601 accounting [4] as their accounting protocol, however the RADIUS 602 accounting protocol is not an IETF standard; in addition, it suffers 603 from similar scaling and security problems. The DIAMETER accounting 604 extension [11] is designed to allow accounting information to be sent 605 across administrative domains (optionally through brokers), and has 606 been derived from an accounting requirements document [6, 8]. 608 +-----------+ 609 | Mobile-IP | 610 | | 611 | Extension | 612 +-----------+ 613 +-----------+ /|\ +------------+ 614 | ROAMOPS | | | Accounting | 615 | (PPP) | | | | 616 | Extension | | | Extension | 617 +-----------+ | +------------+ 618 /|\ | /|\ 619 | | | 620 \|/ \|/ \|/ 621 +----------------------------------+---------------------+ 622 | | | 623 | DIAMETER Base Protocol | End-to-End Security | 624 | | | 625 +----------------------------------+---------------------+ 626 Figure 2: DIAMETER Protocol Architecture 628 3.1 DIAMETER Base Protocol 630 The Base Protocol defines the DIAMETER message format, a set of 631 primitives and how the messages are transmitted in a secure fashion. 632 The Base Protocol assumes a peer-to-peer communication model, as 633 opposed to a client-server model. The following goals motivated the 634 design of the base protocol: 636 - lightweight and simple to implement. 638 - Large AVP space 640 - Efficient encoding of attributes, similar to RADIUS 642 - Support for vendor specific AVPs and Commands 644 - Support for large number of simultaneous pending requests 646 - Reliable, UDP-based transport 648 - Well-defined retransmission and fail-over scheme 650 - Ability to quickly detect unreachable peers 652 - No silent message discards 654 - Support of unsolicited messages to "clients" 656 - integrity and confidentiality at the AVP level 658 - Hop-by-Hop and End-to-End security 660 - One session per authentication/authorization flow 662 - Provide redirect (referal) services, to allow bypassing of 663 broker 665 The DIAMETER base protocol is intended to simply provide a secure 666 transport for the messages defined in the various application- 667 specific extensions. It is therefore imperative that the base be 668 lightweight and simple to implement. 670 In the DIAMETER protocol, data objects are encapsulated within the 671 Attribute Value Pair (AVP). An AVP consists of three parts: the 672 Identifier, Length and Data. A unique AVP Identifier is assigned to 673 all data objects in order to be able to distinguish the data 674 contained. The AVP Identifier namespace must be sufficiently large to 675 ensure that future protocol extensibility is not limited by the size 676 of the namespace, as in the RADIUS protocol. Furthermore, vendors 677 wishing to add "proprietary" extensions must be allowed to do so by 678 using a vendor-specific namespace, managed by IANA. 680 For many years the question as to whether RADIUS should operate over 681 UDP or TCP has led to heated discussion. It must be determined 682 whether the benefits that UDP provides are worth the implementation 683 complexities. Over time, it has become clear that these benefits are 684 well worth the cost. The issue with TCP is that an AAA protocol 685 requires a quick retransmission and fail-over scheme, which TCP 686 cannot provide. The DIAMETER protocol must be able to control 687 retransmission strategy, and more importantly when to switch to an 688 alternate DIAMETER server. 690 Contrary to RADIUS, the DIAMETER protocol requires that each node in 691 a proxy chain acknowledge a request, or response, at the "transport" 692 layer. Since DIAMETER defines a reliable layer over UDP, this is 693 done through the use of sequence and acknowledgement numbers. This 694 allows each node in a chain to retransmit unacknowledged messages. 696 The DIAMETER protocol provides message sequencing within the header, 697 which can be used to detect retransmissions. This simple 698 retransmission detection can greatly simplify server implementations, 699 and allow a given server to support a much larger number of 700 transactions per second. 702 The DIAMETER protocol provides windowing, which requires that each 703 peer advertise it's receive window. This makes it much simpler for a 704 NAS to send only the number of requests that the next hop DIAMETER 705 server can handle. Clever implementations can then decide to send 706 requests to an alternate server when a primary server is busy. 708 When a DIAMETER peer has not acknowledged a specific message, and the 709 message has been retransmitted some maximum number of times, the peer 710 is assumed to be no longer reachable, and all pending requests can 711 then be issued to an alternate server (providing that they fit within 712 the peer's receive window). The Base Protocol also defines a watchdog 713 message, which is sent to a peer to detect reachability when no 714 traffic has been sent for some time. 716 With the exception of a few security related errors, the DIAMETER 717 protocol requires that all messages be acknowledged, either with a 718 successful response or one that contains an error code. 720 Where the RADIUS protocol is client-server, the DIAMETER protocol is 721 peer to peer, allowing unsolicited messages to be sent to NASes. 722 There are many benefits to peer-to-peer AAA protocols. One example is 723 the on-demand retrieval of accounting data; another, server-initiated 724 session termination. 726 The Base DIAMETER protocol provides for hop-by-hop security, similar 727 to the scheme employed by RADIUS today. However, the DIAMETER 728 protocol also provides for replay protection through a timestamp 729 mechanism. This security scheme requires a long lived security 730 association to be established by peers, or can make use of keying 731 material negotiated out of band. The Base Protocol also allows the 732 built-in security measure to be turned off, (i.e., in cases where 733 IPSec is in use). 735 The DIAMETER protocol is a session-oriented protocol, meaning that 736 for each user being authenticated, there exists a session between the 737 initiator of the authentication/authorization request and the home 738 DIAMETER server. Sessions are identified through a session 739 identifier, which is globally unique at any given time. All 740 subsequent DIAMETER transactions (e.g. accounting) must include the 741 session identifier to reference the session. A Session termination 742 message exists in order to end a DIAMETER session, and all sessions 743 have a timeout value in order to ensure that they can be cleaned up 744 properly. 746 Since today's processors work more efficiently when objects are 747 aligned on a 32-bit boundary, the DIAMETER protocol requires 32-bit 748 alignment of all headers and the data. This has recently become a 749 common requirement for many new protocols at the IETF. 751 3.1.1 Proxy Support 753 The DIAMETER protocol was designed from the beginning to support 754 roaming networks. This means that every node in the network is 755 responsible for it's own retransmissions, and the protocol does allow 756 each node to know a priori the reachability state of each peer. This 757 allows for a resilient network, and efficient retransmission scheme. 758 Figure 3 depicts a network where each DIAMETER server can communicate 759 with all other servers. 761 local ISP Home ISP 762 +--------+ +--------+ 763 | Primary| | Primary| 764 +-------+ | Proxy |----------->| Home | 765 | |----------->| Server |\ / | Server | 766 |Network| +--------+ \ / +--------+ 767 |Access | X 768 |Server | +--------+ / \ +--------+ 769 | |----------->| 2 nd |/ \ | 2 nd | 770 +-------+ | Proxy |----------->| Home | 771 | Server | | Server | 772 +--------+ +--------+ 774 Figure 3: DIAMETER Proxy Network 776 In the network shown in figure 3, should a request, or response be 777 lost in the network, the last node that handled the lost message is 778 responsible for retransmitting it to it's peer. Furthermore, should 779 connectivity to a peer be lost, it allowed the node to transmit the 780 message to an alternate peer. This reduces the number of systems 781 required, processing overhead of intermediate nodes, decreases the 782 latency involved in the switch-over and increases reliability. 784 3.1.2 Broker Support 786 A broker is a proxy server that provides simple DIAMETER message 787 "routing" functions. Brokers are generally deployed in order to 788 reduce the configuration information that would otherwise be 789 necessary on all servers owned by ISPs within a roaming consortium. 790 Brokers can provide two separate functions depending upon the 791 business model. 793 The first where the broker forwards messages to the proper 794 destination based on the NAI information (figure 4). In such a 795 network, when the broker receives a request from a DIAMETER server, 796 it determines the message's destination and can optionally perform 797 some authorization decisions based on local policy. 799 +------------------+ 800 | DIAMETER | 801 | Broker | 802 +------------------+ 803 /|\ /|\ 804 | | 805 \|/ \|/ 806 +----------+ +----------+ 807 | Local | | Home | 808 | DIAMETER | | DIAMETER | 809 | Server | | Server | 810 +----------+ +----------+ 812 Figure 4: DIAMETER Roaming Consortium 814 The DIAMETER broker's organization can also provide Certificate 815 Authority services, by issuing certificates to all DIAMETER servers 816 within the consortium. This allows the broker and the DIAMETER 817 servers to communicate in a secure fashion, without the need for 818 long-lived secrets. Protocols such as IP Security can allow for 819 short-lived session keys to be generated and periodically refreshed. 821 The second broker model allows the end DIAMETER servers to directly 822 communicate (figure 5). In this model the broker simply provides 823 redirect services, which is aimed at reducing the amount of 824 configuration that would otherwise be necessary on all end DIAMETER 825 servers. When a DIAMETER servers sends a request the broker, the 826 broker returns contact information that is then used by the 827 requesting server to issue the request directly to the home DIAMETER 828 server. In order for the end DIAMETER servers to be able to 829 communicate in a secure fashion, a pre-established security 830 association is required. This can be in the form of a long-lived 831 shared secret, which has scaling problems, or via certificates when 832 the broker's organization provides CA services. In the event that the 833 broker also provides settlement services, it is possible for the 834 accounting information, signed by both parties, to be transmitted to 835 the broker by the server providing service to the user. 837 When the broker provides the message forwarding functions, it can 838 validate that the source and destination DIAMETER servers are in 839 "good standing", which reduces the processing on the end servers. 840 This can be done by having the broker check the server's certificates 841 against a CRL, via an Online Certificate Status Protocols [25], or 842 through local configuration. The broker can optionally attach the 843 source server's certificate if it isn't already present in the 844 message. When a broker receives a request from or destined to a 845 domain that is either unrecognized or no longer part of the roaming 846 consortium, an error will be returned to the requesting server. 848 +------------------+ +---------+ 849 | DIAMETER | | CRL DB/ | 850 | Broker | | OCSP | 851 +------------------+ +---------+ 852 /|\ 853 Request | Response with 854 | Result Code = 855 | Redirect 856 \|/ 857 +----------+ +----------+ 858 | Local |/ \| Home | 859 | DIAMETER |--------------| DIAMETER | 860 | Server |\ /| Server | 861 +----------+ Direct +----------+ 862 Communication 863 Figure 5: DIAMETER Broker Returning Redirect Indication 865 The very fact that the DIAMETER servers in the roaming network do not 866 have to burden themselves with validating certificates against a CRL, 867 or some other certificate validation infrastructure, is a huge 868 advantage. In cases of inter-consortium roaming, the brokers involved 869 can be responsible for validating any certificates involved. Note 870 that it is also possible for the broker to periodically issue new 871 certificates to the roaming consortium members out-of-band in order 872 to eliminate the need to add certificates to each message, decreasing 873 the message size and the per-message processing penalty. 875 When the broker provides redirect services, the broker can return 876 both the source and the destination server's certificates. The 877 certificates are encapsulated within a DIAMETER attribute, and 878 include a timestamp, an expiration time all signed by the broker. 879 Should the end server's policy be setup such that they will trust the 880 certificate returned by the broker, they do not have to make any 881 additional certificate validation checks. However, local policy may 882 require that the end DIAMETER servers validate periodically. 884 Note that even though some broker's do allow direct communication, 885 some will require that all accounting messages be forwarded by the 886 broker. This is typically required when the broker also provides 887 settlement services. In such a network, the broker normally requires 888 some reassurances that the user was in fact authenticated and 889 authorized by the home DIAMETER server prior to accepting accounting 890 records. The document [5] defines a method by which the broker can 891 get such reassurances. 893 3.2 End-to-End Security Extension 895 The DIAMETER base protocol allows ISP's DIAMETER servers to 896 communicate securely, using hop-by-hop authentication. Hop-by-hop 897 authentication means that the requesting server has secure 898 communication with the broker, and the broker has secure communicate 899 with the destination server. However, the base protocol does not 900 provide the ability for the requesting and destination server to 901 communicate securely through the broker. 903 The End-to-End Security extension provides for end-to-end integrity, 904 confidentiality and non-repudiation at the AVP level. This means that 905 DIAMETER servers can add a Digital Signature over a select set of 906 AVPs, which provides message integrity. Intermediate nodes, such as 907 brokers can also add their own digital signature, should there be a 908 requirement to do so. confidentiality is provided by encrypting AVPs 909 using the target's private key, while non-repudiation is provided via 910 the digital signature previously mentioned. 912 The end-to-end security extension can only be used in networks where 913 the broker issues roaming certificates to all DIAMETER servers that 914 form the roaming consortium. In certain cases, the broker can also 915 act as a settlement agent, similar to the EDI clearing houses [14]. 917 3.3 Mobile-IP Extension 919 The Mobile-IP protocol is used to manage mobility of an IP host 920 across IP subnets [7]. Recent activity within the Mobile-IP Working 921 Group has defined the interaction between Mobile-IP and AAA in order 922 to provide: 924 - Better scaling of security associations 925 - Mobility across administrative domain boundaries 926 - Dynamic home agent assignment 928 The Mobile IP protocol [7] works well when all mobile nodes belong to 929 the same administrative domain. Some of the current work within the 930 Mobile IP Working Group is to allow Mobile IP to scale across 931 administrative domains. This work requires modifications to the 932 existing Mobile IP trust model. 934 Figure 6 depicts the DIAMETER trust model for Mobile-IP. In this 935 model each network contains mobile nodes (MN) and a DIAMETER server. 936 Each mobility device shares a security association (SA) with the 937 DIAMETER server within its own home network. This means that none of 938 the mobility devices initially share a security association. The 939 DIAMETER servers in both administrative domains can either share a 940 direct security association, or can have a security association with 941 an intermediate broker. 943 Broker AAA 944 +--------+ 945 | | 946 |DIAMETER| 947 /=====| |=====\ 948 // +--------+ \\ 949 Local // SA SA \\ Home 950 AAA // \\ AAA 951 +--------+ +--------+ 952 | | SA4 | | 953 |DIAMETER|======================|DIAMETER| 954 | |(in lieu of broker or)| | 955 +--------+(in direct comm model)+--------+ 956 || || || 957 || || || 958 SA1|| SA2 || || SA3 959 || || || 960 || || || 961 +---------+ +---------+ +---------+ 962 | | | | | | 963 | FA | | MN | | HA | 964 | | | | | | 965 +---------+ +---------+ +---------+ 966 Figure 6 - Mobile-IP AAA Trust Model 968 Figure 7 provides an example of a Mobile-IP network that includes 969 DIAMETER. In the integrated Mobile-IP/DIAMETER Network, it is assumed 970 that each mobility agent shares a security association between itself 971 and its home DIAMETER server. Further, the Home and Local DIAMETER 972 servers both share a security association with the broker's DIAMETER 973 server. Lastly, it is assumed that each mobile node shares a trust 974 relationship with its home DIAMETER Server. 976 Local Access Broker Home IP 977 Provider Network Network Network 978 +--------+ +--------+ +--------+ 979 | | | | | | 980 |DIAMETER|------|DIAMETER|------|DIAMETER| 981 | | | | | | 982 +--------+ +--------+ +--------+ 983 | | 984 | | 985 AAA | | AAA 986 | | 987 | | 988 +---------+ +---------+ 989 | | | | 990 | FA | | HA | 991 | | | | 992 +---------+ +---------+ 993 | 994 | Home Network 995 | -Private Network 996 Mobile | -Home Provider 997 IP | -Home ISP 998 | 999 +--------+ 1000 | Mobile | 1001 | Node | 1002 +--------+ 1003 Figure 7 - General Wireless IP Architecture for Mobile-IP AAA 1005 In this example, a Mobile Node appears within a local network and 1006 issues a registration to the Foreign Agent. Since the Foreign Agent 1007 does not share any security association with the Home Agent, it sends 1008 a DIAMETER request to its local DIAMETER server, which includes the 1009 authentication information and the Mobile-IP registration request. 1010 The Mobile Node cannot communicate directly with the home DIAMETER 1011 Server for two reasons: 1013 - It does not have access to the network. The registration request 1014 is sent by the Mobile Node to request access to the network. 1015 - The Mobile Node may not have an IP address, and may be requesting 1016 that one be assigned to it by its home provider. 1018 The Local DIAMETER Server will determine whether the request can be 1019 satisfied locally through the use of the Network Access Identifier 1020 [3] provided by the Mobile Node. The NAI has the form of user@realm 1021 and the DIAMETER Server uses the realm portion of the NAI to identify 1022 the Mobile Node's home DIAMETER Server. If the Local DIAMETER Server 1023 does not share any security association with the Mobile Node's home 1024 DIAMETER Server, it may forward the request to its broker. If the 1025 broker has a relationship with the home network, it can forward the 1026 request, otherwise a failure indication is sent back to the Local 1027 DIAMETER Server. 1029 When the home DIAMETER Server receives the DIAMETER Request, it 1030 authenticates the user and begins the authorization phase. The 1031 authorization phase includes the generation of: 1033 - Dynamic session keys to be distributed among all mobility agents 1034 - Optional dynamic assignment of a home agent 1035 - Optional dynamic assignment of a home address (note this could be 1036 done by the home agent). 1037 - Optional assignment of QOS parameters for the mobile node [22] 1039 Once authorization is complete, the home DIAMETER Server issues an 1040 unsolicited DIAMETER request to the Home Agent, which includes the 1041 information in the original DIAMETER request as well as the 1042 authorization information generated by the home DIAMETER server. The 1043 Home Agent retrieves the Registration Request from the DIAMETER 1044 request and processes it, then generates a Registration Reply that is 1045 sent back to the home DIAMETER server in a DIAMETER response. The 1046 message is forwarded through the broker back to the Local DIAMETER 1047 server, and finally to the Foreign Agent. 1049 The DIAMETER servers maintain session state information based on the 1050 authorization information. If a Mobile Node moves to another Foreign 1051 Agent within the local domain, a request to the local DIAMETER server 1052 can be done in order to immediately return the keys that were issued 1053 to the previous Foreign Agent. This eliminates an additional round 1054 trip through the internet when micro mobility is involved, and 1055 enables smooth hand-off. In order for the DIAMETER server to be able 1056 to provide the keying information to the new Foreign Agent, they must 1057 have a pre-existing security association. 1059 Note that smooth hand-off is really a mobility function, and it is 1060 not clear that DIAMETER should be involved. However, this example is 1061 provided for completeness. 1063 If the Mobile Node enters a service area owned by a new service 1064 provider, the authentication and authorization request will have to 1065 be sent back to the home DIAMETER server, which will create new 1066 keying information. 1068 3.3.1. Minimized Internet Traversal 1070 Although it would have been possible for the DIAMETER interactions to 1071 be performed for basic authentication and authorization, and the 1072 Registration flow to be sent directly to the Home Agent from the 1073 Foreign Agent, one of the key Mobile-IP DIAMETER requirements is to 1074 minimize Internet traversals. Including the Registration Request and 1075 Replies in the DIAMETER messages allows for a single traversal to 1076 authenticate the user, perform authorization and process the 1077 Registration Request. This streamlined approach is required in order 1078 to minimize the latency involved in getting wireless (cellular) 1079 devices access to the network. New registrations should not increase 1080 the connect time more than what the current cellular networks 1081 provide. 1083 3.3.2. Key Distribution 1085 In order to allow the scaling of wireless data access across 1086 administrative domains, it is necessary to minimize the security 1087 associations required. This means that each Foreign Agent does not 1088 share a security association with each Home Agent on the Internet. 1089 The Mobility Agents share a security association with their local 1090 DIAMETER server, which in turn shares a security association with 1091 other DIAMETER servers. Again, the use of brokers (as defined by 1092 ROAMOPS) allows such services to scale by allowing the number of 1093 relationships established by the providers to be reduced. 1095 After a Mobile Node is authenticated, the authorization phase 1096 includes the generation of Sessions Keys. Specifically, three keys 1097 are generated: 1099 - K1 - Key to be shared between the Mobile Node and the Home Agent 1100 - K2 - Key to be shared between the Mobile Node and the Foreign 1101 Agent 1102 - K3 - Key to be shared between the Foreign Agent and the Home 1103 Agent 1105 Each key is encrypted in two separate methods. K1 is encrypted using 1106 SA3 (for the Home Agent), and using SA2 (for the Mobile Node). K2 is 1107 encrypted using SA4 (for the Foreign Agent) and using SA2 (for the 1108 Mobile Node). Lastly, K3 is encrypted using SA4 (for the Foreign 1109 Agent), and using SA3 (for the Home Agent). When the Foreign DIAMETER 1110 Server receives the keys, they are decrypted and re-encrypted using 1111 SA1. All of the Security Associations (SAx) are shown in figure 6. 1113 The keys destined for the foreign and home agent are propagated to 1114 the mobility nodes via the DIAMETER protocol, while the keys destined 1115 for the Mobile Node are sent via the Mobile-IP protocol. 1117 Figure 8 depicts the new security associations used for Mobile-IP 1118 message integrity using the keys derived by the DIAMETER server. 1120 +--------+ +--------+ 1121 | | K3 | | 1122 | FA |======================| HA | 1123 | | | | 1124 +--------+ +--------+ 1125 \\ // 1126 \\ K2 K1 // 1127 \\ +--------+ // 1128 \\ | | // 1129 \=====| MN |=====/ 1130 | | 1131 +--------+ 1132 Figure 8 - Security Association after Key Distribution 1134 Once the session keys have been established and propagated, the 1135 mobility devices can exchange registration information directly 1136 without the need of the DIAMETER infrastructure. However the session 1137 keys have a lifetime, after which the DIAMETER infrastructure must be 1138 used in order to acquire new session keys. 1140 3.4 PPP (ROAMOPS) Extension 1142 The ROAMOPS extension provides authentication and authorization for 1143 PPP users in both intra- and inter-domain networks. The extension 1144 makes use of the attributes defined in the RADIUS protocol to carry 1145 the data objects. This was intended to ease migration of existing 1146 RADIUS servers to DIAMETER since they could share a single dictionary 1147 and user profile. Furthermore, this would reduce the amount of 1148 processing required for an inter-working system that acts as a 1149 RADIUS/DIAMETER bridge. 1151 DIAMETER has native EAP support that solves known problems in the 1152 RADIUS protocol. Furthermore, DIAMETER takes end-to-end 1153 authentication one step further by providing for end-to-end 1154 authentication via PPP's CHAP. This allows for a more secure 1155 authentication infrastructure without having to replace or modify the 1156 installed base of clients. 1158 If end-to-end CHAP is used in bridged DIAMETER/RADIUS environments, 1159 the bridge host is responsible for generating the challenge to the 1160 user. 1162 The remaining authentication and authorization logic found in RADIUS 1163 implementations can then be re-used. The basic changes are the 1164 message formats and the transmission mechanism as defined in the 1165 DIAMETER base protocol. This section does not detail RADIUS 1166 authentication and authorization. The interested reader should refer 1167 to RFC 2138. 1169 3.5 Accounting Extension 1171 The Accounting extension provides usage collection to both the 1172 Mobile-IP and the PPP (ROAMOPS) extensions. The accounting 1173 requirements specifications [6, 8] define that an accounting protocol 1174 must provide the following functionality: 1176 - Negotiable transfer mechanism. 1178 - Provide general purpose AVPs. 1180 - Flexible to allows new extensions to use the accounting 1181 extension. 1183 - Scalable to allows millions to users and thousands of sites. 1185 - Secure accounting data transfer. 1187 The DIAMETER protocol encodes the actual accounting information using 1188 the Accounting Data Interchange Format (ADIF) [24]. ADIF was intended 1189 to allow a uniform encoding of accounting data to be transferred over 1190 virtually any transport (e.g. DIAMETER, SMTP, HTTP, etc). 1192 The DIAMETER Accounting Extension makes extensive use of session 1193 tokens. Session Tokens are created by the server during the 1194 authorization phase. The token includes information about the 1195 session, which is then used by the accounting server to ensure that 1196 the accounting record received corresponds to a previously 1197 authenticated and authorized session. The replay protection and 1198 digital signature embedded within the token is used to minimize 1199 accounting fraud. See [5] for more information. 1201 The DIAMETER Accounting Extension allows accounting information to be 1202 sent in two modes; real-time and batched. Real-time accounting 1203 transfers are useful in environments where timely arrival of the 1204 information is required, such as when debit cards are used. Batched 1205 accounting transfers are useful in environments that do not need up 1206 to the minute accounting records. However, it is possible that in 1207 inter-domain networks, real-time accounting data delivery will be 1208 more popular since the ISPs involved will want to receive some 1209 guarantees of payment prior to providing service. 1211 The DIAMETER protocol is session oriented, and each session typically 1212 has a finite lifetime. Prior to the timeout of a session, a user 1213 typically needs to be re-authentication and/or re-authorized in order 1214 to extend the life of the session. In the Mobile-IP world, this 1215 equates to the mobility registration lifetime, while in PPP this 1216 means that the PPP authentication must be re-opened [5]. When a re- 1217 authentication and/or re-authorization occurs, a new token is 1218 generated, which is used in the corresponding accounting message. 1220 The DIAMETER Accounting Extension supports non-repudiation of both 1221 the request, and the corresponding response. In the RADIUS world, 1222 even if non-repudiation was added to the protocol, an accounting 1223 acknowledgement does not include the information being acknowledged, 1224 making it very difficult to prove that the peer really accepted the 1225 request. The DIAMETER protocol requires that a hash of the accounting 1226 record be included in the response, which can optionally be signed 1227 for non-repudiation. 1229 3.6 DIAMETER Command Naming Conventions 1231 The following conventions are proposed for the naming of Diameter 1232 messages. Diameter commands typically start with an object name, and 1233 end with one of the following verbs: 1235 3.6.1 Request/Answer 1237 Request is used when the command is asking the peer to do something 1238 for it, for example, set up a session, or reconfigure some 1239 parameters. The Answer MUST contain either a positive or negative 1240 result code, telling the requester whether or not the request 1241 successfully occurred. Other information can also be returned in the 1242 Answer. 1244 For example, AA-Request asks the peer device to authorize and/or 1245 authenticate a user in order to set up a session. The request may 1246 fail, thus the answer may be positive or negative. 1248 3.6.2 Query/Response 1250 Query is used when the command is asking for information that it 1251 expects the peer to have. An example would be querying for current 1252 configuration information, or querying for information on resources 1253 or sessions in use. The Response usually contains a positive result 1254 code and the information, or a negative result code with the reason 1255 for not answering the query. 1257 For example, Resource-Query requests the peer device to return 1258 specific information about one or more resources. The answer is 1259 returned in a Resource-Response. 1261 3.6.3 Indication 1263 Indication is used when the command is giving information on 1264 something that is about to or has already occurred. The peer 1265 receiving the message does not respond to the message, but a 1266 transport level acknowledgement must be done in order to ensure that 1267 the message was reliably delivered. 1269 For example the base draft defines a message that is used to ensure 1270 that a peer is still active. This is achieve with the Device- 1271 Watchdog-Ind message, which is acknowledgement as defined in [18]. 1273 4.0 Why not LDAP? 1275 One common question is whether LDAP would provide the functionality 1276 required. 1278 A Server MAY wish to access policies using LDAP, but the use of LDAP 1279 between the client and the server is not possible. The use of LDAP in 1280 this case would require that all routers have read/write access to 1281 the directory. Most customers would not accept this requirements and 1282 it is not efficient. 1284 In the case of roaming, customers would have to open up their 1285 directory so outside routers have writeable access. The security 1286 implications set aside, having 1000's of routers constantly 1287 read/write to the directory would cause some additional problems to 1288 the Directory Service. 1290 Finally, LDAP does not provide server initiated messages which is a 1291 requirement for an AAA protocol. 1293 5.0 References 1295 [1] Rigney, et alia, "RADIUS", RFC-2138, Livingston, April 1997 1297 [2] Veizades, Guttman, Perkins, Kaplan, "Service Location 1298 Protocol", RFC-2165, June 1997. 1300 [3] Aboba, Beadles, "The Network Access Identifier", RFC 2486, 1301 January 1999. 1303 [4] Rigney, "RADIUS Accounting", RFC-2139, April 1997. 1305 [5] G. Zorn, P. Calhoun, "Limiting Fraud in Roaming", 1306 draft-ietf-roamops-fraud-limit-00.txt, IETF Work in Progress, 1307 May 1999. 1309 [6] B. Aboba, J. Arkko, "Introduction to Accounting 1310 Management", draft-aboba-acct-01.txt, IETF Work in Progress 1311 June 1999. 1313 [7] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1314 1996. 1316 [8] J. Arkko, "Requirements for Internet-Scale Accounting 1317 Management", draft-arkko-acctreq-00.txt, IETF Work 1318 in Progress, August 1998. 1320 [9] Bradner, "Key words for use in RFCs to Indicate Requirements 1321 Levels", BCP 14, RFC 2119, March 1997. 1323 [10] L. Blunk, J. Vollbrecht, "Extensible Authentication Protocol 1324 (EAP)", RFC 2284, March 1998. 1326 [11] P. Calhoun, P. Patel, G. Zorn, J. Arkko, "DIAMETER 1327 Accounting Extension", draft-calhoun-diameter-accounting- 1328 00.txt, IETF Work in Progress, October 1999. 1330 [12] J. Case, D. Harrington, R. Presuhn, B. Wijnen, 1331 "Message Processing and Dispatching for the Simple 1332 Network Management Protocol:", RFC 2572, April 1999. 1334 [13] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", 1335 draft-calhoun-diameter-mobileip-02.txt, IETF Work in 1336 Progress, August 1999. 1338 [14] M. Baum, H. Perritt, "Electronic Contracting, Publishing and 1339 EDI Law", Prentice-Hall, ISBN 0-471-53135-9. 1341 [15] P. Calhoun, C. Perkins "Mobile IP Foreign Agent 1342 Challenge/Response Extension", 1343 draft-ietf-mobileip-challenge-02.txt, IETF Work in progress, 1344 May 1999. 1346 [16] D. Harkins, D. Carrell, "The Internet Key Exchange (IKE)" 1347 RFC 1409, November 1998. 1349 [17] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 1350 STD 51, July 1994. 1352 [18] P. Calhoun, A. Rubens, "DIAMETER Base Protocol", 1353 draft-calhoun-diameter-08.txt, IETF Work in Progress, 1354 August 1999. 1356 [19] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming 1357 Protocols", RFC 2477, January 1999. 1359 [20] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang, "Review of 1360 Roaming Implementations", RFC 2194, September 1997. 1362 [21] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy 1363 Implementation in Roaming", RFC 2607, June 1999. 1365 [22] T. Hiller and al, "3G Wireless Data Provider Architecture 1366 Using Mobile IP and AAA", draft-hiller-3gwireless-00.txt, 1367 IETF Work in Progress, March 1999. 1369 [23] E. Gustafsson, A. Jonsson, E. Hubbard, J. Halmkvist, 1370 A. Roos, "Requirements on Mobile IP from a Cellular 1371 Perspective", draft-ietf-mobileip-cellular-requirements- 1372 02.txt, IETF Work in Progress, June 1999. 1374 [24] B. Aboba, D. Lidyard, "The Accounting Data Interchange 1375 Format (ADIF)", draft-roamops-acctng-06.txt, IETF Work 1376 in Progress, August 1999. 1378 [25] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet 1379 Public Key Infrastructure Online Certificate Status 1380 Protocol (OCSP)", RFC 2560, June 1999. 1382 [26] W. Simpson, "PPP Challenge Handshake Authentication 1383 Protocol (CHAP)", RFC 1994, August 1996. 1385 6.0 Acknowledgements 1387 The Authors would like to thanks Bernard Aboba and Jari Arkko for 1388 their Accounting Requirements contribution. Thanks also goes to Erik 1389 Guttman for some very useful comments in helping make this draft more 1390 readable. The Mobile-IP Extension section was text originally 1391 written by Pat Calhoun for another Internet-Draft, which was 1392 subsequently cleaned up by Dave Spence. The authors would like to 1393 thank Nenad Trifunovic, Tony Johansson and Pankaj Patel for their 1394 participation in the Document Reading Party. 1396 7.0 Author's Address 1398 Questions about this memo can be directed to: 1400 Pat R. Calhoun 1401 Sun Laboratories, Network and Security 1402 Sun Microsystems, Inc. 1403 15 Network Circle 1404 Menlo Park, California, 94025 1405 USA 1407 Phone: 1-650-786-7733 1408 Fax: 1-650-786-6445 1409 E-mail: pcalhoun@eng.sun.com 1411 Glen Zorn 1412 Microsoft Corporation 1413 One Microsoft Way 1414 Redmond, WA 98052 1415 USA 1417 Phone: 1-425-703-1559 1418 E-Mail: glennz@microsoft.com 1420 Ping Pan 1421 Bell Laboratories 1422 Lucent Technologies 1423 101 Crawfords Corner Road 1424 Holmdel, NJ 07733 1425 USA 1427 Phone: 1-732-332-6744 1428 E-mail: pingpan@dnrc.bell-labs.com 1430 Haseeb Akhtar 1431 Wireless Technology Labs 1432 Nortel Networks 1433 2221 Lakeside Blvd. 1434 Richardson, TX 75082-4399 1435 USA 1437 Phone: 1-972-684-8850 1438 E-Mail: haseeb@nortelnetworks.com