idnits 2.17.1 draft-ietf-pana-threats-eval-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) 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. Since, it is difficult to protect the discovery process, the information exchanged during the discovery process SHOULD be limited. == 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. Since, it is difficult to protect the discovery process, the information exchanged during the discovery process SHOULD be limited. -- 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 (April 2003) is 7674 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'PANAUS' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'RADIUS' is defined on line 557, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-pana-usage-scenarios-03 == Outdated reference: A later version (-09) exists of draft-ietf-pana-requirements-04 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) == Outdated reference: A later version (-22) exists of draft-aboba-radius-rfc2869bis-08 == Outdated reference: A later version (-04) exists of draft-puthenkulam-eap-binding-01 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PANA Working Group 3 Internet Draft 4 Category: Informational 5 Document: draft-ietf-pana-threats-eval-03.txt April 2003 6 Expires: September 2003 8 PANA Threat Analysis and security requirements 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [i]. 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 except that the right to 17 produce derivative works is not granted. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 Abstract 40 The PANA (Protocol for carrying authentication for Network Access) 41 working group is developing methods for authenticating clients to the 42 access network using IP based protocols. This document discusses the 43 threats in general without referring to a specific authentication 44 protocol. The security requirements arising out of these threats will 45 be used as additional input to the PANA WG for designing the IP based 46 network access protocol. 48 Table of Contents 50 1.0 Introduction..................................................2 51 2.0 Keywords......................................................2 52 3.0 Terminology and Definitions.................................3 53 4.0 Usage Scenarios.............................................4 54 5.0 Trust Relationships.........................................4 55 6.0 Threat Scenarios............................................5 56 6.1 PAA Discovery..............................................5 57 6.2 Authentication.............................................6 58 6.3 PaC leaving the network....................................9 59 6.4 Service theft..............................................9 60 6.5 Miscellaneous attacks.....................................10 61 7.0 Summary of Requirements....................................11 62 8.0 Security Considerations....................................12 63 9.0 Normative References.......................................12 64 10.0 Informative References....................................12 65 12.0 Acknowledgments.............................................13 66 13.0 Revision Log................................................13 67 14.0 Author's Addresses..........................................14 68 15.0 Full Copyright Statement....................................14 70 1.0 Introduction 72 The PANA (Protocol for carrying authentication for Network Access) 73 working group is developing methods for authenticating clients to the 74 access network using IP based protocols. This document discusses the 75 threats in general without referring to a specific authentication 76 protocol. 78 A client wishing to get access to the network must carry on multiple 79 steps. First, it needs to discover the IP address of the PANA 80 authentication agent (PAA) and then execute an authentication 81 protocol to authenticate itself to the network. Once the client is 82 authenticated, there might be other messages exchanged during the 83 lifetime of the network access. This document discusses the threats 84 in these steps without discussing any solutions. The requirements 85 arising out of these threats will be used as input to the PANA 86 working group. 88 2.0 Keywords 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [KEYWORDS]. 94 3.0 Terminology and Definitions 96 Device 98 A network element (notebook computer, PDA, etc.) that requires 99 access to a provider's network. 101 Network Access Server (NAS) 103 Network device that provides access to the network. 105 PANA Client (PaC) 107 An entity in the edge subnet who is wishing to obtain network 108 access from a PANA authentication agent within a network. A PANA 109 client is associated with a device and a set of credentials to 110 prove its identity within the scope of PANA. 112 PANA Authentication Agent (PAA) 114 An entity whose responsibility is to authenticate the PANA client 115 (PaC) and grant network access service to the device. 117 Authentication Server (AS) 119 An entity that authenticates the PaC. It may be co-located with 120 PAA or part of the back-end infrastructure. 122 Device Identifier (DI) 124 The identifier used by the network as a handle to control and 125 police the network access of a client. Depending on the access 126 technology, identifier might contain any of IP address, link-layer 127 address, switch port number, etc. of a device. PANA authentication 128 agent keeps a table for binding device identifiers to the PANA 129 clients. At most one PANA client should be associated with a DI on 130 a PANA authentication agent. 132 Enforcement Point (EP) 134 A node that is capable of filtering packets sent by the PaC using 135 the DI information authorized by PAA. 137 Compound methods 139 Authentication protocol where, sequence of methods are used one 140 after an other or where methods are tunneled inside an 141 independently established tunnel between the client and server 142 [TUN-EAP]. 144 4.0 Usage Scenarios 146 PANA is expected to be used in environments where the nodes trust the 147 operator of the network to provide the service but do not trust the 148 other nodes in the network e.g., Public access networks, Hotel, 149 Airport. Note that the usage of word trust above does not mean trust 150 relationship. It just denotes the belief about how the nodes involved 151 in PANA behave in the future. In these environments, one may observe 152 the following. 154 o The link between PaC and PAA may be a shared medium e.g. 155 Ethernet or may not be a shared medium e.g. DSL network. 157 o All the PaCs may be authenticated to the access network at 158 layer 2 (3GPP2 CDMA network) and share a security association 159 with layer 2 authentication agent e.g., 802.11 Access point, 160 but still do not trust each other. 162 The scenarios mentioned above affect the threat model of PANA. This 163 document discusses the various threats in the context of the above 164 network access scenarios for a better understanding of the threats. 166 5.0 Trust Relationships 168 PANA authentication involves a client, PANA agent (PAA), 169 Authentication server (AS) and an Enforcement point (EP). The 170 communication paths involved between the various entities are as 171 follows. 173 1) The path between PaC and PAA 174 2) The path between PaC and EP 175 3) The path between PAA and EP 176 4) The path between PAA and AS 178 This document discusses the threats involved in path (1) and (2). 180 If PAA and EP are co-located, the path between PAA and EP (3) can be 181 considered secure. Even when they are not co-located, the network 182 operators can setup a security association between PAA and EP to 183 secure the traffic between them. Hence it is assumed that path (3) is 184 secure and not discussed further in the document. 186 The authentication server (AS) could be co-located in the same 187 network as PAA or with the back-end system. If it is co-located, then 188 the path (4) can be considered secure. If it is not co-located, there 189 are various threats possible in this path. [RAD-EAP] discusses the 190 possible threats in this path. This implies that if RADIUS is used as 191 the protocol between PAA and AS, then all the vulnerabilities that 192 are mentioned in [RAD-EAP] are applicable to PANA. As it is beyond 193 the scope of PANA to address these threats, this document does not 194 discuss this further. 196 There is no pre-existing trust relationship between PaC and EP. When 197 PaC is successfully authenticated, it will further enable key 198 derivation between PaC and EP, which can be used to secure the link. 199 For example, EAP keying framework [EAP-KEY], defines a three party 200 EAP exchange where the clients derive the transient sessions keys to 201 secure the link between PaC and NAS in their final step. Similarly, 202 PANA will provide the ability to derive keys between PaC and EP that 203 can be used to secure the link further. This is further discussed in 204 section 6.4 below. 206 6.0 Threat Scenarios 208 The PANA authentication client (PaC) needs to discover the PAA first. 209 This involves either sending solicitations or waiting for 210 advertisements. Once it has discovered the PAA, it will lead to 211 authentication exchange with PAA. Once the access is granted, PaC 212 will most likely exchange data with other nodes in the Internet. All 213 of these are vulnerable to denial of service (DoS), man-in-the-middle 214 (MITM) and service theft attacks. 216 The threats are grouped by the various stages the client goes through 217 to gain access to the network. Section 6.1 discusses the threats 218 related to PAA discovery. Section 6.2 discusses about the 219 authentication itself. Section 6.3 discusses about the threats 220 involved while leaving the network. Section 6.4 discusses about 221 service theft. Section 6.5 discusses the miscellaneous threats. 223 6.1 PAA Discovery 225 PaC is in the process of discovering the PAA. The agents like PAA are 226 discovered by sending solicitations or receiving advertisements. 227 Following are the possible threats. 229 T6.1.1: A malicious node can pretend to be a PAA by sending a spoofed 230 advertisement. 232 In existing dial-up networks, the clients authenticate to the network 233 but generally do not verify the authenticity of the messages coming 234 from Network Access Server (NAS). This mostly works because the link 235 between the device and the NAS is not shared with other nodes 236 (assuming that nobody tampers with the physical link), and clients 237 trust the NAS and the phone network to provide the service, without 238 which the network operator will not make any profit. Since in this 239 environment, nodes in the network cannot directly communicate with 240 each other and may assume that the other end of the point-to-point 241 link is the PAA, spoofing attacks are not present. 243 In environments where the link is shared, any node can pretend to be 244 a PAA (including the nodes that are authenticated at layer 2). Hence, 245 the threat is still present in such networks. It is difficult to 246 protect the discovery process, as there is no a priori trust 247 relationship between PAA and PaC. It is also possible that EP might 248 be able to filter out the packets coming from PaC that resembles PAA 249 packets. 251 The advertisement may be used to include other information like 252 supported authentication methods etc., besides the discovery of the 253 PAA itself. This can lead to a bidding down attack, as a malicious 254 node can send a spoofed advertisement with capabilities that indicate 255 less secure authentication methods than what the real PAA supports, 256 thereby fooling the PaC into negotiating a less secure authentication 257 method than what would otherwise be available. This is best avoided 258 by limiting the amount of information sent during the PAA discovery 259 process. 261 Requirement 1 263 PANA MUST not assume that the discovery process is protected. Since, 264 it is difficult to protect the discovery process, the information 265 exchanged during the discovery process SHOULD be limited. 267 6.2 Authentication 269 This section discusses the threats specific to the authentication 270 protocol. Section 6.2.1 discusses the possible threat associated with 271 success/failure indications that are transmitted to PaC at the end of 272 the authentication. Section 6.2.2 discusses the man-in-the-middle 273 attack when compound methods are used. Section 6.2.3 discusses the 274 replay attack and section 6.2.4 discusses about the device identifier 275 attack. 277 6.2.1 Success or Failure Indications 279 An attacker can send false authentication success or failure to the 280 PaC. By sending false failure, the attacker can prevent the client 281 from accessing the network. By sending false success, the attacker 282 can prematurely end the authentication exchange effectively denying 283 service for the PaC. 285 If the link is not shared, it may be hard to launch this attack as 286 the attacker needs to inject this packet at the right time and the 287 PaC can always reject packets coming from any source address other 288 than the PAA. 290 If the link is shared, it is easy to spoof these packets. If layer 2 291 provides per-packet encryption with pair-wise keys, it might make it 292 hard for the attacker to guess the success/failure packet that the 293 client would accept. Even if the node is already authenticated at 294 layer 2, it can still pretend to be a PAA and spoof the success or 295 failure. 297 This attack is possible because the success or failure indication is 298 not protected using a security association between PaC and PAA. In 299 order to avoid this attack, PaC and PAA should mutually authenticate 300 each other. In the process of mutually authenticating each other, 301 they should be able to derive keys to protect the success/failure 302 indications. 304 Requirement 2 306 PaC and PAA MUST mutually authenticate to each other using methods 307 that can derive keys, which in turn can protect the success and 308 failure indications. 310 6.2.2 MITM attack 312 A malicious node can claim to be PAA to the real PaC and claim to be 313 PaC to the real PAA. This is a MITM attack where the PaC is fooled to 314 think that it is communicating with real PAA and the real PAA is 315 fooled to think that it is communicating with real PaC. 317 An instance of MITM attack, when compound authentication methods are 318 used is described in [TUN-EAP]. In these attacks, the server first 319 authenticates to the client. As the client has not proven its 320 identity yet, it acts as the man-in-the-middle, tunneling the 321 identity of the legitimate client to gain access to the network. The 322 attack is possible because there is no verification that the same 323 entities participated among the compound methods. It is not possible 324 to do such verification, if compound methods are used without being 325 able to create cryptographic binding among them. This implies that 326 PANA will be vulnerable to such attacks if compound methods are used 327 without being able to cryptographically bind them. 329 Requirement 3 331 When compound authentication methods are used in PANA, the methods 332 MUST be cryptographically bound. 334 6.2.3 Replay Attack 336 A malicious node can replay the messages that caused authentication 337 failure or success at a later time to create false failures or 338 success. The attacker can also potentially replay other messages of 339 the PANA protocol to deny service to the PaC. 341 This threat is absent if the link is not a shared medium. If the link 342 is shared, then the attacker can replay old messages to deny service 343 to the client. 345 If the packets are encrypted at layer 2 using pair-wise keys, it will 346 make it hard for the attacker to learn the unencrypted (i.e., 347 original) packet that needs to be replayed. Even if layer 2 provides 348 replay protection, the attacker can still replay the PANA messages 349 (layer 3) for denying service to the client. 351 Requirement 4 353 PANA MUST be resistant to replay attacks. 355 6.2.4 Device Identifier attack 357 When the client is successfully authenticated, PAA sends access 358 control information to EP for granting access to the network. The 359 access control information typically contains the device identifier 360 of the PaC, which is obtained from the IP headers and MAC headers of 361 the packets exchanged during the authentication process. The attacker 362 can gain unauthorized access into the network using the following 363 steps. 365 . An attacker pretends to be a PAA and sends advertisements. PaC 366 gets fooled and starts exchanging packets with the attacker. 367 . The attacker modifies the IP source address on the packet, 368 adjusts the UDP/TCP checksum and forwards the packet to the real 369 PAA. It does the same on return packets also. 370 . When the real PaC is successfully authenticated, the attacker 371 gains access to the network as the packets contained the IP 372 address (and potentially the MAC address also) of the attacker. 374 This threat is absent if the link is not a shared medium. If the 375 layer 2 provides per-packet protection, then it is not possible to 376 change the MAC address and hence this threat may be absent in such 377 cases if EP filters both on IP and MAC address. If the link is 378 shared, it is easy to launch this attack. 380 Requirement 5 381 PANA MUST be able to protect the device identifier transmitted from 382 the PaC to PAA. 384 6.3 PaC leaving the network 386 When the PaC leaves the network, it needs to inform the PAA before 387 disconnecting from the network so that the resources used by PaC can 388 be accounted properly. PAA may also choose to revoke the access any 389 time if it deems necessary. Following are the possible threats. 391 T6.3.1: A malicious node can pretend to be a PAA and revoke the 392 access to PaC. 394 T6.3.2: A malicious node can pretend to be a real PaC and transmit a 395 disconnect message. 397 This threat is absent if the link between PaC and PAA is not a shared 398 medium. 400 If the link is shared, any node on the link can spoof the disconnect 401 message. Even if the layer 2 has per-packet authentication, the 402 attacker can pretend to be a PaC e.g. by spoofing the IP address, and 403 disconnect from the network. Similarly, any node can pretend to be a 404 PAA and revoke the access to the PaC. 406 In some link layers, e.g., 802.11, disassociate and de-authenticate 407 messages are not protected (even with 802.11i). In such link layers, 408 protecting PANA messages may not be very useful as the attacker can 409 attack using the link layer mechanisms rather than PANA. 411 Requirement 6 413 PANA MUST be able to protect disconnect and revocation messages. 415 6.4 Service theft 417 An attacker can gain unauthorized access into the network by stealing 418 the service from another client. Once the PaC is successfully 419 authenticated, EP will have filters in place to prevent unauthorized 420 access into the network. The filters will be based on something that 421 will be carried on every packet. For example, the filter could be 422 based on IP and MAC address where the packets will be dropped unless 423 the packets coming with certain IP address match the MAC address 424 also. Following are the possible threats. 426 T6.4.1: Attacker can spoof both the IP and MAC address of an 427 authorized client to gain unauthorized access. Attacker can launch 428 this attack easily by just sniffing the wire for IP and MAC address. 429 This lets the attacker use the network without any authorization thus 430 getting a free service. 432 These threats are absent in links that are not shared as simple 433 ingress filtering can prevent one node from impersonating as another 434 node. 436 If the link between PaC and PAA is shared, it is easy to launch this 437 attack. If layer 2 provides per-packet protection using pair-wise 438 keys, it can prevent the attacker from gaining unauthorized access 439 using the layer 2 identifier of some other node. 441 PANA MUST be able to prevent service theft. In some cases e.g. non- 442 shared links, it is sufficient to provide access control information 443 like IP address, MAC address, etc., to EP, which in turn can prevent 444 unauthorized users from gaining access to the network by policing the 445 packets for matching addresses. In the case of shared links, this 446 information is not sufficient to prevent service theft. PANA MUST be 447 able to bootstrap a shared secret between the PaC and PAA which can 448 be further used to setup a security association (e.g., IPsec) between 449 PaC and EP to prevent service theft on shared links. 451 Requirement 7 453 PANA MUST be able to generate sufficient access control information 454 like IP address, MAC address etc. for EP to prevent service theft. 455 PANA MUST be able to bootstrap a shared secret between the PaC and 456 PAA which can be further used to setup a security association (e.g., 457 IPsec) between PaC and EP to prevent service theft on shared links. 459 6.5 Miscellaneous attacks 461 T6.5.1: There are various forms of DoS attacks that can be launched 462 on the PAA or AS. A few are mentioned below. AS it is hard to protect 463 against, there is no specific requirement on DoS attack. Protocol 464 should be designed carefully to mitigate or prevent such attacks. 466 . Attacker can bombard the PAA with lots of authentication 467 requests. If PAA and AS are not collocated, PAA may have to 468 allocate resources to store some state about PaC locally before 469 it receives the response from the backend AS. This can deplete 470 memory resources on PAA. 471 . The attacker can force the PAA or AS to make a public key 472 computation with minimal effort, that can deplete the CPU 473 resources of the PAA or AS. 475 T6.5.2: PaC acquires IP address before PANA authentication begins 476 using methods like e.g., DHCP in IPv4 and auto-configuration in IPv6 477 [PANAREQ]. If IP addresses are assigned before authentication, it 478 opens up the possibility of DoS attack where malicious nodes can 479 deplete the IP addresses by assigning multiple IP addresses. If 480 stateless auto-configuration [ADDRCONF] is used, the attacker can 481 respond to duplicate address detection probes sent by any node on the 482 network effectively not allowing the node to configure a link local 483 address. If stateful mechanism is used in IPv6 e.g., DHCPv6, then 484 this attack is still possible. Address depletion attack is not 485 specific to PANA, but a known attack in DHCP [DHCP-AUTH]. If PANA 486 assumes that the client has an IP address already, it opens up the 487 network to the DoS attack. 489 Requirement 8 491 PANA should not assume that the PaC has acquired an IP address before 492 PANA begins. 494 7.0 Summary of Requirements 496 1. PANA MUST not assume that the discovery process is protected. 497 Since, it is difficult to protect the discovery process, the 498 information exchanged during the discovery process SHOULD be 499 limited. 501 2. PaC and PAA MUST mutually authenticate to each other using 502 methods that can derive keys, which in turn can protect the 503 success and failure indications. 505 3. When compound authentication methods are used in PANA, the 506 methods MUST be cryptographically bound. 508 4. PANA MUST be resistant to replay attacks. 510 5. PANA MUST be able to protect the device identifier 511 transmitted from the PaC to PAA. 513 6. PANA MUST be able to protect disconnect and revocation 514 messages. 516 7. PANA MUST be able to generate sufficient access control 517 information like IP address, MAC address etc. for EP to 518 prevent service theft. PANA MUST be able to bootstrap a 519 shared secret between the PaC and PAA which can be further 520 used to setup a security association (e.g., IPsec) between 521 PaC and EP to prevent service theft on shared links. 523 8. PANA should not assume that the PaC has acquired an IP 524 address before PANA begins. 526 8.0 Security Considerations 528 This document discusses various threats with IP based network access 529 protocol. 531 9.0 Normative References 533 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 534 9, RFC 2026, October 1996. 536 2. [PANAUS] Yoshihiro Ohba et. al, "Problem Space and Usage Scenarios 537 for PANA", draft-ietf-pana-usage-scenarios-03.txt 539 3. [PANAREQ] A. Yegin et al., "Protocol for Carrying Authentication 540 for Network Access (PANA) Requirements and Terminology", draft- 541 ietf-pana-requirements-04.txt 543 4. [KEYWORDS] S. Bradner, "Key words for use in RFCS to indicate 544 requirement levels", RFC 2119, March 1997 546 10.0 Informative References 548 5. Bernard Aboba, "Pros and Cons of Upper Layer Network Access", 549 BURP BOF. 551 6. Arunesh Mishra, William A. Arbaugh, "An Initial Security Analysis 552 of the IEEE 802.1X Standard" 554 7. IEEE. Standard for port based network access control. IEEE Draft 555 P802.1X 557 8. [RADIUS] C. Rigney et.al, "Remote Authentication Dial In User 558 Service". 560 9. [EAP-KEY] Bernard Aboba et. al, "EAP keying framework", Work in 561 Progress. 563 10. [ADDRCONF] Susan Thomson et. al "IPv6 Stateless Address 564 Autoconfiguration", RFC2462. 566 11. [DHCP-AUTH] R. Droms, et. al "Authentication for DHCP messages", 567 RFC3118. 569 12. [RAD-EAP] Bernard Aboba, et. al "Radius support for Extensible 570 authentication protocol", draft-aboba-radius-rfc2869bis-08.txt 572 13. [TUN-EAP] J. Puthenkulam et. al "The compound authentication 573 binding problem", draft-puthenkulam-eap-binding-01.txt 575 12.0 Acknowledgments 577 The author would like to thank the following people (in no specific 578 order) for providing comments: Alper Yegin, Basavaraj Patil, Pekka 579 Nikkander, Bernard Aboba, Francis Dupont, Michael Thomas, Yoshihiro 580 Ohba, Gabriel Montenegro, Tschofenig Hannes and Bill Sommerfeld. 582 13.0 Revision Log 584 Changes between 02 and 03 585 - Changed Requirement 1 to include text about weak 586 authentication suites. 587 - Clarified text in a few places. 588 - Rearranged the order of definitions in terminology 589 section. 590 - Removed some confusing text with respect to IPsec from 591 the Service theft section. 593 Changes between revision 01 and 02 595 - Renamed the section "Assumptions" to "Trust relationships" 596 and added more text to clarify the relationship between PaC 597 and EP. 598 - Added more text for threats in PAA � AS path 599 - Merged the "Type of Attacks" section into "Threat Scenarios" 600 - Removed the requirement on DoS attack 601 - Reworded most of the requirements 603 Changes between revision 00 and 01. 605 - Removed unused terms from section 3.0 606 - Removed identity protection as a threat after feedback from 607 Atlanta IETF55 meeting. 609 - Renamed the section "Attacks on Normal Data communication" 610 to "Service theft". Removed confidentiality as a requirement 611 from that section. 612 - Added a new threat "Device Identifier attack". 614 14.0 Author's Addresses 616 Mohan Parthasarathy 617 Tahoe Networks 618 3052 Orchard Drive 619 San Jose, CA 95134 621 Phone: 408-944-8220 622 Email: mohanp@tahoenetworks.com 624 15.0 Full Copyright Statement 626 Copyright (C) The Internet Society (2003). All Rights Reserved. 628 This document and translations of it may be copied and furnished to 629 others, and derivative works that comment on or otherwise explain it 630 or assist in its implementation may be prepared, copied, published 631 and distributed, in whole or in part, without restriction of any 632 kind, provided that the above copyright notice and this paragraph are 633 included on all such copies and derivative works. However, this 634 document itself may not be modified in any way, such as by removing 635 the copyright notice or references to the Internet Society or other 636 Internet organizations, except as needed for the purpose of 637 developing Internet standards in which case the procedures for 638 copyrights defined in the Internet Standards process must be 639 followed, or as required to translate it into languages other than 640 English. 642 The limited permissions granted above are perpetual and will not be 643 revoked by the Internet Society or its successors or assigns. 645 This document and the information contained herein is provided on an 646 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 647 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 648 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 649 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 650 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 652 Acknowledgement 654 Funding for the RFC Editor function is currently provided by the 655 Internet Society.