RE: i004: Security Model

 

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 23 February 2005 16:06
> To: Martin Gudgin
> Cc: public-ws-addressing@w3.org
> Subject: 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 think this has yet to be proven true... 

When I use websites via my browser, when I'm doing SSL/TLS type stuff,
my browser checks that the server certificates are 'valid' per some
criteria I (or more accurately my company) have specified. When I
receive EPRs, one possible approach to detemining whether I trust them
is that I expect them to have been signed by the key associated with
some server cert which is 'valid' per the same criteria as my browser
uses.

In both cases, if the server cert. doesn't match my criteria I won't
talk to the server, but I'm not sure that's an interoperability issue...

> I'd prefer 
> that this group tackle this rather than requiring a follow-on WG in 
> WS-I to complete our work.

I should have been clearer. I don't think that ANY WG should be trying
to boil this ocean...

> 
> > 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".

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? 

Gudge

> 
> 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:55:44 UTC