[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] security problem with ebXML MS
Yes, I am not sure either. Somehow we would have to have something which knows to parse beginning at the boundary down to the first blank line -- leaving out CTE. However, Suresh pointed out that the dSig tools want you to give it the entire ds:Signature element. If we have a foreign ConnonicalizationAlgorithm, is it going to choke? I think these things may be hard coded. I suppose we could recognize the ConnonicalizationAlgorithm value before it goes to the dSig tool and perform the functions at that point. I am not sure how this works. Regards, David. -----Original Message----- From: Christopher Ferris [mailto:chris.ferris@sun.com] Sent: Wednesday, November 07, 2001 1:36 PM To: David Fischer Cc: ebxml-msg@lists.oasis-open.org Subject: Re: [ebxml-msg] security problem with ebXML MS David, This idea should be explored further. The problem I am having is: how do you reference the MIME headers as a URI? I don't think that the same URI (whether cid or content-location URI) can be used... If we can solve that conundrum, then we may have something. Cheers, Chris David Fischer wrote: > I would like to suggest a variation on Suresh's idea. > > What if we add a second Reference in the ds:Signature for 'each' payload so that > there would be two references to the same cid, for each payload. I looked in > the dSig spec and there doesn't seem to be any prohibition on this. > > The first reference would be to the payload as it has always been with whatever > canonicalization or transforms are required. The second reference would be to > the MIME headers. Suresh's canonicalization of the MIME headers would still be > required but we wouldn't have to copy the MIME headers into the Manifest > (minimal change to the spec). We would still have to define that > Canonicalization Algorithm that Suresh described. > > I don't know if this is better or worse but it is another option. > > I'll confess, this is actually Rik's idea but I kind of like it. > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: Christopher Ferris [mailto:chris.ferris@sun.com] > Sent: Wednesday, November 07, 2001 10:03 AM > To: David Fischer > Cc: ebxml-msg@lists.oasis-open.org > Subject: Re: [ebxml-msg] security problem with ebXML MS > > > David, > > Agreed, but even if the "dispatching" was performed from > the Manifest (by some new processor), then there still needs > to be MIME parsing (although possibly not dispatching) to > resolve the attachments. > > What this seems to be suggesting is a whole lot more work > and I'm not convinced that it is really necessary or even > that it solves the problem. > > I wasn't suggesting that there were any changes to the existing > MIME headers, what I was commenting on was the need (for digest > calculation) to specify canonicalization of MIME headers which > is clearly (IMO) outside our scope, responsibility and ownership. > > Cheers, > > Chris > > David Fischer wrote: > > >>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> >> >> >>---------------------------------------------------------------- >>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> > ---------------------------------------------------------------- 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