From lnovikov@mitre.org Mon Jan 10 15:58:37 2011 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58F73A680F; Mon, 10 Jan 2011 15:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV6Tw96ADy-w; Mon, 10 Jan 2011 15:58:36 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 59F363A6814; Mon, 10 Jan 2011 15:58:36 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 189BD21B02A2; Mon, 10 Jan 2011 19:00:51 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 13C7C21B029E; Mon, 10 Jan 2011 19:00:51 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 10 Jan 2011 19:00:51 -0500 From: "Novikov, Lev" To: CICM Discussion List Date: Mon, 10 Jan 2011 18:58:29 -0500 Thread-Topic: -02 draft of CICM posted Thread-Index: AcskWWz5sLSa82ElSNe2wD4zt5uCjSMxqdPw 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 Cc: "saag@ietf.org" Subject: [cicm] -02 draft of CICM posted X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jan 2011 23:58:38 -0000 The -02 draft of the Common Interface to Cryptographic Modules (CICM) has b= een posted. Comments are solicited to . Some new issues have been discovered as a result of this recent work and wi= ll be raised on the mailing list soon. This revision restructures CICM into five documents as discussed back in Ju= ly: 1. [CICM-LM] An informative background document that provides an introducti= on to the space,=20 the terminology, and logical model. 2. [CICM] A normative base document that defines the basic types and the Co= nformance & Extension model. 3. [CICM-MM] A normative document that defines Module Management capabiliti= es. 4. [CICM-KM] A normative document that defines Key Management capabilities. 5. [CICM-CM] A normative document that defines Channel Management capabilit= ies. As discussed previously, the document labeled [CICM] is the normative docum= ent upon which all other documents (except CICM-LM) are based. Other Changes: - figures added to illustrate basic concepts - sample ICS added Pending Changes: - adding ABNF syntax for generating identifiers (in progress) Lev From lnovikov@mitre.org Thu Jan 20 11:05:11 2011 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60D863A67B7 for ; Thu, 20 Jan 2011 11:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4I9BtYAIFP4 for ; Thu, 20 Jan 2011 11:05:10 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 5F3073A67B6 for ; Thu, 20 Jan 2011 11:05:10 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C18F321B0A64 for ; Thu, 20 Jan 2011 14:07:53 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BD3A621B0A5F for ; Thu, 20 Jan 2011 14:07:53 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 20 Jan 2011 14:07:53 -0500 From: "Novikov, Lev" To: CICM Discussion List Date: Thu, 20 Jan 2011 14:05:28 -0500 Thread-Topic: Key Metadata and Fill Events Thread-Index: Acu41QA85f5S7ZbETD6IMan6SSb7QQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AMfL AaJZ Alb5 B3qG DkGD D0e2 D8t0 GWod Ga5g Gofc GuRY G5vX IMow Iio4 Ijd0 J6zz; 1; YwBpAGMAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {33C475B7-10C5-4A40-95ED-788AB66DB956}; bABuAG8AdgBpAGsAbwB2AEAAbQBpAHQAcgBlAC4AbwByAGcA; Thu, 20 Jan 2011 19:06:00 GMT; SwBlAHkAIABNAGUAdABhAGQAYQB0AGEAIABhAG4AZAAgAEYAaQBsAGwAIABFAHYAZQBuAHQAcwA= x-cr-puzzleid: {33C475B7-10C5-4A40-95ED-788AB66DB956} acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cicm] Key Metadata and Fill Events X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jan 2011 19:05:11 -0000 As I mentioned last week, a few issues have come up as part of the last rev= iew of the document. Here's one: Imagine a scenario where we need to apply metadata to keys after they are f= illed into a cryptographic module. The CICM::AsymKeyManager::get_key_last_filled() and CICM::SymKeyManager::ge= t_key_last_filled() methods provide reference the most recently filled key.= =20 See: http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-4.1.2=20 and http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-5.1.2 However, these methods are expecting a key of known type (Sym or Asym). How= do you know which key was filled last? Moreover, what if several keys were= filled of both types? How can you access them to apply the appropriate met= adata? One possible solution is to extend the module events. Currently, we have th= ree module events related to key fill:=20 - C_MODULE_KEY_FILL_CONNECTED,=20 - C_MODULE_KEY_FILL_INITIATED, and=20 - C_MODULE_KEY_FILL_COMPLETE.=20 See: http://tools.ietf.org/html/draft-lanz-cicm-mm-00#section-9.2.1 In theory, there could be a vendor-supplied parameter to the C_MODULE_KEY_F= ILL_COMPLETE event that would indicate the type of key that was loaded. How= ever, we propose that two additional module events be added:=20 - C_MODULE_KEY_FILL_COMPLETE_SYM and=20 - C_MODULE_KEY_FILL_COMPLETE_ASYM. These "KEY_FILL_COMPLETE" events would indicate that one or more keys of th= e specified type was loaded. When the event is called, the client program w= ould then be able to use the appropriate iterator (SymKeyIterator or AsymKe= yIterator) to enumerate all of the keys on the module and determine which k= eys are new. See: http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-4.3 and http://tools.ietf.org/html/draft-lanz-cicm-km-00#section-5.3 The disadvantages of this approach is that the ::get_key_last_filled() meth= ods only work when there's a single key filled and the onus on detecting wh= ich keys are new is pushed off to the client program. The advantages are that the CICM driver can choose to fire these events aft= er each key is filled (e.g., when using sporadic, network-based keying) OR = after a large batch of keys are filled (e.g., when using a fill device). * What are other advantages / disadvantages to this approach? * Are there better approaches? Lev From jfitton@harris.com Tue Jan 25 13:32:24 2011 Return-Path: X-Original-To: cicm@core3.amsl.com Delivered-To: cicm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC18A3A689F for ; Tue, 25 Jan 2011 13:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rlWmKeWjTwD for ; Tue, 25 Jan 2011 13:32:22 -0800 (PST) Received: from mlbe2k2.cs.myharris.net (mlbe2k2.cs.myharris.net [137.237.90.89]) by core3.amsl.com (Postfix) with ESMTP id 4D0FE3A68D3 for ; Tue, 25 Jan 2011 13:32:22 -0800 (PST) Received: from mail pickup service by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC; Tue, 25 Jan 2011 16:35:19 -0500 Received: from roce2k4.cs.myharris.net ([147.177.32.37]) by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 25 Jan 2011 16:35:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jan 2011 16:35:17 -0500 Message-ID: <8CBBCF54EC560B479037451B6F1AA4F5016B65CE@roce2k4.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key identification Thread-Index: Acu43VrApNHh9L4mSWqueP4lHL7NUAD+Hdls References: From: "Fitton, John" To: X-OriginalArrivalTime: 25 Jan 2011 21:35:18.0542 (UTC) FILETIME=[C2FB22E0:01CBBCD7] Subject: [cicm] Key identification X-BeenThere: cicm@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jan 2011 21:32:24 -0000 There are any number of issues associated with identifying keys. Might I = recommend you read Section 5.1.6.4 of the Wireless Innovation Forum's = Security Work Group document "Securing Software Reconfigurable = Communications Devices (WINNF-08-P-0013-V1.0.0). It is a publicly = available document at this link: [ = http://groups.winnforum.org/p/cm/ld/fid=3D84 ] (3rd document down on the = list).=20 =20 As you may know it is not uncommon for type 1 keys to have an associated = tag which contains an identifier which is unique to the source key management system, but if a device = receives material from multiple systems there is a chance that the = identifier may not be unique. The problem is compounded when the using = device receives a key without any such key tag identification. A = recommended approach is for the receiving device key management function = to append a locally generated unique identifier to each key which it = receives. It can then exchange this identifier with any application = which requires the use of the particular key. This is a must stronger = (less vulnerable) approach which can avoid misidentification of key = material and its subsequent misuse. ________________________________ From: cicm-bounces@ietf.org on behalf of cicm-request@ietf.org Sent: Thu 1/20/2011 3:00 PM To: cicm@ietf.org Subject: cicm Digest, Vol 9, Issue 2 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/cicm Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send cicm mailing list submissions to cicm@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/cicm or, via email, send a message with subject or body 'help' to cicm-request@ietf.org You can reach the person managing the list at cicm-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of cicm digest..."