Re: NEW ISSUE: Securing EPRs

On Nov 24, 2004, at 7:36 PM, Mark Nottingham wrote:
>
> 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.
>
I don't think we need to specify a whole trust architecture. We do need  
to specify some minimum set of interoperable requirements such that  
somebody reading our spec can construct a message that is likely to  
work as intended (not guaranteed, but likely). If we don't tackle this  
problem then we risk having to wait for another organization such as  
WS-I to produce a useable specification.

Marc.

> 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
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Friday, 26 November 2004 19:58:28 UTC