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 …
