Note, Hannes is replying to Rex Buddenberg, not yours truly.
Cheers.
Rex
>X-Provags-ID: V01U2FsdGVkX1+1EzgeCJG1p6mBDgNCpQ3dOtHBRcM2xYlauwfbpG
> jVj3vWlRxKIqDP
>From: "Hannes Tschofenig" <>
>To: "'Rex Buddenberg'" <>
>Cc: "'David Aylward \(Comcare\)'" <>,
> "'Rex Brooks'" <>,
> "'matt hoffman'" <>,
> "'Art Botterell'" <>,
> <>
>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:
>>>> [mailto:] On Behalf Of David
>>>> Aylward (Comcare)
> >>> Sent: 12 March, 2009 21:17
>>>> To: 'Rex Brooks'; matt hoffman; Art Botterell
>>>> Cc:
>>>> 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:
>>>> [mailto:] On Behalf Of Rex Brooks
>>>> Sent: Thursday, March 12, 2009 3:01 PM
>>>> To: matt hoffman; Art Botterell
>>>> Cc:
>>>> 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
>>>>>
>>>> <> 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
>>>>>>>>
>>>> <>
>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> 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
>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>> 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
>>>>>
>>>>> 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
>>>>
>>>> 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
>>>>
>>>> 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
>>>
>>> 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
