Re: [cicm] Use Cases

"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Wed, 14 September 2011 16:21 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 7CCEE21F8B44 for <cicm@ietfa.amsl.com>; Wed, 14 Sep 2011 09:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.169
X-Spam-Level:
X-Spam-Status: No, score=-3.169 tagged_above=-999 required=5 tests=[AWL=1.130, BAYES_00=-2.599, MANGLED_STOP=2.3, 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 YalnZqIWk6a6 for <cicm@ietfa.amsl.com>; Wed, 14 Sep 2011 09:21:16 -0700 (PDT)
Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6E821F8B26 for <cicm@ietf.org>; Wed, 14 Sep 2011 09:21:16 -0700 (PDT)
Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-11843365 for cicm@ietf.org; Wed, 14 Sep 2011 09:23:09 -0700
X-AuditID: 8b7911db-b7cafae00000407d-10-4e70d4edfab5
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 3F.93.16509.DE4D07E4; Wed, 14 Sep 2011 09:23:09 -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); Wed, 14 Sep 2011 09:23:10 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Sep 2011 09:23:09 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EA1@0461-its-exmb09.us.saic.com>
In-Reply-To: <86150541B533894DAD5CB2DB3F4788521210CA9E9E@CSFWMAIL1.cs.de.ittind.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] Use Cases
Thread-Index: AcxkLTeZAvR3bwFMSYqPf+pySxYTSgCJ2nxAAf+VFWABKMSAwAAA3aww
References: <F9AB58FA72BAE7449E7723791F6993ED0630EDD3B8@IMCMBX3.MITRE.ORG><7EDDD87A9A1D7F4DB6F78BC55AA4955002085E7C@0461-its-exmb09.us.saic.com><F9AB58FA72BAE7449E7723791F6993ED06310632A4@IMCMBX3.MITRE.ORG> <86150541B533894DAD5CB2DB3F4788521210CA9E9E@CSFWMAIL1.cs.de.ittind.com>
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: CICM Discussion List <cicm@ietf.org>
X-OriginalArrivalTime: 14 Sep 2011 16:23:10.0080 (UTC) FILETIME=[97C8A000:01CC72FA]
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: Wed, 14 Sep 2011 16:21:17 -0000

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: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] 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: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] 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
cicm@ietf.org
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
cicm@ietf.org
https://www.ietf.org/mailman/listinfo/cicm