John, On 2011-08-29 10:27, John Davidson wrote: > When you refer to "sides" in #4, it may lead us to model the "red side" > as "considered secure" and the black side as "considered unsecured". > The secure/unsecured view leads us to think that there is something more > than isolation that makes the red domain "secure." That has a "my > machine; my data vs. their stuff" security policy orientation. > There is another orientation that may be more applicable for so-called high > assurance. That is the Their (the gov's) Top Secret, Their Secret and > Their Unclassified, where none of the domains are "considered secure" > from a trustworthy-ness POV.
This is an excellent point. Security domains do not define trust, per se. They are defined by a security policy which specifies, among other things, how data moves into/out of that domain. This is the definition we previously used. For example, see "$ security domain" in http://tools.ietf.org/html/draft-lanz-cicm-lm-01 Therefore, I'm going to add "multiple levels of security domains" to the list of use cases. This should cover a broad list of arrangements including Joe Mitola's use cases (personal data, NDAs, content-based roles). 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 > I mention this because it the link in #4 implies just 2 "sides" and it > implies communication between those "sides" that encourages software to > fail to "stay out of the way" and violate rules by trying to communicate > from red to black with bypass and such. > > While lots of people (HAIPE et al) want to do that, I suggest our models > stop short of encouraging, suggesting or even enabling it because to do > so creates an architecture that we don't know how to secure today. That > is not what we are about. The use cases are intentionally broad because we are trying to build a framework which will facilitate analysis of existing IETF protocols using a domain-centric approach. Certainly, the classic high assurance cases (1, 3) can be used, but we're evaluating the impact on existing approaches. Our current list so far: 1. high assurance data-in-transit (two networks, two domains) 2. traditional data-in-transit or -at-rest (cf. PKCS#11) 3. one network, two domains (cf. network storage; data-in-transit + -at-rest) 4. one machine, two domains in software (via Vincent Roca) 5. secure key exchange (via Kevin Wall) 6. multiple levels of security domains (via John Davidson/Joe Mitola; one or more networks, multiple domains) Any others? Regards, Lev _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
