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