OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ebxml-msg] Groups - Security Concern


Title: RE: [ebxml-msg] Groups - New Issue Discovered

There are many reasons to profile specifications.

 

I am assuming the v 3.0 ebMS is, like the ebMSes  before, a package of available technology to be used in the exchange of business data and that allows connections to be made to the other levels/parts of ebXML. Convergence means that we will update ebMS to take advantage of new specifications to provide the capabilities for ebMS. These are primarily WSS and WS-R[M|X]

 

So

1. when business data is to have “message enveloping security” of business data, a standard means of doing this deserves definition

2. when business data is to be digitally signed, a standard format of doing this deserves definition

3. when 1 and 2 both, the ebMS format needs specification.

 

If you wish to use WSS in any of the other endless myriad permutations allowed by WSS, and your ebMSes both support the non-mandated format, fine. But we won’t specify those.

 

The main presumption for message layer security is that the message’s business data and all of its business data gets the desirec security treatment. [Businesses do not regard their messages as padded with stuff undeserving of QOS protection. So the goal of the profile here is to say, at least, how to sign all the business data, and so forth.

 

Added specification would say how to sign “other stuff” (mainly soap:headers) if the security situation requires that. So beyond the above 3 variants, there would be (IMO) a way to do secure SOAP headers for 2 broad cases: when SOAP intermediaries present and when they are not present.

 

That is a start.

 

But ebMS “profiling” is responding to different concerns than WS-I in its “conformance  and interop” profiling. The latter wanted to toss out bits that were unclear or that they thought might cause interop problems (or that they did not want to implement). Our goals have been different from the start. Perhaps if all this is unclear, we can devote some time on a call to review why there is an ebXML Messaging spec rather than just starting with CPPA and a SOAP header for support of business process and collaboration protocol agreements.

 

 

 

 


From: Hamid Ben Malek [mailto:HMalek@us.fujitsu.com]
Sent: Wednesday, March 01, 2006 3:11 PM
To: Dale Moberg; Ric Emery
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - Security Concern

 

Date, Ric,

I understand your concern. But let me first explain my view. I am not against profiling WSS within ebMS-3 core draft. It the security section was only about profiling WSS, I would not have deleted that part. The security section contained two parts (its contents could be categorized as being one of two kinds). The first kind (or category) consists of “profiling WSS”. And by this, I mean giving real algorithms (listing the steps to follow) in order to sign/encrypt messages. The second category of contents consists mainly in listing examples of messages that are signed/encrypted. I really believe that the second category of contents is not necessary and should be removed because it overlaps too much with WSS spec and does not provide any help (an implementer not familiar with WSS would still need to read WSS spec in order to implement it. The examples would not help in any way. It is not like the examples of ebMS packaging headers which help an implementer by just looking at them). For the first category of contents (profiling WSS), I am not against that and I can very easily put that back in the draft. However, I first would like to be convinced that such a profiling is really meaningful. I still believe that the WSS spec contains such algorithms (the steps to follow in order to sign/encrypt messages), and we don’t need to list those steps. I would like to understand what we are doing here with those steps that is really very different from those steps described in WSS spec. Furthermore, WS-I already profiled some of the security modules and I still don’t see an interop risk by not profiling WSS in a way that is unique to ebMS-3 core (a way that is not described anywhere in WSS or WS-I). I may be ignorant about WSS, but all I am asking for is to understand what is so special about our own profiling of WSS in ebMS-3 (I still believe that there is no interop risk if we don’t invent a new profile of WSS). Am I wrong about this?

 

Hamid.

 


From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Tuesday, February 28, 2006 8:22 PM
To: Ric Emery
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - No more pending issues

 

+1

 


From: Ric Emery [mailto:remery@cyclonecommerce.com]
Sent: Tuesday, February 28, 2006 1:44 PM
To: Hamid Ben Malek
Cc: Jacques Durand; Sacha Schlegel; Dale Moberg; 'ebxml-msg@lists.oasis-open.org'
Subject: Re: [ebxml-msg] Groups - No more pending issues

 

Dale and I have a concern that the Security Section was, for the most part, removed from the spec. We spoke with Jacques about this last week on the conference call. I was trying to profile WSS down, to show how signing and encryption should be done for ebMS.
We both feel that the ebMS spec should state prescribed ways to sign and encrypt messages. Then state something to the effect that other WSS compliant mechanisms can be utilized. But are left outside of the scope of the ebMS spec, and support is not required.

Only stating that ebMS can utilize WSS is not going to be enough to ensure interoperability.

Hamid Ben Malek wrote:

I don’t know if you are aware of it or not, but this is just to make sure you know. The list of pending issues Jacques is talking about is already resolved. Please read Draft 9a posted to Kavi. We just need to vote on that draft (either approve it the way it is, or correct few items and make it a CD 2).

 

Hamid.

 


From: Jacques Durand
Sent: Tuesday, February 28, 2006 1:34 AM
To: 'Sacha Schlegel'; Dale Moberg; Hamid Ben Malek; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - New Issue Discovered

 

Sacha:

 

Your points are taken.

So far I believe your concerns below are addressed by the current draft (?)– if yes let us move on to wrap-up CD2.

We still have some review work to do on the pending list of proposals to the issues – are we ready to discuss these next meeting?

I have appended these proposals at the end of this email.

 

Jacques

 

 

 


From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com]
Sent: Monday, February 27, 2006 8:46 PM
To: Jacques Durand; Dale Moberg; Hamid Ben Malek; ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Groups - New Issue Discovered

 

 

Hi everyone

I did not follow the conversation but I saw that you mention Service and Action, and even Roles ... actually they have great value if you take the top down approach and if you define your collaborative business processes (with ebXML Business Process) first. Eg you just have to look at the ebXML message header and you got all the information in one place, that is very convenient.

The From, FromRole, To, ToRole, Service, Action, and CPA id values in fact provide the link to the ebXML CPA (to look up security, reliable messaging and other messaging operational aspects). At the same time and in combination with the conversation ID these values provide the information to identify the document exchange in the collaborative business process. So to me ebXML Messaging "2.0" has actually very good support for higher level collaborative business processes. So to deal with ebXML messages that do not have those values anymore ... it would take some headscratching how to interact with the next layer (CPA in this case).

From what I see the advanced ebXML end users, those who think along the lines of adding, removing and changing collaborative business processes over time to their trading partner relationsships, do in fact take the top down approach starting with the collaborative business processes, managing the CPA's and then using ebXML messaging that supports that approach by those Role, Serivce, and Action information in the ebXML message header.

Ignore this email if my concerns are not related to your current discussion.

Sacha

-----Original Message-----
Remiaining proposed and agreed updates on latest WD 0.8: (Feb 15)

 

-----------------------------------------------------------------------

-----------------------------------------------------------------------

5) Subsubsection 5.1.3 (ebXML SOAP Envelope Extension ) should be

moved to 5.1.4, and a new subsubsection 5.1.3 should be added having

the title Example.

 

STATUS: Agreed that a complete example be provided in its own section.

Some disagreement as to placement of Example section.  Some feel it

should be first; others would like the normative specification text

first with example following.

 

EDIT: Just need detailed proposal

 

 

-----------------------------------------------------------------------

6) In examples, the element eb:Partref still contains the attributes:

(and Partref to be renamed PartInfo I believe)

 

5.a- eb:id : agreed to remove (replaced by XML Id)

5.b- eb:idref. Use instead "href" (a SOAP standard attribute).

 

STATUS: agreed.

EDIT: Just need detailed proposal (see SOAP 1.2 appendix which uses it)

 

-----------------------------------------------------------------------

7) remove sections related to SOAP actors:

 

In Part 1:

- Remove sections 5.1.3.8 , 5.1.3.9, 5.1.3.10 about SOAP actors & mustUnderstand,

as the related topologies that such actors

support are relevant to Part 2. (see proposed changes for Section 3 below)

 

In Part II:

- introduce the additional topologies that are handled.

- address the routing issue for MEPs in a more generic way, and add SOAP actors as needed.

 

STATUS: agreed. Issue 8 takes care of scoping Part 1 to remove needs

for handling intermediaries.

EDIT: TO DO (Part 1)

 

-----------------------------------------------------------------------

8) Remodeling of Section 3:

 

8.a- Remove 3.4 and in Section 1 Intro (1.2 "Scope") add:

"Features defined in Part 1 only support the point-to-point MSH topology,

where no MSH or SOAP intermediary is assumed.

Part 2 takes into account topologies with intermediaries, hub or multi-hop, as well

as topologies where the ultimate MSH acts as a SOAP intermediary."

 

8.b- move section 3.3 "Message Service Processing Model" at the end of

Section 2 (Messaging Model), replace title as "Messaging Service Processing Model"

or  "MSH Processing Model". 

 

8.c- Replaces what is left of Section 3 (3.1 + 3.2) with proposal posted.

 

8.d- Section 3 should then be renamed "Processing Modes"

 

STATUS: Proposal has already been discussed and reviewed, no overall objection.

EDIT: Ready for inclusion review draft.

 

-----------------------------------------------------------------------

9) @soapresp attribute:

 

STATUS: Agreed to remove. (references to it still in from 2.2.3.1 and 2.2.3.3)

EDIT: TO DO

 

------------------------------------------------------------------

10) Security:

 

- too many examples that may not add value, redundant with WSS examples?

- Ric notes that the security examples are incorrect, where the references

are supposed to be to the SOAP Body, but instead contain a cid:xxx.

 

STATUS: Agreed in general. Needs detailed proposal.

EDIT:

 

--------------------------------------------------------------------

11)

 

reliability of "Internal" Service/Action (such as msg:service/Ping):

 

Last bullet item in 8.2.2:

 

Relax the requirement:

"... For example, in the case of At-Least-Once delivery, the MSH must

ensure that if a message that has been submitted (Submit) fails before RM-Submit is invoked,

then the user layer (Producer) gets a notification of failure (Notify invocation), as would be the

case if the message processing failed just after RM-Submit was invoked. Similarly, if a message

fails to be delivered on receiver side (Deliver) even after RM-Deliver has been successfully

invoked, then a notification to the Consumer must occur on the receiver side (Notify)."

as:

"...For example, in the case of At-Least-Once delivery, the MSH must

ensure that if a message that has been submitted (Submit) fails before RM-Submit is invoked,

then a delivery failure Error is generated, as would be the

case if the message processing failed just after RM-Submit was invoked. Similarly, if a message

fails to be delivered on receiver side (Deliver) even after RM-Deliver has been successfully

invoked, then a delivery failure Error must be generated.

The reporting of these errors obeys the P-Mode.errorHandling."

 

 

At the end of 8.2.2 (Reliability section) add:

 

"Messages that have eb:CollaborationInfo/eb:Service set to “urn:oasis:names:tc:ebxml-msg:service”

are not intended to be delivered (Deliver) to an MSH Consumer, although they may be submitted by

an MSH Producer. They are intended for internal MSH consumption.

They may also be subject to reliability contracts. In this case, the at-least-once contract

is fulfilled

with a successful RM-delivery. In case of at-least-once delivery, a failure do deliver must cause the

generation of a delivery failure Error. If this message was

submitted or initiated by an MSH Producer (Submit) instead of the MSH itself (e.g. a Ping initiated by

the Producer), the Producer may be notified (Notify)

of the failure depending on the reporting mode, as for regular user messages."

 

Also, in 8.1,  L2822, replace "may be subject" with "is subject".

 

STATUS: Correction by author.

EDIT: Ready for inclusion review draft.

 

----------------------------- Error section: ---------------------

12)

- Add 1 error EBMS:0010 "ProcessingModeMismatch", severity: failure, category: Processing

"the ebMS header is not compatible with expected content based on the associated P-Mode."

 

- in Reliability errors, Add 1 error EBMS:0201 "DysfunctionalReliability"

severity: failure, category: Processing

"some reliability function as implemented by the Reliability module, is not operational,

or the reliability state associated with this message sequence is not valid."

 

- renumber the error code for "DeliveryFailure"as: EBMS:0202 (instad of 0010)

 

- renumber the error code for "Failed Authentication" as: EBMS:0101 (instad of 0011)

 

STATUS: Correction by author. Renumbering is editorial. The new errors are to be discussed.

EDIT:

 

------------------------------------------------------------------

13)

Section 2.2.2.1:

 

reword:

 

The response message, in case a two-way underlying protocol is used:

(a) may contain a SOAP envelope with a SOAP body that is always empty, in which case the One-way MEP

is qualified as "composable".

(b) may contain a SOAP envelope with a SOAP body that is either empty or contains a SOAP Fault.

In that case the MEP is qualified as "fault supporting" in addition to being composable.

(c) may never contain a SOAP envelope, in which case the SOAP One-way MEP is qualified as “strict”.

 

STATUS: Correction by author.

EDIT: Ready for inclusion review draft.

 

------------------------------------------------------------------

14)

Section 4.1:

 

reword as:

 

"...ways with another MSH, engaging in a client-server type of interaction with

the remote MSH, without any need to open a port to incoming requests. This MEP also

supports exchanges with a partner that is intermittently connected: instead of periodically

polling for partner presence, a sending MSH will simply wait for the partner MSH to pull

messages."

 

Example: A mobile, occasionally connected device without static IP address and with

limited storage capability

can only initiate requests and receive messages as synchronous responses to these.

The  One-way Pull MEP allows this device to enable and control the flow of received messages,

and to adjust it to its own resources.

 

L752:

"...without a need to transfer filter expressions. " --> "...without a need to transfer and

process filter expressions. "

 

STATUS: Correction by author.

EDIT: Ready for inclusion review draft.

 

-------------------- Operation COntext --> P-Mode ----------------

15)

 

Section 2.4.3:

"...This is done by sharing the message pipes operation context (see OpCtx_MessagePipes in Section 3)."

replace with:

"...This is done by sharing the message pipes processing mode feature

(see P-Mode.messagePipes in Section 3)."

 

Section 5.2.9:

"... AgreementRef is a string value that identifies the operation context that governs the exchange.

The

recipient of a message MUST be able to resolve the AgreementRef to this operation context, or to the

related agreement between the Sending and Receiving parties."

replace with:

"... AgreementRef is a string value that identifies the agreement that governs the exchange.

The P-Mode under which

the MSH operates for this message MUST be aligned with this agreement."

 

Section 7:

"... Error generation and error reporting are treated here as orthogonal concepts. Some aspects of error

handling - in particular, reporting - are best specified within the operation context for error handling

(OpCtx-ErrorHandling) e.g. as resulting from an agreement."

replace with:

"... Error generation and error reporting are treated here as orthogonal concepts. While the generation of errors

is a matter of conformance, the reporting of errors may be subject to an agreement. Consequently, the way errors

are to be reported is specified in the P-Mode (P-Mode.errorHandling feature) that results from such an agreement."

 

Section 7.5:

"... Except for some cases defined in this specification, Error escalation policies are left to an

agreement between users, represented in the operation context of an MSH ( OpCtx-ErrorHandling)."

replace with:

"... Except for some cases defined in this specification, Error escalation policies are left to an

agreement between users, represented in the processing mode of an MSH ( P-Mode.errorHandling )."

 

Section 7.7.1:

EBMS:0003 : replace operationn context with "processing mode"

 

Section 8.1 (end):

"... Note that depending on the reliability operation

context (OpCtx-Reliability), notification of delivery failure may be detected on either side."

replace with:

"... Note that depending on the reliability processing mode (P-Mode.reliability),  awareness of

delivery failure may occur on either side."

 

STATUS: Editorial effect of replacing Section 3. Follows from agreement on (8)

EDIT: Ready for inclusion review draft

 

------------------------- ----------------

16)

Section 10 "Reliability Protocol Bindings"

Replace:

"It is not the intent of ebMS to open too many options, but the case of reliability is

a particular one, as each one of the two OASIS reliability specifications has strong arguments

in its favor."

with:

"Although either one of the above OASIS reliability specifications is sufficient,

each one has strong arguments in favor of its use."

 

In 10.1.3: in the table:

".. two additional requirements MUST be satisfied"

only the two first bullets apply, bullet 3 should not be part of this sublist.

 

In 10.1.4: in the table:

".. two additional requirements MUST be satisfied"

The two conditions should be singled out , e.g. with dashes or bullets.

 

 

STATUS: Correction by author.

EDIT: Ready for inclusion review draft.

 

---------------------------------------------

17)

Insert COnformance Appendix, latest update (Feb 14).

 

STATUS: 3rd iteration, latest updates to be discussed.

EDIT: Ready for inclusion review draft.

 

 

---------------------------------------------

18)

Insert SOAP 1.2 binding Appendix.

Remove previous Appendix 11.

 

STATUS: SOAP 1.2 latest agreed. Appendix 11 removal to be discussed / confirmed.

no general objection.

EDIT: ?

 

---------------------------------------------

19)

Security Module (Section 6.3)

security of attachments WSS1.0 vs WSS 1.1

 

STATUS: Proposal to handle this by a new COnformance profile (Level 2) in Part1. Linked to Issue 17.

EDIT: Need to describe both WSS 1.0 and WSS 1.1 + WSS-SWA options.

 

---------------------------------------------

20)

Update the packaging figures Section 5 (fig 7 and 8)

- remove StatusRequest / Response signals.

 

STATUS: Need concrete proposal

EDIT:

 

------------------------------------------

 

 

21) Section 10.2.1:

WS-RM binding: should specify that:

- RM QoS applies to an entire sequence, and is communicated in the CS extension point.

(need to decide of a format for interoperability ! propose a default, can be override in P-Mode ?)

 

STATUS: Need discussion, concrete proposal

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]