idnits 2.17.1 draft-ietf-rserpool-threats-15.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 832. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 838. 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 (July 8, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-asap-20 == Outdated reference: A later version (-21) exists of draft-ietf-rserpool-enrp-20 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Stillman, Ed. 3 Internet-Draft Nokia 4 Intended status: Informational R. Gopal 5 Expires: January 9, 2009 Nokia Siemens Networks 6 E. Guttman 7 Sun Microsystems 8 M. Holdrege 9 Strix Systems 10 S. Sengodan 11 Nokia Siemans Networks 12 July 8, 2008 14 Threats Introduced by RSerPool and Requirements for Security in Response 15 to Threats 16 draft-ietf-rserpool-threats-15.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 9, 2009. 43 Abstract 45 RSerPool is an architecture and set of protocols for the management 46 and access to server pools supporting highly reliable applications 47 and for client access mechanisms to a server pool. This Internet 48 draft describes security threats to the RSerPool architecture and 49 presents requirements for security to thwart these threats. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. PE Registration/Deregistration flooding -- 58 non-existent PE . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. PE Registration/Deregistration flooding -- 60 unauthorized PE . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. PE Registration/Deregistration spoofing . . . . . . . . . 6 62 2.4. PE Registration/Deregistration unauthorized . . . . . . . 6 63 2.5. Malicious ENRP server joins the group of legitimate 64 ENRP servers . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.6. Registration/deregistration with malicious ENRP server . . 7 66 2.7. Malicious ENRP Handlespace Resolution . . . . . . . . . . 8 67 2.8. Malicious node performs a replay attack . . . . . . . . . 9 68 2.9. Re-establishing PU-PE security during failover . . . . . . 9 69 2.10. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.11. Data Confidentiality . . . . . . . . . . . . . . . . . . . 10 71 2.12. ENRP Server Discovery . . . . . . . . . . . . . . . . . . 11 72 2.13. Flood of endpoint unreachable messages from the PU to 73 the ENRP server . . . . . . . . . . . . . . . . . . . . . 12 74 2.14. Flood of endpoint keep alive messages from the ENRP 75 server to a PE . . . . . . . . . . . . . . . . . . . . . . 12 76 2.15. Security of the ENRP database . . . . . . . . . . . . . . 13 77 2.16. Cookie mechanism security . . . . . . . . . . . . . . . . 13 78 2.17. Potential insider attacks from legitmate ENRP servers . . 14 79 3. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 5. Normative References . . . . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Intellectual Property and Copyright Statements . . . . . . . . . . 19 85 1. Introduction 87 The RSerPool architecture[I-D.ietf-rserpool-overview] supports high- 88 availability and load balancing by enabling a pool user to identify 89 the most appropriate server from the server pool at a given time. 90 The architecture is defined to support a set of basic goals. These 91 include an application-independent protocol mechanisms, separation of 92 server naming from IP addressing, the use of the end-to-end principle 93 to avoid dependencies on intermediate equipment, separation of 94 session availability/failover functionality from application itself, 95 the ability to facilitate different server selection policies, the 96 ability to facilitate a set of application-independent failover 97 capabilities and a peer-to-peer structure. 99 RSerPool provides a session layer for robustness. The session layer 100 function may redirect communication transparently to upper layers. 101 This alters the direct one-to-one association between communicating 102 endpoints which typically exists between clients and servers. In 103 particular, secure operation of protocols often relies on assumptions 104 at different layers regarding the identity of the communicating party 105 and the continuity of the communication between endpoints. Further, 106 the operation of RSerPool itself has security implications and risks. 107 The session layer operates dynamically which imposes additional 108 concerns for the overall security of the end-to-end application. 110 This document explores the security implications of RSerPool, both 111 due to its own functions and due to its being interposed between 112 applications and transport interfaces. 114 This document is related to the RSerPool 115 ASAP[I-D.ietf-rserpool-asap]and ENRP [I-D.ietf-rserpool-enrp]protocol 116 documents which describe in their security consideration sections the 117 mechanisms for meeting the security requirements in this document. 118 TLS[RFC4346] is the security mechanism for RSerPool that was selected 119 to meet all the requirements described in this document. The 120 security considerations section of ASAP and ENRP describes how TLS is 121 actually used to provide the security that is discussed in this 122 document. 124 1.1. Definitions 126 This document uses the following terms: 128 Endpoint Name Resolution Protocol (ENRP): 129 Within the operational scope of RSerPool, 130 ENRP[I-D.ietf-rserpool-enrp] defines the procedures and message 131 formats of a distributed fault-tolerant registry service for 132 storing, bookkeeping, retrieving, and distributing pool operation 133 and membership information. 135 Aggregate Server Access Protocol (ASAP): 136 ASAP[I-D.ietf-rserpool-asap] is a session layer protocol which 137 uses ENRP to provide a high availability handlespace. ASAP is 138 responsible for the abstraction of the underlying transport 139 technologies, load distribution management,fault management, as 140 well as the presentation to the upper layer (i.e., the ASAP user) 141 a unified primitive interface. 143 Operational scope: 144 The part of the network visible to pool users by a specific 145 instance of the reliable server pooling protocols. 147 Pool (or server pool): 148 A collection of servers providing the same application 149 functionality. 151 Pool handle: 152 A logical pointer to a pool. Each server pool will be 153 identifiable in the operational scope of the system by a unique 154 pool handle. 156 ENRP handlespace (or handlespace): 157 A cohesive structure of pool names and relations that may be 158 queried by a client. A client in this context is an application 159 that accesses another remote application running on a server using 160 a network. 162 Pool element (PE): A server entity having registered to a pool. 164 Pool user (PU): A server pool user. 166 1.2. Conventions 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 2. Threats 174 2.1. PE Registration/Deregistration flooding -- non-existent PE 176 2.1.1. Threat 178 A malicious node could send a stream of false registrations/ 179 deregistrations on behalf of non-existent PEs to ENRP servers at a 180 very rapid rate and thereby create unnecessary state in an ENRP 181 server. 183 2.1.2. Effect 185 The malicious node will corrupt the pool registrar database and/or 186 disable the RSerPool discovery and database function. This 187 represents a denial of service attack as the PU would potentially get 188 an IP address of a non-existent PE in response to an ENRP query. 190 2.1.3. Requirement 192 An ENRP server that receives a registration/deregistration MUST NOT 193 create or update state information until it has authenticated the PE. 194 TLS with PSK is mandatory to implement as the authentication 195 mechanism. For PSK, having a pre-shared-key constitutes 196 authorization.The network administrators of a pool need to decide 197 which nodes are authorized to participate in the pool. The 198 justification for PSK is that we assume that one administrative 199 domain will control and manage the server pool. This allows for PSK 200 to be implemented and managed by a central security administrator. 202 2.2. PE Registration/Deregistration flooding -- unauthorized PE 204 2.2.1. Threat 206 A malicious node or PE could send a stream of registrations/ 207 deregistrations that are unauthorized to register/deregister - to 208 ENRP servers at a very rapid rate and thereby create unnecessary 209 state in an ENRP server. 211 2.2.2. Effect 213 This attack will corrupt the pool registrar database and/or disable 214 the RSerPool discovery and database function. There is the potential 215 for two types of attacks, denial of service and data interception. 216 In the denial of service attack, the PU gets an IP address of a rogue 217 PE in response to an ENRP query which might not provide the actual 218 service. In addition, a flood of message could prevent legitimate 219 PEs from registering. In the data interception attack, the rogue PE 220 does provide the service as man in the middle which allows the 221 attacker to collect data. 223 2.2.3. Requirement 225 An ENRP server that receives a registration/deregistration MUST NOT 226 create or update state information until the authentication 227 information of the registering/de-registering entity is verified. 229 TLS is used as the authentication mechanism between the ENRP server 230 and PE. TLS with PSK is mandatory to implement as the authentication 231 mechanism. For PSK, having a pre-shared-key constitutes 232 authorization.The network administrators of a pool need to decide 233 which nodes are authorized to participate in the pool. 235 2.3. PE Registration/Deregistration spoofing 237 2.3.1. Threat 239 A malicious node could send false registrations/deregistrations to 240 ENRP servers concerning a legitimate PE thereby creating false state 241 information in the ENRP servers. 243 2.3.2. Effect 245 This would generate misinformation in the ENRP server concerning a PE 246 and would be propagated to other ENRP servers thereby corrupting the 247 ENRP database. DDoS, by adding a PE that is a target for DDoS attack 248 for some popular high volume service the attacker can register a PE 249 that a lot of PUs will try to connect to. This allows man in the 250 middle or masquerade attacks on the service provided by the 251 legitimate PEs. If a attacker registers its server address as a PE 252 and handles the requests he can eavesdrop on service data. 254 2.3.3. Requirement 256 An ENRP server that receives a registration/deregistration MUST NOT 257 create or update state information until it has authenticated the PE. 258 TLS is used as the authentication mechanism between the ENRP server 259 and the PE. TLS with PSK is mandatory to implement as the 260 authentication mechanism. For PSK, having a pre-shared-key 261 constitutes authorization.The network administrators of a pool need 262 to decide which nodes are authorized to participate in the pool. A 263 PE can register only for itself and cannot register on behalf of 264 other PEs. 266 2.4. PE Registration/Deregistration unauthorized 268 2.4.1. Threat 270 A PE who is not authorized to join a pool could send registrations/ 271 deregistrations to ENRP servers thereby creating false state 272 information in the ENRP servers. 274 2.4.2. Effect 276 This attack would generate misinformation in the ENRP server 277 concerning a PE and would be propagated to other ENRP servers thereby 278 corrupting the ENRP database. This allows man in the middle or 279 masquerade attacks on the service provided by the legitimate PEs. If 280 a attacker registers its server address as a PE and handles the 281 requests he can eavesdrop on service data. 283 2.4.3. Requirement 285 An ENRP server that receives a registration/deregistration MUST NOT 286 create or update state information until it has authorized the 287 requesting entity. TLS is used as the authentication mechanism. TLS 288 with PSK is mandatory to implement as the authentication mechanism. 289 For PSK, having a pre-shared-key constitutes authorization.The 290 network administrators of a pool need to decide which nodes are 291 authorized to participate in the pool. 293 2.5. Malicious ENRP server joins the group of legitimate ENRP servers 295 2.5.1. Threat 297 A malicious ENRP server joins the group of legitimate ENRP servers 298 with the intent of propagating inaccurate updates to corrupt the ENRP 299 database. The attacker sets up an ENRP server and attempts to 300 communicate with other ENRP servers. 302 2.5.2. Effect 304 The result would be Inconsistent ENRP database state. 306 2.5.3. Requirement 308 ENRP servers MUST perform mutual authentication. This would prevent 309 the attacker from joining its ENRP server to the pool. TLS is used 310 as the mutual authentication mechanism. TLS with PSK is mandatory to 311 implement as the authentication mechanism. For PSK, having a pre- 312 shared-key constitutes authorization.The network administrators of a 313 pool need to decide which nodes are authorized to participate in the 314 pool. 316 2.6. Registration/deregistration with malicious ENRP server 318 2.6.1. Threat 320 A PE unknowingly registers/deregisters with malicious ENRP server. 322 2.6.2. Effect 324 The registration might not be properly processed or ignored. A rogue 325 ENRP server has the ability to return any address to a user 326 requesting service which could result in denial of service or 327 connection to a rouge PE of the attackers choice for service. 329 2.6.3. Requirement 331 The PE MUST authenticate the ENRP server. TLS is the mechanism used 332 for the authentication. TLS with PSK is mandatory to implement as 333 the authentication mechanism. For PSK, having a pre-shared-key 334 constitutes authorization.The network administrators of a pool need 335 to decide which nodes are authorized to participate in the pool. 336 This requirement prevents malicious outsiders and insiders from 337 adding their own ENRP server to the pool. 339 2.7. Malicious ENRP Handlespace Resolution 341 2.7.1. Threat 343 The ASAP protocol receives a handlespace resolution response from an 344 ENRP server, but the ENRP server is malicious and returns random IP 345 addresses or an inaccurate list in response to the pool handle. 347 2.7.2. Effect 349 PU application communicates with the wrong PE or is unable to locate 350 the PE since the response is incorrect in saying that a PE with that 351 handle did not exist. A rouge ENRP server has the ability to return 352 any address to ASAP requesting an address list which could result in 353 denial of service or connection to a rouge PE of the attackers choice 354 for service. From the PE, the attacker could eavesdrop or tamper 355 with the application. 357 2.7.3. Requirement 359 ASAP SHOULD authenticate the ENRP server. TLS with certificates is 360 the mandatory to implement mechanism used for authentication. The 361 administrator uses a centralized CA to generate and sign 362 certificates. The certificate is stored on the ENRP server. A CA 363 trusted root certification authority certificate is sent to the 364 client out of band and the certificate signature on the ENRP server 365 certificate is checked for validity during TLS handshake. This 366 authentication prevents malicious outsiders and insiders from adding 367 an ENRP server to the pool that may be accessed by ASAP. 369 2.8. Malicious node performs a replay attack 371 2.8.1. Threat 373 A malicious node could replay the entire message previously sent by a 374 legitimate entity. This could create false/unnecessary state in the 375 ENRP servers when the replay is for registration/de-registration or 376 update. 378 2.8.2. Effect 380 The result is that false/extra state is maintained by ENRP servers. 381 This would most likely be used as a denial of service attack if the 382 replay is used to deregister all PEs. 384 2.8.3. Requirement 386 The protocol MUST prevent replay attacks. The replay attack 387 prevention mechanism in TLS meets this requirement. 389 2.9. Re-establishing PU-PE security during failover 391 2.9.1. Threat 393 PU fails over from PE A to PE B. In the case that the PU had a 394 trusted relationship with PE A, then the PU will likely not have the 395 same relationship established with PE B. 397 2.9.2. Effect 399 If there was a trust relationship involving security context between 400 PU and PE A, the equivalent trust relationship will not exist between 401 PU and PE B. This will violate security policy. For example, if the 402 security context with A involves encryption and the security context 403 with B does not then an attacker could take advantage of the change 404 in security. 406 2.9.3. Requirement 408 The application SHOULD be notified when fail over occurs so the 409 application can take appropriate action to establish a trusted 410 relationship with PE B. ENRP has a mechanism to perform this 411 function. 413 2.10. Integrity 414 2.10.1. Threat 416 The following are all instances of the same class of threats, and all 417 have similar effects. 419 a. ENRP response to pool handle resolution is corrupted during 420 transmission 422 b. ENRP peer messages are corrupted during transmission 424 c. PE sends update for values and that information is corrupted 425 during transmission 427 2.10.2. Effect 429 The result is that ASAP receives corrupt information for pool handle 430 resolution which the PU believes to be accurate. This corrupt 431 information could be an IP address that does not resolve to a PE so 432 the PU would not be able to contact the server. 434 2.10.3. Requirement 436 An integrity mechanism MUST be present. Corruption of data that is 437 passed to the PU means that the PU can't rely on it. The consequence 438 of corrupted information is that the IP addresses passed to the PU 439 might be wrong in which case it will not be able to reach the PE. 440 The interfaces that MUST implement integrity are PE to ENRP server 441 and ENRP to ENRP server. The integrity mechanism in TLS is used for 442 this. 444 2.11. Data Confidentiality 446 2.11.1. Threat 448 An eavesdropper capable of snooping on fields within messages in 449 transit, may be able to gather information such as 450 topology/location/IP addresses etc. that may not be desirable to 451 divulge. 453 2.11.2. Effect 455 Information that an administrator does not wish to divulge is 456 divulged. The attacker gains valuable information that can be used 457 for financial gain or attacks on hosts. 459 2.11.3. Requirement 461 A provision for data confidentiality service SHOULD be available. 462 TLS provides data confidentiality in support of this mechanism. 464 2.12. ENRP Server Discovery 466 2.12.1. Threats 468 a. Thwarting successful discovery: When a PE wishes to register with 469 an ENRP server, it needs to discover an ENRP server. An attacker 470 could thwart the successful discovery of ENRP server(s) thereby 471 inducing the PE to believe that no ENRP server is available. For 472 instance, the attacker could reduce the returned set of ENRP 473 servers to null or a small set of inactive ENRP servers. The 474 attacker performs a MITM attack to do this. 476 b. A similar thwarting scenario also applies when an ENRP server or 477 ASAP on behalf of a PU needs to discover ENRP servers. 479 c. Spoofing successful discovery: An attacker could spoof the 480 discovery by claiming to be a legitimate ENRP server. When a PE 481 wishes to register, it finds the spoofed ENRP server. An 482 attacker can only make such a claim if no security mechanisms are 483 used. 485 d. A similar spoofing scenario also applies when an ENRP server or 486 ASAP on behalf of a PU needs to discover ENRP servers. 488 2.12.2. Effects (letters correlate with threats above) 490 a. A PE that could have been in an application server pool does not 491 become part of a pool. The PE does not complete discovery 492 operation. This is a DOS attack. 494 b. An ENRP server that could have been in an ENRP server pool does 495 not become part of a pool. A PU is unable to utilize services of 496 ENRP servers. 498 c. This malicious ENRP would either misrepresent, ignore or 499 otherwise hide or distort information about the PE to subvert 500 RSerPool operation. 502 d. Same as above. 504 2.12.3. Requirement 506 A provision for authentication MUST be present and a provision for 507 data confidentiality service SHOULD be present. TLS has a mechanism 508 for confidentiality. 510 2.13. Flood of endpoint unreachable messages from the PU to the ENRP 511 server 513 2.13.1. Threat 515 Endpoint unreachable messages are sent by ASAP to the ENRP server 516 when it is unable to contact a PE. There is the potential that a PU 517 could flood the ENRP server intentionally or unintentionally with 518 these messages. The non-malicious case would require an incorrect 519 implementation. The malicious case would be caused by writing code 520 to flood the ENRP server with endpoint unreachable messages. 522 2.13.2. Effect 524 The result is a DOS attack on the ENRP server. The ENRP server would 525 not be able to service other PUs effectively and would not be able to 526 take registrations from PEs in a timely manner. Further, it would 527 not be able to communicate with other ENRP servers in the pool to 528 update the database in a timely fashion. 530 2.13.3. Requirement 532 The number of endpoint unreachable messages sent to the ENRP server 533 from the PU SHOULD be limited. This mechanism is described in the 534 ASAP[I-D.ietf-rserpool-asap] protocol document. 536 2.14. Flood of endpoint keep alive messages from the ENRP server to a 537 PE 539 2.14.1. Threat 541 Endpoint keep-alive messages would be sent from the ENRP server to 542 the PEs during the process of changing the home ENRP server for this 543 PE. 545 2.14.2. Effect 547 If the ENRP server maliciously sent a flood of endpoint keep alive 548 messages to the PE, the PE would not be able to service clients. The 549 result is an unintentional DOS attack on the PE. 551 2.14.3. Requirement 553 ENRP MUST limit the frequency of keep alive messages to a given PE to 554 prevent overwhelming the PE. This mechanism is described in 555 ENRP.[I-D.ietf-rserpool-enrp] protocol document. 557 2.15. Security of the ENRP database 559 2.15.1. Threat 561 Another consideration involves the security characteristics of the 562 ENRP database. Suppose that some of the PEs register with an ENRP 563 server using security and some do not. In this case, when a client 564 requests handle space resolution information from ENRP, it would have 565 to be informed which entries are "secure" and which are not. 567 2.15.2. Effect 569 This would not only complicate the protocol, but actually bring into 570 question the security and integrity of such a database. What can be 571 asserted about the security of such a database is a very thorny 572 question. 574 2.15.3. Requirement 576 The requirement is that either the entire ENRP server database MUST 577 be secure, that is, it has registrations exclusively from PEs that 578 have used security mechanisms or the entire database MUST be 579 insecure, that is, registrations are from PEs that have used no 580 security mechanisms. ENRP servers that support security MUST reject 581 any PE server registration that does not use the security mechanisms. 582 Likewise, ENRP servers that support security MUST NOT accept updates 583 from other ENRP servers that do not use security mechanisms. TLS is 584 used as the security mechanism so any information not sent using TLS 585 to a secure ENRP server MUST be rejected. 587 2.16. Cookie mechanism security 589 The application layer is out of scope for RSerPool. However, some 590 questions have been raised about the security of the cookie mechanism 591 which will be addressed. 593 Cookies are passed via the ASAP control channel. If TCP is selected 594 as the transport, then the data and control channel MUST be 595 multiplexed. Therefore, the cases: 597 a. control channel is secured; data channel is not 598 b. data channel is secured; control channel is not 600 are not possible as the multiplexing onto one TCP port results in 601 security for both data and control channels or neither. 603 The multiplexing requirement results in the following cases: 605 1. the multiplexed control channel-data channel is secure OR 607 2. the multiplexed control channel-data channel is not secured 609 This applies to cookies in the sense that if you choose to secure 610 your control-data channel, then the cookies are secured. 612 A second issue is that the PE could choose to sign and/or encrypt the 613 cookie. In this case, it must share keys and other information with 614 other PEs. This application level state sharing is out of scope of 615 RSerPool. 617 2.17. Potential insider attacks from legitmate ENRP servers 619 The previous text does not address all byzantine attacks that could 620 arise from legitimate ENRP servers. True protection against 621 misbehavior by authentic (but rogue) servers is beyond the capability 622 of TLS security mechanisms. Authentication using TLS does not 623 protect against byzantine attacks as authenticated ENRP servers might 624 have been maliciously hacked. Protections against insider attacks 625 are generally specific to the attack, so more experimentation is 626 needed. For example, the following discusses two insider attacks and 627 potential mitigations. 629 One issue is that legitimate users may choose to not follow the 630 proposed policies regarding choice of servers (namely, members in the 631 pool). If the "choose a member at random" policy is employed, then a 632 pool user can always set its "random choices" so that it picks a 633 particular pool member. This bypasses the "load sharing" idea behind 634 the policy. Another issue is that a pool member (or server) may 635 report a wrong policy to a user. 637 To mitigate the first attack, the protocol may require the pool user 638 to "prove" to the pool member that the pool member was chosen 639 "randomly", say by demonstrating that the random choice was the 640 result of applying some hash function to a public nonce. Different 641 methods may be appropriate for other member scheduling policies. 643 To mitigate the second attack, the protocol might require the PE to 644 sign the policy sent to the ENRP server. During pool handle 645 resolution, the signed policy needs to be sent from an ENRP server to 646 an ASAP endpoint in a way that will allow the user to later hold the 647 server accountable to the policy. 649 3. Security Considerations 651 This informational document characterizes potential security threats 652 targeting the RSerPool architecture. The security mechanisms 653 required to mitigate these threats are summarized for each 654 architectural component. It will be noted which mechanisms are 655 required and which are optional. 657 From the threats described in this document, the security services 658 required for the RSerPool protocol suite are given in the following 659 table. 661 +--------------+----------------------------------------------------+ 662 | Threat | Security mechanism in response | 663 +--------------+----------------------------------------------------+ 664 | Section 2.1 | ENRP server authenticates the PE. | 665 | Section 2.2 | ENRP server authenticates the PE. | 666 | Section 2.3 | ENRP server authenticates the PE. | 667 | Section 2.4 | ENRP server authenticates the PE. | 668 | Section 2.5 | ENRP servers mutually authenticate. | 669 | Section 2.6 | PE authenticates the ENRP server. | 670 | Section 2.7 | The PU authenticates the ENRP server. If the | 671 | | authentication fails, it looks for another ENRP | 672 | | server. | 673 | Section 2.8 | Security protocol which has protection from replay | 674 | | attacks. | 675 | Section 2.9 | Either notify the application when fail over | 676 | | occurs so the application can take appropriate | 677 | | action to establish a trusted relationship with PE | 678 | | B OR reestablish the security context | 679 | | transparently. | 680 | Section 2.10 | Security protocol which supports integrity | 681 | | protection. | 682 | Section 2.12 | Security protocol which supports data | 683 | | confidentiality. | 684 | Section 2.11 | The PU authenticates the ENRP server. If the | 685 | | authentication fails, it looks for another ENRP | 686 | | server. | 687 | Section 2.13 | ASAP must control the number of endpoint | 688 | | unreachable messages transmitted from the PU to | 689 | | the ENRP server. | 690 | Section 2.14 | ENRP server must control the number of | 691 | | Endpoint_KeepAlive messages to the PE. | 692 +--------------+----------------------------------------------------+ 693 The first four threats combined with the sixth threat result in a 694 requirement for mutual authentication of the ENRP server and the PE. 696 To summarize the first twelve threats require security mechanisms 697 which support authentication, integrity, data confidentiality and 698 protection from replay attacks. For RSerPool we need to authenticate 699 the following: 701 o PU -----> ENRP Server (PU authenticates the ENRP server) 703 o PE <----> ENRP Server (mutual authentication) 705 o ENRP server <-----> ENRP Server (mutual authentication) 707 Summary by component: 709 RSerPool client -- mandatory to implement authentication of the ENRP 710 server is required for accurate pool handle resolution. This is 711 to protect against threats from rogue ENRP servers. In addition, 712 confidentiality, integrity and preventing replay attack are also 713 mandatory to implement to protect from eavesdropping and data 714 corruption or false data transmission. Confidentiality is 715 mandatory to implement and is used when privacy is required. 717 PE to ENRP communications -- mandatory to implement mutual 718 authentication, integrity and protection from replay attack is 719 required for PE to ENRP communications. This is to protect the 720 integrity of the ENRP handle space database. Confidentiality is 721 mandatory to implement and is used when privacy is required. 723 ENRP to ENRP communications -- mandatory to implement mutual 724 authentication, integrity and protection from replay attack is 725 required for ENRP to ENRP communications. This is to protect the 726 integrity of the ENRP handle space database. Confidentiality is 727 mandatory to implement and is used when privacy is required. 729 4. IANA Considerations 731 This document introduces no additional considerations for IANA. 733 5. Normative References 735 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 736 Requirement Levels", BCP 14, RFC 2119, March 1997. 738 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 739 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 741 [I-D.ietf-rserpool-asap] 742 Stewart, R., Xie, Q., Stillman, M., and M. Tuexen, 743 "Aggregate Server Access Protocol (ASAP)", 744 draft-ietf-rserpool-asap-20 (work in progress), May 2008. 746 [I-D.ietf-rserpool-enrp] 747 Xie, Q., Stewart, R., Stillman, M., Tuexen, M., and A. 748 Silverton, "Endpoint Handlespace Redundancy Protocol 749 (ENRP)", draft-ietf-rserpool-enrp-20 (work in progress), 750 May 2008. 752 [I-D.ietf-rserpool-overview] 753 Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 754 Overview of Reliable Server Pooling Protocols", 755 draft-ietf-rserpool-overview-06 (work in progress), 756 May 2008. 758 Authors' Addresses 760 Maureen Stillman (editor) 761 Nokia 762 1167 Peachtree Court 763 Naperville, IL 60540 764 US 766 Email: maureen.stillman@nokia.com 768 Ram Gopal 769 Nokia Siemens Networks 770 12278 Scripps Summit Drive 771 San Diego, CA 92131 772 US 774 Email: ram.gopal@nsn.com 776 Erik Guttman 777 Sun Microsystems 778 Eichhoelzelstrasse 7 779 74915 Waibstadt 780 DE 782 Email: Erik.Guttman@sun.com 783 Matt Holdrege 784 Strix Systems 785 26610 Agoura Road 786 Suite 110 787 Calabasas, CA 91302 788 US 790 Email: matt@strixsystems.com 792 Senthil Sengodan 793 Nokia Siemans Networks 794 6000 Connection Drive 795 Irving, TX 75039 796 US 798 Email: Senthil.sengodan@nsn.com 800 Full Copyright Statement 802 Copyright (C) The IETF Trust (2008). 804 This document is subject to the rights, licenses and restrictions 805 contained in BCP 78, and except as set forth therein, the authors 806 retain all their rights. 808 This document and the information contained herein are provided on an 809 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 810 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 811 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 812 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 813 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 814 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 816 Intellectual Property 818 The IETF takes no position regarding the validity or scope of any 819 Intellectual Property Rights or other rights that might be claimed to 820 pertain to the implementation or use of the technology described in 821 this document or the extent to which any license under such rights 822 might or might not be available; nor does it represent that it has 823 made any independent effort to identify any such rights. Information 824 on the procedures with respect to rights in RFC documents can be 825 found in BCP 78 and BCP 79. 827 Copies of IPR disclosures made to the IETF Secretariat and any 828 assurances of licenses to be made available, or the result of an 829 attempt made to obtain a general license or permission for the use of 830 such proprietary rights by implementers or users of this 831 specification can be obtained from the IETF on-line IPR repository at 832 http://www.ietf.org/ipr. 834 The IETF invites any interested party to bring to its attention any 835 copyrights, patents or patent applications, or other proprietary 836 rights that may cover technology that may be required to implement 837 this standard. Please address the information to the IETF at 838 ietf-ipr@ietf.org.