idnits 2.17.1 draft-ietf-roamops-auth-10.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 247: '...he diagram above SHOULD NOT send a Rep...' RFC 2119 keyword, line 263: '...lementing policy MAY reply directly to...' RFC 2119 keyword, line 265: '...quest, the proxy MUST reply either wit...' RFC 2119 keyword, line 266: '... packet. A proxy MUST NOT reply direct...' RFC 2119 keyword, line 276: '...A proxy MAY also decide to Reject a Re...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 27 has weird spacing: '...t>, and expir...' == Line 179 has weird spacing: '...rver is beyon...' == Line 246 has weird spacing: '...scribed below...' == Line 247 has weird spacing: '...xy2 in the d...' == Line 248 has weird spacing: '...a Reply packe...' == (36 more instances...) -- 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.) -- The document date (11 February 1999) is 9205 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '3' on line 542 looks like a reference -- Missing reference section? '4' on line 384 looks like a reference -- Missing reference section? '6' on line 389 looks like a reference -- Missing reference section? '5' on line 386 looks like a reference -- Missing reference section? '1' on line 374 looks like a reference -- Missing reference section? '2' on line 377 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROAMOPS Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Informational John R. Vollbrecht 5 Merit Networks, Inc. 6 11 February 1999 8 Proxy Chaining and Policy Implementation in Roaming 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet-Drafts as reference material or to cite 21 them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The distribution of this memo is unlimited. It is filed as , and expires August 1, 1999. Please send comments 28 to the authors. 30 2. Copyright Notice 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 3. Abstract 36 This document describes how proxy chaining and policy implementation can 37 be supported in roaming systems. The mechanisms described in this 38 document are in current use. 40 However, as noted in the security considerations section, the techniques 41 outlined in this document are vulnerable to attack from external parties 42 as well as susceptible to fraud perpetrated by the roaming partners 43 themselves. As a result, such methods are not suitable for wide-scale 44 deployment on the Internet. 46 4. Terminology 48 This document frequently uses the following terms: 50 Network Access Server 51 The Network Access Server (NAS) is the device that clients 52 contact in order to get access to the network. 54 RADIUS server 55 This is a server which provides for 56 authentication/authorization via the protocol described in 57 [3], and for accounting as described in [4]. 59 RADIUS proxy 60 In order to provide for the routing of RADIUS authentication 61 and accounting requests, a RADIUS proxy can be employed. To 62 the NAS, the RADIUS proxy appears to act as a RADIUS server, 63 and to the RADIUS server, the proxy appears to act as a RADIUS 64 client. 66 Network Access Identifier 67 In order to provide for the routing of RADIUS authentication 68 and accounting requests, the userID field used in PPP (known 69 as the Network Access Identifier or NAI) and in the subsequent 70 RADIUS authentication and accounting requests, can contain 71 structure. This structure provides a means by which the RADIUS 72 proxy will locate the RADIUS server that is to receive the 73 request. The NAI is defined in [6]. 75 Roaming relationships 76 Roaming relationships include relationships between companies 77 and ISPs, relationships among peer ISPs within a roaming 78 association, and relationships between an ISP and a roaming 79 consortia. Together, the set of relationships forming a path 80 between a local ISP's authentication proxy and the home 81 authentication server is known as the roaming relationship 82 path. 84 5. Requirements language 86 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 87 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 88 described in [5]. 90 6. Introduction 92 Today, as described in [1], proxy chaining is widely deployed for the 93 purposes of providing roaming services. In such systems, 94 authentication/authorization and accounting packets are routed between a 95 NAS device and a home server through a series of proxies. Consultation 96 of the home server is required for password-based authentication, since 97 the home server maintains the password database and thus it is necessary 98 for the NAS to communicate with the home authentication server in order 99 to verify the user's identity. 101 6.1. Advantages of proxy chaining 103 Proxies serve a number of functions in roaming, including: 105 Scalability improvement 106 Authentication forwarding 107 Capabilities adjustment 108 Policy implementation 109 Accounting reliability improvement 110 Atomic operation 112 Scalability improvement 113 In large scale roaming systems, it is necessary to provide for 114 scalable management of keys used for integrity protection and 115 authentication. 117 Proxy chaining enables implementation of hierarchical 118 forwarding within roaming systems, which improves scalability 119 in roaming consortia based on authentication protocols without 120 automated key management. Since RADIUS as described in [3] 121 requires a shared secret for each client-server pair, a 122 consortium of 100 roaming partners would require 4950 shared 123 secrets if each partner were to contact each other directly, 124 one for each partner pair. However, were the partners to 125 route authentication requests through a central proxy, only 126 100 shared secrets would be needed, one for each partner. The 127 reduction in the number of partner pairs also brings with it 128 other benefits, such as a reduction in the number of bilateral 129 agreements and accounting and auditing overhead. Thus, 130 hierarchical routing might be desirable even if an 131 authentiation protocol supporting automated key exchange were 132 available. 134 Capabilities adjustment 135 As part of the authentication exchange with the home server, 136 the NAS receives authorization parameters describing the 137 service to be provided to the roaming user. Since RADIUS, 138 described in [3], does not support capabilities negotiation, 139 it is possible that the authorization parameters sent by the 140 home server will not match those required by the NAS. For 141 example, a static IP address could be specified that would not 142 be routable by the NAS. As a result, capbilities adjustment is 143 performed by proxies in order to enable communication between 144 NASes and home servers with very different feature sets. 146 As part of capabilities adjustment, proxies can edit 147 attributes within the Access-Accept in order to ensure 148 compatibility with the NAS. Such editing may include 149 addition, deletion, or modification of attributes. In 150 addition, in some cases it may be desirable for a proxy to 151 edit attributes within an Access-Request in order to clean up 152 or even hide information destined for the home server. Note 153 that if the proxy edits attributes within the Access-Accept, 154 then it is possible that the service provided to the user may 155 not be the same as that requested by the home server. This 156 creates the possibility of disputes arising from inappropriate 157 capabilities adjustment. 159 Note that were roaming to be implemented based on an 160 authentication/authorization protocol with built-in capability 161 negotiation, proxy-based capabilities adjustment would 162 probably not be necessary. 164 Authentication forwarding 165 Since roaming associations frequently implement hierarchical 166 forwarding in order to improve scalability, in order for a NAS 167 and home server to communicate, authentication and accounting 168 packets are forwarded by one or more proxies. The path 169 travelled by these packets, known as the roaming relationship 170 path, is determined from the Network Access Identifier (NAI), 171 described in [6]. Since most NAS devices do not implement 172 forwarding logic, a proxy is needed to enable forwarding of 173 authentication and accounting packets. For reasons that are 174 described in the security section, in proxy systems it is 175 desirable for accounting and authentication packets to follow 176 the same path. 178 Note: The way a proxy learns the mapping between NAI and the 179 home server is beyond the scope of this document. This 180 mapping can be accomplished by static configuration in the 181 proxy, or by some currently undefined protocol that provides 182 for dynamic mapping. For the purposes of this document, it is 183 assumed that such a mapping capability exists in the proxy. 185 Policy implementation 186 In roaming systems it is often desirable to be able to 187 implement policy. For example, a given partner may only be 188 entitled to use of a given NAS during certain times of the 189 day. In order to implement such policies, proxies may be 190 implemented at the interface between administrative domains 191 and programmed to modify authentication/authorization packets 192 forwarded between the NAS and the home server.As a result, 193 from a security point of view, a proxy implementing policy 194 operates as a "man in the middle." 196 Accounting reliability improvement 197 In roaming systems based on proxy chaining, it is necessary 198 for accounting information to be forwarded between the NAS and 199 the home server. Thus roaming is inherently an interdomain 200 application. 202 This represents a problem since the RADIUS accounting 203 protocol, described in [4] is not designed for use on an 204 Internet scale. Given that in roaming accounting packets 205 travel between administrative domains, packets will often pass 206 through network access points (NAPs) where packet loss may be 207 substantial. This can result in unacceptable rates of 208 accounting data loss. 210 For example, in a proxy chaining system involving four 211 systems, a one percent failure rate on each hop can result in 212 loss of 3.9 percent of all accounting transactions. Placement 213 of an accounting proxy near the NAS may improve reliability by 214 enabling enabling persistent storage of accounting records and 215 long duration retry. 217 Atomic operation 218 In order to ensure consistency among all parties required to 219 process accounting data, it can be desirable to assure that 220 transmission of accounting data is handled as an atomic 221 operation. This implies that all parties on the roaming 222 relationship path will receive and acknowledge the receipt of 223 the accounting data for the operation to complete. Proxies can 224 be used to ensure atomic delivery of accounting data by 225 arranging for delivery of the accounting data in a serial 226 fashion, as discussed in section 7.2. 228 7. Proxy chaining 230 An example of a proxy chaining system is shown below. 232 (request) (request) (request) 233 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 234 (reply) (reply) (reply) Server 235 <--------- <--------- <--------- 237 In the above diagram, the NAS generates a request and sends it to 238 Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the 239 request to the Home Server. The Home Server generates a reply and sends 240 it to Proxy2. Proxy2 receives the reply, matches it with the request it 241 had sent, and forwards a reply to Proxy1. Proxy1 matches the reply with 242 the request it sent earlier and forwards a reply to the NAS. This model 243 applies to all requests, including Access Requests and Accounting 244 Requests. 246 Except for the two cases described below, a proxy server such as 247 Proxy2 in the diagram above SHOULD NOT send a Reply packet to Proxy1 248 without first having received a Reply packet initiated by the Home 249 Server. The two exceptions are when the proxy is enforcing policy as 250 described in section 7.1 and when the proxy is acting as an 251 accounting store (as in store and forward), as described in section 252 7.2. 254 The RADIUS protocol described in [3] does not provide for end-to-end 255 security services, including integrity or replay protection, 256 authentication or confidentiality. As noted in the security 257 considerations section, this omission results in several security 258 problems within proxy chaining systems. 260 7.1. Policy implementation 262 Proxies are frequently used to implement policy in roaming situations. 263 Proxies implementing policy MAY reply directly to Access-Requests 264 without forwarding the request. When replying directly to an Access- 265 Request, the proxy MUST reply either with an Access-Reject or an Access- 266 Challenge packet. A proxy MUST NOT reply directly with an Access-Accept. 267 An example of this would be when the proxy refuses all connections from 268 a particular realm during prime time. In this case the home server will 269 never receive th Access-Request. This situation is shown below: 271 (request) (request) 272 NAS ----------> Proxy1 ----------> Proxy2 Home 273 (reply) (reply) Server 274 <--------- <--------- 276 A proxy MAY also decide to Reject a Request that has been accepted by 277 the home server. This could be based on the set of attributes returned 278 by the home server. In this case the Proxy SHOULD send an Access-Reject 279 to the NAS and an Accounting-Request with Acct-Status-Type=Proxy-Stop 280 (6) to the home server. This lets the home server know that the session 281 it approved has been denied downstream by the proxy. However, a proxy 282 MUST NOT send an Access-Accept after receiving an Access-Reject from a 283 proxy or from the home server. 285 (Access-Req) (Access-Req) (Access-Req) 286 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 287 (Access-Reject) (Access-Accept) (Access-Accept) Server 288 <--------- <--------- <--------- 289 (AcctPxStop) (AcctPxStop) 290 ----------> ----------> 292 7.2. Accounting behavior 294 As described above, a proxy MUST NOT reply directly with an Access- 295 Accept, and MUST NOT reply with an Access-Accept when it has received 296 an Access-Reject from another proxy or Home Server. As a result, in 297 all cases where an accounting record is to be generated (accepted 298 sessions), no direct replies have occurred, and the Access-Request 299 and Access-Accept have passed through the same set of systems. 301 In order to allow proxies to match incoming Accounting-Requests with 302 previously handled Access-Requests and Access-Accepts, a proxy SHOULD 303 route the Accounting-Request along the same realm path travelled in 304 authentication/authorization. Note that this does not imply that 305 accounting packets will necessarily travel the identical path, machine 306 by machine, as did authentication/authorization packets. This is 307 because it is conceivable that a proxy may have gone down, and as a 308 result the Accounting-request may need to be forwarded to an alternate 309 server. It is also conceivable that authentication/authorization and 310 accounting may be handled by different servers within a realm. 312 The Class attribute can be used to match Accounting Requests with 313 prior Access Requests. It can also be used to match session log 314 records between the home Server, proxies, and NAS. This matching can 315 be accomplished either in real-time (in the case that authentication 316 and accounting packets follow the same path, machine by machine), or 317 after the fact. 319 Home servers SHOULD insert a unique session identifier in the Class 320 attribute in an Access-Accept and Access-Challenge. Proxies and NASes 321 MUST forward the unmodified Class attribute. The NAS MUST include the 322 Class attribute in subsequent requests, in particular for Accounting- 323 Requests. The sequence of events is shown below: 325 Authentication/Authorization 327 --------> --------> ---------> 328 NAS Proxy1 Proxy2 Home (add class) 329 <-class-- <-class- <-class-- 331 Accounting 333 (Accounting-req) (Accounting-req) (Accounting-req) 334 w/class w/class w/class 335 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 336 (Accounting-reply) (Accounting-reply)(Accounting-reply) Server 337 <--------- <--------- <--------- 339 Since there is no need to implement policy in accounting, a proxy MUST 340 forward all Accounting Requests to the next server on the path. The 341 proxy MUST guarantee that the Accounting Request is received by the 342 End Server and all intermediate servers. The proxy may do this either 343 by: 1) forwarding the Accounting Request and not sending a Reply until 344 it receives the matching Reply from the upstream server, or 2) 345 acting as a store point which takes responsibility for reforwarding 346 the Accounting Request until it receives a Reply. 348 Note that when the proxy does not send a reply until it receives a 349 matching reply, this ensures that Accounting Start and Stop messages are 350 received and can be logged by all servers along the roaming 351 relationship path. If one of the servers is not available, then the 352 operation will fail. As a result the entire accounting transaction will 353 either succeed or fail as a unit, and thus can be said to be atomic. 355 Where store and forward is implemented, it is possible that one or more 356 servers along the roaming relationship path will not receive the 357 accounting data while others will. The accounting operation will not 358 succeed or fail as a unit, and is therefore not atomic. As a result, it 359 may not be possible for the roaming partners to reconcile their audit 360 logs, opening new opportunities for fraud. Where store and forward is 361 implemented, forwarding of Accounting Requests SHOULD be done as they 362 are received so the downstream servers will receive them in a timely 363 way. 365 Note that there are cases where a proxy will need to forward an 366 Accounting packet to more than one system. For example, in order to 367 allow for proper accounting in the case of a NAS that is shutting 368 down, the proxy can send an Accounting-Request with Acct-Status- 369 Type=Accounting-Off (8) to all realms that it forwards to. In turn, 370 these proxies will also flood the packet to their connected realms. 372 8. References 374 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming 375 Implementations", RFC 2194, September 1997. 377 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 378 Protocols", RFC 2477, January 1999. 380 [3] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 381 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 382 1997. 384 [4] Rigney, C., "RADIUS Accounting." RFC 2139, April 1997. 386 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 387 Levels", BCP 14, RFC 2119, March 1997. 389 [6] Aboba, B., and M. Beadles, "The Network Access Identifier", 390 RFC 2486, January 1999. 392 9. Security Considerations 394 The RADIUS protocol described in [3] was designed for intra-domain use, 395 where the NAS, proxy, and home server exist within a single 396 administrative domain, and proxies may be considered a trusted 397 component. However, in roaming the NAS, proxies, and home server will 398 typically be managed by different administrative entities. As a result, 399 roaming is inherently an inter-domain application, and proxies cannot 400 necessarily be trusted. This results in a number of security threats, 401 including: 403 Message editing 404 Attribute editing 405 Theft of passwords 406 Theft and modification of accounting data 407 Replay attacks 408 Connection hijacking 409 Fraudulent accounting 411 9.1. Message editing 413 Through the use of shared secrets it is possible for proxies operating 414 in different domains to establish a trust relationship. However, if only 415 hop-by-hop security is available then untrusted proxies are capable of 416 perpetrating a number of man-in-the-middle attacks. These include 417 modification of messages. 419 For example, an Access-Accept could be substituted for an Access-Reject, 420 and without end-to-end integrity protection, there is no way for the NAS 421 to detect this. On the home server, this will result in an accounting 422 log entry for a session that was not authorized. However, if the proxy 423 does not forward accounting packets or session records to the home 424 server, then the home server will not be able to detect the discrepancy 425 until a bill is received and audited. 427 Note that a proxy can also send an Access-Reject to the NAS after 428 receiving an Access-Accept from the home server. This will result in an 429 authentication log entry without a corresponding accounting log entry. 430 Without the proxy sending an Accounting-Request with Acct-Status- 431 Type=Proxy-Stop (6) to the home server, then there will be no way for 432 the home server to determine whether the discrepancy is due to policy 433 implementation or loss of accounting packets. Thus the use of Acct- 434 Status-Type=Proxy-Stop can be of value in debugging roaming systems. 436 It should be noted that even if end-to-end security were to be 437 available, a number of sticky questions would remain. While the end- 438 points would be able to detect that the message from the home server had 439 been modified by an intermediary, the question arises as to what action 440 should be taken. While the modified packet could be silently discarded, 441 this could affect the ability of the home server to . accept an Acct- 442 Status-Type=Proxy-Stop message from an intermediate proxy. Since this 443 message would not be signed by the NAS, it may need to be dropped by the 444 home server. 446 This is similar to the problem that IPSEC-capable systems face in making 447 use of ICMP messages from systems with whom they do not have a security 448 association. The problem is more difficult here, since in RADIUS 449 retransmission is driven by the NAS. Therefore the home server does not 450 receive acknowledgement for Access-Accepts and thus would have no way of 451 knowing that its response has not been honored. 453 9.2. Attribute editing 455 RADIUS as defined in [3] does not provide for end-to-end security or 456 capabilities negotiation. As a result there is no way for a home server 457 to securely negotiate a mutually acceptable configuration with the NAS 458 or proxies. As a result, a number of attribute editing attacks are 459 possible. 461 For example, EAP attributes might be removed or modified so as to cause 462 a client to authenticate with EAP MD5 or PAP, instead of a stronger 463 authentication method. Alternatively, tunnel attributes might be removed 464 or modified so as to remove encryption, redirect the tunnel to a rogue 465 tunnel server, or otherwise lessen the security provided to the client. 466 The mismatch between requested and received services may only be 467 detectable after the fact by comparing the Access-Accept attributes 468 against the attributes included in the Accounting-Request. However, 469 without end-to-end security services, it is possible for a rogue proxy 470 to cover its tracks. 472 Due to the complexity of proxy configuration, such attacks need not 473 involve malice, but can occur due to mis-configuration or implementation 474 deficiencies. Today several proxy implementations remove attributes 475 that they do not understand, or can be set up to replace attribute sets 476 sent in the Access-Accept with sets of attributes appropriate for a 477 particular NAS. 479 In practice, it is not possible to define a set of guidelines for 480 attribute editing, since the requirements are very often implementation- 481 specific. At the same time, protection against inappropriate attribute 482 editing is necessary to guard against attacks and provide assurance that 483 users are provisioned as directed by the home server. 485 Since it is not possible to determine beforehand whether a given 486 attribute is editable or not, a mechanism needs to be provided to allow 487 senders to indicate which attributes are editable and which are not, and 488 for the receivers to detect modifications of "non-editable" attributes. 489 Through implementation of end-to-end security it may be possible to 490 detect unauthorized addition, deletion, or modification of integrity- 491 protected attributes. However, it would still possible for a rogue proxy 492 to add, delete or modify attributes that are not integrity-protected. If 493 such attributes influence subsequent charges, then the possibility of 494 fraud would remain. 496 9.3. Theft of passwords 498 RADIUS as defined in [3] does not provide for end-to-end 499 confidentiality. As a result, where clients authenticate using PAP, each 500 proxy along the path between the local NAS and the home server will have 501 access to the cleartext password. In many circumstances, this represents 502 an unacceptable security risk. 504 9.4. Theft and modification of accounting data 506 Typically in roaming systems, accounting packets are provided to all the 507 participants along the roaming relationship path, in order to allow them 508 to audit subsequent invoices. RADIUS as described in [3] does not 509 provide for end-to-end security services, including integrity protection 510 or confidentiality. Without end-to-end integrity protection, it is 511 possible for proxies to modify accounting packets or session records. 512 Without end-to-end confidentiality, accounting data will be accessible 513 to proxies. However, if the objective is merely to prevent snooping of 514 accounting data on the wire, then IPSEC ESP can be used. 516 9.5. Replay attacks 518 In this attack, a man in the middle or rogue proxy collects CHAP- 519 Challenge and CHAP-Response attributes, and later replays them. If this 520 attack is performed in collaboration with an unscrupulous ISP, it can be 521 used to subsequently submit fraudulent accounting records for payment. 522 The system performing the replay need not necessarily be the one that 523 initially captured the CHAP Challenge/Response pair. 525 While RADIUS as described in [3] is vulnerable to replay attacks, 526 without roaming the threat is restricted to proxies operating in the 527 home server's domain. With roaming, such an attack can be mounted by any 528 proxy capable of reaching the home server. 530 9.6. Connection hijacking 532 In this form of attack, the attacker attempts to inject packets into the 533 conversation between the NAS and the home server. RADIUS as described in 534 [3] is vulnerable to such attacks since only Access-Reply and Access- 535 Challenge packets are authenticated. 537 9.7. Fraudulent accounting 539 In this form of attack, a local proxy transmits fraudulent accounting 540 packets or session records in an effort to collect fees to which they 541 are not entitled. This includes submission of packets or session records 542 for non-existent sessions. Since in RADIUS as described in [3], there is 543 no end-to-end security, a rogue proxy may insert or edit packets without 544 fear of detection. 546 In order to detect submissions of accounting packets or session records 547 for non-existent sessions, parties receiving accounting packets or 548 session records would be prudent to reconcile them with the 549 authentication logs. Such reconciliation is only typically possible when 550 the party acts as an authentication proxy for all sessions for which an 551 accounting record will subsequently be submitted. 553 In order to make reconciliation easier, home servers involved in roaming 554 include a Class attribute in the Access-Accept. The Class attribute 555 uniquely identifies a session, so as to allow an authentication log 556 entry to be matched with a corresponding accounting packet or session 557 record. 559 If reconciliation is put in place and all accounting log entries without 560 a corresponding authentication are rejected, then the attacker will need 561 to have obtained a valid user password prior to submitting accounting 562 packets or session records on non-existent sessions. While use of end- 563 to-end security can defeat unauthorized injection or editing of 564 accounting or authentication packets by intermediate proxies, other 565 attacks remain feasible. For example, unless replay protection is put in 566 place, it is still feasible for an intermediate proxy to resubmit 567 authentication or accounting packets or session records. In addition, 568 end-to-end security does not provide protection against attacks by the 569 local proxy, since this is typically where end-to-end security will be 570 initiated. To detect such attacks, other measures need to be put in 571 place, such as systems for detecting unusual activity of ISP or user 572 accounts, or for determining whether a user or ISP account is within 573 their credit limit. 575 Note that implementation of the store and forward approach to proxy 576 accounting makes it possible for some systems in the roaming 577 relationship path to receive accounting records that other systems do 578 not get. This can result in audit discrepancies. About the best that is 579 achievable in such cases is to verify that the accounting data is 580 missing by checking against the authentication logs. 582 10. Acknowledgments 584 Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, 585 Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain 586 of Shore.Net for useful discussions of this problem space. 588 11. Authors' Addresses 590 Bernard Aboba 591 Microsoft Corporation 592 One Microsoft Way 593 Redmond, WA 98052 594 Phone: 425-936-6605 595 EMail: bernarda@microsoft.com 597 John R. Vollbrecht 598 Merit Network, Inc. 599 4251 Plymouth Rd. 600 Ann Arbor, MI 48105-2785 602 Phone: 313-763-1206 603 EMail: jrv@merit.edu 605 12. Full Copyright Statement 607 Copyright (C) The Internet Society (1998). All Rights Reserved. 608 This document and translations of it may be copied and furnished to 609 others, and derivative works that comment on or otherwise explain it or 610 assist in its implmentation may be prepared, copied, published and 611 distributed, in whole or in part, without restriction of any kind, 612 provided that the above copyright notice and this paragraph are included 613 on all such copies and derivative works. However, this document itself 614 may not be modified in any way, such as by removing the copyright notice 615 or references to the Internet Society or other Internet organizations, 616 except as needed for the purpose of developing Internet standards in 617 which case the procedures for copyrights defined in the Internet 618 Standards process must be followed, or as required to translate it into 619 languages other than English. The limited permissions granted above are 620 perpetual and will not be revoked by the Internet Society or its 621 successors or assigns. This document and the information contained 622 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 623 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 624 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 625 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 626 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 628 13. Expiration Date 630 This memo is filed as , and expires August 631 1, 1999.