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.
>
>
>
>
>
> *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:
>
>
>
>
>
> 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:
>
>
>
>
>
> *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 …
>