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] | [Elist Home]


Subject: Fw: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment


Resent due to incorrect addressees in the original message.

-Arvola

-----Original Message-----
From: Arvola Chan <arvola@tibco.com>
To: Duane Nickull <duane@xmlglobal.com>
Cc: ebxml-msg@oasis-open.org <ebxml-msg@oasis-open.org>;
ebxml-cppa@oasis-open.org <ebxml-cppa@oasis-open.org>; ebtwg@lists.ebtwg.org
<ebtwg@lists.ebtwg.org>
Date: Thursday, August 30, 2001 11:55 AM
Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment


>Duane:
>
>The current Messaging Service is point to point, so I think "Smurf" attacks
>are
>less likely. I suppose if we add broadcast or multicast facilities in the
>future,
>then we need to worry more about denial of service attacks.
>
>If the To Party is expecting a request message to be signed, then signature
>validation failures need to be handled more delicately. Currently, the spec
>says that an error message with the error code SecurityFailure should be
>returned. I think the To Party should not be obligated to return an error
in
>the case of security failures.
>
>In the RosettaNet Implementation Framework (RNIF 2.0), security errors
>are only logged internally. No exception can be sent (for security reasons)
>under normal circumstances. An exception may be sent if there is a
>debug header present in the transport headers of the incoming message.
>
>-Arvola
>
>-----Original Message-----
>From: Duane Nickull <duane@xmlglobal.com>
>To: Arvola Chan <arvola@tibco.com>
>Cc: ebxml-msg@oasis-open.org <ebxml-msg@oasis-open.org>;
>ebxml-cppa@oasis-open.org <ebxml-cppa@oasis-open.org>;
ebtwg@lists.ebtwg.org
><ebtwg@lists.ebtwg.org>
>Date: Thursday, August 30, 2001 11:32 AM
>Subject: Re: T2 Non repudiation and MSG, CPP/A, BPSS spec alignment
>
>
>
>
>Arvola Chan wrote:
>
>> The BPSS spec says that nonRepudiationOfReceipt (NRR) is tied to the
>> ReceiptAcknowledgement signal. NRR and reliable messaging are orthogonal.
>A
>> business process may specify the non repudiation of receipt for the
>> requesting business activity business message and/or the repudiation of
>> receipt for the responding business activity business message, without
>> requiring that reliable messaging be used. I think the Messaging Service
>> should not tie NRR to the DeliveryReceipt element if the latter is used
>> exclusively in reliable messaging.<SNIP>
>
>>>>>>>>>
>
>I want to bring up a security concern that came to mind reading all of
>this.  Is there any possibility that someone could place a cleverly
>composed message with a ReceiptAcknowledgement signal required in return
>to a multiple parties thereby starting a "Smurf" campaign.  Many of you
>who have been in the industry long enough probably remember the chaos
>caused by smurf attacks back in the 90's.
>
>
>Just a thought to muse over ;-)
>
>Duane Nickull
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebtwg.org/ob/adm.pl>
>



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


Powered by eList eXpress LLC