[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
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:JDurand@us.fujitsu.com] 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]
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:
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
Reliable messaging
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:
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
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]