Re: [cicm] Use Cases
"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Tue, 20 September 2011 16:29 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 C740C11E80BB for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 09:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.171
X-Spam-Level:
X-Spam-Status: No, score=-5.171 tagged_above=-999 required=5 tests=[AWL=1.427, 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 yianDwQ-RjZl for <cicm@ietfa.amsl.com>; Tue, 20 Sep 2011 09:29:42 -0700 (PDT)
Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1A11E80B7 for <cicm@ietf.org>; Tue, 20 Sep 2011 09:29:41 -0700 (PDT)
Received: from 0599-its-sbg01.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-12867503 for cicm@ietf.org; Tue, 20 Sep 2011 09:31:54 -0700
X-AuditID: 8b791438-b7ca8ae0000047cf-32-4e78bffa4cd9
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg01.saic.com (Symantec Brightmail Gateway) with SMTP id 0E.40.18383.AFFB87E4; Tue, 20 Sep 2011 09:31:54 -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 09:31:54 -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_01CC77B2.CE7961E9"
Date: Tue, 20 Sep 2011 09:31:53 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085EB3@0461-its-exmb09.us.saic.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] Use Cases
Thread-Index: AQHMdtzvjPBWvrSjpk2RwGRVzj5bBpVVnDQGgAC0zdCAACbhFw==
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: cicm@ietf.org
X-OriginalArrivalTime: 20 Sep 2011 16:31:54.0821 (UTC) FILETIME=[CF083F50:01CC77B2]
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 16:29:42 -0000
Rats, I meant BLP => no flow down! ----- Original Message ----- From: cicm-bounces@ietf.org <cicm-bounces@ietf.org> To: CICM Discussion List <cicm@ietf.org> Sent: Tue Sep 20 08:49:30 2011 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 _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm
- [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