Subject: Re: [atoca] New Version Notification for draft-barnes-atoca-escape-01.txt

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Sep 2012 23:43:21 -0400

Dear ATOCA,

In order to respond to the chairs' call for candidate alert format documents, we have put together a revision of draft-barnes-atoca-escape.  As you may recall from earlier versions, ESCAPE uses S/MIME to wrap a CAP document, in order to add authentication for alert originators (digital signature and "alert token").  

The changes from -00 are largely to add more explanatory text, and clarify a few things technically. We haven't translated the whole thing to JOSE (yet).  Mostly, our hope is that in reading the new version, you'll be able to envision how these secure alerts can be used to build an overall alerting system.  For example, they highlight some of the things that a discover / metadata protocol might need to provide (e.g., public keys for authorities).

Comments very welcome.  There's even a list of open questions at the front!

Thanks a lot,
--Richard

On Sep 10, 2012, at 11:38 PM, [email-masked] wrote:

> 
> A new version of I-D, draft-barnes-atoca-escape-01.txt
> has been successfully submitted by Richard Barnes and posted to the
> IETF repository.
> 
> Filename:	 draft-barnes-atoca-escape
> Revision:	 01
> Title:		 Encoding of Secure Common Alert Protocol Entities (ESCAPE)
> Creation date:	 2012-09-11
> WG ID:		 Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-barnes-atoca-escape-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-barnes-atoca-escape
> Htmlized:        http://tools.ietf.org/html/draft-barnes-atoca-escape-01
> Diff:            http://www.ietf.org/rfcdiff?url2=draft-barnes-atoca-escape-01
> 
> Abstract:
>   Recipients of emergency alerts need to be able to verify that an
>   alert they receive was issued by an authorized source.  The Common
>   Alerting Protocol (CAP) provides a standard way of encoding alert
>   information, but does not provide any security features that would
>   support authentication of alert originators.  This document describes
>   a security wrapper for Common Alerting Protocol objects to allow
>   alerts to be signed by alert originators.
> 
>   Please send feedback to the [email-masked] mailing list.
> 
> 
> 
> 
> The IETF Secretariat
>

---

From: Art Botterell <[email-masked]>
Date: Mon, 10 Sep 2012 22:20:13 -0700

Hi Richard -

I'm confused by the claim that CAP "does not provide any security features that would support authentication of alert originators."  

Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The <alert> element of a CAP Alert Message MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing," and makes reference to both <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ > and <http://www.ietf.org/rfc/rfc3275.txt>.  

Indeed, XMLSIG has been a feature of every CAP version since 1.0.  And if that's not enough, there's also the existing OASIS EDXL-DE wrapper specification.

So while I'm a huge supporter of an end-to-end approach to CAP authentication, on the face of it the ESCAPE draft seems duplicative and somewhat ill-informed.  Also I fear I'm missing the point of the added "alert token" mechanism, other than to add one more maintenance task that nobody is going to want to own.

But possibly you've just leapt ahead too far for me to follow in a single bound.  What am I missing here?

- Art

On Sep 10, 2012, at 8:43 PM, Richard Barnes wrote:

> _______________________________________________
> atoca mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/atoca

---

From: Martin Thomson <[email-masked]>
Date: Tue, 11 Sep 2012 10:01:42 -0700

Art,

It is generally accepted wisdom (in the IETF at least) that XML DSig
[RFC3275] is a recipe for interoperability failure.  The primary
reason for this is the dependency on XML canonicalization.

I'd be interested in hearing a different perspective.  I've used the
apache library to implement an enveloped signature and it wasn't
straightforward.  I'm not aware of any other implementation, but it's
been a few years since I last looked.

Of course, it's a different thing to say the mechanism is broken or
unusable rather than "there is no mechanism".  The former statement
requires greater justification.

I'll let Richard explain the token mechanism.  It's an optimization.

--Martin

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Sep 2012 14:11:59 -0400

I have reviewed this draft and have the following comments:

Overall, I think this is a helpful part in solving a large problem.  I do look forward to hearing any fallout from the discussion Art started on XML DSig, as I was unaware that there were interoperability issues with it.

The mechanism of using S/MIME, and the text describing how it is used seems clear to me.  I'm a fan of re-use, and despite the lack of support for S/MIME in some protocols that specified its use, I think here it is used appropriately and intelligently to produce an interoperable way.  I will have to go look at RFC5751to make sure we don't have any possible holes on preparing the CAP message for this process.  I get worried about trivial things like whether there must be a trailing line end at the end of the CAP message or not.

I am less enthused about the token mechanism.  There are a couple of reasons I think we need more discussion.  Let me say up front that the notion of having a trivial reject mechanism that avoids a DDoS by crypto of bad messages is a good one, so I'm more interested in finding solutions that allow us to have something like this token than in dropping it.

Forcing the alert sender to be the token inserter means there is no opportunity to have any form of transitive trust on message originators.  Using the example in the draft, a recipient would need a token list from what I expect would be a dozen U.S. federal agencies to cover what we would generically describe as a "national alert".  There is no way to have a single "U.S. Government aggregator" that could avoid this.

The token hashes have to be securely delivered to each endpoint by each originator.  This seems to me to be pretty onerous.  Clearly every endpoint has the same list of token hashes, which makes this tractable, but it does seem like a lot of mechanism will be needed to deploy.

This seems like a problem that has been solved.  What this feels like is a one time password, where the encrypt key and the decrypt keys are different.  Rather than a hash, can we really just securely pass the decrypt keys around?  Still need a hash for message integrity, but…  Maybe I'm dreaming.

I don't understand the notion (in 3.4) of allowing tokens with no signatures.  

I don't understand the notion (in 4.1) of a list of tokens.  At first, I thought that you start with a list, but choose one.  Alas, it says create a header for each of the tokens in the list.  What is that doing?

If you allow an intermediary to sign, wouldn't you want to include a token?  Would we not get back to the problem the token solves without that?  But, really, why would an intermediary sign? What would that get us?  In the past, when we have talked about intermediaries signing, it was part of a transitive trust model.  The tokens break that model.  So, if we have tokens, what is an intermediary signature used for?

Finally, I was reminded, looking at the example, why we need an area affected mechanism in some form of wrapper -- the CAP one is not processable by automatons and we need to have successive filtering on area affected to make the distribution mechanisms work.  That got me thinking of whether that, and possibly also other wrapper data needed to be protected, and thus how would it affect this mechanism.

Brian

---

From: Art Botterell <[email-masked]>
Date: Tue, 11 Sep 2012 12:36:04 -0700

Hi Martin -

Not sure how one might implement digital signatures of XML without canonicalization, really, but if that "accepted wisdom" is correct, wouldn't that better be addressed by refinement or replacement of RFC3275 rather than vectoring off into development of a "splinter" specification?

I do observe that all the various implementers of IPAWS-compatible systems in the US have had to implement XML signatures and seem to have managed without undue difficulty.  Perhaps the available libraries have improved.

And I'm not clear on what it is that tokens would optimize, but hopefully Richard can explain that.

- Art

---

From: Brian Rosen <[email-masked]>
Date: Tue, 11 Sep 2012 16:22:23 -0400

Art

I think I can explain it.

Verifying a digital signature that uses public key crypto is expensive.  A convenient DoS attack on a client would be to forge a set of alerts that are just nonsense, but appear to be valid.  The client has to check the signature to discover that it's bad, using lots of cycles to do that.

The token provides a short cut to checking the signature that uses far fewer cycles.   Both ends have the token hash.  The sender includes the token value, which prior to sending it, was known only to the sender.  The recipient runs the hash algorithm on the value to see if it matches one of the hashes it knows.  The tokens are one time use, so a replay is not possible.

The token scheme is not foolproof because an attacker might be able to forge a token value that matches the hash (it could know all the hashes, since it might be a recipient too). Thus, you use the hash test to do trivial discard, and then if you have something that the token check says is valid, then you do the real public key signature check to make sure it's valid.

Brian

---

From: Art Botterell <[email-masked]>
Date: Tue, 11 Sep 2012 13:42:41 -0700

Thanks, Brian, that's helpful.  Sounds like it might require a bit of infrastructure to pre-distribute the hashes... is this actually the most efficient way to defend against DDoS attacks involving digital signatures?

If so, I'm thinking CAP alerts might not be the most likely or even the most critical place where this mechanism might be needed.  Isn't this a general vulnerability of any system that uses signatures?  

If so, might a defensive mechanism be worth developing on its own, as an extension or adjunct to RFC3275, rather than associating it narrowly with a particular application?

- Art

---

From: Andrew Chi <[email-masked]>
Date: Wed, 12 Sep 2012 11:27:01 -0400

> The token scheme is not foolproof because an attacker might be able to forge a token value that matches the hash (it could know all the hashes, since it might be a recipient too). Thus, you use the…

Slight fix to this statement: forging a token value won't happen since 
that requires computing a pre-image to a cryptographic hash function. 
What *could* happen is that an active MITM could intercept a message 
that already contains a legitimate token, and modify the body while 
leaving the token.  So IMO we still need a signature.

---

From: Andrew Chi <[email-masked]>
Date: Wed, 12 Sep 2012 11:41:43 -0400

On 9/11/2012 2:11 PM, Brian Rosen wrote:
> I am less enthused about the token mechanism... What this feels like is a one time password

Yep, I agree with Brian that the token system needs some work, both in 
terms of distribution as well as figuring out what to do with 
intermediaries (perhaps they don't participate in the token system?).

Distribution might be made a little simpler by using a system akin to 
Leslie Lamport's One-Time-Password (OTP) scheme (RFC2289) where each 
successive token is the hash-preimage of the previous token.  This would 
enable recipients to store only a single hash per originator (i.e. 
government agency).

-Andrew

---

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Sep 2012 10:02:48 -0700

> Not sure how one might implement digital signatures of XML without canonicalization, really, but if that "accepted wisdom" is correct, wouldn't that better be addressed by refinement or replacement…

That's precisely the problem.  I can digitally sign a serialization of
XML relatively trivially, but to truly sign the XML then you need to
canonicalize the content.  JOSE are dealing with signing in a
completely different fashion for this exact reason: they only deal
with the serialization.  That simplifies implementation greatly.

> I do observe that all the various implementers of IPAWS-compatible systems in the US have had to implement XML signatures and seem to have managed without undue difficulty.  Perhaps the available l…

Perhaps they have.  Though I note that it's a different matter to
implement this sort of canonicalization in millions of devices with a
wide range of capabilities.  Last I checked, XML canonicalization
libraries weren't small either.

> And I'm not clear on what it is that tokens would optimize, but hopefully Richard can explain that.

Checking a signature is expensive.  Proving that you have access to
the pre-image for a prearranged hash allows clients to filter out
bogus alerts quickly.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2012 14:29:56 -0400

Hey Art,

I apologize for that line.  I had forgotten about the use of XML-DSig in CAP, probably because, as Martin notes, it's broadly viewed in the IETF as not very interoperable.

In general, it seems like we have a choice to make as to what security container we want to specify here:
-- XML-DSig
-- S/MIME / CMS
-- JOSE

We (the authors) chose to go with S/MIME because in our view it was simpler to implement than XML-DSig and more mature than JOSE.  As Martin noted, the simplicity compared to XML-DSig is largely due to the fact that S/MIME just signs the serialized octets, so that the signing layer doesn't need any knowledge of XML.  In the long run, I think JOSE is probably the way to go, because it's likely to be even easier to implement than S/MIME, but that's still developing.

Could you provide any data on how much actual implementation / usage of XML-DSig with CAP?  

Thanks,
--Richard

On Sep 11, 2012, at 1:20 AM, Art Botterell wrote:

> Section 3.3.4.1 of the OASIS CAP 1.2 specification says "The <alert> element of a CAP Alert Message MAY have an Enveloped Signature, as described by XML-Signature and Syntax Processing," and makes reference to both <http://www.w3.org/TR/2002/REC-xmlDSig-core-20020212/ > and <http://www.ietf.org/rfc/rfc3275.txt>.  
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2012 14:32:02 -0400

Hi Art,

Could you say more about how IPAWS uses XML signature?  

It does seem like compatibility with IPAWS (and similar systems elsewhere) might be a desirable feature for the overall ATOCA framework.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2012 14:45:13 -0400

Keep in mind that even for full public-key signatures, there are things to be pre-distributed.  Namely, you need to know which public keys correspond to trusted signers -- what's the public key for FEMA?  This can be partly addressed with PKI concepts, i.e., by distributing a CA certificate under which authority certificates are issued.  But there's still a process of pre-distributing some public keys.  Plus, as Andrew pointed out, using the One Time Password scheme from RFC 2289 would mean that an endpoint would only need to store one hash value per signer. 

--Richard

---

From: Brian Rosen <[email-masked]>
Date: Wed, 12 Sep 2012 15:05:38 -0400

I don't think you can use any of the OTP schemes that rely on either a sequence (usually time based) or a challenge.   Sequence doesn't work because there isn't a good way to maintain sync with zillions of recipients.  Challenge doesn't work because we can't have the client challenge the server for scalability reasons.

PKI does need some pre-distribution, but it's also hierarchical, so we don't need ALL the keys - if we trust a root, we only need to pre-distribute the root cert.  We can also use transitive trust.

Brian

---

From: Richard Barnes <[email-masked]>
Date: Wed, 12 Sep 2012 15:26:55 -0400

When Andrew first pointed me to RFC 2289, I had the same reaction.  But you actually don't need everyone to get the message in order for it to be useful.  Suppose we have a hash chain 

secret, h(secret), h^2(secret), ..., h^(n-1)(secret), h^n(secret) = public

The thing that gets published is h^n(secret) (along with n).  The authority has to use the tokens in sequence (h^(n-1), then h^(n-2), ...), because once a token is public, so are all of the ones after it.  

Clients don't have any dependency on the sequence.  Whenever a client receives a candidate hash, he hashes it until he gets the public value (up to n times).  So if the authority uses h^(n-2), a client will hash it twice to get h^n, even if it hasn't seen h^(n-1).  

Actually, clients can *benefit* from the sequencing: Since the next token used will before a published token in the sequence, the client just needs to cache the earliest token he's seen. 

--Richard

---

From: Art Botterell <[email-masked]>
Date: Wed, 12 Sep 2012 21:31:57 -0700

Hi Richard / All -

Again it sounds like we might be trying to address a general problem with end-to-end authentication... or perhaps with XML... that's in no way particular to the alerting domain.  A worthy undertaking, so far as I can tell, but is this really the best venue for it?

Re your questions about IPAWS, all providers of software compatible with IPAWS, CMAS and/or EAS in the U.S. have had to demonstrate their products' ability to apply or verify signed XML CAP messages.  The list of IPAWS-certified vendors ran to several dozen last time I looked.  And since each IPAWS message must be signed I infer that FEMA has bought-or-built a PKI to support the thousands or tens-of-thousands of potential IPAWS, although I haven't looked into the details lately.

Another system recently deployed by the UN Development Program in the Caribbean also uses signed-XML CAP, so implementation of the existing standard isn't limited to IPAWS or the US.

- Art

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 17 Sep 2012 20:29:47 +0000

I agree with Martin's and Richard's sentiments on this.  The vast majority of XML or XML-like implementations I am aware of cannot properly verify or generate XML canonicalization.  I also have concern of transporting XMLDSig things over transports that look an awful lot like XML, and the potential for incompatibility because of the lack of XML canonicalization support.

In my opinion, using a serialized method such as ESCAPE would mitigate most of that concern.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.