RE: Composibility problems with refps

Rich,

Okay, I am baffled now. If the EPR ref props/params are XML, how is it 
then that they are any different
than say a WS-RM Sequence header? Because there is a spec that says how 
Sequences are to be secured
where as for EPR ref props/params, there isn't? As I just responded to 
Dims, can you think of a case where you
would not sign a SOAP header you inserted, whether because it was an echo 
of an EPR ref prop/param or not?
I can't.

I would certainly agree that the WS-A spec should provide guidance as to 
what security measures should be
taken. To an extent, the current draft already does this, but that could 
be augmented. 

But, that is a completely different issue than the one that Dave is 
writing about. Maybe I am missing something, but
the vulnerability Dave was describing would not be mitigated by having the 
EPR signed by the minter or by having the
resultant SOAP headers derived from ref props/params signed by the holder 
of the EPR. My point was that any
service that had been compromised as he described is screwed anyway 
regardless of the fact that it could
insert some malicious ref prop/param.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



Rich Salz <rsalz@datapower.com> 
11/24/2004 07:09 PM

To
Christopher B Ferris/Waltham/IBM@IBMUS
cc
"public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Subject
RE: Composibility problems with refps






> What I don't understand is why you think that just because WS-A includes
> as part of its
> processing model the echoing of EPR props/params as SOAP headers that
> makes it somehow special with regards
> to the security model and its application to outbound messages.

Because it just is.  Honest, it really is.

Don't think of it as echoing, think of it as promotion.  No other
generic composible specification does this.  Every other spec makes
it clear, through standard use of XML, what it is.  Therefore it
is easy to express a security policy, implement it, and verify it.

Since addressing information is now put as header elements that
are indistinguishable from any other header elements, then you
cannot reliably secure them, you cannot express a policy that says
how they should be secured, and even if you could, the set of
headers to be affected not only varies per-message-type, but
per message instance.

IT makes it *much* harder to provide end-to-send security of message
headers.  Without close coupling and clumsy policy expression, it's
impossible.

        /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 Thursday, 25 November 2004 02:43:34 UTC