[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
Hi David, I'm including the TC in this reply, so it will get into everyone's inbox. Everyone: the comments David refers to are in my reply to his earlier message (entire thread below for the record). I will be looking at ebMS. Can't say how it will fit till I do. Cheers, Rex David RR Webber (XML) wrote: > Rex, > Looks like you only sent this to me? Please cc list if that was an > oversight! > WRT complexity - yes, yes, and yes! > Obviously the CAM work I'm doing is focused on reducing complexity of > doing NIEM xsd. > Likewise I was trying to get a REST initiative going for regrep. We > have the subcommittee and charter done - just need folks to show up > and complete the work ; -) > Having a REST interface saves you from the gory details of ebRIM - and > makes the whole thing much easier to implement. > Everyone is grappling with the same set of challenges in ensuring > robust message exchanges with extended deliver control and routing. > The ebMS work has always provided for that - and now with V3 - I'm > seeing this mature from real world experience in implementations - and > actually having real use case needs. Always a good sign. It may not be > completely simple - but at least everything in one place and API. > Having the grapple with multiple XML layers in a stack to achieve the > same thing is always likely to be more challenging. > > Thanks, DW > > -------- Original Message -------- > Subject: Re: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN > From: Rex Brooks <rexb@starbourne.com> > Date: Fri, February 12, 2010 8:52 am > To: "David RR Webber (XML)" <david@drrw.info> > > I've been working with Dave in a lot in crossover work that spans the > SOA Reference Architecture Foundation work in the SOA RM TC that just > concluded its second 60-Day Public Review and the Reference > Information > Model SC work in this TC that is driving out requirements from Use > Cases > for the ValueListURN that is core of the EDXL-DE, especially looking > toward the 2.0 work that is poised to get underway in our > Infrastructure > Framework SC. > > So I have an inside-out view on this. I've supported much of the > ebXML > work, especially the ebXML Registry and Registry-Repository work, and > included that as part of the reuseable SOA that also specifies the > latest versions of CAP and EDXL-DE in the All Hazards Alerts and > Warnings (AHAW) Capability Pattern I'm working through the > Net-Centric > Operations Industry Consortium (NCOIC). > > So, obviously, I support using existing standards rather than > "reinventing" any wheels. However, having said that, and > acknowledging > that I'll have to look at ebMS 3, I think the work we've done in the > ValueListURN in RIM that will be included in the EDXL-DE 2.0 > specification, (and perhaps others) is critical to actually providing > the basis for a sane approach to creating the kind of trust network > through a workable SOA that we actually need. > > Without getting into details about on-going work, the reason for this > relates to an issue I brought up in the EDXL-SitReps work in the > Philadelphia F2F, namely complexity. (See Lee's post for an example). > > I'm not asking for a dialong (pun intended) on this topic. I ask > everyone to study and research it on your own, but my experience in > attempting to implement ebXMLRR resulted in abandoning complete > adoption > and only adopting a bare minimum of features necessary because the > complexity presented a barrier way too high to explain to an audience > being asked to financially support the registry under development. > The > ultimate result was that we stalled and our best assets had to go > back > to corporate work. > > We now have other drivers, including the AHAW Pattern, that require > registries, so I expect that we'll just struggle through getting > the eb > XML Registry Information Model (anothert RIM) understood and > accepted, > but it will necessarily require explaining only the most essential > components, and I honestly don't look forward to it. In fact, this is > something that will need to be done for the AHAW Technical Pattern. > > Gary's mention of NP Hard Problems in the CAP encryption problem > represents the computational aspect of complexity, while what I > brought > up was the procedural aspect with regard to deciding how many and > which > kinds of Sit Reps (as well as how many and which data fields in > the Sit > Reps) need to be included in the spec to make decision making > easier (in > essence taking as much complexity contained within unstructured data > (text) out of the decision-maker's way and providing as many > summarized > facts (in structured data) as needed. > > Our last previous effort in dealing with complexity was EDXL-RM > that is > criticized for being too complex even though that complexity is > largely > due to the number of components one sees at first glance rather > than an > understanding for how those components fit together in patterns > repeated > in each separate message. In retrospect it might have been wiser > to have > a main spec with all the common components and separate mini-specs > for > the individual messages, but that's just conjecture. > > This is tough work, folks, and I don't see any easy answers. In fact, > its our job to make answers easier to find. > > Cheers, > Rex > > David RR Webber (XML) wrote: > > Dave, > > I understand the issues you raise. I've long heard these same > concerns > > and needs discussed on the ebXML messaging work. > > The ebMS v3.0 has new features that are specifically designed to > > support sophisticated message handling and routing and trust issues. > > Perhaps this is something we could direct to that committee for > > insights given the use cases you mention. > > Also - I believe we do need to decouple transport from packaging and > > content WRT specification standards. > > Obviously CAP does not need to reinvent the wheel here. > > Perhaps one way forward here is to have suggested transport and > > delivery profiles. I know other standards groups work has used that > > very successfully. > > Therefore you could have profiles for using WS* stack, and then > ebXML > > - and then implementers could select what profile meets their needs. > > BTW - the new ebMS v3 also has significantly improved ability to > > deliver via WS* channels (obviously where these are solely end > points > > only and not routing channels). > > Lastly - I want to say I appreciate you raising this all - because I > > attended a present by FEMA the other week - and was concerned that > > these aspects were not being covered - and especially malicious or > > runaway scenarios - such as those that crippled the power grid in > > times past. > > We know these things can occur - and therefore we should take > > necessary precautions to safe guard infrastructure accordingly. > > > > Thanks, DW > > > > -------- Original Message -------- > > Subject: RE: [emergency] Re: CAP 1.2, Encryption, and DM-OPEN > > From: "Lee Tincher" <ltincher@evotecinc.com> > > Date: Thu, February 11, 2010 1:13 pm > > To: "'David E. Ellis'" <dellis@sandia.gov>, > > <emergency@lists.oasis-open.org> > > Cc: "'Oien, Chuck'" <ctoien@sandia.gov>, "'Sanzero, George'" > > <gsanzer@sandia.gov> > > > > 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./ > > > > /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/ > > > > / / > > > > Thanks, > > Lee > > > > /Better to write for yourself and have no public, than to write > > for the public and have no self. - /*Cyril Connolly > > <http://www.quotationspage.com/quotes/Cyril_Connolly/>*// > > > > *From:* David E. Ellis [mailto:dellis@sandia.gov > <http://email.secureserver.net/#Compose>] > > *Sent:* Thursday, February 11, 2010 10:57 AM > > *To:* emergency@lists.oasis-open.org > > *Cc:* 'Oien, Chuck'; 'Sanzero, George' > > *Subject:* 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 > <http://email.secureserver.net/#Compose>] > > *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 <http://grandpaham.com/> > <http://grandpaham.com/> > > 703-899-6241 > > > > -- > Rex Brooks > President, CEO > Starbourne Communications Design > GeoAddress: 1361-A Addison > Berkeley, CA 94702 > Tel: 510-898-0670 > -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]