idnits 2.17.1 draft-ietf-roamops-auth-08.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 552 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 61 lines 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.) ** There are 221 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 322 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 205: '...ature attributes SHOULD be included in...' RFC 2119 keyword, line 207: '...t packets. The Hidden attribute MAY be...' RFC 2119 keyword, line 214: '...ementing policy MAY reply directly ...' RFC 2119 keyword, line 216: '...quest, the proxy MUST reply either w...' RFC 2119 keyword, line 217: '...cket. A proxy MUST NOT reply dire...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 13 has weird spacing: '...), its areas...' == Line 14 has weird spacing: '... its worki...' == Line 18 has weird spacing: '... and may ...' == Line 19 has weird spacing: '...afts as refer...' == Line 22 has weird spacing: '... To learn...' == (216 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 (13 October 1998) is 9326 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 497 looks like a reference -- Missing reference section? '4' on line 362 looks like a reference -- Missing reference section? '6' on line 367 looks like a reference -- Missing reference section? '5' on line 364 looks like a reference -- Missing reference section? '1' on line 353 looks like a reference -- Missing reference section? '7' on line 500 looks like a reference -- Missing reference section? '2' on line 356 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: Standards Track John R. Vollbrecht 5 Merit Networks, Inc. 6 13 October 1998 8 Proxy Chaining and Policy Implementation in Roaming 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working docu- 13 ments of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute work- 15 ing documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 The distribution of this memo is unlimited. It is filed as , and expires May 1, 1999. Please send com- 29 ments to the authors. 31 2. Copyright Notice 33 Copyright (C) The Internet Society (1998). All Rights Reserved. 35 3. Abstract 37 This document describes the use of proxy chaining in roaming and how 38 policy may be implemented concurrently with end-to-end security. 40 4. Terminology 42 This document frequently uses the following terms: 44 Network Access Server 45 The Network Access Server (NAS) is the device that clients 46 contact in order to get access to the network. 48 RADIUS server 49 This is a server which provides for 50 authentication/authorization via the protocol described in 51 [3], and for accounting as described in [4]. 53 RADIUS proxy 54 In order to provide for the routing of RADIUS authentication 55 and accounting requests, a RADIUS proxy can be employed. To 56 the NAS, the RADIUS proxy appears to act as a RADIUS server, 57 and to the RADIUS server, the proxy appears to act as a 58 RADIUS client. 60 Network Access Identifier 61 In order to provide for the routing of RADIUS authentication 62 and accounting requests, the userID field used in PPP (known 63 as the Network Access Identifier or NAI) and in the subse- 64 quent RADIUS authentication and accounting requests, can 65 contain structure. This structure provides a means by which 66 the RADIUS proxy will locate the RADIUS server that is to 67 receive the request. The NAI is defined in [6]. 69 Roaming relationships 70 Roaming relationships include relationships between compa- 71 nies and ISPs, relationships among peer ISPs within a roam- 72 ing association, and relationships between an ISP and a 73 roaming consortia. Together, the set of relationships form- 74 ing a path between a local ISP's authentication proxy and 75 the home authentication server is known as the roaming rela- 76 tionship path. 78 5. Requirements language 80 In this document, the key words "MAY", "MUST, "MUST NOT", 81 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 82 interpreted as described in [5]. 84 6. Introduction 86 Today, as described in [1], proxy chaining is widely deployed for the 87 purposes of providing roaming services. In such systems, authentica- 88 tion and accounting packets are routed between a NAS device and a home 89 server through a series of proxies. 91 Proxies serve a number of functions in roaming, including: 93 Scalability improvement 94 Authentication forwarding 95 Capabilities adjustment 96 Policy implementation 97 Accounting reliability improvement 98 Atomic operation 100 It should be noted that while a number of these functions can be pro- 101 vided within a new protocol, thus reducing the need to use proxies to 102 perform these functions, the policy implementation function is funda- 103 mental and therefore is likely to remain, regardless of the protocol 104 chosen. 106 Scalability improvement 107 Proxy chaining enables implementation of hierarchical for- 108 warding within roaming systems, which significantly improves 109 scalability. Since RADIUS requires a shared secret for each 110 communicating pair of systems, a consortium of 100 roaming 111 partners would require 4950 shared secrets if each partner 112 were to contact each other directly, one for each partner 113 pair. However, were the partners to route authentication 114 requests through a central proxy, only 100 shared secrets 115 would be needed, one for each partner. 117 Authentication forwarding 118 Since roaming partners typically do not communicate directly 119 due to scalability concerns, in order for a NAS and home 120 server to communicate, authentication and accounting packets 121 are forwarded by one or more proxies. The path travelled by 122 these packets, known as the roaming relationship path, is 123 determined from the Network Access Identifier (NAI), 124 described in [6]. Since most NAS devices do not implement 125 forwarding logic, a proxy is needed to enable proper routing 126 of authentication and accounting packets. 128 Note: The way a proxy learns the mapping between NAI and 129 end servers is beyond the scope of this document. This 130 mapping can be done by static configuration in the proxy, or 131 by some currently undefined pro- tocol that get the mapping 132 information dynamically. The assumption is that such a map- 133 ping exists in the proxy. 135 Capabilities adjustment 136 Since RADIUS does not support capabilities negotiation, it 137 is possible that network parameters sent back from the home 138 server will not match those required by the NAS. Proxies 139 can edit attributes within the Access-Accept in order to 140 ensure compatibility. Such editing may include addition, 141 deletion, or modification of attributes. In addition, in 142 some cases it may be desirable for a proxy to edit 143 attributes within an Access-Request. Note that if the proxy 144 edits attributes within the Access-Accept, then it is possi- 145 ble that the service provided to the user may not be the 146 same as that requested by the home server. 148 Policy implementation 149 RADIUS proxies can be used to implement policy. For example, 150 a given partner may only be entitled to use of a given NAS 151 during certain times of the day. 153 Accounting reliability improvement 154 The RADIUS accounting protocol, described in [4] is not 155 designed for use on an Internet scale. This is a significant 156 issue in roaming, which is inherently an interdomain appli- 157 cation. Given that in roaming accounting packets travel 158 between administrative domains, packets will often pass 159 through network access points (NAPs) where packet loss may 160 be substantial. This can result in unacceptable rates of 161 accounting data loss. For example, in a proxy chaining sys- 162 tem involving four systems, a one percent failure rate on 163 each hop can result in loss of 3.9 percent of all accounting 164 transactions. Placement of an accounting proxy near the NAS 165 may improve reliability by enabling enabling persistent 166 storage of accounting records and long duration retry. 168 Atomic operation 169 In order to ensure consistency among all parties required to 170 process accounting data, it can be desirable to assure that 171 transmission of accounting data is handled as an atomic 172 operation. This implies that all parties on the roaming 173 relationship path will receive and acknowledge the receipt 174 of the accounting data for the operation to complete. 176 7. Proxy chaining 178 An example of a proxy chaining system is shown below. 180 (request) (request) (request) 181 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 182 (reply) (reply) (reply) Server 183 <--------- <--------- <--------- 185 In the above agram, the NAS generates a request and sends it to 186 Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the 187 request to the Home Server. The Home Server generates a reply and 188 sends it to Proxy2. Proxy2 receives the reply, matches it with the 189 request it had sent, and forwards a reply to Proxy1. Proxy1 matches 190 the reply with the request it sent earlier and forwards a reply to the 191 NAS. This model applies to all requests, including Access Requests 192 and Accounting Requests. 194 Except for the two cases described below, a proxy server such as 195 Proxy2 in the diagram above should not send a Reply packet to Proxy1 196 without first having received a Reply packet initiated by the Home 197 Server. The two exceptions are when the proxy is enforcing policy as 198 described in section 7.1 and when the proxy is acting as an 199 accounting store (as in store and forward), as described in section 200 7.2. 202 While the RADIUS protocol described in [3] does not provide for end- 203 to-end security services, this is made possible using the attributes 204 described in [7]. The Security-Parameter-Index and End-to-End- 205 Signature attributes SHOULD be included in packets sent between admin- 206 istrative domains, including Access-Request, Access-Challenge, 207 Access-Accept, and Access-Reject packets. The Hidden attribute MAY be 208 included, as necessary, in order to prevent disclosure of passwords or 209 keys to untrusted proxies. 211 7.1. Policy implementation 213 Proxies are frequently used to implement policy in roaming situations. 214 Proxies implementing policy MAY reply directly to Access-Requests 215 without forwarding the request. When replying directly to an Access- 216 Request, the proxy MUST reply either with an Access-Reject or an 217 Access-Challenge packet. A proxy MUST NOT reply directly with an 218 Access-Accept. An example of this would be when the proxy refuses all 219 connections from a particular realm during prime time. In this case 220 the home server will never receive the Access-Request. This situation 221 is shown below: 223 (request) (request) 224 NAS ----------> Proxy1 ----------> Proxy2 Home 225 (reply) (reply) Server 226 <--------- <--------- 228 A proxy MAY also decide to Reject a Request that has been accepted by 229 the home server. This could be based on the set of attributes 230 returned by the home server. In this case the Proxy SHOULD send an 231 Access-Reject to the NAS and an Accounting-Request with Acct-Status- 232 Type=Proxy-Stop (6) to the home server. This lets the home server 233 know that the session it approved has been denied downstream by the 234 proxy. However, a proxy MUST NOT send an Access-Accept after receiv- 235 ing an Access-Reject from a proxy or from the home server. 237 (Access-Req) (Access-Req) (Access-Req) 238 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 239 (Access-Reject) (Access-Accept) (Access-Accept) Server 240 <--------- <--------- <--------- 241 (AcctPxStop) (AcctPxStop) 242 ----------> ----------> 244 7.2. Accounting behavior 246 As described above, a proxy MUST NOT reply directly with an Access- 247 Accept, and MUST NOT reply with an Access-Accept when it has received 248 an Access-Reject from another proxy or Home Server. As a result, in 249 all cases where an accounting record is to be generated (accepted ses- 250 sions), no direct replies have occurred, and the Access-Request and 251 Access-Accept have passed through the same set of systems. 253 In order to allow proxies to match incoming Accounting-Requests with 254 previously handled Access-Requests and Access-Accepts, a proxy SHOULD 255 route the Accounting-Request along the same realm path travelled in 256 authentication/authorization. Note that this does not imply that 257 accounting packets will necessarily travel the identical path, machine 258 by machine, as did authentication/authorization packets. This is 259 because it is conceivable that a proxy may have gone down, and as a 260 result the Accounting-request may need to be forwarded to an alternate 261 server. It is also conceivable that authentication/authorization and 262 accounting may be handled by different servers within a realm. 264 The Class attribute can be used to match Accounting Requests with 265 prior Access Requests. It can also be used to match session log 266 records between the home Server, proxies, and NAS. This matching can 267 be accomplished either in real-time (in the case that authentication 268 and accounting packets follow the same path, machine by machine), or 269 after the fact. 271 Home servers SHOULD insert a unique session identifier in the Class 272 attribute in an Access-Accept and Access-Challenge. Proxies and NASes 273 MUST forward the unmodified Class attribute. The NAS MUST include the 274 Class attribute in subsequent requests, in particular for Accounting- 275 Requests. The sequence of events is shown below: 277 Authentication/Authorization 279 --------> --------> ---------> 280 NAS Proxy1 Proxy2 Home (add class) 281 <-class-- <-class- <-class-- 283 Accounting 285 (Accounting-req) (Accounting-req) (Accounting-req) 286 w/class w/class w/class 287 NAS ----------> Proxy1 ----------> Proxy2 ----------> Home 288 (Accounting-reply) (Accounting-reply)(Accounting-reply) Server 289 <--------- <--------- <--------- 291 Since there is no need to implement policy in accounting, a proxy MUST 292 forward all Accounting Requests to the next server on the path. The 293 proxy MUST guarantee that the Accounting Request is received by the 294 End Server and all intermediate servers. The proxy may do this either 295 by: 1) forarding the Accounting Request and not sending a Reply until 296 it receives the matching Reply from the upstream server, or 2) 297 acting as a Store point which takes responsibility for reforwarding 298 the Accounting Request until it receives a Reply. Note that in the 299 former arrangement, atmoic operation can be supported, while in the 300 latter case it typically cannot. 302 This ensures that Accounting Start and Stop messages are received, and 303 can be logged by all servers along the authentication/authorization 304 path. Forwarding of Accounting Requests SHOULD be done as they are 305 received so the downstream servers will receive them in a timely way. 307 Note that there are cases where a proxy may need to forward an 308 Accounting packet to more than one system. For example, in order to 309 allow for proper accounting in the case of a NAS that is shutting 310 down, the proxy may need to send an Accounting-Request with Acct- 311 Status-Type=Accounting-Off (8) to all realms that it forwards to. In 312 turn, these proxies will also flood the packet to their connected 313 realms. 315 8. Attribute editing 317 One of the biggest obstacles to interoperation of proxies today 318 results from editing behavior. Today several proxy implementations 319 remove attributes that they do not understand, or can be set up to 320 replace attribute sets sent in the Access-Accept with sets of 321 attributes appropriate for a particular NAS. 323 In practice, it is not possible to define a set of guidelines for 324 attribute editing, since the requirements are very often implementa- 325 tion-specific. However, using the end-to-end security attributes 326 defined in [7], it is possible to provide for both "protected" and 327 "unprotected" attributes. Protected attributes preceed an End-to-End- 328 Signature attribute within the packet, and as a result, these 329 attributes are integrity-protected end-to-end. Protected attributes 330 MUST NOT be added, deleted, or modified by a proxy. 332 Unprotected attributes follow the End-to-End-Signature attribute, and 333 are not covered by the message integrity check. As a result, these 334 attributes MAY be added, deleted, or modified by a proxy. 336 The choice of which attributes are protected or unprotected is left up 337 to the sender of the packet. For example, if the home server wishes to 338 guarantee that the client will be tunneled to a given destination, 339 then it will integrity protect tunnel attributes by placing them prior 340 to the End-to-End-Signature attribute. In general, home servers SHOULD 341 protect attributes whose modification would compromise security, 342 including tunnel attributes, and EAP-Message attributes. 344 If a proxy is unable to accept a protected attribute within an Access- 345 Request, then it MUST reply to the NAS with an Access-Reject packet. 346 If a proxy is unable to accept a protected attribute within an Access- 347 Accept or Access-Challenge packet, then it SHOULD send an Access- 348 Reject to the NAS, as well as well as an Accounting-Request with Acct- 349 Status-Type=Proxy-Stop (6) to the home server. 351 9. References 353 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roam- 354 ing Implementations", RFC 2194, September 1997. 356 [2] Aboba, B., and G. Zorn, "Roaming Requirements", Internet draft 357 (work in progress), draft-ietf-roamops-roamreq-10.txt, May 1998. 359 [3] Rigney C., Rubens A., Simpson W., and S. Willens, "Remote Authen- 360 tication Dial In User Service (RADIUS)", RFC 2138, April 1997. 362 [4] Rigney C., "RADIUS Accounting", RFC 2139, April 1997. 364 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 365 Levels", BCP 14, RFC 2119, March 1997. 367 [6] Aboba, B., and M. Beadles, "The Network Access Identifier", 368 Internet draft (work in progress), draft-ietf-roamops-nai-10.txt, May 369 1998. 371 [7] Calhoun, P., and B. Aboba, "End-to-End Security in Roaming", 372 Internet draft (work in progress), draft-ietf-roamops-roamsec-01.txt, 373 July 1998. 375 10. Security Considerations 377 The following security threats have been identified in roaming sys- 378 tems: 380 Rogue proxies 381 Theft of passwords 382 Theft of accounting data 383 Replay attacks 384 Connection hijacking 385 Fraudulent accounting 387 10.1. Rogue proxies 389 In conventional ISP application, the NAS, proxy, and home server exist 390 within a single administrative entity. As a result, the proxy may be 391 considered a trusted component. 393 However, in a roaming system implemented with proxy chaining, the NAS, 394 proxies, and home server may be managed by different administrative 395 entities. Through the use of shared secrets it is possible for proxies 396 operating in different domains to establish a trust relationship. How- 397 ever, if packets are only authenticated on a hop-by-hop basis, then 398 untrusted proxies are capable of perpetrating a number of man-in-the- 399 middle attacks. 401 These attacks typically involve the editing of attributes, or the mod- 402 ification or insertion of messages, such as the substitution of an 403 Access-Accept for an Access-Reject. For example, a proxy may modify 404 an Access-Accept sent by the home server so as to lessen the security 405 obtained by the client. For example, EAP attributes might be removed 406 or modified so as to cause a client to authenticate with EAP MD5 or 407 PAP, instead of a stronger authentication method. Alternatively, tun- 408 nel attributes might be removed or modified so as to remove encryp- 409 tion, redirect the tunnel to a rogue tunnel server, or otherwise 410 lessen the security provided to the client. 412 Through implementation of the End-to-End-Signature attribute, it is 413 possible to detect unauthorized addition, deletion, or modification of 414 protected attributes. Note that it is still possible for a rogue proxy 415 to add, delete or modify unprotected attributes. 417 While a proxy MUST NOT send an Access-Accept to the NAS after receiv- 418 ing an Access-Reject from the home server, a proxy MAY send an Access- 419 Reject to the NAS after receiving an Access-Accept from the home 420 server. Note that in the latter case, a Security-Parameter-Index 421 attribute should be used denoting the security association between the 422 proxy and the NAS, rather than that between the home server and the 423 NAS, since the proxy has originated the packet. This will allow the 424 NAS to verify the End-to-End-Signature attribute within the packet, 425 and decide whether to silently discard the packet. As noted earlier, 426 an Access-Accept originated by a proxy MUST be silently discarded by 427 the NAS, even if the End-to-End-Signature attribute can be verified. 429 The determination of whether end-to-end security is to be used in a 430 conversation is made using out-of-band mechanisms. Typically this is 431 based either on static configuration or on the outcome of a key 432 exchange conversation between the two endpoints. However, once it is 433 determined that the end systems wish to use end-to-end security, all 434 packets sent MUST include an End-to-End-Signature attribute and pack- 435 ets received without an End-to-End-Signature attribute MUST be 436 silently discarded. Note that policy determination using an out-of- 437 band mechanism rather than a proxied conversation limits the ability 438 of a rogue proxy to interfere with the security negotiation between 439 the two end systems. 441 10.2. Theft of passwords or keys 443 Unless the Hidden attribute is used, where clients authenticate using 444 PAP, or where the Tunnel-Password attribute is included with the 445 Access-Accept, each proxy along the path between the local NAS and the 446 home server will have access to the cleartext password or key. In many 447 circumstances, this represents an unacceptable security risk. As a 448 result, the Hidden attribute SHOULD be used to provide end-to-end con- 449 fidentiality for User-Password or Tunnel-Password attributes. 451 10.3. Integrity and confidentiality of accounting data 453 Typically in roaming systems, accounting packets are provided to all 454 the participants along the roaming relationship path, in order to 455 allow them to audit subsequent invoices. In order to prevent modifica- 456 tion of accounting packets by untrusted proxies, the End-to-End-Signa- 457 ture attribute MAY be used. If it is desired that accounting data be 458 kept confidential from a proxy, the Hidden attribute MAY be used. If 459 the objective is to prevent snooping of accounting data on the wire, 460 then IPSEC ESP MAY be used. 462 10.4. Replay attacks 464 In this attack, a man in the middle or rogue proxy collects CHAP-Chal- 465 lenge and CHAP-Response attributes, and later replays them. If this 466 attack is performed in collaboration with an unscrupulous ISP, it can 467 be used to subsequently submit fraudulent accounting records for pay- 468 ment. The system performing the replay need not necessarily be the 469 one that initially captured the CHAP Challenge/Response pair. 471 While RADIUS as described in [3] is vulnerable to replay attacks, 472 without roaming the threat is restricted to proxies operating in the 473 home server's domain. With roaming, such an attack can be mounted by 474 any proxy capable of reaching the home server. 476 In order to protect against replay attacks, CHAP-Challenge and CHAP- 477 Response attributes MAY be protected using the Hidden attribute. CHAP 478 replay attacks can also be defeated by means of an end-to-end chal- 479 lenge-response exchange. For example, if the home server returns an 480 Access-Challenge packet containing a CHAP-Challenge attribute and 481 maintains state with respect to outstanding challenges, replay attacks 482 cannot succeed. 484 However, it should also be noted that end-to-end challenges (as prac- 485 ticed within the EAP MD5 authentication method, or in the CHAP-Chal- 486 lenge method described above) are also subject to attacks by rogue 487 proxies. In such an attack a proxy substitutes a static challenge for 488 the challenge sent by the home server, and on receiving the response, 489 checks it against a databases of hashes applied against a dictionary. 490 This attack may be prevented through use of the End-to-End-Signature 491 attribute. 493 10.5. Connection hijacking 495 In this form of attack, the attacker attempts to inject packets into 496 the conversation between the NAS and the home server. RADIUS as 497 described in [3] is vulnerable to such attacks since only Access-Reply 498 and Access-Challenge packets are authenticated. This attack may be 499 defeated via use of an End-to-End-Signature attribute as described in 500 [7]. 502 10.6. Fraudulent accounting 504 In this form of attack, a local proxy transmits fraudulent accounting 505 packets or session records in an effort to collect fees to which they 506 are not entitled. This includes submission of packets or session 507 records for non-existent sessions.. 509 In order to detect submissions of accounting packets or session 510 records for non-existent sessions, parties receiving accounting pack- 511 ets or session records will typically wish to reconcile them with the 512 authentication logs. Such reconciliation is only typically possible 513 when the party acts as an authentication proxy for all sessions for 514 which an accounting record will subsequently be submitted. 516 In order to make reconciliation easier, home servers involved in roam- 517 ing SHOULD include a Class attribute in the Access-Accept. The Class 518 attribute SHOULD uniquely identify a session, so as to allow an 519 authentication log entry to be matched with a corresponding accounting 520 packet or session record. 522 Note that in order to prevent submission of accounting packets or ses- 523 sion records for non-existent sessions, it is necessary to prevent 524 replay. 526 11. Acknowledgments 528 Thanks to Pat Calhoun of Sun Microsystems, Mark Beadles of CompuServe, 529 Aydin Edguer of Morningstar, Bill Bulley of Merit, and Steven P. Crain 530 of Shore.Net for useful discussions of this problem space. 532 12. Authors' Addresses 534 Bernard Aboba 535 Microsoft Corporation 536 One Microsoft Way 537 Redmond, WA 98052 539 Phone: 425-936-6605 540 EMail: bernarda@microsoft.com 542 John R. Vollbrecht 543 Merit Network, Inc. 544 4251 Plymouth Rd. 545 Ann Arbor, MI 48105-2785 547 Phone: 313-763-1206 548 EMail: jrv@merit.edu 550 13. Full Copyright Statement 552 Copyright (C) The Internet Society (1997). All Rights Reserved. 553 This document and translations of it may be copied and furnished to 554 others, and derivative works that comment on or otherwise explain it 555 or assist in its implmentation may be prepared, copied, published and 556 distributed, in whole or in part, without restriction of any kind, 557 provided that the above copyright notice and this paragraph are 558 included on all such copies and derivative works. However, this docu- 559 ment itself may not be modified in any way, such as by removing the 560 copyright notice or references to the Internet Society or other Inter- 561 net organizations, except as needed for the purpose of developing 562 Internet standards in which case the procedures for copyrights defined 563 in the Internet Standards process must be followed, or as required to 564 translate it into languages other than English. The limited permis- 565 sions granted above are perpetual and will not be revoked by the 566 Internet Society or its successors or assigns. This document and the 567 information contained herein is provided on an "AS IS" basis and THE 568 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 569 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 570 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 571 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 572 PARTICULAR PURPOSE." 574 14. Expiration Date 576 This memo is filed as , and expires May 577 1, 1999.