Hema, 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. Consequently, considering it would be divisive and alienate a large constituency. I have been struggling with how to do this in a way that accommodates both views.
John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Krishnamurthy, Hema - ES Sent: Wednesday, September 14, 2011 8:52 AM To: CICM Discussion List Subject: Re: [cicm] Use Cases Lev, My 2 cents on the use cases: 1. There is mention of MLS in the list below, but have you considered "containers" for each security level in an MLS system? 2. Key exchange - Is it going to cover all types - IPSec, SSL/TLS/DTLS? 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. 4. I forget, does CICM support the ability to write down SADs into the crypto module? Hema -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Novikov, Lev Sent: Thursday, September 08, 2011 11:14 AM To: CICM Discussion List Subject: Re: [cicm] Use Cases 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 This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list [email protected] https://www.ietf.org/mailman/listinfo/cicm
