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

[Christopher Ferris <chris.ferris@sun.com>]

It is interesting, and we should put it on the
f2f agenda for discussion, but I have some comments.

This proposal seems to imply that MIME processing/parsing
of the message is limited exclusively to the first body
part of the multipart/related MIME object (the SOAP Envelope)
and that all subsequent processing of the multipart/related
object is driven by the contents of the MIME header info
contained within the Manifest.

No MIME processor/parser of which I am aware works in this
manner. Thus, it would seem that this proposal is suggesting
that in order to process a message, a new parser would be
required. I'm not sure that this is desireable. In addition,
the issue raised suggests that ALL MIME headers, including
those that comprise the multipart/related "envelope" and
those of the start object (the SOAP Envelope) would need
to be protected, or maybe I'm missing something. I don't see
how this proposal addresses the potential that these MIME
headers might also become compromised.

Further, I don't think that it is the responsibility of
the OASIS ebXML Messaging TC to specify MIME header C14N. I would
think that if this s to be done at all that the ownership
and responsibility for this would belong squarely in the IETF camp.

Cheers,

Chris

David Fischer wrote:

> This is very good and we should include it on the F2F agenda.
> 
> Regards,
> 
> David Fischer
> Drummond Group.
> 
> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> 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>
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>