RE: SOAP Confidentiality and Integrity: What do we have now?

I think this is a digression from what Blake was asking for.
So I'll be minimal in my response.

> From: Pete Wenzel [mailto:pete@seebeyond.com]
> Sent: Friday, June 21, 2002 4:17 PM
> To: Joseph Hui
> Cc: Dournaee, Blake; Krishna Sankar; www-ws-arch@w3.org;
> xml-encryption@w3.org; www-xkms@w3.org; reagle@w3.org
> Subject: Re: SOAP Confidentiality and Integrity: What do we have now?
> 
> At the risk of stating the obvious, message-based and channel-based
> security mechanisms often have very different purposes, and cannot be
> substituted for each other, depending on what the real requirements
> and threat models are.  I only mention this because I spend far too
> much time (or perhaps not enough?)  explaining to people why you can't
> "just throw in SSL and you're done" with security.

That depends what kinds of people you're dealing with; and it all
depends on the reqs and threats, no rocket science there indeed.

That said, one may take note that often users can indeed just throw
in SSL and be done with.  Millions upon millions of SSL/TLS secured
transactions -- info exchange, monetary settlement, etc  -- are
conducted hourly over the internet.  [Latest source: Newsweek
(or Time?) just did a profile on eBay in a recent issue, where
the figures could back up the mil-upon-mil/hour claim made here.]
It works, cheap and easy.

Description wasn't asked in the thread's origin,
thus I'm skipping the rest.

Cheers,

Joe Hui
Exodus, a Cable & Wireless service
==============================================

> The descriptions I like to use are:
> 
> - Transient (point-to-point) confidentiality is at such a layer that
> it can protect against certain types of traffic analysis and cleartext
> header snooping.  It does not protect messages end-to-end (end-to-end
> being defined as whatever level of application processing you choose,
> which may be well within the implementation of a web service, rather
> than just the exposed service endpoint).
> 
> - Transient integrity and data authentication guard against annoyances
> like session hijacking and deliberate or accidental data corruption.
> It does not address the crucial business need of nonrepudiation, as
> there is no lasting evidence that integrity has actually been
> preserved.
> 
> - Persistent confidentiality is needed in order to achieve true end-
> to-end confidentiality; the endpoints being whatever level of
> application processing you choose.  There is no exposure of the
> messages in my DMZ, or at my ISP's secure server farm, or wherever it
> pops out of its secure channel before finally getting to my LAN or an
> application deep within my LAN.
>
> - Persistent integrity and data authentication are necessary in order
> to achieve nonrepudiation.
> 
> Is it the intent of WS-Arch Requirement AC006, and thus a future WS-
> Security WG, to address only the persistent forms of the security
> constructs mentioned, with the transient ones being assumed because
> they exist in the lower-level IETF protocols?
> 
> --Pete
> Pete Wenzel <pete@seebeyond.com>
> SeeBeyond
> Standards & Product Strategy
> +1-626-471-6311 (US-Pacific)
> 
> Thus spoke Joseph Hui (Joseph.Hui@exodus.net) on Thu, Jun 20, 
> 2002 at 12:18:40PM -0700:
> > 
> > > From: Dournaee, Blake [mailto:bdournaee@rsasecurity.com]
> > > Sent: Thursday, June 20, 2002 11:52 AM
> > > To: Joseph Hui; Krishna Sankar; www-ws-arch@w3.org;
> > > xml-encryption@w3.org; www-xkms@w3.org; reagle@w3.org
> > > Subject: SOAP Confidentiality and Integrity: What do we have now?
> > > 
> > > 
> > > Hello All,
> > > 
> > > Where exactly do we stand in terms of existing proposals 
> (W3C Notes,
> > > additional specs, etc) that offer confidentiality and 
> > > integrity for SOAP
> > > messages? We have [1], which has been used in practice by 
> > > some of RSA's
> > > customers. Is this is only existing piece of work on the subject.
> > 
> > [1] does not satisfy the confidentiality req.  For that you 
> need xenc.
> > Note that both xenc and xml-dsig are message-based 
> approaches from W3C.
> > There're also the channel-based approaches that can satisfy the two
> > said requirements (presumably of your particular interest) 
> coming from
> > outside of W3C, for instance, the TLS, IPSec from IETF.
> >  
> > Joe Hui
> > Exodus, a Cable & Wireless service
> > 
> > [1] http://www.w3.org/TR/SOAP-dsig/
>

Received on Monday, 24 June 2002 18:22:54 UTC