[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] security problem with ebXML MS
C14N for XML applies only to XML. You can digest anything you want and you can define whatever C14N mechanism you like for arbitrary content types. The problem with MIME is that its fragments haven't a content type per se and you cannot (easily) address them with a URI. You *could* use an xpointer which addressed characters, but that becomes difficult when you consider that the offsets to the characters you want to reference will be mutable. Cheers, Chris David Fischer wrote: > 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