Re: [cicm] Use Cases

"Fitton, John" <jfitton@harris.com> Tue, 20 September 2011 21:24 UTC

Return-Path: <prvs=0244a4b822=jfitton@harris.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 650061F0C80 for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 14:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.116
X-Spam-Level:
X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599]
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 KD3CN3iV+Era for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 14:24:19 -0700 (PDT)
Received: from mlbefw2.harris.com (mlbefw2.harris.com [192.52.233.80]) by ietfa.amsl.com (Postfix) with ESMTP id C80131F0C67 for <cicm@ietf.org>; Tue, 20 Sep 2011 14:24:18 -0700 (PDT)
From: "Fitton, John" <jfitton@harris.com>
To: CICM Discussion List <cicm@ietf.org>
Thread-Topic: [cicm] Use Cases
Thread-Index: AQHMd7LmjPBWvrSjpk2RwGRVzj5bBpVWw2Ru
Date: Tue, 20 Sep 2011 21:26:18 +0000
Message-ID: <06D46EAFF7D0C946BEC108DB7CCDC9A608B6DD4A@ROCMXUS21.cs.myharris.net>
References: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EAF@0461-its-exmb09.us.saic.com> <06D46EAFF7D0C946BEC108DB7CCDC9A608B6CC19@ROCMXUS21.cs.myharris.net>, <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EB2@0461-its-exmb09.us.saic.com>
In-Reply-To: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EB2@0461-its-exmb09.us.saic.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Sep 2011 21:26:21.0189 (UTC) FILETIME=[F1021350:01CC77DB]
Received-SPF: none
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: Tue, 20 Sep 2011 21:24:20 -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. [JOHN.A.DAVIDSON@saic.com]
Sent: Tuesd ay, September 20, 2011 11:49 AM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

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