Re: Need for new Rec or TR on attaching policy to EPR

Wouldn't the EPR be signed in that case? Or have a local policy that 
says encryption is required.

I may have misunderstood the usecase, but isn't this risk present 
whenever a policy is exchanged (eg using ws-mex) regardless of whether 
it is embedded in the EPR.

Additionally, we already specify how WSDL can be embedded within the 
metadata section of the EPR. A WSDL can contain a policy. So one can 
currently include policy within an EPR right now, just not without a WSDL.

One example where this would be useful is an AcksTo EPR in the 
WS-ReliableMessaging specification. An RMS may include a policy related 
to initial expected ack interval/retransmission/timeouts in the AcksTo EPR.

-Anish
--

Richard Salz wrote:
>> Isn't this similar to the issue of what does a consumer do with 
>> wsa:Address value within an EPR when it already has a WSDL with the WSDL 
> 
>> port/endpoint information in it?
> 
> It's different because the client presumably *asked* for the EPR.
> 
> I am concerned about an EPR service being an obvious place to attack. 
> Right now, if I use XML encryption, for example, I don't have to worry 
> about DNS being compromised, because I can make sure that my message can 
> only be decrypted by its intended recipient.  Once an EPR can have policy 
> statements, an attacker might be able to send me an EPR with a security 
> policy that says "just sign it." If I trust that EPR -- or, more 
> accurately, if the all-singing and dancing runtime that I'm forced to use 
> trusts it -- then I have lost the ability to protect myself. This is a 
> real concern; a similar weakness is one of the main reasons why SSLv2 
> should not be used.
> 
> The idea that every policy-carrying EPR is a potential man-in-the-middle 
> attack is not one that occurs to many people.
> 
>         /r$
> 
> --
> STSM
> Senior Security Architect
> DataPower SOA Appliances
>

Received on Wednesday, 4 April 2007 18:01:50 UTC