Re: i004: Security Model

On Feb 23, 2005, at 5:35 AM, Martin Gudgin wrote:
>
> 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.
>
Its going to be difficult to achieve any kind of interoperability 
without some specification of a minimum set of criteria. I'd prefer 
that this group tackle this rather than requiring a follow-on WG in 
WS-I to complete our work.

> 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.
>
Sorry if I wasn't clear, I didn't mean to imply that we should define 
an alternative to OASIS WSS. Rather I think we should describe the use 
of WSS as an expression of a minimum set of criteria for "claims 
allowing it to speak for the specified target" or "EPRs that are signed 
by parties the user of the EPR trusts".

Marc.

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

Received on Wednesday, 23 February 2005 16:20:50 UTC