Re: [cicm] Use Cases

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