RE: The Web Services Threat Model

There is a ebXML Security Risk Assessment Technical 
Note that discusses threats in a comprehensive manner.

See:

http://www.ebxml.org/specs/secRISK.pdf


Also, we should identify web services threats w.r.t. 
the diversified set of web services use cases, including 
for B2B.


thanks,
Zahid



-----Original Message-----
From: Joseph Hui [mailto:jhui@digisle.net]
Sent: Thursday, April 18, 2002 2:54 PM
To: Krishna Sankar; www-ws-arch@w3.org
Subject: RE: The Web Services Threat Model


Hi Krishna,

Thanks for the feedback from Ricky.
My comments are inlined below.

> From: Krishna Sankar [mailto:ksankar@cisco.com]
[snip]
> I had solicited internal comments on our discussions thru internal
> mailer. Here is one from Ricky Ho on threat model.
[snip]
>  | In the threat model described in the mail, it hasn't highlight those 
>  | threats which a "transport-layer" protocol like SSL doesn't solve. 

SSL is a solution.  (It provides end-point Authentication,
data Integrity, and Confidentiality.)  The threat model
is meant to focus on the  problems, i.e. the threats, and
is intentionally aversive to critiquing solutions.
E.g. I could have pointed out that SSL/TLS doesn't do
non-repudiation.  But I'd have also to show IPSec's laundry
list, just to be fair.  Incidentally, I happen to know
SSL/TLS quite well, from its nuts and bolts to where the
bodies are buried, including what SSL/TLS can or cannot do.
So if there's suggestion about the exact locations in the 
draft where the shortcomings of SSL (and/or IPSec) should be
brought to the readers' attention, then let's see what can
be done.  

>  | (so far 
>  | it hasn't justified the need to address those threats at the web
service 
>  | level).

IMO one should stay neutral while describing a threat model,
i.e.  present the threats matter-of-factly and refrain from
justifying one way or the other.  The readers can justify for
themselves how threads are to be addressed.  If we were to do it
for them, we should do it in a separate draft.

>  | The threat model hasn't talked about the "time" dimension which is 
>  | important in the dynamic nature of web services.  (E.g. certain
information 
>  | is valid within certain time period, or the authority is designated
within 
>  | a certain period).  And one of the threat is how the hackers extend
that 
>  | time period.

I'm quite puzzled by this "time" dimension.
I can take this as-is and make several guesses and address
each of them.  But I'd rather wait for a concrete example on how
a timeframe can be extended and the WS-specific ramification
before responding to this meaningfully.  

The notion that certain info is of ephemeral value may argue
for the non-need for Perfect Forward Secrecy (PFS) in some cases.
(PFS is widely known and accepted as a desirable property in security.)
But it can't be used to argue for getting by with weaker/cheaper
ciphers (in the case of ephemeral confidentiality) or for
controlling an authz window (in the case of authz time, such
as stretching the expiration limit of a Kerberos ticket.
So what am I missing?

Exactly how would a hacker extend "that time period" (and take
advantage the extension), given that in security, unless stated
otherwise, one assumes confidentiality is desired to last "forever?"
(Recall PFS being a desirable property in security.)

>  | The coverage of the underlying communication model (which 
> the threat
> model 
>  | base on) is kind of "incomplete".  Besides the most basic
> communication 
>  | pattern, the following are important ones that are missing.
>  | 
>  | 1) Dynamic "route"
>  | In this case, the client cannot determine the whole route before it
> sends 
>  | its request, and it delegates some of the decisions to subsequent 
>  | intermediaries.  So the threat model should look at the trust issue
> under 
>  | the delegation scenario.
>  | 
>  | 2) Conversation
>  | In real life B2B scenario, the communication is not a one-off
> invocation 
>  | but rather "dialog based".  There are multiple web services
> invocations 
>  | which are correlated under a certain context.  So the threat model
> should 
>  | look at the whole context rather than just individual invocation.
>  | 
>  | 3) Asynchronous service invocation
>  | The characteristic is that there is no "output" from any service
> because 
>  | the response will come back from a separate reverse 
> invocation.  This
> can 
>  | be considered a special case of conversation.
>  | 
>  | 4) Multicast invocation
>  | In this case, the sender doesn't know who is the ultimate receiver
> (or is 
>  | there any of them).

The coverage may indeed be incomplete.  (I was just firing away
with what comes to mind and then re-organize the contents a bit
for readability.)
There are an infinite number of other things that the threat model
(in a finite form) can't possibly cover.  That said, I suspect many
of the cases that some see as not being covered may actually be some
variants of the exemplary cases being covered.  

If references can be provided for research-grade security papers 
or dissertations on the above four, I'll be glad to check them out.
(Sorry, a broad pointer like "msec for Multicast" won't help. ;-)

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
======================================================


>  | 
>  | Best regards,
>  | Ricky
>  | 
>  | At 07:57 AM 4/6/2002 -0800, Krishna Sankar wrote:
>  | >Good first cut in articulating the threat model for web services.
>  | >Comments are welcome.
>  | >
>  | >cheers
>  | >
>  | >  | -----Original Message-----
>  | >  | From: www-ws-arch-request@w3.org
>  | >  | [mailto:www-ws-arch-request@w3.org] On Behalf Of Joseph Hui
>  | >  | Sent: Friday, April 05, 2002 8:01 PM
>  | >  | To: www-ws-arch@w3.org
>  | >  | Subject: The Web Services Threat Model
>  | >  |
> <snip ../>
> 
>