idnits 2.17.1 draft-ietf-rserpool-threats-08.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. 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 (March 17, 2008) is 5877 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Rserarch' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC3365' is defined on line 492, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-rserpool-overview-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Maureen Stillman(editor) 2 INTERNET DRAFT Ram Gopal 3 Intended status:Informational Senthil Sengodan 4 Nokia 5 Erik Guttman 6 Sun Microsystems 7 Matt Holdrege 8 Strix Systems 9 17 September 2007 10 expires March 17, 2008 12 Threats Introduced by Rserpool and Requirements for Security 13 in response to Threats 14 16 Status of This Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on March 17, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). All Rights Reserved. 46 Abstract 48 Rserpool is an architecture and set of protocols for the management 49 and access to server pools supporting highly reliable applications 50 and for client access mechanisms to a server pool. This Internet 51 draft describes security threats to the Rserpool architecture and 52 presents requirements for security to thwart these threats. 54 Contents 56 Status of This Memo 1 57 Abstract 1 58 1. Introduction 3 59 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Threats 4 61 2.1 PE Registration/Deregistration flooding . . . . . . . . . 4 62 2.2 PE Registration/Deregistration flooding . . . . . . . . . 4 63 2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4 64 2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 65 2.5 Malicious ENRP server joins the group of legitimate ENRP 66 servers . . . . . . . . . . . . . . . . . 5 67 2.6 Registration/deregistration with malicious ENRP servers . 5 68 2.7 Malicious ENRP Handlespace Resolution . . . . . . . . . . 5 69 2.8 Malicious node performs a replay attack.. . . . . . . . . 6 70 2.9 Re-establishing PU-PE security during failover. . . . . . 6 71 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 73 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 74 2.13 Flood of endpoint unreachable messages . . . . . . . . . 7 75 2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 77 3.1 Database security . . . . . . . . . . . . . . . . . . . . 10 78 3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 80 5. Normative References . . . . . . . . . . . . . . . . . . . . . 11 81 6. Informative References. . . . . . . . . . . . . . . . . . . . . 11 82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 83 8. Intellectual Property Statement . . . . . . . . . . . . . . . . 12 84 9. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 RSERPOOL provides a session layer for robustness. The session layer 88 function may redirect communication transparently to upper layers. This 89 alters the direct one-to-one association between communicating endpoints 90 which typically exists between clients and servers. In particular, 91 secure operation of protocols often relies on assumptions at different 92 layers regarding the identity of the communicating party and the 93 continuity of the communication between endpoints. Further, the 94 operation of RSERPOOL itself has security implications and risks. The 95 session layer operates dynamically which imposes additional concerns for 96 the overall security of the end-to-end application. This document 97 explores the security implications of RSERPOOL, both due to its own 98 functions and due to its being interposed between applications and 99 transport interfaces. 101 1.1 Definitions 103 This document uses the following terms: 105 ENRP Endpoint Name Resolution Protocol (ENRP): 106 Within the operational scope of Rserpool, ENRP defines the 107 procedures and message formats of a distributed fault-tolerant 108 registry service for storing, bookkeeping, retrieving, and 109 distributing pool operation and membership information. 111 ASAP Aggregate Server Access Protocol: 112 A session layer protocol which uses ENRP to provide a high 113 availability handlespace. ASAP is responsible for the 114 abstraction of the underlying transport technologies, load 115 distribution management,fault management, as well as the 116 presentation to the upper layer (i.e., the ASAP user) a 117 unified primitive interface. 119 Operational scope: 120 The part of the network visible to pool users by a specific 121 instance of the reliable server pooling protocols. 123 Pool (or server pool): 124 A collection of servers providing the same application 125 functionality. 127 Pool handle: 128 A logical pointer to a pool. Each server pool will be 129 identifiable in the operational scope of the system by a 130 unique pool handle. 132 ENRP handlespace (or handlespace): 133 A cohesive structure of pool names and relations that may be 134 queried by an internal or external agent. 136 Pool element (PE): 137 A server entity that runs ASAP and has registered to a pool. 139 Pool user (PU): 140 A server pool user that runs ASAP. Note, a PU can also be a 141 PE if it has registered itself to a pool. 143 ENRP server: 144 Entity which runs ENRP and is responsible for managing and 145 maintaining the handlespace within the operation scope. 147 2. Threats 149 2.1 PE Registration/Deregistration flooding -- non-existent PE 151 Threat: A malicious node could send a stream of false 152 registrations/deregistrations on behalf of non-existent PEs to ENRP 153 servers at a very rapid rate and thereby create unnecessary state in an 154 ENRP server. 156 Effect: Corrupting the pool registrar database and/or disabling the 157 Rserpool discovery and database function. 159 Requirement: An ENRP server that receives a registration/deregistration 160 should not create or update state information until it has authenticated 161 the PE. 163 2.2 PE Registration/Deregistration flooding -- unauthorized PE 165 Threat: A malicious node or PE could send a stream of 166 registrations/deregistrations that are unauthorized to 167 register/deregister - to ENRP servers at a very rapid rate and thereby 168 create unnecessary state in an ENRP server. 170 Effect: Corrupting the pool registrar database and/or disabling the 171 Rserpool discovery and database function. 173 Requirement: An ENRP server that receives a registration/deregistration 174 should not create or update state information until the authorization of 175 the registering/de-registering entity is verified. 177 2.3 PE Registration/Deregistration spoofing 179 Threat: A malicious node could send false registrations/deregistrations 180 to ENRP servers concerning a legitimate PE thereby creating false state 181 information in the ENRP servers. 183 Effect: Misinformation in the ENRP server concerning a PE would get 184 propagated to other ENRP servers thereby corrupting the ENRP database. 186 Requirement: An ENRP server that receives a registration/deregistration 187 should not create or update state information until it has authenticated 188 the PE. 190 2.4 PE Registration/Deregistration unauthorized 192 Threat: A PE who is not authorized to join a pool could send 193 registrations/deregistrations to ENRP servers thereby creating false 194 state information in the ENRP servers. 196 Effect: Misinformation in the ENRP server concerning a PE would get 197 propagated to other ENRP servers thereby corrupting the ENRP database. 199 Requirement: An ENRP server that receives a registration/deregistration 200 should not create or update state information until it has authorized 201 the requesting entity. 203 2.5 Malicious ENRP server joins the group of legitimate ENRP servers 205 Threat: Malicious ENRP server joins the group of legitimate ENRP servers 206 with the intent of propagating inaccurate updates to corrupt the ENRP 207 database. 209 Effect: Inconsistent ENRP database state. 211 Requirement: Mutual authentication of ENRP servers. 213 2.6 Registration/deregistration with malicious ENRP server 215 Threat: A PE unknowingly registers/deregisters with malicious ENRP 216 server. 218 Effect: Registration might not be properly processed or ignored. 220 Requirement: PE needs to authenticate the ENRP server. 222 2.7 Malicious ENRP Handlespace Resolution 224 Threat: The ASAP protocol receives a handlespace resolution response 225 from an ENRP server, but the ENRP server is malicious and returns random 226 IP addresses or an inaccurate list in response to the pool handle. 228 Effect: PU application communicates with the wrong PE or is unable to 229 locate the PE since the response is incorrect in saying that a PE with 230 that handle did not exist. 232 Requirement: ASAP needs to authenticate the ENRP server. 234 2.8 Malicious node performs a replay attack 236 Threat: A malicious node could replay the entire message previously sent 237 by a legitimate entity. This could create false/unnecessary state in the 238 ENRP servers when the replay is for registration/de-registration or 239 update. 241 Effect: False/extra state is maintained by ENRP servers 243 Requirement: Care should be taken to prevent replay attacks. 245 2.9 Re-establishing PU-PE security during failover 247 Threat: PU fails over from PE A to PE B. In the case that the PU had a 248 trusted relationship with PE A, then the PU will likely not have the 249 same relationship established with PE B. 251 Effect: If there was a trust relationship involving security context 252 between PU and PE A, the equivalent trust relationship will not exist 253 between PU and PE B. This will violate security policy. 255 Requirement: Either notify the application when fail over occurs so the 256 application can take appropriate action to establish a trusted 257 relationship with PE B OR reestablish the security context 258 transparently. 260 2.10 Integrity 262 Threats: 263 a) ENRP response to pool handle resolution is corrupted during 264 transmission 265 b) ENRP peer messages are corrupted during transmission 266 c) PE sends update for values and that information is corrupted during 267 transmission 269 Effect: ASAP receives corrupt information for pool handle resolution 270 which the PU believes to be accurate. 272 Requirement: Integrity mechanism needed. 274 2.11 Data Confidentiality 276 Threat: An eavesdropper capable of snooping on fields within messages in 277 transit, may be able to garner information such as topology/location/IP 278 addresses etc. that may not be desirable to divulge. 280 Effect: Information that an administrator does not wish to divulge are 281 divulged. 283 Requirement: Provision for data confidentiality service. 285 2.12 ENRP Server Discovery 287 Threat A: Thwarting successful discovery: When a PE wishes to register 288 with an ENRP server, it needs to discover an ENRP server. An attacker 289 could thwart the successful discovery of ENRP server(s) thereby inducing 290 the PE to believe that no ENRP server is available. For instance, the 291 attacker could reduce the returned set of ENRP servers to null or a 292 small set of inactive ENRP servers. 294 Threat B: A similar thwarting scenario also applies when an ENRP server 295 or ASAP on behalf of a PU needs to discover ENRP servers. 297 Threat C: Spoofing successful discovery: An attacker could spoof the 298 discovery by claiming to be a legitimate ENRP server. When a PE wishes 299 to register, it finds the spoofed ENRP server. 301 Threat D: A similar spoofing scenario also applies when an ENRP server 302 or ASAP on behalf of a PU needs to discover ENRP servers. 304 Effect A: A PE that could have been in an application server pool does 305 not become part of a pool. The PE does not complete discovery operation. 306 This is a DOS attack. 308 Effect B: An ENRP server that could have been in an ENRP server pool 309 does not become part of a pool. A PU is unable to utilize services of 310 ENRP servers. 312 Effect C,D: This malicious ENRP would either misrepresent, ignore 313 or otherwise hide or distort information about the PE to subvert 314 RSERPOOL operation. 316 Requirement: Discovery phase needs to be authenticated. 318 2.13 Flood of endpoint unreachable messages from the PU to the ENRP 319 server 321 These messages are sent by ASAP to the ENRP server when it is unable to 322 contact a PE. There is the potential that a PU could flood the ENRP 323 server intentionally or unintentionally with these messages. 325 Effect: DOS attack on the ENRP server 327 Requirement: Need to limit the number of endpoint unreachable messages 328 sent to the ENRP server from the PU. 330 2.14 Flood of endpoint keep alive messages from the ENRP server to a PE 332 These messages would be sent in response to a flood of endpoint 333 unreachable messages from the PUs to the ENRP server. 335 Effect: Unintentional DOS attack on the PE 337 Requirement: ENRP must limit the frequency of keep alive messages to a 338 given PE to prevent overwhelming the PE. 340 3. Security Considerations for Rserpool 342 This informational document characterizes potential security threats 343 targeting the Rserpool architecture. The security mechanisms required 344 to mitigate these threats are summarized for each architectural 345 component. It will be noted which mechanisms are required and which are 346 optional. 348 From the threats described in this document, the security services 349 required for the Rserpool protocol are enumerated below. 351 Threat 2.1, 2.2, 2.3, 2.4) PE registration/deregistration flooding 352 and/or spoofing. 353 Security mechanism in response: ENRP server authenticates the PE 355 Threat 2.6) PE registers with a malicious ENRP server 356 Security mechanism in response: PE authenticates the ENRP server 358 These combined threats result in a requirement for mutual authentication 359 of the ENRP server and the PE. 361 Threat 2.5) Malicious ENRP server joins the ENRP server pool 362 Security mechanism in response: ENRP servers mutually authenticate 364 Threat 2.7, 2.12) A PU communicates with a malicious ENRP server for 365 handlespace resolution 366 Security mechanism in response: The PU authenticates the ENRP server. 367 If the authentication fails, it looks for another ENRP server. 369 Threat 2.8) Replay attack 370 Security mechanism in response: Security protocol which has protection 371 from replay attacks 373 Threat 2.9) Re-establishing PU-PE security during failover 374 Requirement: Either notify the application when fail over occurs so the 375 application can take appropriate action to establish a trusted 376 relationship with PE B OR reestablish the security context 377 transparently. 379 Threat 2.10) Corrupted data which causes a PU to have misinformation 380 concerning a pool handle resolution 381 Security mechanism in response: Security protocol which supports 382 integrity protection 384 Threat 2.11) Eavesdropper snooping on handlespace information 385 Security mechanism in response: Security protocol which supports data 386 confidentiality 388 To summarize the threats 2.1-2.12 require security mechanisms which 389 support authentication, integrity, data confidentiality and protection 390 from replay attacks. 392 For Rserpool we need to authenticate the following: 394 PU -----> ENRP Server (PU authenticates the ENRP server) 395 PE <----> ENRP Server (mutual authentication) 396 ENRP server <-----> ENRP Server (mutual authentication) 398 Summary by component: 400 Rserpool client -- mandatory to implement authentication of the ENRP 401 server is required for accurate pool handle resolution. This is to 402 protect against threats from rogue ENRP servers. In addition, 403 confidentiality, integrity and preventing replay attack are also 404 mandatory to implement to protect from eavesdropping and data corruption 405 or false data transmission. Confidentiality is mandatory to implement 406 and is used when privacy is required. 408 PE to ENRP communications -- mandatory to implement mutual 409 authentication, integrity and protection from replay attack is required 410 for PE to ENRP communications. This is to protect the integrity of the 411 ENRP handle space database. Confidentiality is mandatory to implement 412 and is used when privacy is required. 414 ENRP to ENRP communications -- mandatory to implement mutual 415 authentication, integrity and protection from replay attack is required 416 for ENRP to ENRP communications. This is to protect the integrity of 417 the ENRP handle space database. Confidentiality is mandatory to 418 implement and is used when privacy is required. 420 Threat 2.13) Flood of Endpoint_Unreachable messages from the PU to ENRP 421 server 422 Security mechanism in response: ASAP must control the number of endpoint 423 unreachable messages transmitted from the PU to the ENRP server. 425 Threat 2.14) Flood of Endpoint_KeepAlive messages to the PE from the 426 ENRP server 427 Security mechanism in response: ENRP server must control the number of 428 Endpoint_KeepAlive messages to the PE 429 3.1 Security of the ENRP Database 431 Another consideration involves the security characteristics of the 432 ENRP database. Suppose that some of the PEs register with an ENRP 433 server using security and some do not. In this case, when a client 434 requests handle space resolution information from ENRP, it would have to 435 be informed which entries are "secure" and which are not. This would 436 not only complicate the protocol, but actually bring into question the 437 security and integrity of such a database. What can be asserted about 438 the security of such a database is a very thorny question. Due to these 439 two facts it was decided that either the entire ENRP server database is 440 secure, that is, it has registrations exclusively from PEs 441 that have used security mechanisms or the entire database is insecure, 442 that is, registrations are from PEs that have used no security 443 mechanisms. ENRP servers that support security are required to reject 444 any PE server registration that does not use the security mechanisms. 445 Likewise, ENRP servers that support security should not accept updates 446 from other ENRP servers that do not use security mechanisms. 448 3.2 Cookie mechanism security 450 The application layer is out of scope for Rserpool. However, some 451 questions have been raised about the security of the cookie mechanism 452 which will be addressed. 454 Cookies are passed via the ASAP control channel. If TCP is selected 455 as the transport, the data and control channel must always be 456 multiplexed. Therefore, the cases: 458 a) control channel is secured; data channel is not 459 b) data channel is secured; control channel is not 461 are not allowed. It is even hard to understand what this really means 462 from a security point of view. 464 The multiplexing requirement results in the following cases: 466 1) the multiplexed control channel-data channel is secure OR 467 2) the multiplexed control channel-data channel is not secured 469 This applies to cookies in the sense that if you choose to secure your 470 control-data channel, then the cookies are secured. 472 A second issue is that the PE could choose to sign and/or encrypt the 473 cookie. In this case, it must share keys and other information with 474 other PEs. This application level state sharing is out of scope of 475 Rserpool. 477 4. IANA Considerations 479 This document introduces no additional considerations for IANA. 481 5. Normative References 483 [Rserarch] P. Lei, et. al., "An Overview of Reliable Server 484 Pooling Protocols", draft-ietf-rserpool-overview-02.txt, July, 2007, 485 work in progress. 487 6. Informative References 489 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 490 RFC 2026, October 1996. 492 [RFC3365] RFC 3365, Strong Security Requirements for IETF Standard 493 Protocols, August, 2002. 495 7. Acknowledgements 497 Thanks to the Rserpool security design team and others that provided 498 valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing 499 Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas, 500 Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj. 502 Funding for the RFC Editor function is currently provided by the 503 Internet Society. 505 7. Intellectual Property Statement 507 Full Copyright Statement 509 Copyright (C) The IETF Trust (2007). 511 This document is subject to the rights, licenses and restrictions 512 contained in BCP 78, and except as set forth therein, the authors 513 retain all their rights. 515 This document and the information contained herein are provided on 516 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 517 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 518 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 519 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 520 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 521 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 522 FOR A PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed 528 to pertain to the implementation or use of the technology 529 described in this document or the extent to which any license 530 under such rights might or might not be available; nor does it 531 represent that it has made any independent effort to identify any 532 such rights. Information on the procedures with respect to 533 rights in RFC documents can be found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use 538 of such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository 540 at http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention 543 any copyrights, patents or patent applications, or other 544 proprietary rights that may cover technology that may be required 545 to implement this standard. Please address the information to the 546 IETF at ietf-ipr@ietf.org. 548 8. Author's Addresses 550 Ram Gopal 551 Nokia Research Center 552 5 Wayside Road 553 Burlington, MA 01803 554 USA 555 email: ram.gopal@nokia.com 557 Erik Guttman 558 Sun Microsystems 559 Eichhoelzelstr. 7 560 74915 Waibstadt 561 Germany 562 Email: Erik.Guttman@sun.com 564 Matt Holdrege 565 Strix Systems 566 26610 Agoura Road, Suite 110 567 Calabasas, CA, 91302 568 matt@strixsystems.com 570 Senthil Sengodan 571 Nokia Research Center 572 5 Wayside Road 573 Burlington, MA 01803 574 USA 575 email: Senthil.sengodan@nokia.com 577 Maureen Stillman 578 Nokia 579 35 Woodcrest Ave. 580 Ithaca, NY 14850 581 USA 582 email: maureen.stillman@nokia.com