Subject: [cicm] Channel and Conduit

From: "Krishnamurthy, Hema - ES" <[email-masked]>
Date: Wed, 9 Mar 2011 11:04:10 -0500

Lev,

What's the difference between a channel and a conduit? Would a conduit need to be used irrespective of whether it's a single or a multi-domain security system?

-Hema

________________________________
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.

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 9 Mar 2011 11:07:14 -0500

Hema,

On 2011-03-09 11:04, Hema Krishnamurthy wrote:
> What's the difference between a channel and a conduit? 
> Would a conduit need to be used irrespective of whether 
> it's a single or a multi-domain security system?

In CICM a "channel" is the high level abstraction that refers to any 
cryptographic transform while a "conduit" is a specific type of channel--
one that manages the configuration (like a "controller") AND manages the 
data flow (like a "stream"). In a single domain you only have conduits 
because you cannot separate the controller from the stream like you can 
when you have multiple domains.

See <http://tools.ietf.org/html/draft-lanz-cicm-lm-00#appendix-A>:
   $ channel

      Abstraction under which one or more cryptographic transforms are
      performed and within which all details associated with the
      transform are encapsulated, including the path through the module.
      See also conduit, controller, and stream.

   $ conduit

      Abstraction that encapsulates channel control and data flow.  See
      also channel, controller, and stream.

   $ controller

      Abstraction used to configure and control a channel.  See also
      channel, conduit, and stream.

   $ stream

      An abstraction representing an entity utilizing an existing
      controller to enable data to be sent to a module to be transformed
      and transformed data to be received using a controller as a
      foundation.

Also see Figure 7 in <http://tools.ietf.org/html/draft-lanz-cicm-lm-00#section-5>

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Wed, 9 Mar 2011 08:16:13 -0800

Novikov, 
Could you give me a few words on why the channel cannot be separated
from the stream in a single domain.  The concern I had was that the
control (is that the channel?) often needs to be isolated from the
stream in several dimensions (e.g. integrity + secrecy.)  
Thanks, 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, March 09, 2011 8:07 AM
To: CICM Discussion List
Subject: Re: [cicm] Channel and Conduit

Hema,

In CICM a "channel" is the high level abstraction that refers to any 
cryptographic transform while a "conduit" is a specific type of
channel--
one that manages the configuration (like a "controller") AND manages the

   $ conduit

   $ controller

   $ stream

Also see Figure 7 in
<http://tools.ietf.org/html/draft-lanz-cicm-lm-00#section-5>

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

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 9 Mar 2011 11:52:48 -0500

John,

> stream in several dimensions (e.g. integrity + secrecy.)  

Just to clarify, when I say "controller" and "stream" I'm referring to
the type of API objects that are returned to the client program; not
what is happening inside the crypto.

Also, I realize now that I need to qualify my statement more carefully.
In CICM there are three namespaces that produce "single domain" channels:
CICM::Emit (Random, Pseudorandom, etc.), CICM::Answer (Hash, Sign, Verify), 
and CICM::Coprocessor (Encrypt, Decrypt in a single domain).

CICM::Emit contains Controllers and Conduits because you may want to emit
data out of the module to another domain (using a Controller; you control 
the Channel, but don't see the data) but you may also want to retrieve 
the data into the current domain (using a Conduit; you control the Channel 
AND you see the data).

CICM::Answer and CICM::Coprocesser only have Conduits because the client
program that creates a Channel in a single domain also sees the results
of that Channel (control the channel AND you see the data = Conduit).

Technically, this is a design choice-- we could have said that multiple
client programs are involved in a single domain operation (e.g., one to
create the Channel and another to send the data and receive the result).
However, coordinating this process for single domain Channels is harder
when there isn't something like an external port as there is in a
typical multi-domain high assurance scenario.

Regarding your point about integrity and secrecy:
CICM::Coprocessor channels come in several flavors including those that 
combine secrecy and integrity. Again, this discussion is about what happens
in the client program, not what happens in the crypto.

See <http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-18>.

Let me know if this addresses your concern. If not, I can elaborate more
on the origin of the Controller and Stream concepts and why you can't get
at them separately in a single domain.

Lev

---

From: "Davidson, John A." <[email-masked]>
Date: Wed, 9 Mar 2011 09:19:04 -0800

It does, thanks, Lev.  Its clear (-er.)  I see I need to reread the doc
(when Im not so swamped).  
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, March 09, 2011 8:53 AM
To: CICM Discussion List
Subject: Re: [cicm] Channel and Conduit

John,

Also, I realize now that I need to qualify my statement more carefully.
In CICM there are three namespaces that produce "single domain"
channels:
CICM::Emit (Random, Pseudorandom, etc.), CICM::Answer (Hash, Sign,
Verify), 
and CICM::Coprocessor (Encrypt, Decrypt in a single domain).

CICM::Emit contains Controllers and Conduits because you may want to
emit
data out of the module to another domain (using a Controller; you
control 
the Channel, but don't see the data) but you may also want to retrieve 
the data into the current domain (using a Conduit; you control the
Channel 
AND you see the data).

Regarding your point about integrity and secrecy:
CICM::Coprocessor channels come in several flavors including those that 
combine secrecy and integrity. Again, this discussion is about what
happens
in the client program, not what happens in the crypto.

Let me know if this addresses your concern. If not, I can elaborate more
on the origin of the Controller and Stream concepts and why you can't
get
at them separately in a single domain.

Lev

---

From: "Krishnamurthy, Hema - ES" <[email-masked]>
Date: Wed, 9 Mar 2011 12:40:41 -0500

So, if I have a single security domain only system with a single client program, to encrypt/decrypt, would I use the CoProcessor namespace or would I just use the Encrypt/Decrypt ones?

Hema

-----Original Message-----

John,

Lev

---

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 9 Mar 2011 12:46:55 -0500

Hema,

On 2011-03-09 12:41, Hema Krishnamurthy wrote:
> So, if I have a single security domain only system with a single client program, 
> to encrypt/decrypt, would I use the CoProcessor namespace or would I just use 
> the Encrypt/Decrypt ones?

If you only have a single domain (e.g., storing encrypted data to a database),
you would create a CICM::Coprocessor::Encrypt (or ::Decrypt) conduit because
you want the result of the encrypt (or decrypt) operation to return to the
same client program that asks to encrypt (or decrypt) the data.

You would use the CICM::Encrypt and CICM::Decrypt channels in a more typical
high assurance scenario in which the results of the operation are not in the same
domain that initiates the operation.

Lev

---

From: "Krishnamurthy, Hema - ES" <[email-masked]>
Date: Wed, 9 Mar 2011 14:47:30 -0500

Thanks Lev! That definitely cleared up some things for me.

Hema

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, March 09, 2011 10:47 AM
To: CICM Discussion List
Subject: Re: [cicm] Channel and Conduit

Hema,

Lev