- From: Pete Wenzel <pete@seebeyond.com>
- Date: Fri, 21 Jun 2002 16:16:36 -0700
- To: Joseph Hui <Joseph.Hui@exodus.net>
- Cc: "Dournaee, Blake" <bdournaee@rsasecurity.com>, Krishna Sankar <ksankar@cisco.com>, www-ws-arch@w3.org, xml-encryption@w3.org, www-xkms@w3.org, reagle@w3.org
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. 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 Friday, 21 June 2002 19:17:31 UTC