[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN
-------- Original Message --------
Subject: RE: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN
From: "Lee Tincher" <firstname.lastname@example.org>
Date: Thu, February 11, 2010 1:13 pm
To: "'David E. Ellis'" <email@example.com>,
Cc: "'Oien, Chuck'" <firstname.lastname@example.org>, "'Sanzero, George'"
It seems that this is the age-old discussion on where security should live during message transport. One of our guys (Lew Leinenweber) suggests the following guidelines:
The open standards communities that created Web services developed a number of security standards for web services. Figure 8 illustrates a notional reference model for web services security standards. This reference model maps the various standards to the functional layers of a typical web service implementation. These layers are modeled after the OSI Reference Model but are not intended to be interpreted as strictly hierarchical.
Figure 8 - Web Services Security Standards - Notional Reference Model
Standards at the network, transport and XML security layers are used to secure messages as they are transmitted over the network. The security standards IPsec, SSL/TLS (Secure Sockets Layer/Transport Layer Security), XML Encryption and XML Signature each operate on SOAP messages at a different level.
Above the XML Security layer standards fall into two primary categories: standards that are built on top of SOAP and standalone standards. Message security standards WS-Security and WS‑SecureConversation define how to use XML Signature, XML Encryption and credentials to secure SOAP at the message layer while reliable messaging standards define the protocols and constructs necessary to ensure that messages will be received. The access control standards are not unique to web services; XACML can define the access policy for any system and SAML can be used to define assertions in any environment. At the policy layer, WS-Policy defines a grammar to communicate policy requirements of a web service.
Security management specifications define other Web services to manage credentials such as PKI certificates within the SOA. Identity management standards take advantage of access control standards, policy standards and SOAP standards to offer services for distributing and managing user identities and credentials within the SOA.
The Digital Signature provides message integrity among a service’s exchange partners. Digital signature provides a mechanism for the authentication of messages, allowing a consumer to make certain that a message has not been tampered with during transit.
A digital signature should be applied to the service header and the message body. As the message travels, service requests and responses are signed at each ESB. A digital signature establishes a chain of trust between components and enables non-repudiation and authentication of messages. Digital signatures should be based upon open source and accepted federal standards. Digital signature should be based upon the Web Services Interoperability Organization (WS-I) Basic Security Profile, which provides an interoperable framework for major security standards to effectively work together.
The following standards should be used to implement digital signatures:
• XML Digital Signature (XMLDSig) provide syntax and processing standards.
• Web Services Security (WS-Security) is an XML extension to SOAP which provides a flexible means to employ security measures in messages.
WS-Security with XMLDSig is used to secure basic end-to-end authentication and message integrity while remaining transport independent. By implementing XML digital signatures through WS-Security standards, the message header framework maintains interoperability between components with an added level of audit-ability and security. Used in conjunction with other security measures, such as Secure Socket Layer (SSL), messages can be secured and authenticated.
Table 2-1 shows which security requirements are satisfied by various specifications and standards.
In this table, each security dimension encompasses one or more security requirements. Each requirement may have one or more standards that support it. For example, SSL/TLS and WS-Security provide confidentiality, integrity and authentication support for the messaging dimension. A notable exception is the accountability requirement in the resource protection dimension which does not have any supporting standards.
Dimension Requirement Specifications Messaging Confidentiality and Integrity WS-Security SSL/TLS Authentication WS-Security Tokens SSL/TLS X.509 Certificates Resource Authorization
XACML XrML RBAC, ABAC Privacy
EPAL XACML Accountability None Negotiation Registries UDDI ebXML Semantic Discovery SWSA OWL-S Business Contracts ebXML Trust Establishment WS-Trust XKMS X.509 Trust Proxying SAML WS-Trust Federation WS-Federation Liberty IDFF Shibboleth Security Properties Policy WS-Policy Security Policy WS-SecurityPolicy Availability WS-ReliableMessaging WS-Reliability
Better to write for yourself and have no public, than to write for the public and have no self. - Cyril Connolly
From: David E. Ellis [mailto:email@example.com]
Sent: Thursday, February 11, 2010 10:57 AM
Cc: 'Oien, Chuck'; 'Sanzero, George'
Subject: FW: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN
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.
From: Gary Ham [mailto:firstname.lastname@example.org]
Sent: Thursday, February 11, 2010 7:22 AM
To: Gary Ham
Cc: email@example.com; 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:
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.
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
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.
FEMA Disaster Management Program