Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in a multilevel system?

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 2 Jul 2010 13:32:34 -0400

On 2010-06-22 14:11, Charles Linn Wrote:

> Is CICM specifying a) an API, b) a set of APIs or c) a component?  

If I understand the question correctly, CICM is somewhere between (a) and (b).
CICM defines a large set of interfaces, attributes and methods. 
Some subset of those definitions are chosen by an implementer to implement. 

> Coming at things from the JTRS world, APIs themselves are not 
> designated to a "side".

CICM made a similar design choice. None of the APIs are designated as being
on a side.

> This brings up a challenge for CICM, due to its OO nature, including the
> ability to (through iteration) get a large number of manipulation
> ability though base interfaces, e.g. CryptoModule.  This potentially
> flies in the face, or at least requires some creativity, to apply
> least-privilege principles.  For example, lets say you want to give a
> given component ability to encrypt, but not perform other functions - we
> need to think about how this could be done, if not in the API, than in
> runtime behavior.

Again, please look at Section 4 on Conformance
(see: http://tools.ietf.org/html/draft-lanz-cicm-00#section-4.1).
CICM handles the rules of least-privilege by having the 
implementers select which pieces of CryptoModule are implemented 
in the first place. For the example you provided, only the ChannelManager
would be implemented (and only the EncryptChannelManager would be defined)
whereas the other managers would not even be defined.

Perhaps this is the point you were trying to make when you said:
> The best you can do is to provide a reasonable set of 
> groupings of functions.  In this way, individual implementations 
> can support different combinations at different security levels 
> (including the same interface present in multiple locations) 
> as they see fit, while maintaining reasonable
> least-privilege access limitations.

* If not, does our Conformance model satisfy the least-privilege concerns?

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 6 Jul 2010 14:53:30 -0700

Lev, thanks for the discussion.

I don't disagree that exporting RED key can be necessary.  I am not comfortable with the position that “bypass may be needed to support “last ditch”” (efforts).  In my opinion, I don’t see failure of the crypto or packet headers as even approaching justifiability as a need for bypass.  Bypass simply offers a non-secure illegitimate alternative that unnecessarily corrupts the host.  I say unnecessary because I see high assurance secure alternatives that do not require bypass:  

1.  Failure of the cryptosystem can be accommodated by consciously deciding to declassify only the data we want to transmit before we transmit it.  Declassification of secret data must be done by authority of a “classification guide” contingency put in place before the emergency.  Once declassified by that procedure, whatever it is, then the data is immediately joins the set of “black side” data.  Neither the crypto nor bypass is involved with that.  Seems to me that should not be a crypto function, it has nothing to do with cryptography.  

2.  The reality is we allow headers to flow to the black side fundamentally because we trust the source not to hide any classified information in them.  That is tantamount to trusting the source (as MLS) and assuming the packet as an MLS data structure, ignoring the fact that the source may be “called” system high.  The only secure thing we can do is to acknowledge that we have always been trusting that source (assuming it is outside our context boundary) and decide to immediately parse the packet isolate the header with a high assurance trustworthy parser, separate it in its own domain and (implicitly) label it unclassified.  Then, by that action alone, it is immediately “ON” the “black side.”  Nothing got bypassed, no bypass needed.  You may say that is the same as bypass, and in some ways it is similar, but it happens immediately on receipt of the packet, and it has nothing to do with any crypto.  You may have a concern that we are trusting an untrustworthy source.  I agree, and that can cause a leak, but it is not a leak we can do anything about unless we stop all traffic.  No guard checking can do better, all the guard can do is blindly rely on checks of format and content that originated in the packet source anyway.  Our system cannot affect the trustworthiness of the source, our guard can do anything (except BW limit the leak.)  

So, I might counter that we are providing both the opiate and the needles just because the users say they really need it.  I’d argue they don’t “need” it and it causes an awful lot of unnecessary harm to the innocent.  We can provide it anyway, but should we?  

John

---

From: "Fitton, John" <[email-masked]>
Date: Wed, 7 Jul 2010 20:21:23 -0400

John
 
In my opinion this entire discussion of the need for bypass is inappropriate to this forum. I have heard your position many times and I am in total disagreement with your statements on the topic as I know are others, but I respect your right to possess and express your views. This is however, not the proper venue for such a discussion since you are addressing a matter of secutity policy. 
 
Dan hit the nail on the head regarding this API specification. What specific security functions are needed for any given situation is a function of the security policy established for the application/system. API's do not establish policy, they provide a means for implementing it. Thus in my view it is imperitive that the API support bypass functionality. 
 
As you are well aware, there are many legacy waveforms which require bypass in one form or another for various functions. It is the responsibility of the designers of the bypass to provide an implement which enforces the policy and it is the responsibility for the group certifying the design to ensure that the design is sufficiently robust. 
 
 Tactical radios have bypass because the need for communications can completely override the need for security. Remember "tactical" means perishable. Life is also perishable!  Troops in the battlefield have the right to decide to transmit in the clear if there is no other recourse. Classification guides have little, if any meaning in life and death situations. 
 
I hope to be in San Diego next spring at the Wireless Innovation Forum and would enjoy having a spirited debate with you on the topic of bypass among others.
 
John

________________________________

From: Davidson, John A. [mailto:[email-masked]]
Sent: Tue 7/6/2010 5:53 PM
To: CICM Discussion List; CICM Discussion List
Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API in amultilevel system?

I don't disagree that exporting RED key can be necessary.  I am not comfortable with the position that "bypass may be needed to support "last ditch"" (efforts).  In my opinion, I don't see failure of the crypto or packet headers as even approaching justifiability as a need for bypass.  Bypass simply offers a non-secure illegitimate alternative that unnecessarily corrupts the host.  I say unnecessary because I see high assurance secure alternatives that do not require bypass: 

1.  Failure of the cryptosystem can be accommodated by consciously deciding to declassify only the data we want to transmit before we transmit it.  Declassification of secret data must be done by authority of a "classification guide" contingency put in place before the emergency.  Once declassified by that procedure, whatever it is, then the data is immediately joins the set of "black side" data.  Neither the crypto nor bypass is involved with that.  Seems to me that should not be a crypto function, it has nothing to do with cryptography. 

2.  The reality is we allow headers to flow to the black side fundamentally because we trust the source not to hide any classified information in them.  That is tantamount to trusting the source (as MLS) and assuming the packet as an MLS data structure, ignoring the fact that the source may be "called" system high.  The only secure thing we can do is to acknowledge that we have always been trusting that source (assuming it is outside our context boundary) and decide to immediately parse the packet isolate the header with a high assurance trustworthy parser, separate it in its own domain and (implicitly) label it unclassified.  Then, by that action alone, it is immediately "ON" the "black side."  Nothing got bypassed, no bypass needed.  You may say that is the same as bypass, and in some ways it is similar, but it happens immediately on receipt of the packet, and it has nothing to do with any crypto.  You may have a concern that we are trusting an untrustworthy source.  I agree, and that can cause a leak, but it is not a leak we can do anything about unless we stop all traffic.  No guard checking can do better, all the guard can do is blindly rely on checks of format and content that originated in the packet source anyway.  Our system cannot affect the trustworthiness of the source, our guard can do anything (except BW limit the leak.) 

So, I might counter that we are providing both the opiate and the needles just because the users say they really need it.  I'd argue they don't "need" it and it causes an awful lot of unnecessary harm to the innocent.  We can provide it anyway, but should we? 

John

---

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

WARNING: contains banned part

Subject: RE: [cicm] Does CICM only provide (specify) the "red" side API inamultilevel system?
From: "Davidson, John A." <[email-masked]>
To: "CICM Discussion List" <[email-masked]>
Date: Thu, 8 Jul 2010 07:53:11 -0700

John, 

I don't think we are discussing what the security policy states.  I think supporting a bypass API can impact whether a security policy can rigorously be enforced, no matter what the policy states.  

I believe the view that bypass must be an API is based on the conventional view of a radio as a red side and black side with a crypto in the middle; in that view bypass is imperative.  And that works for our legacy radios made with hardware boxes (or circuit cards), but seems unrealistic to me for a SDR.  I view an SDR as a computer with processes that have mediated access to read and write objects in a (potentially common) memory.  That thing has no sides.  Only the OE can enforce security policy.  Some policies can be rigorously enforced, some not.  

My concern is that including bypass as an API has the unintended consequence of placing security enforcement in the application layer.  The only way we know how to rigorously enforce security policy is with hardware support in the OE.  

Its like a standard for building a prison.  If you include doors between cells because the prisoners say they need it, you create yourself the problem of mitigating unauthorized use.  If we decline to offer that as a standard, then we enable prisons that force the prisoners to deal with rigorous policy enforcement to interact with other cells.  To avoid simply trusting all the software, processes in an SDR need to be treated like prisoners and mitigated by a secure OE.  

True, legacy radios have these doors between cells, OK so be it.  And waveforms do use them, but waveforms still work if ported to secure OEs with no bypass.  So do we want to support bypass in new SDRs?  I hear loud and clear that you do.  If that is the consensus then so be it.  I anticipate that at some point in our evolution we will be forced by logic to abandon the view of an SDR as having these ‘sides’ and bypass.   

Best regards, 
John

-----Original Message-----
From: [email-masked] on behalf of Fitton, John
Sent: Wed 7/7/2010 5:21 PM
To: CICM Discussion List
Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API inamultilevel system?
 
John

 

 
John

2.  The reality is we allow headers to flow to the black side fundamentally because we trust the source not to hide any classified information in them.  That is tantamount to trusting the source (as MLS) and assuming the packet as an MLS data structure, ignoring the fact that the source may be "called" system high.  The only secure thing we can do is to acknowledge that we have always been trusting that source (assuming it is outside our context boundary) and decide to immediately parse the packet isolate the header with a high assurance trustworthy parser, separate it in its own domain and (implicitly) label it unclassified.  Then, by that action alone, it is immediately "ON" the "black side."  Nothing got bypassed, no bypass needed.  You may say that is the same as bypass, and in some ways it is similar, but it happens immediately on receipt of the packet, and it has nothing to do with any crypto.  You may have a concern that we are trusting an untrustworthy source.  I agre
 e, and that can cause a leak, but it is not a leak we can do anything about unless we stop all traffic.  No guard checking can do better, all the guard can do is blindly rely on checks of format and content that originated in the packet source anyway.  Our system cannot affect the trustworthiness of the source, our guard can do anything (except BW limit the leak.) 

John

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

---

From: "Dr. Joe Mitola" <[email-masked]>
Date: Thu, 08 Jul 2010 10:58:57 -0400

Somehow CICM emails now are being flagged by my firewall as potentially 
malicious
joe

Dr. Joseph Mitola III, Fellow of the IEEE
Distinguished Professor
Charles V. Schaefer, Jr.  School of Engineering and Science
School of Systems and Enterprises
Vice President for the Research Enterprise
Stevens Institute of Technology
Castle Point on Hudson, Hoboken, NJ, USA
Cell: 703-314-5709

Davidson, John A. wrote:
> ------------------------------------------------------------------------
>
> Subject:
> RE: [cicm] Does CICM only provide (specify) the "red" side API 
> inamultilevel system?
> From:
> "Davidson, John A." <[email-masked]>
> Date:
> ------------------------------------------------------------------------
>

---

From: "Novikov, Lev" <[email-masked]>
Date: Thu, 8 Jul 2010 11:04:26 -0400

Joe,

> Somehow CICM emails now are being flagged by my firewall as potentially malicious

To me it looks like the phrase "WARNING: contains banned part" is being attached at the sender side.
John: Did you (or your corporate firewall) intend to have that extra phrase in the email?

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Thu, 8 Jul 2010 09:45:48 -0700

Lev, 
Our corp. IT help desk claims that statement was not added by our systems.  
It did not go out with that. 
Do you have evidence I can use to prove them wrong.  
John

-----Original Message-----
From: [email-masked] on behalf of Novikov, Lev
Sent: Thu 7/8/2010 8:04 AM
To: CICM Discussion List
Subject: Re: [cicm] Does CICM only provide (specify) the "red" side API inamultilevel system?
 
Joe,

Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Thu, 8 Jul 2010 13:15:17 -0400

John,

> Do you have evidence I can use to prove them wrong.

I stand corrected; it seems that your corporate help desk was correct. The issue 
seems to be with the IETF spam filter. There was an HTTP header that showed that 
revealed this to be the case:

X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com

And <core3.amsl.com> redirects to <ietf.org> so it's their doing. I'm trying to find out
how to modify those settings (I may not have the authority), but for now let's just move on.

Sorry about the confusion.

Lev

---

From: "Fitton, John" <[email-masked]>
Date: Thu, 8 Jul 2010 21:40:10 -0400

John,
 
Iiwill try to respond to your various points:
 
1) " I don't think we are discussing what the security policy states."
 
We apparently have different views of what is and what is not covered by security policy. Whether or not a bypass function is allowed for any given application is definitely an element of a security policy. And indeed for some applications (read as waveform) a plain text audio bypass is not allowed as a matter of security policy. And because of that, the bypass security service for such a waveform should not allow such a bypass channel to be configured. It is part of othe security policy for that waveform because enforcement of that aspect (as with any other aspect of the security policy) is crucial to overall platfrom  security policy enforcement.
 
2) "I think supporting a bypass API can impact whether a security policy can rigorously be enforced, no matter what the policy states. "

Your comments seem to focus on policy enforcement implementation issues. Again that is not germaine to this discussion. Bypass is an essential component of some waveforms and an API is needed to allow the function to be properly configured and used.  Your second statement is a question of the security architecture and design of any given system. It is not appropriate for this standard to eliminate that which is already an valid choice in other API's. You might not like them, but again that is not pertinent to this forum. Remember that just because Bypass is an element of the overall API it doesn't mean that it must be used. It simply means it is available for use if the security architect chooses to implement the bypass in that manner. There are some types of bypass in fact that probably would not be implemented in that manner. But is should be at the choice of the security architect (assuming that policy allows the bypass in the first place)
 
You seem to believe that by allowiing a bypass you somehow weaken enforcement of other aspects of the security policy. In general I do not believe that this is a direct consequence of the existence of a bypass, because security policy enforcement involves many different factors and they must all work together to enforce the policy. 
 
John, I recommend you read the latest version of the document that the WINNF has submitted for ballot "Securing Software Reconfigurable Communication Devices". I believe SAIC is a member of the forum and your principal delegate should have a copy. JPEO also has a copy. This document addressed many aspects of security architecture and security policy enforcement.
 
3)" believe the view that bypass must be an API is based on the conventional view of a radio as a red side and black side with a crypto in the middle; in that view bypass is imperative.  And that works for our legacy radios made with hardware boxes (or circuit cards), but seems unrealistic to me for a SDR.  I view an SDR as a computer with processes that have mediated access to read and write objects in a (potentially common) memory.  That thing has no sides.  Only the OE can enforce security policy.  Some policies can be rigorously enforced, some not. 

I absolutely disagree. A bypass is a means of passing information contained in one security container at a given security level to another container at a different security level without the use of a cryptographic transform. It has nothing to do with the terms RED and BLACK which only have meaning in terms of TEMPEST!  I know you have heard my speech on the mis-use of the terms RED and BLACK and you are definitely misusing them in your statement above. I cannot delve into this any further since it is a public forum.  

However, It is precisely because we are discussing SDR's that the term API is appropriate. An API is a software interface. But just because the API is a software interface it doesn't mean that the security policy enforcement is simply software based.  Any security architect that uses common memory without all of the necessary safeguards in an SDR, deserves to be put in front of a firing squad..and  the Government employees that certify such a design should be standing right next to that miscreant.  

I'm not sure what you mean by the term "OE" since it has different meaning to different folks. We defined what we meant in our WINNF document.  But if you are for example referring to one of the new partitioning Operating Systems then I must disagree. Indeed that OS is a crucial component but it is incomplete, but again this topic is for a different forum than this. 

The degree of rigor in any security policy enforcement is a matter of Security Architecture and Design and how well it has been done and the level of robustness associated with all aspects of that design. This is true of any element of security policy enforcement and bypass is no exception, nor is it special.

 Again I recommend you read the new WINNF document. It is available on the WINNF Groups portal immediately after you log in.

4) "My concern is that including bypass as an API has the unintended consequence of placing security enforcement in the application layer.  The only way we know how to rigorously enforce security policy is with hardware support in the OE. "

I'm not sure why you come to that conclusion that security policy enforcement is in the application layer.  The API should allow a bypass to be configured for use  (if allowed by the waveform security policy) and it should, when relevent support the transfer of the "data" to be bypassed, between those application layer components that are supposed to process that information on either side of the bypass function. Enforcement of the specifics of what is or is not allowed to be bypassed is a reference monitor function charged with specifically enforcing the bypass content security policy. That reference monitor function is generally not the OS. [The OS is a reference monitor function but bypass management is typically not an OS function . The OS reference monitor function deals with resource allocation (memory management via an MMU, allocating processing space and time, etc.). Your use of the term hardware support is rather vague.  I am a strong proponent of the view that a proper balanced is requried between hardware and software mechanisms when it comes to security policy enforcement. But the nature and the degree to which hardware is required is a function of many different elements. Our WINNF paper has a fairly balanced treatment of this topic.

5) " Its like a standard for building a prison.  If you include doors between cells because the prisoners say they need it, you create yourself the problem of mitigating unauthorized use.  If we decline to offer that as a standard, then we enable prisons that force the prisoners to deal with rigorous policy enforcement to interact with other cells.  To avoid simply trusting all the software, processes in an SDR need to be treated like prisoners and mitigated by a secure OE.  True, legacy radios have these doors between cells, OK so be it.  And waveforms do use them, but waveforms still work if ported to secure OEs with no bypass.  So do we want to support bypass in new SDRs?  I hear loud and clear that you do.  If that is the consensus then so be it.  I anticipate that at some point in our evolution we will be forced by logic to abandon the view of an SDR as having these 'sides' and bypass.  
"

I've never heard of a prison where the prisoners define any aspect of the prison's security policy.  The waveforms that employ bypass were designed in conjunction with the user community for that waveform and functions like bypass were explicit requirements or grew out of other operational considerations. In each and every instance the need for the bypass and it's implementation in the legacy system was carefully scrutinized as part of the security evaluation process. In many, if not most cases, the bypass wasn't even part of the radio, it was part of the stand-alone crypto that worked with many different radios. (That's how old some of these legacy waveforms actually are).  Even HAIPE supports some bypass functionality because it must in order to work. If you think you can make HAIPE work without those bypass functions  then I urge you to join the HAIPE working group and show them how to eliminate them.

I would like to hear (but not in this forum) about of an  example of a legacy waveform that supported bypass functionality being ported to a platform that doesn't support bypass. I would maintain that such a waveform does not meet interoperability requirements because it would not be backwards compatible. 

John, This is not the place for this discussion and I urge you to cease and desist. If you wish to reply directly to me, please do so at [email-masked]. 

Incidently, Dan, regarding my much earlier response regarding RED/BLACK side. The key point that I wanted to make was that I belelived the API should permit both RED and BLACK side usages (be RED vs BLACK agnostic) and was not suggesting that you change the manner by which this would occur or would be declared by any given implementation.

regards,

John

> True, legacy radios have these doors between cells, OK so be it.  And waveforms do use them, but waveforms still work if ported to secure OEs with no bypass.  So do we want to support bypass in new SDRs?  I hear loud and clear that you do.  If that is the consensus then so be it.  I anticipate that at some point in our evolution we will be forced by logic to abandon the view of an SDR as having these 'sides' and bypass.  
>
> Best regards,
> John
>

---

From: "Davidson, John A." <[email-masked]>
Date: Fri, 9 Jul 2010 07:47:35 -0700

Subject: RE: [cicm] Does CICM only provide (specify) the "red" side APIinamultilevel system?
From: "Davidson, John A." <[email-masked]>
To: "CICM Discussion List" <[email-masked]>
Date: Fri, 9 Jul 2010 07:47:35 -0700

John, 
It seems to me a lot of your disagreement with my view is rooted in your view that bypass can be a fundamental requirement.  I claim not; but admit there are caveats to my claim.  If the policy being enforced is too stringent, then the security domains driven by that policy can preclude system operation without bypass.  For example, if the security policy says never transmit (to avoid revealing my presence) then I can’t make my waveform interoperable.  I am convinced (from logical analysis, without proof) for basic policies based on non-disclosure of classified information (ie for the US, derived from Executive Order 12958) all of the dozen or so legacy waveforms I am familiar with (& HAIPE) can be ported to an OE that absolutely enforces that policy without bypass without loss of interoperability.  

In my view, the need for bypass is never driven by operational objectives; it is caused by flaws in the IA architecture, specifically but trying to enforce the wrong security domains.  It is surprisingly difficult (almost impossible) to get the domain structure right with ad-hoc methods.  Many in the computer security research community view bypass as a symptom of a failed security architecture.   That happens when we decline to use formal computer security design methods to derive the IA architectural framework directly from a security policy.  Too often we are designing secure systems without even writing a policy so we never know exactly what we are trying to enforce.  The policy is the top level definition of what secure operation means to our system.  To robustly enforce a policy, all security requirements should be formally derived from that policy using the security model (not from DIACAP, not UIC etc).  Unfortunately, understanding exactly how to do that requires an unusual amount of background information.  But not knowing has a cost.  When we decline (for whatever reason) to do that, it almost inevitably leads to architectures that won’t work without bypass.  

Whether we decide to standardize bypass may depend on whether we see bypass as an unnecessary evil.  Seeing this requires an awful lot of involved investigation and willingness to reexamine comfortable conventions.  I believe a bypass API enables an unnecessary and harmful practice and enabling harmful practices is cross purposes with standardization.  But in today’s reality, we find we have a sort of broken foundation when it comes to high assurance secure computer system engineering; we have the theory but we in the practice community decline to use it.  An opposing argument might be that too many designers will decline to use formal methods and end up needing bypass, so give them a standard and accept (or disregard) the consequence.  

Thanks for the discussion,
John

-----Original Message-----
From: [email-masked] on behalf of Fitton, John
Sent: Thu 7/8/2010 6:40 PM
To: CICM Discussion List
Subject: Re: [cicm] Does CICM only provide (specify) the "red" side APIinamultilevel system?
 
John,

 

 

I'm not sure why you come to that conclusion that security policy enforcement is in the application layer.  The API should allow a bypass to be configured for use  (if allowed by the waveform security policy) and it should, when relevent support the transfer of the "data" to be bypassed, between those application layer components that are supposed to process that information on either side of the bypass function. Enforcement of the specifics of what is or is not allowed to be bypassed is a reference monitor function charged with specifically enforcing the bypass content security policy. That reference monitor function is generally not the OS. [The OS is a reference monitor function but bypass management is typically not an OS function . The OS reference monitor function deals with resource allocation (memory management via an MMU, allocating processing space and time, etc.). Your use of the term hardware support is rather vague.  I am a strong proponent of the view that a pro
 per balanced is requried between hardware and software mechanisms when it comes to security policy enforcement. But the nature and the degree to which hardware is required is a function of many different elements. Our WINNF paper has a fairly balanced treatment of this topic.

regards,

John

---

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 9 Jul 2010 11:10:20 -0400

Folks,

We have had a good civil discussion about whether or not 
bypass capabilities ought to be defined in the CICM API. 
It seems that all the relevant points on this subject have 
been made and we request the community to end the current 
discussion of bypass. 

Our explicit design decision was to architect the API and
conformance model so that implementers can choose which pieces 
to implement according a defined security policy. Furthermore, 
we believe there is strong community support to continue to 
include bypass definitions in CICM.

Nonetheless, we invite interested parties to write and review the 
Security Considerations section to address any concerns regarding 
the use of specific CICM capabilities including bypass.

This concludes our current discussion on bypass; thank you all 
for your input. (Next week: Should we split CICM into smaller documents?)

Have a good weekend,
Lev