Re: [cicm] Use Cases

"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Mon, 19 September 2011 04:01 UTC

Return-Path: <JOHN.A.DAVIDSON@saic.com>
X-Original-To: cicm@ietfa.amsl.com
Delivered-To: cicm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865AA21F8B5C for <cicm@ietfa.amsl.com>; Sun, 18 Sep 2011 21:01:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.507
X-Spam-Level:
X-Spam-Status: No, score=-4.507 tagged_above=-999 required=5 tests=[AWL=2.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClWoXuFFoWaf for <cicm@ietfa.amsl.com>; Sun, 18 Sep 2011 21:01:04 -0700 (PDT)
Received: from cpmx.mail.saic.com (cpmx.mail.saic.com [139.121.17.160]) by ietfa.amsl.com (Postfix) with ESMTP id 973D121F8B5B for <cicm@ietf.org>; Sun, 18 Sep 2011 21:01:04 -0700 (PDT)
Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx.mail.saic.com with ESMTP id BT-MMP-13001314 for cicm@ietf.org; Sun, 18 Sep 2011 21:03:20 -0700
X-AuditID: 8b7911db-b7cafae00000407d-f9-4e76bf083379
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg02.saic.com (Symantec Brightmail Gateway) with SMTP id CF.7B.16509.80FB67E4; Sun, 18 Sep 2011 21:03:20 -0700 (PDT)
Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Sep 2011 21:03:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7681.1171075D"
Date: Sun, 18 Sep 2011 21:03:20 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EAF@0461-its-exmb09.us.saic.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] Use Cases
Thread-Index: AQHMcxOyMfztYf1AaEmg6voOoaqlbpVNmD16gAWk+ACAAN7GdA==
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: cicm@ietf.org
X-OriginalArrivalTime: 19 Sep 2011 04:03:20.0894 (UTC) FILETIME=[11D51DE0:01CC7681]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [cicm] Use Cases
X-BeenThere: cicm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: CICM Discussion List <cicm@ietf.org>
List-Id: CICM Discussion List <cicm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cicm>, <mailto:cicm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cicm>
List-Post: <mailto:cicm@ietf.org>
List-Help: <mailto:cicm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cicm>, <mailto:cicm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 04:01:05 -0000

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: cicm-bounces@ietf.org <cicm-bounces@ietf.org>
To: CICM Discussion List <cicm@ietf.org>
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
cicm@ietf.org
https://www.ietf.org/mailman/listinfo/cicm