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