Re: [cicm] Use Cases

["Fitton, John" <[e-mail]>]

1) The definition of high assurance has absolutely nothing to do with security policy that is being enforced, it is about the measures being taken to enforce whatever the policy requires and the robustness with which the measures are enforced. There is no other "customary connotation".  If  you claim otherwise then provide your sources which substantiate your claim.  Even you refer to "high assurance mechanisms". Please provide your definition of what those are supposed to be and please define what makes them high assurance.  I will also state that there are definitions of what is meant by high assurance, none of which conform to you presumed meaning.



2) Security policy goes way beyond "protecting government secrets" E.g. Financial institutions require high assurance mechanisms that have absolutely nothing to do with protecting government secrets! Their security policy deals with protecting assets (as does the Governments... but the Governments assets are information which may or may not be officially "classified".



3) MILS is definitely not a subset of MLS. In a MILS environment one of the partitions may be MLS all by itself.

MILS is a set of processing environments that are separated by high assurance and trusted mechanisms which ensure the separation of the environments.



4) I think you need to study just what high assurance really means. You view is overly narrow and not consistent.



5) You state the modem must have unclassified IF/RF processes. The modem does not operate in either the IF or RF domain. It provides the input to those domains and processes the information received from those domains. As you should be aware, there are any number of instances (but not all) where the modem code itself is classified. In addition radio modems are parametrically driven engines, and the parameters used to configure and drive those engines are themselves operationally classified until they are used, at which point many are immediately downgraded to unclassified.



6) I can envision many configurations that only require a radio that operates in the SLS mode.  You general supposition that all must be MLS is totally unsupportable.  Such unsupported statements, unfortunately weaken any argument you may put forth. If you want to make such a claim, then provide your supporting rational.



7) You refer to a CICM radio, but the CICM is intended to apply to many situations other than radios defined for use by national military forces.  It is intended to apply to any situation where High Assurance is required. These might be medical records and date, financial data, and any number of other situations.  I f you are concerned with HIgh assurance applications for radios then you might also want to consider those used by state and local law enforcement, or emergency medical services which must transmit extremely sensitive patient information over the air.  The Wireless Innovation Forum has published one document on Security design and architecture guidelines for any type of software based radio, and has just approved an API for Radio Security services to support waveform and application portability across diverse radio platforms. While targeted to those platforms which employ the DoD defined Software Communications Architecture (SCA), there are aspects which could apply to any operating environment.



8) Constructive criticism of a document can be useful, but if you are going to criticize, then at least offer suggested changes with concrete tangible support for your argument.





Unsupported criticism is not useful nor productive.









________________________________
From: Davidson, John A. [[e-mail]]
Sent: Monday, September 19, 2011 12:03 AM
To: [e-mail]
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: [e-mail] <[e-mail]>
To: CICM Discussion List <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/cicm