idnits 2.17.1 draft-ietf-pana-threats-eval-07.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 826), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: PANA MUST not assume that the discovery process is protected. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 1. PANA MUST not assume that the discovery process is protected. -- 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 (August 2004) is 7192 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) == Unused Reference: 'RADIUS' is defined on line 683, but no explicit reference was found in the text == Unused Reference: 'ADDRCONF' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'IPSEC' is defined on line 700, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.11i' is defined on line 706, but no explicit reference was found in the text == Unused Reference: 'IEEE-802.11' is defined on line 713, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-08 == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-00 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'IPSEC') (Obsoleted by RFC 4301) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group 3 Internet Draft M. Parthasarathy 4 Document: draft-ietf-pana-threats-eval-07.txt Nokia 5 Expires: January 2005 August 2004 7 Protocol for Carrying Authentication and Network Access Threat 8 Analysis and Security Requirements 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at 24 anytime. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document discusses the threats to protocols that are used to 42 carry authentication for network access. The security requirements 43 arising out of these threats will be used as additional input to the 44 PANA WG for designing the IP based network access authentication 45 protocol. 47 PANA threat analysis August 2004 49 Table of Contents 51 1.0 Introduction..................................................2 52 2.0 Keywords......................................................2 53 3.0 Terminology and Definitions...................................3 54 4.0 Usage Scenarios...............................................4 55 5.0 Trust Relationships...........................................4 56 6.0 Threat Scenarios..............................................6 57 6.1 PAA Discovery..............................................6 58 6.2 Authentication.............................................7 59 6.3 PaC leaving the network...................................10 60 6.4 Service theft.............................................11 61 6.5 PAA-EP communication......................................12 62 6.6 Miscellaneous attacks.....................................12 63 7.0 Summary of Requirements......................................13 64 8.0 Security Considerations......................................14 65 9.0 IANA Considerations..........................................14 66 10.0 Normative References........................................14 67 11.0 Informative References......................................14 68 12.0 Acknowledgments.............................................15 69 13.0 Revision Log................................................15 70 14.0 Author's Address............................................16 71 Intellectual Property Statement..................................16 72 Disclaimer of Validity...........................................17 73 Copyright Statement..............................................17 74 Acknowledgment...................................................17 76 1.0 Introduction 78 The PANA (Protocol for Carrying Authentication for Network Access) 79 Working Group is developing methods for authenticating clients to the 80 access network using IP based protocols. This document discusses the 81 threats to such IP based protocols. 83 A client wishing to get access to the network must carry on multiple 84 steps. First, it needs to discover the IP address of the PANA 85 authentication agent (PAA) and then execute an authentication 86 protocol to authenticate itself to the network. Once the client is 87 authenticated, there might be other messages exchanged during the 88 lifetime of the network access. This document discusses the threats 89 in these steps without discussing any solutions. The requirements 90 arising out of these threats will be used as input to the PANA 91 Working Group. The use of word co-located in this document means that 92 the referred entities are present on the same node. 94 2.0 Keywords 95 PANA threat analysis August 2004 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [KEYWORDS]. 101 3.0 Terminology and Definitions 103 Client Access Device 105 A network element (e.g., notebook computer, PDA, etc.) that 106 requires access to a provider's network. 108 Network Access Server (NAS) 110 Network device that provides access to the network. 112 PANA Client (PaC) 114 An entity in the edge subnet, who is wishing to obtain network 115 access from a PANA authentication agent within a network. A PANA 116 client is associated with a device and a set of credentials to 117 prove its identity within the scope of PANA. 119 PANA Authentication Agent (PAA) 121 An entity whose responsibility is to authenticate the PANA client 122 and grant network access service to the client's device. 124 Authentication Server (AS) 126 An entity that authenticates the PANA client. It may be co-located 127 with PANA authentication agent or part of the back-end 128 infrastructure. 130 Device Identifier (DI) 132 The identifier used by the network as a handle to control and 133 police the network access of a client. Depending on the access 134 technology, identifier might contain any of IP address, link-layer 135 address, switch port number, etc. of a device. PANA authentication 136 agent keeps a table for binding device identifiers to the PANA 137 clients. At most one PANA client should be associated with a DI on 138 a PANA authentication agent. 140 Enforcement Point (EP) 141 PANA threat analysis August 2004 143 A node that is capable of filtering packets sent by the PANA 144 client using the DI information authorized by PANA authentication 145 agent. 147 Compound methods 149 Authentication protocol where, sequence of methods are used one 150 after an other or where methods are tunneled inside an another 151 independently established tunnel between the client and server 152 [TUN-EAP]. 154 4.0 Usage Scenarios 156 PANA is intended to be used in an environment where there is no a 157 priori trust relationship or security association between the PaC and 158 other nodes like PAA and EP. In these environments, one may observe 159 the following. 161 o The link between PaC and PAA may be a shared medium 162 (e.g., Ethernet) or may not be a shared medium (e.g., DSL 163 network). 165 o All the PaCs may be authenticated to the access network at 166 layer 2 (e.g., 3GPP2 CDMA network) and share a security 167 association with layer 2 authentication agent (e.g., BTS). The 168 PaCs still don't trust each other i.e., any PaC can pretend to 169 be a PAA, spoof IP addresses and launch various other attacks. 171 The scenarios mentioned above affect the threat model of PANA. This 172 document discusses the various threats in the context of the above 173 network access scenarios for a better understanding of the threats. 174 In the following discussion, any reference to a link that is not 175 shared (or non-shared) is assumed to be physically secure. If such an 176 assumption cannot be made about the link, then it becomes the same as 177 the link that is being shared by more than one node. 179 5.0 Trust Relationships 181 PANA authentication involves a client (PaC), PANA agent (PAA), 182 Authentication server (AS) and an Enforcement point (EP). The AS here 183 refers to the AAA server that resides in the home realm of the PaC. 185 The entities that have a priori trust relationships before PANA 186 begins are as follows. 188 1) PAA and AS: The PaC belonging to the same administrative domain 189 as the AS, often needs to use resources provided by PAA that 190 belongs to another administrative domain. PAA authenticates the 191 PaC before providing local network access. The credentials 192 PANA threat analysis August 2004 194 provided by PaC for authentication may or may not be understood 195 by PAA. If PAA does not understand the credentials, it needs to 196 communicate with the AS in a different domain to verify the 197 credentials. The threats in the communication path between PAA 198 and AS are already covered in [RAD-EAP]. To counter these 199 threats, the communication between PAA and AS are secured using 200 a static or dynamic security association. 202 2) PAA and EP: The PAA and EP belong to the same administrative 203 domain. Hence, the network operator can setup a security 204 association to protect the traffic exchanged between them. This 205 document discusses the threats in this path. 207 3) PaC and AS: The PaC and AS belong to the same administrative 208 domain and share a trust relationship. When PaC uses a different 209 domain than its home for network access, it provides its 210 credentials to the PAA in the visited network for 211 authentication. The information provided by PaC traverses the 212 PaC-PAA path and PAA-AS path. The threats in PAA-AS path are 213 already discussed in [RAD-EAP]. This document discusses the 214 threats in PaC-PAA path. 216 It is possible that some of the entities like PAA, AS and EP are 217 co-located. In those cases, it can be safely assumed that there are 218 no significant external threats in their communication. 220 The entities that do not have any trust relationship before PANA 221 begins are as follows. 223 1) PaC and PAA: The PaC and PAA normally belong to two different 224 administrative domains. They do not necessarily share a trust 225 relationship initially. They establish a security association in 226 the process of authentication. All messages exchanged between 227 PaC and PAA are subject to various threats, which are discussed 228 in this document. 230 2) PaC and EP: The EP belongs to the same administrative domain as 231 PAA and hence PaC and EP do not necessarily share a trust 232 relationship initially. When PaC is successfully authenticated, 233 it may result in key establishment between PaC and PAA, which 234 can be further used to secure the link between PaC and EP. For 235 example, EAP keying framework [EAP-KEY], defines a three party 236 EAP exchange where the clients derive the transient sessions 237 keys to secure the link between the peer and NAS in their final 238 step. Similarly, PANA will provide the ability to establish keys 239 between PaC and EP that can be used to secure the link further. 240 This is further discussed in section 6.4 below. 242 PANA threat analysis August 2004 244 6.0 Threat Scenarios 246 The PANA authentication client (PaC) needs to discover the PAA first. 247 This involves either sending solicitations or waiting for 248 advertisements. Once it has discovered the PAA, it will lead to 249 authentication exchange with PAA. Once the access is granted, PaC 250 will most likely exchange data with other nodes in the Internet. 251 These steps are vulnerable to man-in-the-middle (MITM), denial of 252 service (DoS), and service theft attacks, which are discussed below. 254 The threats are grouped by the various stages the client goes through 255 to gain access to the network. Section 6.1 discusses the threats 256 related to PAA discovery. Section 6.2 discusses the threats related 257 to authentication itself. Section 6.3 discusses the threats involved 258 while leaving the network. Section 6.4 discusses service theft. 259 Section 6.5 discusses the threats in PAA-EP path. Section 6.6 260 discusses the miscellaneous threats. 262 Some of the threats discussed in the following sections may be 263 specific to shared links. The threat may be absent on non-shared 264 links. Hence, it is only required to prevent the threat on shared 265 links. Instead of specifying a separate set of requirements for 266 shared links and non-shared links, this document just specifies one 267 set of requirements with the following wording: "PANA MUST be able to 268 prevent threat X". This means that the PANA protocol should be 269 capable of preventing threat X. The feature that prevents threat X 270 may or may not be used depending on the deployment. 272 6.1 PAA Discovery 274 The PAA is discovered by sending solicitations or receiving 275 advertisements. Following are the possible threats. 277 T6.1.1: A malicious node can pretend to be a PAA by sending a 278 spoofed advertisement. 280 In existing dial-up networks, the clients authenticate to the network 281 but generally do not verify the authenticity of the messages coming 282 from Network Access Server (NAS). This mostly works because the link 283 between the device and the NAS is not shared with other nodes 284 (assuming that nobody tampers with the physical link), and clients 285 trust the NAS and the phone network to provide the service. Spoofing 286 attacks are not present in this environment because the PaC may 287 assume that the other end of the link is the PAA. 289 In environments where the link is shared, this threat is present as 290 any node can pretend to be a PAA. Even if the nodes are authenticated 291 at layer 2, this threat is present. It is difficult to protect the 292 PANA threat analysis August 2004 294 discovery process, as there is no a priori trust relationship between 295 PAA and PaC. In deployments where EP can police the packets that are 296 sent among the PaCs, it is possible to filter out the unauthorized 297 PANA packets (e.g., PAA advertisements sent by PaC) and prevent this 298 threat. 300 The advertisement may be used to include other information like 301 supported authentication methods etc., besides the discovery of the 302 PAA itself. This can lead to a bidding down attack, as a malicious 303 node can send a spoofed advertisement with capabilities that indicate 304 less secure authentication methods than what the real PAA supports, 305 thereby fooling the PaC into negotiating a less secure authentication 306 method than what would otherwise be available. 308 Requirement 1 310 PANA MUST not assume that the discovery process is protected. 312 6.2 Authentication 314 This section discusses the threats specific to the authentication 315 protocol. Section 6.2.1 discusses the possible threat associated with 316 success/failure indications that are transmitted to PaC at the end of 317 the authentication. Section 6.2.2 discusses the man-in-the-middle 318 attack when compound methods are used. Section 6.2.3 discusses the 319 replay attack and section 6.2.4 discusses about the device identifier 320 attack. 322 6.2.1 Success or Failure Indications 324 Some authentication protocols e.g., EAP, have a special message to 325 indicate success or failure. An attacker can send false 326 authentication success or failure message to the PaC. By sending 327 false failure message, the attacker can prevent the client from 328 accessing the network. By sending false success message, the attacker 329 can prematurely end the authentication exchange effectively denying 330 service for the PaC. 332 If the link is not shared, then this threat is absent as ingress 333 filtering can prevent the attacker from impersonating as the PAA. 335 If the link is shared, it is easy to spoof these packets. If layer 2 336 provides per-packet encryption with pair-wise keys, it might make it 337 hard for the attacker to guess the success or failure packet that the 338 client would accept. Even if the node is already authenticated at 339 layer 2, it can still pretend to be a PAA and spoof the success or 340 failure. 342 PANA threat analysis August 2004 344 This attack is possible if the success or failure indication is not 345 protected using a security association between the PaC and the PAA. 346 In order to avoid this attack, the PaC and PAA should mutually 347 authenticate each other. In the process of mutually authenticating 348 each other, they should be able to establish keys to protect the 349 success or failure indications. It may not be possible to protect the 350 success or failure indication always as the keys may not be 351 established prior to transmitting the success or failure packet. If 352 the client is re-authenticating to the network, it can use the 353 previously established security association to protect the success or 354 failure indications. Similarly, all PANA messages that are exchanged 355 during the authentication prior to key establishment may not be 356 protected. 358 Requirement 2 360 PANA MUST be able to mutually authenticate the PaC and PAA. PANA MUST 361 be able to establish keys between the PaC and PAA to protect the PANA 362 messages. 364 6.2.2 MITM attack 366 A malicious node can claim to be PAA to the real PaC and claim to be 367 PaC to the real PAA. This is a man in the middle (MITM) attack where 368 the PaC is fooled to think that it is communicating with real PAA and 369 the real PAA is fooled to think that it is communicating with real 370 PaC. 372 If the link is not shared, this threat is absent as ingress filtering 373 can prevent the attacker from acting as man in the middle. 375 If the link is shared, this threat is present. Even if the layer 2 376 provides per-packet protection, the attacker can act as man in the 377 middle and launch this attack. An instance of MITM attack, when 378 compound authentication methods are used is described in [TUN-EAP]. 379 In these attacks, the server first authenticates to the client. As 380 the client has not proven its identity yet, the server acts as the 381 man-in-the-middle, tunneling the identity of the legitimate client to 382 gain access to the network. The attack is possible because there is 383 no verification that the same entities participated among the 384 compound methods. It is not possible to do such verification if 385 compound methods are used without being able to create cryptographic 386 binding among them. This implies that PANA will be vulnerable to such 387 attacks if compound methods are used without being able to 388 cryptographically bind them. Note that the attack does not exist if 389 the keys derived during the tunnel establishment are not used for 390 authenticating the client e.g., tunnel keys are used for just 391 protecting the identity of the client. 393 PANA threat analysis August 2004 395 Requirement 3 397 When compound authentication methods are used in PANA, the methods 398 MUST be cryptographically bound. 400 6.2.3 Replay Attack 402 A malicious node can replay the messages that caused authentication 403 failure or success at a later time to create false failures or 404 success. The attacker can also potentially replay other messages of 405 the PANA protocol to deny service to the PaC. 407 If the link is not shared, this threat is absent as ingress filtering 408 can prevent the attacker from impersonating as PAA and replay the 409 packets. 411 If the link is shared, this threat is present. If the packets are 412 encrypted at layer 2 using pair-wise keys, it will make it hard for 413 the attacker to learn the unencrypted (i.e., original) packet that 414 needs to be replayed. Even if layer 2 provides replay protection, the 415 attacker can still replay the PANA messages (layer 3) for denying 416 service to the client. 418 Requirement 4 420 PANA MUST be able to protect itself against replay attacks. 422 6.2.4 Device Identifier Attack 424 When the client is successfully authenticated, the PAA sends access 425 control information to the EP for granting access to the network. The 426 access control information typically contains the device identifier 427 of the PaC, which is obtained from the IP headers and MAC headers of 428 the packets exchanged during the authentication process or carried 429 explicitly in the PANA protocol field. The attacker can gain 430 unauthorized access into the network using the following steps. 432 . An attacker pretends to be a PAA and sends advertisements. PaC 433 gets fooled and starts exchanging packets with the attacker. 434 . The attacker modifies the IP source address on the packet, 435 adjusts the UDP/TCP checksum and forwards the packet to the real 436 PAA. It does the same on return packets also. 437 . When the real PaC is successfully authenticated, the attacker 438 gains access to the network as the packets contained the IP 439 address (and potentially the MAC address also) of the attacker. 441 If the link is not shared, this threat is absent, as the attacker 442 cannot impersonate as PAA and intercept the packets from PaC. 444 PANA threat analysis August 2004 446 If the link is shared, this threat is present. If the layer 2 447 provides per-packet protection, it is not possible to change the MAC 448 address and hence this threat may be absent in such cases if EP 449 filters both on IP and MAC address. 451 Requirement 5 453 PANA MUST be able to protect the device identifier against spoofing 454 when it is exchanged between the PaC and PAA. 456 6.3 PaC leaving the network 458 When the PaC leaves the network, it can inform the PAA before 459 disconnecting from the network so that the resources used by PaC can 460 be accounted properly. The PAA may also choose to revoke the access 461 any time if it deems necessary. Following are the possible threats. 463 T6.3.1: A malicious node can pretend to be a PAA and revoke the 464 access to PaC. 466 T6.3.2: A malicious node can pretend to be a real PaC and transmit a 467 disconnect message. 469 T6.3.3: The PaC can leave the network without notifying the PAA or EP 470 e.g., the Ethernet cable is unplugged, system crash. An 471 attacker can pretend to be the PaC and start using the 472 network. 474 If the link is not shared, the threats T6.3.1 and T6.3.2 are absent. 475 The threat T6.3.3 may still be present. If there is no layer 2 476 indication or the layer 2 indication cannot be relied up on, then the 477 threat T6.3.3 is still present on non-shared links. 479 If the link is shared, all of the above threats are present as any 480 node on the link can spoof the disconnect message. Even if the layer 481 2 has per-packet authentication, the attacker can pretend to be a PaC 482 e.g., by spoofing the IP address, and disconnect from the network. 483 Similarly, any node can pretend to be a PAA and revoke the access to 484 the PaC. Hence, T6.3.1 and T6.3.2 are possible even on links where 485 layer 2 is secured. The threat T6.3.3 can be prevented if layer 2 486 provides per-packet authentication. The attacker cannot subsume the 487 PaC that left the network without knowing the keys that protect the 488 packet at layer 2. 490 Requirement 6 491 PANA threat analysis August 2004 493 PANA MUST be able to protect disconnect and revocation messages. PANA 494 MUST NOT depend on the PaC sending a disconnect message. 496 6.4 Service theft 498 An attacker can gain unauthorized access into the network by stealing 499 the service from another client. Once the real PaC is successfully 500 authenticated, EP will have filters in place to prevent unauthorized 501 access into the network. The filters will be based on something that 502 will be carried on every packet. For example, the filter could be 503 based on IP and MAC address where the packets will be dropped unless 504 the packets coming with certain IP address match the MAC address 505 also. Following are the possible threats. 507 T6.4.1: Attacker can spoof both the IP and MAC address of an 508 authorized client to gain unauthorized access. Attacker can 509 launch this attack easily by just sniffing the wire for IP 510 and MAC address. This lets the attacker use the network 511 without any authorization, getting a free service. 513 T6.4.2: The PaC can leave the network without notifying the PAA or EP 514 e.g., the Ethernet cable is unplugged, system crash. An 515 attacker can pretend to be the PaC and start using the 516 network. 518 Service theft allows the possibility of exploiting the weakness in 519 other authentication protocols that use IP address for 520 authentication. It also allows for intercepting traffic destined for 521 other nodes by spoofing the IP address. 523 If the link is not shared, T6.4.1 is absent as there is only one 524 client on the link and ingress filtering can prevent the use of 525 authorized IP and MAC address by the attacker on another link. The 526 threat T6.4.2 exists as the attacker can use the IP address or MAC 527 address of the real PaC to gain access to the network. 529 If the link is shared, both the threats are present. If layer 2 530 provides per-packet protection using pair-wise keys, both the threats 531 can be prevented. 533 Requirement 7 535 PANA MUST securely bind the authenticated session to the device 536 identifier of the client, to prevent service theft. PANA MUST be able 537 to bootstrap a shared secret between the PaC and PAA which can be 538 further used to setup a security association between PaC and EP to 539 provide cryptographic protection against service theft. 541 PANA threat analysis August 2004 543 6.5 PAA-EP communication 545 After a successful authentication, the PAA needs to communicate the 546 access control information of the PaC to EP so that PaC will be 547 allowed to access the network. The information communicated would 548 contain at least the device identifier of the PaC. If strong security 549 is needed, PAA will communicate a shared secret known only to PaC and 550 PAA, for setting up a security association between PaC and EP. 551 Following are the possible threats. 553 T6.5.1: Attacker can eavesdrop to learn the information communicated 554 between PAA and EP. The attacker can further use this 555 information to spoof the real PaC and also setup an security 556 association for gaining access to the network. This threat is 557 absent, if the attacker cannot eavesdrop the link e.g., PAA 558 and EP are communicating on a separate link from that of 559 visiting PaCs. 561 T6.5.2: Attacker can pretend to be PAA and send false information to 562 EP for gaining access to the network. The attacker has to 563 send its own device identifier and also a shared secret in 564 the case of stronger security so that EP will let the 565 attacker access the network. 567 If the communication between PAA and EP is protected, these threats 568 are absent. 570 Requirement 8 572 The communication between the PAA and EP MUST be protected against 573 eavesdropping and spoofing attacks. 575 6.6 Miscellaneous attacks 577 T6.6.1: There are various forms of DoS attacks that can be launched 578 on the PAA or AS. A few are mentioned below. As it is hard to 579 defend against some of the DoS attacks, the protocol should 580 be designed carefully to mitigate or prevent such attacks. 582 . Attacker can bombard the PAA with lots of 583 authentication requests. If PAA and AS are not 584 collocated, PAA may have to allocate resources to store 585 some state about PaC locally before it receives the 586 response from the backend AS. This can deplete memory 587 resources on PAA. 589 . The attacker can force the PAA or AS to make 590 computationally intensive operations with minimal 591 PANA threat analysis August 2004 593 effort, that can deplete the CPU resources of the PAA 594 or AS. 596 T6.6.2: PaC acquires an IP address by using stateful or stateless 597 mechanisms before PANA authentication begins [PANAREQ]. When 598 the IP addresses are assigned before the client 599 authentication, it opens up the possibility of DoS attacks 600 where unauthenticated malicious nodes can deplete the IP 601 address space by acquiring multiple IP addresses, or denying 602 allocation to others by responding to every duplicate address 603 detection (DAD) query. 605 Depleting a /64 IPv6 link-local address space or a /8 RFC1918 606 private address space requires a brute-force attack. Such an 607 attack is part of a DoS class that can equally target the 608 link capacity or the CPU cycles on the target system by 609 bombarding arbitrary packets. Therefore solely handling the 610 IP address depletion attack is not going to improve the 611 security as a more general solution is needed to tackle the 612 whole class of brute-force attacks. 614 The DAD attack can be prevented by deploying secure address 615 resolution that does not depend on the client authentication, 616 such as [SEND]. The attack may also be prevented if the EP is 617 placed in between the PaCs to monitor the ND/ARP activity and 618 detect DAD attacks (excessive NA/ARP replies). If none of 619 these solutions are applicable to a deployment, the PaCs can 620 send arbitrary packets to each other without going through 621 the EP which enables a class of attacks that are based on 622 interfering with the PANA messaging (See T6.1.1). Since there 623 will always be a threat in this class (e.g., insecure 624 discovery), it is not going to improve the overall security 625 by addressing DAD. 627 7.0 Summary of Requirements 629 1. PANA MUST not assume that the discovery process is protected. 631 2. PANA MUST be able to mutually authenticate the PaC and PAA. 632 PANA MUST be able to establish keys between the PaC and PAA 633 to protect the PANA messages. 635 3. When compound authentication methods are used in PANA, the 636 methods MUST be cryptographically bound. 638 4. PANA MUST be able to protect itself against replay attacks. 640 5. PANA MUST be able to protect the device identifier against 641 spoofing when it is exchanged between the PaC and PAA. 643 PANA threat analysis August 2004 645 6. PANA MUST be able to protect disconnect and revocation 646 messages. PANA MUST NOT depend on the PaC sending a 647 disconnect message. 649 7. PANA MUST securely bind the authenticated session to the 650 device identifier of the client, to prevent service theft. 651 PANA MUST be able to bootstrap a shared secret between the 652 PaC and PAA which can be further used to setup a security 653 association between PaC and EP to provide cryptographic 654 protection against service theft. 656 8. The communication between the PAA and EP MUST be protected 657 against eavesdropping and spoofing attacks. 659 8.0 Security Considerations 661 This document discusses various threats with IP based network access 662 authentication protocol. Though this document discusses the threats 663 separately for shared and unshared links, it may be difficult to make 664 such distinction in practice e.g., a dial-up link may be a 665 point-to-point IP tunnel. Hence, the link should be assumed to be a 666 shared link for most of the threats in this document. 668 9.0 IANA Considerations 670 This document has no actions for IANA. 672 10.0 Normative References 674 [KEYWORDS] S. Bradner, "Key words for use in RFCS to indicate 675 requirement levels", RFC 2119, March 1997. 677 11.0 Informative References 679 [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication for 680 Network Access (PANA) Requirements and Terminology", 681 draft-ietf-pana-requirements-08.txt. 683 [RADIUS] C. Rigney et. al, "Remote Authentication Dial In User 684 Service", RFC2865, June 2000. 686 [EAP-KEY] B. Aboba et. al, "EAP keying framework", 687 draft-ietf-eap-keying-00.txt. 689 [ADDRCONF] S. Thomson et. al, "IPv6 Stateless Address 690 Autoconfiguration", RFC2462, December 1998. 692 PANA threat analysis August 2004 694 [RAD-EAP] B. Aboba, et. al, "Radius support for Extensible 695 authentication protocol", RFC3579, September 2003. 697 [TUN-EAP] J. Puthenkulam et. al, "The compound authentication 698 binding problem", draft-puthenkulam-eap-binding-04.txt. 700 [IPSEC] S. Kent et. al, "Security architecture for the Internet 701 Protocol", RFC 2401, November 1998. 703 [SEND] J. Arkko et. al, "Secure Neighbor Discovery (SEND)", 704 draft-ietf-send-ndopt-05.txt. 706 [IEEE-802.11i] Institute of Electrical and Electronics Engineers 707 "Unapproved Draft Supplement to Standard for Telecommunications and 708 Information Exchange Between systems - LAN/MAN Specific Requirements 709 - Part 11: Wireless LAN Medium Access Control (MAC) and Physical 710 Layer (PHY) Specifications: Specification for Enhanced Security", 711 IEEE Draft 802.11i (work in progress), 2003. 713 [IEEE-802.11] Institute of Electrical and Electronics Engineers, 714 "Information Technology - Telecommunications and Information Exchange 715 between Systems - Local and Metropolitan Area Network - Specific 716 Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and 717 Physical Layer (PHY) Specifications", IEEE Standard 802.11, 1999. 719 12.0 Acknowledgments 721 The author would like to thank the following people (in no specific 722 order) for providing valuable comments: Alper Yegin, Basavaraj Patil, 723 Pekka Nikander, Bernard Aboba, Francis Dupont, Michael Thomas, 724 Yoshihiro Ohba, Gabriel Montenegro, Tschofenig Hannes, Bill 725 Sommerfeld, N. Asokan, Pete McCan, Derek Atkins and Thomas Narten. 727 13.0 Revision Log 729 Changes between 06 and 07 731 -Updates after IESG review 733 Changes between 05 and 06 735 -IANA considerations section added. 737 Changes between 04 and 05 739 -Updates after AD review. 741 Changes between 03 and 04 742 PANA threat analysis August 2004 744 -Added a new requirement for the disconnect notification. 745 -Trust relationship section was rewritten. 746 -Device identifier attack requirements was rewritten. 747 -Service theft requirement was rewritten. 748 -Added a new section for PAA-EP threats. 750 Changes between revision 02 and 03 752 -Changed Requirement 1 to include text about weak authentication 753 suites. 754 -Rearranged the order of definitions in terminology section. 755 -Removed some confusing text with respect to IPsec from the Service 756 theft section. 758 Changes between revision 01 and 02 760 -Renamed the section "Assumptions" to "Trust relationships" and added 761 more text to clarify the relationship between PaC and EP. 762 -Added more text for threats in the path between PAA and AS. 763 -Merged the "Type of Attacks" section into "Threat Scenarios" 764 -Removed the requirement on DoS attack. 765 -Reworded most of the requirements. 767 Changes between revision 00 and 01 769 -Removed unused terms from section 3.0. 770 -Removed identity protection as a threat after feedback from Atlanta 771 IETF55 meeting. 772 -Renamed the section "Attacks on Normal Data communication" to 773 "Service theft". Removed confidentiality as a requirement from that 774 section. 775 -Added a new threat "Device Identifier attack". 777 14.0 Author's Address 779 Mohan Parthasarathy 780 Nokia 781 313 Fairchild Drive 782 Mountain View, CA-94303 784 Email: mohanp@sbcglobal.net 786 Intellectual Property Statement 788 The IETF takes no position regarding the validity or scope of any 789 Intellectual Property Rights or other rights that might be claimed to 790 pertain to the implementation or use of the technology described in 791 this document or the extent to which any license under such rights 792 PANA threat analysis August 2004 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2004). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.