RE: i004: Security Model

Marc,

The problem with your 'minimum required to declare victory' is that
'trust' is in the eye of the beholder. One party will have one set of
criteria for establishing trust, a different party will have different
criteria. I don't see how the WS-Addressing WG can or should try to
resolve this.

It's also not clear to me what you mean by 'define concrete security
mechanisms for SOAP in the SOAP binding.' This is NOT a security WG.
It's the WS-Addressing WG. Mechanisms for securing headers and bodies in
SOAP messages have been defined at OASIS as part of the WSS TC.

Gudge

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Marc Hadley
> Sent: 23 February 2005 01:04
> To: public-ws-addressing@w3.org
> Subject: i004: Security Model
> 
> 
> I have an action item to "identify parts of the specs that place  
> requirements on the security model". There are several aspects of  
> WS-Addressing that raise security concerns, most notably the ability  
> for a sender to arrange for a receiver to send replies or 
> faults to a  
> message to an arbitrary EPR and (when using the SOAP binding) to  
> include arbitrary canned SOAP headers in the resulting message. The  
> security considerations section of the SOAP binding[1] lists the  
> concerns in greater detail and proposes some generic counter 
> measures.  
> Gudge's proposal for resolving issue 4 [3] seems to cover 
> much of the  
> same ground as the existing text though in terser language and with  
> some additional concerns (e.g. the suggestion to not put sensitive
> information into wsa:Address values or Reference Parameters).
> 
> I previously tried to raise an issue[2] about the inadequacy of the  
> security considerations section which I agreed to defer until the  
> security model had been defined. Gudge's proposal for 
> resolving issue 4  
> doesn't cover the concern I raised about the nature of trusting EPRs:
> 
> Security Considerations text: "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). As  well, care should be taken if the  
> specified endpoint contains reference  parameters as unverified   
> endpoint references could cause certain classes of header insertion  
> attacks."
> 
> Gudge's proposal: "Users of EPRs SHOULD only use EPRs from 
> sources they  
> trust. In practice this is likely to mean that users of EPRs 
> only use  
> EPRs that are signed by parties the user of the EPR trusts."
> 
> I think that the minimum required to declare victory is for  
> WS-Addressing to concretely define what is meant by "claims 
> allowing it  
> to speak for the specified target" or "EPRs that are signed 
> by parties  
> the user of the EPR trusts". If we don't define this then use of  
> <ReplyTo> and <FaultTo> (except when using the anonymous 
> address URI)  
> will be restricted in publicly deployed systems since, 
> without such a  
> concrete definition, most endpoints simply won't allow their use  
> because of security concerns.
> 
> To repeat my original proposal[2]: 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.
> 
> In addition I'd propose that we move the generic parts of the 
> security  
> considerations section to a new section in the core and 
> define concrete  
> security mechanisms for SOAP in the SOAP binding.
> 
> Marc.
> 
> [1]  
> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr- 
> soap.html#_Toc77464334
> [2] http://www.w3.org/mid/44A0547C-3E2C-11D9-8A29-000A95BC8D92@Sun.COM
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
> 
>

Received on Wednesday, 23 February 2005 10:35:56 UTC