RE: The Web Services Threat Model

Please feel free to contribute the use case anytime.
 
Thanks,
 
Joe Hui
Exodus, a Cable & Wireless service
===============================

-----Original Message-----
From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
Sent: Thursday, April 18, 2002 5:40 PM
To: www-ws-arch@w3.org
Subject: 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 ../> 
> 
>