Subject: Re: [cicm] Use Cases

From: "Davidson, John A." <[email-masked]>
Date: Sun, 18 Sep 2011 21:03:20 -0700

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-masked] <[email-masked]>
To: CICM Discussion List <[email-masked]>
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-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Mon, 19 Sep 2011 11:00:29 -0400

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-masked] [mailto:[email-masked]] On Behalf Of Davidson, John A.
Sent: Monday, September 19, 2011 12:03 AM
To: [email-masked]
Subject: Re: [cicm] Use Cases

Lev wrote,

John

----- Original Message -----
From: [email-masked] <[email-masked]>
To: CICM Discussion List <[email-masked]>
Sent: Sun Sep 18 07:46:36 2011
Subject: Re: [cicm] Use Cases

Hema,

Lev
_______________________________________________
cicm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Davidson, John A." <[email-masked]>
Date: Mon, 19 Sep 2011 09:26:07 -0700

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-masked] [mailto:[email-masked]] 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,

Jim Cottrell

Lev wrote,

John

----- Original Message -----
From: [email-masked] <[email-masked]>
To: CICM Discussion List <[email-masked]>
Sent: Sun Sep 18 07:46:36 2011
Subject: Re: [cicm] Use Cases

Hema,

Lev

---

From: "Fitton, John" <[email-masked]>
Date: Tue, 20 Sep 2011 03:56:49 +0000

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. [[email-masked]]
Sent: Monday, September 19, 2011 12:03 AM
To: [email-masked]
Subject: Re: [cicm] Use Cases

Lev wrote,

John

----- Original Message -----
From: [email-masked] <[email-masked]>
To: CICM Discussion List <[email-masked]>
Sent: Sun Sep 18 07:46:36 2011
Subject: Re: [cicm] Use Cases

Hema,

Lev

---

From: "Fitton, John" <[email-masked]>
Date: Tue, 20 Sep 2011 04:04:46 +0000

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-masked]]
Sent: Monday, September 19, 2011 12:26 PM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

Jim,

John,

Jim Cottrell

Lev wrote,

John

----- Original Message -----
From: [email-masked] <[email-masked]>
To: CICM Discussion List <[email-masked]>
Sent: Sun Sep 18 07:46:36 2011
Subject: Re: [cicm] Use Cases

Hema,

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 20 Sep 2011 08:49:30 -0700

John Fitton wrote
"...if you are going to criticize, then at least offer suggested changes
with concrete tangible support for your argument."  

OK.  One change I could suggest is to divide the APIs into two sets, a
High Assurance Consistency subset that supports high assurance that we
have technology to implement and a second Extensions set of extensions.
The problem with this would be it would divide users into 2 groups,
Group 1 who would be certain they cannot make their radio work without
the extensions, and a Group 2 who will.  Group 2 will use their
engineering skills to stay out of the way of the enforcement mechanisms.
Group 1 would be free to use the extensions, but it would use their
engineering skills to find a way to somehow secure the extensions to the
satisfaction of their approver.  As a practical matter, approvers have
varying backgrounds and some will be harder to convince than others.  (I
have tried to get a real DAA to contribute to our group.)  

If there is interest in discussing the details of this (and thats beyond
the scope of this email) I think we would eventually conclude that the
subset High Assurance Consistency subset would, as a practical matter,
boil down to that set of APIs that does not seek to violate the Bell La
Padula (BLP) policy (no objects flow up in classification level).
Mainly, it would exclude the crypto bypass APIs.  The rationale is that
that is the widest policy our present COMPUSEC technology can enforce
with HA, although there are lots of kinds of policies.  

In theory, high assurance (HA) could be required for any policy, but as
a practical matter, we only know how to enforce one special narrow
component of Secrecy Policy, BLP with HA.  (Its implementation would end
up involving a HW mechanism.)  Security Policies are made up of
components, and as a practical matter, HA is linked to this component of
the policy, if the policy has that component.  We simply do not know how
to apply HA to banking policies or website policies and others.
Consequently practical HA only applies to that one component.  

There are issues with the interface between the crypto and the modem
TRANSEC that need to be addressed separately that may also need to be in
a separate subset.  I am not convinced that one API approach fits all
implementation approaches here.  Suggestions to address can be addressed
in another email if there is interest in doing any of this.  

John

---

From: "Fitton, John" <[email-masked]>
Date: Tue, 20 Sep 2011 21:26:18 +0000

I see a claim of yours that there is not technology available to support high assurance. That is your opinion, one which I and others disagree. I have not see you offer any support for your assertions and I do not believe that you can in this forum. Any such discussionsn would most assuredly violate ITAR. 

My claim is supported by many official US Government agency certifications of  equipments approved to the highest security criteria and classifications with which I was associated. 

Flaws in the Bell La Padula model, which is a MODEL, not a POLICY, were recognized shortly after it was published. Furthermore BLP is only appropriate as an Access Control model, and nothing else. There is considerable literature available to support this view. It was defined in an era when there were many user terminals attempting to access information in classified data bases. These computer systems were isolated and not connected to anythiing except their peripherals. As such it is outmoded. 

I reject your unsupported assertion  about only knowing how to enforce one BLP model as would many who have been involved in protecting our national assets. 

You also have made the same assertions about bypass on many occasions. I do not accept these unsupported asssertions, AND as we have discussed before this is not the forum for that discussion. 

I am not aware of any issues between the crypto and the modem as you state. If you believe there are issues that effect the API then you should bring the specifics forward so they can be discussed. 

John
Again your statements are broad and totally without support.

________________________________________
From: Davidson, John A. [[email-masked]]
Sent: Tuesd ay, September 20, 2011 11:49 AM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

John Fitton wrote

John