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