gmane.ietf.cicm

Taking over High Assurance Crypto Mailing List

Novikov, Lev — 2012-02-20T13:43:17

For the past few years, I've been managing the Common Interface to Cryptographic
Modules (CICM) mailing list (cicm< at >ietf.org) and the associated drafts 
(draft-lanz-cicm-*; see: <https://datatracker.ietf.org/doc/draft-lanz-cicm/>)

Unfortunately, late last fiscal year funding for CICM was cut (although rumors
of its return persist) making it difficult for me to contribute in any way.

However, instead of declaring this effort dead (or indefinitely offline), I want
to know if anyone is interested in taking over the management of the list and
moving the spec forward.

The use cases would need to be finalized and the spec would have to be rebuilt
according to those use cases, although a substantial part could be moved over
from the five existing drafts. The result would be an API that is flexible enough
to handle existing commercial applications, but robust enough to handle existing
scenarios with security domain separation for which PKCS#11-like APIs are 
inadequate due to differences in logical model.

Contact

Re: Use Cases

Fitton, John — 2011-09-20T21:26:18

I see a claim of yours that there is not technology available to support high assurance. That is your opinion, one which I and others disagree. I have not see you offer any support for your assertions and I do not believe that you can in this forum. Any such discussionsn would most assuredly violate ITAR. 

My claim is supported by many official US Government agency certifications of  equipments approved to the highest security criteria and classifications with which I was associated. 

Flaws in the Bell La Padula model, which is a MODEL, not a POLICY, were recognized shortly after it was published. Furthermore BLP is only appropriate as an Access Control model, and nothing else. There is considerable literature available to support this view. It was defined in an era when there were many user terminals attempting to access information in classified data bases. These computer systems were isolated and not connected to anythiing except their peripherals. As such it is outmoded. 


I reject your unsupported as

Re: Use Cases

Davidson, John A. — 2011-09-20T16:31:53

Rats, I meant BLP => no flow down! 

----- Original Message -----
From: cicm-bounces< at >ietf.org <cicm-bounces< at >ietf.org>
To: CICM Discussion List <cicm< at >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
satis

Re: Use Cases

Davidson, John A. — 2011-09-20T15:49:30

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 det

Re: Use Cases

Fitton, John — 2011-09-20T04:04:46

John



You are way off base with the claims in your post and you are entering areas of discussion which are not appropropriate for this forum.  You make claims which you cannot explain or otherwise support without delving into topics which encroach on classified information or at least on information covered by the ITAR.



As with your previous posts, you speak in vague unsupported terms and you are not, in my opinion contributing to the activity in a positive way.





________________________________
From: Davidson, John A. [JOHN.A.DAVIDSON< at >saic.com]
Sent: Monday, September 19, 2011 12:26 PM
To: CICM Discussion List
Subject: Re: [cicm] Use Cases

Jim,
All gov. secret type MLS Mode systems are a composition of single level domains.  Whether or not the domains are implemented as HW domains is a distinction that makes no difference.  The radio as a system would still operate in MLS Mode.  I concede a lot of connotations and expectations to the contrary, but those lead to contradictions.  While I don’t adv

Re: Use Cases

Fitton, John — 2011-09-20T03:56:49

1) The definition of high assurance has absolutely nothing to do with security policy that is being enforced, it is about the measures being taken to enforce whatever the policy requires and the robustness with which the measures are enforced. There is no other "customary connotation".  If  you claim otherwise then provide your sources which substantiate your claim.  Even you refer to "high assurance mechanisms". Please provide your definition of what those are supposed to be and please define what makes them high assurance.  I will also state that there are definitions of what is meant by high assurance, none of which conform to you presumed meaning.



2) Security policy goes way beyond "protecting government secrets" E.g. Financial institutions require high assurance mechanisms that have absolutely nothing to do with protecting government secrets! Their security policy deals with protecting assets (as does the Governments... but the Governments assets are information which may or may not be officially "cl

Re: Use Cases

Davidson, John A. — 2011-09-19T16:26:07

Jim, 

All gov. secret type MLS Mode systems are a composition of single level domains.  Whether or not the domains are implemented as HW domains is a distinction that makes no difference.  The radio as a system would still operate in MLS Mode.  I concede a lot of connotations and expectations to the contrary, but those lead to contradictions.  While I don’t advocate silence on this, I think it would be better for CICM to be silent than wrong in such a harmful way.

 

Furthermore,  I don’t see how radios can even come close to any reasonable notion of “Independent” domains, I see that as a myth, the domains aren’t really independent at all, they are managed by a common control plane that interacts with both domains.  They are independent except for the yada-yada.  I have seen this notion that so-called “MSLS” can avoid high assurance MLS Mode be devastating.  I am concerned about CICM validating or promulgating that notion; it is unsound.    

 

This is not just me, I have never see

Re: Use Cases

Cottrell Jr., James R. — 2011-09-19T15:00:29

John,

While a gov.secret type radio has two security domains, plaintext side containing sensitive/classified and ciphertext side containing usually unclassified (encrypted) information, this isn’t normally MLS because the processing of each domain is performed by independent hardware.  Use of a hypervisor to host the plaintext, cryptographic and ciphertext domains would be an example of a MLS implementation.

MLS is typically used to describe processing multiple classification levels of information on a single hardware processor, https://secure.wikimedia.org/wikipedia/en/wiki/Multilevel_security

The example of a product having a single plaintext port usually would be at a single security level.  A single plaintext port could support MLS if the Operating environment servicing the port supports MLS, possibly hypervisors, and the protocols and hardware for the single port support data separation and/or data labeling.  The systems feeding/receiving data over the port would have to support this MLS solu

Re: Use Cases

Davidson, John A. — 2011-09-19T04:03:20

Lev wrote,

 





 

Without a formal definition of High Assurance, I use the customary connotation that it enforces a policy with near certainty, for cases where gov. secrets are being protected (by gov directive).  When we have a radio that handles gov classified traffic, it is necessarily MLS mode, (MILS is a subset of MLS) and should enforce a policy for non-disclosure of classified and use high assurance mechanisms.  There is no other requirement I know of for high assurance.  The radio must have unclassified IF/RF processes (e.g. modem) and it must have classified processes (e.g. baseband user interfaces).  Even a single level classified radio will necessarily operate in MLS mode as a system.  …and needs Hema’s containers.   

 

So, I am not sure what realistic configuration of a CICM radio, presumably containing a crypto(?), with an antenna on one connector and a classified userdata port on another connector, does NOT need to support MLS.  I guess one is when the userdat

Re: Use Cases

Novikov, Lev — 2011-09-18T14:46:36

Hema,

On 2011-09-14 11:52, Hema Krishnamurthy wrote:

On 2011-09-14 12:23, John Davidson wrote:

On 2011-09-13 15:10, John Fitton wrote:

I was trying to be very careful with this use case, but I went too far. Recall,
that on 2011-09-08 14:14, I wrote:


The point of the use case is to say "CICM should not interfere with systems in 
which there are multiple levels of security" (but it doesn't do anything to help
either). Therefore, I believe that this use cases any and all "container" 
configurations in which there are multiple security levels.


The use case is generic--that CICM should support secure key exchange; the 
analysis will evaluate the feasibility of using those protocols with the CICM 
model.


Perhaps I'm misunderstanding something, but is there some fundamental difference
between this use case and the regular two-domain use case?


Assuming SAD is "Security Association Database", then, no, there aren't 
currently specific CICM API commands for managing the SAD as an entity unto 
itself. Creat

Re: Use Cases

Fitton, John — 2011-09-15T01:02:54

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 pol
 icies. 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 s

Re: Use Cases

Davidson, John A. — 2011-09-14T16:23:09

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: cicm-bounces< at >ietf.org [mailto:cicm-bounces< at >ietf.org] 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

Re: Use Cases

Krishnamurthy, Hema - ES — 2011-09-14T15:51:36

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: cicm-bounces< at >ietf.org [mailto:cicm-bounces< at >ietf.org] 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:

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" i

Re: Use Cases

Novikov, Lev — 2011-09-08T18:14:17

John,

On 2011-08-29 10:27, John Davidson wrote:

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


The use cases are intentionally broad because we are trying to build a framework
which will

Re: Use Cases

Kevin W. Wall — 2011-08-30T15:35:14

Yes; that would be bad. ;-)


I didn't realize that CICM supported key negotiation, but if it does,
I agree that there should be a use case for secure key exchange
to describe it.

-kevin

Re: Use Cases

Novikov, Lev — 2011-08-30T15:04:21

Kevin,

On 2011-08-26 16:34, Lev Novikov wrote:

On 2011-08-26 18:25, Kevin Wall wrote:

Yes. Hopefully we're not resetting the data when we store it.

On 2011-08-26 18:25, Kevin Wall wrote:

I don't think the model should assume that keys were pre-shared. For 
example, CICM currently supports negotiating an asymmetric key which 
results in an ephemeral symmetric key.

See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-8

Therefore, adding a use case for a secure key exchange seems 
reasonable (assuming I understood your proposed case correctly).

Lev

Re: Use Cases

Davidson, John A. — 2011-08-29T14:27:08

Lev, 
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.  

The reason we have to treat all application SW domains as "not
trustworthy" for the latter orientation is that we do not have the
COMPUSEC technology to make software good enough to be trustworthy.  So
we must enforce the policy from externally to the application SW, that
is, from the OE to achieve high assurance.  In a model that
realistically addresses high assurance today, all the software has to do
is stay out of th

Re: Use Cases

Kevin W. Wall — 2011-08-26T22:24:41

I presume that you meant 'at-rest' rather than 'at-reset' here?


What are your assumptions about crypto keys? Are you assuming that
2 parties have already met and shared keys (probably out of band)?
If not, then I could see maybe use cases involving secure key exchange.
However, I suspect that is considered out of scope.

-kevin

Use Cases

Novikov, Lev — 2011-08-26T20:17:52

I started a rewrite of draft-lanz-cicm-lm and want to discuss the use
cases we want included in the Logical Model.

Here's a short list I've got so far:
1. Two networks each in their own security domain (archetypal
   high assurance data-in-transit case)

2. Traditional data-in-transit and -at-reset case (cf. PKCS#11)

3. One network with two security domains (cf. network storage;
   data-in-transit and -at-rest )

4. One machine with two security domains in software (cf. Vincent
   Roca's slides http://www.ietf.org/proceedings/81/slides/cicm-1.pdf)

The resulting model will be used to analyze the impact on existing
protocols where, for example, there might not be separate security
domains.

** Anything else to add to the use case list?

Thanks,
Lev

RFC 5116 (AEAD)

Novikov, Lev — 2011-08-24T17:18:32

[...]
[...]

I've read through RFC 5116 and there doesn't seem to be any reason why
CICM couldn't support AEAD, although it would probably have to be its
own channel type. Here's why:

1. AEAD encryption takes a key (K), a nonce (N), plaintext (P), and
   associated data (A) and outputs ciphertext (C). Decryption takes
   K, N, A, and C and returns P (or FAIL).
   (Simplicity itself!)

2. Since the associated data (A) is sent in the clear, this is similar
   to a CICM::EncryptBypass::Conduit, although the whole bundle is
   authenticated, so it is more like a CICM::Encrypt::WithMACConduit
   --albeit with a single key (K).

   See:
   http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-9.8
   http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-14.5

3. Therefore, it seems like the best way to handle AEAD would be to
   create a new channel type. Specifically, we'd need to support
   creating a conduit just like an EncryptBypass::Conduit (one key,
   one algorithm) that behaved like an Encrypt::With

Re: CICM Scope

Alfonso De Gregorio — 2011-08-16T02:41:49

Lev,

On Mon, Aug 15, 2011 at 11:19 PM, Novikov, Lev <lnovikov< at >mitre.org> wrote:

Absolutely. Thanks for asking.

IPsec is the most natural protocol we should look at, indeed.

In my opinion, the Secure Shell Connection Protocol (RFC 4254) is also
to be consider among the (de-facto) VPN establishment crypto
protocols, if we consider its most popular implementation. Let me
elaborate why this is the case.

As we know, the SSH protocol doesn't provide a VPN establishment
mechanism built-in. However, at the connection layer the IETF standard
defines the channel mechanism and specify the first four basic channel
types. Real world implementations have the possibility to build upon
this mechanism extending the protocol to accommodate new use cases.

This is what OpenSSH did with the tunnel forward extension. As of
version 4.3, OpenSSH supports layer 2 and layer 3 tunnelling via the
"tun< at >openssh.com" channel type. On network endpoints equipped with
pseudo-device interface like the BSD tun(4), this extended channel
t