Subject: [cicm] Use Cases

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 26 Aug 2011 16:17:52 -0400

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

---

From: "Kevin W. Wall" <[email-masked]>
Date: Fri, 26 Aug 2011 18:24:41 -0400

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

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

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

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
-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein

---

From: "Davidson, John A." <[email-masked]>
Date: Mon, 29 Aug 2011 07:27:08 -0700

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 the way (not try to violate rules).  

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.  

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Friday, August 26, 2011 1:18 PM
To: CICM Discussion List ([email-masked])
Subject: [cicm] Use Cases

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

---

From: "Novikov, Lev" <[email-masked]>
Date: Tue, 30 Aug 2011 11:04:21 -0400

Kevin,

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

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

On 2011-08-26 18:25, Kevin Wall wrote:
> If not, then I could see maybe use cases involving secure key 
> exchange. However, I suspect that is considered out of scope.

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

---

From: "Kevin W. Wall" <[email-masked]>
Date: Tue, 30 Aug 2011 11:35:14 -0400

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

Yes; that would be bad. ;-)

> reasonable (assuming I understood your proposed case correctly).

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