Re: NEW ISSUE: Securing EPRs

Marc,

I'm uneasy about putting this onto the issues list as stated, because  
it is potentially out of scope. We're chartered to provide a 'security  
model'; I have difficulty interpreting that to be so inclusive as to  
cover the 'contents of security artifacts.'

That isn't to say that we shouldn't give guidance on security in  
relation to EPRs, but, as stated, the issue you raise can be read to  
include the definition of an entire trust architecture, including the  
specification of concrete artefacts.

We can discuss this on Monday's call; in the meantime, if you'd like to  
re-state the issue to make it more limited in scope, please do so.

Thanks,



On Nov 24, 2004, at 7:19 AM, Marc Hadley wrote:

>
> Title: Securing EPRs
>
> Description: As has been mentioned in several threads, use of  
> addressing headers and reference props/params opens several avenues  
> for attack by malicious message senders. Message security is often  
> cited as a way to defeat such attacks, see e.g. "It's not a problem  
> for me because I'll only trust EPRs signed by certain parties"[1]. The  
> specification[2] states that "Whenever an address is specified (e.g.  
> <wsa:From>,  <wsa:ReplyTo>, <wsa:FaultTo>, ...), the processor should  
> ensure that a signature is provided with claims allowing it to speak  
> for the specified target in order to prevent certain classes of  
> attacks (e.g. redirects)." but doesn't really nail down what qualifies  
> a signature to "speak for the specified target"
>
> Justification: To have any hope of interoperability, the specification  
> needs to provide more exact guidance on the contents of security  
> artifacts that must be included in a message for a receiver to trust  
> the EPRs included in it.
>
> Target: SOAP binding
>
> Proposal: Add more exact language to the specification outlining the  
> message security requirements that must be met for an EPR to be  
> trusted. Add a standard fault that may be returned on receipt of a  
> message that fails to meet such security requirements.
>
> [1]  
> http://www.w3.org/mid/DD35CC66F54D8248B6E04232892B633804099D3E@RED- 
> MSG-43.redmond.corp.microsoft.com
> [2]  
> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- 
> soap.html
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Thursday, 25 November 2004 00:36:34 UTC