RE: Composibility problems with refps

 

> -----Original Message-----
> From: Rich Salz [mailto:rsalz@datapower.com] 
> Sent: 24 November 2004 18:14
> To: Christopher B Ferris
> Cc: Martin Gudgin; David Orchard; Francisco Curbera; 
> public-ws-addressing@w3.org
> Subject: Re: Composibility problems with refps
> 
> It's probably the case that you haven't seen my message yet, but with 
> all the spam filters around you never know.  And anyway, I like this 
> writeup better.
> 
> The risk is that an adversary inject an unsigned header. 

Won't any reasonable system reject unsigned headers? And isn't this a
general attack on SOAP, not on WS-Addressing?

>  Since you 
> cannot sign an entire SOAP Header, but only individual Header 
> elements, 
> you have to have a close coupling among at least two of the security 
> layer, the ws-addressing layer, and the application layer, in 
> order to 
> know what headers have been signed, and/or what headers must 
> be signed.

Won't a recipient of a message be expecting a given set of headers? And
won't it expect that those headers will have been integrity protected? I
agree that the security layer somehow needs to let the software that
processes a given header know that that particular header is 'OK to
process'.

> 
> A more subtle attack would be for the adversary to insert signed 
> headers, but signed by someone else.  

This attack is a general attack on SOAP, not specific to WS-Addressing,
right?

> If the recipient is 
> following the 
> standard Internet trust model of "must be a Verisign cert," 
> then it is 
> quite likely that this would escape detection.

That seems like a very loose policy, but I guess if that's my policy I
deserve all I get.


>  Even if the 
> recipient is 
> quite careful, however, it is difficult for current systems 
> to support 
> the concept of multiple signers; 

Do you mean multiple signatures over the same data? Or multiple
signatures over different data?

> throwing in the concept of "some 
> trusted, some not" is probably beyond the pale.  

I think I'd either reject any message containing a header signed by
someone I didn't trust or I'd strip that header at the security layer (
I'm sure there are also other approaches ).

> If not, it requires 
> further linkage between the layers, because now the application must 
> tell the security system who is authorized to sign what parts of a 
> message, or the security layer must pass back the signer 
> identity on a 
> per-element basis.

Ah, I see you mean different signatures for different data. Isn't the
principal used to generate the signature part of what makes a header 'OK
to process' or not? For example, if my endpoint is expecting headers A,
B and C, and it's expecting A to be signed by Alica and B to be signed
by Bob and C to be signed by either of them, then my security layer
checks those things and lets the header processing software know that
each header is OK. If A is signed by Bob, it won't be marked as OK. If
any header is unsigned, it won't be marked OK. If the headers are signed
by any party other than Alice or Bob they won't be marked as OK.

> 
> If you don't want to accept this kind of linkage then you 
> need to make 
> it obvious to all layers when something is an endpoint param or ref. 

I guess I don't understand this conclusion. Can you elaborate? Given we
have to solve the problem in general for SOAP headers anyway, it doesn't
seem like Ref Props/Params make life any more difficult.

> There are a couple of ways to do this:
> 	Put them inside the endpoint reference
> 	Put them in a wrapper
> 	Use actor/role to target them
> 
> Not only is self-description good, it seems here to be a security 
> requirement.

I guess I'm missing something, what security requirement is satisfied by
self-description? (and what does self-description mean in this context?)

Gudge

> 	/r$
> 
> -- 
> Rich Salz, Chief Security Architect
> DataPower Technology                           
> http://www.datapower.com
> XS40 XML Security Gateway   
> http://www.datapower.com/products/xs40.html
> XML Security Overview  
> http://www.datapower.com/xmldev/xmlsecurity.html
>

Received on Wednesday, 24 November 2004 20:18:48 UTC