Subject: [cicm] FW: comments on CICM

From: "Novikov, Lev" <[email-masked]>
Date: Wed, 3 Aug 2011 10:03:23 -0400

FYI: Below is an insightful email from David McGrew that does not 
appear to have made it to the mailing list nor was it held for 
moderation so the list never saw it.

Lev

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 14:39
To: [email-masked]; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,

I skimmed the CICM documents and have several comments.

It seems that the major goal for CICM is multi-vendor support.   
Worthwhile goal, but what crypto hardware vendors whose products  
support IETF standards are participating in this effort?

RFC 5116 defines a standard interface to Authenticated Encryption with  
Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH,  
SRTP, IKE, and SMIME, and is backwards compatible with ESP.   The AEAD  
interface is simple (two defined messages, four inputs and one output  
each), and AEAD is widely regarded as the state of the art in security  
and efficiency (including both OCB and GCM, for instance).  It appears  
that CICM is not compatible with this interface, in which case it  
would be a real step backwards.  (If CICM does support AEAD, it is not  
clear to me how it does.  Am I missing something?)

CICM is intended for use in a high assurance crypto module.   
Considering that AES-GCM is required for Suite B, and the Suite B RFCs  
all cite RFC 5116, the lack of AEAD support appears problematic.

The use cases for which CICM is intended are those where  
"cryptographic transformation of data initiated in one security        
domain with the result made available in another security domain";  
three cases are given, two of which are HAIPE.  So clearly the CICM  
design has been driven by high assurance requirements that are highly  
security conscious and not publicly available.   My question here is:  
how will the CICM design make implementations of IETF security  
protocols better?   If CICM is tightly bound to non-public protocols,  
it will not have much relevance to the IETF.   On the other hand, if  
there is a document that shows how a high assurance design approach  
can be used in an IETF standard like TLS or IPsec, that could be  
valuable.   It could be a good contribution to the IETF to provide  
implementation criteria or design approaches that are applicable to  
internet standards.  I think there would be a good amount of interest  
in this sort of work, and in fact I would be very happy to see that  
sort of document show up in IRTF CFRG.

An important nit: MD5 is used as an example on pg 24 of draft-lanz- 
cicm-02.  It has been deprecated by RFC 6151; I encourage that a  
different hash be used as an example.

regards,

David

---

From: "Davidson, John A." <[email-masked]>
Date: Wed, 3 Aug 2011 07:40:00 -0700

Interesting, Dave.  

Could you expand on your comment:   
"On the other hand, if there is a document that shows how a high
assurance design approach can be used in an IETF standard like TLS or
IPsec, that could be  
valuable."

I was pondering whether there was a distinction underlying that comment?
Like did you mean an approach that allows TLS or IPsec to terminate in a
high assurance domain, or did you mean how to implement the protocols in
a high assurance OE, or did you mean how to make protocol software be
trustworthy?  Or how to hook them up to the crypto?  Or something else?

I too see the HAIPE influence on this.  As I have said, I frankly have a
quibble with the way HAIPE is structured, its assumed domains are
structured to need crypto bypass to work, that seems to be so widely
assumed to be a fundamental need for secure comms (from the HW crypto
legacy).  I just don't see it that way.  

Thanks, 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Wednesday, August 03, 2011 7:03 AM
To: CICM Discussion List ([email-masked])
Subject: [cicm] FW: comments on CICM

Lev

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 14:39
To: [email-masked]; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,

regards,

David

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

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Wed, 3 Aug 2011 10:49:23 -0400

David McGrew,

In your email you stated " Considering that AES-GCM is required for Suite B, and the Suite B RFCs  
all cite RFC 5116, the lack of AEAD support appears problematic"

Can you please provide an authoritative document stating this requirement?

Thanks,

Jim Cottrell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, August 03, 2011 10:03 AM
To: CICM Discussion List ([email-masked])
Subject: [cicm] FW: comments on CICM

Lev

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 14:39
To: [email-masked]; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,

regards,

David

---

From: "Krishnamurthy, Hema - ES" <[email-masked]>
Date: Wed, 3 Aug 2011 10:52:01 -0400

http://tools.ietf.org/html/rfc4869 lists AES-GCM as part of Suite B.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cottrell Jr., James R.
Sent: Wednesday, August 03, 2011 7:49 AM
To: CICM Discussion List
Subject: Re: [cicm] comments on CICM

David McGrew,

Thanks,

Jim Cottrell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, August 03, 2011 10:03 AM
To: CICM Discussion List ([email-masked])
Subject: [cicm] FW: comments on CICM

Lev

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]]
Sent: Wednesday, July 27, 2011 14:39
To: [email-masked]; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,

regards,

David

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: "David A. McGrew" <[email-masked]>
Date: Wed, 3 Aug 2011 11:15:43 -0700

> Can you please provide an authoritative document stating this  

Let me use TLS as an example.  The AEAD facility in TLS 1.2 is based  
on RFC 5116.  For Suite B, RFC 5430 requires RFC 5289, which requires  
RFC 5288, which has RFC 5116 as a normative reference.

In the quote above, I said "all".  I may have been wrong on that; I  
was rushing to get my comments out before the CICM BoF.  But I stand  
by the broader point, which is that support for AEAD would be essential.

David

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Wed, 3 Aug 2011 17:05:15 -0400

Hema,

Thanks.

Not all Suite B products will be IPsec.  I believe Harris has a Suite B tactical radio.  For protection of voice traffic, I wouldn't think that they used AES-GCM.

Jim Cottrell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cottrell Jr., James R.
Sent: Wednesday, August 03, 2011 7:49 AM
To: CICM Discussion List
Subject: Re: [cicm] comments on CICM

David McGrew,

Thanks,

Jim Cottrell

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Novikov, Lev
Sent: Wednesday, August 03, 2011 10:03 AM
To: CICM Discussion List ([email-masked])
Subject: [cicm] FW: comments on CICM

Lev

-----Original Message-----
From: David A. McGrew [mailto:[email-masked]]
Sent: Wednesday, July 27, 2011 14:39
To: [email-masked]; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,

regards,

David

---

From: "David A. McGrew" <[email-masked]>
Date: Wed, 3 Aug 2011 15:02:58 -0700

Hi Jim,

http://tools.ietf.org/html/draft-peck-suiteb-dtls-srtp-00 requires AES- 
GCM, and is presumably intended for VoIP, though it does not  
specifically mention VoIP.

Suite B RFCs have shown a clear preference for GCM, though some other  
modes are allowed (as transitional in TLS, and within IKE but not ESP).

David

On Aug 3, 2011, at 2:05 PM, Cottrell Jr., James R. wrote:

> Hema,
>
> Thanks.
>
> Not all Suite B products will be IPsec.  I believe Harris has a  
> Suite B tactical radio.  For protection of voice traffic, I wouldn't  
> think that they used AES-GCM.
>
> Jim Cottrell
>
> 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: "David A. McGrew" <[email-masked]>
Date: Thu, 4 Aug 2011 05:36:57 -0700

Hi John,

> trustworthy?  Or how to hook them up to the crypto?  Or something  

I didn't have any specific ideas in mind.

> legacy).  I just don't see it that way.

I was wondering how we can make this work have a positive impact on  
Internet practice.  I think this is one of CICM two goals, the other  
being to impact non-Internet practice that I'm not familiar with and  
can't comment on (I don't have any experience with HAIPE myself).

On the goal of improving the state of the art of IETF security  
protocol implementation, there are a lot of open questions, and it  
would be essential to investigate the details of how the CICM model  
could work with Internet protocols.  The CICM model (in which there is  
a secure side, and insecure side, and a crypto module between, and  
there are two messages queues that connect the module to each side,  
and don't pass any information back) is far from current practice for  
IETF security protocols.  I assume that the goal for using a queue as  
an interface is to prevent side channels that could pass information  
from one side to the other.   This could prevent a subliminal channel  
that could potentially be exploited by an untrustworthy application on  
the secure side to slowly leak information out to the insecure side, I  
suppose, which would be good in an implementation environment that  
already has strong separation between secure/insecure sides.   But how  
many implementations of IETF protocols support such strong  
separations?    This raises the question: what benefit does the CICM  
model provide in cases where there is no such separation?

For improving current Internet practice, there are some other problem  
areas that in my opinion deserve to be addressed first, including  
reducing implementation flaws and the possibilty of remote timing  
attacks.  Perhaps a message queue could be used to defeat timing  
attacks (like those against exponentiation algorithms or typing  
patterns in text-oriented protocols), though I am not sure if that is  
an explicit goal.   But increased implementation complexity would  
likely increase the number of implementation flaws.   At any rate,  
defeating a timing attack doesn't require hiding return codes from a  
calling application.  Perhaps there is another class of attacks being  
addressed by that approach, though I'm not quite sure what it protects  
against.

The idea of having a queue (or two?) in between the plaintext and  
ciphertext sides raises some interesting questions about networking,  
such as: what is the impact on latency, jitter, retransmission timers,  
TCP startup time?   how bad is the impact on bufferbloat?   what  
protocols can run over these queues without impact, and what ones  
could not?

The practice of not providing return codes to a secure-side  
application sending a packet, even when that packet couldn't be sent,  
would also have an impact.  What about "no route to host" and MTUs?

A secure-side application can get information back through messages  
that it receives from its peer in the cryptographic protocol.  Thus,  
if it is a goal to prevent information from the insecure side from  
getting into the secure side, it would appear that it would be a  
requirement in this security model to have both sides of the crypto  
protocol use the same model.  That is, some of the security properties  
that would accrue from using the CICM model would be voided if only  
one of the communicating parties used that model.

It seems to me that the protocol that best matches the CICM model is  
IPsec, but there are still many open questions about how it could  
work, such as: how would this map onto the idea of an IPsec Security  
Association Database?   Where would the different parts of the IPsec  
architecture reside?   What would happen to information that needs to  
be copied from one side to the other, such as a ToS byte?   what  
happens to how ICMP gets handled in IPsec?

I personally feel that work on improving the practice of security  
protocol implementations would be valuable, but that the best approach  
would be to identify the most significant threats and vulnerabilities,  
then work on mitigating them.   For instance, it would be worthwhile  
to develop an interface to cryptography that kept details about  
initialization vectors inside the crypto module, since it is widely  
regarded that IVs can be a problem area.  But if there is interest in  
applying the CICM model to Internet practice, I would suggest starting  
with the applicability questions that other people and I have raised  
(Paul Hoffman had some good suggestions in the BoF), and I would be  
willing to participate at least as a reviewer.

Apologies for the somewhat rambling email.

David

---

From: "Davidson, John A." <[email-masked]>
Date: Thu, 4 Aug 2011 07:36:06 -0700

Wow, what insightful questions, David.  The short answer is I don't
know.  But that won't deter me from rambling about it.  I wish I knew
how to approach some of your questions with high assurance IA solutions.

I have never seen a formal definition of high assurance (HA), so when we
talk about that we sometimes talk past each other.  To me, from a formal
methods perspective, high assurance means a near certainty that SOME IA
security policy is successfully enforced.  Less than HA may be good
enough to protect from casual threats but it takes HA to protect against
determined subversion.  

We have figured out the constraints we must impose on stuff to enforce
some IA policies, like Bell-LaPadula [BLP] for example.  Other policies
(integrity and availability) we haven't even figured out how to express
the policy formally, let alone enforce that with HA.  But we have even
figured out how to impose those constraints on SW by using HW mechanisms
in the microprocessor.  We still have not figured out how to make SW
high assurance though.  So from my perspective, approaches (such as
guards and SW imposed domains) that rely (at all) on SW to behave or
work correctly in some way are not going to be HA today.  That means
they should not be relied on to protect military classified data.  

I am involved with enforcing military security policies, namely
BLP-like, or "don't disclose classified data", because it is the only
thing we know how to do with HA.  But BLP has little or no applicability
to the non-military, commercial, internet world, where we lack security
classification levels and formal employee clearance levels.  

Without giving it enough thought, my knee-jerk approach might be to try
to define the security policies we wish we could enforce, then try to
express them formally.  This is hard.  Then try to figure out how to
enforce those with HW if we want HA.  Short of that SW enforcement is
likely to fall to subversion eventually.  

>From a real system IA standpoint, the kind of strategies that enforce
"don't disclose military classified" is first defining security domain
properties.  Then we hook up the crypto to those domains securely,
keeping connections and flows separated with HW-backed mechanisms, and
controlling the data flow with HW-backed mechanisms to and from the
crypto module so that nothing can physically flow that we do not allow.
Then we have to control the crypto module such that it physically cannot
do something illegal, maybe using some kind of HW-backed mechanisms that
"know" the domain properties and rules, having them "wired in".  We have
been this rigorous on a few systems but we have kinda strayed from that
kind of rigor recently.  Not sure why, because it is really more
expensive and harder to use to do it the way we now try to do it, with
SW only.  Seems like if we could figure out some rules at a low enough
level that we can impose to imply whatever policy we want to enforce, we
might find a similar way to apply HA more broadly.  That too is hard.  

Now I am concerned that I should have thought a little longer and harder
about my response.  Oh well, Im not erasing it now.  

Kindest regards,
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
David A. McGrew
Sent: Thursday, August 04, 2011 5:37 AM
To: CICM Discussion List
Subject: Re: [cicm] FW: comments on CICM

Hi John,

David

---

From: jmitola <[email-masked]>
Date: Thu, 04 Aug 2011 12:16:37 -0400

Hi, John
   I'm an academic who just this week has signed three different Non 
Disclosure Agreements (NDAs) where we promise not to disclose technical 
content of a proposal, and we also promise to pass through financial 
information or to provide pointers so that the subcontractor can send 
their financial data directly to the government without going through 
us.  It is a lot of work keeping the various NDA'd materials protected.
   In addition, I just did a hiring action where personally identifiable 
data (PID) was used in an email, the disclosure of which would violate 
the Full Accountability in Credit Transactions Act (FACTA).  Disney is 
supposed to pay $3M for violating the rights of children by sharing 
their email addresses with a third party, they claim accidentally 
violating the recent children on line privacy protection act.
   The protection of NDAs and PID, I would assert, is exactly like the 
protection of different security levels in a MLS environment.  I say 
this as a recent DoD government guy well acquainted with HAIPE and 
WikiLeaks.
   So the ability of CICM to pass through non-sensitive data (most of 
the data would be non-sensitive, so there is a lack of symmetry) while 
encrypting protected NDA data would be a huge boon to the commercial 
sector.  Content filtering to flag personally identifiable data to 
encrypt it in such a way that only authorized recipients can decrypt it 
also would have saved Disney $3M.  The mix of sensitive versus 
pass-through probably is inverted between HAIPE and NDA/PID, but I don't 
think there is a lot of difference once you allow both in some mix, even 
though the purposes are different.
   I'm offering this use case to the CICM community because there are a 
dozen pieces of cybersecurity legislation on the Hill that will drive 
commercial encryption technology so far beyond where we are today that 
full HAIPE will look like child's play by comparison.  Paragraph 
markings like (NDA) on a paragraph or <PID> somebody's ssn </PID> seem 
to be on the way sooner rather than later.  Specific people such as your 
doctor, the RN, the LPN, the person who bills your insurance company and 
you all will have different authorizations for your PID such as your DNA 
and even the MD may not get to know what your GYN or oncologist get to 
see.  So if you can imagine a matrix of permissions by content and by 
current role (the RN may bill the insurance company in a small medical 
practice), then that is where the commercial sector is heading on the 
medical front.  Similar ideas are in play in smart grids, privacy 
communities (e.g. for control of Facebook data), etc.  PKI here we 
come.  Making all of this user-friendly will require content tagging at 
its source as well as content screening of legacy systems so that the 
red/black boundary permeability becomes real in the commercial sector 
and movement through that boundary, with different keys and maybe 
different crypto systems for different commercial content (AIS and its 
variations may not be adopted by everybody).
   Thus, I don't think of CICM as a niche API for DoD but as an enabler 
for broad commercial leverage of foundations that DoD has laid.  Just 
like the arpanet/ Internet, I expect CICM and crypto commercialization 
to leap beyond its DoD roots.  But sometimes when I make such 
predictions, I'm wrong by a decade or two.  For example, when I coined 
the term software radio in 1990, I expected it to be here by now.  RF 
front ends still are not very programmable even thought the term is in 
the radio engineering lexicon.  Similarly, CICM may not go big 
commercially during the next year or two as I predict, but that's why 
I'm resolutely on the CICM list, if mostly as an observer.
   In any event I hope you find the medical and smart grid use cases 
interesting, if a bit of a stretch at present.
   - joe

-- 
Dr. Joseph Mitola III, Fellow of the IEEE
DoD Systems Engineering Research Center (SERC) Director of Special Projects
Distinguished Professor, Vice President for the Research Enterprise
Stevens Institute of Technology, Hoboken NJ
Cell - 703.314.5709

---

From: Alfonso De Gregorio <[email-masked]>
Date: Thu, 4 Aug 2011 18:36:26 +0200

Hi all,

On Thu, Aug 4, 2011 at 2:36 PM, David A. McGrew
<[email-masked]> wrote:
> On the goal of improving the state of the art of IETF security protocol
> implementation, there are a lot of open questions, and it would be essential
> to investigate the details of how the CICM model could work with Internet
> protocols.  The CICM model (in which there is a secure side, and insecure
> side, and a crypto module between, and there are two messages queues that
> connect the module to each side, and don't pass any information back) is far
> from current practice for IETF security protocols.  I assume that the goal
> for using a queue as an interface is to prevent side channels that could
> pass information from one side to the other.   This could prevent a
> subliminal channel that could potentially be exploited by an untrustworthy
> application on the secure side to slowly leak information out to the
> insecure side, I suppose, which would be good in an implementation
> environment that already has strong separation between secure/insecure
> sides.   But how many implementations of IETF protocols support such strong
> separations?    This raises the question: what benefit does the CICM model
> provide in cases where there is no such separation?
>
> For improving current Internet practice, there are some other problem areas
> that in my opinion deserve to be addressed first, including reducing
> implementation flaws and the possibilty of remote timing attacks.  Perhaps a
> message queue could be used to defeat timing attacks (like those against
> exponentiation algorithms or typing patterns in text-oriented protocols),
> though I am not sure if that is an explicit goal.   But increased
> implementation complexity would likely increase the number of implementation
> flaws.   At any rate, defeating a timing attack doesn't require hiding
> return codes from a calling application.  Perhaps there is another class of
> attacks being addressed by that approach, though I'm not quite sure what it
> protects against.

David, I believe your post raises a number of relevant questions.
Investigating them can really help us in describing -- maybe a topic
for a new ID? -- how the CICM model could work with Internet
protocols.

While the CICM model can be beneficial in enforcing the star-property
(therefore, mitigating the information leak and contributing towards
the overall confidentiality), it can help us in providing also
stronger integrity guarantees.

Let's consider, for example, systems implementing strong isolation
between different security domains or even system-level components
(e.g., networking, or storage), so that their compromise don't affect
the integrity of the rest of the system. In the open-source world,
this is the case of Qubes, where security domains are lightweight
virtual machines (VM) and the networking code, including drivers and
protocol stacks, has been confined  (using IOMMU/VT-d) to an
unpriviledged VM, called the Network Domain.

The CICM model would fit well into this class of architectures, where:
- the "Network Domain" (or the communication channel) is the insecure side;
- the crypto module can be run in a separate domain (*), isolated from
the world-facing networking code that might be exploited, sooner or
later;
- security protocols (e.g, VPN protocols) are also implemented in
separate domains, exposing their services (e.g., virtual network
interfaces) to the other privileged domains.

(*) far from suggesting that isolation mechanisms based on IOMMU/VT-d
are sufficient per se in achieving high assurance.

Hence, from a security architecture perspective, CICM may have a
positive impact in both the confidentiality and integrity guarantees
provided by IETF protocol implementations.

Which protocols?

> It seems to me that the protocol that best matches the CICM model is IPsec,
> but there are still many open questions about how it could work, such as:
> how would this map onto the idea of an IPsec Security Association Database?
>   Where would the different parts of the IPsec architecture reside?   What
> would happen to information that needs to be copied from one side to the
> other, such as a ToS byte?   what happens to how ICMP gets handled in IPsec?

Agreed. IPsec looks to be the best match, as well all cryptographic
protocols supporting the establishment of VPN connections.

I'm thinking also about domain security services, such as those
described by RFC 3183 (Domain Security Services using S/MIME).

> I personally feel that work on improving the practice of security protocol
> implementations would be valuable, but that the best approach would be to
> identify the most significant threats and vulnerabilities, then work on
> mitigating them.   For instance, it would be worthwhile to develop an
> interface to cryptography that kept details about initialization vectors
> inside the crypto module, since it is widely regarded that IVs can be a
> problem area.  But if there is interest in applying the CICM model to
> Internet practice, I would suggest starting with the applicability questions
> that other people and I have raised (Paul Hoffman had some good suggestions
> in the BoF), and I would be willing to participate at least as a reviewer.
>

I'd be super happy to join the CICM activities, in the way the group
believes to be best.

alfonso

-- 
 tweets @secYOUre      blog. http://Plaintext.crypto.lo.gy/