RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases e-Bus ines s Architecture Technical Specification for Public Review])

> -----Original Message-----
> From: Duane Nickull [mailto:duane@xmlglobal.com]
> Sent: Thursday, February 13, 2003 8:51 AM
> To: Assaf Arkin
> Cc: Burdett, David; www-ws-arch@w3.org
> Subject: Re: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> e-Bus ines s Architecture Technical Specification for Public Review])
>
>
>
>
> Assaf Arkin wrote:
> > For example, you can have a service level agreement that need to be
> > pre-negotiated and all messages have to carry the SLA number to be
> > processed and the SLA can be started and managed by some WSDL
> operation.
> > There is no need to negotiate messaging-level agreement, and the
> > negotiation of another agreement could be in itself a service.
> >>>>>>>>>>>
>
> I thought of that in ebXML as well, however I personally pushed for the
> CPA to be required and processed in the outermost envelope.  This was an
> architectural decision based on the rising popularity of DOS attacks
> (denial of service).  It is foreseeable that someone could pump in
> 1000's of bogus messages if they wanted to tie up a specific BSI
> (Business Service Interface).  The TA team was constrained by making
> sure we thought of hacker attacks, no single point of failure etc..
>
> By parsing and comparing the CPA ID in the outermost envelope at the
> messaging layer (probably by slurping the first 500 bytes via SAX),  it
> requires far less processor resources than to open the envelope first,
> then route the message payload to another resource before trying to
> validate the service level agreement.

Security by obscurity ;-)

If the message is not encrypted it's easy for an attacker to obtain a CPA ID
and use that for a DoS. If the message is encrypted then the signature is
used to filter bogus messages from real messages. Signatures is the only
solution I am aware of for the generals problem which is basically this form
of attack (attacker masquarading as sender).

I assume we all agree WS-Security provides a better framework for
identifying the sender and determining whether or not to accept a message
from that sender in a manner that is truely secure and with multiple
mechanisms.

I basically think it's wrong for a specification to try and solve problems
that are outside it's jurisdiction. On the other hand, it should use an open
framework to allow such solutions to be used in combination. So one of the
value statements of WSDL is that it allows such specifications to exist. You
can always create a better security specification and use it to reference
WSDL operations to which the security policy applies. (And a million other
things, like transactions, business commitements, billing, analytics, etc).

arkin

>
> For right or wrong,  that was the thinking.
>
> Duane
>
>
>
> --
> VP Strategic Relations,
> Technologies Evangelist
> XML Global Technologies
> ****************************
> ebXML software downloads - http://www.xmlglobal.com/prod/

Received on Thursday, 13 February 2003 21:45:47 UTC