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

Just to be on the safe side, I will ask RSP WG for 
confirmation - and possibly a clearer wording of R3100.

Although I am pretty sure that this is what the requirement 
says even when there is no WS-SecureConversations 
context.

(the title 6.2.1 and the rationale blurb are rather clear 
on this)

 

Jacques

From: Moberg Dale [mailto:] 

Sent: Wednesday, February 27, 2008 1:22 PM
To: Durand, 
Jacques R.; Pim van der Eijk; 
Subject: 
RE: [ebxml-msg] More thoughts on relayed reliable messaging 
scenario

Does RS3100 imply that 
the WSRM:Sequence block is signed if no security context is present? Is 
“security context” meant in the WS-SecureConversations sense or is it just 
another way of talking about the PKI infrastructure that supports signing 
between RMS and RMD?

 

 

 

From: Durand, 
Jacques R. [mailto:] 
Sent: Wednesday, February 27, 2008 2:13 
PM
To: Pim van der Eijk; 

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:] 
Sent: Tuesday, February 26, 2008 9:12 
AM
To: 

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:

  
HTTP transport 
  connections. 
  
SOAP 
  messaging.  
  
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

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

 

Reliable 
messaging

  
Higher-level 
  protocols compensate for any unreliabilities at the HTTP connection level. 
  
  
WSRM can be used 
  for reliability at each SOAP message connection level. 
  
  
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 …