From girish.nanjundiah@viasat.com Thu Jun 2 16:17: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 7FE93E0709 for ; Thu, 2 Jun 2011 16:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.482 X-Spam-Level: X-Spam-Status: No, score=-1.482 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_05=-1.11, HTML_MESSAGE=0.001] 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 OY5TdvTu1+3Z for ; Thu, 2 Jun 2011 16:17:49 -0700 (PDT) Received: from viasat.com (bateleur.viasat.com [199.106.52.160]) by ietfa.amsl.com (Postfix) with ESMTP id 88750E06FC for ; Thu, 2 Jun 2011 16:17:49 -0700 (PDT) Received: from ([172.20.1.71]) by bateleur.viasat.com with ESMTP id H6GMFJ1.45401334; Thu, 02 Jun 2011 16:17:47 -0700 Received: from vcaexch06.hq.corp.viasat.com ([172.18.46.74]) by VCAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jun 2011 16:17:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC217B.355EA114" Date: Thu, 2 Jun 2011 16:17:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Key Identifers Thread-Index: AcwhezV3QC9uOkO8TZmDXjV91Jju3A== From: "Nanjundiah, Girish" To: "CICM Discussion List" X-OriginalArrivalTime: 02 Jun 2011 23:17:47.0193 (UTC) FILETIME=[48BCD290:01CC217B] Subject: [cicm] Key Identifers 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, 02 Jun 2011 23:17:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC217B.355EA114 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Everyone, =20 Sorry if this question is extremely obvious or just hasn't been answered but I'm a little confused as to how we are meant to access the CICM::CharString identifier attribute of the CICM::Key class. I'm assuming attributes are all private or protected, so how is one to access the identifier? While it is easy to obtain its value with CICM::Key::export, I can't seem to find a way to set it without adding another function or a constructor for the CICM::Key class... =20 Thanks, -Girish Nanjundiah ------_=_NextPart_001_01CC217B.355EA114 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Everyone,

Sorry if this question is extremely obvious or just = hasn’t been answered but I’m a little confused as to how we = are meant to access the CICM::CharString identifier attribute of the = CICM::Key class. I’m assuming attributes are all private or = protected, so how is one to access the identifier? While it is easy to = obtain its value with CICM::Key::export, I can’t seem to find a = way to set it without adding another function or a constructor for the = CICM::Key class…

Thanks,

-Girish = Nanjundiah

------_=_NextPart_001_01CC217B.355EA114-- From lnovikov@mitre.org Fri Jun 3 13:34: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 31F3DE07D4 for ; Fri, 3 Jun 2011 13:34:45 -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 nJ-ClSTAwnEK for ; Fri, 3 Jun 2011 13:34:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id DE071E07AB for ; Fri, 3 Jun 2011 13:34:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BBC8D21B0EDC for ; Fri, 3 Jun 2011 16:34:42 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B783821B0CA3 for ; Fri, 3 Jun 2011 16:34:42 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 3 Jun 2011 16:34:42 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Fri, 3 Jun 2011 16:33:40 -0400 Thread-Topic: Key Identifers Thread-Index: AcwhezV3QC9uOkO8TZmDXjV91Jju3AAsPBNw 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] Key Identifers 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, 03 Jun 2011 20:34:45 -0000 Girish, On 2011-06-02 at 19:17, Girish Nanjundiah wrote: > [...] how we are meant to access the CICM::CharString identifier attribut= e=20 > of the CICM::Key class. An attribute in IDL gets mapped to _get_{attribute}() and _set_{attribute}(= )=20 methods for the object. For example, the CryptoModule::sym_key_manager=20 attribute is a read-only attribute so it becomes: =20 SymKeyManager* CryptoModule::_get_sym_key_manager(void) { return &(this->sym_key_manager); }; =20 See: http://code.google.com/p/ietf-cicm/source/browse/cpp/cicm.cpp#47 For your case, you'd want to define something similar. Let me know if works for your situation. Lev From jfitton@harris.com Fri Jun 3 15:29:33 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 741D8E07F5 for ; Fri, 3 Jun 2011 15:29:33 -0700 (PDT) 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=[AWL=0.000, 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 SKJHeRDhW0HZ for ; Fri, 3 Jun 2011 15:29:32 -0700 (PDT) Received: from mlbe2k2.cs.myharris.net (mlbe2k2.cs.myharris.net [137.237.90.89]) by ietfa.amsl.com (Postfix) with ESMTP id C152EE07F2 for ; Fri, 3 Jun 2011 15:29:32 -0700 (PDT) Received: from mail pickup service by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC; Fri, 3 Jun 2011 18:29:31 -0400 Received: from mlbe2kpf1.cs.myharris.net ([137.237.89.95]) by mlbe2k2.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 18:29:30 -0400 Received: from MLBMXHTUS1.cs.myharris.net ([137.237.89.77]) by mlbe2kpf1.cs.myharris.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Jun 2011 18:29:30 -0400 Received: from ROCMXCAHT22.cs.myharris.net (10.64.228.25) by MLBMXHTUS1.cs.myharris.net (137.237.89.77) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 3 Jun 2011 18:29:30 -0400 Received: from ROCMXUS21.cs.myharris.net ([fe80::1161:8dee:2d75:5ac]) by ROCMXCAHT22.cs.myharris.net ([::1]) with mapi id 14.01.0270.001; Fri, 3 Jun 2011 18:29:29 -0400 From: "Fitton, John" To: CICM Discussion List Thread-Topic: [cicm] Key Identifers Thread-Index: AQHMIiC4MPsFX1Dzn0qnSMClDalVL5SsNdIj Date: Fri, 3 Jun 2011 22:29:29 +0000 Message-ID: <06D46EAFF7D0C946BEC108DB7CCDC9A608B49452@ROCMXUS21.cs.myharris.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.228.55] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Jun 2011 22:29:30.0617 (UTC) FILETIME=[B4A82690:01CC223D] Subject: Re: [cicm] Key Identifers 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, 03 Jun 2011 22:29:33 -0000 I would imagine that one method would be for the entity desiring to obtain = key identifiers would be to list the attributes of the keys that it is inte= rested in. By passing in such an attribute list, then a compilation of the = key identifiers which satisfy the attribute list could be provided. Proper = Least Privilege restrictions would restrict the entity from including any a= ttributes in the request that are not consistent with the applications need= s. These "needs" could be listed in a security policy which is enforced by = the Security Model. In that way the application could only find out about k= eys which a constrained to that attribute set. ________________________________ From: Nanjundiah, Girish [Girish.Nanjundiah@viasat.com] Sent: Thursday, June 02, 2011 7:17 PM To: CICM Discussion List Subject: [cicm] Key Identifers Hello Everyone, Sorry if this question is extremely obvious or just hasn=92t been answered = but I=92m a little confused as to how we are meant to access the CICM::Char= String identifier attribute of the CICM::Key class. I=92m assuming attribut= es are all private or protected, so how is one to access the identifier? Wh= ile it is easy to obtain its value with CICM::Key::export, I can=92t seem t= o find a way to set it without adding another function or a constructor for= the CICM::Key class=85 Thanks, -Girish Nanjundiah From Steven.DiMedio@L-3Com.com Mon Jun 6 06:50:46 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 A254A11E813E for ; Mon, 6 Jun 2011 06:50:46 -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 qMNaGfv+gqAO for ; Mon, 6 Jun 2011 06:50:45 -0700 (PDT) Received: from smtp4out.l-3com.com (smtp4out.l-3com.com [128.170.207.112]) by ietfa.amsl.com (Postfix) with ESMTP id 717C211E80F7 for ; Mon, 6 Jun 2011 06:50:35 -0700 (PDT) X-filenames: None X-filesizes: None X-filetypes: None X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="277294991" From: Steven.DiMedio@L-3Com.com Received: from host-166-20-16-165.l-3com.com (HELO csemail02.cse.l-3com.com) ([166.20.16.165]) by smtp4out.l-3com.com with ESMTP; 06 Jun 2011 13:50:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 6 Jun 2011 09:49:43 -0400 Message-ID: In-Reply-To: <06D46EAFF7D0C946BEC108DB7CCDC9A608B49452@ROCMXUS21.cs.myharris.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Key Identifers Thread-Index: AQHMIiC4MPsFX1Dzn0qnSMClDalVL5SsNdIjgAQiuFA= References: <06D46EAFF7D0C946BEC108DB7CCDC9A608B49452@ROCMXUS21.cs.myharris.net> To: "CICM Discussion List" Subject: Re: [cicm] Key Identifers 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, 06 Jun 2011 13:50:46 -0000 Maybe the spirit of Girish's original question was whether we implementers are permitted to modify the CICM test harness files provided to us by MITRE. It was my understanding (from the kickoff telecon) that we vendors are only to modify the cicm.cpp and config.h files, not the cicm.h, encrypt.cpp, and decrypt.cpp files. (That is, implementers are to complete the coding of the stubs in cicm.cpp.) If that understanding is correct, it limits implementers a bit as to what functionality can be added. So maybe the broader question is: are venders permitted/expected to modify all the test harness files? Thanks, Steve DiMedio L3 Communications 856-338-4204 -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Fitton, John Sent: Friday, June 03, 2011 6:29 PM To: CICM Discussion List Subject: Re: [cicm] Key Identifers I would imagine that one method would be for the entity desiring to obtain key identifiers would be to list the attributes of the keys that it is interested in. By passing in such an attribute list, then a compilation of the key identifiers which satisfy the attribute list could be provided. Proper Least Privilege restrictions would restrict the entity from including any attributes in the request that are not consistent with the applications needs. These "needs" could be listed in a security policy which is enforced by the Security Model. In that way the application could only find out about keys which a constrained to that attribute set. ________________________________ From: Nanjundiah, Girish [Girish.Nanjundiah@viasat.com] Sent: Thursday, June 02, 2011 7:17 PM To: CICM Discussion List Subject: [cicm] Key Identifers Hello Everyone, Sorry if this question is extremely obvious or just hasn't been answered but I'm a little confused as to how we are meant to access the CICM::CharString identifier attribute of the CICM::Key class. I'm assuming attributes are all private or protected, so how is one to access the identifier? While it is easy to obtain its value with CICM::Key::export, I can't seem to find a way to set it without adding another function or a constructor for the CICM::Key class... Thanks, -Girish Nanjundiah _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From girish.nanjundiah@viasat.com Mon Jun 6 09:47: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 1991511E8177 for ; Mon, 6 Jun 2011 09:47:35 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TWDsV6qqo45 for ; Mon, 6 Jun 2011 09:47:34 -0700 (PDT) Received: from viasat.com (bateleur.viasat.com [199.106.52.160]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9111E8181 for ; Mon, 6 Jun 2011 09:47:33 -0700 (PDT) Received: from ([172.20.1.71]) by bateleur.viasat.com with ESMTP id H6GMFJ1.45571390; Mon, 06 Jun 2011 09:47:30 -0700 Received: from vcaexch06.hq.corp.viasat.com ([172.18.46.74]) by VCAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jun 2011 09:47:29 -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, 6 Jun 2011 09:47:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Key Identifers Thread-Index: AQHMIiC4MPsFX1Dzn0qnSMClDalVL5SsNdIjgAQiuFCAADVEEA== References: <06D46EAFF7D0C946BEC108DB7CCDC9A608B49452@ROCMXUS21.cs.myharris.net> From: "Nanjundiah, Girish" To: "CICM Discussion List" X-OriginalArrivalTime: 06 Jun 2011 16:47:29.0806 (UTC) FILETIME=[6C8A22E0:01CC2469] Subject: Re: [cicm] Key Identifers 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, 06 Jun 2011 16:47:35 -0000 That is part of my question, I realize we are not allowed to modify the header file but if we are to add _set and _get methods for the classes as Lev said then we do need to modify the header file in order to add the function signatures. Thanks, -Girish -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Steven.DiMedio@L-3Com.com Sent: Monday, June 06, 2011 6:50 AM To: CICM Discussion List Subject: Re: [cicm] Key Identifers Maybe the spirit of Girish's original question was whether we implementers are permitted to modify the CICM test harness files provided to us by MITRE. It was my understanding (from the kickoff telecon) that we vendors are only to modify the cicm.cpp and config.h files, not the cicm.h, encrypt.cpp, and decrypt.cpp files. (That is, implementers are to complete the coding of the stubs in cicm.cpp.) If that understanding is correct, it limits implementers a bit as to what functionality can be added. So maybe the broader question is: are venders permitted/expected to modify all the test harness files? Thanks, Steve DiMedio L3 Communications 856-338-4204 -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Fitton, John Sent: Friday, June 03, 2011 6:29 PM To: CICM Discussion List Subject: Re: [cicm] Key Identifers I would imagine that one method would be for the entity desiring to obtain key identifiers would be to list the attributes of the keys that it is interested in. By passing in such an attribute list, then a compilation of the key identifiers which satisfy the attribute list could be provided. Proper Least Privilege restrictions would restrict the entity from including any attributes in the request that are not consistent with the applications needs. These "needs" could be listed in a security policy which is enforced by the Security Model. In that way the application could only find out about keys which a constrained to that attribute set. ________________________________ From: Nanjundiah, Girish [Girish.Nanjundiah@viasat.com] Sent: Thursday, June 02, 2011 7:17 PM To: CICM Discussion List Subject: [cicm] Key Identifers Hello Everyone, Sorry if this question is extremely obvious or just hasn't been answered but I'm a little confused as to how we are meant to access the CICM::CharString identifier attribute of the CICM::Key class. I'm assuming attributes are all private or protected, so how is one to access the identifier? While it is easy to obtain its value with CICM::Key::export, I can't seem to find a way to set it without adding another function or a constructor for the CICM::Key class... Thanks, -Girish Nanjundiah _______________________________________________ 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 lnovikov@mitre.org Mon Jun 6 11:22:49 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 48D4211E81C7 for ; Mon, 6 Jun 2011 11:22:49 -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 4gUzfJyoFg6q for ; Mon, 6 Jun 2011 11:22:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ADDF211E81BF for ; Mon, 6 Jun 2011 11:22:48 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 948B421B203C for ; Mon, 6 Jun 2011 14:22:44 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 904C121B156F for ; Mon, 6 Jun 2011 14:22:44 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 6 Jun 2011 14:22:44 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Mon, 6 Jun 2011 14:21:49 -0400 Thread-Topic: [cicm] Key Identifers Thread-Index: AQHMIiC4MPsFX1Dzn0qnSMClDalVL5SsNdIjgAQiuFCAADVEEIAAGbIA Message-ID: References: <06D46EAFF7D0C946BEC108DB7CCDC9A608B49452@ROCMXUS21.cs.myharris.net> 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] Key Identifers 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, 06 Jun 2011 18:22:49 -0000 Girish, On 2011-06-06 at 12:47, Girish Nanjundiah wrote: > [...] if we are to add _set and _get methods for the classes > as Lev said then we do need to modify the header file in order to add > the function signatures. Correct. The header file is just a barebones version of a CICM driver;=20 vendors may need to add more CICM-defined methods to make the whole=20 harness work (as a last resort). Lev From girish.nanjundiah@viasat.com Tue Jun 7 13:17:11 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 850DE11E81AE for ; Tue, 7 Jun 2011 13:17:11 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 fuisgrF6-pgV for ; Tue, 7 Jun 2011 13:17:09 -0700 (PDT) Received: from viasat.com (bateleur.viasat.com [199.106.52.160]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2011E81A8 for ; Tue, 7 Jun 2011 13:17:09 -0700 (PDT) Received: from ([172.20.1.71]) by bateleur.viasat.com with ESMTP id H6GMFJ1.45665651; Tue, 07 Jun 2011 13:17:05 -0700 Received: from vcaexch06.hq.corp.viasat.com ([172.18.46.74]) by VCAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jun 2011 13:17:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC254F.C89161EE" Date: Tue, 7 Jun 2011 13:16:28 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Freeing Memory and Constructors Thread-Index: AcwlT8i+OpC2oJYrQXCIpeOOY1Vn/g== From: "Nanjundiah, Girish" To: "CICM Discussion List" X-OriginalArrivalTime: 07 Jun 2011 20:17:05.0190 (UTC) FILETIME=[DE773460:01CC254F] Subject: [cicm] Freeing Memory and Constructors 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, 07 Jun 2011 20:17:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC254F.C89161EE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Everyone, =20 We have the following remaining questions about the CICM code and were wondering if anyone had any ideas: =20 1. Many of the functions in the CICM driver are called with a double pointer parameter that is labeled as "out", meaning that the parameter is expected to be pointing to a newly created instance of its type upon the function's return (Ex: Decrypt::Stream::decrypt( Buffer** buffer )). By allocating memory in functions like this, we introduce memory leaks into the program since decrypt.cpp and encrypt.cpp do not delete anything. Is this acceptable behavior or should we add member variables with destructors into the classes to take care of cleaning up the memory? 2. Using _get and _set functions for accessing member variables works but it also introduces the potential problem of depending on uninitialized read-only member variables to set a value (Ex: We use the read-only Key::State state variable to check if a Key::_set_identifier() call is valid). Since we do not have any constructors defined in the CICM spec, how are we meant to set read-only member variables (since in IDL, read-only members only imply _get methods)? =20 Thanks for taking the time to read this, -Girish =20 ------_=_NextPart_001_01CC254F.C89161EE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Everyone,

We have the following = remaining questions about the CICM code and were wondering if anyone had = any ideas:

1. = Many of the functions in the CICM driver are = called with a double pointer parameter that is labeled as = “out”, meaning that the parameter is expected to be pointing = to a newly created instance of its type upon the function’s return = (Ex: Decrypt::Stream::decrypt( Buffer** buffer )). By allocating memory = in functions like this, we introduce memory leaks into the program since = decrypt.cpp and encrypt.cpp do not delete anything. Is this acceptable = behavior or should we add member variables with destructors into the = classes to take care of cleaning up the memory?

2. = Using _get and _set functions for accessing = member variables works but it also introduces the potential problem of = depending on uninitialized read-only member variables to set a value = (Ex: We use the read-only Key::State state variable to check if a = Key::_set_identifier() call is valid). Since we do not have any = constructors defined in the CICM spec, how are we meant to set read-only = member variables (since in IDL, read-only members only imply _get = methods)?

Thanks for taking the = time to read this,

-Girish

------_=_NextPart_001_01CC254F.C89161EE-- From girish.nanjundiah@viasat.com Thu Jun 9 16:28:10 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 4441F11E813C for ; Thu, 9 Jun 2011 16:28:10 -0700 (PDT) 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=[AWL=0.000, 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 w2VTcDzwywPZ for ; Thu, 9 Jun 2011 16:28:09 -0700 (PDT) Received: from viasat.com (bateleur.viasat.com [199.106.52.160]) by ietfa.amsl.com (Postfix) with ESMTP id 250A811E812C for ; Thu, 9 Jun 2011 16:28:09 -0700 (PDT) Received: from ([172.20.1.71]) by bateleur.viasat.com with ESMTP id H6GMFJ1.45830428; Thu, 09 Jun 2011 16:28:06 -0700 Received: from vcaexch06.hq.corp.viasat.com ([172.18.46.74]) by VCAEXCH02.hq.corp.viasat.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jun 2011 16:28: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, 9 Jun 2011 16:27:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cicm] Moving Packets and Storing Identifiers (was RE:CICMQuestions) Thread-Index: AcwcpsTkd/0hRpvdRrCyJDEF6zWhTwC7DKNAAdnXQGA= References:

From: "Nanjundiah, Girish" To: "CICM Discussion List" X-OriginalArrivalTime: 09 Jun 2011 23:28:06.0263 (UTC) FILETIME=[E29FA870:01CC26FC] Subject: Re: [cicm] Moving Packets and Storing Identifiers (was RE:CICMQuestions) 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, 09 Jun 2011 23:28:10 -0000 With regards to this, I should also mention that it would be best to store the identifier in the CICM::Stream class. The reason is that both create_en/decrypt_conduit and en/decrypt both need access to the identifier. The create function needs to store the conduit identifier that it obtains from the module in the CICM::Conduit parameter that it is given and the encryption/decryption functions (part of the CICM::Encrypt/Decrypt::Stream) need to use the identifier to tell the module to perform the requested encryption/decryption. Since encrypt/decrypt() cannot access the CICM::Conduit variables (CICM::Conduit is one inheritance level up from CICM::Encrypt/Decrypt::Stream), it would make sense to define the identifier in a class that both CICM::Encrypt/Decrypt::Stream can access. Both classes inherit from CICM::Stream as a base class, so that would seem to be the best choice from my point of view.=20 Is this still something that people are alright with? Thanks, -Girish -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Steven.DiMedio@L-3Com.com Sent: Tuesday, May 31, 2011 8:43 AM To: CICM Discussion List Subject: Re: [cicm] Moving Packets and Storing Identifiers (was RE:CICMQuestions) Lev (and group),=20 I'm implementing the CICM driver here at L3. I'd support the concept of extending the API to allow vendors to store a conduit identifier as a numeric value, such as channel ID. This allows vendors to link the conduits created through the API to their own internal hardware-specific attributes for the conduits. Regards, Steve DiMedio L-3 Communications 856-338-4204 >> 2. When create_en/decrypt_conduit is finished executing, it needs to store=20 >> an identifier (just a number really) to identify the conduit it has created=20 >> with the Crypto. Since both of these functions only return a status and a=20 >> CICM::En/Decrypt::Conduit pointer, the only way to store the identifier for=20 >> the conduit to use is to add it as a member variable to the Conduit class.=20 >> If the variable is to be private, we would also need a simple public member=20 >> function to access it. Is there a way to update the CICM API so that we can=20 >> store the conduit's identifier in one of the ways I listed? > >This is an interesting suggestion. We define KeyId for key identifiers, but=20 >we do not define a ChannelId for channel identifiers. This is because there >isn't currently a way to lookup a channel by its identifier (like there is=20 >for keys, modules, and tokens). > >This is going to require some discussion. Normally, vendor-specific attributes >are defined by extending the CICM base object and adding those properties.=20 >However, it seems like a common operation to store a vendor-specific=20 >identifier in a CICM object to make it easy to reference the underlying object >later on. > >** What do people think about extending the API to allow vendors to store a=20 > single numeric value to uniquely identify the objects to the underlying=20 > system? > =20 >Lev _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm From lnovikov@mitre.org Fri Jun 17 11:52:36 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 63B979E802C for ; Fri, 17 Jun 2011 11:52:36 -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 6n+42uxF3M0f for ; Fri, 17 Jun 2011 11:52:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D372C9E802B for ; Fri, 17 Jun 2011 11:52:35 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2547121B1D64 for ; Fri, 17 Jun 2011 14:52:33 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 20C3021B1D5F for ; Fri, 17 Jun 2011 14:52:33 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 17 Jun 2011 14:52:33 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Fri, 17 Jun 2011 14:51:43 -0400 Thread-Topic: Storing Identifiers Thread-Index: AcwtH5mSk8xtebnwRAamBPgFwO4y7w== 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] Storing Identifiers 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, 17 Jun 2011 18:52:36 -0000 Girish, On 2011-06-09 19:27, Girish Nanjundiah wrote: > With regards to this, I should also mention that it would be best to > store the identifier in the CICM::Stream class. > [...] My proposal was actually more general: To store an vendor-defined=20 identifier with ANY object. http://www.ietf.org/mail-archive/web/cicm/current/msg00144.html For your specific situation, it would actually make more sense to store=20 the identifier in the CICM::Channel object because a CICM::Stream is a=20 CICM::Channel (and so is a CICM::Conduit). Lev From lnovikov@mitre.org Fri Jun 17 11:58:00 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 51A019E802D for ; Fri, 17 Jun 2011 11:58:00 -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 xY0lmYiKMuHH for ; Fri, 17 Jun 2011 11:57:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6C9E8026 for ; Fri, 17 Jun 2011 11:57:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3821221B1D66 for ; Fri, 17 Jun 2011 14:57:59 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 33D0821B0C17 for ; Fri, 17 Jun 2011 14:57:59 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 17 Jun 2011 14:57:59 -0400 From: "Novikov, Lev" To: CICM Discussion List Date: Fri, 17 Jun 2011 14:56:05 -0400 Thread-Topic: Moving Packets Thread-Index: AcwtIDWpAazCH2KDS+aIA2rCngrpdQ== 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] Moving Packets 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, 17 Jun 2011 18:58:00 -0000 I've had a chance to reflect some more on the question that Girish had asked (as well as those asked by others previously). On 2011-05-27 15:47, Lev Novikov wrote: > In fact, CICM does not define functions for simply moving data into > the crypto. Therefore, you are free to use whatever transport > mechanism works for you (e.g., POSIX socket). On 2011-05-27 18:35, Girish Nanjundiah wrote: > [...] while we can define the actual mechanism to reflect back the=20 > packets outside of the driver, the driver still needs to call the > function/mechanism that we define within its decrypt() function before > it can expect the packet to appear. [...] Two points: 1. The specification for decrypt() says: > Read plaintext data off of decrypt channel stream. The method=20 > blocks until data becomes available. See http://tools.ietf.org/html/draft-lanz-cicm-cm-00#section-10.2.2 Therefore, decrypt() should be called *before* there is data and only returns when there is data (or an error occurs). =20 2. My initial response to your question was based on a misunderstanding; I thought you were asking "What function--on the unprotected side-- pushes the data into the module?" Our current design does not have=20 anything like that, but perhaps it should. I will address the=20 relevant issues in a separate email. =20 Lev From lnovikov@mitre.org Fri Jun 17 12:15:08 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 ADC2022800E for ; Fri, 17 Jun 2011 12:15:08 -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 D8JSx33vEY89 for ; Fri, 17 Jun 2011 12:15:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A16639E8047 for ; Fri, 17 Jun 2011 12:15:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 225B521B1E65 for ; Fri, 17 Jun 2011 15:15:07 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1D79A21B1E61 for ; Fri, 17 Jun 2011 15:15:07 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 17 Jun 2011 15:15:07 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Fri, 17 Jun 2011 15:13:41 -0400 Thread-Topic: Unprotected-side APIs Thread-Index: AcwtIquJhQ9/mD3+SHG7s8pUB5MLCQ== 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] Unprotected-side APIs 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, 17 Jun 2011 19:15:09 -0000 As I previously mentioned, CICM does not define any APIs that simply move data into / out of the crypto. After several discussions, I believe there may be a need for additions to the API to support such operations. Here are the issues: * Currently, CICM does not define a mechanism for the unprotected side to pump data into / out of the module. * Moreover, there is no mechanism to provide non-payload data (e.g., supply an IV on the decrypt side). * Currently, there is no way to associate any given traffic on the unprotected side with a channel on the protected side. Here are some ways we can start to address these issues. 1. CICM has a notion of a Module Event (similar to a callback or interrupt) which is activated under certain conditions. See: http://tools.ietf.org/html/draft-lanz-cicm-mm-00#section-9 2. We can define a set of events that are relevant to the unprotected side of a module. For example, it can be notified of the creation of a new channel on the protected side. ** What other events would need to be defined? 3. We would also have to define appropriate administrative functions for the unprotected side to perform such as supply an IV, provide header-bypass information, move data into/out of the crypto. ** What other administrative functions would need to be defined? ** What are other issues that need to be considered? NOTE I recognize that these APIs may not be appropriate for each and every environment, but I am interested in feedback for those where it would apply. Thanks, Lev From lnovikov@mitre.org Fri Jun 17 12:34:53 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 EC1F99E8031 for ; Fri, 17 Jun 2011 12:34:53 -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 OrK-Qsq7ucnx for ; Fri, 17 Jun 2011 12:34:53 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 373339E800A for ; Fri, 17 Jun 2011 12:34:52 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1E80C21B1707 for ; Fri, 17 Jun 2011 15:34:52 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 19E3E21B16E5 for ; Fri, 17 Jun 2011 15:34:52 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Fri, 17 Jun 2011 15:34:52 -0400 From: "Novikov, Lev" To: "CICM Discussion List (cicm@ietf.org)" Date: Fri, 17 Jun 2011 15:33:25 -0400 Thread-Topic: CICM BOF Approved for IETF 81 Thread-Index: AcwtJWzOCK69+yoiSCyVUv2RQUoPJw== 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 Approved for IETF 81 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, 17 Jun 2011 19:34:54 -0000 On 2011-05-13 13:01, Lev Novikov wrote: > I'm formally requesting a BoF at IETF 81 to form a CICM WG [...] Well I'm pleased to announce that the BOF has been approved. See: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Security What this means: 1. We (as a community) have one hour to make the case that CICM is a worthwhile endeavor and that neither PKCS#11 nor GSS-API can be simply extended to accommodate the needs that CICM addresses. 2. We need people to participate in the Jabber chat session (or in person in Quebec City, Canada) to voice their position on this effort. It will take place sometime during the week of July 24-29; the exact day/time will be announced later. ** Please respond to this email letting me know if you plan on attending the BOF in person or online via the Jabber session. Thanks, Lev From lnovikov@mitre.org Tue Jun 21 12: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 EAC0E1F0C46 for ; Tue, 21 Jun 2011 12:20:16 -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 yS7vwmi5zvsM for ; Tue, 21 Jun 2011 12:20:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 54FEF1F0C38 for ; Tue, 21 Jun 2011 12:20:15 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6F24821B11EA; Tue, 21 Jun 2011 15:20:14 -0400 (EDT) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6A62021B0EF3; Tue, 21 Jun 2011 15:20:14 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Tue, 21 Jun 2011 15:20:14 -0400 From: "Novikov, Lev" To: Crypto discussion list Date: Tue, 21 Jun 2011 15:19:08 -0400 Thread-Topic: [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM) Thread-Index: AcwwQH0fiSh6ngwjSyi7APC2FyIeoQAAF8Yw 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Nico Williams , "CICM Discussion List \(cicm@ietf.org\)" Subject: Re: [cicm] [cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (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: Tue, 21 Jun 2011 19:20:17 -0000 Q3Jvc3MtcG9zdGVkIG9uIDxjaWNtQGlldGYub3JnPi4NClRoaXMgaXMgYSBkaXNjdXNzaW9uIHRo YXQgc3RhcnRlZCBvbiB0aGUgQ3J5cHRvZ3JhcGh5IG1haWxpbmcgbGlzdDoNCmh0dHA6Ly9saXN0 cy5yYW5kb21iaXQubmV0L3BpcGVybWFpbC9jcnlwdG9ncmFwaHkvMjAxMS1KdW5lLzAwMDk0MC5o dG1sDQoNCk5PVEU6IFlvdSBuZWVkIHRvIGJlIGEgbWVtYmVyIHRvIHBvc3Qgb24gZWl0aGVyIGxp c3QuDQogIFJhbmRvbUJpdDogaHR0cDovL2xpc3RzLnJhbmRvbWJpdC5uZXQvbWFpbG1hbi9saXN0 aW5mby9jcnlwdG9ncmFwaHkNCiAgSUVURjogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jaWNtDQoNCk5pY28sDQoNCk9uIDIwMTEtMDYtMjEgMTQ6MjUsIE5pY28gV2lsbGlh bXMgd3JvdGU6DQo+IEV2ZW4gc28sIHdoYXQgdmFsdWUgZG9lcyB0aGlzIGFkZCBvdmVyLCBhbnkg b2YgdGhlIEFQSXMgYW5kIGZyYW1ld29ya3MNCj4gd2UgYWxyZWFkeSBoYXZlPw0KPg0KPiBJZiB0 aGUgaXNzdWUgaXMgZW5zdXJpbmcgdGhhdCB5b3UgYXJlIGFibGUgdG8gbG9naW4gdG8gdG9rZW5z LCB3aHkgbm90DQo+IGFkZCBzdWl0YWJsZSBleHRlbnNpb25zIHRvIHRoZSBHU1MtQVBJIChiYXNp Y2FsbHkgYSBzaW5nbGUgZnVuY3Rpb24pPw0KDQpUaGUgaXNzdWUgaXMgbXVjaCBicm9hZGVyLg0K DQpGb3IgZXhhbXBsZSwgaGVyZSdzIGEgcXVvdGUgZnJvbSBSRkMgMjc0MyAoR1NTLUFQSSB2Mi4x KToNCj4gVGhlIGNsaWVudCBnZW5lcmF0ZXMgYSBkYXRhIG1lc3NhZ2UgYW5kIHBhc3NlcyBpdCB0 byBHU1NfV3JhcCgpLg0KPiBHU1NfV3JhcCgpIHBlcmZvcm1zIGRhdGEgb3JpZ2luIGF1dGhlbnRp Y2F0aW9uLCBkYXRhIGludGVncml0eSwgYW5kDQo+IChvcHRpb25hbGx5KSBjb25maWRlbnRpYWxp dHkgcHJvY2Vzc2luZyBvbiB0aGUgbWVzc2FnZSBhbmQNCj4gZW5jYXBzdWxhdGVzIHRoZSByZXN1 bHQgaW50byBvdXRwdXRfbWVzc2FnZSwgaW5kaWNhdGluZw0KPiBHU1NfU19DT01QTEVURSBzdGF0 dXMuIFRoZSBjbGllbnQgc2VuZHMgdGhlIG91dHB1dF9tZXNzYWdlIHRvIHRoZQ0KPiBzZXJ2ZXIu DQoNClRoaXMgbWFrZXMgc2Vuc2UgZm9yIG1hbnkgZGV2aWNlcyBhbmQgZW52aXJvbm1lbnRzLiBI b3dldmVyLCBoaWdoDQphc3N1cmFuY2UgZW52aXJvbm1lbnRzIGFyZSBtb3JlIHZhcmllZC4gRm9y IGV4YW1wbGUsIHlvdSBtYXkgaGF2ZSB0d28NCnByb2Nlc3NlcyB0aGF0IGNvbnRyb2wgKGluIGEg bXV0dWFsbHkgZXhjbHVzaXZlIG1hbm5lcikgdGhlIGNoYW5uZWwNCmNyZWF0aW9uIGFuZCBuZWdv dGlhdGlvbiAoYSBDb250cm9sbGVyIGluIENJQ00tc3BlYWspIGFuZCB0aGUgZGF0YSBmbG93DQpv biB0aGUgY2hhbm5lbCAoU3RyZWFtKS4NCg0KQW5vdGhlciBleGFtcGxlOg0KSW4gZXhpc3Rpbmcg QVBJcywgeW91IGNhbiBwZXJmb3JtIHR3byBvcGVyYXRpb25zIGJ5IGFwcGx5aW5nIGVhY2gNCm9w ZXJhdGlvbiBpbiBzZXF1ZW5jZSBvbiB0aGUgcGxhaW50ZXh0IChlLmcuLCBlbmNyeXB0IGFuZCBz aWduKS4NCkhvd2V2ZXIsIGhpZ2ggYXNzdXJhbmNlIG1vZHVsZSBvZnRlbiBzdXBwb3J0IGF0b21p YyAiaHlicmlkIiBvcGVyYXRpb25zDQp3aGljaCBjYW5ub3QgYmUgYWNjb21wbGlzaGVkIHdpdGgg ZXhpc3RpbmcgQVBJcyB3aGVuIHRoZSBkYXRhIHRoYXQgaXMNCnByb3ZpZGVkIHRvIHRoZSBtb2R1 bGUgZG9lcyBub3QgcmV0dXJuIGJhY2sgdG8gdGhlIGNhbGxpbmcgcHJvZ3JhbS4NCg0KSSB1bmRl cnN0YW5kIHRoZSBkZXNpcmUgdG8gYXZvaWQgY3JlYXRpbmcgbmV3IEFQSXMgd2hlbiB0aGVyZSBh cmUgc28NCm1hbnkgZXhpc3Rpbmcgb25lcyAoc3VyZWx5IG9uZSBvZiB0aGVtIHNob3VsZCBkbyB0 aGUgdHJpY2shPykuIEhvd2V2ZXIsDQp0aGUgZmVlZGJhY2sgZnJvbSB1c2VycyBhbmQgdmVuZG9y cyBpcyB0aGF0IHRoZSB1bmRlcmx5aW5nIGxvZ2ljYWwgDQptb2RlbHMgb2YgdGhlaXIgZGV2aWNl cyBpcyBzdWZmaWNpZW50bHkgZGlmZmVyZW50IChhbmQgdmFyaWVkKSBmcm9tIHdoYXQNCmV4aXN0 aW5nIEFQSXMgYXNzdW1lIHRoYXQgaXQgaXMgZGlmZmljdWx0IHRvIHJldHJvZml0IHRoZWlyIGNv bmNlcHRzIGFuZA0KcmVxdWlyZW1lbnRzIGludG8gdGhvc2UgQVBJcy4gQW1vbmcgb3RoZXIgcmVh c29ucywgdGhpcyBpcyB3aHkgdGhlcmUgaXMgDQpzdWNoIGEgcHJvbGlmZXJhdGlvbiBvZiBwcm9w cmlldGFyeSBBUElzIGluIHRoZXNlIGVudmlyb25tZW50cyAod2hpY2ggQ0lDTQ0KaXMgdHJ5aW5n IHRvIHVuaWZ5LCBhYnN0cmFjdCwgYW5kIHN0YW5kYXJkaXplKS4NCg0KTGV2DQo= From nico@cryptonector.com Thu Jun 23 17:07: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 68A9711E80D8 for ; Thu, 23 Jun 2011 17:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.841 X-Spam-Level: X-Spam-Status: No, score=-2.841 tagged_above=-999 required=5 tests=[AWL=-0.864, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 ZhmqNTM21JkV for ; Thu, 23 Jun 2011 17:07:56 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CB11E8086 for ; Thu, 23 Jun 2011 17:07:56 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 3FED2768059 for ; Thu, 23 Jun 2011 17:07:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; q=dns; s=cryptonector.com; b=GwjAvTq6 PtzZw7kgA/8tvD04h1r89/9tqRx5jWzURGtKKzIK6XRczq6ON9A9tBDqf02I2JON 5ZKOpbIOgc7ZcqKWQPSOpGEBn44xHHMzVTD4QaxXgAU971Ua1xYeervlRUTwsNpU uVnH+pzOf2zPjQFoZ2Fg9of0Qe8vZLbK64Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type: content-transfer-encoding; s=cryptonector.com; bh=qeJS4YpaCub+/o 0NtJ2rwFcPkYk=; b=JawPifvR34BVuU3FR8F0ANId8ZrSJaJVm+iaEr7qMFPzug hsymi5JonhABDN0VghJex1k0shwvukWZDrUe45J2iMw2oMqFp1SCrom1U8Cm98lW d2QroFg7Cif8hkIPuUxhAWGMlYz414KEYg+sdEhXhCcRus5eNY6OpzyN6Zoho= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 23A98768058 for ; Thu, 23 Jun 2011 17:07:56 -0700 (PDT) Received: by pwj5 with SMTP id 5so1637783pwj.31 for ; Thu, 23 Jun 2011 17:07:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.103 with SMTP id n7mr1405615pbd.73.1308874075717; Thu, 23 Jun 2011 17:07:55 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Thu, 23 Jun 2011 17:07:55 -0700 (PDT) Date: Thu, 23 Jun 2011 19:07:55 -0500 Message-ID: From: Nico Williams To: "Novikov, Lev" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Crypto discussion list , "CICM Discussion List \(cicm@ietf.org\)" Subject: [cicm] CICM Channels and GSS (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (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: Fri, 24 Jun 2011 00:07:57 -0000 On Tue, Jun 21, 2011 at 2:19 PM, Novikov, Lev wrote: > Cross-posted on . > This is a discussion that started on the Cryptography mailing list: > http://lists.randombit.net/pipermail/cryptography/2011-June/000940.html > > NOTE: You need to be a member to post on either list. > =C2=A0RandomBit: http://lists.randombit.net/mailman/listinfo/cryptography > =C2=A0IETF: https://www.ietf.org/mailman/listinfo/cicm I suggest that you allow posts by non-subscribers who are subscribers of any IETF lists -- I cannot subscribe to every IETF list. > On 2011-06-21 14:25, Nico Williams wrote: >> Even so, what value does this add over, any of the APIs and frameworks >> we already have? >> >> If the issue is ensuring that you are able to login to tokens, why not >> add suitable extensions to the GSS-API (basically a single function)? > > The issue is much broader. > > For example, here's a quote from RFC 2743 (GSS-API v2.1): >> The client generates a data message and passes it to GSS_Wrap(). >> GSS_Wrap() performs data origin authentication, data integrity, and >> (optionally) confidentiality processing on the message and >> encapsulates the result into output_message, indicating >> GSS_S_COMPLETE status. The client sends the output_message to the >> server. > > This makes sense for many devices and environments. However, high > assurance environments are more varied. For example, you may have two > processes that control (in a mutually exclusive manner) the channel > creation and negotiation (a Controller in CICM-speak) and the data flow > on the channel (Stream). Nothing stops you from building an application that has several sub-channels built on existing technologies. I'd be happy with you specifying such a protocol as long as it is on top of existing secure channel technology, or, as long as you show why that just won't do (I'm open to that possibility). (I could also end up on the rough side of consensus, but I'd rather make CICM palatable to a larger audience.) Also, you can structure privilege separation with only one channel. And you can bind multiple authentications into one channel (for an example of this see RPCSEC_GSSv3[0]). You'll want to make sure that you cover why such alternatives are not appropriate. > Another example: > In existing APIs, you can perform two operations by applying each > operation in sequence on the plaintext (e.g., encrypt and sign). Not in the GSS-API. GSS wrap tokens cover both, confidentiality (optional) and integrity protection automatically for you; no need to think about how to do authenticated encryption. > However, high assurance module often support atomic "hybrid" operations > which cannot be accomplished with existing APIs when the data that is > provided to the module does not return back to the calling program. Do you mean AE and/or AEAD cipher modes? The GSS-API most certainly precludes neither (see above). > I understand the desire to avoid creating new APIs when there are so > many existing ones (surely one of them should do the trick!?). However, > the feedback from users and vendors is that the underlying logical > models of their devices is sufficiently different (and varied) from what > existing APIs assume that it is difficult to retrofit their concepts and Some of the experts you need are in the KITTEN WG. I'm sure KITTEN WG participants will be happy to talk to you about these issues, or to put you in contact with other KITTEN WG participants. We have been *adding* to the GSS-API to make it meet our needs. Surely you might consider the same approach? > requirements into those APIs. Among other reasons, this is why there is > such a proliferation of proprietary APIs in these environments (which CIC= M > is trying to unify, abstract, and standardize). Whereas I suspect that proprietary APIs proliferate due to either a) a vendor's desire to keep their APIs proprietary, b) accidental ignorance of existing alternatives. In this case it seems I have to educate myself as to your needs, but I'm not sure that you and/or other CICM proponents are really up to date on the GSS-API. I don't mean that you should be an expert in the GSS-API before setting out to build something like CICM, but it would be good to make sure that CICM, or parts of it, are not predicated on misconceptions about existing APIs. [0] http://tools.ietf.org/html/draft-ietf-nfsv4-rpcsec-gssv3-00 Nico -- From lnovikov@mitre.org Fri Jun 24 12:09: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 533E911E816E for ; Fri, 24 Jun 2011 12:09: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 fX4xc92joHCw for ; Fri, 24 Jun 2011 12:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 641B711E8106 for ; Fri, 24 Jun 2011 12:09:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E3F2B21B1DA5; Fri, 24 Jun 2011 15:09:36 -0400 (EDT) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DCD7B21B0F5D; Fri, 24 Jun 2011 15:09:36 -0400 (EDT) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Fri, 24 Jun 2011 15:09:36 -0400 From: "Novikov, Lev" To: Nico Williams Date: Fri, 24 Jun 2011 15:08:54 -0400 Thread-Topic: CICM Channels and GSS (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)) Thread-Index: AcwyAsX7ML37X0AjRtifaJYSxfVwIgAeD51g 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Crypto discussion list , "CICM Discussion List \(cicm@ietf.org\)" Subject: Re: [cicm] CICM Channels and GSS (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (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: Fri, 24 Jun 2011 19:09:38 -0000 TmljbywNCg0KT24gMjAxMS0wNi0yMyAyMDowOCwgTmljbyBXaWxsaWFtcyB3cm90ZToNCj4gTm90 aGluZyBzdG9wcyB5b3UgZnJvbSBidWlsZGluZyBhbiBhcHBsaWNhdGlvbiB0aGF0IGhhcyBzZXZl cmFsDQo+IHN1Yi1jaGFubmVscyBidWlsdCBvbiBleGlzdGluZyB0ZWNobm9sb2dpZXMuDQo+IA0K PiBJJ2QgYmUgaGFwcHkgd2l0aCB5b3Ugc3BlY2lmeWluZyBzdWNoIGEgcHJvdG9jb2wgYXMgbG9u ZyBhcyBpdCBpcyBvbg0KPiB0b3Agb2YgZXhpc3Rpbmcgc2VjdXJlIGNoYW5uZWwgdGVjaG5vbG9n eSwgb3IsIGFzIGxvbmcgYXMgeW91IHNob3cgd2h5DQo+IHRoYXQganVzdCB3b24ndCBkbyAoSSdt IG9wZW4gdG8gdGhhdCBwb3NzaWJpbGl0eSkuICAoSSBjb3VsZCBhbHNvIGVuZA0KPiB1cCBvbiB0 aGUgcm91Z2ggc2lkZSBvZiBjb25zZW5zdXMsIGJ1dCBJJ2QgcmF0aGVyIG1ha2UgQ0lDTSBwYWxh dGFibGUNCj4gdG8gYSBsYXJnZXIgYXVkaWVuY2UuKQ0KPiANCj4gQWxzbywgeW91IGNhbiBzdHJ1 Y3R1cmUgcHJpdmlsZWdlIHNlcGFyYXRpb24gd2l0aCBvbmx5IG9uZSBjaGFubmVsLg0KPiBBbmQg eW91IGNhbiBiaW5kIG11bHRpcGxlIGF1dGhlbnRpY2F0aW9ucyBpbnRvIG9uZSBjaGFubmVsIChm b3IgYW4NCj4gZXhhbXBsZSBvZiB0aGlzIHNlZSBSUENTRUNfR1NTdjNbMF0pLiAgWW91J2xsIHdh bnQgdG8gbWFrZSBzdXJlIHRoYXQNCj4geW91IGNvdmVyIHdoeSBzdWNoIGFsdGVybmF0aXZlcyBh cmUgbm90IGFwcHJvcHJpYXRlLg0KPiBbLi4uXQ0KPiBHU1Mgd3JhcCB0b2tlbnMgY292ZXIgYm90 aCwgY29uZmlkZW50aWFsaXR5IChvcHRpb25hbCkgYW5kIGludGVncml0eSANCj4gcHJvdGVjdGlv biBhdXRvbWF0aWNhbGx5IGZvciB5b3U7IG5vIG5lZWQgdG8gdGhpbmsgYWJvdXQgaG93IHRvIGRv IA0KPiBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24uDQo+IFsuLi5dDQo+IFNvbWUgb2YgdGhlIGV4 cGVydHMgeW91IG5lZWQgYXJlIGluIHRoZSBLSVRURU4gV0cuICBJJ20gc3VyZSBLSVRURU4gV0cN Cj4gcGFydGljaXBhbnRzIHdpbGwgYmUgaGFwcHkgdG8gdGFsayB0byB5b3UgYWJvdXQgdGhlc2Ug aXNzdWVzLCBvciB0bw0KPiBwdXQgeW91IGluIGNvbnRhY3Qgd2l0aCBvdGhlciBLSVRURU4gV0cg cGFydGljaXBhbnRzLiAgV2UgaGF2ZSBiZWVuDQo+ICphZGRpbmcqIHRvIHRoZSBHU1MtQVBJIHRv IG1ha2UgaXQgbWVldCBvdXIgbmVlZHMuICBTdXJlbHkgeW91IG1pZ2h0DQo+IGNvbnNpZGVyIHRo ZSBzYW1lIGFwcHJvYWNoPw0KPiBbLi4uXQ0KPiBJbiB0aGlzIGNhc2UgaXQgc2VlbXMgSSBoYXZl IHRvIGVkdWNhdGUgbXlzZWxmIGFzIHRvIHlvdXIgbmVlZHMsDQo+IGJ1dCBJJ20gbm90IHN1cmUg dGhhdCB5b3UgYW5kL29yIG90aGVyIENJQ00gcHJvcG9uZW50cyBhcmUgcmVhbGx5IHVwIA0KPiB0 byBkYXRlIG9uIHRoZSBHU1MtQVBJLiAgSSBkb24ndCBtZWFuIHRoYXQgeW91IHNob3VsZCBiZSBh biBleHBlcnQgaW4gDQo+IHRoZSBHU1MtQVBJIGJlZm9yZSBzZXR0aW5nIG91dCB0byBidWlsZCBz b21ldGhpbmcgbGlrZSBDSUNNLCBidXQgaXQgDQo+IHdvdWxkIGJlIGdvb2QgdG8gbWFrZSBzdXJl IHRoYXQgQ0lDTSwgb3IgcGFydHMgb2YgaXQsIGFyZSBub3QgDQo+IHByZWRpY2F0ZWQgb24gbWlz Y29uY2VwdGlvbnMgYWJvdXQgZXhpc3RpbmcgQVBJcy4NCg0KQ2xlYXJseSwgSSBuZWVkIHRvIG1h a2UgYSBiZXR0ZXIgZWZmb3J0IGF0IGJlaW5nIGVkdWNhdGVkIGFib3V0IEdTUy1BUEkuDQpJJ2xs IGJlIGluIHRvdWNoIHdpdGggdGhlIEtJVFRFTiBmb2xrcywgcGVyIHlvdXIgc3VnZ2VzdGlvbi4N Cg0KSW4gYnJpZWYsIHlvdSdkIGxpa2UgdG8ga25vdyBDSUNNIGNhbid0IHVzZSBHU1MtQVBJIGFu ZDoNCiAgKiB1c2UgZXhpc3Rpbmcgc2VjdXJlIGNoYW5uZWwgdGVjaG5vbG9naWVzLA0KICAqIGVu Zm9yY2UgcHJpdmlsZWdlIHNlcGFyYXRpb24gaW4gYSBzaW5nbGUgY2hhbm5lbCwNCiAgKiBiaW5k IG11bHRpcGxlIGF1dGhlbnRpY2F0aW9ucyBpbnRvIGEgc2luZ2xlIGNoYW5uZWwsDQogICogb3Ig ZXh0ZW5kIEdTUy1BUEkgdG8gbWVldCAob3RoZXIpIGhpZ2ggYXNzdXJhbmNlIG5lZWRzPw0KDQpB bSBJIG1pc3NpbmcgYW55dGhpbmc/DQoNClRoYW5rcywNCkxldg0K From nico@cryptonector.com Fri Jun 24 12:21:43 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 715DE11E80EE for ; Fri, 24 Jun 2011 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 FwXB0B8xm1As for ; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id BEDEA11E80BE for ; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 94E5A350078 for ; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=dp8l6YTigKRGtvzPhWmbKQiNF1l9kwY4LRTeMOfk8eAY nONN4mHT5lhZyRdiSsKc0sB0iS8xQtxT1QSdgU9pupLlP268Eu6BXOovso/Vb8Zh hYv/RYFPM+pyeZVX8XOUPYZhUYZtZ8VhP/Lj2lvOHc47dobzvIzDvYSwGqEVP/Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=vr4fu7iPoJZ0ScP8zQoFAgoFfQs=; b=pLgNQJnCNBO taqMV0n9+yloedH1KcMF9O0TnwBFDqt7SAAuQdRAUPkBNzINx0tjI7lPlRqpOOaX B/n8YOoJEfGooBTes0RELcuBV6LXd/V5eXbYs8SKzxgsIR4/uQxfCO3ymyJQcVXq UoLEeTv9PQNNBpPcRpg36dGzgJVagpGU= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 70456350072 for ; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) Received: by pwj5 with SMTP id 5so2140743pwj.31 for ; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.9.5 with SMTP id v5mr1866461pba.140.1308943302072; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) Received: by 10.68.41.167 with HTTP; Fri, 24 Jun 2011 12:21:42 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Jun 2011 14:21:42 -0500 Message-ID: From: Nico Williams To: "Novikov, Lev" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Crypto discussion list , "CICM Discussion List \(cicm@ietf.org\)" Subject: Re: [cicm] CICM Channels and GSS (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (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: Fri, 24 Jun 2011 19:21:43 -0000 On Fri, Jun 24, 2011 at 2:08 PM, Novikov, Lev wrote: > Clearly, I need to make a better effort at being educated about GSS-API. > I'll be in touch with the KITTEN folks, per your suggestion. > > In brief, you'd like to know CICM can't use GSS-API and: > =C2=A0* use existing secure channel technologies, > =C2=A0* enforce privilege separation in a single channel, > =C2=A0* bind multiple authentications into a single channel, > =C2=A0* or extend GSS-API to meet (other) high assurance needs? > > Am I missing anything? That's about it, assuming the previous context. Basically, I would like strong justification for re-inventing wheels we already have. Sometimes we have to invent new wheels that are similar to, yet sufficiently distinguished from other wheels -- it's good to know what are the justifying distinctions. Thanks! Nico --