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: 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.


-----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

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

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
    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?


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

ebXML SignatureProcessing0x2.pdf

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

Powered by eList eXpress LLC