W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2006

Re: One-way MEP with security

From: Pete Wenzel <pete.wenzel@Sun.COM>
Date: Wed, 29 Nov 2006 14:32:58 -0800
To: Marc Hadley <Marc.Hadley@Sun.COM>
Cc: David Hull <dmh@tibco.com>, xml-dist-app@w3.org
Message-ID: <20061129223258.GA13588@seebeyond.com>

If it's helpful, there are ways of turning David's scenarios into true
multicast MEPs.  That is, instead of assuming that a different message
is produced on the wire for each recipient, a single wire-format
message can be devised, that is suitable for delivery to all

1. One method, which has been commonly used in email-based messaging
for a long time (cf. PGP, S/MIME), is to generate a random per-message
symmetric encryption key, encrypt the message with it, then encrypt
the key itself under each recipient's public key.  The resulting set
of encrypted keys is included along with the message.  Each recipient
chooses its specific variant from the list of keys, allowing exclusive
decryption of the original message.

In terms of WS-Security, the SOAP message's Security header would
contain one EncryptedKey per recipient.  (WSS Core sections 7.7 and
9.2 discuss EncryptedKey usage, but neither describe nor prohibit this
particular case of multiple EncryptedKey elements.)

2. In the second method, commonly used for digital cable and satellite
broadcasts, a symmetric key is distributed to all authorized
recipients in some fashion.  Messages to be multicast are then
encrypted with this single key.  (Typically, the key is changed
periodically, with distribution of the new key limited to currently-
entitled recipients, thus limiting the usefulness of an improperly
disclosed key.  The whole key distribution problem is out of scope of
the multicast MEP in question, of course, but may be accomplished by
using either unicast messaging, method #1 above, or some other
bidirectional? protocol.)

Here, there would be no EncryptedKey in the Security header, but
rather a single reference to the previously distributed session key.

The obvious trade-off is between security (for which #1 has better
properties) and scalability (where #2 has the advantage).


Thus spoke Marc Hadley (Marc.Hadley@sun.com) on Mon, Oct 30, 2006 at 01:30:36PM -0500:
> IIRC, the action was concerning use of in-message security (as an  
> example of a SOAP-based feature) with a multicast one-way MEP.  
> However, the SOAP-based security example you describe below doesn't  
> feature a multicast MEP but rather multiple instances of a unicast  
> MEP. The claim that:
> >this is an example of the one-way MEP, in which there happens
> >to be more than one receiver.
> mischaracterizes MEPs as being end-to-end but in the SOAP binding  
> framework MEPs are hop-by-hop. As a result I don't think this example  
> really serves to explore the interactions it was intended to.
> Marc.
> On Oct 26, 2006, at 9:58 AM, David Hull wrote:
> >
> >I have an action to propose text explaining possible subtle  
> >interactions
> >between the one-way MEP and, say, a SOAP security mechanism which
> >encodes a message to a receiver with that receiver's public key, in
> >other words, one which, given a single sent SOAP message, produces a
> >different SOAP message for each recipient.
> >
> >On further reflection, I'm not convinced that anything subtle is  
> >going on.
> >
> >First, consider a scenario where security is handled outside SOAP.  I
> >believe that XMPP can provide such an example.  In this case:
> >
> >    * The sender sends a plaintext SOAP message
> >    * The transport encrypts that message, producing a different  
> >message
> >      on the wire for each recipient.
> >    * For each receiver, the transport decrypts that receiver's copy
> >    * Each receiver receives a plaintext SOAP message.
> >
> >Clearly, this is an example of the one-way MEP, in which there happens
> >to be more than one receiver.
> >
> >Now consider a scenario where security is handled within SOAP.
> >
> >    * The sender sends a plaintext SOAP message to an intermediary
> >    * The intermediary encrypts that message, producing a different  
> >      message for each recipient, which it then sends out.
> >    * For each receiver, an intermediary receives an encrypted SOAP
> >      message and produces a plaintext SOAP message, which it sends to
> >      the receiver
> >    * Each receiver receives a plaintext SOAP message.
> >
> >Clearly, this is an example of the one-way MEP, in which there happens
> >to be more than one receiver.
> >
> >As it happens, it also involves several other examples of the one-way
> >MEP, each with a single receiver.
> >
> >The one-way MEP is playing a crucial role here.  It provides a  
> >standard
> >way to assert that each receiver receives the same plaintext message,
> >whatever happens in the middle.  Put another way, it provides a  
> >standard
> >way to assert that the overall behavior of the two systems is the  
> >same.
> >You can use the underlying transport's security if it's available.  If
> >it's not, or if you otherwise choose not to, you can handle security
> >end-to-end using SOAP.
> >
> >As far as I can tell, this is not a subtle interaction between  
> >security
> >and the one-way MEP.  It is simply layering.

Pete Wenzel <pete.wenzel@sun.com>
Sun Microsystems, SOA & Business Integration
Standards & Product Strategy
+1 (626)471-6311, Sun x61311, US-Pacific TZ
Received on Wednesday, 29 November 2006 22:35:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:30 UTC