Subject: (ION) SCSP security analysis draft

From: cliff wang <[email-masked]>
Date: Fri, 06 Mar 1998 18:31:55 -0500

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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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     <draft-wang-ion-sec-scsp-00.txt>         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: [email-masked]

   Felix Wu
   North Carolina State University
   Dept. of Computer Science
   P.O.Box 7550
   Raleigh, NC    27695
   phone: +1-919-515-7920
   email: [email-masked]

Wang, Wu                 Expires Sep.13th, 1998        FORMFEED[Page 11]

Internet Draft     <draft-wang-ion-sec-scsp-00.txt>         Mar.13, 1998

Wang, Wu                 Expires Sep.13th, 1998        FORMFEED[Page 12]

-- 

*************************************************
  Cliff Wang                                    
  IPSEC team,  Dept.MDZA/NHD               
  International Business Machines Corp.         
  800 Park Offices Drive, G418/B664             
  Research Triangle Park, NC 27709              
  Email: [email-masked]                
  Voice: (919)486-1255 (IBM T/L 526-1255)       
  Fax:   919-254-0391                           
*************************************************
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.