- From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
- Date: Tue, 9 Apr 2002 10:17:48 -0500
- To: Joseph Hui <jhui@digisle.net>, www-ws-arch@w3.org
Hi Joe,
Thanks for writing this up. This is a very useful first step
in understanding the scope of WS security. Overall reads very well.
Some comments:
1. I would use words "initiator" and "responder" instead of client and
server
in this context because, a WS client MAY be a WS server at another time.
"Initiator and responder" define roles taken by the WS at any given point in
time.
2. I would prefer discussion of threats to primarily the message layer and
above +
and add any implications of threats on layers below. Discussion of IP
threats
in general would make this model more comprehensive, though possibly not
manageable
from WSA perspective. Essentially, as you have defined the horizontal
boundaries,
define vertical boundaries too.
3. It may be worthwhile thinking about adding the "service invocation
context" within
the boundary of WS threat model. Adding the context would ensure threats to
compositions of WS
and resulting collaborations among WS are also within the model.
Best regards,
-Suresh
-----Original Message-----
From: Joseph Hui [mailto:jhui@digisle.net]
Sent: Friday, April 05, 2002 10:01 PM
To: www-ws-arch@w3.org
Subject: The Web Services Threat Model
Hi all,
From yesterday's teleconf I think it's safe to conclude by
now that the D-AG0006 goal statement is set.
So during the F2F next week, as far as D-AG0006 is concerned,
we'll most likely be only discussing the CSFs and the requirements.
In view that I've already set up the strawman CSFs, it's
the requirements area where we'll need infusion the most.
On that thought, I decided to whip up a threat model soon after
the teleconf ended, in hope it would help our next efforts in
spelling out the security requirements.
The following is what I've got so far. It's only a rough draft.
There're still sections to complete, and more importantly,
sources to pay tributes to.
Here it goes:
The Web Services Threat Model
1 Introduction
This document describes the Web Services Threat Model, which may
serve to derive the requirements for Web Services Security (WSSec).
Web Services (WS), being diverse applications running on
interconnected network hosts, are exposed to a plethora of computing
security hazards, which present themselves as threats to the well
being of the providers as well as consumers of such services. On
individual basis, a Web Service is conducted in a WS session comprising
a WS server (aka a Web Service endpoint), a WS client (aka a Web
Service consumer), and one or more WS channels (of communication).
Between a WS client and its WS server along a WS channel there may be
zero, one, or multiple WS intermediaries purposed for value added
services. They -- the WS server, client, and intermediaries -- are
generically referred to as WS nodes. The Web Services Threat Model
in this draft describes the possible threats to a WS node (of any
kind), a WS channel (of single or multiple hops), or a WS session.
Note that the model does not include threats that are physical in
nature, such as network cable disconnection, computer theft, facility
break-in, etc, i.e. even though physical hazards can also directly
affect the normal functioning of a Web Service.
2 Terminology
TBW
2.1 Key Word Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KWORD].
3 Threats to Web Services
Web Services, in the eye of the Web Services Threat Model being
described in this document, are conducted in sessions, where the
servers provide, the clients consume, and their intermediaries, if
any, relay transparently or non-transparently. (To relay
transparently is to tunnel, by [HTTP] convention. To replay non-
transparently implies payload transformation, which is a deviation
from the orthodox interpretation of the Internet end-to-end argument.
(Ref: [RFC1958],[RFC3238]))
Figure 1 depicts a basic configuration of a WS session involving a WS
server, a WS client, and a single-hop WS channel where
request/response (Q/R) messaging is the dominant traffic pattern. (A
WS channel comprising n hops spans over n + 1 WS nodes, where n >=
1.)
Figure 2 depicts a complex configuration of a WS session involving a
server, a client, multiple intermediaries, multiple channels, and
some call-out services. It is an elaborated outgrowth of the basic
configuration.
It MUST be understood that a threat applicable to the basic
configuration is also applicable to all complex configurations.
Accordingly, the security of Web Services is rooted at the security
of the basic configuration.
+-----------+
| WS Node A |
+-----------+
^
|
Q|
|R
|
v
+-----------+
| WS Node B |
+-----------+
KEYS:
Q -- Request (from client).
R -- Response (from server).
Figure 1: The WS Basic Configuration Conceptual Diagram
+------------------------------------------------+ +-------------+
| | 8 | Client-side |
| Client (C, the Source WS Node) |<----->| Callout |
| | | Service |
+------------------------------------------------+ +-------------+
^ | ^
| |Q 7|
| 2| |R''
| v |
| +----------------+ +----------------+ +------------+
| | Inbound | | Outbound | b |Out. Interm.|
| | Intermediary 1 | | Intermediary 1 |<--->| Callout |
| | (II1) | | (OI1) | | Service |
1| +----------------+ +----------------+ +------------+
| | ^
Q| |Q' 6|
|R 3| |R'
| v |
| +------------+ +----------------+ +----------------+
| | In. Interm.| a | Inbound | | Outbound |
| | Callout |<--->| Intermediary 2 | | Intermediary 2 |
| | Service | | (II2) | | (OI2) |
| +------------+ +----------------+ +----------------+
| | ^
| |Q'' 5|
| 4| |R
v v |
+------------------------------------------------+ +-------------+
| | 9 | Server-side |
| Server (S, the Destination WS Node) |<----->| Callout |
| | | Service |
+------------------------------------------------+ +-------------+
KEYS:
Q -- Original request/query from client.
Q' -- Result of transforming Q by Inbound Intermediary 1 (II1).
Q'' -- Result of transforming Q' by Inbound Intermediary 2 (II1).
R -- Original response from server.
R' -- Result of transforming R by Outbound Intermediary 2 (OI2).
R'' -- Result of transforming R' by Outbound Intermediary 1 (OI1).
Figure 2: A WS Complex Configuration Conceptual Diagram
3.1 Targeted Threads
An adversary may at any time attack a Web Service by targeting
a WS node itself, its communication, or both.
An attack may be active, passive, or some combinations of both.
It may be executed before, during, or after a WS session,
with or without detection.
3.1.1 Threats to a WS Node
A WS node, as a process running on a network host, is under the
adminstration (and thus at the mercy) of the host. Its secret
is not safe from any entity, human or otherwise, that possesses
adminstrative privileges that are equal to or higher than the
WS node does on the host in question.
3.1.1.1 Memory Capture
A WS node's run-time image may be captured by an attacker possessing
sufficient administrative privileges, in the form of memory snapshots
or core dumps.
3.1.1.2 Process Assassination
A WS node, as a running process on a host, may be involuntarily terminated
by an attacker possessing sufficient administrative privileges.
This is a very effective form of truncation attack, which abruptly
terminates the communication between affected WS nodes and
leaves them little clues for the cause of termination.
3.1.2 Threats to a WS Channel
A WS channel is for all practical purpose a public medium that any party
that wishes to tap into can tap into, thus every single byte traversing
the channel is a fairgame for snoopers.
3.1.2.1 Channel Eavesdropping
A passive attacker with marginal eavesdropping capability may snoop
a WS hop constantly and scoop up any data in transit, and at its
discretion exploit the data online or offline.
3.1.2.2 Channel Interference
An active attacker with marginal transmitting capability may inject
bogus data into a WS channel, thus confusing or damaging the
WS nodes at both ends or en route.
3.1.2.3 Connection Assassination
The overwhelming majority of WS traffics use TCP as their transport
protocol.
Unless a WS channel's transport layer is protected (e.g. by IPSec at
the network layer, one lower than transport in the OSI networking stack),
an attacker may send a spurious TCP RST packet to a WS node's end of
TCP connection, terminating the connection unexpectedly.
This is also a very effective form of truncation attack, which abruptly
terminates the communication between affected WS nodes and
leaves them little clues for the cause of termination.
3.1.2.4 Man-in-the-middle Attack
An attacker may insert itself between two WS nodes, say Alice and Bob, such
that it appears to Alice as Bob, and to Bob as Alice.
3.1.2.5 Session Hijacking
An attacker may hijack an established session between two WS nodes by
directing their traffic away from the intented recipient(s).
3.2 Integrity Threats
In the Web Services Threat Model, Integrity pertains to data only,
unless explicitly stated otherwise.
3.2.1 Data Integrity Threats
An attacker may intercept an (Alice-to-Bob) message from a WS channel,
modify it, and then place it back into the channel, resulting in Bob's
receiving an altered, and probably misinforming, message.
It is understood that over the Internet attackers can easily tamper
with data in transit, and the state-of-the-art recourses for
senders and receivers are limited to no more than
detecting (by means of checksum or message digest) whether the
received data has been altered.
3.2.2 ID Integrity Threats
ID Integrity threats at large fall in the category of ID authentication
threats. They are thus described in the Authentication Threats section.
3.3 Authentication Threats
This section describes the Authentication threats to Web Services.
3.3.1 Server (ID) Authentication
An attacker may impersonate a WS server and steals secret
(e.g. credit card numbers) from
unsuspecting WS clients who neglect to authenticate the identity
of the server they connect to.
3.3.2 Client (ID) Authentication
An attacker may impersonate a WS client and steals secret from
and/or gains unauthorized access to
an unsuspecting WS server who neglect to authenticate the identity
of the client requesting connection.
3.3.3 Intermediary (ID) Authentication
An attacker may impersonate a WS intermediary and steals secret
from and/or gains unauthorized access to
unsuspecting WS server/clients who neglect to authenticate the identity
of the intermediary in question.
3.3.4 Data Source Authentication
Data received by a WS node may come from a malicious source other
than a legitimate sender.
3.3.6 Replay Attack
An attacker may copy an (Alice-to-Bob) message (of monetary
donation) from a WS channel, and repeatedly send it to Bob,
thus grossly inflating the amount tallied.
3.4 Authorization Threats
This session describes known Authorization threats to Web Services.
3.4.1 Access Control
A WS server should control the access to its resources by WS clients.
An entity that has legitimately authenticated its true identity
to a WS server is not necessarily authorized to be a WS client
of the server. Even if it is authorized to be a WS client,
it is not necessarily authorized to access all resources
under the server's control at free will. Conversely, the
WS client should also control the access to its resources
by the WS server.
3.4.2 Username/Password
An attacker may impersonate an authorized WS client to gain
access to a WS server's resources, by snooping for Username/Passord
data in a WS channel. If the login data is in plaintext, then
the attacker scoop it up and use it readily. Even if the login
data is encrypted by a WS client, the attacker may still scooop
it up and replay it to the WS server to gain access.
3.5 Confidentiality Threats
This session describes known Confidentiality threats to Web Services.
3.5.1 Plaintext Data
Plaintext data in transit over a WS channel are fairgames to
eavesdroppers, who can tap into the Internet with minimal efforts.
3.5.2 Encrypted Data
Weakly encrypted data do not fair much better than their
plaintext cousin, in the face of universal availability of
high-performance computers.
3.5.3 (Imperfect) Forward Secrecy
It is common practice to encrypt bulk data using a symmetric (session)
key shared by two communicating WS nodes (say Alice and Bob), where
the session key is kept from prying eyes by means of public key
encryption, e.g. Bob encrypts the secret keying material M for
deriving the session key K with Alice's public key, resulting in
M' and sends M' to Alice over a TLS-secure WS channel. Upon
receipt, Alices decrypts M'
with her private key to recover M, which she uses to derive
K. An attacker, while incapable of determining K by cryptanalysis,
may excel in break-ins to obtain a copy of Alice's private key
in some future time, and use it to unravel
the intercepted trafic to recover M, which leads to K.
With K, the attacker can decrypt the data scooped off
the aforementioned TLS-secure WS channel.
The following are TBW. (I can't get to them until after the F2F.)
3.6 Accessibility Threats
3.6.1 DOS/DDOS Attacks
3.6.2 DNS Spoofing
3.6.3 ARP Spoofing
3.7 Accessibility Threats
3.7.1 DOS/DDOS Attacks
3.7.2 DNS Spoofing
3.7.3 ARP Spoofing
3.8 (Non-)Repudiation Threats
3.8.1 Repudiation of Document
3.8.2 Repudiation of Digital Signature Ownership
3.9 Misplaced Trust
3.9.1 Public Key Certificate Chain
3.9.2 Private Key Storage
...
Regards,
Joe Hui
Exodus, a Cable & Wireless service
Received on Tuesday, 9 April 2002 11:18:30 UTC