OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] More thoughts on relayed reliable messaging scenario


Hello Jacques,
 
The comment is about the separate WSSE header, which is ebMS (level 3) end-to-end. It is not about the WSSE header that secures the WSRM and WS-A headers.   So what I am proposing is:
- one RSP compiant header, SOAP (level 2) end-to-end but not ebMS (level 3) end-to-end,
- and a(n optional) second non-RSP compliant header, which is at level 3, and does not sign the WSA/WSRM headers, but does sign payloads and ebMS headers.
 
The WSRM/WSA headers are signed per "level 2" connection, and these fit the intended use of RSP perfectly well and should conform to it.   This is what I refer to as "SOAP message WSSE headers" in:
 
Reliable Secure Profile

The use of WS-A WSRM and the SOAP message WSSE headers should comply with the upcoming Reliable Secure Profile. This is possible if the RSP does not prevent:

·        The “ack on successful forward” semantics of relayed reliable messaging.

·        The presence of a second WSSE header.

 

I think what we have been discussing is a higher-level ("level 3") connection which RSP does not support well. This higher level connection would be secured (if needed) using the proposed non-RSP compliant WSSE header signing the ebMS header and payloads only.
 
 
Pim 


From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 27 February 2008 22:13
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] More thoughts on relayed reliable messaging scenario

Pim:
 
Regarding compliance with RSP, the following should also be considered.
You say:
 
The end-to-end ebMS message connection can be secured using a separate WSSE header, targeted at the final ebMS recipient. This header encrypts the business documents (in the SOAP body and/or in the MIME attachments) and signs these business documents and the ebMS header. It does not sign the WS-A and/or WS-RM headers, as these are processed at the SOAP message connection level. Any ebMS intermediary must not process this end-to-end security header, but copy it to the forwarded message
 
But RSP profile says:

6.2.1 Single Signature for Sequence Header and SOAP Body

As discussed in Section 5.1.1 of WS-ReliableMessaging, any mechanism which allows an attacker to alter the information in a Sequence Traffic Message or break the linkage between a wsrm:Sequence header block and its assigned message, represents a threat to the WS-RM protocol

R3100 When present in an ENVELOPE, the wsrm:Sequence header block and the SOAP Body MUST be signed with a common signature that uses the key(s) associated with security context, if any, that protects the applicable sequence

 
Whether there is a security context or not (this is optional), the requirement is clear that When a signature is used, it must cover both the RM header and the SOAP Body. In spite of actually mixing two requirements, the introductory text for R3100 makes this clear.
 
This among other things, leads me to see the "relayed RM" technique as something that is not appropriate for every segment of a multihop path, but rather for some critical intermediaries such as gateways that bridge different domains and might be in charge of some security processing.
 
Jacques
 
 


From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Tuesday, February 26, 2008 9:12 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] More thoughts on relayed reliable messaging scenario

 

 

Relayed reliable messaging scenario

 

Here are some further thought about the relayed reliable messaging scenario.

Key elements:

-         End-to-end reliable messaging based on propagating acknowledgments

-         Optional end-to-end security using a separate WSSE header

-         No assumption that all messages sent on a sequence have to be delivered ultimately at a single MSH.

-         An MSH can be Intermediary or Endpoint depending on ebMS header content.

-         Extensible to support message batching

 

Introduction

The discussion will refer to three levels of connections:

  1. HTTP transport connections.
  2. SOAP messaging. 
  3. ebMS end-to-end messaging

 

In the following diagram, arrows 1, 2, 3 and 4 are level 1 connections. Arrows 5 and 6 are level 2 connections. Arrow 7 is an ebMS end-to-end level 3 connection:

 

 

A SOAP messaging connection can involve multiple (non-ebMS aware) SOAP intermediaries. An ebMS intermediary is viewed as an endpoint from the SOAP messaging perspective. An end-to-end ebMS message that crosses n ebMS intermediaries is composed of n+1 SOAP message connections.

 

Addressing

  1. Addressing at HTTP transport level involves a mapping from next-SOAP node URIs to IP addresses
  2. Addressing at SOAP message level can be based on processing WS-A header elements like wsa:To, wsa:Action
  3. Addressing at ebMS level for end-to-end messaging is based on processing ebMS header elements such as eb:To/eb:PartyId.

 

Reliable messaging

  1. Higher-level protocols compensate for any unreliabilities at the HTTP connection level.
  2. WSRM can be used for reliability at each SOAP message connection level.
  3. End-to-end ebMS reliability is achieved by marking received SOAP messages that are forwared as delivered only when the next hop has acknowledged receipt.

 

This proposal is compatible with WSR as alternative reliable messaging spec.

 

Security

1.      The HTTP transport can be secured using TLS

2.      The SOAP message connection can be secured using a WS-Security header block. The target of this header block is the ebMS intermediary (for all SOAP connections other than the last).  The full SOAP header (including WS-A, WS-RM and ebMS extension blocks) and all payloads are signed (or whichever headers RSP wants people to sign). This WSSE header block is created by the initial sending endpoint and validated and discarded by each subsequent ebMS node (intermediary or endpoint). Each ebMS intermediary again applies WSSE SOAP message security (on all headers) before it forwards a message. 

3.      The end-to-end ebMS message connection can be secured using a separate WSSE header, targeted at the final ebMS recipient. This header encrypts the business documents (in the SOAP body and/or in the MIME attachments) and signs these business documents and the ebMS header. It does not sign the WS-A and/or WS-RM headers, as these are processed at the SOAP message connection level. Any ebMS intermediary must not process this end-to-end security header, but copy it to the forwarded message.

 

In some communities there may not be a need for the “end-to-end security” provided by the separate WSSE header, if the Intermediaries are known and are trusted to perform TLS and WSSE validation of incoming messages. In that case only the special forwarding functionality is needed.

 

Reliable Secure Profile

The use of WS-A WSRM and the SOAP message WSSE headers should comply with the upcoming Reliable Secure Profile. This is possible if the RSP does not prevent:

·        The “ack on successful forward” semantics of relayed reliable messaging.

·        The presence of a second WSSE header.

 

Sequence lifecycle messages

Any pair of ebMS nodes, endpoints or intermediaries, is free to establish any number of reliable sequences. These sequences can be established “just-in-time” or “ahead-of-time” (see http://www.oasis-open.org/apps/org/workgroup/ebxml-msg/download.php/27235/ebMS-end2end-RM-scenario4.doc).

 

Since reliable sequences are established at SOAP message level, not ebMS level, the sequence lifecycle messages need not be bundled with any ebMS headers.  They can be routed across non-ebMS intermediaries that can process WS-Addressing headers. No special functionality is required.

 

Any node needs only set up a few reliable sequences to any ebMS node it connects to, one for each set of reliable messaging parameters (e.g. At-Least-Once or At-Most-Once, various retry intervals). In the following diagram, the Intermediary can reuse a reliable connection to “Receiver C” to send messages from “Sender A” and messages from “Sender B”. This assumes we can generalize “Sequence Mapping” to “Message Mapping” (see below). This is a major advantage over the end-to-end reliable messaging scenario.  Assume an intermediary that acts as a central business activity monitoring facility for n business partners. Assume k sets of reliable messaging parameters, then the community needs to set up 2 * k * n reliable messaging sequences. In situations with end-to-end sequences, there will be a need for k * n* (n-1) sequences. Practical values for k will be just a handful, but the values for n may be in the hundreds or thousands, so this is a huge practical advantage.

 

 

 

Relayed acknowledgment

The scenario assumes that all incoming reliable messages are not acknowledged “on receipt”, but “on delivery”.  Whatever mechanism is used to establish whether the message is successfully delivered should be extended such that “reliably forwarded” is a kind of successful delivery.

When Intermediary receives an acknowledgment for Message 1 on Int-C from Receiver C, the MSH should mark Message 1 on A-Int from Sender A as “delivered”. Subsequent SOAP messages with WSRM header blocks like the following will then get confirmation on successful delivery of this message.

 

<?xml version="1.0" encoding="UTF-8"?>

<wsrm:Ackrequested>

    <wsrm:Identifier>A-Int</wsrm:Identifier>

</wsrm:Ackrequested>

 

Message mapping table

The SequenceTable proposed in http://lists.oasis-open.org/archives/ebxml-msg/200801/msg00009.html assumes a one-to-one mapping between sequence ids. This can be generalized to a Message Mapping table:

 

From

Sequence

Message-Number

To

Sequence

Message-Number

Sender A

A-Int

1

Receiver C

Int-C

1

Sender A

A-Int

2

Receiver C

Int-D

2

Sender A

A-Int

3

Receiver D

Int-D

1

Sender B

A-Int

4

Receiver D

Int-D

2

 

The MSH needs to implement some trigger mechanism such that receipt acknowledgments for forwarded messages result in marking incoming messages as marked. This is the area where WSRM processors will need to be modified to be used by ebMS intermediaries.

Note that the IDs in this table are WSRM MessageIds, not ebMS MessageIds.

 

Mixed Intermediaries / Endpoints

In situations where Intermediary is an Endpoint for some messages and an intermediary for others, the MSH can mark received messages as delivered immediately. No entry is added to the Message Mapping Table.

 

The decision whether to forward or deliver can be based on ebMS header data, such as eb:To/eb:PartyId.  Basically any pattern that can be used to decide on routing can be used here. Delivering instead of forwarding becomes a kind of routing decisions.

 

Local configurability

This proposal supports a “localized” configuration where many important connection configuration changes about an Endpoint need only be accounted for at the “last” Intermediary.  An eb:To/eb:PartyId or eb:Service can migrate from one MSH to another just by notifying the nearest Intermediary. See http://lists.oasis-open.org/archives/ebxml-msg/200802/msg00025.html for discussion.

 

Sample messages

A sample ebMS message from Sender A to Intermediary, sent over A-Int is shown:

 

<?xml version="1.0" encoding="UTF-8"?>

<S:Header xmlns:S="http://www.w3.org/2003/05/soap-envelope"

    xmlns:wsa="http://www.w3.org/2005/08/addressing"

    xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">

    <wsse:Security

        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        actor="intermediary">

        <!-- This is the security block targeted at the next ebMS node. It signs the SOAP header including all WS-A and WS-RM headers, ebMS header and all encrypted payloads.  -->

    </wsse:Security>

    <wsse:Security

        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        actor="receiver">

        <!-- This is the security block targeted at the ultimate ebMS node. It can be used to sign and encrypt the ebMS and payloads, not any WS-A and WS-RM headers as those are per hop-->

    </wsse:Security>

    <wsa:To>http://int.com/msh</wsa:To>

    <wsa:Reply-To>

        <wsa:Address>http://senderA.com/msh</wsa:Address>

    </wsa:Reply-To>

    <wsrm:Sequence>

        <!--  The message is sent on a sequence between Source and Intermediary -->

        <wsrm:Identifier>A-Int</wsrm:Identifier>

        <wsrm:MessageNumber>1</wsrm:MessageNumber>

    </wsrm:Sequence>

    <eb:Messaging xmlns:eb=":http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">

        <eb:UserMessage>

            <!-- ebMS user message. Must be unencrypted to support routing at intemediary  -->

        </eb:UserMessage>

    </eb:Messaging>

</S:Header>

 

 

This message is forwarded from Intermediary to Receiver C, sent over Int-C. Note that both WSSE are addressing the same WSSE endpoint, but in different roles:

 

<?xml version="1.0" encoding="UTF-8"?>

<S:Header xmlns:S="http://www.w3.org/2003/05/soap-envelope"

    xmlns:wsa="http://www.w3.org/2005/08/addressing"

    xmlns:wsrm="http://docs.oasis-open.org/ws-rx/wsrm/200702">

    <wsse:Security

        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        actor="intermediary">

        <!-- This is the security block targeted at the next ebMS node, which happens to be the true endpoint in this case. Intermediary signs the SOAP header including all WS-A and WS-RM headers, ebMS header and all encrypted payloads.  -->

    </wsse:Security>

    <wsse:Security

        xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"

        actor="receiver">

        <!-- This is the security block targeted at the ultimate ebMS MSH. It can be used to sign and encrypt the ebMS and payloads, not any WS-A and WS-RM headers as those are per hop-->

    </wsse:Security>

    <wsa:To>http://receiverC.com/msh</wsa:To>

    <wsa:Reply-To>

        <wsa:Address>http://int.com/msh</wsa:Address>

    </wsa:Reply-To>

    <wsrm:Sequence>

        <!--  The message is sent on a sequence between Source and Intermediary -->

        <wsrm:Identifier>Int-C</wsrm:Identifier>

        <wsrm:MessageNumber>1</wsrm:MessageNumber>

    </wsrm:Sequence>

    <eb:Messaging xmlns:eb=":http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/">

        <eb:UserMessage>

            <!-- ebMS user message  -->

        </eb:UserMessage>

    </eb:Messaging>

</S:Header>

 

Batching and Un-Batching

 

The Message Mapping Table and modified “Mark Delivered” semantics discussed before assumes a one-to-one mapping between incoming and forwarded messages.  This mechanism can be generalized to support batching (combining multiple messages and sending them in one larger message) or unbatching (splitting large messages and sending them as separate message)

 

An intermediary can combine multiple incoming messages (with multiple eb:Messaging elements) in a single larger message. The following table shows that three incoming messages are forwarded in a single message. Once that message is acknowledged, the three incoming messages can be marked delivered

 

From

Sequence

Message-Number

To

Sequence

Message-Number

Sender A

A-Int

1

Receiver C

Int-C

88

Sender A

A-Int

2

Receiver C

Int-D

88

Sender A

A-Int

3

Receiver C

Int-C

88

 

I’m not sure if end-to-end security is possible with batching, since we can’t have multiple WSSE headers all targeted at the same endpoint, more thinking to do …

 

The reverse (splitting) is a bit more complex, a message should only be marked delivered when all parts into which it is split before forwarding are acknowledged …

 

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]