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] Re: Signed Errors



In the mean time,  I got feedback from another developer, yet a different opinion, see italic text below ...


We do not sign errors as we think that this doesn’t make sense and may cause follow-up errors.

o  - Do not sign errors caused by signed messages, ie. leave as is: Yes/No

YES
-   problem with signed errors is that they can cause followup errors if the wrong certificate is installed at the sender
what to do with ErrorMessages with unknown certificates ?

o   completely ignore the ErrorMessage (like Receipts) ?

o   ignore just the signature and process the error ?

o -  Always sign errors if the originating message causing an error condition was signed: Yes/No

NO

o - Optionally sign errors for signed messages that caused an error condition: Yes/No

NO



On 05/08/2014 05:04 PM, Dale Moberg wrote:

+1 to final (bold emphasized) point. We should leave this as a user-selected security policy choice. Error reporting (& delivery) was subject to different p-modes that, imo, amounted to a policy-based configuration in ebms3. I think this should be retained and perhaps clarified in the next minor version of ebms3.

The developers’ concerns possibly raises a wider problem of TC guidance to implementers on a reasonable out-of-the-box default policy for conformance profiles. I suppose that a conformance profile such as AS4 could recommend a default security policy (using “should” or “recommended” modality), with it being noted that bilateral decisions to override the default policy are possibilities that implementations are expected to enable (through selectable pmodes).

 

 

 

From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Thursday, May 08, 2014 3:42 AM
To: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Re: Signed Errors

 


Here is some feedback from another developer:

In our opinion Option number three, to provide signing as an optional feature makes the most sense. The reason for not always signing is the determination of the certificate which should be used to sign. If I have my system configured to use multiple certificates for communicating with different partners (as many of our customers do) and the cause for the error is that I cannot determine the partner who sent the message – for example because of an erroneous PartyID configuration or because of database problems – which certificate should I use for signing the error message?

When defining that error messages which relate to signed user messages should be signed when possible but also have to be processed when not signed, we would not run into severe problems when being unable to recognize the partner.

Another point which may not be overseen is that error messages can become a security issue. If a system provides too much information in its error messages (I have seen many stack traces in the tests we have done by now), an attacker is able to determine vulnerabilities by sending erroneous messages to an MSH, see many SQLInjection-Attacks which rely on error messages passed through to the GUI.

My response is that the problem may not arise when there is WS-Security processing as the first step in the pipeline,  so any message by some malicious third party would not be signed, or at least not using a valid certificate (unless that party has obtained the certificate of a valid trading partner).   The behaviour of responding to faulty signed SOAP requests is described in WS-Security,  and the response (if there is one) would be a Fault rather than an ebMS error.  I think WS-Security allows not sending a fault, as indeed the fault may leak information useful to an attacker.  So as ebMS TC we could clarify that ebMS signed errors are only relevant for valid signed requests that have some other ebMS-level error, and then the receiver knows who she is sending the error to.

Most emerging profiles I am aware of require WS-Security, so a receiver MSH can simply reject (and ignore) any unsigned message. There could be a problem with users of profiles that support unsigned ebMS messages,  there the decision whether or not to send errors is an ebMS3 level decision, rather than a WS-Security decision.    For the same reason that WS-Security allows to ignore faulty requests instead of sending faults,  ebMS could perhaps allow such a policy at ebMS level.

Pim

On 05/08/2014 06:50 AM, K N, Krishna wrote:

Hi,
 
Here are your answers (From SoftwareAG team).
 
o  - Do not sign errors caused by signed messages, ie. leave as is: Yes/No
NO
 
o -  Always sign errors if the originating message causing an error condition was signed: Yes/No
YES(We discussed in our team and thought this might be the right approach) 
 
o - Optionally sign errors for signed messages that caused an error condition: Yes/No
NO
 
 
Thanks
Krishna
 
 
 
-----Original Message-----
From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Theo Kramer
Sent: Tuesday, April 29, 2014 12:27 AM
To: Pim van der Eijk
Cc: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Re: Signed Errors
 
Hi Pim
 
Apologies for the delay - am on holiday with the family. Hope the following will suffice. I have copied this to the list should there be any further comment or input
 
Re: ebMS3/AS4 Signed and/or Encrypted Error Handling
 
Dear AS4 Developer/Administrator/Vendor
 
It has come to our attention that  there is no explicit method to ensure that ebMS3 error messages should be signed or encrypted either in the ebMSV3 core specification or in the AS4 Profile.
 
It would be useful, particularly in cases where it is not possible to provide other means such as access control lists (ACLs) to ensure authorised connectivity, to  authenticate and validate that the MSH that is posting an error with the MSH to which the original message in error was sent and not from some other source. This, in particular, for asynchronous errors, and also inline with the required behaviour for signed receipts as per the AS4 Profile.
 
It is, however, our understanding that for current implementations neither synchronous or asynchronous error messages are signed and/or encrypted and requiring this as for signed receipts may cause interoperability implications for existing systems.
 
With that, and prior to making a change to either the ebMSV3 core spec or to the AS4 profile we would like to obtain your opinion on the above matter. Please respond to this by answering the following questions and also feel free to provide any further input on this that you may feel appropriate
 
o  - Do not sign errors caused by signed messages, ie. leave as is: Yes/No
 
o -  Always sign errors if the originating message causing an error condition was signed: Yes/No
 
o - Optionally sign errors for signed messages that caused an error condition: Yes/No
 
Sincerely
 
OASIS EBXML Messaging Technical Committee
 
Related Documents
 
OASIS ebXML Messaging Services Version 3.0 Part 1: Core Features. 01 October 2007. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html.
 
AS4 Profile of ebMS 3.0 Version 1.0. 23 January 2013. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html.
 
 
On 28 Apr 2014, at 09:01 , Pim van der Eijk <pvde@sonnenglanz.net> wrote:
 
 
OK,  feel free to update the text.   As you may see at http://ebxml.xml.org/,   the number of vendors implementing AS4 is increasing rapidly ..
 
Pim
 
On 04/27/2014 12:39 PM, Theo Kramer wrote:
I've been thinking of adding some options eg. Leave as is, always sign, or make it optional to be agreed by parties before sending.
 
Regards
Theo
Sent from typo enabled phone
 
On 27 Apr 2014, at 11:45, Pim van der Eijk <pvde@sonnenglanz.net> wrote:
 
 
Hi Theo,
 
Did you want to discuss this on the TC,  or shall I forward this as is?
 
Kind regards,
 
Pim
 
On 04/19/2014 08:23 AM, Pim van der Eijk wrote:
 
 
Hi Theo,
 
This looks fine to me,   and I can forward this to some of the vendors that are not in OASIS/on the TC.
 
We could indeed add a PMode parameter to the core spec and profile AS4 to have behaviour like we do with receipts.  I agree we (practically) only need signing and not encryption.
 
Good Easter,
 
Pim
 
 
 
 
On 04/19/2014 08:08 AM, Theo Kramer wrote:
Hi Pim
 
Following on from our discussion on Signing Errors I thought we could send out the following to some of the current AS4 Implementation vendors, developers and system administrators.
 
------------------------------------------
Re: ebMS3/AS4 Signed and/or Encrypted Error Handling
 
Dear AS4 Developer/Administrator/Vendor
 
It has come to our attention that  there is no explicit method to ensure that ebMS3 error messages should be signed or encrypted either in the ebMSV3 core specification or in the AS4 Profile.
 
It would be useful, particularly in cases where it is not possible to provide other means such as access control lists (ACLs) to ensure authorised connectivity, to  authenticate and validate that the MSH that is posting an error with the MSH to which the original message in error was sent and not from some other source. This in particular for asynchronous errors, and also inline with the required behaviour for signed receipts as per the AS4 Profile.
 
It is, however, our understanding that for current implementations neither synchronous or asynchronous error messages are signed and/or encrypted and requiring this as for signed receipts may cause interoperability implications for existing systems.
 
With that, and prior to making a change to either the ebMSV3 core spec or to the AS4 profile we would like to obtain your opinion on the above matter.
 
Sincerely
 
OASIS EBXML Messaging Technical Committee
 
Related Documents
 
OASIS ebXML Messaging Services Version 3.0 Part 1: Core Features. 01 October 2007. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/core/ebms_core-3.0-spec.html.
 
AS4 Profile of ebMS 3.0 Version 1.0. 23 January 2013. OASIS Standard. http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/profiles/AS4-profile/v1.0/AS4-profile-v1.0.html.
 
----------------------------------------
 
... and now as I write this why not just make this an option with a p-mode such as
 
PMode[1].ErrorHandling.Report.SignErrors: support not required and only valid for errors generated from signed messages (true/false)
 
?
 

 




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