[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: RE: [CAP] Then Again... (was Re: CAP Security UsingDigitalSignatures)
Note, Hannes is replying to Rex Buddenberg, not yours truly. Cheers. Rex >X-Provags-ID: V01U2FsdGVkX1+1EzgeCJG1p6mBDgNCpQ3dOtHBRcM2xYlauwfbpG > jVj3vWlRxKIqDP >From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> >To: "'Rex Buddenberg'" <budden@nps.navy.mil> >Cc: "'David Aylward \(Comcare\)'" <daylward@comcare.org>, > "'Rex Brooks'" <rexb@starbourne.com>, > "'matt hoffman'" <matthoffman@acm.org>, > "'Art Botterell'" <acb@incident.com>, > <cap-list@lists.incident.com> >Subject: RE: [CAP] Then Again... (was Re: CAP Security Using > DigitalSignatures) >Date: Thu, 12 Mar 2009 22:58:13 +0200 >Thread-Index: AcmjUtCmXHnBFgsDRcWpI0c40NfxEwAAOLGQ >X-Y-GMX-Trusted: 0 >X-FuHaFi: 0.53 >X-Nonspam: Statistical 62% > >Hi Rex, > >Thanks for your quick response. > >>Hannes, >> >>You have most of the points of concern. >> >>Hannes Tschofenig wrote: >>> Identity Management is the fuzzy term. >>> >> >>There's a well-worn quartet of end-end security features: >> >> 1. authenticity >> 2. integrity >> 3. confidentiality >> 4. non-repudiation >> >>The digital signature function provides for the first two. >>(if you add a receipt system you can then realize >>non-repudiation, but it requires authenticity as a foundation). >>> All you need is a Public Key Infrastructure. >>The digital signature leaves the signed data untouched. But >>once you get the PKI properly provisioned to do the digital >>signature process, you can also apply encryption for no >>additional infrastructure cost. > >Most of the early warning architectures I have seen would have a lot of >problems with encryption on an end-to-end basis as you source of the warning >does not necessarily know the recipients. Additionally, I am not sure you >are actually protecting against realistic threats. > > >> >>Central point: these are protections applied to the data. >>They tell you nothing about the infrastructure and they derive >>no security value from the infrastructure. And that >>orthogonality is exactly what we need here. > >The problem so far with end-to-end public key crypto was not the technical >mechanism itself but with the infrastructure you need to get it to work. >I am trying to figure out whether there is a plan for that. > >> >> >>(I agree that identity management is a fuzzy term and it comes >>with a lot of other baggage, so I don't use it) >>> In the mentioned end-to-end use >>> case as a recipient of alerts you need to have a way to verify the >>> digital signature. Therefore, you need to have common trust anchor. >>> Where do you get that from? Use it from the trust anchors >>you have in your browser? >>> >>> What does it mean if you have authenticated the message >>sender? Would >>> this tell the user a lot? >>> >>Absolutely. If you've ever been knee-deep in a large sized >>disaster and watched the rumor mill multiply, then you'll know >>that authenticity of the sender is an extremely valuable and >>informative feature. >>> If you cannot verify the signature do dump the message? >>> >>If you receive the message but it won't verify (because, >>perhaps, a hiccup in the PKI), you still have the data. >>That's no worse than life today. The receiver then needs to >>make a judgement call about the authenticity of the message. >> >>Art's central point is that you can no longer infer >>authenticity from the comms pipes -- both the Bad Guys and the >>rumormongers are on the same internet that the rest of us are >>using. He's absolutely right. > >I guess someone has to describe the architecture that you have in mind. >I have recently written a few "strawman" architecture proposals, see Section >3 of http://tinyurl.com/al9yoh > >My guess is that folks haven't uses XML digital signatures with CAP because >in their early warning architecture the threats do not justify the >complexity. > >Ciao >Hannes > >>> >>> >>>> -----Original Message----- >>>> From: cap-list-bounces@lists.incident.com >>>> [mailto:cap-list-bounces@lists.incident.com] On Behalf Of David >>>> Aylward (Comcare) > >>> Sent: 12 March, 2009 21:17 >>>> To: 'Rex Brooks'; matt hoffman; Art Botterell >>>> Cc: cap-list@lists.incident.com >>>> Subject: Re: [CAP] Then Again... (was Re: CAP Security Using >>>> DigitalSignatures) >>>> >>>> It is indeed a very significant issue. Thanks to Art for > >raising it, >>>> and to Rex for expanding the scope. >>>> >>>> I think what has been raised is end to end identity >>management, which >>>> is a central problem across the emergency/safety >>eco-system, for lots >>>> of use cases, and is closely related to access control (the >>right to >>>> send or receive certain messages, and assignment of identities). >>>> >>>> CAP is an important use case, but only one of those that need these >>>> related capabilities. And it is an important standard, but >>only one >>>> of those that need these. >>>> >>>> As Art correctly points out, the nature of emergency >>interoperability >>>> is a wide variety of emergency messages, going across multiple >>>> networks/applications which may or may not be secure. And it is "n" >>>> originators, sending messages to "n" recipients. Because >>of this we >>>> in COMCARE came to the conclusion reached by a lot of folks that we >>>> need federated, standardized solutions for these needs. >>Rather than >>>> the ad hoc, use-centric approach that has been used to date. >>>> >>>> I hope as you address the particular needs of CAP, you will do so >>>> with this broader set of needs in mind. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: cap-list-bounces@lists.incident.com >>>> [mailto:cap-list-bounces@lists.incident.com] On Behalf Of Rex Brooks >>>> Sent: Thursday, March 12, 2009 3:01 PM >>>> To: matt hoffman; Art Botterell >>>> Cc: cap-list@lists.incident.com >>>> Subject: Re: [CAP] Then Again... (was Re: CAP Security Using Digital >>>> Signatures) >>>> >>>> Just wanted to let you all know that I have forwarded this >>thread to >>>> the Messages and Notification Subcommittee of the OASIS EM >>TC because >>>> I think it is significant, and I wanted them to be aware of the >>>> conversation. >>>> >>>> Thanks, >>>> Rex >>>> >>>> At 2:46 PM -0400 3/12/09, matt hoffman wrote: >>>> >>>>> Sorry, didn't see this post before replying to the other. >>>>> Whether we specify it or not (and, it could be that >>canonicalization >>>>> standards have reached a point that we no longer need to >>-- I don't >>>>> want to be too hopeful, but it is certainly possible) there are >>>>> certainly performance benefits in forwarding the message as you >>>>> received it, if there were no local changes. >>>>> At least, in my implementation experiences. Saves one >>serialization >>>>> step, and one set of possible compatibility issues. >>>>> >>>>> Now, whether we want to mandate sign-the-blob... I agree >>that, from >>>>> a signature point of view, it simplifies things considerably >>>>> >>>> (or seems to >>>> >>>>> -- >>>>> >>>> I >>>> >>>>> haven't tried it with the Java toolkits, but it makes >>sense that it >>>>> would work as you're suggesting). But other implementers >>>>> >>>> might want to >>>> >>>>> speak up there about the feasibility of ALWAYS passing >>>>> >>>> exactly what they received if >>>> >>>>> there is a digital signature included. That's mandating >>a particular >>>>> implementation step that might not be trivial for all users. >>>>> >>>>> >>>>> >>>>> On Thu, Mar 12, 2009 at 12:08 PM, Art Botterell >>>>> >>>> <acb@incident.com> wrote: >>>> >>>>>> Thinking about it a bit more... am I mistaken, or wouldn't >>>>>> >>>> a simple >>>> >>>>>> way >>>>>> >>>> to >>>> >>>>>> implement a "sign the blob" approach be just to use a "null" >>>>>> canonicalization in otherwise-normal XMLSIG? >>>>>> >>>>>> As I understand it, the reason for C14N is to deal with >>variations >>>>>> in whitespace, attribute order and such that can occur >>when XML is >>>>>> parsed >>>>>> >>>> and >>>> >>>>>> then re-serialized. So we try to factor out every >>possible change >>>>>> that might occur in those processes... with, it appears, >>>>>> >>>> limited success. >>>> >>>>>> But to simply forward/publish someone else's CAP alert, > >seems like >>>>>> >>>> passing >>>> >>>>>> it along precisely, byte-for-byte, would be relatively >>>>>> >>>> simple... and >>>> >>>>>> (as >>>>>> >>>> the >>>> >>>>>> Gutmann paper points out) much more auditable. Of course that > >>>>> wouldn't prevent any node from parsing the alert and >>acting on the >>>>>> basis of the contents. It would only mean that if that >>>>>> >>>> node decides >>>> >>>>>> to pass the >>>>>> >>>> alert to >>>> >>>>>> other nodes, it must give them the precise version it received. >>>>>> >>>>>> In other words, if C14N is murky bathwater, maybe we could >>>>>> >>>> dispense >>>> >>>>>> with >>>>>> >>>> it >>>> >>>>>> without needing to toss the baby too. All we'd need would be a >>>>>> clarification in the OASIS spec (and an implementers' >>>>>> >>>> convention till >>>> then) >>>> >>>>>> that canonicalization SHALL NOT be applied during signing. >>>>>> >>>> (And to >>>> >>>>>> fix >>>>>> >>>> the >>>> >>>>>> schema, of course.) >>>>>> >>>>>> Or am I missing something here? >>>>>> >>>>>> - Art >>>>>> >>>>>> >>>>>> On Mar 12, 2009, at 3/12/09 8:32 AM, Art Botterell wrote: >>>>>> >>>>>> Interesting link, Matt. Sounds like an object lesson on why we >>>>>> should >>>>>> >>>>>>> resist the temptation to standardize what we don't yet >>understand. >>>>>>> >>>>>>> I was thinking we might wind up proposing an erratum to >>OASIS to >>>>>>> fix >>>>>>> >>>> the >>>> >>>>>>> schema issue, but hadn't appreciated that cannonicalization was >>>>>>> still proving so intractable. Although that article is >>>>>>> >>> >from 2004, >>> >>>>>>> I take it >>>>>>> >>>> the >>>> >>>>>>> C14N situation hasn't improved. So maybe it would make >>>>>>> >>>> more sense >>>> >>>>>>> to >>>>>>> identify (and demonstrate!) alternate approaches that >>>>>>> >>>> could be fed >>>> >>>>>>> back into >>>>>>> the standard. >>>>>>> >>>>>>> My concern is that if we don't address the end-to-end signature >>>>>>> problem >>>>>>> >>>> as >>>> >>>>>>> a community there might not be a business incentive for any >>>>>>> particular implementer to design for that level of >>>>>>> interoperability. And while >>>>>>> >>>> the >>>> >>>>> >> OASIS process usually does a good job of refining and >>ratifying >>>>> contributed >>>>> >>>>>>> designs, it seems not to be as effective as a framework for >>>>>>> developing those designs in the first place. >>>>>>> >>>>>>> - Art >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mar 12, 2009, at 3/12/09 5:59 AM, matt hoffman wrote: >>>>>>> >>>>>>> I did a proof-of-concept implementation of this on a previous >>>>>>> DHS >>>>>>> >>>> system. >>>> >>>>>>>> Although, as you say, there was no way of verifying it >>>>>>>> >>>> with other >>>> >>>>>>>> providers >>>>>>>> >>>>> >>> or consumers at the time. >>>>> >>>>>>>> However, a couple of points that I recall: >>>>>>>> >>>>>>>> a.) The document mentions that the signature element can be a >>>>>>>> child of "alert", but unless I'm mistaken it is not >>>>>>>> >>>> specified in the schema. >>>> So >>>> >>>>>>>> messages containing signatures fail schema validation >>>>>>>> >>>> ... I had to >>>> >>>>>>>> explicitly add it to the schema. >>>>>>>> >>>>>>>> b.) The signatures are delicate, and tricky: >>>>>>>> http://www.cs.auckland.ac.nz/~pgut001/pubs/xmlsec.txt >>>>>>>> >>>>>>>> Unfortunately I no longer have access to that code, but I'd be >>>>>>>> happy >>>>>>>> >>>> to >>>> >>>>>>>> help others if they're looking into it. >>>>>>>> >>>>>>>> >>>>>>>> - matt >>>>>>>> >>>>>>>> On Wed, Mar 11, 2009 at 11:20 PM, Art Botterell >>>>>>>> >>>> <acb@incident.com> >>>> >>>>>>>> wrote: >>>>>>>> Friends - >>>>>>>> >>>>>>>> We're moving rapidly toward an important threshold in CAP >>>>>>>> implementations. So far, most CAP-based systems have been >>>>>>>> >>>> self-contained, >>>> >>>>>>>> single vendor/implementer arrangements. But soon >>we're going to > >>>>>>> need >>>>>>>> >>>> to >>>> >>>>>>>> "federate" CAP traffic among multiple interoperable >>>>>>>> >>>> systems. And >>>> >>>>>>>> that >>>>>>>> > >>> has >>>> >>>>>>>> important implications for security. >>>>>>>> >>>>>>>> Most current systems use a trusted-link/trusted-host >>>>>>>> >>>> mode based on >>>> >>>>>>>> encrypted network links and password access control at a central >>>>>>>> >>>> server. >>>> >>>>>>>> That's a familiar Web 1.0 approach and it works fine >>>>>>>> >>>> for "single-hop" >>>> >>>>>>>> implementations. But it has a major drawback: As soon >>>>>>>> >>>> as messages >>>> >>>>>>>> are forwarded from one server to another, a security >>compromise >>>>>>>> anywhere >>>>>>>> >>>> can >>>> >>>>>>>> compromise the authentication and integrity of all CAP >>messages >>>>>>>> downstream. >>>>>>>> >>>>>>>> The alternative, of course, is to apply digital signatures to >>>>>>>> CAP messages at their origin, and to verify them at >>>>>>>> >>>> receiving points. >>>> >>>>>>>> That way, >>>>>>>> it doesn't matter if the links or intervening nodes are >>>>>>>> >>>> secure or >>>> >>>>>>>> not; >>>>>>>> >>>> any >>>> >>>>>>>> recipient can verify independently that the message is >>>>>>>> >>>> a) from who >>>> >>>>>>>> it >>>>>>>> >>>> says >>>> >>>>>>>> it's from, and b) hasn't been modified in transit. >>>>>>>> >>>>>>>> There's a standard way of doing this for XML, as cited in the >>>>>>>> CAP >>>>>>>> Specification: >>>>>>>> >>>>>>>> >3.3.2.1 Digital Signatures >>>>>>>> >The alert element of a CAP Alert Message MAY have an >>Enveloped >>>>>>>> Signature, as described by XML Signature and >Syntax >>Processing >>>>>>>> [XMLSIG]. Other XML signature mechanisms MUST NOT >>>>>>>> >>>> be >>>> >>>>>>>> used in CAP Alert Messages. Processors >MUST NOT >>reject a CAP >>>>>>>> Alert Message containing such a signature >>>>>>>> >>>> simply >>>> >>>>>>>> because they are not capable of verifying >it; they >>>>>>>> >>>> MUST continue >>>> >>>>>>>> processing and MAY inform the user of their failure to >>validate >>>>>>>> the signature. >>>>>>>> >>>>>>>> But I'm not aware of anyone that's implemented it yet... partly >>>>>>>> >>>> because >>>> >>>>>>>> it hasn't been necessary in stand-alone systems, and partly >>>>>>>> because it involves a type of programming a lot of >>folks haven't >>>>>>>> had occasion to explore yet. >>>>>>>> >>>>>>>> But ultimately, it's going to be essential for >>>>>>>> >>>> interoperability. >>>> >>>>>>>> So >>>>>>>> >>>> I'd >>>> >>>>>>>> be interested in hearing, has anyone implemented XMLSIG >>>>>>>> >>>> on CAP yet? >>>> And >>>> >>>>>>>> would anyone be interested in doing some interoperability >>>>>>>> experiments? The standard is there, the technology is >>there (in >>>>>>>> Java and a number of >>>>>>>> >>>> other >>>> >>>>>>>> languages) and I see the requirement bearing down on >>us quickly. >>>>>>>> >>>>>>>> What say? >>>>>>>> >>>>>>>> - Art >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> This list is for public discussion of the Common >>>>>>>> >>>> Alerting Protocol. >>>> This >>>> >>>>>>>> list is NOT part of the formal record of the OASIS Emergency >>>>>>>> Management TC. >>>>>>>> Comments for the OASIS record should be posted using the form >>>>>>>> at >>>>>>>> >>>>>>>> >>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbre >>>> v=emergency >>>> >>>>>>>> CAP-list mailing list >>>>>>>> CAP-list@lists.incident.com >>>>>>>> http://lists.incident.com/mailman/listinfo/cap-list >>>>>>>> >>>>>>>> This list is not for announcements, advertising or >>>>>>>> >>>> advocacy of any >>>> >>>>> >>> particular program or product other than the CAP itself. >>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> This list is for public discussion of the Common Alerting > >>>>>> >>>> Protocol. >>>> This >>>> >>>>>>> list is NOT part of the formal record of the OASIS Emergency > >>>>>> Management >>>>>>> >>>> TC. >>>> >>>>>>> Comments for the OASIS record should be posted using >>the form at >>>>>>> >>>>>>> >>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbre >>>> v=emergency >>>> >>>>> >> CAP-list mailing list >>>>> >>>>>>> CAP-list@lists.incident.com >>>>>>> http://lists.incident.com/mailman/listinfo/cap-list >>>>>>> >>>>>>> This list is not for announcements, advertising or >>>>>>> >>>> advocacy of any >>>> >>>>>>> particular program or product other than the CAP itself. >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> This list is for public discussion of the Common >>Alerting Protocol. >>>>>> >>>> This >>>> >>>>>> list is NOT part of the formal record of the OASIS Emergency >>>>>> Management >>>>>> >>>> TC. >>>> >>>>>> Comments for the OASIS record should be posted using the form at >>>>>> >>>>>> >>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbre >>>> v=emergency >>>> >>>>>> CAP-list mailing list >>>>>> CAP-list@lists.incident.com >>>>>> http://lists.incident.com/mailman/listinfo/cap-list >>>>>> >>>>>> This list is not for announcements, advertising or >>>>>> >>>> advocacy of any >>>> >>>>>> particular program or product other than the CAP itself. >>>>>> >>>>>> >>>>> -------------- next part -------------- An HTML attachment was >>>>> scrubbed... >>>>> URL: >>>>> <http://lists.incident.com/pipermail/cap-list/attachments/2009 >>>>> >>>> 0312/2990 >>>> >>>>> 9d94 >>>>> >>>> /attachment.htm> >>>> >>>>> _______________________________________________ >>>>> This list is for public discussion of the Common Alerting >>Protocol. >>>>> This list is NOT part of the formal record of the OASIS Emergency >>>>> Management TC. Comments for the OASIS record should be >>posted using >>>>> the form at >>>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbr >>>>> >>>> ev=emerge >>>> >>>>> ncy >>>>> CAP-list mailing list >>>>> CAP-list@lists.incident.com >>>>> http://lists.incident.com/mailman/listinfo/cap-list >>>>> >>>>> This list is not for announcements, advertising or advocacy of any >>>>> particular program or product other than the CAP itself. >>>>> >>>> -- >>>> Rex Brooks >>>> President, CEO >>>> Starbourne Communications Design >>>> GeoAddress: 1361-A Addison >>>> Berkeley, CA 94702 >>>> Tel: 510-898-0670 >>>> _______________________________________________ >>>> This list is for public discussion of the Common Alerting >>Protocol. >>>> This list is NOT part of the formal record of the OASIS Emergency >>>> Management TC. >>>> Comments for the OASIS record should be posted using the form at >>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbre >>>> v=emergency >>>> CAP-list mailing list >>>> CAP-list@lists.incident.com >>>> http://lists.incident.com/mailman/listinfo/cap-list >>>> >>>> This list is not for announcements, advertising or advocacy of any >>>> particular program or product other than the CAP itself. >>>> >>>> >>>> >>>> _______________________________________________ >>>> This list is for public discussion of the Common Alerting >>Protocol. >>>> This list is NOT part of the formal record of the OASIS Emergency >>>> Management TC. Comments for the OASIS record should be >>posted using >>>> the form at >>>> http://www.oasis-open.org/committees/comments/form.php?wg_abbre >>>> v=emergency >>>> CAP-list mailing list >>>> CAP-list@lists.incident.com >>>> http://lists.incident.com/mailman/listinfo/cap-list >>>> >>>> This list is not for announcements, advertising or advocacy of any >>>> particular program or product other than the CAP itself. >>>> >>>> >>> >>> _______________________________________________ >>> This list is for public discussion of the Common Alerting Protocol. >>> This list is NOT part of the formal record of the OASIS Emergency >>> Management TC. Comments for the OASIS record should be posted using >>> the form at >>> >>http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=emerg > >> ency > >> CAP-list mailing list >>> CAP-list@lists.incident.com >>> http://lists.incident.com/mailman/listinfo/cap-list >>> >>> This list is not for announcements, advertising or advocacy >>of any particular program or product other than the CAP itself. >>> >>> >> >>-- >>Rex Buddenberg >>Senior Lecturer >>Naval Postgraduate School >>Monterey, Ca 93943 >>831/656-3576 >> -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]