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

[David Fischer <david@drummondgroup.com>]

Chris,

I didn't take this to mean NOT have MIME headers on the payloads but just to
copy them (Suresh used the word 'Repeat').  This presents two possibilities,
either the ebXML signature verification must compare the signed MIME headers in
the Manifest to the ones on the payloads to make sure they have not changed, OR,
I suppose the ebXML processor could dispatch off of the headers in the Manifest
(except that some headers might not be there - like CTE headers).

I didn't understand this as any change to the existing payload MIME headers.

Regards,

David Fischer
Drummond Group.

-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Wednesday, November 07, 2001 8:57 AM
To: David Fischer
Cc: Ian. C. Jones (E-mail); ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] security problem with ebXML MS


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



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