FW: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN

All:

After consulting with Sandia Management, I have voted “No” for the CAP 1.2 committee specification. The reasons follow:

First, Sandia presented during the IPAWS program the reasons for creating a true publish/subscribe capability for public alert and warning. This meant both individuals (e.g. subscription services) and jurisdictions (city, county, tribal) could select the levels of information they wanted to receive via various communications media. This implied a decoupling of the Alert Publisher and the Alert Consumer (e.g. SOA loose coupling). It also implied a significant number of redistribution capabilities managed by both Federal and Commercial entities. During discussions with FCC, the issue of non-repudiation and liability for distribution of misleading or spoofed Alerts was emphasized.

These concerns implied a design which was well suited for using the OASIS EDXL-DE distribution capability. Yesterday, I arranged a technical discussion with Gary Ham and Rex Brooks to explain some of my concerns with the current schema for CAP 1.2. There has always been the capability to “wrap” CAP 1.0 or CAP 1.1 with any appropriate wrapping metadata (e.g. OASIS EDXL-DE, W3C XML signature or encryption techniques etc.). The real question was about the infrastructure to interpret the wrapping metadata (we have a subcommittee dedicated to this).

Here are some of the issues I presented to Gary and Rex. The Emergency Management Technical Committee years ago realized the need for a publish/subscribe capability for distribution. They also realized the need for confidentiality and non-repudiation of critical information exchanges. I reminded them of the reason we created the keyXMLContent element tag. If there was Law Enforcement (e.g. Radiation detections) or Health Sensitive (e.g. HAVE messages) content being distributed, the distribution/re-distribution infrastructure might need selected information from within the embeddedXMLContent elements about the “Intent” of the distribution in addition to information extracted from embedded content and included in other EDXL-DE tags. It states:

· Extracts must come from the XML document contained within the <embeddedXMLContent> element within the current <contentObject> block.

· All content within this element MUST be explicitly namespaced as defined in the enclosing <contentObject> tag.

· MUST be a properly formed -escaped if necessary- XML string.

Since disclosure control is about only exposing “readable” information to appropriately vetted consumers, there was a need to not only encrypt the data but ensure the recipient was “authorized” to receive the decryption capability to read the information. This could only be accomplished with PKI or symmetric key technologies and additional distribution infrastructure (e.g. TSG and SPORs). This has significant impacts on the distribution/redistribution capabilities. Gary and Rex cautioned me not to go into technical details but I would be glad to provide selected individuals the reasons why both symmetric and PKI encryption are bad ideas for distributing CAP messages without appropriate wrapping metadata and supporting infrastructure. CAP 1.2 encrypted content could also break OASIS EDXL-DE infrastructure designed to “automatically” wrap time sensitive distribution like the TSG/SPOR network used by DNDO. There are many other reasons.

There is also a misconception about digital signatures and non-repudiation. It is true that a digital signature can detect the tampering of a message after it has routed through various distribution technologies. However as we have be documenting in the OASIS SOA Reference Architecture Framework documentation, non-repudiation requires Authenticity of delivered message, Proof of intent of message, and Authority of sender to request this intent in a point-to-point transaction and if it uses in a loosely coupled SOA publish/subscribe distribution capability there must also be a “Trust” anchor and transmission of trust through the routing infrastructure. Digital Signature can only provide authenticity of delivered message. The CAP Alert structure provides some proof of intent which can be strengthen by usage profiles. But there is no mechanism for determining that the “Social Structure” has authorized the transmission of CAP alert. The OASIS EDXL-DE schema has and SenderRole element but even this must be used with other technologies to bind it with authenticity and proof of its authority from the Jurisdiction in the distributed EDXL-DE message. This is the reason I don’t even like the signing of CAP 1.2 Alert messages because people assert this provides non-repudiation of the transmitted message. I do not believe this could successfully proven in a court of law. This could also create potential liabilities for the distribution/redistribution capabilities if they had some implied non-repudiation responsibilities.

Please understand that Sandia is only trying to be an honest broker for development of “international” standards per the OASIS charter. We are not trying to block need Emergency Management capability.

Dave

From: Gary Ham [mailto:gham@grandpaham.com]
Sent: Thursday, February 11, 2010 7:22 AM
To: Gary Ham
Cc: emergency@lists.oasis-open.org; Bryan Field; Mark Lucero; Dean Rychlik; ARTHUR C III CTR DISA JITC BOTTERELL; Roderick [USA] [USA] Cash; Neil C Bourgeois
Subject: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN

A clarification on the below tool issues:

Neil and I have been dealing with issues related to the implementation of CAP 1.2 in DM-OPEN 2.0 using the <any> tag and Oracle 10g SOA Suite. They are workable and probably OBE with the next implementation of the Oracle 11g SOA Suite.

The point is that they are tool issues. We will work it out.

On Feb 11, 2010, at 9:09 AM, Gary Ham wrote:

Folks,

As you may or may not know we had some discussions concerning implementation difficulties with CAP 1.2. For the most part those issues are tool-related and can be dealt with (although the work level is still TBD). Encryption is, however, a different matter and would be very hard to do in a CAP 1.2 environment. Bottom line is this, we support CAP 1.2, but we will not be handling encrypted traffic on the CAP interfaces. The essential story follow:

Here is a message I drafted for all of you to review, but sent to for vetting to Art Botterell and Mark Lucero (IPAWS):

Neil and I have been dealing with issues related to the implementation of CAP 1.2 in DM-OPEN 2.0 using the <any> tag. They are workable and probably OBE with the next implementation of the Oracle SOA Suite. So, the initial DM-OPEN 2.0 will be CAP 1.1 with CAP 1.2 to be part of the first fully IPAWS capable follow-on release. In looking at the <any> issue I came across what might be a bigger worry down the line. If you choose to encrypt the content of the CAP message in a CAP only network, every node on the network that the CAP message can be sent to (or through as in network to network traffic) must be able to decrypt the message in order to read it or to get the needed information to pass it on. At the number of network nodes grow in a network of networks, key management will become an NP hard problem, growing at an exponential rate. This my be the reason so little encryption of CAP 1.1 messages has occurred. My point is that encryption of CAP 1.2 in a CAP only network will be extremely hard to manage. Signatures can be handled. Encryption; not so well. Your thoughts are welcome.

Art's response:

But what's the requirement for encryption in a public warning system?

Encryption tends to get confused with authentication because of the Web 1.0 practice of using passwords (or certificates) to authenticate sessions or connections, and then assuming that anything arriving over the trusted link must itself be authentic.

In that case encryption is required to protect the integrity of that individual link, whether or not there's any requirement for privacy of the actual communication. (And of course any compromise at either end of the link means the whole game's over.)

By applying authentication to the individual messages, rather than to the links, the question of encryption becomes orthagonal to that of authentication. Each message is provably authentic or not, regardless of how it arrived or where it's been. And encryption can be evaluated separately and on its own merits.

Bottom line, I think the reason there's been so little encryption of CAP alerts is that there's been no particular requirement to keep the contents of public warnings secret.

Mark Lucero's response:

You're correct, Art. IPAWS requirements are: Low Confidentiality, High
Integrity, High Availability. We don't want to encrypt anything, we
only want to ensure the message has not been altered (high integrity).
This infers the need for digital signatures, but there's no need to
encrypt anything.

My Bottom line:

Since we will not be encrypting or accepting encrypted CAP on the DM-OPEN CAP Interfaces, we can make CAP1.2 work in its other capacities for public warning. If you do need to transport an encrypted CAP message, you can use the DM-OPEN DE interface with an encrypted CAP payload, but the recipient systems will have to know how to know how to retrieve DE messages from DM-OPEN and decrypt them on their end.

Respectfully,

Gary Ham
Systems Architect
FEMA Disaster Management Program
703-899-6241

Gary Ham

http://grandpaham.com

703-899-6241

emergency message