Re: i004: Security Model

On Feb 23, 2005, at 11:55 AM, Martin Gudgin wrote:
>> 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".
>
> OK, you keep using the phrase 'minimum set of criteria' and I have no
> idea what that means. Can you give me a concrete example of such
> criteria?
>
An example (not a proposal): an EPR should be signed using an X509 
certificate issued by a recognized certificate authority (some 
configurability here of course - recognized by who...) for the domain 
to which the EPR [address] refers.

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

Received on Wednesday, 23 February 2005 17:55:53 UTC