Re: [cicm] Use Cases
"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Tue, 20 September 2011 15:47 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 F2F1421F8CAD for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 08:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.992
X-Spam-Level:
X-Spam-Status: No, score=-4.992 tagged_above=-999 required=5 tests=[AWL=1.607, BAYES_00=-2.599, 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 lk3dI5Zm3n3i for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 08:47:24 -0700 (PDT)
Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7021F8CAB for <cicm@ietf.org>; Tue, 20 Sep 2011 08:47:19 -0700 (PDT)
Received: from 0599-its-sbg03.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-12855739 for cicm@ietf.org; Tue, 20 Sep 2011 08:49:31 -0700
X-AuditID: 8b79132a-b7cf7ae000005009-88-4e78b60bb9c7
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg03.saic.com (Symantec Brightmail Gateway) with SMTP id 13.50.20489.B06B87E4; Tue, 20 Sep 2011 08:49:31 -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); Tue, 20 Sep 2011 08:49:31 -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: Tue, 20 Sep 2011 08:49:30 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EB2@0461-its-exmb09.us.saic.com>
In-Reply-To: <06D46EAFF7D0C946BEC108DB7CCDC9A608B6CC19@ROCMXUS21.cs.myharris.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] Use Cases
Thread-Index: AQHMdtzvjPBWvrSjpk2RwGRVzj5bBpVVnDQGgAC0zdA=
References: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EAF@0461-its-exmb09.us.saic.com> <06D46EAFF7D0C946BEC108DB7CCDC9A608B6CC19@ROCMXUS21.cs.myharris.net>
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: CICM Discussion List <cicm@ietf.org>
X-OriginalArrivalTime: 20 Sep 2011 15:49:31.0631 (UTC) FILETIME=[E32C3FF0:01CC77AC]
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: Tue, 20 Sep 2011 15:47:25 -0000
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
- [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Kevin W. Wall
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Kevin W. Wall
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Krishnamurthy, Hema - ES
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Novikov, Lev
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Cottrell Jr., James R.
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Fitton, John
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Davidson, John A.
- Re: [cicm] Use Cases Fitton, John