Re: [cicm] Use Cases

["Fitton, John" <[e-mail]>]

An API does not and should not determine the underlying security architecture compliance to security policy. The API should be 100% agnostic to an MLS, MILS, MSLS or SLS security architecture. The API is a standardized construct used to communicate between processes which require security services and the processes which provide those services. That being said the API should have features which allow it so support key security architecture principals such as the Principal of Least Privilege, and separation of control and data paths so that systems which require MLS have a chance of being certified to that level. The API should not restrict in any way the choices which a security architect needs to make to ensure that the resultant system architecture satisfies the total set of security policies. Security classifications are a small subset of the total set of security policies which a robustly designed system needs to satisfy. 

A bit of information. The Wireless Innovation Forum just approved a basic API set designed to enhance application portability across platforms employing different security and hardware architectures. The platforms are software defined radios. The "legacy" applications to which John is referring are the waveforms which provide the modulation and demodulation of the air interfaces employed by these radios. The API set produced by the Forum does not address the complete set of platform interfaces needed but it is intended to be agnostic to the underlying security architecture, the platform hardware architecture or the nature of the cryptographic/INFOSEC components which provide the required security services.  It's purpose is to enhance and facilitate portability of these waveform applications across diverse radio platforms.  Ignoring platform interfaces for this API set is intentional for the time being. The CICM specification is designed to provide a complete set of API's necessary to support a complete design. The market for the Forum's API is such that the underlying radio platform is already constrained by platform specific requirements, and there is a complete void for the security services API due to a variety of reasons.  The API developed is targeted to platforms which conform to the US DoD Software Communications Architecture (SCA) which is a Gernmenet standard for an entire family of new radios for the DoD. A part of this standard requires a POSIX OS and the use of CORBA for inter-process communications.   

The Wireless Innovation Forum Security API was specifically targeted towards tactical radio systems and will shortly be available in the publicly accessible portion of the the forums websites document library. Those interested may use this link:

http://groups.winnforum.org/index.php?mo=cm&op=ld&fid=46

I also have a very different view about the ability of industry to develop secure systems than does John.

John Fitton
Harris Fellow
Senior Scientist
Harris RF Communications

________________________________________
From: Davidson, John A. [[e-mail]]
Sent: Wednesday, September 14, 2011 12:23 PM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

Hema,
IMHO, the answer to 1. is "not really," because to address this in a
sound way excludes a lot of unsound things that legacy systems are
accustomed to doing; and expect of CICM.  Consequently, considering it
would be divisive and alienate a large constituency.  I have been
struggling with how to do this in a way that accommodates both views.

John

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Krishnamurthy, Hema - ES
Sent: Wednesday, September 14, 2011 8:52 AM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

Lev,

My 2 cents on the use cases:

1. There is mention of MLS in the list below, but have you considered
"containers" for each security level in an MLS system?
2. Key exchange - Is it going to cover all types - IPSec, SSL/TLS/DTLS?
3. How about voice over IP use case? Part of it would fall under the
networking arena, but there would be some specifics pertaining to VoIP -
like support of SRTP.
4. I forget, does CICM support the ability to write down SADs into the
crypto module?

Hema


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Novikov, Lev
Sent: Thursday, September 08, 2011 11:14 AM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

John,

On 2011-08-29 10:27, John Davidson wrote:
> When you refer to "sides" in #4, it may lead us to model the "red
side"
> as "considered secure" and the black side as "considered unsecured".
> The secure/unsecured view leads us to think that there is something
more
> than isolation that makes the red domain "secure."  That has a "my
> machine; my data vs. their stuff" security policy orientation.
> There is another orientation that may be more applicable for so-called
high
> assurance.  That is the Their (the gov's) Top Secret, Their Secret and
> Their Unclassified, where none of the domains are "considered secure"
> from a trustworthy-ness POV.

This is an excellent point. Security domains do not define trust, per
se. They
are defined by a security policy which specifies, among other things,
how data
moves into/out of that domain. This is the definition we previously
used.
For example, see "$ security domain" in
http://tools.ietf.org/html/draft-lanz-cicm-lm-01

Therefore, I'm going to add "multiple levels of security domains" to the
list of
use cases. This should cover a broad list of arrangements including Joe
Mitola's
use cases (personal data, NDAs, content-based roles).

FYI: By adding this use case, I'm not saying that CICM needs to support
Multiple
Levels of Security (MLS) and/or Multiple Independent Levels of Security
(MILS),
but I am saying we shouldn't do anything to prevent someone from using
it those
configurations, if they so choose.
See http://tools.ietf.org/html/draft-lanz-cicm-lm-01#section-1.4

> I mention this because it the link in #4 implies just 2 "sides" and it
> implies communication between those "sides" that encourages software
to
> fail to "stay out of the way" and violate rules by trying to
communicate
> from red to black with bypass and such.
>
> While lots of people (HAIPE et al) want to do that, I suggest our
models
> stop short of encouraging, suggesting or even enabling it because to
do
> so creates an architecture that we don't know how to secure today.
That
> is not what we are about.

The use cases are intentionally broad because we are trying to build a
framework
which will facilitate analysis of existing IETF protocols using a
domain-centric
approach. Certainly, the classic high assurance cases (1, 3) can be
used, but
we're evaluating the impact on existing approaches.

Our current list so far:
1. high assurance data-in-transit (two networks, two domains)
2. traditional data-in-transit or -at-rest (cf. PKCS#11)
3. one network, two domains (cf. network storage; data-in-transit +
-at-rest)
4. one machine, two domains in software (via Vincent Roca)
5. secure key exchange (via Kevin Wall)
6. multiple levels of security domains (via John Davidson/Joe Mitola;
  one or more networks, multiple domains)

Any others?

Regards,
Lev
_______________________________________________
cicm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cicm

This e-mail and any files transmitted with it may be proprietary and are
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this e-mail in error please notify the
sender.
Please note that any views or opinions presented in this e-mail are
solely those of the author and do not necessarily represent those of ITT
Corporation. The recipient should check this e-mail and any attachments
for the presence of viruses. ITT accepts no liability for any damage
caused by any virus transmitted by this e-mail.
_______________________________________________
cicm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/cicm