INTERNET DRAFT: Cliff X. Wang IBM Corp. S. Felix Wu NCSU Security Analysis to Server Cache Synchronization Protocol Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Distribution of this document is unlimited. Abstract Server Cache Synchronization Protocol SCSP [1], [2], [3], [4] is used to solve the generalized cache synchronization/cache -replication problem for distributed protocol entities. In a client-server paradigm, SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group. This document provided a security analysis of the current SCSP framework and identified potential threats to the protocol operation. Possible solutions to secure the SCSP from potential attacks are presented and discussed. Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 1] Internet Draft Mar.13, 1998 It is intended in this document to provide analysis and solution to the protocol independent part of SCSP. Security considerations with respect to SCSP application of a specific protocol is beyond the scope of this draft. 1. Introduction SCSP contains three sub protocols: the "Hello" protocol, the "Cache Alignment" Protocol and the "Cache State Update" protocol. The Hello protocol is used to monitor the status of the connections between the Local Server (LS) and its Directly Connected Servers (DCS) (i.e., neighbors). The "Cache Alignment" protocol is used to synchronize the cache of an initializing LS with the cache of its DCSs. The "Cache State Update" protocol is used to update the state of cache entries once the servers are synchronized. Synchronization is performed on a per Server Group/Protocol basis. That is, a separate instance of the protocol is run for each Server Group. Therefore, the SGID/PID pair uniquely identifies an instance of SCSP. A server group contains one LS and one or multiple DCS associated with this LS. Note that in this draft, LS and DCS are sometimes referred as SCSP entities. A separate instance of the "Hello" and "Cache Alignment" protocol are maintained for each DCS of the Server Group (except for the scenario of aggregating Protocol ID/SGID pairs). State machines exist to execute the protocol independently for each DCS session. For more information, refer to [1]. For a given server group, SCSP entities, including LS and DCSs, are distributed on different end hosts or routers. Three types of SCSP messages [1] are used in the SCSP protocol. "Hello" messages are used to check whether a DCS is operational and whether the connections between the LS and the DCS are bi- directional, unidirectional, or non-functional. "Hello" message is periodically sent from LS to its DCSs. "Cache Alignment" (CA) messages are used by an LS to synchronize its cache with that of the cache of each of its DCS. A CA message contains a CA header followed by zero or more Cache State Advertisement Summary records (CSAS records). "Cache State Update" (CSU) messages are used to dynamically update the state of cache entries in servers on a given PID/SGID basis. CSU messages contain zero or more "Cache State Advertisement" (CSA) record each of which contains the state of a particular cache entry. These SCSP messages are exchanged between LS and its associated DCSs. Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 2] Internet Draft Mar.13, 1998 This implies the possibility of potential attacks directly on the SCSP protocol operations. It is the purpose of this draft to identify these potential security threats and provide solutions to secure the operations of SCSP. The scope of this draft is limited to the protocol independent part of SCSP. However, additional protocol dependent security analysis may also need to be carried out when SCSP is applied to a specific client-server protocol. The analysis and solution to the security threats related to SCSP's application to a specific protocol is beyond the scope of this document. 2. Security Analysis of SCSP SCSP is used to provide cache synchronization/cache-replication for distributed servers. Since servers are usually the crucial part of some protocol operations, they are usually the targets for attack. It is important to secure servers from potential attacks. This section attempts to identify the potential security threats associated with running SCSP to synchronize the distributed servers. It is presented in such a way that the analysis is independent of the protocols associated with the server synchronization. Security analysis with respect to specific protocols may be studied further. Security threats for SCSP can be classified into two types: insider attack and outsider attack. An insider attack refer to the event that the attacker has means to break into one or more SCSP entities (either an LS or a DCS) and to compromise these SCSP entities. On the other hand, an outsider attacker can only eavesdrop or intercept SCSP protocol messages on a link. In the following sections, discussions are presented on what types of attacks are possible on the SCSP operation, either as an insider attacker or as an outside attacker. Enhancement to the SCSP protocol to deal with these attacks is also suggested in Section 3. 2.1 Outsider Threats for SCSP An outsider attacker has access only to the links between SCSP entities. The security threats concentrate mostly on SCSP messages exchanged between SCSP entities. Type 1 - Unauthorized access threat Access control refers to the process of identifying legitimate access request and enable information exchange between local and authorized remote entities. For each SCSP entity, two types of message exchange are involved: the first type is the protocol specific message exchanges between the SCSP entity (server) and its clients. The second type is the SCSP message exchange between SCSP entities (distributed servers). The protocol message exchange between client Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 3] Internet Draft Mar.13, 1998 and server is usually defined in the specific protocol involved and is actually outside the scope of SCSP. Security analysis for those message are not addressed here. This document only discuss access control related to SCSP message exchange. Unauthorized access threat refers to the action that un-authorized entity can send fake or illegitimate messages to SCSP entities in order to disturb the normal operation or to inject false information to overwrite the server database. For example, an attacker can send a spoofed CSU request to participating servers in a server group to update their server cache. This spoofed CSU request can overwrite current valid server entry with an invalid entry. This can achieve the effect that the protocol being synchronized may start function incorrectly. For example, when SCSP is used to synchronize Classic IP server, a modified ATMARP cache entry may lead to failure of new SVC setup to a particular IP host. In the case that the affected IP host is a gateway, further IP routing function will be affected. Another types of illegal access is that an illegitimate entity sends a request to a server for information it is not authorized to acquire. Without server access control, an attacker can retrieve information from server and uses the acquired information to plan for additional attacks. Generally the server database should has restrictive access privilege and only authenticated messages are allowed to be passed for processing. SCSP message authentication can eliminate such attacks from un- authorized outside attackers. Spoofed messages originating from untrusted or unauthorized entities will fail authentication check, thus eliminate unauthorized access to SCSP servers. Furthermore, it is also suggested that unsuccessful access attempts should be logged for further detection of intrusions. In the current SCSP framework, SCSP messages between servers have an authentication extension, which will be discussed in detail in Section 3.1. Type 2 - Modification of information threat Modification of information attack refers to the act that legitimate messages are altered by the attacker when message authentication is absent. The intruder may alter in-transit legitimate SCSP messages generated by an authorized entity in such way that normal operation of servers synchronization is jeopardized. The "Hello", "Cache Alignment", and "Cache State Update" messages have 3 parts in every packet: the fixed part, the mandatory part, and the extension part. Modification of any field in any part is prohibited for the normal operation of SCSP operation. Any message modification may affect the Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 4] Internet Draft Mar.13, 1998 state of the HFSM or that of CAFSM, or the server cache entry, resulting in various consequences of different severity levels, from server group synchronization performance degradation, cache entry mis-alignment, to total server group shutdown due to HFSM shutdown caused by error messages. One example would be that the attacker can modify the Protocol ID or the Server Group ID field and these modifies messages will be flushed by the receiving server. If messages are being flushed continuously at the receiving server, the CAFSM or the HFSM may time out, leading to the loss of server synchronization. Of course, modification of any other field will cause similar problems for normal operation. Modification of information threat is very similar to access control threat such that SCSP servers process fake or modified illegitimate messages. Thus applying SCSP message authentication will be able to keep the integrity of SCSP messages and protect SCSP servers from such information modification threat. Un-authenticated or authentication failed messages will be flushed by the server and only those authenticated messages are processed. Type 3 - Message sequencing threat The message sequencing threat is the danger that messages may be arbitrarily re-sequenced, delayed or replayed back such that normal operations of the SCSP entities are japordized. SCSP uses sequence number in its information exchange. Message sequencing threat is both realistic and significant. For example, during the "Cache summarize" process, a play back attack can destroy the correct operation of the Cache Alignment State Machine and set the finite state machine to an incorrect "Master/Slave" state. Specifically, when the LS is slave during the "Cache summarize" process and received a played back CA message from the attacker which has an earlier CA sequence number, the Local Server will be fooled to think that an error has occurred and switch its state to "Master/Slave" state erroneously, interrupting its normal server function for its clients. This type of threat can be avoided by combining both authentication and some kind of timestamp or challenge-response í5ù. Message authentication guarantees that the messages have not been altered and timestamp or challenge-response can be used to detect playbacked messages. Type 4 - Disclosure of information threat The disclosure threat is the danger that SCSP message is obtained and disclosed to the unintended party. When the SCSP server lacks access control, any un-authorized party can contact and retrieve information Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 5] Internet Draft Mar.13, 1998 from the unrestricted SCSP entities. Or the attacker can eavesdrop on the links to steal the information exchanged among SCSP entities. The attacker can use the stolen information to plan further attack, eg., attacks on other servers in the server group. To handle this concern, server access control and SCSP messages encryption are needed. After encryption, the whole cipher message usually needs to be authenticated. Otherwise, without authentication, cut-and-paste attack is possible. Type 5 - Denial of service threat Denial of service threat usually refers to the type of attack that stops or slows the normal operation of SCSP entities by diverting or depleting resources, or by exploiting certain implementation shortfall (weakness). One particular scenario of denial of service threat is that without access control, an attacker can simply flood the SCSP server with illegitimate SCSP messages. Queuing and processing of these illegal messages may saturate the resources (message buffer, CPU cycle, etc) of SCSP entities, and legitimate users may be deprived of gaining normal server operation because of resource exhaustion. Other types of possible attacks at different level are possible. For example, the intruder can repeatedly placing/disconnecting SVCs to the SCSP entities if the ATM is the media used. This may result SCSP entities lose part or all of its normal operation capacity. However, since the current context concentrates on security threats on SCSP protocol operation and SCSP entities only, discussion on the ATM level security is outside the scope of this draft. Denial of service attacks are hard to prevent. Access control and message authentication may drop illegal flooding messages at an early processing time, but can not fully protect server from attack until the message flooding origination is detected and stopped. The best protection will reply on a sophisticated network infrastructure intrusion detection system (e.g., [6]) to identify and stop the attacks. 2.2 Insider Attack Threats for SCSP When an intruder has compromised a SCSP entity, such as the LS, it can attack any other servers in the same Server Group. All 5 types of outsider threats discussed in the previous sections can be exercised by an insider. The worse part is that symmetric cryptographic protocols is no longer effective in stopping these attacks. When the attacker has full control of a SCSP entity, the compromised server's Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 6] Internet Draft Mar.13, 1998 behavior may seem just as normal to other members, if the intruder tries to mimic the regular SCSP operation. Since the intruder is trusted as a legitimate member in the group, it can legally access to any resources in the Server Group. It is obvious that the Server Group can easily be brought down even with implementation of strong SCSP entity to entity authentication. One such example would be (to be added) One important objective in dealing with insider attacks is to have the protocol robust enough such that the damages caused by a trusted but compromised SCSP entity (insider attack) can be contained or limited. Otherwise, the protocol is vulnerable to such insider attack if insider attack's impact cannot be contained and has a global bad impact on every other SCSP entities. The router black-hole attack is one famous example of uncontained insider attack such that a vicious router can cheat/trick directly or indirectly all the routers to forward all their packets to this vicious node. Please refer to [7] for more information about insider attacks on routing protocols. 3. Security Measures for SCSP This section presents security measures to protect normal SCSP operation from security intrusions. 3.1 Server Access Control SCSP server access control refers to the process of identifying legitimate access request and enable information exchange between local and authorized remote entities. Message exchange can happen between SCSP entities (servers) and between protocol client and server. This draft only limit to itself to SCSP message exchange. The protocol client-server message is outside the scope of this draft. For SCSP server access control, SCSP message authentication is suggested and it will be discussed in the next section. Message authentication guarantees that only legitimate remote SCSP entity can exchange information with the local entity. Authentication failed messages are flushed to protect the server from illegal access. 3.2 SCSP Message Authentication As pointed out in Section 2.1, message authentication can provide access control and is very important in detecting and preventing message modification attack, and message sequencing attack when combined with timestamp. Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 7] Internet Draft Mar.13, 1998 When authentication is used in SCSP messages, forged or modifies SCSP messages fail authentication check and are not be honored. Only those authenticated messages are processed. By flushing unauthorized messages to servers which failed authentication, access control can be maintained. In current SCSP message definition, two types of authentication methods can be used: clear-text password and HMAC-MD5-128 [8]. It is obvious that cleartext password does not off much protection against serious intruders. On the other hand, the HMAC-MD5-128 authentication mechanism between an LS and its DCSs provides a much stronger means of protection for SCSP. The purpose of this authentication is to verify that the the received messages are actually coming from a trusted legitimate SCSP entity, rather than from an attacker. Furthermore, it is suggested that some kind of timestamp field be incorporated into each SCSP message to protect from message replay attack discussed in Section 2.1. In IPSEC document [9], a 32-bit timestamp field is allocated to guarantee that each packet exchanged between two parties is different. This 32-bit field is included in the calculation of the authentication data. With the timestamp contained in each SCSP message, replayed SCSP messages can be easily detected and flushed. Obviously, the use of authentication in SCSP messages increases the processing overhead. However, since SCSP messages are used infrequently to update server cache, authenticating SCSP messages does not increase overall processing load much. Direct impact on end-system performance is much less than authenticating data packets. 3.3 Secure Checksum enhancement Currently, SCSP uses a simple standard IP checksum over the entire SCSP packet. It has been pointed out that this type of checksum mechanism used in OSPF may become a security weakness. The MaxAgeDiff (Max Age Difference) attack in OSPFv2 is impossible if the checksum were either MD5 or SHA. Since OSPF [14] and SCSP are similar in operation, MD5 and SHA are suggested to offer a stronger secure checksum mechanism. 4. Open Issues of SCSP Security This section dealts with some of the open issues that related to SCSP security, and also some possible security options that can be adopted and implemented. Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 8] Internet Draft Mar.13, 1998 4.1 Protocol specific security concerns The previous sections primarily focus on analyzing SCSP security issues independent of any actual protocol the client-server is running. Also current security measures a very basic security service for all the SCSP applications to various client-server protocols. However, SCSP has been designed to apply to different applications, which might have their specific security requirements and is outside the scope of this draft. 4.2 Possible adoption of IPSEC working group framework The IETF security working group has proposed a set of network security standards to offer a variety of security services. These services include authentication [8], [9], [11], encapsulation payload [12], and automatic key management [10]. It is suggested that SCSP can re-use as much work as possible from the effort of IETF IPSEC working group. For example, the importance of payload encryption maybe depend on data sensitivity of a particular protocol being synchronized by SCSP. If there is a need for encryption, IETF IPSEC ESP protocol can be adopted. 4.3 SCSP Digital Signature with Public Key Protocols As discussed in Section 3.2, the HMAC MD5 authentication provide a strong authentication for SCSP messages to guard against outsider attack. However, when a SCSP entity is compromised, link to link authentication such as the HMAC MD5 authentication can't prevent these insider attacks. When a SCSP entity is compromised, the attacker can potentially damage the SCSP infrastructure. This insider problem has been identified in the OSPF community [7]. LSA (Link State Advertisement) Digital Signature [14] has been proposed and implemented to prevent such insider attacks. It is suggested that SCSP adopt the same approach as OSPF by using digital signature to sign the origination cache record. The digital signature can be implemented as follows, *SCSP_message, Sign(Originator's Private Key, MD5(SCSP_message)) The details of using digital signature is beyond the scope of this draft. Refer to RFC 2154 for the detailed scheme of using digital signature for OSPFv2. Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 9] Internet Draft Mar.13, 1998 4.4 Key Management and Security Association Establishment SCSP supports both manual and key management protocol for distribution of secret keys. Manual key management is of limited practical use, as it has a severe limitation of scalability. Many automatic key management protocols have been proposed, for example, ISAKMP/Oakley [10]. SCSP drafts suggest that any Internet standard key management protocol MAY be used to negotiate the SPI and parameters. Further study (which is outside of the scope of this draft) is needed to investigate how to use these standard key management protocol in SCSP (instead of re-inventing a new key management protocol). 5. Conclusion SCSP can be used to solve the generalized cache synchronization/cache replication problem for distributed protocol entities. In a client/server paradigm, SCSP synchronizes caches (or a portion of the caches) of a set of server entities of a particular protocol which are bound to a Server Group. This draft presents a security analysis of running SCSP protocol. Both insider and outsider attack cases are studied. Possible solution to these security threats are presented and suggested. When SCSP is applied a specific protocol, additional protocol dependent security analysis may be needed. Acknowledgments Reference [1] "Server Cache Synchronization Protocol (SCSP)", J. Luciani, G. Armitage, and J. Halpern, draft-ietf-ion-scsp-04.txt. [2] "A Distributed NHRP Service Using SCSP", J. Luciani, draft-ietf-ion-scsp-nhrp-05.txt. [3] "A Distributed ATMARP Service Using SCSP", J. Luciani draft-ietf-ion-scsp-atmarp-00.txt. [4] "A Distributed MARS Service Using SCSP", J. Luciani, A. Gallo, draft-ietf-ion-scsp-mars-01.txt [5] "Freshness Assurance of Authentication Protocols", Kwok-Yan Lam, Dieter Gollmann, ESORICS 92, November, 1992, pages 261-271 [6] "Architecture Design of a Scalable Intrusion Detection System for the Emerging Network Infrastructure", F. Jou, F. Gong, C. Sargor S. F. Wu, R. Cleaveland, MCNC Technical Report, April, 1997. Available under Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 10] Internet Draft Mar.13, 1998 http://www.mcnc.org/HTML/ITD/ANR/JiNao.html. [7] "An Experimental Study of Insider Attacks for the OSPF Routing Protocol", B. Vetter, F. Wang, S.F. Wu, IEEE International Conference on Network Protocols (ICNP), October 1997, pages 293-300. [8] "HMAC: Keyed-Hashing for Message Authentication", Krawczyk, H., Bellare, M., and R. Canetti, RFC 2104 [9] "HMAC-MD5-96 IP Authentication with Replay Prevention", M. Oehler, R. Glenn, RFC 2085 [10] "Internet Security Association and Key Management Protocol (ISAKMP)" Douglas Maughan, Mark Schertler, Mark Schneider, Jeff Turner, draft-ietf-ipsec-isakmp-08.txt, [11] "IP Authentication Header", Stephen Kent, Randall Atkinson, draft-ietf-ipsec-auth-header-04.txt [12] "IP Encapsulating Security Payload (ESP)", Stephen Kent, Randall Atkinson, draft-ietf-ipsec-esp-v2-03.txt [13] "OSPF Version 2", J. Moy, RFC 2178 [14] "OSPF with Digital Signatures", S. Murphy, M. Badger, B. Wellington RFC 2154 Authors' Addresses Cliff X. Wang IBM, Networking Hardware Division Dept. 0L4A/B664 P.O. Box 12195 Research Triangle Park, NC 27709 phone: +1-919-486-1255 email: cliff_wang@vnet.ibm.com Felix Wu North Carolina State University Dept. of Computer Science P.O.Box 7550 Raleigh, NC 27695 phone: +1-919-515-7920 email: wu@csc.ncsu.edu Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 11] Internet Draft Mar.13, 1998 Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 12]