[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
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:dmoberg@axway.com] Sent: Wednesday, February 27, 2008 1:22 PM To: Durand, Jacques R.; Pim van der Eijk; ebxml-msg@lists.oasis-open.org 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]