[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)
... >Date: Thu, 12 Mar 2009 13:41:19 -0700 >From: Rex Buddenberg <budden@nps.navy.mil> >To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net> >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) >X-Nonspam: Statistical 55% > >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. >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. > > >(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. >> >> >>>-----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=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. >> >> > >-- >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]