This may be a case for just leaving out the "high assurance" (HA) part. Our APIs support that so-called "necessary evil" bypass which (from my distorted COMPUSEC background POV) technically contradicts HA. (From my background, HA originally implied cross domain flow but only in the down direction.) Despite what *any* APIs may aspire to do, an MLS HA OE can impose rigorous HA on any kind of APIs. However, if it does, that can break some applications that expect use APIs that enable prohibited flow (down.)
As originally applied to COMPUSEC, HA loosely referred to mechanisms intended to *absolutely* enforce a particular policy and separate hierarchical security levels (as mathematical "lattices") underneath software systems. As the line between software and cryptos blurs, HA has migrated into crypto lingo, but it doesn't seem to fit well when cryptos (and SDRs) are approached as HW wires and components rather than software. In my opinion, there are two approaches to IA in a complex system of systems, like a SDR. One is the classical HA COMPUSEC approach that precludes flow up and allows flow down. I realize this is contentious, but I can only say this has a long history of working fine in MLS processing environments without needing bypass. The other approach is the way we did hardware (HW) cryptos, which allows bypass provided it is "not harmful" (epitomized by header bypass). There are technical IA issues with doing the latter with HA because it allows flow down and we lack a rigorous HA criteria for "not harmful." That is why bypass is termed "evil" in the phrase "necessary evil." I think that while a SDR contains a crypto, it is more of a generic software MLS application than a crypto with wires and components. To me, supporting HA means supporting the approach above that does not require crypto bypass, like we used in Blacker, an MLS software FEP. It still moved unclassified header to the unclassified processes, but by a COMPUSEC scheme of isolating flow at the source instead of trying to inspect bypass object content downstream. Our APIs allow either. Since our APIs do support bypass, it is up to the users not to try to use it if they expect to run in a conventional HA OE. I know everyone wants to call everything HA, (myself included) but to me, allowing HA is not exactly "supporting" everybody's view of HA, it just blurs the line between "best effort" and HA. Isn't our API more about being generic and allowing the user to make design choices between best effort and rigorous HA? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Fitton, John Sent: Tuesday, May 17, 2011 5:15 AM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 I agree that the API does not provide "high assurance" nor does it "offers security domain separation" as stated in the draft Charter. How about stating it like this: "The API is intended to support high assurance cryptography by allowing for security domain separation and includes provisions for enhanced module, key and channel management capabilities that are vendor agnostic." The fact that there is an API is what allows for security domain separation. While an API in and of itself cannot be "high assurance", it is possible to define security policy concerning its application and use that would enable a high assurance implementation. A question then arises, is should the API include a section which includes API related security policies which support high assurance applications. ________________________________________ From: Cottrell Jr., James R. [[email protected]] Sent: Monday, May 16, 2011 1:08 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 Dennis, I agree that the API by itself cannot provide "high assurance" but this API has been designed to be targeted for use in high assurance applications. Not sure how to work this thought into your suggested charter wording. Jim C. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bourget, Dennis Sent: Friday, May 13, 2011 6:12 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 I just don't see how any API can provide "high assurance", it is the implementation of the API, host platform and operating system that would need to be evaluated to FIPS 140-2 or Common Criteria. For example, the API does not and cannot provide domain separation, I suggest that we strike that text from the charter. Perhaps the following: The Common Interface to Cryptographic Modules (CICM) API defines a "standardized" application interface for the security services provided by cryptographic modules developed by multiple vendors. The API supports security domain separation, and enhanced module, key, and channel management capabilities that is vendor agnostic. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Fitton, John Sent: Friday, May 13, 2011 2:56 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 I would suggest defining High Assurance in terms of FIPS-140-2 Level 4. Of course FIPS 140-2 refers to the Common Criteria AL4 or higher, but does offer specific criteria to be used in the evaluation. That being said, however, while the stated goal is for a high assurance API, there is nothing in principal which limits the API to high assurance applications. I would also point out that the Orange Book (as was the entire original Rainbow series) was targeted at information processing systems. These systems were essentially large data bases with many users gaining access via dedicated terminals, and there are those who would argue that the old assurance levels, were also not that well defined. As these system evolved and internet access was introdouced there was additional volumes created to address some of the security issues involved. I would argue that nothing in the Rainbow series specifically addressed security requirements or assurance levels for cryptographic modules. One advantage of the Common Criteria, is that the meaning of any given Assurance Level for a given application (e.g. a Cryptographic module) can be defined through an evaluation profile. Another advantage is that it is an internationally recognized set of criteria with a group of international evaluation/certification bodies. ________________________________________ From: Davidson, John A. [[email protected]] Sent: Friday, May 13, 2011 1:34 PM To: CICM Discussion List Subject: Re: [cicm] BoF Request for CICM at IETF 81 Lev, I am wondering if we need to (or even can) clarify what we mean by High Assurance. Assurance levels were fairly well-defined under the Orange Book but that has been grayed out by the move to international flavored Common Criteria. Today when we say we are addressing HA, it is no longer clear to me whether we mean to restrict our view to approaches that are logically "closed form," or if we mean just a better version of "best effort," whatever that is. In my mind, there are IA critical capabilities we can support with one that may be ruled out by the other. Thanks, John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Novikov, Lev Sent: Friday, May 13, 2011 10:01 AM To: [email protected] Cc: CICM Discussion List ([email protected]) Subject: [cicm] BoF Request for CICM at IETF 81 I'm formally requesting a BoF at IETF 81 to form a CICM WG based on the draft charter below. Updated version at: http://code.google.com/p/ietf-cicm/wiki/WGCharter Discussion also at: [email protected] Thanks, Lev Draft CICM Working Group Charter = Description of Working Group = The Common Interface to Cryptographic Modules (CICM) API provides high assurance crypto applications with a security framework that accommodates the needs of a high assurance environment including security domain separation, and enhanced module, key, and channel management capabilities. The purpose of the CICM Working Group is to shepherd the CICM specification documents to publication and provide guidance for any new submissions related to high assurance cryptos. Specifically, the Working Group will: * Complete existing requests: * replace algorithm strings with OIDs * use ABNF notation for unique identifiers syntax * add module events for symmetric and asymmetric key filled * Shepard the following documents to publication: * draft-lanz-cicm * draft-lanz-cicm-lm * draft-lanz-cicm-mm * draft-lanz-cicm-km * draft-lanz-cicm-cm = Goals and Milestones = TBD WGLC on draft-lanz-cicm-lm TBD WGLC on draft-lanz-cicm TBD WGLC on draft-lanz-cicm-mm TBD WGLC on draft-lanz-cicm-km TBD Submit draft-lanz-cicm to the IESG as Proposed Standard _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
