Subject: Re: [cicm] Use of Bypass

From: "John Davidson" <[email-masked]>
Date: Sat, 3 Jul 2010 07:08:52 -0700

Lev, your position is undeniable:  

If:
  - Those devices have bypass capabilities, and
  - People write software that uses those capabilities,
Then:
  - We'd like them to do it in a standard way.

However, I claim supporting bypass is tantamount to providing a suicide
pill.  Can we do it?  Sure.  My concern is if we provide it, uninformed
developers will be able to decline to do responsible COMPUSEC engineering
and simply use it.  So is it responsible of us to legitimize this behavior
with a standard is my question.  It is only a moral issue, not technical.
Either way, I think a secure (bypass free) system can be implemented because
it is not the API that is responsible for enforcing security.  Only the MLS
OE (the OS or the architecture) can reasonably enforce high assurance secure
behavior.  Even if the API supports bypass in a secure OE; in a SOS, any
attempt to use it would result in the calling process being permanently
blacklisted.  But maybe morality isn't our thing?  

Or maybe there is some middle ground.  Bypass isn't really fundamentally a
crypto function anyway, why bundle them?  It is a corruption of the crypto
function, a hole in its domain wall.  One idea may be to support bypass with
another function, a separate function that has nothing to do with
cryptography, a sort of "Corruption of Domain Suicide" or CDS function.  

Where do we go?     

John

---

From: "Lanz, Dan" <[email-masked]>
Date: Tue, 6 Jul 2010 15:43:51 -0400

John,

This question has been raised regarding a handful of CICM functions.  For example, CICM will allow you to export RED key from a module.  It provides the capability to perform administrative actions that may make sense only in under very specific conditions.  Bypass, too, can have negative consequences if used incorrectly or under the wrong conditions.  For all these examples, there are clearly conditions under which the functions are necessary.  As you know, bypass may be needed to support "last ditch" communications in the event of a failure in a cryptosystem or to allow packet headers in a packet encryptor to move across a domain boundary.

Is providing these capabilities in the API tantamount to offering free needles to drug users?  CICM does not prescribe policy and hopefully does not encourage any type of negative behavior.  Even uncontroversial functions may not be appropriate for certain cryptographic modules.

The CICM conformance appendix was designed to enable an implementation to be "conformant" and yet not implement every function in the entire specification.  Your proposal is to move one class of controversial functions to a separate specification.  Is that necessary under the circumstances?  Is it acceptable to allow an implementation to be conformant without implementing bypass?

Do others have an opinion in this matter?  How should we proceed?

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Davidson
Sent: Saturday, July 03, 2010 10:09 AM
To: [email-masked]
Subject: Re: [cicm] Use of Bypass

However, I claim supporting bypass is tantamount to providing a suicide pill.  Can we do it?  Sure.  My concern is if we provide it, uninformed developers will be able to decline to do responsible COMPUSEC engineering and simply use it.  So is it responsible of us to legitimize this behavior with a standard is my question.  It is only a moral issue, not technical.  Either way, I think a secure (bypass free) system can be implemented because it is not the API that is responsible for enforcing security.  Only the MLS OE (the OS or the architecture) can reasonably enforce high assurance secure behavior.  Even if the API supports bypass in a secure OE; in a SOS, any attempt to use it would result in the calling process being permanently blacklisted.  But maybe morality isn't our thing?

Or maybe there is some middle ground.  Bypass isn't really fundamentally a crypto function anyway, why bundle them?  It is a corruption of the crypto function, a hole in its domain wall.  One idea may be to support bypass with another function, a separate function that has nothing to do with cryptography, a sort of "Corruption of Domain Suicide" or CDS function.

Where do we go?

John

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 7 Jul 2010 14:10:30 -0400

John,

> One idea may be to support bypass with another function, a separate 
> function that has nothing to do with cryptography, a sort of 
> "Corruption of Domain Suicide" or CDS function. 

Doesn't our namespace model address this? By putting all the bypass-related 
functions in a separate namespace we're trying to make it painfully obvious
that you are entering the realm of dangerous.

Perhaps we can add a statement to the IETF-mandated "Security Considerations" 
section that makes this even clearer (perhaps you'd like to volunteer to
review the Security Considerations for the -02 draft?)

* Does that work?

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Thu, 8 Jul 2010 07:44:16 -0700

WARNING: contains banned part

Subject: RE: [cicm] Use of Bypass
From: "Davidson, John A." <[email-masked]>
To: "CICM Discussion List" <[email-masked]>
Date: Thu, 8 Jul 2010 07:44:16 -0700

Lev, 
*Does that work?  
Well, it works to obviate the danger.  

I am not sure how it works to preserve isolation between domains.  Aren't incompatible security domains in separate namespaces (e.g. processing on secret data and unclassified data)?  Those domains should be exist in separate virtual machines that have no access to each other except via the secure OE.  Would a "bypass guard" have an API assessable in each of those namespaces?  

I am trying to see the security oriented view of how this can work to see if it is consistent with the operational view.  This should be consistent with how MLS OS works and in that OE, when we want something to flow between domains, we create an object at a security classification that is consistent with where we want it to be seen.  Then the consuming processes just access it if they can.  The bypass guard function, if you will, is implicitly built into the creating process.  We have been building secure MLS computers like this for decades with no notion of bypass APIs.  I don't see why SDRs are different, just that we have a deeply rooted preconceived notion that they must be confined to an implementation that has red/black sides with a crypto in the middle, that won't work without bypassing the crypto.    

This MLS view works implicitly for non secure radios, and equally implicitly for secure radios provided they don't try to violate their OE-enforced policy.  

Another question, would this API be part of the crypto API?  

Thanks, 
John

-----Original Message-----
From: [email-masked] on behalf of Novikov, Lev
Sent: Wed 7/7/2010 11:10 AM
To: CICM Discussion List
Subject: Re: [cicm] Use of Bypass
 
John,

* Does that work?

Lev
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm