From lnovikov@mitre.org Tue Aug 2 20:07:15 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F0711E80F7 for ; Tue, 2 Aug 2011 20:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9f1smXUsBwH for ; Tue, 2 Aug 2011 20:07:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDB711E8081 for ; Tue, 2 Aug 2011 20:07:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A89F921B1612 for ; Tue, 2 Aug 2011 23:07:22 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A40CF21B078B for ; Tue, 2 Aug 2011 23:07:22 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 2 Aug 2011 23:07:22 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Tue, 2 Aug 2011 23:06:00 -0400 Thread-Topic: CICM BOF Summary Thread-Index: AcxRikXVBtVd6HzwS/Wc900oQWt4TA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] CICM BOF Summary X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:07:15 -0000 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? CICM could sit under such a protocol; it is also intended manage the crypto (note the large number of management commands), and not just the pipe (channel). * Which approach, C-style or object-oriented, was intended? The .NET crypto classes might be suitable for an object-oriented approach. CICM is defined in IDL for which one can generate bindings in many different languages including C, C++, Java, etc. We will have to investigate the .NET approach further. ** There was a request that folks on the list discuss these issues for the benefit of the community. 2. The charter is insufficient for a Working Group: * It was noted that there could be two goals: (a) to produce multi-vendor support for a standard interface (b) to introduce these concepts into existing IETF protocols * The charter appears to be too detailed; it should focus more on outlining the problem scope well. * CICM appears to address requirements that are not well explained in published documents. * How would CICM work with Authenticated Encryption with Authenticated Data [RFC 5116], TLS, or IPSEC? What are the consequences on other protocols? The major consequence of these points is that we should re-write the charter and write documents to address the: * larger problem scope * logical model (in more generic terms) and requirements * impact of this logical model on 2-3 existing protocols * details for an corresponding API (e.g., CICM) --- End Summary --- More on this to follow. Lev From kevin.w.wall@gmail.com Tue Aug 2 20:15:09 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D4911E80F7 for ; Tue, 2 Aug 2011 20:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJsMry341ZPd for ; Tue, 2 Aug 2011 20:15:08 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id D3AC611E8081 for ; Tue, 2 Aug 2011 20:15:07 -0700 (PDT) Received: by wwg11 with SMTP id 11so3063602wwg.1 for ; Tue, 02 Aug 2011 20:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=QNM5LERayTjDnwYmG6oW4qlneCigTpz48BbT3TJTgT4=; b=Y1Bg35kX5Hs3NYUO8xVdgJOt/Hu4DxZ17YuOYCRAMn+T5Hx1iBvXnj8Qw/oRwQ7F7Y yhJNCRos1cDafDVoDgMjp+vefYh9fPJNxXscJF32ClWmAQxtyd8tSb1fOsZylzGL1tr8 bW/kzEEfVqaYMYF0xz3UZexs8OSTzzgCTRgfw= MIME-Version: 1.0 Received: by 10.227.42.203 with SMTP id t11mr1587493wbe.53.1312341317691; Tue, 02 Aug 2011 20:15:17 -0700 (PDT) Received: by 10.227.157.135 with HTTP; Tue, 2 Aug 2011 20:15:17 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Aug 2011 23:15:17 -0400 Message-ID: From: "Kevin W. Wall" To: CICM Discussion List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cicm] CICM BOF Summary X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 03:15:09 -0000 Lev, I think you ought to post this summary to the crypto list at . -kevin On Tue, Aug 2, 2011 at 11:06 PM, Novikov, Lev wrote: > 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: > =A0 =A0* Why can't you extend PKCS#11 so that crypto operations like > =A0 =A0 =A0encrypt always return TRUE? > > =A0 =A0 =A0A few reasons were given: > =A0 =A0 =A0(a) CICM needs richer semantics (more and different kinds of > =A0 =A0 =A0 =A0 =A0inputs) than what is available in PKCS#11. Previous at= tempts > =A0 =A0 =A0 =A0 =A0at extending PKCS#11 became a mess. > =A0 =A0 =A0(b) Return values can be more complex than just TRUE (e.g., li= st > =A0 =A0 =A0 =A0 =A0of things that went wrong). > > =A0 =A0* What about using an existing protocol as an interface? > > =A0 =A0 =A0CICM could sit under such a protocol; it is also intended mana= ge > =A0 =A0 =A0the crypto (note the large number of management commands), and= not > =A0 =A0 =A0just the pipe (channel). > > =A0 =A0* Which approach, C-style or object-oriented, was intended? The .N= ET > =A0 =A0 =A0crypto classes might be suitable for an object-oriented approa= ch. > > =A0 =A0 =A0CICM is defined in IDL for which one can generate bindings in = many > =A0 =A0 =A0different languages including C, C++, Java, etc. We will have = to > =A0 =A0 =A0investigate the .NET approach further. > > =A0** There was a request that folks on the list discuss these issues for > =A0 =A0 the benefit of the community. > > 2. The charter is insufficient for a Working Group: > > =A0 =A0* It was noted that there could be two goals: > =A0 =A0 =A0(a) to produce multi-vendor support for a standard interface > =A0 =A0 =A0(b) to introduce these concepts into existing IETF protocols > > =A0 =A0* The charter appears to be too detailed; it should focus more > =A0 =A0 =A0on outlining the problem scope well. > > =A0 =A0* CICM appears to address requirements that are not well explained > =A0 =A0 =A0in published documents. > > =A0 =A0* How would CICM work with Authenticated Encryption with > =A0 =A0 =A0Authenticated Data [RFC 5116], TLS, or IPSEC? What are the > =A0 =A0 =A0consequences on other protocols? > > The major consequence of these points is that we should re-write the > charter and write documents to address the: > =A0* larger problem scope > =A0* logical model (in more generic terms) and requirements > =A0* impact of this logical model on 2-3 existing protocols > =A0* details for an corresponding API (e.g., CICM) > > --- End Summary --- > > More on this to follow. > > Lev > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > --=20 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." =A0 =A0 =A0 =A0-- Nathaniel Borenstein From jmitola@stevens.edu Wed Aug 3 05:41:09 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4D21F87C7 for ; Wed, 3 Aug 2011 05:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQRcHyvP-6h5 for ; Wed, 3 Aug 2011 05:41:08 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with SMTP id 5442121F87C6 for ; Wed, 3 Aug 2011 05:41:07 -0700 (PDT) Received: from nexus.stevens.edu ([155.246.14.12]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTjlB6Eficyzx/2oyxTycfaLQpcal65qW@postini.com; Wed, 03 Aug 2011 05:41:20 PDT Received: from [192.168.1.146] (c-76-106-141-63.hsd1.fl.comcast.net [76.106.141.63]) (Authenticated sender: jmitola) by nexus.stevens.edu (Postfix) with ESMTPSA id 3B20C300620 for ; Wed, 3 Aug 2011 08:41:12 -0400 (EDT) Message-ID: <4E3941E3.5090000@stevens.edu> Date: Wed, 03 Aug 2011 08:41:07 -0400 From: jmitola User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: CICM Discussion List References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cicm] CICM BOF Summary X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 12:41:09 -0000 Hi, Lev Is NIST working on a CICM-equivalent standard as a follow-on to FIPS 140-3? Sorry I could not make IETF 81, but I remain interested in the working group's charter and technical work. joe On 8/2/2011 11:06 PM, Novikov, Lev wrote: > 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? > > CICM could sit under such a protocol; it is also intended manage > the crypto (note the large number of management commands), and not > just the pipe (channel). > > * Which approach, C-style or object-oriented, was intended? The .NET > crypto classes might be suitable for an object-oriented approach. > > CICM is defined in IDL for which one can generate bindings in many > different languages including C, C++, Java, etc. We will have to > investigate the .NET approach further. > > ** There was a request that folks on the list discuss these issues for > the benefit of the community. > > 2. The charter is insufficient for a Working Group: > > * It was noted that there could be two goals: > (a) to produce multi-vendor support for a standard interface > (b) to introduce these concepts into existing IETF protocols > > * The charter appears to be too detailed; it should focus more > on outlining the problem scope well. > > * CICM appears to address requirements that are not well explained > in published documents. > > * How would CICM work with Authenticated Encryption with > Authenticated Data [RFC 5116], TLS, or IPSEC? What are the > consequences on other protocols? > > The major consequence of these points is that we should re-write the > charter and write documents to address the: > * larger problem scope > * logical model (in more generic terms) and requirements > * impact of this logical model on 2-3 existing protocols > * details for an corresponding API (e.g., CICM) > > --- End Summary --- > > More on this to follow. > > Lev > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm -- Dr. Joseph Mitola III, Fellow of the IEEE DoD SERC Director of Special Projects Distinguished Professor Vice President for the Research Enterprise Stevens Institute of Technology, Hoboken NJ Cell - 703.314.5709 From lnovikov@mitre.org Wed Aug 3 06:58:09 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9035721F8AF0 for ; Wed, 3 Aug 2011 06:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osh-aGERPs-S for ; Wed, 3 Aug 2011 06:58:09 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DFD6321F8AE9 for ; Wed, 3 Aug 2011 06:58:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 99F5221B1AD6; Wed, 3 Aug 2011 09:58:20 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 92F6621B1A39; Wed, 3 Aug 2011 09:58:20 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 3 Aug 2011 09:58:20 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" , "cryptography@randombit.net" Date: Wed, 3 Aug 2011 09:56:44 -0400 Thread-Topic: [cicm] CICM BOF Summary Thread-Index: AcxRi5TNyTXvPoKxTzSpXV1w6blPTgAWR1yw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] CICM BOF Summary X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:58:09 -0000 NOTE: Cross-posting from cicm@ietf.org to cryptography@randombit.net (Hat-tip: Kevin Wall) 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? CICM could sit under such a protocol; it is also intended manage the crypto (note the large number of management commands), and not just the pipe (channel). * Which approach, C-style or object-oriented, was intended? The .NET crypto classes might be suitable for an object-oriented approach. CICM is defined in IDL for which one can generate bindings in many different languages including C, C++, Java, etc. We will have to investigate the .NET approach further. ** There was a request that folks on the list discuss these issues for the benefit of the community. 2. The charter is insufficient for a Working Group: * It was noted that there could be two goals: (a) to produce multi-vendor support for a standard interface (b) to introduce these concepts into existing IETF protocols * The charter appears to be too detailed; it should focus more on outlining the problem scope well. * CICM appears to address requirements that are not well explained in published documents. * How would CICM work with Authenticated Encryption with Authenticated Data [RFC 5116], TLS, or IPSEC? What are the consequences on other protocols? The major consequence of these points is that we should re-write the charter and write documents to address the: * larger problem scope * logical model (in more generic terms) and requirements * impact of this logical model on 2-3 existing protocols * details for an corresponding API (e.g., CICM) --- End Summary --- More on this to follow. Lev From lnovikov@mitre.org Wed Aug 3 07:03:51 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F23921F8A7A for ; Wed, 3 Aug 2011 07:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNcg8u3WmJNJ for ; Wed, 3 Aug 2011 07:03:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2A21F8A1A for ; Wed, 3 Aug 2011 07:03:50 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9184221B0C38 for ; Wed, 3 Aug 2011 10:04:02 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8E26021B0BF4 for ; Wed, 3 Aug 2011 10:04:02 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 3 Aug 2011 10:04:02 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Wed, 3 Aug 2011 10:03:23 -0400 Thread-Topic: comments on CICM Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrA Message-ID: References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> In-Reply-To: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:03:51 -0000 FYI: Below is an insightful email from David McGrew that does not=20 appear to have made it to the mailing list nor was it held for=20 moderation so the list never saw it. Lev -----Original Message----- From: David A. McGrew [mailto:david.a.mcgrew@mindspring.com]=20 Sent: Wednesday, July 27, 2011 14:39 To: cicm@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. =20 Worthwhile goal, but what crypto hardware vendors whose products =20 support IETF standards are participating in this effort? RFC 5116 defines a standard interface to Authenticated Encryption with =20 Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH, =20 SRTP, IKE, and SMIME, and is backwards compatible with ESP. The AEAD =20 interface is simple (two defined messages, four inputs and one output =20 each), and AEAD is widely regarded as the state of the art in security =20 and efficiency (including both OCB and GCM, for instance). It appears =20 that CICM is not compatible with this interface, in which case it =20 would be a real step backwards. (If CICM does support AEAD, it is not =20 clear to me how it does. Am I missing something?) CICM is intended for use in a high assurance crypto module. =20 Considering that AES-GCM is required for Suite B, and the Suite B RFCs =20 all cite RFC 5116, the lack of AEAD support appears problematic. The use cases for which CICM is intended are those where =20 "cryptographic transformation of data initiated in one security =20 domain with the result made available in another security domain"; =20 three cases are given, two of which are HAIPE. So clearly the CICM =20 design has been driven by high assurance requirements that are highly =20 security conscious and not publicly available. My question here is: =20 how will the CICM design make implementations of IETF security =20 protocols better? If CICM is tightly bound to non-public protocols, =20 it will not have much relevance to the IETF. On the other hand, if =20 there is a document that shows how a high assurance design approach =20 can be used in an IETF standard like TLS or IPsec, that could be =20 valuable. It could be a good contribution to the IETF to provide =20 implementation criteria or design approaches that are applicable to =20 internet standards. I think there would be a good amount of interest =20 in this sort of work, and in fact I would be very happy to see that =20 sort of document show up in IRTF CFRG. An important nit: MD5 is used as an example on pg 24 of draft-lanz-=20 cicm-02. It has been deprecated by RFC 6151; I encourage that a =20 different hash be used as an example. regards, David From JOHN.A.DAVIDSON@saic.com Wed Aug 3 07:39:56 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D521F86C1 for ; Wed, 3 Aug 2011 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iEcv6dGYaG6 for ; Wed, 3 Aug 2011 07:39:55 -0700 (PDT) Received: from cpmx.mail.saic.com (cpmx.mail.saic.com [139.121.17.160]) by ietfa.amsl.com (Postfix) with ESMTP id C20A721F867F for ; Wed, 3 Aug 2011 07:39:55 -0700 (PDT) Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx.mail.saic.com with ESMTP id BT-MMP-5675930 for cicm@ietf.org; Wed, 3 Aug 2011 07:40:01 -0700 X-AuditID: 8b7911db-b7bb6ae000000974-5c-4e395dc1264e Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg02.saic.com (Symantec Brightmail Gateway) with SMTP id 7D.08.02420.1CD593E4; Wed, 3 Aug 2011 07:40:01 -0700 (PDT) Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 07:40:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 07:40:00 -0700 Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] FW: comments on CICM Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrAAADFFnA= References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> From: "Davidson, John A." To: "CICM Discussion List" X-OriginalArrivalTime: 03 Aug 2011 14:40:01.0627 (UTC) FILETIME=[39D422B0:01CC51EB] X-Brightmail-Tracker: AAAAAA== Subject: Re: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:39:56 -0000 Interesting, Dave. =20 Could you expand on your comment: =20 "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 =20 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. =20 Thanks,=20 John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Novikov, Lev Sent: Wednesday, August 03, 2011 7:03 AM To: CICM Discussion List (cicm@ietf.org) Subject: [cicm] FW: comments on CICM FYI: Below is an insightful email from David McGrew that does not=20 appear to have made it to the mailing list nor was it held for=20 moderation so the list never saw it. Lev -----Original Message----- From: David A. McGrew [mailto:david.a.mcgrew@mindspring.com]=20 Sent: Wednesday, July 27, 2011 14:39 To: cicm@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. =20 Worthwhile goal, but what crypto hardware vendors whose products =20 support IETF standards are participating in this effort? RFC 5116 defines a standard interface to Authenticated Encryption with =20 Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH, =20 SRTP, IKE, and SMIME, and is backwards compatible with ESP. The AEAD =20 interface is simple (two defined messages, four inputs and one output =20 each), and AEAD is widely regarded as the state of the art in security =20 and efficiency (including both OCB and GCM, for instance). It appears =20 that CICM is not compatible with this interface, in which case it =20 would be a real step backwards. (If CICM does support AEAD, it is not =20 clear to me how it does. Am I missing something?) CICM is intended for use in a high assurance crypto module. =20 Considering that AES-GCM is required for Suite B, and the Suite B RFCs =20 all cite RFC 5116, the lack of AEAD support appears problematic. The use cases for which CICM is intended are those where =20 "cryptographic transformation of data initiated in one security =20 domain with the result made available in another security domain"; =20 three cases are given, two of which are HAIPE. So clearly the CICM =20 design has been driven by high assurance requirements that are highly =20 security conscious and not publicly available. My question here is: =20 how will the CICM design make implementations of IETF security =20 protocols better? If CICM is tightly bound to non-public protocols, =20 it will not have much relevance to the IETF. On the other hand, if =20 there is a document that shows how a high assurance design approach =20 can be used in an IETF standard like TLS or IPsec, that could be =20 valuable. It could be a good contribution to the IETF to provide =20 implementation criteria or design approaches that are applicable to =20 internet standards. I think there would be a good amount of interest =20 in this sort of work, and in fact I would be very happy to see that =20 sort of document show up in IRTF CFRG. An important nit: MD5 is used as an example on pg 24 of draft-lanz-=20 cicm-02. It has been deprecated by RFC 6151; I encourage that a =20 different hash be used as an example. regards, David _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From jxc@mitre.org Wed Aug 3 07:49:14 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0647121F8B7C for ; Wed, 3 Aug 2011 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E479V4Oq1nj for ; Wed, 3 Aug 2011 07:49:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4803821F8B75 for ; Wed, 3 Aug 2011 07:49:13 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2D89F21B1B31 for ; Wed, 3 Aug 2011 10:49:25 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1E1C021B0123 for ; Wed, 3 Aug 2011 10:49:25 -0400 (EDT) Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 3 Aug 2011 10:49:25 -0400 From: "Cottrell Jr., James R." To: CICM Discussion List Date: Wed, 3 Aug 2011 10:49:23 -0400 Thread-Topic: comments on CICM Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrAAAGlEzA= Message-ID: References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:49:14 -0000 David McGrew, In your email you stated " Considering that AES-GCM is required for Suite B= , and the Suite B RFCs =20 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@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Nov= ikov, Lev Sent: Wednesday, August 03, 2011 10:03 AM To: CICM Discussion List (cicm@ietf.org) Subject: [cicm] FW: comments on CICM FYI: Below is an insightful email from David McGrew that does not=20 appear to have made it to the mailing list nor was it held for=20 moderation so the list never saw it. Lev -----Original Message----- From: David A. McGrew [mailto:david.a.mcgrew@mindspring.com]=20 Sent: Wednesday, July 27, 2011 14:39 To: cicm@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. =20 Worthwhile goal, but what crypto hardware vendors whose products =20 support IETF standards are participating in this effort? RFC 5116 defines a standard interface to Authenticated Encryption with =20 Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH, =20 SRTP, IKE, and SMIME, and is backwards compatible with ESP. The AEAD =20 interface is simple (two defined messages, four inputs and one output =20 each), and AEAD is widely regarded as the state of the art in security =20 and efficiency (including both OCB and GCM, for instance). It appears =20 that CICM is not compatible with this interface, in which case it =20 would be a real step backwards. (If CICM does support AEAD, it is not =20 clear to me how it does. Am I missing something?) CICM is intended for use in a high assurance crypto module. =20 Considering that AES-GCM is required for Suite B, and the Suite B RFCs =20 all cite RFC 5116, the lack of AEAD support appears problematic. The use cases for which CICM is intended are those where =20 "cryptographic transformation of data initiated in one security =20 domain with the result made available in another security domain"; =20 three cases are given, two of which are HAIPE. So clearly the CICM =20 design has been driven by high assurance requirements that are highly =20 security conscious and not publicly available. My question here is: =20 how will the CICM design make implementations of IETF security =20 protocols better? If CICM is tightly bound to non-public protocols, =20 it will not have much relevance to the IETF. On the other hand, if =20 there is a document that shows how a high assurance design approach =20 can be used in an IETF standard like TLS or IPsec, that could be =20 valuable. It could be a good contribution to the IETF to provide =20 implementation criteria or design approaches that are applicable to =20 internet standards. I think there would be a good amount of interest =20 in this sort of work, and in fact I would be very happy to see that =20 sort of document show up in IRTF CFRG. An important nit: MD5 is used as an example on pg 24 of draft-lanz-=20 cicm-02. It has been deprecated by RFC 6151; I encourage that a =20 different hash be used as an example. regards, David _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From prvs=18937e232=Hema.Krishnamurthy@itt.com Wed Aug 3 07:51:59 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280CB21F8B55 for ; Wed, 3 Aug 2011 07:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvZxiWgltCd2 for ; Wed, 3 Aug 2011 07:51:58 -0700 (PDT) Received: from cip-fwa-c1.itt.com (cip-fwa-c1.itt.com [151.190.252.21]) by ietfa.amsl.com (Postfix) with ESMTP id 53EBC21F8B50 for ; Wed, 3 Aug 2011 07:51:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAKxfOU4KHOwB/2dsb2JhbABCmAaQUYFAAQEBAQMBAQE3NBcEAgEIEQQBAR8JBycLFAkIAQEEEwiHaMEGhWNfBJgLi3A X-IronPort-AV: E=Sophos;i="4.67,310,1309737600"; d="scan'208";a="120229812" Received: from usfwa1excas1.itt.net ([10.28.236.1]) by cip-fwa-c1.itt.com with ESMTP/TLS/AES128-SHA; 03 Aug 2011 14:52:06 +0000 Received: from USFWA1EXCAS5.itt.net (10.28.236.33) by USFWA1EXCAS1.itt.net (10.28.236.1) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 3 Aug 2011 10:52:06 -0400 Received: from CSFWCAS1.cs.de.ittind.com (10.32.129.151) by USFWA1EXCAS5.itt.net (10.28.236.33) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 3 Aug 2011 10:52:05 -0400 Received: from CSFWMAIL1.cs.de.ittind.com ([10.32.129.153]) by CSFWCAS1.cs.de.ittind.com ([10.32.129.151]) with mapi; Wed, 3 Aug 2011 10:52:02 -0400 From: "Krishnamurthy, Hema - ES" To: CICM Discussion List Date: Wed, 3 Aug 2011 10:52:01 -0400 Thread-Topic: comments on CICM Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrAAAGlEzAAACTIsA== Message-ID: <86150541B533894DAD5CB2DB3F4788520E2B00C8F2@CSFWMAIL1.cs.de.ittind.com> References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:51:59 -0000 http://tools.ietf.org/html/rfc4869 lists AES-GCM as part of Suite B. -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Cot= trell Jr., James R. Sent: Wednesday, August 03, 2011 7:49 AM To: CICM Discussion List Subject: Re: [cicm] 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@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Nov= ikov, Lev Sent: Wednesday, August 03, 2011 10:03 AM To: CICM Discussion List (cicm@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@mindspring.com] Sent: Wednesday, July 27, 2011 14:39 To: cicm@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?) 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 _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm This e-mail and any files transmitted with it may be proprietary and are in= tended solely for the use of the individual or entity to whom they are addr= essed. 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 Corporati= on. The recipient should check this e-mail and any attachments for the pres= ence of viruses. ITT accepts no liability for any damage caused by any viru= s transmitted by this e-mail. From david.a.mcgrew@mindspring.com Wed Aug 3 11:15:35 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CF921F8A57 for ; Wed, 3 Aug 2011 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.452 X-Spam-Level: X-Spam-Status: No, score=-1.452 tagged_above=-999 required=5 tests=[AWL=1.147, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5AUjUPakiUG for ; Wed, 3 Aug 2011 11:15:35 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D821F8A23 for ; Wed, 3 Aug 2011 11:15:35 -0700 (PDT) Received: from [69.251.37.177] (helo=stealth-10-32-254-211.cisco.com) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Qofyr-00064p-0I for cicm@ietf.org; Wed, 03 Aug 2011 14:15:45 -0400 Message-Id: From: "David A. McGrew" To: CICM Discussion List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Aug 2011 11:15:43 -0700 References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> X-Mailer: Apple Mail (2.936) X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac4507fb1ad3334e09ac4591ca2b786f22b3b1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.251.37.177 Subject: Re: [cicm] comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 18:15:36 -0000 On Aug 3, 2011, at 7:49 AM, Cottrell Jr., James R. wrote: > 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? > 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 > Thanks, > > Jim Cottrell > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf > Of Novikov, Lev > Sent: Wednesday, August 03, 2011 10:03 AM > To: CICM Discussion List (cicm@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@mindspring.com] > Sent: Wednesday, July 27, 2011 14:39 > To: cicm@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?) > > 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 > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm From jxc@mitre.org Wed Aug 3 14:05:05 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDB711E8088 for ; Wed, 3 Aug 2011 14:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gs4Nb+x6WF35 for ; Wed, 3 Aug 2011 14:05:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 61CE311E807C for ; Wed, 3 Aug 2011 14:05:04 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB15921B0F60 for ; Wed, 3 Aug 2011 17:05:16 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E436D21B0E9C for ; Wed, 3 Aug 2011 17:05:16 -0400 (EDT) Received: from IMCMBX1.MITRE.ORG ([129.83.29.204]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 3 Aug 2011 17:05:16 -0400 From: "Cottrell Jr., James R." To: CICM Discussion List Date: Wed, 3 Aug 2011 17:05:15 -0400 Thread-Topic: comments on CICM Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrAAAGlEzAAACTIsAAM8ptQ Message-ID: References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> <86150541B533894DAD5CB2DB3F4788520E2B00C8F2@CSFWMAIL1.cs.de.ittind.com> In-Reply-To: <86150541B533894DAD5CB2DB3F4788520E2B00C8F2@CSFWMAIL1.cs.de.ittind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:05:05 -0000 Hema, Thanks. Not all Suite B products will be IPsec. I believe Harris has a Suite B tac= tical radio. For protection of voice traffic, I wouldn't think that they u= sed AES-GCM. Jim Cottrell -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Kri= shnamurthy, Hema - ES Sent: Wednesday, August 03, 2011 10:52 AM To: CICM Discussion List Subject: Re: [cicm] comments on CICM http://tools.ietf.org/html/rfc4869 lists AES-GCM as part of Suite B. -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Cot= trell Jr., James R. Sent: Wednesday, August 03, 2011 7:49 AM To: CICM Discussion List Subject: Re: [cicm] 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@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Nov= ikov, Lev Sent: Wednesday, August 03, 2011 10:03 AM To: CICM Discussion List (cicm@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@mindspring.com] Sent: Wednesday, July 27, 2011 14:39 To: cicm@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?) 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 _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm This e-mail and any files transmitted with it may be proprietary and are in= tended solely for the use of the individual or entity to whom they are addr= essed. 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 Corporati= on. The recipient should check this e-mail and any attachments for the pres= ence of viruses. ITT accepts no liability for any damage caused by any viru= s transmitted by this e-mail. _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From david.a.mcgrew@mindspring.com Wed Aug 3 15:02:50 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7E4D21F8748 for ; Wed, 3 Aug 2011 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF5snt1aIXTt for ; Wed, 3 Aug 2011 15:02:49 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id A194221F874A for ; Wed, 3 Aug 2011 15:02:49 -0700 (PDT) Received: from [69.251.37.177] (helo=stealth-10-32-254-211.cisco.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QojWm-0004iv-8f for cicm@ietf.org; Wed, 03 Aug 2011 18:03:00 -0400 Message-Id: <00352365-DFE3-4090-BE24-1FD0F55F8EC1@mindspring.com> From: "David A. McGrew" To: CICM Discussion List In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Aug 2011 15:02:58 -0700 References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> <86150541B533894DAD5CB2DB3F4788520E2B00C8F2@CSFWMAIL1.cs.de.ittind.com> X-Mailer: Apple Mail (2.936) X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac45076ba9369942794d92d915be484dfacb70350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.251.37.177 Subject: Re: [cicm] comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 22:02:50 -0000 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 > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf > Of Krishnamurthy, Hema - ES > Sent: Wednesday, August 03, 2011 10:52 AM > To: CICM Discussion List > Subject: Re: [cicm] comments on CICM > > http://tools.ietf.org/html/rfc4869 lists AES-GCM as part of Suite B. > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] 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, > > 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@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf > Of Novikov, Lev > Sent: Wednesday, August 03, 2011 10:03 AM > To: CICM Discussion List (cicm@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@mindspring.com] > Sent: Wednesday, July 27, 2011 14:39 > To: cicm@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?) > > 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 > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > > 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. > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm From david.a.mcgrew@mindspring.com Thu Aug 4 05:37:07 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835CB21F8B6D for ; Thu, 4 Aug 2011 05:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F012rw13f4EJ for ; Thu, 4 Aug 2011 05:37:06 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6E21221F8B5A for ; Thu, 4 Aug 2011 05:37:06 -0700 (PDT) Received: from [69.251.37.177] (helo=stealth-10-32-254-211.cisco.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1QoxAl-0004w3-1F for cicm@ietf.org; Thu, 04 Aug 2011 08:37:18 -0400 Message-Id: From: "David A. McGrew" To: CICM Discussion List In-Reply-To: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Aug 2011 05:36:57 -0700 References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> X-Mailer: Apple Mail (2.936) X-ELNK-Trace: ad1f9a46c4c7bfd19649176a89d694c0f43c108795ac450763c000f2f5c98f9962aaa9d081dfcf96350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 69.251.37.177 Subject: Re: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 12:37:07 -0000 Hi John, On Aug 3, 2011, at 7:40 AM, Davidson, John A. wrote: > 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 didn't have any specific ideas in mind. > > 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. > 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 > Thanks, > John > > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf > Of > Novikov, Lev > Sent: Wednesday, August 03, 2011 7:03 AM > To: CICM Discussion List (cicm@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@mindspring.com] > Sent: Wednesday, July 27, 2011 14:39 > To: cicm@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?) > > 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 > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm From JOHN.A.DAVIDSON@saic.com Thu Aug 4 07:36:02 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B996E21F8AE6 for ; Thu, 4 Aug 2011 07:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTF1dd4TbFgW for ; Thu, 4 Aug 2011 07:36:01 -0700 (PDT) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37421F8AF3 for ; Thu, 4 Aug 2011 07:36:01 -0700 (PDT) Received: from 0599-its-sbg03.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-5244907 for cicm@ietf.org; Thu, 4 Aug 2011 07:36:06 -0700 X-AuditID: 8b79132a-b7b62ae0000020af-35-4e3aae5665cb Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg03.saic.com (Symantec Brightmail Gateway) with SMTP id 26.FD.08367.65EAA3E4; Thu, 4 Aug 2011 07:36:06 -0700 (PDT) Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 4 Aug 2011 07:36:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Aug 2011 07:36:06 -0700 Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E42@0461-its-exmb09.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] FW: comments on CICM Thread-Index: AcxSo0TWDjeXOGBYSoKQIJQ+rewJ9AAD0l9g References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com><7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> From: "Davidson, John A." To: "CICM Discussion List" X-OriginalArrivalTime: 04 Aug 2011 14:36:06.0815 (UTC) FILETIME=[D8486AF0:01CC52B3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 14:36:02 -0000 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. =20 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. =20 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. =20 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. =20 >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. =20 Now I am concerned that I should have thought a little longer and harder about my response. Oh well, Im not erasing it now. =20 Kindest regards, John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] 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, On Aug 3, 2011, at 7:40 AM, Davidson, John A. wrote: > 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 =20 > comment? > Like did you mean an approach that allows TLS or IPsec to terminate =20 > in a > high assurance domain, or did you mean how to implement the =20 > 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 =20 > else? > I didn't have any specific ideas in mind. > > I too see the HAIPE influence on this. As I have said, I frankly =20 > 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. > I was wondering how we can make this work have a positive impact on =20 Internet practice. I think this is one of CICM two goals, the other =20 being to impact non-Internet practice that I'm not familiar with and =20 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 =20 protocol implementation, there are a lot of open questions, and it =20 would be essential to investigate the details of how the CICM model =20 could work with Internet protocols. The CICM model (in which there is =20 a secure side, and insecure side, and a crypto module between, and =20 there are two messages queues that connect the module to each side, =20 and don't pass any information back) is far from current practice for =20 IETF security protocols. I assume that the goal for using a queue as =20 an interface is to prevent side channels that could pass information =20 from one side to the other. This could prevent a subliminal channel =20 that could potentially be exploited by an untrustworthy application on =20 the secure side to slowly leak information out to the insecure side, I =20 suppose, which would be good in an implementation environment that =20 already has strong separation between secure/insecure sides. But how =20 many implementations of IETF protocols support such strong =20 separations? This raises the question: what benefit does the CICM =20 model provide in cases where there is no such separation? For improving current Internet practice, there are some other problem =20 areas that in my opinion deserve to be addressed first, including =20 reducing implementation flaws and the possibilty of remote timing =20 attacks. Perhaps a message queue could be used to defeat timing =20 attacks (like those against exponentiation algorithms or typing =20 patterns in text-oriented protocols), though I am not sure if that is =20 an explicit goal. But increased implementation complexity would =20 likely increase the number of implementation flaws. At any rate, =20 defeating a timing attack doesn't require hiding return codes from a =20 calling application. Perhaps there is another class of attacks being =20 addressed by that approach, though I'm not quite sure what it protects =20 against. The idea of having a queue (or two?) in between the plaintext and =20 ciphertext sides raises some interesting questions about networking, =20 such as: what is the impact on latency, jitter, retransmission timers, =20 TCP startup time? how bad is the impact on bufferbloat? what =20 protocols can run over these queues without impact, and what ones =20 could not? The practice of not providing return codes to a secure-side =20 application sending a packet, even when that packet couldn't be sent, =20 would also have an impact. What about "no route to host" and MTUs? A secure-side application can get information back through messages =20 that it receives from its peer in the cryptographic protocol. Thus, =20 if it is a goal to prevent information from the insecure side from =20 getting into the secure side, it would appear that it would be a =20 requirement in this security model to have both sides of the crypto =20 protocol use the same model. That is, some of the security properties =20 that would accrue from using the CICM model would be voided if only =20 one of the communicating parties used that model. It seems to me that the protocol that best matches the CICM model is =20 IPsec, but there are still many open questions about how it could =20 work, such as: how would this map onto the idea of an IPsec Security =20 Association Database? Where would the different parts of the IPsec =20 architecture reside? What would happen to information that needs to =20 be copied from one side to the other, such as a ToS byte? what =20 happens to how ICMP gets handled in IPsec? I personally feel that work on improving the practice of security =20 protocol implementations would be valuable, but that the best approach =20 would be to identify the most significant threats and vulnerabilities, =20 then work on mitigating them. For instance, it would be worthwhile =20 to develop an interface to cryptography that kept details about =20 initialization vectors inside the crypto module, since it is widely =20 regarded that IVs can be a problem area. But if there is interest in =20 applying the CICM model to Internet practice, I would suggest starting =20 with the applicability questions that other people and I have raised =20 (Paul Hoffman had some good suggestions in the BoF), and I would be =20 willing to participate at least as a reviewer. Apologies for the somewhat rambling email. David > Thanks, > John > > > -----Original Message----- > From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf =20 > Of > Novikov, Lev > Sent: Wednesday, August 03, 2011 7:03 AM > To: CICM Discussion List (cicm@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@mindspring.com] > Sent: Wednesday, July 27, 2011 14:39 > To: cicm@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?) > > 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 > > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From jmitola@stevens.edu Thu Aug 4 09:16:38 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10A521F8B72 for ; Thu, 4 Aug 2011 09:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJI9UBfalP9l for ; Thu, 4 Aug 2011 09:16:37 -0700 (PDT) Received: from na3sys009aog123.obsmtp.com (na3sys009aog123.obsmtp.com [74.125.149.149]) by ietfa.amsl.com (Postfix) with SMTP id B0FD421F8BBA for ; Thu, 4 Aug 2011 09:16:36 -0700 (PDT) Received: from nexus.stevens.edu ([155.246.14.12]) by na3sys009aob123.postini.com ([74.125.148.12]) with SMTP ID DSNKTjrF7InvcLB8DpuNAGRaZ5BZS5rWgx4G@postini.com; Thu, 04 Aug 2011 09:16:52 PDT Received: from [192.168.1.146] (c-76-106-141-63.hsd1.fl.comcast.net [76.106.141.63]) (Authenticated sender: jmitola) by nexus.stevens.edu (Postfix) with ESMTPSA id B8AD7300414 for ; Thu, 4 Aug 2011 12:16:43 -0400 (EDT) Message-ID: <4E3AC5E5.5080504@stevens.edu> Date: Thu, 04 Aug 2011 12:16:37 -0400 From: jmitola User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: cicm@ietf.org References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com><7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E42@0461-its-exmb09.us.saic.com> In-Reply-To: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E42@0461-its-exmb09.us.saic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:16:38 -0000 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 somebody's ssn 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 On 8/4/2011 10:36 AM, Davidson, John A. wrote: > 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: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] 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, > > On Aug 3, 2011, at 7:40 AM, Davidson, John A. wrote: > >> 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 didn't have any specific ideas in mind. > >> 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. >> > 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 > > >> Thanks, >> John >> >> >> -----Original Message----- >> From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf >> Of >> Novikov, Lev >> Sent: Wednesday, August 03, 2011 7:03 AM >> To: CICM Discussion List (cicm@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@mindspring.com] >> Sent: Wednesday, July 27, 2011 14:39 >> To: cicm@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?) >> >> 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 >> >> _______________________________________________ >> cicm mailing list >> cicm@ietf.org >> https://www.ietf.org/mailman/listinfo/cicm >> _______________________________________________ >> cicm mailing list >> cicm@ietf.org >> https://www.ietf.org/mailman/listinfo/cicm > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm > _______________________________________________ > cicm mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm From adg@crypto.lo.gy Thu Aug 4 09:36:17 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55FF21F8BAC for ; Thu, 4 Aug 2011 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b9PpQFujlcD for ; Thu, 4 Aug 2011 09:36:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4AA21F8888 for ; Thu, 4 Aug 2011 09:36:12 -0700 (PDT) Received: by gxk19 with SMTP id 19so1348125gxk.31 for ; Thu, 04 Aug 2011 09:36:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.217.3 with SMTP id p3mr952953wfg.166.1312475786233; Thu, 04 Aug 2011 09:36:26 -0700 (PDT) Received: by 10.142.99.16 with HTTP; Thu, 4 Aug 2011 09:36:26 -0700 (PDT) X-Originating-IP: [195.32.92.139] In-Reply-To: References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> Date: Thu, 4 Aug 2011 18:36:26 +0200 Message-ID: From: Alfonso De Gregorio To: CICM Discussion List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cicm] FW: comments on CICM X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 16:36:17 -0000 Hi all, On Thu, Aug 4, 2011 at 2:36 PM, David A. McGrew 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 essent= ial > to investigate the details of how the CICM model could work with Internet > protocols. =A0The CICM model (in which there is a secure side, and insecu= re > 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. =A0I assume that the g= oal > for using a queue as an interface is to prevent side channels that could > pass information from one side to the other. =A0 This could prevent a > subliminal channel that could potentially be exploited by an untrustworth= y > 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. =A0 But how many implementations of IETF protocols support such st= rong > separations? =A0 =A0This 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 are= as > that in my opinion deserve to be addressed first, including reducing > implementation flaws and the possibilty of remote timing attacks. =A0Perh= aps 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. =A0 But increased > implementation complexity would likely increase the number of implementat= ion > flaws. =A0 At any rate, defeating a timing attack doesn't require hiding > return codes from a calling application. =A0Perhaps there is another clas= s 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 IPse= c, > 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 Databas= e? > =A0 Where would the different parts of the IPsec architecture reside? =A0= What > would happen to information that needs to be copied from one side to the > other, such as a ToS byte? =A0 what happens to how ICMP gets handled in I= Psec? 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 protoco= l > implementations would be valuable, but that the best approach would be to > identify the most significant threats and vulnerabilities, then work on > mitigating them. =A0 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. =A0But if there is interest in applying the CICM model to > Internet practice, I would suggest starting with the applicability questi= ons > that other people and I have raised (Paul Hoffman had some good suggestio= ns > in the BoF), and I would be willing to participate at least as a reviewer= . > > Apologies for the somewhat rambling email. > > David I'd be super happy to join the CICM activities, in the way the group believes to be best. alfonso --=20 tweets @secYOUre blog. http://Plaintext.crypto.lo.gy/ From lnovikov@mitre.org Mon Aug 15 14:20:17 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00EF21F8D2E for ; Mon, 15 Aug 2011 14:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG3nAuJLKogm for ; Mon, 15 Aug 2011 14:20:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id F058E21F8D2F for ; Mon, 15 Aug 2011 14:20:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1C9DA21B0EF5; Mon, 15 Aug 2011 17:20:59 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1683121B02EB; Mon, 15 Aug 2011 17:20:59 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 15 Aug 2011 17:20:58 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Mon, 15 Aug 2011 17:19:56 -0400 Thread-Topic: CICM Scope Thread-Index: AcxbkRMh9Y390meMR22bUzEoml09qA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cryptography@randombit.net" Subject: [cicm] CICM Scope X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 21:20:17 -0000 (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? * What is the impact of having queues between plaintext and ciphertext on: - latency - jitter - retransmission timers - TCP startup time - bufferbloat * What is the impact of not providing return codes to a secure-side application sending a packet? What about "no route to host" and=20 MTUs? * Regarding applying the CICM model to IPsec: - How would it map onto the IPsec Security Association Database? - Where do the different parts of the IPsec architecture reside? - How is information that needs to cross domains (e.g., TOS byte) handled? - How is ICMP handled? At a higher level, we could also address questions such as: * How can we further push responsibility for performing cryptography correctly into the crypto (e.g., being responsible for initialization vectors)? (via David McGrew) * How can we improve integrity guarantees between security domains or among system-level components? (via Alfonso De Gregorio) * How can we improve the practice of transmitting and storing data=20 at mixed levels of sensitivity? (via Joe Mitola) Other ideas / questions? Are there other people / WGs we should get involved? Lev From adg@crypto.lo.gy Mon Aug 15 19:41:04 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789A21F8CEF for ; Mon, 15 Aug 2011 19:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjL6q1iqLHvI for ; Mon, 15 Aug 2011 19:41:03 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6E35A21F8CED for ; Mon, 15 Aug 2011 19:41:03 -0700 (PDT) Received: by pzk33 with SMTP id 33so6387753pzk.18 for ; Mon, 15 Aug 2011 19:41:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.18.21 with SMTP id v21mr2147959wfi.109.1313462509484; Mon, 15 Aug 2011 19:41:49 -0700 (PDT) Received: by 10.142.112.19 with HTTP; Mon, 15 Aug 2011 19:41:49 -0700 (PDT) X-Originating-IP: [195.32.92.139] In-Reply-To: References: Date: Tue, 16 Aug 2011 04:41:49 +0200 Message-ID: From: Alfonso De Gregorio To: CICM Discussion List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cryptography@randombit.net" Subject: Re: [cicm] CICM Scope X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2011 02:41:04 -0000 Lev, On Mon, Aug 15, 2011 at 11:19 PM, Novikov, Lev wrote: > (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): > =A0* IPsec (suggested by almost everyone) > =A0* TLS (via Paul Hoffman, David McGrew) > =A0* AEAD (in RFC 5116; via David McGrew) > =A0* VPN establishment crypto protocols (via Alfonso De Gregorio) > =A0* Domain Security Services (as in RFC 3183; via Alfonso De Gregorio) > > ** Alfonso: > =A0Can you elaborate on which protocols you had in mind regarding VPN? > > It seems clear that, at the very least, we should look at IPsec. Absolutely. Thanks for asking. IPsec is the most natural protocol we should look at, indeed. In my opinion, the Secure Shell Connection Protocol (RFC 4254) is also to be consider among the (de-facto) VPN establishment crypto protocols, if we consider its most popular implementation. Let me elaborate why this is the case. As we know, the SSH protocol doesn't provide a VPN establishment mechanism built-in. However, at the connection layer the IETF standard defines the channel mechanism and specify the first four basic channel types. Real world implementations have the possibility to build upon this mechanism extending the protocol to accommodate new use cases. This is what OpenSSH did with the tunnel forward extension. As of version 4.3, OpenSSH supports layer 2 and layer 3 tunnelling via the "tun@openssh.com" channel type. On network endpoints equipped with pseudo-device interface like the BSD tun(4), this extended channel type allows to forward layer 2 frames and layer 3 packets back and forth, and hence to establish an encrypted VPN connections. Building on the above, there is yet another IETF protocol that we might want to consider in order to discuss the impact of CICM Model and it is iSCSI (RFC 3720). If we try to frame a CICM-enabled-iSCSI endpoint in the use cases detailed in draft-lanz-cicm-lm, we would find it related to both the HAIPE and the data-at-rest cases. iSCSI uses the IPsec mechanism for providing integrity, authentication and confidentiality at the IP level between the initiator and the target (RFC 3723). Here, considerations originating from to the presence of queues (e.g., latency) may be especially relevant. At the same time, the data-at-rest use case is also relevant, when we relax the architectural constraints, moving the cryptographic-module interface to the storage from a local bus to the network. Cheers, -- alfonso blogs at http://Plaintext.crypto.lo.gy tweets @secYOUre From lnovikov@mitre.org Wed Aug 24 10:18:25 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D669721F86F6 for ; Wed, 24 Aug 2011 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJ_ALL_CAPS=2.077] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QphYP2u6Grbt for ; Wed, 24 Aug 2011 10:18:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BB2FD21F876F for ; Wed, 24 Aug 2011 10:18:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6586321B1285 for ; Wed, 24 Aug 2011 13:19:35 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 60D6E21B073E for ; Wed, 24 Aug 2011 13:19:35 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 24 Aug 2011 13:19:35 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Wed, 24 Aug 2011 13:18:32 -0400 Thread-Topic: RFC 5116 (AEAD) Thread-Index: AcxigcxlwIPJgN19T/a+DCPpDcGWZQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] RFC 5116 (AEAD) X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 17:18:25 -0000 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). See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-9.8 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-14.5 3. Therefore, it seems like the best way to handle AEAD would be to create a new channel type. Specifically, we'd need to support creating a conduit just like an EncryptBypass::Conduit (one key, one algorithm) that behaved like an Encrypt::WithMACConduit (supporting the end_get_mac() method). CICM::Status create_encrypt_auth_data_conduit( in CICM::RemotePort remote_port, in CICM::SymKey key_ref, in CICM::SymEncrAlgorithmId algorithm, out CICM::EncryptBypass::AEADConduit conduit_ref ); The conduit would look exactly like a Encrypt::WithMACConduit, except that both key attributes (key, mac_key) would point to the same key. For example, interface AEADConduit : CICM::AbstractMACConduit, CICM::Encrypt::Conduit {} 4. The approach above would differ from RFC 5116 in a few ways: - There is not a single method with four inputs that returns a single output. This is because in CICM channel *creation* is separate from channel *usage*. - The output is not returned, but is emitted in another domain. If necessary, we can add a similar channel type to the CICM::Coprocessor namespace as we have for Coprocessor::EncryptWithMACConduit. The conduit would no longer require a remote port, and the conduit would inherit from CICM::Coprocessor::EncryptConduit rather than CICM::Encrypt::Conduit. See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.3 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-18.4 - Additionally, the nonce (N) parameter would be omitted, but could be supplied or generated using the attributes and methods inherited from CICM::SetVectorController and CICM::GenVectorController. See: http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.5 http://tools.ietf.org/html/draft-lanz-cicm-cm-01#section-7.6 ** David McGrew: - Is my understanding of how AEAD works correct? - Would these sorts of additions satisfy the needs of AEAD, or would a more explicit conformance to the method signature be required? Lev From lnovikov@mitre.org Fri Aug 26 13:17:12 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B111D21F8C72 for ; Fri, 26 Aug 2011 13:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCGibLiywgH3 for ; Fri, 26 Aug 2011 13:17:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 409AE21F8AFB for ; Fri, 26 Aug 2011 13:17:12 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EB7C221B15BA for ; Fri, 26 Aug 2011 16:18:28 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E77BC21B15B6 for ; Fri, 26 Aug 2011 16:18:28 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 26 Aug 2011 16:18:28 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Fri, 26 Aug 2011 16:17:52 -0400 Thread-Topic: Use Cases Thread-Index: AcxkLTeZAvR3bwFMSYqPf+pySxYTSg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] Use Cases X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:17:12 -0000 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@gmail.com Fri Aug 26 15:23:27 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0540A21F8C72 for ; Fri, 26 Aug 2011 15:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpkru1lMw+1i for ; Fri, 26 Aug 2011 15:23:26 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 393BD21F8C6E for ; Fri, 26 Aug 2011 15:23:26 -0700 (PDT) Received: by wyg8 with SMTP id 8so3180720wyg.31 for ; Fri, 26 Aug 2011 15:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+NB7PpchK4INFjFVheRwAisSis4XPyE30cuR6xLuj+k=; b=IsVe2qCbaqBx9xbdkl3HboSaEU4Ioep5/B2j80T2f2JLqzdXzyevxp3IG6ejz2iyjr r3buO6XNdMgTF1Xsr2VkyTPENIvxV5fiDHgsTCZ9HCMHFU0g8SxTMdDeWfN+09/xkIV1 LnhVgjOxzROJOjxx4gzeMG3dt3e1vBHU8EMuw= MIME-Version: 1.0 Received: by 10.216.202.136 with SMTP id d8mr941624weo.52.1314397481500; Fri, 26 Aug 2011 15:24:41 -0700 (PDT) Received: by 10.216.55.208 with HTTP; Fri, 26 Aug 2011 15:24:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Aug 2011 18:24:41 -0400 Message-ID: From: "Kevin W. Wall" To: CICM Discussion List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cicm] Use Cases X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 22:23:27 -0000 On Fri, Aug 26, 2011 at 4:17 PM, Novikov, Lev wrote: > 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 > =A0 high assurance data-in-transit case) > > 2. Traditional data-in-transit and -at-reset case (cf. PKCS#11) I presume that you meant 'at-rest' rather than 'at-reset' here? > 3. One network with two security domains (cf. network storage; > =A0 data-in-transit and -at-rest ) > > 4. One machine with two security domains in software (cf. Vincent > =A0 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? 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 --=20 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." =A0 =A0 =A0 =A0-- Nathaniel Borenstein From JOHN.A.DAVIDSON@saic.com Mon Aug 29 07:25:57 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0D21F8876 for ; Mon, 29 Aug 2011 07:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.386 X-Spam-Level: X-Spam-Status: No, score=-1.386 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, MANGLED_STOP=2.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICW39PYDVl4i for ; Mon, 29 Aug 2011 07:25:57 -0700 (PDT) Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0906921F893C for ; Mon, 29 Aug 2011 07:25:57 -0700 (PDT) Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-9101199 for cicm@ietf.org; Mon, 29 Aug 2011 07:27:09 -0700 X-AuditID: 8b7911db-b7cafae00000407d-0a-4e5ba1bcf18a Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg02.saic.com (Symantec Brightmail Gateway) with SMTP id 9B.5A.16509.DB1AB5E4; Mon, 29 Aug 2011 07:27:09 -0700 (PDT) Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 07:27:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Aug 2011 07:27:08 -0700 Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E7C@0461-its-exmb09.us.saic.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Use Cases Thread-Index: AcxkLTeZAvR3bwFMSYqPf+pySxYTSgCJ2nxA References: From: "Davidson, John A." To: "CICM Discussion List" X-OriginalArrivalTime: 29 Aug 2011 14:27:09.0106 (UTC) FILETIME=[BC1C4920:01CC6657] X-Brightmail-Tracker: AAAAAA== Subject: Re: [cicm] Use Cases X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:25:57 -0000 Lev,=20 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. =20 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). =20 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. =20 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. =20 John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Novikov, Lev Sent: Friday, August 26, 2011 1:18 PM To: CICM Discussion List (cicm@ietf.org) Subject: [cicm] 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 _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From lnovikov@mitre.org Tue Aug 30 08:03:45 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FBC21F8C83 for ; Tue, 30 Aug 2011 08:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrMupyPIpmYe for ; Tue, 30 Aug 2011 08:03:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 532FE21F8C7B for ; Tue, 30 Aug 2011 08:03:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7ECB721B1991 for ; Tue, 30 Aug 2011 11:05:12 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7A53D21B1379 for ; Tue, 30 Aug 2011 11:05:12 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Tue, 30 Aug 2011 11:05:12 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Tue, 30 Aug 2011 11:04:21 -0400 Thread-Topic: [cicm] Use Cases Thread-Index: AcxkPvbugw7FLYN7TPOoFiP6PoW3aAC5ccDg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cicm] Use Cases X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 15:03:45 -0000 Kevin, On 2011-08-26 16:34, Lev Novikov wrote: > 2. Traditional data-in-transit and -at-reset case (cf. PKCS#11) On 2011-08-26 18:25, Kevin Wall wrote: > 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: > 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=20 > exchange. However, I suspect that is considered out of scope. I don't think the model should assume that keys were pre-shared. For=20 example, CICM currently supports negotiating an asymmetric key which=20 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=20 reasonable (assuming I understood your proposed case correctly). Lev From kevin.w.wall@gmail.com Tue Aug 30 08:33:48 2011 Return-Path: X-Original-To: cicm@ietfa.amsl.com Delivered-To: cicm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D27921F8CC0 for ; Tue, 30 Aug 2011 08:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O1Iu7dtaSdo for ; Tue, 30 Aug 2011 08:33:47 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4984621F8CBE for ; Tue, 30 Aug 2011 08:33:46 -0700 (PDT) Received: by wwe5 with SMTP id 5so3529434wwe.1 for ; Tue, 30 Aug 2011 08:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=MuYjZ0bIXCR3ejTKvb2B/0lowybtu6N47FRquckc8Gc=; b=CNrVb3IjqA/gx8ikLIksgFOit1tbdYcuKGOCqHeXc9DZZfasYc7poK4n4e8HTbVeNK XHWYR1p/YcZIb+ON3MHS96X1c3yu6DtIywTPt5FJTVmEsdwsBB5dJHFNbHzTOKe10pLO hfNFFg27IEc/T+MQDot3tEjGi5A0enc8CGMZg= MIME-Version: 1.0 Received: by 10.216.179.10 with SMTP id g10mr5076717wem.22.1314718514169; Tue, 30 Aug 2011 08:35:14 -0700 (PDT) Received: by 10.217.1.144 with HTTP; Tue, 30 Aug 2011 08:35:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Aug 2011 11:35:14 -0400 Message-ID: From: "Kevin W. Wall" To: CICM Discussion List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [cicm] Use Cases X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: CICM Discussion List List-Id: CICM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 15:33:48 -0000 On Tue, Aug 30, 2011 at 11:04 AM, Novikov, Lev wrote: > Kevin, > > On 2011-08-26 16:34, Lev Novikov wrote: >> 2. Traditional data-in-transit and -at-reset case (cf. PKCS#11) > > On 2011-08-26 18:25, Kevin Wall wrote: >> I presume that you meant 'at-rest' rather than 'at-reset' here? > > Yes. Hopefully we're not resetting the data when we store it. Yes; that would be bad. ;-) > On 2011-08-26 18:25, Kevin Wall wrote: >> 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. > > 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). 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 --=20 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." =A0 =A0 =A0 =A0-- Nathaniel Borenstein