Secure MSH pulling

As discussed in last conf call, after review and updates with Hamid,

here is a proposal for Secure pulling, which does not require introduction of

new concepts such as MSH Id.

Although the text uses RFC2119 keywords, it does not pretend to be even close to final...

(still rough, several points need be verified / tighten-up - and how this would split between the core Pull section and the Security section is TBD.)

Jacques

1. Security of Pull mode (authentication / authorization)

- A Sending MSH MUST be able to authenticate a Receiving MSH that sends a PullRequest.

MSH support for this feature is a requirement, though its use is optional.

Authentication MUST be achieved in a way that does not depend on the parties that

may be using this MSH.

In other words, authentication of a Receiving MSH must be possible regardless of the

security requirements specific to the parties using this MSH. For example, even if these

parties decide to not use any security for exchanging messages - this could be indicated

by a CPA - it may be decided that the Receiving MSH they use still needs be authenticated

when doing pulling, like when sending any other MSH-level signal.

(it must be reminded that several parties with different security requirements,

may share a same MSH.)

- When authentication is required for a particular Receiving MSH, it is RECOMMENDED

that the Sending MSH uses persistent security.

In case a Receiving MSHs is not able to use persistent security based on XML signatures,

a password-based authentication MAY be used, e.g. as in the HTTP Basic Access Authentication

scheme [RFC2617]. In that case a secure communication protocol SHOULD be used.

If a CPA is used that defines an MSH DeliveryChannel for MSH signals sent from Receiving MSH

to Sending MSH, and when a secure Pull mode is required, then the tp:Transport element [CPPA2.1] referred to by this MSH DeliveryChannel MUST contain enough information to

support the authentication of the Receiving MSH, e.g. by enabling signatures.

The tp:Transport element MUST include a tp:EndPoint element that matches the Sending MSH

endpoint, with type attribute = "allPurpose".

- The PullRequest signal MUST contain an EndPoint element similar to the tp:EndPoint element

defined in the tp:Transport element [CPPA2.1].

The uri attribute of this element MUST uniquely identify the Receiving MSH, among all

the Receiving MSHs that may also send PullRequest signals to the same destination.

When persistent authentication based on signatures is used, a detached, WSS-compliant signature

[WSS] SHALL be used to sign the EndPoint element so that the integrity of this element is also

guarateed.

Further requirements are described in more details in the Security module.

- The processing of a received PullRequest by a Sending MSH is authorized based on

internal information that the Sending MSH maintains, that associates a list of

endpoint information about pre-authorized Receiving MSHs, with the queues these are

allowed to pull from.

2- Operational Context and scenarios (for illustration)

- When pulling is enabled between a Sending MSH and a Receiving MSH, messages submitted

to the former MUST be pulled by the latter according to a FIFO policy, effectively

achieving a queuing behavior. This queuing behavior between Sending MSH and Receiving MSH

is abstractly referred to as the S-R-queue. No assumption is made on the

implementation of the S-R-queue.

- A Sending MSH MUST associate a received PullRequest signal with an S-R-queue by matching

the tp:Endpoint in the PullRequest with the endpoint info of the Receiving MSH associated with

this S-R-queue.

- A message that is submitted to the Sending MSH and intended to a Receiving MSH for which pulling

is enabled, MUST be put in the related S-R-queue only under the following conditions:

(a) the transport attributes associated with this message - e.g. as defined in the CPA between

the parties exchanging this message - are compatible with the transport

attributes defined for PullRequest signals going the other way - e.g. as defined by the

MSH DeliveryChannel of a CPA. If that were not the case, an error MUST be raised for this message.

Configuration scenario:

o A Receiving MSH is configured with the endpoint info of every Sending MSH that it is

authorized to pull messages from. Such endpoint info may be described in the Transport element

associated with the Default MSH DeliveryChannel of a CPA.

o Similarly, a Sending MSH is configured with the endpoint info of every Receiving MSH that

is authorized for pulling.

Run-time scenario:

o The Receiving MSH sends a PullRequest to a Sending MSH.

o The Sending MSH associates this PullRequest with the claimed Receiving MSH endpoint,

and therefore with the claimed S-R-queue. It authenticates the "pulling" endpoint as

specified for this S-R-queue, typically by validating the signature using the certificate

associated with the MSH-level transport.

o The Sending MSH sends back the next message in the S-R-queue over the transport response,

applying the QoS and security required by teh communication between these two parties,

e.g. as defined in the DeliveryChannel element of their CPA.

ebxml-msg message