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

[Sander Fieten <sander@fieten-it.com>]

Jacques,

does this requirement R3100 from the RSP really require that when a 
signature is used it should cover both the ws-rm headers and the body 
even when the target of that signature is only the body? I can imagine 
that ws-rm is used to get reliable transport but not for reliability on 
the business level, i.e. the payload. In such a scenario signing of the 
ws-rm headers would not be necessary.


Regards,
Sander

Durand, Jacques R. wrote:
> 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 …
>