John
You are way off base with the claims in your post and you are entering areas of discussion which are not appropropriate for this forum. You make claims which you cannot explain or otherwise support without delving into topics which encroach on classified information or at least on information covered by the ITAR. As with your previous posts, you speak in vague unsupported terms and you are not, in my opinion contributing to the activity in a positive way. ________________________________ From: Davidson, John A. [[email protected]] Sent: Monday, September 19, 2011 12:26 PM To: CICM Discussion List Subject: Re: [cicm] Use Cases Jim, All gov. secret type MLS Mode systems are a composition of single level domains. Whether or not the domains are implemented as HW domains is a distinction that makes no difference. The radio as a system would still operate in MLS Mode. I concede a lot of connotations and expectations to the contrary, but those lead to contradictions. While I don’t advocate silence on this, I think it would be better for CICM to be silent than wrong in such a harmful way. Furthermore, I don’t see how radios can even come close to any reasonable notion of “Independent” domains, I see that as a myth, the domains aren’t really independent at all, they are managed by a common control plane that interacts with both domains. They are independent except for the yada-yada. I have seen this notion that so-called “MSLS” can avoid high assurance MLS Mode be devastating. I am concerned about CICM validating or promulgating that notion; it is unsound. This is not just me, I have never seen a DAA that would buy that notion of “independent” domains across a system, our DAA does not, and evaluates such JTRS radios as MLS per the Computer Security / Intermediate Value Theorem. Check out who the authors of that link were. All MLS operating systems that have been approved (A1) were based on hardware enforcement, even though they have hypervisors. They separate domains by specialized HW circuits under the hypervisors. Don’t we still “call” them MLS, exemplifying a consistency between connotations and theory. (Note: MLS Mode is distinct from “MLS” as a capability.) Independent HW domains is two laptops sitting on a desk with no connectivity between them at all. Taken together, as a system, they still operate in MLS mode. John From: [email protected] [mailto:[email protected]] On Behalf Of Cottrell Jr., James R. Sent: Monday, September 19, 2011 8:00 AM To: CICM Discussion List Subject: Re: [cicm] Use Cases John, While a gov.secret type radio has two security domains, plaintext side containing sensitive/classified and ciphertext side containing usually unclassified (encrypted) information, this isn’t normally MLS because the processing of each domain is performed by independent hardware. Use of a hypervisor to host the plaintext, cryptographic and ciphertext domains would be an example of a MLS implementation. MLS is typically used to describe processing multiple classification levels of information on a single hardware processor, https://secure.wikimedia.org/wikipedia/en/wiki/Multilevel_security The example of a product having a single plaintext port usually would be at a single security level. A single plaintext port could support MLS if the Operating environment servicing the port supports MLS, possibly hypervisors, and the protocols and hardware for the single port support data separation and/or data labeling. The systems feeding/receiving data over the port would have to support this MLS solution. Jim Cottrell From: [email protected] [mailto:[email protected]] On Behalf Of Davidson, John A. Sent: Monday, September 19, 2011 12:03 AM To: [email protected] Subject: Re: [cicm] Use Cases Lev wrote, > FYI: By adding this use case, I'm not saying that CICM needs to support > Multiple Levels of Security (MLS) and/or Multiple Independent Levels of > Security (MILS), but I am saying we shouldn't do anything to prevent someone > from using it those configurations, if they so choose. Without a formal definition of High Assurance, I use the customary connotation that it enforces a policy with near certainty, for cases where gov. secrets are being protected (by gov directive). When we have a radio that handles gov classified traffic, it is necessarily MLS mode, (MILS is a subset of MLS) and should enforce a policy for non-disclosure of classified and use high assurance mechanisms. There is no other requirement I know of for high assurance. The radio must have unclassified IF/RF processes (e.g. modem) and it must have classified processes (e.g. baseband user interfaces). Even a single level classified radio will necessarily operate in MLS mode as a system. …and needs Hema’s containers. So, I am not sure what realistic configuration of a CICM radio, presumably containing a crypto(?), with an antenna on one connector and a classified userdata port on another connector, does NOT need to support MLS. I guess one is when the userdata has no secrecy properties, but for that do we need a radio with a crypto? Guess I am splitting hairs (and pulling teeth!). Sure, CICM should work for a non-MLS radio, but I don’t understand what purpose it serves to acknowledge it. Is it a political correctness thing? John ----- Original Message ----- From: [email protected] <[email protected]> To: CICM Discussion List <[email protected]> Sent: Sun Sep 18 07:46:36 2011 Subject: Re: [cicm] Use Cases Hema, On 2011-09-14 11:52, Hema Krishnamurthy wrote: > 1. There is mention of MLS in the list below, but have you considered > "containers" for each security level in an MLS system? On 2011-09-14 12:23, John Davidson wrote: > IMHO, the answer to 1. is "not really," because to address this in a sound way > excludes a lot of unsound things that legacy systems are accustomed to doing; > and expect of CICM. On 2011-09-13 15:10, John Fitton wrote: > An API does not and should not determine the underlying security architecture > compliance to security policy. The API should be 100% agnostic to an MLS, > MILS, MSLS or SLS security architecture. I was trying to be very careful with this use case, but I went too far. Recall, that on 2011-09-08 14:14, I wrote: > FYI: By adding this use case, I'm not saying that CICM needs to support > Multiple Levels of Security (MLS) and/or Multiple Independent Levels of > Security (MILS), but I am saying we shouldn't do anything to prevent someone > from using it those configurations, if they so choose. > See http://tools.ietf.org/html/draft-lanz-cicm-lm-01#section-1.4 The point of the use case is to say "CICM should not interfere with systems in which there are multiple levels of security" (but it doesn't do anything to help either). Therefore, I believe that this use cases any and all "container" configurations in which there are multiple security levels. > 2. Key exchange - Is it going to cover all types - IPSec, SSL/TLS/DTLS? The use case is generic--that CICM should support secure key exchange; the analysis will evaluate the feasibility of using those protocols with the CICM model. > 3. How about voice over IP use case? Part of it would fall under the > networking arena, but there would be some specifics pertaining to VoIP - like > support of SRTP. Perhaps I'm misunderstanding something, but is there some fundamental difference between this use case and the regular two-domain use case? > 4. I forget, does CICM support the ability to write down SADs into the crypto > module? Assuming SAD is "Security Association Database", then, no, there aren't currently specific CICM API commands for managing the SAD as an entity unto itself. Creating channels will have effects on the SAD, but CICM doesn't expose that level of detail to the application. Lev _______________________________________________ cicm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
