[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
Dave, 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. Digital Signature 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. Relationship of Web Service Security Requirements to Standards 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.
Thanks, Lee 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:dellis@sandia.gov] 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] 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, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]