INTERNET DRAFT: Cliff X. Wang
IBM Corp.
S. Felix Wu
NCSU
Security Analysis to Server Cache Synchronization Protocol
<draft-wang-ion-sec-scsp-00.txt>
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: 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 <draft-wang-ion-sec-scsp-00.txt> Mar.13, 1998
Wang, Wu Expires Sep.13th, 1998 FORMFEED[Page 12]