Novikov, Lev | 20 Feb 14:43 2012
Picon

Taking over High Assurance Crypto Mailing List

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 me privately to discuss a transition of leadership.

Thanks,
Lev
Novikov, Lev | 26 Aug 22:17 2011
Picon

Use Cases

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
Novikov, Lev | 24 Aug 19:18 2011
Picon

RFC 5116 (AEAD)

On 2011-07-27 14:39, David McGrew wrote:
[...]
> 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.
[...]

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).
(Continue reading)

Novikov, Lev | 15 Aug 23:19 2011
Picon

CICM Scope

(Cross-posted on the Cryptography mailing list at randombit.net)

I've been doing a bit of reading based on the comments we've received.

The results of the BOF at IETF 81 suggested we should broaden our
scope and discuss the impact of the CICM Model, particularly Security
Domain Separation, on (2 or more) existing IETF protocols.

Here are the suggestions we've heard to-date (in no particular order):
  * IPsec (suggested by almost everyone)
  * TLS (via Paul Hoffman, David McGrew)
  * AEAD (in RFC 5116; via David McGrew)
  * VPN establishment crypto protocols (via Alfonso De Gregorio)
  * Domain Security Services (as in RFC 3183; via Alfonso De Gregorio)

** Alfonso:
  Can you elaborate on which protocols you had in mind regarding VPN?

It seems clear that, at the very least, we should look at IPsec.

Perhaps first, however, we should put together a crisper version of
draft-lanz-cicm-lm "CICM Logical Model" which we can then use as the
basis for analysis to address questions like: (via David McGrew)

  * What benefit does the CICM model provide in cases where there
    isn't a strict separation between security domains?

  * How can the CICM model operate if only one of the communicating
    parties uses the model?

(Continue reading)

Cottrell Jr., James R. | 3 Aug 16:49 2011
Picon

Re: comments on CICM

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: cicm-bounces <at> ietf.org [mailto:cicm-bounces <at> ietf.org] On Behalf Of Novikov, Lev
Sent: Wednesday, August 03, 2011 10:03 AM
To: CICM Discussion List (cicm <at> ietf.org)
Subject: [cicm] FW: comments on CICM

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:david.a.mcgrew <at> mindspring.com] 
Sent: Wednesday, July 27, 2011 14:39
To: cicm <at> ietf.org; Lanz, Dan; Novikov, Lev
Subject: comments on CICM

Hi Lev and Daniel,
(Continue reading)

Novikov, Lev | 3 Aug 16:03 2011
Picon

FW: comments on CICM

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:david.a.mcgrew <at> mindspring.com] 
Sent: Wednesday, July 27, 2011 14:39
To: cicm <at> ietf.org; 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?)

(Continue reading)

Novikov, Lev | 3 Aug 05:06 2011
Picon

CICM BOF Summary

Last week we had a BOF at IETF 81. Thanks to all who attended (in-person
and via Jabber). For those who couldn't make it, a summary:

--- Begin Summary ---
Dan Harkins and Dan Lanz were the BOF Chairs.

Sean Turner and Stephen Farrell are the Security ADs.

Vincent Roca presented slides about using CICM in a
High Assurance, High Performance Security Gateway.
Slides: http://www.ietf.org/proceedings/81/slides/cicm-1.pdf

Lev Novikov presented slides about CICM's logical model and how
security domain separation makes CICM different from other crypto APIs.
Slides: http://www.ietf.org/proceedings/81/slides/cicm-2.pdf

There were several points of discussion:

1. What about existing approaches:
    * Why can't you extend PKCS#11 so that crypto operations like
      encrypt always return TRUE?

      A few reasons were given:
      (a) CICM needs richer semantics (more and different kinds of
          inputs) than what is available in PKCS#11. Previous attempts
          at extending PKCS#11 became a mess.
      (b) Return values can be more complex than just TRUE (e.g., list
          of things that went wrong).

    * What about using an existing protocol as an interface?
(Continue reading)

James.L.Howard | 26 Jul 19:49 2011

CICM

To the CICM Forum,

 

L-3 Communications Systems East supports approval of the CICM standard by the IETF.  In our view, it is necessary to have a cryptographic module interface specification to enhance standardization of cryptographic products throughout the commercial and government domains.   The common command set and structures described in the CICM standard allow greater reuse of cryptographic products and designs from various suppliers across divergent platforms and applications – thus offering the promise of reducing overall development, integration and test cost for the cryptographic systems.  Such a specification enhances the security posture of future systems we will use, develop, and/or depend on.

 

Thank you for your consideration.

 

 

James L Howard

Director and Chief Engineer, Secure Space and Sensors Systems (S4)

L-3 Communications, Communication Systems-East

1 Federal Street

Camden, NJ 08103

James.L.Howard <at> L-3Com.com

(856) 338-3504

 

_______________________________________________
cicm mailing list
cicm <at> ietf.org
https://www.ietf.org/mailman/listinfo/cicm
Novikov, Lev | 26 Jul 17:47 2011
Picon

CICM BOF Jabber Info

The CICM BOF is still scheduled for Tomorrow (Wed, 2011-07-27) from 
15:10 - 16:10. The jabber room is: cicm <at> jabber.ietf.org

FYI: 
  Participation in the IETF is subject to the NOTE WELL found at:
  http://www.ietf.org/about/note-well.html

  Everything you type is logged!
  http://www.ietf.org/jabber/logs/cicm <at> jabber.ietf.org/

How to Participate (READ INSTRUCTIONS FIRST)
1. Open the audio stream in an audio player (e.g., Windows Media Player)
   http://ietf81streaming.dnsalias.net/ietf/ietf806.m3u
   (This is a room feed, so you can listen to whoever is speaking in that 
   room right now.)

2. You need a public jabber handle. You can get one:
  a. Visit https://register.jabber.org/
  b. Provide a username and password.
  c. Click "Register" (You DO NOT need to download one of their clients)

3. You need a jabber client. You can use a free online one:
  a. Visit http://jwchat.org/
  b. Change "Server" to "jabber.org"
  c. Provide your username and password (from 2b above).
     (You DO NOT need to "Register New Account")
  d. Click "Login" (a new window will pop-up)

4. You need to connect to <cicm <at> jabber.ietf.org>. For jwchat:
  a. Click the group icon (Join Groupchat) in the 
     lower left corner of the popup.
  b. Change "Room" to "cicm",
     "Server" to "jabber.ietf.org" 
     (leave "Password" blank)
  d. Click "Join"

You can join the room at any time (even now!). Please try it out and let me 
know if you have any issues connecting.

Thanks,
Lev
Picon

Benefits of CICM to the Air Force

The AF Cryptographic Modernization Program office believes the utility of CICM lies in the ability to
decouple cryptographic modules from the larger system.  This provides for an ability of cryptographic
services to be updated on a more frequent basis than the typical long lifespan of various Air Force
systems.  In addition in provides flexibility to define a boundary in which the larger system integrator
is free to choose from various cryptographic module vendors based on technical and security
requirements, but still retain an ability to upgrade if a different vendor provides a better technology
in the future.  This is currently not the case typically, because once you select a module vendor you are
utilizing that vendors proprietary API and potentially requires the module vendor to assi
 st in writing higher level system software that utilizes the proprietary API.  In summary this
standardization effort is critical to achieving a modular, open systems approach in the arena o
 f embedded cryptographic systems.

Michael Putney
Lead Information Systems Engineer (MITRE) 
Air Force Cryptographic Modernization Program Office - ESC/HNCGE
Frank.Costantini | 26 Jul 15:23 2011

CICM standard support

To the CICM Forum,

 

L-3 Communications Systems East would like to express support for approval of the CICM standard by the IETF.  Our company produces a variety of cryptographic products for use in tactical Airborne, Man-Portable, Ground, Shipboard and Satellite platforms and also for strategic applications.  The common command set and structure described the CICM standard will allow greater reuse of cryptographic products and designs from various suppliers across divergent platforms and applications while reducing overall development, integration and test cost for the cryptographic system and for the overall platform.

 

Thank you for your consideration.

 

Frank Costantini

Chief Engineer, Information Assurance

L-3 Communication Systems-East
1 Federal Street, AE-3NE, Camden, NJ 08103


 

Attachment (smime.p7s): application/x-pkcs7-signature, 8 KiB
_______________________________________________
cicm mailing list
cicm <at> ietf.org
https://www.ietf.org/mailman/listinfo/cicm

Gmane