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