[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] security problem with ebXML MS
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC