idnits 2.17.1 draft-hoeper-proxythreat-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 753. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 743. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (November 3, 2008) is 5646 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '3') (Obsoleted by RFC 6733) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force K. Hoeper, Ed. 2 Internet Draft NIST 3 Intended status: Informational S. Winter 4 Expires: May 3, 2009 RESTENA 5 November 3, 2008 7 Threat Model for Networks Employing AAA Proxies 8 draft-hoeper-proxythreat-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute 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 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 3, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This memo defines a threat model for access networks with AAA 41 proxies. Use cases of current and future applications in which AAA 42 proxies are employed are described and it is discussed how proxies 43 could launch attacks in the defined use cases. The risk associated 44 with these attacks in each use case is analyzed. As a result, this 45 draft can serve as a guideline for risk assessments by providers, 46 implementers and protocol designers of systems with proxies. 48 Table of Contents 50 1. Introduction...................................................2 51 1.1. Goals of this Document....................................3 52 1.2. Scope.....................................................4 53 1.3. Terminology...............................................4 54 2. Problem Statement..............................................5 55 3. Related Work...................................................6 56 4. Use Cases......................................................6 57 4.1. Enterprise Network Management.............................6 58 4.2. Free International Roaming................................7 59 4.3. Billable International Roaming............................9 60 5. Threat Model...................................................9 61 5.1. Network Entities and their Trust Relationships............9 62 5.2. Potential Attacks........................................10 63 6. Risk Analysis.................................................12 64 6.1. Feasibility..............................................13 65 6.2. Severity.................................................14 66 7. Security Considerations.......................................14 67 8. IANA Considerations...........................................14 68 9. Conclusions...................................................14 69 10. Acknowledgments..............................................15 70 11. References...................................................15 71 11.1. Normative References....................................15 72 11.2. Informative References..................................15 73 Authors' Addresses...............................................16 74 Intellectual Property Statement..................................16 75 Disclaimer of Validity...........................................17 77 1. Introduction 79 Currently, AAA proxies are implemented in many access networks 80 serving a variety of purposes. For example, proxies provide a 81 scalable solution for access management in large networks. 82 Furthermore, proxies can enable roaming because mobile nodes (MN) can 83 access other networks by authenticating to their home server through 84 local proxies. Some of these tasks require proxies to possess AAA 85 keying material. 87 The introduction of proxies can change the security model of a 88 network as well as of the implemented protocols. As a consequence, 89 AAA proxies may introduce new security vulnerabilities. However, 90 currently the role of AAA proxies in networks and all their security 91 implications are not considered in many existing RFCs and Internet 92 drafts. The relationship with RFC 4962 [1] is the most glaring aspect 93 of the problem, but the progress of numerous drafts in a number of 94 working groups is affected by the so-called "proxy problem". 95 Recently, there have been attempts to reconcile the widespread 96 deployment of AAA proxies with the security requirements of 97 individual Internet protocols or protocol extensions. 99 While the re-occurrence of the proxy problem in several WGs may be 100 bothersome and slow down progress, the problems are more severe for 101 providers and users of already existing implementations with proxies. 102 Doubts exist whether current security claims stated in RFCs and 103 Internet Drafts are still valid for implementations with proxies. 104 Hence, providers of networks with proxies that rely on such security 105 claims may have unknowingly introduced new vulnerabilities to their 106 systems that have not been covered in the respective protocol 107 specifications. For the same reasons, users of such systems may be 108 unknowingly exposed to attacks. 110 Concluding, the proxy problem may affect existing and future 111 implementations of Internet protocols whose specifications neglected 112 proxies in their security considerations. If security issues 113 introduced by proxies are not identified and addressed, future 114 protocol specifications will suffer from the same problems. 116 1.1. Goals of this Document 118 Since the "proxy problem" challenges the credibility of existing RFCs 119 and slows down the progress of many IETF WGs, it seems necessary to 120 evaluate this problem in detail and make the results available to all 121 current and future IETF WGs and other standard bodies. 123 This document shows how AAA proxies may change the security models of 124 networks and their employed protocols in several use cases. Even more 125 importantly, the document analyses the feasibility as well as 126 severity of the identified threats. 128 As a result, this draft can be used as a tool for risk assessment of 129 a network with AAA proxies or protocols implemented in such networks. 130 This draft shows which attacks by proxies are feasible in particular 131 use cases under certain conditions. It is up to the 132 provider/implementer/protocol designer to decide whether the 133 identified threats justify the costs that would be introduced by 134 countermeasures such as infrastructure and/or protocol modifications 136 Current and future drafts that are subject to the "proxy problem" 137 could reference this document to point out possible vulnerabilities 138 and risks. 140 Technical solutions addressing the identified vulnerabilities are not 141 presented in this draft. However, authors of affected protocol 142 specifications are encouraged to use the presented threat model to 143 design a case-based security solution or at least highlight proxy- 144 related security vulnerabilities. The threat model presented in this 145 draft could also serve as basis for designing more general solutions 146 in a separate draft. 148 1.2. Scope 150 This document focuses on security issues related to AAA proxies and 151 the discussions and results in this memo should not be applied to 152 other types of proxies. However, it is encouraged to work on similar 153 documents for other kind of proxies. 155 This document solely identifies security-related issues introduced by 156 AAA proxies and their severity but neither provides solutions to 157 address these problems nor discusses non-security related issues 158 (such as routing, performance, etc.). Furthermore, this document does 159 not consider AAA proxies that are configured to solely serve as a re- 160 direct (as supported by Diameter), because such proxies do not need 161 to gain access to attributes and/or keying material. 163 1.3. Terminology 165 This section defines terms that are frequently used in this document. 167 AAA 168 Authentication, Authorization, and Accounting (AAA). AAA protocols 169 include RADIUS [2] and Diameter [3]. 171 AAA Server 172 A server which provides AAA services via an implemented AAA 173 protocol to mobile nodes. 175 AAA Client 176 A network entity sending AAA requests to the AAA server and 177 receiving AAA replies from the AAA server. NAS and AAA proxy can 178 both act as AAA client. 180 AAA Proxy 181 An AAA proxy provides routing for AAA requests and replies. An 182 AAA proxy appears to act as an AAA client to the AAA server and 183 as AAA server to the AAA client. In this draft, pure re-direct 184 proxies as supported by Diameter are not considered. Only AAA 185 proxies that are capable of modifying attributes and may possess 186 cryptographic keying material are considered. 188 MN 189 A mobile node (MN) that wishes to access the network. 191 NAS 192 The Network Access Server (NAS) is the network entity that mobile 193 nodes contact in order to obtain access to the network. 195 Proxy Chain 196 A routing path through a sequence of AAA proxies. In roaming 197 scenarios, when a proxy chain is across different administrative 198 domains, roaming agreements exist between the first and last proxy 199 of the chain as well as between each neighboring pair of proxies. 201 Roaming agreement 202 Roaming agreements include agreements between companies and 203 Internet Service Providers (ISPs), agreements among peer ISPs 204 within a roaming association, and relationships between an ISP and 205 a roaming consortium. These agreements require a certain level of 206 trust among all parties of a roaming agreement. 207 In the context of this draft, roaming agreements between two 208 administrative domains imply that AAA proxies in these domains may 209 share pairwise AAA keys with each other or may be capable of 210 establishing such pairwise keys. 212 2. Problem Statement 214 Unlike some other network entities that simply forward packets in the 215 network, AAA proxies are designed to have additional capabilities and 216 properties such that the AAA protocols executed through AAA proxies 217 may have the following features: 219 o AAA proxies are able to modify and/or delete AAA attributes 221 o AAA proxies share pairwise AAA keys with the AAA server and/or 222 other AAA proxies; 224 o AAA proxies and NAS cannot be distinguished by AAA server; 226 o AAA proxies and AAA server cannot be distinguished by NAS; 228 o AAA proxy chains cannot be distinguished from single proxies by 229 neither NAS nor AAA server. 231 The above special features may lead to new security vulnerabilities. 232 For example, a proxy could modify or delete some attributes of an AAA 233 request/reply. Or a proxy in possession of AAA keying material can 234 break the end-to-end integrity and/or confidentiality between NAS and 235 AAA server that is assumed in some protocols. The last three bullets 236 show that the other communicating entities might not even be aware of 237 the proxies on the communication path. In the case of a single proxy 238 or a chain of proxies [4] between NAS and AAA server, not every party 239 authenticates to all parties it communicates with as required in RFC 240 4962[1]. The sum of these and other security issues imposed by AAA 241 proxies is referred to as "proxy problem" in this document. 243 3. Related Work 245 [Editor's note: what other references should be mentioned here?] 247 The "Security Consideration" Section of RFC 2607 [4] outlines 248 security threats introduced by proxies in roaming scenarios using 249 RADIUS. These observations and other threats will be further analyzed 250 in this draft in a more general context. For instance, threats 251 introduced by AAA proxies are analyzed in several use cases. In 252 addition, this draft allows an application-based risk analysis. 254 4. Use Cases 256 [Editor's note: Any more use cases?] 258 For easier identification of vulnerabilities as well as analysis of 259 feasibility and severity of attacks, a representative set of use 260 cases for AAA proxies in networks are supplied here. 262 4.1. Enterprise Network Management 264 In enterprise networks or other local networks with a single 265 administrative domain, AAA proxies are used to enable easy and 266 scalable network access in large networks. Here-instead of having a 267 direct connection between each NAS and the authentication server- 268 groups of NAS' can be connected to proxies in proximity. The proxies 269 are then attached to the authentication server, resulting in a 270 scalable network infrastructure. This is illustrated in Figure 1 for 271 a network with two AAA proxies, where proxy 1 serves NAS 1 to NAS i 272 and proxy 2 serves NAS j to NAS n. Hierarchical proxy routing can 273 further simplify key management, as has been pointed out in RFC 2607. 274 Note that this would lead to proxy chaining. 276 Other reasons why proxies may be used in enterprise networks are that 277 the administrator wants to assign different sets of offered services 278 and policies for different groups of NAS'. In that case a proxy 279 adjusts the AAA request from a certain NAS to the specified policy 280 for this NAS, and/or adjusts the AAA reply to the capabilities of the 281 NAS. This requires the proxy to modify or delete AAA attributes. For 282 example, a NAS talking to proxy 1 only supports weak authentications 283 (e.g. to constrained devices) but in return only limited services are 284 made available to MNs connecting through this NAS. On the other hand, 285 requests routed through proxy 2 may demand stronger authentication 286 but provide a larger variety of services and information. 288 +------+ 289 | AAA | 290 +------+ 291 / \ 292 / \ 293 / \ 294 / \ 295 +------+ +------+ 296 |proxy1| |proxy2| 297 +------+ +------+ 298 / \ / \ 299 / \ / \ 300 / \ / \ 301 +----+ +----+ +----+ +----+ 302 |NAS1|..|NASi| |NASj|..|NASn| 303 +----+ +----+ +----+ +----+ 305 Figure 1 Enterprise network with two proxies. 307 4.2. Free International Roaming 309 AAA proxies are also used to enable roaming across administrative 310 domains with roaming agreements. Note that roaming agreements may 311 imply that proxies from one domain share AAA keys with proxies from 312 the other domain or may be capable of establishing such shared keys. 313 A proxy in domain 1 (lets say the home domain of a MN) can serve as 314 entry point for roaming requests from a domain 2 (lets say a visited 315 domain). Even though the roaming is free in this use case (and thus 316 billing unnecessary), it can be very important in such applications 317 that policies of both domains are observed (e.g. the minimum age of 318 users or minimum security level of provided services). To ensure 319 this, the home proxy may need to adjust incoming AAA requests and 320 outgoing AAA replies according to the capabilities and policies of 321 visited and home networks, respectively, as well as the roaming 322 agreements between them. 324 Note that the path for AAA communications between the visited domain 325 and the home domain may consist of several proxies, i.e. a proxy 326 chain. Here, the roaming agreements between domain 1 and domain 2 327 specify the relationship between proxies in domain 1 (say the first 328 proxy in the chain) and proxies in domain 2(say the last proxy in the 329 chain). However, successful AAA functionality may require roaming 330 agreements between each neighboring pair of proxies in the proxy 331 chain (e.g. to share pairwise keys). For this reason, either the 332 existing roaming agreement between domain 1 and domain 2 needs to 333 extend to the intermediated proxies or additional agreements are 334 needed. The described roaming scenario is illustrated in Figure 2. 336 - - - - - - - - - - - - - - - 337 +-------+ Roaming agreements +-------+ 338 | | Local | <==================> | Home | | 339 | AAA | | | | AAA | 340 | +-------+ +-------+ | 341 | | | ^ 342 | | | | 343 | | | | 344 | +-------+ [*proxy chain] +-------+ | 345 | Local | -------- ... ----->| Home | 346 | | Proxy | | | | Proxy | | 347 +-------+ +-------+ 348 | ^ | | | 349 | 350 | | | | | 351 +-------+ 352 | | Local | | | | 353 | NAS | 354 | +-------+ | | | 355 ^ 356 | | | | | 357 | 358 | +------+ | | | 359 | MN | 360 | +------+ | | | 362 | Visited Domain | _|Home Domain | 363 - - - - - - - - - - - - - - - 365 *optional 366 Figure 2 International Roaming Utilizing Proxies 368 An example of an existing network enabling international roaming free 369 of charge is eduroam [5]. Eduroam is a world-wide WLAN roaming 370 network for users in education and research. The network consists of 371 a hierarchy of RADIUS servers interconnecting participating sites. 372 The hierarchy consists of a root level proxy, used for international 373 roaming between different top-level domains, country-level proxy 374 servers for roaming between institutions in the same top level 375 domain, and institutional servers to perform the actual 376 authentication (these servers may optionally further proxy requests 377 to departments within their own institution at their discretion). 378 Most RADIUS servers are duplicated for resiliency purposes. This 379 architecture leads to a proxy path with at least five RADIUS servers 380 in a chain when roaming internationally. 382 4.3. Billable International Roaming 384 In many roaming scenarios, the MN will be billed for the used roaming 385 services according to the roaming agreements between the MN's home 386 network and the visited network. The network architecture with 387 proxies is the same as in the previous use case (see Figure 2), 388 however additional billing information needs to be exchanged. Please 389 note that authentication and accounting data may not take the same 390 routing path [4]. As a consequence this document distinguishes 391 between authentication proxy and accounting proxy for this use case. 393 5. Threat Model 395 To be able to analyze security vulnerabilities introduced by AAA 396 proxies and their risks, a threat model needs to be established 397 first. Section 5.1. describes the different players in the threat 398 model. Section 5.2. defines the attacks an AAA proxy may launch in 399 any of the use cases that have been described in Section 4. 401 5.1. Network Entities and their Trust Relationships 403 Since this document focuses on potential security risks introduced by 404 AAA proxies, all other network entities (such as AAA servers and NAS) 405 and MNs are assumed to execute all protocol steps faithfully and do 406 not behave maliciously in any way. The practicability of these 407 assumptions is out of scope of this document. 409 The above assumptions are generally based on the following trust 410 relationships: 412 o Within a home domain (can be also considered as an intra-domain) 413 it is assumed that all entities are correctly configured and not 414 controlled by a malicious party. This can be achieved by intrusion 415 detection systems or other means to detect so-called malicious 416 insiders. 418 o The trust relationships between a home network and other local 419 networks are specified in roaming agreements. These roaming 420 agreements imply that the home network trusts the local network to 421 faithfully carry out the roaming services that have been agreed on 422 under specified conditions (e.g. roaming fees). 424 This document deals with potential security threats introduced by AAA 425 proxies. The attacks (as specified in the next Section) are executed 426 by an AAA proxy that is either controlled by an adversary or mis- 427 configured. In this threat model the following types of malicious 428 proxies are distinguished: 430 1. Proxies in the home network 432 2. Proxies in the visited network 434 3. Proxies in a proxy chain between the home and the visited 435 networks 437 Furthermore, these three proxy types are split into authentication 438 and accounting proxies. 440 5.2. Potential Attacks 442 A malicious or misconfigured AAA proxy may launch the following 443 attacks: 445 1. Passively eavesdrop on network traffic 447 Monitoring network traffic is feasible for any entity with access 448 to the network. It does not require any special capabilities or 449 privileges, such as the knowledge of cryptographic keying material. 450 Consequently, this attack is not limited to AAA proxies. 452 Traffic analysis can be used to track the activity and/or mobility 453 of particular users. 455 2. Replay data packets 457 This attack consists of two phases: (i) the recording of data 458 packets of previous network authentications and (ii) the replaying 459 of this data at a later time. This requires access to the network 460 but no knowledge of keying material. Hence, the attack is not 461 limited to proxies. 463 Replay attacks are typically prevented by the AAA protocol itself 464 with the aid of time variant information. There are legacy 465 operation modes in RADIUS that can be replayed easily (Access- 466 Request packets without the Message-Authenticator attribute, which 467 is against the Recommendation of RFC 5080[6]). 469 3. Re-direct data packets 471 Any proxy could maliciously re-direct AAA data packets. This 472 requires access to the routing path but no knowledge of keying 473 material. Hence, the attack can also be carried out by routers and 474 is not specific to proxies. 476 It appears that this attack can only be exploited for Denial of 477 Service (DoS) attacks [Editor's note: Is this true?] which are 478 typically not preventable by cryptographic means. 480 4. Drop data packets 482 As for re-direction attacks, any proxy can drop packets causing re- 483 transmissions that can lead to a denial of service. [Editor's note: 484 Is there any other attack?]. This attack can be executed by all 485 entities on the routing paths, i.e. it is not limited to proxies 486 and, e.g., can also be executed by routers. 488 Note that this attack cannot easily be distinguished from "natural" 489 packet losses. 491 5. Actively extract confidential information from network traffic 493 Where AAA protocols do not encrypt their payload or parts of it on 494 the wire, an attacker may extract confidential information from the 495 packet without knowledge of encryption keys. In this case, any 496 intermediate hop (like routers) can eavesdrop on the non-encrypted 497 parts of the protocol payload. 499 If the protocol payload is encrypted as a whole, this attack 500 requires the knowledge of the encryption key(s). If shared AAA keys 501 are used for encrypting data, then a proxy in possession of these 502 keys can decrypt the data. 504 For example, this attack can be used to gather personal user 505 information or accounting information (such as roaming fees and 506 offered services) of competitive networks. 508 6. Fabricate fake data packets 509 This attack requires the knowledge of the keying material used to 510 protect data packets. If shared AAA keys are used for protecting 511 data, then a proxy in possession of these keys can generate fake 512 data packets. 514 For instance, a malicious proxy could fabricate valid 515 authentication packets for an unauthorized mobile node or fabricate 516 fake accounting data to charge for unused services. 518 7. Modify messages 520 If shared AAA keys are used for protecting AAA messages, then a 521 proxy in possession of these keys can modify the data. 523 If an AAA message is not protected, any proxy or any other network 524 entity can modify it. 526 If an AAA message (protected or unprotected) is not bound to any 527 other protected message it can be dropped by any proxy or other 528 network entity on the routing path. 530 8. Modify AAA attributes 532 If shared AAA keys are used for protecting AAA attributes, then a 533 proxy in possession of these keys can modify the attributes. 535 If an AAA attribute is not protected, any proxy or any other 536 network entity can modify it. 538 If an AAA attribute (protected or unprotected) is not bound to any 539 other protected AAA message or attribute it can be dropped by any 540 proxy or other network entity on the routing path. 542 Current AAA protocols provide shared keying material for payload 543 protection and thus expose packet contents to proxies. There are 544 key wrapping schemes to protect individual attributes though, which 545 can encrypt AAA attributes between any two AAA servers while not 546 exposing them to intermediate AAA proxies. These key wrapping 547 schemes require out of band negotiation of wrapping keys, which is 548 hardly scalable. 550 6. Risk Analysis 552 This section uses the threat model in Section 5. to analyze the 553 feasibility and severity of the identified attacks 5. in each of the 554 uses cases discussed in Section 4. An attack is only considered a 555 risk, if the attack is feasible and the impact is sufficiently severe 556 to justify the attack's costs from an attacker's perspective. 558 6.1. Feasibility 560 It can be observed that the feasibility of attacks by proxies depend 561 on the use case, the type of employed proxies, and whether the proxy 562 possesses keying material required for an attack. 564 In general, the existence of malicious home proxies in an enterprise 565 network (and thus the feasibility of attacks in such networks) is 566 fairly unlikely because enterprise networks can be efficiently 567 protected. For such an attack, the trust assumption in the home 568 network must be violated (see Section5.1. ). 570 On the other hand, in roaming scenarios, the attacks by proxies (as 571 listed in Section 5.2. ) can be classified as more feasible because 572 they can be carried out by local proxies and/or proxies in a proxy 573 chain between home and visited network. The trustworthiness of 574 visited proxies is specified in the respective roaming agreements, 575 while the trustworthiness of proxies in proxy chains may depend on a 576 chain of roaming agreements. In a proxy chain, both ends of the chain 577 (i.e. home and visited network) have roaming agreements with each 578 other as well as neighboring pairs of proxies in the chain. Only if 579 the chain consists of three or less proxies, the home network 580 directly trusts all proxies (up to two) in the chain. For chains 581 longer than three (including the end points) trust is transitive, 582 i.e. the home proxy does not directly trust all proxies on the chain 583 but rather trusts its direct neighbor to only have agreements with 584 other trusted proxies and so forth. This results into a chain of 585 trust. It can be observed, that a violation of this chain of trust is 586 more likely than a direct trust violation in the home or visited 587 network. Furthermore, the longer the proxy chain, the more diluted 588 may the trust relations become and the more likely is a compromised 589 or mis-configured proxy as part of the proxy chain. 591 In any case, attacks in roaming use cases require that a trust 592 relation as part of the roaming agreements is violated (see Section 593 5.1. . 595 In addition, the feasibility of attacks depend whether they require 596 knowledge of keying material. For instance, attacks 1-4 in Section 597 5.2. do not require the knowledge of keying material and thus can be 598 executed by any proxy. On the other hand, attacks 5-8 require the 599 knowledge of the AAA keying material that has been used to protect 600 the data under attack. However, the possession of keying material is 601 likely because AAA protocols are often based on hop-by-hop security 602 using shared keys. In addition, proxies often need to be able to 603 adjust (protected) AAA attributes to meet local requirements. 605 6.2. Severity 607 In enterprise networks, the severity of attacks are rather limited, 608 because the exchanged data would not be of great value for an 609 attacker and the exploitation of fabricated of modified packets is 610 limited (e.g. because of the lack of accounting data and mobility 611 pattern of users). 613 The severity of all attacks in roaming scenarios is higher due to 614 the higher value of the exchanged information and offered services. 615 For instance, traffic analysis attacks (attack 1) could be of 616 interest to track the movements of particular mobile users. DoS 617 attacks (attacks 3 and 4) could bring down the entire services, so 618 the risk can be considered moderate to severe depending on the 619 offered services. 621 Especially accounting information is an attractive target for an 622 adversary. However, the information of free roaming services (use 623 case 2) can be of value as well. For example, in [5] data can 624 contain the age, nationality, and other personal information of the 625 mobile user wishing to access the network. Modification attacks can 626 also be a severe risk, e.g. under aged users can control proxies to 627 modify the age in order to pass the age limit for a requested 628 service or local proxies may modify the roaming information to make 629 their network services more attractive but later charge more. In 630 addition modification attacks can be used for the downgrading of 631 negotiated security credentials. Fabrication attacks can be 632 classified as extremely severe in use case 3, because a malicious 633 accounting proxy could fabricate false accounting information, such 634 that the home network is charged for roaming fees even though no 635 mobile node actually roamed. 637 7. Security Considerations 639 TBD 641 8. IANA Considerations 643 This document has no IANA considerations. 645 9. Conclusions 647 This draft facilitates implementers and providers of networks with 648 AAA proxies as well as protocols designers to carry out a risk 649 analysis of threats introduced by AAA proxies. The result of such 650 analysis enables to decide whether the potential security 651 vulnerabilities introduced by AAA proxies in the network justify the 652 costs of necessary system or protocol modifications to thwart the 653 identified attacks. 655 Furthermore, as another result of this draft, it can be observed that 656 security solutions thwarting proxy attacks can be expected not to be 657 of pure technical nature. The feasibility of attacks highly depends 658 on the reliability of trust assumptions in enterprise networks and 659 roaming agreements in roaming applications. 661 Technical solutions such as providing end-to-end protection of AAA 662 attributes and messages can prevent modifications and fabrication 663 attacks and should be carefully studied in future works. 665 10. Acknowledgments 667 Thanks to everybody contributing to the proxy list and/or the meeting 668 in Philadelphia, especially Bernard Aboba, Alan DeKok, Pasi Eronen, 669 Dan Harkins, Sam Hartman, Russ Housley, Tim Polk, Klaas Wierenga, and 670 Glen Zorn. Special thanks to Stefan Winter for providing the eduroam 671 application as one of the use cases. 673 11. References 675 11.1. Normative References 677 (None). 679 11.2. Informative References 681 [1] Housley, R. and Aboba, B., "Guidance for Authentication, 682 Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 683 4962, July 2007. 685 [2] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 686 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, 687 June 2000. 689 [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J., 690 "Diameter Base Protocol", RFC 3588, September 2003. 692 [4] Aboba, B., "Proxy Chaining and Policy Implementation in 693 Roaming", RFC 2607, June 1999. 695 [5] Wierenga, K. and S. Winter, "Deliverable DJ5.1.4: Inter-NREN 696 Roaming Architecture: Description and Development Items", 2006, 697 . 699 [6] Nelson, D. and DeKok, A., "Common Remote Authentication Dial 700 In User Service (RADIUS) Implementation Issues and Suggested 701 Fixes", RFC 5080, December 2007. 703 Authors' Addresses 705 Katrin Hoeper (editor) 706 National Institute of Standards and Technology 707 100 Bureau Drive, MS: 8930 708 Gaithersburg, MD 20899 709 USA 711 Email: khoeper@nist.gov 713 Stefan Winter 714 RESTENA Foundation 715 6, rue Richard Coudenhove-Kalergi 716 1359 Luxembourg 717 LUXEMBOURG 719 Email: stefan.winter@restena.lu 721 Intellectual Property Statement 723 The IETF takes no position regarding the validity or scope of any 724 Intellectual Property Rights or other rights that might be claimed to 725 pertain to the implementation or use of the technology described in 726 this document or the extent to which any license under such rights 727 might or might not be available; nor does it represent that it has 728 made any independent effort to identify any such rights. Information 729 on the procedures with respect to rights in RFC documents can be 730 found in BCP 78 and BCP 79. 732 Copies of IPR disclosures made to the IETF Secretariat and any 733 assurances of licenses to be made available, or the result of an 734 attempt made to obtain a general license or permission for the use of 735 such proprietary rights by implementers or users of this 736 specification can be obtained from the IETF on-line IPR repository at 737 http://www.ietf.org/ipr. 739 The IETF invites any interested party to bring to its attention any 740 copyrights, patents or patent applications, or other proprietary 741 rights that may cover technology that may be required to implement 742 this standard. Please address the information to the IETF at 743 ietf-ipr@ietf.org. 745 Disclaimer of Validity 747 This document and the information contained herein are provided on an 748 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 749 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 750 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 751 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 752 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 753 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 755 Copyright Statement 757 Copyright (C) The IETF Trust (2008). 759 This document is subject to the rights, licenses and restrictions 760 contained in BCP 78, and except as set forth therein, the authors 761 retain all their rights. 763 Acknowledgment 765 Funding for the RFC Editor function is currently provided by the 766 Internet Society.