RE: [ebxml-msg] security problem with ebXML MS

["Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>]

An updated version including payload encryption.
Realistically, I am not hopeful payload encryption
can be fixed for this version, but it is here for consideration by
the TC either short term or long term.

Thanks,
-Suresh

-----Original Message-----
From: Damodaran, Suresh 
Sent: Tuesday, November 06, 2001 5:44 PM
To: 'James M Galvin'; Christopher Ferris
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] security problem with ebXML MS



Attached is a proposal to address the issues that Jim is bringing up.
The proposal discusses a processing model when signatures are involved.
I believe it would serve us best to include the specifics in 1.1 version
of MSG, since not addressing MIME headers is a hole that we need to cover.
Comments are most welcome.

Regards,
-Suresh

-----Original Message-----
From: James M Galvin [mailto:galvin@drummondgroup.com]
Sent: Wednesday, October 31, 2001 9:08 PM
To: Christopher Ferris
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] security problem with ebXML MS



On Wed, 31 Oct 2001, Christopher Ferris wrote:
    
    Transient security mechanisms (on-the-wire confidentiality,
    integrity and authentication) by means of technologies such as
    SSL, TLS or IPSEC can be used as countermeasures for MITM
    attacks, especially when combined with the persistent mechanisms
    described.

SSL and TLS are transport level mechanisms suitable for protecting
against MITM attacks in a peer-to-peer environment.  IPSec is a network
level mechanism that may or may not satisfy transport security
requirements depending on how cognizant the transport level is of the
network level activities.  In particular, IPSec would typically be
deployed firewall to firewall, which may or may not be the endpoints of
the transport layer connection.  There's a lot of if's in there for an
application.

In any case, ebMS is intended to be transport independent.  Thus, while
the transport and below mechanisms may be suitable for non-persistent
services they are unsuitable *in general* in the persistent case.  The
architecture document to which you referred makes this clear.

  SIDEBAR: It turns out that "persistent security" is never actually
  defined anywhere that I can find (not even in the architecture
  document).  Since non-persistent makes specific reference to transport
  level services, I made the obvious inference that persistent means
  "survives end-to-end", i.e., between trading partners.  It would be
  interesting, I think, to understand if others have a different
  understanding, or perhaps I've overlooked the definition.

Specifically, if SMTP is used as the transport, the persistent services
do not adequately protect against MITM attacks.

    Because certain portions of the message are meant to be mutable
    it is not possible to apply a persistent signature over the entire
stream
    unless it is known that the message will never (need to) be changed.
    If intermediaries are not involved, then it is possible to ensure
    message integrity by means of transient mechanisms between
    the two adjacent nodes providing an assurance that the message
    has not been tampered by a MITM.

You seem to be suggesting that if the communication path between the
trading partners is not peer-to-peer, it must be assumed that the
message will probably need to be changed while in transit?  Do you mean
this in general or are you referring specifically to the various "trace"
information that might appear in a message?

If the latter, the fact that certain portions of the message are mutable
is irrelevant to the requirement to properly make use of the security
service to achieve the desired goal.  If the desired goal is persistent
authentication, then the MIME headers must be protected while
in-transit.  In the SMTP transport case this means the headers must be
protected at each hop along the path.

The fact that certain portions of the message are mutable *is* relevant
to how the digital signature is calculated and what is included when the
message is encrypted.  But that is an implementation detail one level
past the issue of agreeing to achieve the desired goal.

Do we agree on the goal?

Jim


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

ebXML ProcessingModelv0x3.pdf