[CAP] Then Again... (was Re: CAP Security Using DigitalSignatures)
Hannes Tschofenig
Hannes.Tschofenig at gmx.net
Thu Mar 12 13:58:13 PDT 2009
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 at lists.incident.com
>>> [mailto:cap-list-bounces at 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 at 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 at lists.incident.com
>>> [mailto:cap-list-bounces at lists.incident.com] On Behalf Of Rex Brooks
>>> Sent: Thursday, March 12, 2009 3:01 PM
>>> To: matt hoffman; Art Botterell
>>> Cc: cap-list at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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
>
More information about the CAP-list
mailing list