Subject: [cicm] BoF Request for CICM at IETF 81

From: "Novikov, Lev" <[email-masked]>
Date: Fri, 13 May 2011 13:01:05 -0400

I'm formally requesting a BoF at IETF 81 to form a CICM WG based on the draft charter below.
Updated version at: http://code.google.com/p/ietf-cicm/wiki/WGCharter
Discussion also at: [email-masked]

Thanks,
Lev

Draft CICM Working Group Charter

= Description of Working Group =
The Common Interface to Cryptographic Modules (CICM) API provides high 
assurance crypto applications with a security framework that accommodates the 
needs of a high assurance environment including security domain separation, 
and enhanced module, key, and channel management capabilities.

The purpose of the CICM Working Group is to shepherd the CICM specification 
documents to publication and provide guidance for any new submissions related 
to high assurance cryptos.

Specifically, the Working Group will:

  * Complete existing requests:
    * replace algorithm strings with OIDs
    * use ABNF notation for unique identifiers syntax
    * add module events for symmetric and asymmetric key filled

  * Shepard the following documents to publication:
    * draft-lanz-cicm
    * draft-lanz-cicm-lm
    * draft-lanz-cicm-mm
    * draft-lanz-cicm-km
    * draft-lanz-cicm-cm

= Goals and Milestones =
TBD   WGLC on draft-lanz-cicm-lm
TBD   WGLC on draft-lanz-cicm
TBD   WGLC on draft-lanz-cicm-mm
TBD   WGLC on draft-lanz-cicm-km
TBD   Submit draft-lanz-cicm to the IESG as Proposed Standard

---

From: "Davidson, John A." <[email-masked]>
Date: Fri, 13 May 2011 10:34:48 -0700

Lev, 
I am wondering if we need to (or even can) clarify what we mean by High
Assurance.  Assurance levels were fairly well-defined under the Orange
Book but that has been grayed out by the move to international flavored
Common Criteria.  Today when we say we are addressing HA, it is no
longer clear to me whether we mean to restrict our view to approaches
that are logically "closed form," or if we mean just a better version of
"best effort," whatever that is.  

In my mind, there are IA critical capabilities we can support with one
that may be ruled out by the other.  

Thanks, 
John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Novikov, Lev
Sent: Friday, May 13, 2011 10:01 AM
To: [email-masked]
Cc: CICM Discussion List ([email-masked])
Subject: [cicm] BoF Request for CICM at IETF 81

I'm formally requesting a BoF at IETF 81 to form a CICM WG based on the
draft charter below.
Updated version at: http://code.google.com/p/ietf-cicm/wiki/WGCharter
Discussion also at: [email-masked]

Thanks,
Lev

= Description of Working Group =
The Common Interface to Cryptographic Modules (CICM) API provides high 
assurance crypto applications with a security framework that
accommodates the 
needs of a high assurance environment including security domain
separation, 
and enhanced module, key, and channel management capabilities.

The purpose of the CICM Working Group is to shepherd the CICM
specification 
documents to publication and provide guidance for any new submissions
related 
to high assurance cryptos.

= Goals and Milestones =
TBD   WGLC on draft-lanz-cicm-lm
TBD   WGLC on draft-lanz-cicm
TBD   WGLC on draft-lanz-cicm-mm
TBD   WGLC on draft-lanz-cicm-km
TBD   Submit draft-lanz-cicm to the IESG as Proposed Standard
_______________________________________________
cicm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cicm

---

From: "Fitton, John" <[email-masked]>
Date: Fri, 13 May 2011 21:56:02 +0000

I would suggest defining High Assurance in terms of  FIPS-140-2 Level 4. Of course FIPS 140-2 refers to the Common Criteria AL4 or higher, but does offer specific criteria to be used in the evaluation. That being said, however, while the stated goal is for a high assurance API, there is nothing in principal which limits the API to high assurance applications. 

I would also point out that the Orange Book (as was the entire original Rainbow series) was targeted at information processing systems. These systems were essentially large data bases with many users gaining access via dedicated terminals, and there are those who would argue that the old  assurance levels, were also not that well defined. As these system evolved and  internet access was introdouced there was additional volumes created to address some of the security issues involved. 

I would argue that nothing in the Rainbow series specifically addressed security requirements or assurance levels for cryptographic modules. 

One advantage of the Common Criteria, is that the meaning of any given Assurance Level for a given application (e.g. a Cryptographic module) can be defined through an evaluation profile. Another advantage is that it is an internationally recognized set of criteria with a group of international evaluation/certification bodies. 

________________________________________
From: Davidson, John A. [[email-masked]]
Sent: Friday, May 13, 2011 1:34 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Lev,

Thanks,
John

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

Thanks,
Lev

= Goals and Milestones =

---

From: "Bourget, Dennis" <[email-masked]>
Date: Fri, 13 May 2011 15:12:15 -0700

I just don't see how any API can provide "high assurance", it is the
implementation of the API, host platform and operating system that would
need to be evaluated to FIPS 140-2 or Common Criteria.  For example, the
API does not and cannot provide domain separation, I suggest that we
strike that text from the charter.

Perhaps the following:

The Common Interface to Cryptographic Modules (CICM) API defines a
"standardized" application interface
for the security services provided by cryptographic modules developed by
multiple vendors. The API supports 
security domain separation, and enhanced module, key, and channel
management capabilities that is vendor agnostic. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fitton, John
Sent: Friday, May 13, 2011 2:56 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

I would suggest defining High Assurance in terms of  FIPS-140-2 Level 4.
Of course FIPS 140-2 refers to the Common Criteria AL4 or higher, but
does offer specific criteria to be used in the evaluation. That being
said, however, while the stated goal is for a high assurance API, there
is nothing in principal which limits the API to high assurance
applications. 

I would also point out that the Orange Book (as was the entire original
Rainbow series) was targeted at information processing systems. These
systems were essentially large data bases with many users gaining access
via dedicated terminals, and there are those who would argue that the
old  assurance levels, were also not that well defined. As these system
evolved and  internet access was introdouced there was additional
volumes created to address some of the security issues involved. 

I would argue that nothing in the Rainbow series specifically addressed
security requirements or assurance levels for cryptographic modules. 

One advantage of the Common Criteria, is that the meaning of any given
Assurance Level for a given application (e.g. a Cryptographic module)
can be defined through an evaluation profile. Another advantage is that
it is an internationally recognized set of criteria with a group of
international evaluation/certification bodies. 

Lev,

Thanks,
John

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

Thanks,
Lev

= Goals and Milestones =

---

From: "Cottrell Jr., James R." <[email-masked]>
Date: Mon, 16 May 2011 13:08:47 -0400

Dennis,

I agree that the API by itself cannot provide "high assurance" but this API has been designed to be targeted for use in high assurance applications.  Not sure how to work this thought into your suggested charter wording.

Jim C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bourget, Dennis
Sent: Friday, May 13, 2011 6:12 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Perhaps the following:

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

Lev,

Thanks,
John

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

Thanks,
Lev

= Goals and Milestones =

---

From: "Fitton, John" <[email-masked]>
Date: Tue, 17 May 2011 12:15:17 +0000

I agree that the API does not provide "high assurance" nor does it "offers security domain separation" as stated in the draft Charter.  How about stating it like this:

"The API is intended to support high assurance cryptography by allowing for security domain separation and includes provisions for enhanced module, key and channel management capabilities that are vendor agnostic."  The fact that there is an API is what allows for security domain separation. 

While an API in and of itself cannot be "high assurance", it is possible to define security policy concerning its application and use that would enable a high assurance implementation. A question then arises, is should the API include a section which includes API related security policies which support high assurance applications.  
________________________________________
From: Cottrell Jr., James R. [[email-masked]]
Sent: Monday, May 16, 2011 1:08 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Dennis,

Jim C.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bourget, Dennis
Sent: Friday, May 13, 2011 6:12 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Perhaps the following:

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

Lev,

Thanks,
John

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

Thanks,
Lev

= Goals and Milestones =

---

From: "Davidson, John A." <[email-masked]>
Date: Tue, 17 May 2011 07:28:20 -0700

This may be a case for just leaving out the "high assurance" (HA) part.
Our APIs support that so-called "necessary evil" bypass which (from my
distorted COMPUSEC background POV) technically contradicts HA.  (From my
background, HA originally implied cross domain flow but only in the down
direction.)  Despite what *any* APIs may aspire to do, an MLS HA OE can
impose rigorous HA on any kind of APIs.  However, if it does, that can
break some applications that expect use APIs that enable prohibited flow
(down.)  

As originally applied to COMPUSEC, HA loosely referred to mechanisms
intended to *absolutely* enforce a particular policy and separate
hierarchical security levels (as mathematical "lattices") underneath
software systems.  As the line between software and cryptos blurs, HA
has migrated into crypto lingo, but it doesn't seem to fit well when
cryptos (and SDRs) are approached as HW wires and components rather than
software.  

In my opinion, there are two approaches to IA in a complex system of
systems, like a SDR.  One is the classical HA COMPUSEC approach that
precludes flow up and allows flow down.  I realize this is contentious,
but I can only say this has a long history of working fine in MLS
processing environments without needing bypass.  The other approach is
the way we did hardware (HW) cryptos, which allows bypass provided it is
"not harmful" (epitomized by header bypass).   There are technical IA
issues with doing the latter with HA because it allows flow down and we
lack a rigorous HA criteria for "not harmful."  That is why bypass is
termed "evil" in the phrase "necessary evil."  I think that while a SDR
contains a crypto, it is more of a generic software MLS application than
a crypto with wires and components.  

To me, supporting HA means supporting the approach above that does not
require crypto bypass, like we used in Blacker, an MLS software FEP.  It
still moved unclassified header to the unclassified processes, but by a
COMPUSEC scheme of isolating flow at the source instead of trying to
inspect bypass object content downstream.  Our APIs allow either.  Since
our APIs do support bypass, it is up to the users not to try to use it
if they expect to run in a conventional HA OE.  I know everyone wants to
call everything HA, (myself included) but to me, allowing HA is not
exactly "supporting" everybody's view of HA, it just blurs the line
between "best effort" and HA.  Isn't our API more about being generic
and allowing the user to make design choices between best effort and
rigorous HA?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Fitton, John
Sent: Tuesday, May 17, 2011 5:15 AM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

I agree that the API does not provide "high assurance" nor does it
"offers security domain separation" as stated in the draft Charter.  How
about stating it like this:

"The API is intended to support high assurance cryptography by allowing
for security domain separation and includes provisions for enhanced
module, key and channel management capabilities that are vendor
agnostic."  The fact that there is an API is what allows for security
domain separation. 

While an API in and of itself cannot be "high assurance", it is possible
to define security policy concerning its application and use that would
enable a high assurance implementation. A question then arises, is
should the API include a section which includes API related security
policies which support high assurance applications.  
________________________________________
From: Cottrell Jr., James R. [[email-masked]]
Sent: Monday, May 16, 2011 1:08 PM
To: CICM Discussion List
Subject: Re: [cicm] BoF Request for CICM at IETF 81

Dennis,

I agree that the API by itself cannot provide "high assurance" but this
API has been designed to be targeted for use in high assurance
applications.  Not sure how to work this thought into your suggested
charter wording.

Jim C.

-----Original Message-----
Bourget, Dennis

Perhaps the following:

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

Lev,

Thanks,
John

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

Thanks,
Lev

= Goals and Milestones =