[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