RE: [ebxml-msg] a bi-partisan proposal

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello Jacques,

 

Sorry I missed last night's call.  Some comments inline.

 

 

 

---

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 February 2008 20:49
To: Pim van der Eijk; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] a bi-partisan proposal

Pim:

 

Sure, WS-Reliability can handle both (a) and (b) cases - assuming that the Sender knows which messages must belong to the same sequence (something most P-Modes should be able to tell).

 

In other words, there are two subcases for (b):

 

(b1) The Sender always knows which messages belong to the same RM group/sequence, even if it does not know in advance what the destination (end of route) will be. The assumption is here that we know an RM group will always end-up in teh same destination MSH.

 

(b2) The Sender does not even have the knowledge that 2 messages it sends will end up in the same destination (even if it does not know this destination as in b1). It is then unable to assign an end-to-end RM group/seq to its messages.

 

So for (b1), there is a choice:

- use WS-RM but with an RM sequence bridging technique (no end-to-end RM sequence, due to routing issues for RM signals)

- use WS-Reliability with simply end-to-end RM sequences (no routing problem). Advantage: the intermediary has nothing to do except routing!

 

For (b2), WS-Reliability wouldn't help. Some RM sequence bridging technique would be needed regardless of which RM spec is used.

 

I thought it could help if the group/sequence size is limited to one (i.e. effectively going back to ebMS 2.0 style message acknowledgments).  

 

Now, if WS-ReliableMessaging gets built-in support in several WS stacks, it should be accommodated, especially for cases (a). For cases (b) it is not clear that what's in the WS stack in terms of WS-RM implementation, can easily be manipulated to do this RM seq bridging. Certainly a stack with an open-source implementation of WS-RM would help implement this kind of intermediary.

 

About security:

 

Wouldn't what you suggest (the outermost int-to-int security layer) amount to using some transient security like SSL provides? Also the ebMS header can't be encrypted all the way if you need it for routing.

 

I was thinking of three levels of security:

1:  HTTP transport security between any pair of nodes. SSL/TLS fits here.

2:  SOAP message security across SOAP (non-ebMS intermediary) nodes.

3:  End-to-end security between "true" sender (ebMS MSH) and ultimate recipient (ebMS MSH) across ebMS intermediaries.

In an environment where there are no SOAP nodes other than the ebMS nodes, you are right that (1) and (2) are the same and the ebMS endpoint connects directly to either an ebMS intermediary or another endpoint. But if there are SOAP nodes in between the ebMS endpoint and the ebMS intermediary, then it makes sense to protect the WS-A and WS-RM/WS-R headers too.  At least, I guess that is the reason why a reliable secure profile would want to protect those headers.

In case of level (3), when the WS-A and WS-RM/WS-R headers change after forwarding by the intermediary, there still is a need to secure the ebMS header and payloads. You are right that, to support routing, the ebMS header should not be encrypted. 
  

Besides this, it is clear that several additional security schemes can be supported, as the ebMS core model is not exclusive of additional security headers. If an intermediary knows it is the "last one" on the way, it can manage to not ask more from the next MSH than what core V3 conformance requires.

 

Jacques

---

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Wednesday, February 13, 2008 7:04 AM
To: Durand, Jacques R.; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] a bi-partisan proposal

Hello Jacques,

 

If WS-Reliability is considered as an option, could it provide end-to-end reliable messaging in situation 2 (b) too? Assuming a constraint that the reliable messaging headers must be piggy-backed with ebMS headers (assuming routing is based on these ebMS headers). When the sender knows which messages will end up at the same MSH (even if it does not know which particular MSH), it could send these messages as a group. If it does not even know this, it could use groups of cardinality one, functionality that ebMS 2.0 reliable messaging provides today. Security would be preserved too.

 

When end-to-end reliable messaging is not used, perhaps we need to consider two separate wsse:Security blocks to secure the exchange:

1: One that signs the complete SOAP with attachments message, including any WS-A and WS-RM headers, targeted at the next MSH.

2: A second header that signs (and encrypts) only the ebMS 3.0 header and all payloads, targeted at the ultimate receiver MSH.

An intermediary would remove the first wsse:Security header block and re-sign the message. The second wsse header, the ebMS 3.0 header and all payloads would be copied. In this scenario, the intermediary can forward messages in different sequences, not necessarily to the same ultimate receiving MSH, and it can even deliver some messages locally. An intermediary needs sequences to deliver to its associated endpoints and for any other intermediaries. Each intermediary is an end-point for WS-A and WS-RM processing, except for the special ACK "relaying" functionality.

 

I know proposing a second header violates the requirement that endpoints should not have to behave differently to support intermediaries, but we need to balance that against the requirement of end-to-end security. 

 

Pim

 

 

---

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 February 2008 05:07
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] a bi-partisan proposal

Here is a bi-partisan proposal for a change ;-)

 

1. The core of an "Intermediary role" specification should primarily focus on such functions as store-and-forward, bridging MPCs, rules for bridging MEPs e.g. allowing a received pushed message to be pulled, etc.

- The routing function has to be assumed, but can remain unspecified, as it may depend on various header data anyway.

- the RM function can be largely ignored when specifying the above.

 

2. Reliability function: a couple of options should be specified.

 

(a) Because there will be multi-hop configurations where the Sender knows enough about the ultimate receiver endpoint so that routing is not an issue even for RM signals,  the end-to-end RM sequence should be an option. Note that this option is straightforward for conformance profiles that make use of WS-Reliability (no RM signals besides Acks). When using WS-ReliableMessaging, it will require routing support for RM signals (e.g. use of WSA, or other means TBD).

This option is the only "fully transparent" end-to-end RM (e.g. for security) and this alone justifies to support it although not possible in all multi-hop configurations dues to routing constraints. It is also very straightforward in terms of itnermediary conformance - once the routing is resolved.

 

(b) Because there will be multi-hop configurations where the routing of RM signals cannot be done e.g. to establish a stable RM sequence between two endpoint MSHs (e.g. because of too much dynamics on resolving MSHs even if partners are known, or because security issues require to "hide" a portion of the cloud) then end-to-end RM sequences cannot be established. In that case, an advanced intermediary profile will support RM sequences "bridging", so that end-to-end delivery assurance is still possible at least for "At-Least-Once", "At-Most-Once" and "Exactly-Once" delivery. This bridging can involve some Ack relaying techniques that need to be specified so as to depart as little as possible from standard RM module behavior.

 

Clearly, some multi-hop topologies might combine both (a) and (b). E.g. the I-cloud includes a "hidden" portion that has a well-known "gatekeeper" intermediary. Regardless of how many intermediaries are involved between a Sender endpoint MSH and a "hidden" ultimate Receiver MSH, it is possible to use a single RM sequence from Sender to Gatekeeper, and a single RM sequence from Gatekeeper to ultimate Receiver, while reducing the RM sequence bridging to the Gatekeeper only (all other intermediaries of the I-cloud being "transparent"). A non-transparent Gatekeeper would make sense anyway as  it is possible that the QoS on the hidden I-cloud is different (e.g. a VPN), so some Security processing may need to take place on the Gatekeeper, e.g. validating a sig on the RM headers that are removed, or removing encryption.

 

Hope that may relieve the deadlock... or provide enough wiggle room to move one step further.

 

Jacques