From cga-ext-bounces@ietf.org Wed Sep 3 06:51:39 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 917C13A6BBF; Wed, 3 Sep 2008 06:51:39 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603AF3A6403 for ; Wed, 3 Sep 2008 06:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 3fKvtw7FXFGZ for ; Wed, 3 Sep 2008 06:51:36 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 7D1BA3A6B1F for ; Wed, 3 Sep 2008 06:51:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-133-95.dialup.adsl.anteldata.net.uy [190.135.133.95])by smtp01.uc3m.es (Postfix) with ESMTP id 4B3BE9C5CFF;Wed, 3 Sep 2008 15:51:33 +0200 (CEST) Message-ID: <48BE9662.5060904@it.uc3m.es> Date: Wed, 03 Sep 2008 14:51:30 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cga-ext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.9664 TC:1F TRN:93 TV:5.5.1026(16134.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [CGA-EXT] Draft CSI meeting minutes X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Please find attached the minutes. Send comments if you want to change something ------------------------------------------ Minutes CSI WG meeting IETF72 ------------------------------------------ MONDAY, July 28, 2008 1300-1500 Afternoon Session I ------------------------------------------ Proxy SeND PS http://www.ietf.org/internet-drafts/draft-daley-csi-sndp-prob-00.txt Jean Michel - 15 min Marcelo: Do all the solutions address the complete problem space? JMC: Yes Suresh: Not really, all solutions together would do that but individual solutions do not. JMC: Wants to know if we should add references to potential solutions? Marcelo: thinks the answer was yes last meeting JMC: thought the answer was no Dave: Thinks no. but it is ok to describe classes of solutions. But there is no need to do so Gabe: Is it OK to add multicast? Dave: They are not used in ND Marcelo: OK to adopt unless there is no objection. (ADOPTED) Proxy SeND http://www3.tools.ietf.org/html/draft-krishnan-csi-proxy-send-00 Julien/Suresh - 15 min This version updates previous version to generalize it for more than proxy ND Marcelo: What about if the owner himself delegates the authority instead of trust anchor? Suresh: That is another class of solutions MArcelo: is not talking about ring signatues but each host individually delegates authority Suresh: The host does not know about the presence of the nd proxy at all. Julien: It is simpler to do it this way Marcelo: Easy way Dave: Solution looks good. There is two cases here Two trust models in ND proxy. This draft solves one but leaves the other one out. host->proxy->lan : The host can delegate the authority itself. Show of hands. (Seems to be about 15-20 hands) Chairs thinks that this draft looks OK for adoption but will check on ML Hash Agility for SeND http://www3.tools.ietf.org/html/draft-kukec-csi-hash-threat-02 Sheng - 10 min Marcelo - Is the option vulnerable to downgrading attacks Sheng - yes Marcelo - if the method for CGA and RSA signature is the same. then downgrading is not possible Sheng - this could be possible for just some messages Julien - this approach does not work. You need to encode some how in the address the hash function you want to use. Marcelo - there is no way to avoid downgrade attacks in this way Suresh - just make public that an algorithm is no longer secure. Marcelo - I don't like this conclusion Julien - define nCGA, not cryptographic (requiring certificates from other parties), but with the algorithm encoded in the address. Gabriel - go forward with the analysis part, but not with the solution. Separate analysis and proposal. Julien - we have to agree on the requirements wanted. Should be analysis and requirments. All addresses must be CGAs (even the routers one's, because then it cannot test for reachability. Marcelo and Gab: Split the draft in two parts, one with the analysis and another one with the recommendation of how to encode the hash function in SeND. The first one is adopted and we need more discussion about the second one. (discussion to continue offline for the way to encode the hash function) ECC support for SeND http://www.ietf.org/proceedings/staging/draft-shen-csi-ecc-00.txt Sean/Michaela - 20 min An option is presented to support signature to include an ECC signature, both in the SEND signature and in the CGA parameter data structure. Marcelo: Parameter For sEND or for CGA? Shen: for SEND Gabriel. Is this aligned with the work made for TLS? Sean. Yes Gabriel. 256 is not too much for low capability devices? 160 may be fine Sean. Yes. Marcelo. Is any point in the CGA that says that the key is ECC? Sean. Not in the parameter data structure format Alberto. It is signaled in the DER-encoding of the public key. Marcelo. Why is this approach backward compatible? Does not agree that there is backward compatibility. If one node supports ECC and the other supports only RSA what happens. He wants multiple keys Marcelo. People should read the document, and think how it should be manage pki agility, that it is not obvious Certificate Management http://www.ietf.org/internet-drafts/draft-krishnan-cgaext-send-cert-eku-01.= txt Suresh - 20 min Needed semantics to adapt certificates to SEND use. How is performed Certificate revocation? CRL is bad idea if there are large numbers of elements. Certificate extensions that must be implemented. EKU field to specify any of 3 purposes: =B7 router =B7 proxy =B7 client (addr owner) =B7 useful if not a CGA address, but still wish to prove ownership of your address = items in the cert SAN - ip addr EKU key usage basic constraints auth info access = ready for review by security directorate nod from Tim Polk, to be continued off line "Requirements for configuring Cryptographically Generated Addresses (CGA) and overview on RA and DHCPv6-based approaches", http://www.ietf.org/internet-drafts/draft-jiang-sendcgaext-cga-config-01.txt Sheng - 10 min Gabe: wants to know about "validate IID" Sheng: mentions that it just avoids reserved IIDs Jari: why the focus on configuring parameters? IS it useful and/or required. You can just register the CGA with the dhcp server. Marcelo: we are chartered to identify useful things to make cga and dhcp work together. Not to identify parameters. Jari: wants to narrow down the scope. Dave: talks about Marcelo's question about proxy SEND. DHCP generates the address and delegates the authority to the receiving node CGA and SeND MIB http://www.ietf.org/internet-drafts/draft-garcia-martinez-cgamib-00.txt http://www.ietf.org/internet-drafts/draft-garcia-martinez-sendmib-00.txt Alberto - 15 min CGA mib Jari: Are you creating an address by creating an entry in a MIB? Alberto: Yes. Where is the private key? Alberto: That is a good point. Should only be used to manage Dave: It can be used to request a remote node to generate a public/private key pair Jari: That is fine to do, but why? Alberto: From central mgmt point. Dave: Uses Sec=3D2 to request preceomputation or for algorithm change Alberto: Is it valuable to use SNMP to configure CGA Jari: is not convinced that this is necessary. SEND mib Gabe: wants to wait a little bit until all the other work that is aiming to modify SEND is complete. Thomas: thinks the work is premature. How much experience do we have with SEND. Who will use this MIB. Even IP and TCP mibs on hosts are not used. If we want to use this on devices like set top boxes, we need buyin from some operator. Gabe: we might have a better answer at a later time when the wg progresses. Dave: It is possible to split the draft into router config and host config and we can then go forward with the router part. Distributing a Symmetric Neighbor Discovery Key Using SEND" http://tools.ietf.org/id/draft-xia-csi-symmetric-key-00.txt Frank - 5 min Gabe: 6lowpan has l2 security. Are there any residual threats? JMC: Not clear from 6lowpan docs. Also can use this with netlmm. Gabe: netlmm is also used on carrier based networks which may also have l2 security JMC: refers to the security analysis draft in 6lowpan which does not have much info Janos: How can we prevent a node from faking the router? Suresh: The host still verifies the router certificate as usual. _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 3 06:54:58 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E991C3A6BF4; Wed, 3 Sep 2008 06:54:58 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3DE3A6BF6 for ; Wed, 3 Sep 2008 06:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.913 X-Spam-Level: X-Spam-Status: No, score=-0.913 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 jFCiHSd5e1Ow for ; Wed, 3 Sep 2008 06:54:53 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id A3E363A6BF4 for ; Wed, 3 Sep 2008 06:54:50 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-133-95.dialup.adsl.anteldata.net.uy [190.135.133.95])by smtp03.uc3m.es (Postfix) with ESMTP id 1BB3A61DB40;Wed, 3 Sep 2008 15:54:53 +0200 (CEST) Message-ID: <48BE972C.4010607@it.uc3m.es> Date: Wed, 03 Sep 2008 14:54:52 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cga-ext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-6.3372 TC:1F TRN:9 TV:5.5.1026(16134.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [CGA-EXT] adoption of draft-daley-csi-sndp-prob-00.txt X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi, After discussion in the ml and in the meeting there is consensus to adopt draft-daley-csi-sndp-prob-00.txt as WG item. Please submit new version as draft-ietf-csi- Thanks, Gab and marcelo _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 3 06:57:07 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6ABE3A6BBF; Wed, 3 Sep 2008 06:57:07 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A6C03A6B1F for ; Wed, 3 Sep 2008 06:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 8w5PpT9e-McC for ; Wed, 3 Sep 2008 06:57:05 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 783853A68B0 for ; Wed, 3 Sep 2008 06:57:05 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-133-95.dialup.adsl.anteldata.net.uy [190.135.133.95])by smtp03.uc3m.es (Postfix) with ESMTP id F2CB761DA64;Wed, 3 Sep 2008 15:57:09 +0200 (CEST) Message-ID: <48BE97B4.2050701@it.uc3m.es> Date: Wed, 03 Sep 2008 14:57:08 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cga-ext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-3.7231 TC:1F TRN:11 TV:5.5.1026(16134.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [CGA-EXT] call for adoption for draft-krishnan-csi-proxy-send-00 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi, In the last meeting there was consensus to adopt draft-krishnan-csi-proxy-send-00 as a WG item. there were about 20 people supporting this. We would like to confirm the adoption in the ml. Please read the draft, send comments and express your opinion about this before the 18 september. Regards, Gab and marcelo _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 3 07:00:28 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325893A6C3B; Wed, 3 Sep 2008 07:00:28 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE363A6C3B for ; Wed, 3 Sep 2008 07:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] 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 uMw6renWl5nv for ; Wed, 3 Sep 2008 07:00:22 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 586783A6BFE for ; Wed, 3 Sep 2008 07:00:22 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-133-95.dialup.adsl.anteldata.net.uy [190.135.133.95])by smtp01.uc3m.es (Postfix) with ESMTP id 33E6F9C5BE1;Wed, 3 Sep 2008 16:00:20 +0200 (CEST) Message-ID: <48BE9873.7010605@it.uc3m.es> Date: Wed, 03 Sep 2008 15:00:19 +0100 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cga-ext@ietf.org X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.5829 TC:1F TRN:13 TV:5.5.1026(16134.007) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [CGA-EXT] adoption of draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi, In the meeting and in the ml there is consensus to adopt this document. However, while there is full consensus about the analysis, the actual proposed option to support hash agility needs more disucssion. For this reason, the proposal is to adopt the document as WG draft without the actual mean to support hash agility (i.e. we only keep the analysis) and we continue the disucssion about how to support hash agility in the ml. So, please authors submit a new version of the draft as draft-ietf-csi and launch disucssion on how to support the hash agility in the ml. Regards, marcelo _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Fri Sep 5 09:26:54 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F363A6A70; Fri, 5 Sep 2008 09:26:54 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C813A6A70 for ; Fri, 5 Sep 2008 09:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 HJ2jzafPuqAS for ; Fri, 5 Sep 2008 09:26:53 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by core3.amsl.com (Postfix) with ESMTP id 77E253A6A79 for ; Fri, 5 Sep 2008 09:26:53 -0700 (PDT) Received: from dcl-ex.dcml.docomolabs-usa.com (viruswall.docomolabs-usa.com [172.21.96.230]) by fridge.docomolabs-usa.com (Postfix) with ESMTP id C456E1B84F for ; Fri, 5 Sep 2008 09:26:53 -0700 (PDT) Received: from DCLKEMPF ([172.21.97.67]) by dcl-ex.dcml.docomolabs-usa.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 09:26:53 -0700 Message-ID: <7692BBEB001A46029D5EAD2F73328F07@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 5 Sep 2008 09:26:52 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 05 Sep 2008 16:26:53.0211 (UTC) FILETIME=[34BBB6B0:01C90F74] Subject: [CGA-EXT] Docomo USL SEND Distribution X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Docomo Labs USA has been distributing an open source implementation of SEND for several years. Unfortunately, we no longer have anyone here who is maintaining the code and therefore in the near future we would like to drop distribution by removing the link from our Web page. The code is licensed under the BSD license and therefore anyone can continue to maintain and distribute it, including incorporating it into commercial products (subject, of course, to any IPR from other parties), with no further obligation to Docomo except to keep Docomo's name on the code that was developed at Docomo and to continue using the BSD license on that code. Is there anyone who would like to take over the code and continue maintaining it, including working on whatever extensions the CSI WG decides upon? If so, please let me know by the end of Sept. so we can vector any future questions on the code to you. If we can't find anybody that wants to take over the code, we will likely remove the link from our Web page sometime in the near future, archive the code, and shut down the distribution mailing list with no referral for future questions. Note that this does not mean that Docomo is no longer interested in SEND. SEND is an important part of the entire IPv6 security architecture, and any work in CGI that helps to extend last hop link security is important for future wireless networks. jak _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Sat Sep 6 07:33:51 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AAC23A6A3D; Sat, 6 Sep 2008 07:33:51 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1F53A6A5B for ; Sat, 6 Sep 2008 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 ZXUxNFoHbELo for ; Sat, 6 Sep 2008 07:33:48 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id 8F9A83A69D5 for ; Sat, 6 Sep 2008 07:33:48 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m86EXlPF022188 for ; Sat, 6 Sep 2008 16:33:50 +0200 (CEST) Received: from [192.168.1.121] ([89.164.21.109]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Sep 2008 16:33:09 +0200 Message-ID: <48C294A4.8050508@fer.hr> Date: Sat, 06 Sep 2008 16:33:08 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: cga-ext@ietf.org X-OriginalArrivalTime: 06 Sep 2008 14:33:09.0625 (UTC) FILETIME=[7BF8DE90:01C9102D] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Subject: [CGA-EXT] hash function agility support in draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi all, We didn't reach the consensus about how to support hash function agility. We should try to reach the consensus, thus, i am sending the summary of analysis, possible solutions for encoding the hash functions, pros and cons. The uses of hashes are the following: a) Digital signature in X.509 certificate. Attacker can produce the false certificate with the same identity data and signature, and different key. After that, he does not have to break any other hash (CGA, key hash field, digital signature), just uses that new, unauthorized key in the generation of mentioned fields. b) CGAs. The same as with certificate, it is enough just to break the CGA, and use the false key in key hash field generation and for digital signature signing. c) Key hash field. Again the same thing. Attacker breaks the key hash and does not have to break any other hash, cause he just uses the new key for other fields generation. d) Digital signature. Attacker could change some of the SeND message fields. However the attack is probably just theoretically possible; in practice it is hard to perform it since there are mostly human-readable fields to be signed. Attacker does not need to break any other hash, the hashed message can be signed with authorized key (if attacker manages to change the message before the SeND node starts signing it). The question is, do we need to provide opportunity to choose different hash algorithms? If attacker attacks just one hash, he breaks the whole chain. Thus, it is enough to define just one hash algorithm in the Hash Algorithm option. On the other hand, the possibility for configuring multiple hashes provides additional flexibility. Additionally, we could support it because of the possible future changes in SeND. What are your opinions? Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Sun Sep 7 14:22:56 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B6F3A6954; Sun, 7 Sep 2008 14:22:56 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE473A6954 for ; Sun, 7 Sep 2008 14:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 rH7bwVhrgktq for ; Sun, 7 Sep 2008 14:22:54 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id 8BBEB3A692E for ; Sun, 7 Sep 2008 14:22:54 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m87LNTdH018991 for ; Sun, 7 Sep 2008 23:23:29 +0200 (CEST) Received: from [192.168.1.121] ([89.164.47.222]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Sep 2008 23:22:51 +0200 Message-ID: <48C44629.4030407@fer.hr> Date: Sun, 07 Sep 2008 23:22:49 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: cga-ext@ietf.org X-OriginalArrivalTime: 07 Sep 2008 21:22:51.0419 (UTC) FILETIME=[E246B6B0:01C9112F] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Subject: [CGA-EXT] Questions about RFC3971 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi all, Here are some questions about the RFC3971, there are some illogical paragraphs.. Answers are welcomed :-) 1. RFC3971 says about Router Solicitations: Section 5.1.1: If the node has been configured to use SEND, the CGA option MUST be present in all NS and Advertisement messages and MUST be present in RS messages unless they are sent with the unspecified source address. Section 5.1.2: Note that the CGA option is not used when the source address is the unspecified address. Section 5.2.2: Router Solicitation messages wihout the RSA Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address. -> Which means that message with unspecified address, without CGA and signature must be treated as secured? I am aware that the router will not update its Neighbor Cache in this situation. But anyway, why can such message be treated as secured? 2. RFC3971 says: Because authorization paths are not a common practice in the Internet at the time of this writing, the path MUST consist of standard Public Key Certificates (PKC, in the sense of [8]). -> But [8] points to Authorization certificate which does not have public key? 3. Isn't there Pad Length missing in the RSA Signature option? Section 5.2 says: Digital Signature This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the RSA Signature option minus the length of the other fields (including the variable length Pad field). Padding This variable-length field contains padding, as many bytes long as remain after the end of the signature. -> Isn't this circular? We need Pad Length, right? 4. Again, RFC3971 says: Section 6.3.1 says: The X.509 IP address extension MUST contain at least one addressesOrRanges element. This element MUST contain an addressPrefix element containing an IPv6 address prefix for a prefix that the router or the intermediate entity is authorized to route. ... Instead of an addressPrefix element, the addressesOrRange element MAY contain an addressRange element for a range of subnet prefixes, if more than one prefix is authorized. -> addressPrefix is first said to be MUST. And then, "instead of addressPrefix we may have.." Tnx for the answers, Cheers Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Sun Sep 7 23:43:49 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAA53A6AB8; Sun, 7 Sep 2008 23:43:49 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD703A6AB8 for ; Sun, 7 Sep 2008 23:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] 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 vPT5eejsdSOA for ; Sun, 7 Sep 2008 23:43:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 859653A69EA for ; Sun, 7 Sep 2008 23:43:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,356,1217808000"; d="scan'208";a="19995124" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Sep 2008 06:43:45 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m886hipa029868; Mon, 8 Sep 2008 02:43:44 -0400 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m886hdAF024661; Mon, 8 Sep 2008 06:43:44 GMT Received: from xmb-ams-335.cisco.com ([144.254.231.80]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 08:43:38 +0200 Received: from printer-nice-144-254-53-239.cisco.com ([144.254.53.239]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 08:43:38 +0200 From: Eric Levy-Abegnoli Organization: Cisco To: cga-ext@ietf.org Date: Mon, 8 Sep 2008 02:42:14 +0200 User-Agent: KMail/1.9.7 References: <48C44629.4030407@fer.hr> In-Reply-To: <48C44629.4030407@fer.hr> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809080242.14455.elevyabe@cisco.com> X-OriginalArrivalTime: 08 Sep 2008 06:43:38.0613 (UTC) FILETIME=[39911250:01C9117E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3750; t=1220856224; x=1221720224; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=elevyabe@cisco.com; z=From:=20Eric=20Levy-Abegnoli=20 |Subject:=20Re=3A=20[CGA-EXT]=20Questions=20about=20RFC3971 |Sender:=20 |To:=20cga-ext@ietf.org; bh=lwFhiqbFvSn3XmbJRnlueTQGy5uJbecozu5MVCsg2jg=; b=iHCABu954p3KOipHT9quh35GlCUuo27KV4xvIInTeG03joqge1BKaTsmxF X86/SkOG1zw51gYVJJRcmtJAiS1BbLkCaZ0EG9gd42jUEckhH6yy9Z0IFg+K d7QuAbiGze; Authentication-Results: rtp-dkim-2; header.From=elevyabe@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [CGA-EXT] Questions about RFC3971 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi Ana, see comments inline On Sunday 07 September 2008 23:22:49 Ana Kukec wrote: > Hi all, > > Here are some questions about the RFC3971, there are some illogical > paragraphs.. Answers are welcomed :-) > > 1. RFC3971 says about Router Solicitations: > Section 5.1.1: If the node has been configured to use SEND, the CGA > option MUST be present in all NS and Advertisement messages and MUST be > present in RS messages unless they are sent with the unspecified source > address. > Section 5.1.2: Note that the CGA option is not used when the source > address is the unspecified address. > Section 5.2.2: Router Solicitation messages wihout the RSA Signature > option MUST also be treated as unsecured, unless the source address of > the message is the unspecified address. > > -> Which means that message with unspecified address, without CGA and > signature must be treated as secured? I am aware that the router will > not update its Neighbor Cache in this situation. But anyway, why can > such message be treated as secured? What else could the receiver do? The semantic may be bogus, but RS with unspec is quite commonly the first message that a node will send, before acquiring an address. What "secure" means in that context is that the receiver must respond. Even when instructed to be in "full-secure" mode. And as you suggested, these messages don't create any state at the receiver. >From a "handling" standpoint, they are to be treated the same way as secured message, even if they are not. > > 2. RFC3971 says: > Because authorization paths are not a common practice > in the Internet at the time of this writing, the path MUST consist of > standard Public Key Certificates (PKC, in the sense of [8]). > > -> But [8] points to Authorization certificate which does not have > public key? I don't get it. Certificate used in SEND have a public key. As well as X.509 certifcate referred to in 3280. What beast are you talking about? > > 3. Isn't there Pad Length missing in the RSA Signature option? > Section 5.2 says: > Digital Signature > This field starts after the Key Hash field. The length of the > Digital Signature field is determined by the length of the RSA > Signature option minus the length of the other fields (including > the variable length Pad field). > Padding > This variable-length field contains padding, as many bytes long as > remain after the end of the signature. > > -> Isn't this circular? We need Pad Length, right? The length of Digital Signature can be inferred from the length of the key modulus (that you can get from the public key in the CGA option). > > 4. Again, RFC3971 says: > Section 6.3.1 says: > The X.509 IP address extension MUST contain at least one > addressesOrRanges element. This element MUST contain an > addressPrefix element containing an IPv6 address prefix for a prefix > that the router or the intermediate entity is authorized to route. > ... > Instead of an addressPrefix element, the addressesOrRange element MAY > contain an addressRange element for a range of subnet prefixes, if > more than one prefix is authorized. > > -> addressPrefix is first said to be MUST. And then, "instead of > addressPrefix we may have.." I don't see any ambiguity there. The way I read it is "It MUST be either A or B". How else would you interpret it? And don't know how to better put it ... Eric > > Tnx for the answers, > Cheers > Ana > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Sun Sep 7 23:56:24 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA6653A6B6E; Sun, 7 Sep 2008 23:56:24 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82B873A6943 for ; Sun, 7 Sep 2008 23:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 GIHB9pMxi2KZ for ; Sun, 7 Sep 2008 23:56:22 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 93EDF3A6803 for ; Sun, 7 Sep 2008 23:56:22 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K6V005W17A01Y@usaga01-in.huawei.com> for cga-ext@ietf.org; Sun, 07 Sep 2008 23:56:25 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K6V00MH779ZRZ@usaga01-in.huawei.com> for cga-ext@ietf.org; Sun, 07 Sep 2008 23:56:24 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Mon, 08 Sep 2008 14:56:08 +0800 Date: Mon, 08 Sep 2008 14:56:08 +0800 From: JiangSheng 66104 In-reply-to: <7692BBEB001A46029D5EAD2F73328F07@dcml.docomolabsusa.com> To: James Kempf Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <7692BBEB001A46029D5EAD2F73328F07@dcml.docomolabsusa.com> Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Docomo USL SEND Distribution X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi, James, We, IP Research of Huawei, have discussed to start an experimental implementation for a couple of months already. So far, we have not decided whether our implementation would based on Docomo's implementation or we will build up from zero. We have discussed this with CSI chairs and Jari. The point, so far, is a total new implementation may help to re-examine the protocol. It will help us to make the decision if you can tell up how much man power you have used in your open source SeND project. If we decide to use Docomo's implementation as our start point at the end, of course, we will let you know and "keep Docomo's name on the code that was developed at Docomo and to continue using the BSD license on that code." Best regards, Sheng ----- Original Message ----- From: James Kempf Date: Saturday, September 6, 2008 0:26 am Subject: [CGA-EXT] Docomo USL SEND Distribution To: cga-ext@ietf.org > Docomo Labs USA has been distributing an open source implementation > of SEND > for several years. Unfortunately, we no longer have anyone here who > is > maintaining the code and therefore in the near future we would like > to drop > distribution by removing the link from our Web page. The code is > licensed > under the BSD license and therefore anyone can continue to maintain > and > distribute it, including incorporating it into commercial products > (subject, > of course, to any IPR from other parties), with no further > obligation to > Docomo except to keep Docomo's name on the code that was developed > at Docomo > and to continue using the BSD license on that code. Is there anyone > who > would like to take over the code and continue maintaining it, > including > working on whatever extensions the CSI WG decides upon? If so, > please let me > know by the end of Sept. so we can vector any future questions on > the code > to you. If we can't find anybody that wants to take over the code, > we will > likely remove the link from our Web page sometime in the near > future, > archive the code, and shut down the distribution mailing list with > no > referral for future questions. > > Note that this does not mean that Docomo is no longer interested in > SEND. > SEND is an important part of the entire IPv6 security architecture, > and any > work in CGI that helps to extend last hop link security is > important for > future wireless networks. > > jak > > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext > _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Mon Sep 8 13:41:17 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF8B3A6971; Mon, 8 Sep 2008 13:41:17 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E8528C0DF for ; Mon, 8 Sep 2008 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.231 X-Spam-Level: X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=2.367, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 hG2Tfd0-D8Pb for ; Mon, 8 Sep 2008 13:41:15 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by core3.amsl.com (Postfix) with ESMTP id CFC363A687C for ; Mon, 8 Sep 2008 13:41:15 -0700 (PDT) Received: from dcl-ex.dcml.docomolabs-usa.com (viruswall.docomolabs-usa.com [172.21.96.230]) by fridge.docomolabs-usa.com (Postfix) with ESMTP id E6B821B841; Mon, 8 Sep 2008 13:41:16 -0700 (PDT) Received: from DCLKEMPF ([172.21.97.67]) by dcl-ex.dcml.docomolabs-usa.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 Sep 2008 13:41:16 -0700 Message-ID: <6E8C769B4B3E4C51A0FC9B65838273A1@dcml.docomolabsusa.com> From: "James Kempf" To: "JiangSheng 66104" References: <7692BBEB001A46029D5EAD2F73328F07@dcml.docomolabsusa.com> Date: Mon, 8 Sep 2008 13:41:16 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 08 Sep 2008 20:41:16.0428 (UTC) FILETIME=[3D8F0CC0:01C911F3] Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Docomo USL SEND Distribution X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Jiang, A totally new implementation, especially in if it is open source, would certainly be useful. I have a volunteer to continue working with Docomo's implementation. With two implementations tracking CSI, I think there should be an opportunity to get a good idea about any technical issues. Thanx for your interest. jak ----- Original Message ----- From: "JiangSheng 66104" To: "James Kempf" Cc: ; "Shuo Shen" Sent: Sunday, September 07, 2008 11:56 PM Subject: Re: [CGA-EXT] Docomo USL SEND Distribution > Hi, James, > > We, IP Research of Huawei, have discussed to start an experimental > implementation for a couple of months already. So far, we have not decided > whether our implementation would based on Docomo's implementation or we > will build up from zero. We have discussed this with CSI chairs and Jari. > The point, so far, is a total new implementation may help to re-examine > the protocol. > > It will help us to make the decision if you can tell up how much man power > you have used in your open source SeND project. > > If we decide to use Docomo's implementation as our start point at the end, > of course, we will let you know and "keep Docomo's name on the code that > was developed at Docomo and to continue using the BSD license on that > code." > > Best regards, > > Sheng > > ----- Original Message ----- > From: James Kempf > Date: Saturday, September 6, 2008 0:26 am > Subject: [CGA-EXT] Docomo USL SEND Distribution > To: cga-ext@ietf.org > >> Docomo Labs USA has been distributing an open source implementation >> of SEND >> for several years. Unfortunately, we no longer have anyone here who >> is >> maintaining the code and therefore in the near future we would like >> to drop >> distribution by removing the link from our Web page. The code is >> licensed >> under the BSD license and therefore anyone can continue to maintain >> and >> distribute it, including incorporating it into commercial products >> (subject, >> of course, to any IPR from other parties), with no further >> obligation to >> Docomo except to keep Docomo's name on the code that was developed >> at Docomo >> and to continue using the BSD license on that code. Is there anyone >> who >> would like to take over the code and continue maintaining it, >> including >> working on whatever extensions the CSI WG decides upon? If so, >> please let me >> know by the end of Sept. so we can vector any future questions on >> the code >> to you. If we can't find anybody that wants to take over the code, >> we will >> likely remove the link from our Web page sometime in the near >> future, >> archive the code, and shut down the distribution mailing list with >> no >> referral for future questions. >> >> Note that this does not mean that Docomo is no longer interested in >> SEND. >> SEND is an important part of the entire IPv6 security architecture, >> and any >> work in CGI that helps to extend last hop link security is >> important for >> future wireless networks. >> >> jak >> >> >> _______________________________________________ >> CGA-EXT mailing list >> CGA-EXT@ietf.org >> https://www.ietf.org/mailman/listinfo/cga-ext >> > _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Tue Sep 9 03:16:51 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE8928C176; Tue, 9 Sep 2008 03:16:51 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 400BB28C176 for ; Tue, 9 Sep 2008 03:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 uFyy5N697nbu for ; Tue, 9 Sep 2008 03:16:49 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id 0254628C107 for ; Tue, 9 Sep 2008 03:16:48 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m89AGcrp001465 for ; Tue, 9 Sep 2008 12:16:38 +0200 (CEST) Received: from [192.168.1.121] ([89.164.39.188]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 12:16:00 +0200 Message-ID: <48C64CDD.2000603@fer.hr> Date: Tue, 09 Sep 2008 12:15:57 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <48C44629.4030407@fer.hr> <200809080242.14455.elevyabe@cisco.com> In-Reply-To: <200809080242.14455.elevyabe@cisco.com> X-OriginalArrivalTime: 09 Sep 2008 10:16:00.0252 (UTC) FILETIME=[0E96A3C0:01C91265] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] Questions about RFC3971 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Oh, i see. Thank you very much for the comments Eric. Regards, Ana Eric Levy-Abegnoli wrote: > Hi Ana, > see comments inline > On Sunday 07 September 2008 23:22:49 Ana Kukec wrote: > >> Hi all, >> >> Here are some questions about the RFC3971, there are some illogical >> paragraphs.. Answers are welcomed :-) >> >> 1. RFC3971 says about Router Solicitations: >> Section 5.1.1: If the node has been configured to use SEND, the CGA >> option MUST be present in all NS and Advertisement messages and MUST be >> present in RS messages unless they are sent with the unspecified source >> address. >> Section 5.1.2: Note that the CGA option is not used when the source >> address is the unspecified address. >> Section 5.2.2: Router Solicitation messages wihout the RSA Signature >> option MUST also be treated as unsecured, unless the source address of >> the message is the unspecified address. >> >> -> Which means that message with unspecified address, without CGA and >> signature must be treated as secured? I am aware that the router will >> not update its Neighbor Cache in this situation. But anyway, why can >> such message be treated as secured? >> > What else could the receiver do? The semantic may be bogus, but RS with unspec > is quite commonly the first message that a node will send, before acquiring > an address. What "secure" means in that context is that the receiver must > respond. Even when instructed to be in "full-secure" mode. > And as you suggested, these messages don't create any state at the receiver. > From a "handling" standpoint, they are to be treated the same way as secured > message, even if they are not. > >> 2. RFC3971 says: >> Because authorization paths are not a common practice >> in the Internet at the time of this writing, the path MUST consist of >> standard Public Key Certificates (PKC, in the sense of [8]). >> >> -> But [8] points to Authorization certificate which does not have >> public key? >> > I don't get it. Certificate used in SEND have a public key. As well as X.509 > certifcate referred to in 3280. What beast are you talking about? > > >> 3. Isn't there Pad Length missing in the RSA Signature option? >> Section 5.2 says: >> Digital Signature >> This field starts after the Key Hash field. The length of the >> Digital Signature field is determined by the length of the RSA >> Signature option minus the length of the other fields (including >> the variable length Pad field). >> Padding >> This variable-length field contains padding, as many bytes long as >> remain after the end of the signature. >> >> -> Isn't this circular? We need Pad Length, right? >> > The length of Digital Signature can be inferred from the length > of the key modulus (that you can get from the public key in the CGA option). > > >> 4. Again, RFC3971 says: >> Section 6.3.1 says: >> The X.509 IP address extension MUST contain at least one >> addressesOrRanges element. This element MUST contain an >> addressPrefix element containing an IPv6 address prefix for a prefix >> that the router or the intermediate entity is authorized to route. >> ... >> Instead of an addressPrefix element, the addressesOrRange element MAY >> contain an addressRange element for a range of subnet prefixes, if >> more than one prefix is authorized. >> >> -> addressPrefix is first said to be MUST. And then, "instead of >> addressPrefix we may have.." >> > I don't see any ambiguity there. The way I read it is "It MUST be either A or > B". How else would you interpret it? And don't know how to better put it ... > Eric > > >> Tnx for the answers, >> Cheers >> Ana >> _______________________________________________ >> CGA-EXT mailing list >> CGA-EXT@ietf.org >> https://www.ietf.org/mailman/listinfo/cga-ext >> > > > > _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Tue Sep 9 13:34:10 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CAD28C213; Tue, 9 Sep 2008 13:34:10 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A3228C213 for ; Tue, 9 Sep 2008 13:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.952 X-Spam-Level: X-Spam-Status: No, score=0.952 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 X3HT0kPrv3pR for ; Tue, 9 Sep 2008 13:34:08 -0700 (PDT) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by core3.amsl.com (Postfix) with ESMTP id 111FC28C1F8 for ; Tue, 9 Sep 2008 13:34:07 -0700 (PDT) Received: from dcl-ex.dcml.docomolabs-usa.com (viruswall.docomolabs-usa.com [172.21.96.230]) by fridge.docomolabs-usa.com (Postfix) with ESMTP id C298F1B84D for ; Tue, 9 Sep 2008 13:34:10 -0700 (PDT) Received: from DCLKEMPF ([172.21.97.67]) by dcl-ex.dcml.docomolabs-usa.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Sep 2008 13:34:09 -0700 Message-ID: From: "James Kempf" To: Date: Tue, 9 Sep 2008 13:34:09 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-OriginalArrivalTime: 09 Sep 2008 20:34:09.0893 (UTC) FILETIME=[69BCB950:01C912BB] Subject: [CGA-EXT] Home for Docomo SEND Found X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Suresh Krishnan (suresh_send_impl@sureshk.com) has agreed to take over the Docomo SEND implementation and continue working with it. Jean-Michel Combes also has a group of people working on SEND called MobiSEND. They've patched it to run on recent Debian versions and are working on a Web site where people can download the patched version. They are also working on a new implementation and will no longer by updating Docomo SEND due to its limitations. Suresh and Jean-Michel will work together to ensure that the Debian patches are propagated forward into Suresh's work. So, any further requests for information or bug fixes should be directed to Suresh. Starting around Sept. 26, the Docomo SEND distribution will be removed from the Docomo USL Web site. Thanx to Suresh for volunteering to contribute his time to the IETF community! jak _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Tue Sep 9 16:26:38 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF21628C1D1; Tue, 9 Sep 2008 16:26:38 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD38428C1D8 for ; Tue, 9 Sep 2008 16:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.867, 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 k2huDA6UhlJT for ; Tue, 9 Sep 2008 16:26:37 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id DCBCC28C131 for ; Tue, 9 Sep 2008 16:26:36 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m89NRDej015990 for ; Wed, 10 Sep 2008 01:27:14 +0200 (CEST) Received: from [192.168.1.121] ([89.164.39.188]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 01:25:14 +0200 Message-ID: <48C705D7.2000000@fer.hr> Date: Wed, 10 Sep 2008 01:25:11 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: cga-ext@ietf.org References: <48C294A4.8050508@fer.hr> In-Reply-To: <48C294A4.8050508@fer.hr> X-OriginalArrivalTime: 09 Sep 2008 23:25:14.0434 (UTC) FILETIME=[4FE16220:01C912D3] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Subject: Re: [CGA-EXT] hash function agility support in draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi all, Just to summarize the possible options about encoding hash algorithm: a) Use the same hash algorithm as in CGA for all hashes. There is no bidding down attack in that case. Different algorithms then CGA algorithm for other hashes does not increase security. b) Use the Hash Algorithm option to define different (or the same?) algorithm for all hashes. It is vulnerable to the bidding down attack, but provides flexibility, since in the future, SeND might be used without CGAs. Any opinions? :-) Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Tue Sep 9 17:52:38 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE4A528C20D; Tue, 9 Sep 2008 17:52:37 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2061A28C0E2 for ; Tue, 9 Sep 2008 17:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 ITDI89-X50MJ for ; Tue, 9 Sep 2008 17:52:36 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id AE0E328C1F7 for ; Tue, 9 Sep 2008 17:52:35 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (46-217.static.dedicado.com.uy [200.108.217.46])by smtp02.uc3m.es (Postfix) with ESMTP id CF9BD583825;Wed, 10 Sep 2008 02:52:35 +0200 (CEST) Message-ID: <48C71A4C.9020604@it.uc3m.es> Date: Wed, 10 Sep 2008 02:52:28 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ana Kukec References: <48C294A4.8050508@fer.hr> In-Reply-To: <48C294A4.8050508@fer.hr> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-16.2081 TC:1F TRN:58 TV:5.5.1026(16148.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] hash function agility support indraft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi Ana, thanks for starting the disucssion on this. see comments in-line Ana Kukec escribi=F3: > Hi all, > > We didn't reach the consensus about how to support hash function = > agility. We should try to reach the consensus, thus, i am sending the = > summary of analysis, possible solutions for encoding the hash functions, = > pros and cons. > > The uses of hashes are the following: > a) Digital signature in X.509 certificate. Attacker can produce the = > false certificate with the same identity data and signature, and = > different key. After that, he does not have to break any other hash = > (CGA, key hash field, digital signature), just uses that new, = > unauthorized key in the generation of mentioned fields. > = right, but this is not send specific, since it affects X.509 certs in = general. I don't think we should aim to solve this here imho we should use it as baseline to compare whatever solution we come = up with > b) CGAs. The same as with certificate, it is enough just to break the = > CGA, and use the false key in key hash field generation and for digital = > signature signing. > = same here CGA hash agility has already been addressed in a separate document, so i = don't see the need to deal with it here as well With the defined CGA hash agility should be enough to deal with it, right? > c) Key hash field. Again the same thing. Attacker breaks the key hash = > and does not have to break any other hash, cause he just uses the new = > key for other fields generation. > = i think this is the key issue to address here. This is seND specific and = this is what we should aim to solve > d) Digital signature. Attacker could change some of the SeND message = > fields. However the attack is probably just theoretically possible; in = > practice it is hard to perform it since there are mostly human-readable = > fields to be signed. Attacker does not need to break any other hash, the = > hashed message can be signed with authorized key (if attacker manages to = > change the message before the SeND node starts signing it). > > = i am not sure about this one > The question is, do we need to provide opportunity to choose different = > hash algorithms? If attacker attacks just one hash, he breaks the whole = > chain. Thus, it is enough to define just one hash algorithm in the Hash = > Algorithm option. > > = but the problem is that we may end up conditioning other operations I mean, CGAs are used for several things, not only send, so we may not = want to impose changing all the different protocols in chain. In = addition, there are many parties involved, Certs are generated by the CA = and CGAs are generated by the host itself, so it may not be a good idea = to require that both are upgraded simultaneously I am not sure what would be the right way to go here Regards, marcelo > On the other hand, the possibility for configuring multiple hashes = > provides additional flexibility. Additionally, we could support it = > because of the possible future changes in SeND. > > What are your opinions? > > Ana > > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext > > = _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Tue Sep 9 18:00:55 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1163A6C8B; Tue, 9 Sep 2008 18:00:55 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDE428C1C9 for ; Tue, 9 Sep 2008 18:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.762 X-Spam-Level: X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 N+xC7I+zTzIW for ; Tue, 9 Sep 2008 18:00:53 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 78CC63A6C8B for ; Tue, 9 Sep 2008 18:00:53 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (46-217.static.dedicado.com.uy [200.108.217.46])by smtp01.uc3m.es (Postfix) with ESMTP id 534B19EBC56;Wed, 10 Sep 2008 03:00:55 +0200 (CEST) Message-ID: <48C71C44.7030608@it.uc3m.es> Date: Wed, 10 Sep 2008 03:00:52 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ana Kukec References: <48C294A4.8050508@fer.hr> <48C705D7.2000000@fer.hr> In-Reply-To: <48C705D7.2000000@fer.hr> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-21.2459 TC:1F TRN:31 TV:5.5.1026(16148.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] hash function agility supportin draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Ana Kukec escribi=F3: > Hi all, > > Just to summarize the possible options about encoding hash algorithm: > = right thanks > a) Use the same hash algorithm as in CGA for all hashes. There is no = > bidding down attack in that case. Different algorithms then CGA = > algorithm for other hashes does not increase security. > = right actually, as someone suggested in the meeting, it is also possible to = encode the hash function in the last 3 bits of the address, = irrespectivly the address is a CGA or not > b) Use the Hash Algorithm option to define different (or the same?) = > algorithm for all hashes. It is vulnerable to the bidding down attack, = > but provides flexibility, since in the future, SeND might be used = > without CGAs. > > = well, the scope of bidding down attacks in this case could be limited by = admin configuration. I mean, if it is determined that a given hash = function is insecure, then hosts simply don't accept the hash algorithm = any more and no bidding down attack is possible The problem is when two hash algorithms with different level of security = must be accepted simultaneously, so during that period, the attack will = be possible regards, marcelo > Any opinions? :-) > > Ana > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext > > = _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 10 02:57:39 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A40D28C1F3; Wed, 10 Sep 2008 02:57:39 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B97728C1F3 for ; Wed, 10 Sep 2008 02:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 m97ZSAQn1co1 for ; Wed, 10 Sep 2008 02:57:37 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id 61A1028C146 for ; Wed, 10 Sep 2008 02:57:37 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m8A9wEUs017344 for ; Wed, 10 Sep 2008 11:58:15 +0200 (CEST) Received: from [192.168.1.121] ([89.164.39.188]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 11:57:36 +0200 Message-ID: <48C79A0E.9040004@fer.hr> Date: Wed, 10 Sep 2008 11:57:34 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: marcelo bagnulo braun References: <48C294A4.8050508@fer.hr> <48C71A4C.9020604@it.uc3m.es> In-Reply-To: <48C71A4C.9020604@it.uc3m.es> X-OriginalArrivalTime: 10 Sep 2008 09:57:37.0061 (UTC) FILETIME=[A772CD50:01C9132B] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] hash function agility support indraft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hey Marcelo, I agree with what you said about certificates and CGAs. For the Key Hash and Digital Signature, please see my questions below. marcelo bagnulo braun wrote: >> c) Key hash field. Again the same thing. Attacker breaks the key hash >> and does not have to break any other hash, cause he just uses the new >> key for other fields generation. > i think this is the key issue to address here. This is seND specific > and this is what we should aim to solve Right, this is SeND specific, but i see the Digital Signature field as a bigger issue then this field. The Key Hash field is not susceptible to the collision attacks, since attacker chooses both keys, right? Preimage attacks could be more useful, but are not feasible. But even in that case, if an attacker breaks key hash and produces signature with the new key, there is still CGA to deal with. Right? > >> d) Digital signature. Attacker could change some of the SeND message >> fields. However the attack is probably just theoretically possible; >> in practice it is hard to perform it since there are mostly >> human-readable fields to be signed. Attacker does not need to break >> any other hash, the hashed message can be signed with authorized key >> (if attacker manages to change the message before the SeND node >> starts signing it). >> >> > i am not sure about this one Why? AFAIU, the Digital Signature field is vulnerable to the collision attack. An attacker produces two colliding messages, underlays one of the messages to be signed with authorized keys (through CGAs), but uses another message afterwards. However, the prediction and production of the useful content of such two messages is just theoretically possible, since SeND message contains mostly human readable data. And as rfc4270 says, the structure of at least one of two messages is predefined. What am i missing here? >> The question is, do we need to provide opportunity to choose >> different hash algorithms? If attacker attacks just one hash, he >> breaks the whole chain. Thus, it is enough to define just one hash >> algorithm in the Hash Algorithm option. >> >> > but the problem is that we may end up conditioning other operations > I mean, CGAs are used for several things, not only send, so we may not > want to impose changing all the different protocols in chain. In > addition, there are many parties involved, Certs are generated by the > CA and CGAs are generated by the host itself, so it may not be a good > idea to require that both are upgraded simultaneously > Right, that is about flexibility, we should not expect from CA and host to use the same algorithm. It might be useful to give opportunity to define separate algorithm for certs, and use CGA algorithm for other hashes. CGAs are used for different purposes, but CGA hash threat analysis and hash agility is provided by the rfc4982, we should not bother with that, right? Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 10 08:36:41 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 250DD3A6D99; Wed, 10 Sep 2008 08:36:41 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1E93A6D98 for ; Wed, 10 Sep 2008 08:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 IjtrnfyvtoD2 for ; Wed, 10 Sep 2008 08:36:36 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6B4D128C285 for ; Wed, 10 Sep 2008 08:36:36 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K6Z003JKKP5CW@usaga01-in.huawei.com> for cga-ext@ietf.org; Wed, 10 Sep 2008 08:36:41 -0700 (PDT) Received: from huawei.com ([172.17.1.36]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K6Z00CUVKP3W5@usaga01-in.huawei.com> for cga-ext@ietf.org; Wed, 10 Sep 2008 08:36:41 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [212.147.29.179]) by szxmc04-in.huawei.com (mshttpd); Wed, 10 Sep 2008 23:36:23 +0800 Date: Wed, 10 Sep 2008 23:36:23 +0800 From: JiangSheng 66104 In-reply-to: <48C71C44.7030608@it.uc3m.es> To: marcelo bagnulo braun Message-id: MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006) Content-language: en Content-disposition: inline X-Accept-Language: en Priority: normal References: <48C294A4.8050508@fer.hr> <48C705D7.2000000@fer.hr> <48C71C44.7030608@it.uc3m.es> Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] hash function agility supportin draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org See my reply in lines. Sheng ----- Original Message ----- From: marcelo bagnulo braun Date: Wednesday, September 10, 2008 9:00 am Subject: Re: [CGA-EXT] hash function agility supportin draft-kukec-csi-hash= -threat-02 To: Ana Kukec Cc: cga-ext@ietf.org > Ana Kukec escribi=F3: > > Hi all, > > > > Just to summarize the possible options about encoding hash = > algorithm:> = > right thanks > = > > a) Use the same hash algorithm as in CGA for all hashes. There is = > no = > > bidding down attack in that case. Different algorithms then CGA = > > algorithm for other hashes does not increase security. > > = > = > right > actually, as someone suggested in the meeting, it is also possible = > to = > encode the hash function in the last 3 bits of the address, = > irrespectivly the address is a CGA or not I am support to use the same hash algorithm while don't want to rule out th= e necessariness of a new hash algorithm option. There are some scenarios th= at CGA option is not necessary and SEND Signature is needed. For example, a= ccording to RFC3971, "Router Advertisement, and Redirect messages MUST cont= ain the RSA Signature option", but CGA option is not mandate. In these case= s, since no CGA hash algorithm be described, we do need a SeND option to de= scribe the hash algorithm in SeND. = > > b) Use the Hash Algorithm option to define different (or the = > same?) = > > algorithm for all hashes. It is vulnerable to the bidding down = > attack, = > > but provides flexibility, since in the future, SeND might be used = > > without CGAs. > > > > = > well, the scope of bidding down attacks in this case could be = > limited by = > admin configuration. I mean, if it is determined that a given hash = > function is insecure, then hosts simply don't accept the hash = > algorithm = > any more and no bidding down attack is possible > = > The problem is when two hash algorithms with different level of = > security = > must be accepted simultaneously, so during that period, the attack = > will = > be possible > = > regards, marcelo > = > = > = > > Any opinions? :-) > > > > Ana > > _______________________________________________ > > CGA-EXT mailing list > > CGA-EXT@ietf.org > > https://www.ietf.org/mailman/listinfo/cga-ext > > > > = > = > _______________________________________________ > CGA-EXT mailing list > CGA-EXT@ietf.org > https://www.ietf.org/mailman/listinfo/cga-ext > = _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Wed Sep 17 08:57:33 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B588228C2CE; Wed, 17 Sep 2008 08:57:33 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AAA28C2CE for ; Wed, 17 Sep 2008 08:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 d03BtZQ4WIWv for ; Wed, 17 Sep 2008 08:57:27 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 04C6528C2CA for ; Wed, 17 Sep 2008 08:57:26 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-140-234.dialup.adsl.anteldata.net.uy [190.135.140.234])by smtp01.uc3m.es (Postfix) with ESMTP id DF40DA1F2DC;Wed, 17 Sep 2008 17:57:34 +0200 (CEST) Message-ID: <48D128EA.3060503@it.uc3m.es> Date: Wed, 17 Sep 2008 17:57:30 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: cga-ext@ietf.org, Ana Kukec , Suresh Krishnan , JiangSheng 66104 X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.6558 TC:1F TRN:80 TV:5.5.1026(16164.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Subject: [CGA-EXT] about draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi, I have read the draft and i have the following comments: First overall comment, i understand that the analysis of the attacks affecting the hash functions are only about collision attacks, right? I mean, we don't make the analysis of what could happen if other attacks affecting other properties of the hash fucntion were possible, right? However, in the section about the recommendation, i understand the analysis is broader and we do perform an analysis about what type of attacks woudl be possible to the new extension if the has function was completely broken, right? In section 3.2. Attacks against PKIX certificates in ADD process it reads Additionally, since identity field is humane readable data, certificates are not affected by collision attacks in practice. I don't understand this sentence, could you expand? Implementations SHOULD use human-readable certificate extensions only if SeND certificate profile demands. I don't understand this recommendation, could you expand? In the same section, it first states: In 2005 they succeeded to construct the original and the false certificate that had the same identity data and digital signature, but different public keys [new-hashes]. and then it states* * In 2007 were demonstrated certificates with the same identity data and signatures, which differed only in public keys. I don't understnad the difference between the attack in 2005 and the one in 2007, could you explain that? From the text that follows, that reads: Such attacks are potentially more dangerous, since attacker can decide about contents of human readable fields, and produce for example certificates with the same signatures, but different identities or validity periods. It seems to me that the description of the attack of 2007 is wrong, since the two certificates not only differ in the public keys. However, if that is the case, i don't understnad why the attack in 2007 is worse than the one in 2005. I mean, if you can generate two certs that only differen in the pk, then you can generate any two certificates that differ in whatever you want, since the most restricitve situation is when you can only change the pk afaiu. I find the section on the analysis on the certificates a bit inconclusive. I mean, you describe a set of attacks, which all of them are about to create two certs with more or less similar data and with different pk. Do these attacks have some implications in send? How would an attacker launch an attack to send using that? My understnading is that no new attack against send is possible because of that. I mean, this basically affects non repudiation and send does not provides or uses non repudiation features afaict. So, i would like to suggest to try to understand if these attacks against certificates have some implication in send security and if there are new attacks that can be launched against send and include that in the document. In section 3.3. Attacks against Digital Signature in RSA Signature option it reads However, the problem for the attacker is that they are very hard to predict the useful input data. why is that? It minimizes the possibility for a real-world collision attack what minimizes the possibility? please rephrase and the fact that in order to perform a succesful real-world attack he can not change a human-readable data. how is that? SeND is exectued without human intervention, so i am not sure this argument applies (in addition, rephrase this cause it is hard to understand, in particular, it is hard to follow the linking with the previous sentence) But we also have to take into account that a variant of SHA-1 was already affected by recent collision attacks and we have to prepare for future improved attacks. This seems that was left unfinished Again, this section seems inconlcusive to me. suppose that an attacker could actually do what you describe, what would be the actual impact of the attack? I mean, would it be able to affect send in some way? Again, i think not, cause send does not relies in non repudiation afaict I think additional text is needed to describe the impact on the send protocol of the described attack In section 3.4. Attacks against Key Hash in RSA Signature option a non human-readable data. But the problem for the attacker is that a public key, which is input data is authorized through CGAs, and sometimes additionally through a certification path if peer has configured trust anchor. For the succesful attack, attacker has to break both SHA-1 hashed public key, as well as corresponding CGA and possibly a certification path. Otherwise, changed key pair will be detected in the process of CGA verification. But if i manage to generate the hash colision, i will probably want to use a different pk, one that i have the private key for, right? So, i am not sure you also need to break the pk in order to lauch some attack here Again, i think the section is inconclusive, Again, i think the collision attack affect non repudiation so i would like to have an analysis of non repudiation in send and see if it is possible to launch an attack that affect send. If not i would like to have some conclusion about this Later on in 4. Support for the hash agility in SeND While all of analyzed hash functions in SeND are theoretically affected by recent collision attacks, these attacks indicate the possibility of future real-world attacks. please rephrase, it is not clear to me what you mean besides, i don't think the attacks actually affect send, since they only affect non repudiation afaict and send does not relies on non repudiation afaict later on it reads: We could decide to use by default the same hash function in SeND as in CGA, but this solution is architecturally strange and it does not really increase the security since the difficulty for attackers remain to break one single hash function. Furthermore, it may even reduce the security level by providing more relevant information of the hash function. On the other side, the use of two different hash algorithms makes attacker's life harder. I am not sure i follow the line of reasoning here If a hash function can be attacks, it is bad to use it, in one or in two palces, is still the same casue it is broken. So if you are using the same function in the two places you are in a very bad shape indeed. But if you are using it in only one place, you are worse than if you are not using it at all, so i don't see how the above point applies I would simply suggest to remove the last sentence later on... Another solution is to incorporate the hash function option into SeND message. By putting a new hash function option in SeND message before RSA Signature option, attacker will have to break both the signature and the hash input at the same time since the new option will be input field for the Digital Signature in RSA Signature option. However, we can not avoid a downgrade attack totally because peer might be using just ND and not SeND. i don't follow that A downgrade attack would be performed in a different way imho AFAIU, a downgrading attack would be performed by the attacker changing the hash function to an weaker hash fucntion that it can crack and then simply changing the content of the message. the downgrading attack is not possible because some nodes use just ND but because you are using the hash function to sign the hash function that you are using, so breaking the hash function allows you to break the signature for it, so you can change the hash fucntion you are claiming to use. Question, wouldn't it be possible to modifiy the signature, so that the hash algorithm field is not signed using a hash function at all? i.e. is directly encrypted wihtout performing a hash before so, that in order to change the hash funtion field you need to break the pk encryption but not the hash algorithm? (not sure if you are following what i am saying here, but i think it may be possible) regards, marcelo A completely safe solution here does not exist. A new hash function option in SeND message is a reasonable and the best solution for the hash algorithm agility support in SeND. Each implementation SHOULD use different hash or signature algorithms for each of the relevant fields (Key Hash field, Digital Signature, PKIX signature algorithm). Since all algorithms are in different procedures, making them the same does not make those procedures simpler, but making them different complicates possible attacks. _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Fri Sep 19 10:15:54 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8CB3A6B5F; Fri, 19 Sep 2008 10:15:54 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A24D3A6B5F for ; Fri, 19 Sep 2008 10:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.520, 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 nfr4fh2ClgQX for ; Fri, 19 Sep 2008 10:15:47 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id A4AF23A6987 for ; Fri, 19 Sep 2008 10:15:46 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m8JHG6pt006822 for ; Fri, 19 Sep 2008 19:16:08 +0200 (CEST) Received: from [192.168.1.121] ([89.164.5.16]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 19:15:28 +0200 Message-ID: <48D3DE2F.4090607@fer.hr> Date: Fri, 19 Sep 2008 19:15:27 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: marcelo bagnulo braun References: <48D128EA.3060503@it.uc3m.es> In-Reply-To: <48D128EA.3060503@it.uc3m.es> X-OriginalArrivalTime: 19 Sep 2008 17:15:28.0558 (UTC) FILETIME=[5032DCE0:01C91A7B] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] about draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hey Marcelo, There is a new version of draft (draft-ietf-csi-hash-threat-00), most paragraphs are changed compared to draft-kukec-csi-hash-threat-02. Below are the comments for those parts of text which did not change. I think other questions are, at least partly, answered in the new parts of text. Thank you for the comments, and please see my comments below, and in the new version of draft. marcelo bagnulo braun wrote: > > First overall comment, i understand that the analysis of the attacks > affecting the hash functions are only about collision attacks, right? > I mean, we don't make the analysis of what could happen if other > attacks affecting other properties of the hash fucntion were possible, > right? Right. > > However, in the section about the recommendation, i understand the > analysis is broader and we do perform an analysis about what type of > attacks woudl be possible to the new extension if the has function was > completely broken, right? Right. Scenarios in which the hash is completely broken are also described, but just for the comparation purposes. That is something what we were talking in Philadelphia -- do we have to solve all the attacks or just the attacks which are up to date possible in practice. We decided to mention in the draft all the attacks (including just theoretically possible ones), but to solve just practically possible attacks. > > In section 3.2. Attacks against PKIX certificates in ADD process it reads > > Additionally, since identity field > is humane readable data, certificates are not affected by collision > attacks in practice. > > I don't understand this sentence, could you expand? Is something like this better..? "Attacks against the human-readable fields demand much more effort than the attacks against non human-readable fields, such as a public key field. In case of the identity field, an attacker is faced with the problem of the prediction and the generation of the false but meaningful identity data, which at the end might be revealed by the Certification Authority. Thus, in practice, collision attacks do not affect non human-readable parts of the certificate." > > Implementations SHOULD use human-readable > certificate extensions only if SeND certificate profile demands. > > > I don't understand this recommendation, could you expand? It should be something like this: "Implementations MUST use human-readable certificate extensions in accordance with [draft-krishnan-cert-eku..]." > > In the same section, it first states: > > In 2005 they succeeded to construct the original and the false > certificate that had the same identity data and digital signature, > but different public keys [new-hashes]. > > and then it states* > * > In 2007 were demonstrated certificates with the same identity data > and signatures, which differed only in public keys. > > I don't understnad the difference between the attack in 2005 and the > one in 2007, could you explain that? Oh, typo. In 2005 - the same distinguished names, while in 2007 - different distinguished names. > From the text that follows, that reads: > Such attacks are > potentially more dangerous, since attacker can decide about contents > of human readable fields, and produce for example certificates with > the same signatures, but different identities or validity periods. > > It seems to me that the description of the attack of 2007 is wrong, > since the two certificates not only differ in the public keys. > However, if that is the case, i don't understnad why the attack in > 2007 is worse than the one in 2005. I mean, if you can generate two > certs that only differen in the pk, then you can generate any two > certificates that differ in whatever you want, since the most > restricitve situation is when you can only change the pk afaiu. I am not sure i understand the last sentence. 2005 certificates differ only in public keys. The resulting hash value in 2005 attack is a random string. The only X.509 cert field in which such random string can be placed is pk. You can not generate any two certs that differ in whatever you want. And if you have two certificates that differ only in pk, i don't see what could you do with them. Those certificates has the same identities, the same validity periods, everything. The only thing you can do is to blame Certification Authority for the issuance of two certificates with different keys. In 2007 the Intermediate Hash Value is extended in the way that it can be placed in the X.509 human-readable field. So, you can claim you are someone else, you could change validities, etc. Which is potentially more dangerous, right? > > I find the section on the analysis on the certificates a bit > inconclusive. I mean, you describe a set of attacks, which all of them > are about to create two certs with more or less similar data and with > different pk. Do these attacks have some implications in send? How > would an attacker launch an attack to send using that? > My understnading is that no new attack against send is possible > because of that. I mean, this basically affects non repudiation and > send does not provides or uses non repudiation features afaict. > > So, i would like to suggest to try to understand if these attacks > against certificates have some implication in send security and if > there are new attacks that can be launched against send and include > that in the document. IMO, the attacks which affect just pk do not have implications in send. But, attacks which affect human-readable data have implications in send. For example, the changed set of IP prefixes in the rfc3779 IP address extension, changed validity period. Up to date, no such attack has been demonstrated, but 2007 attack against identity field is on the way to such attacks. > > and the fact that in > order to perform a succesful real-world attack he can not change a > human-readable data. > > how is that? SeND is exectued without human intervention, so i am not > sure this argument applies > (in addition, rephrase this cause it is hard to understand, in > particular, it is hard to follow the linking with the previous sentence) My understanding is that, taking into account demonstrated collision attacks, it is hard to generate two useful, meaningful human-readable fields. Because, in the recent collision attacks, at least on of two messages has predefined shape, as described in section 2.1, rfc4270. > > Question, wouldn't it be possible to modifiy the signature, so that > the hash algorithm field is not signed using a hash function at all? > i.e. is directly encrypted wihtout performing a hash before so, that > in order to change the hash funtion field you need to break the pk > encryption but not the hash algorithm? > > (not sure if you are following what i am saying here, but i think it > may be possible) > Yes, i think it may be possible, with both the hash algorithm field, and the digital signature field. Should we analyze this case? Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Fri Sep 19 13:22:30 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF653A685A; Fri, 19 Sep 2008 13:22:30 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03A573A685A for ; Fri, 19 Sep 2008 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.939 X-Spam-Level: X-Spam-Status: No, score=-2.939 tagged_above=-999 required=5 tests=[AWL=0.823, BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4] 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 y+tR5e4b32gv for ; Fri, 19 Sep 2008 13:22:28 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 512773A67D8 for ; Fri, 19 Sep 2008 13:22:27 -0700 (PDT) Received: from marcelo-bagnulos-macbook-pro.local (r190-135-128-142.dialup.adsl.anteldata.net.uy [190.135.128.142])by smtp03.uc3m.es (Postfix) with ESMTP id 719DA646EF1;Fri, 19 Sep 2008 22:22:38 +0200 (CEST) Message-ID: <48D40A0C.2070707@it.uc3m.es> Date: Fri, 19 Sep 2008 22:22:36 +0200 From: marcelo bagnulo braun User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: Ana Kukec References: <48D128EA.3060503@it.uc3m.es> <48D3DE2F.4090607@fer.hr> In-Reply-To: <48D3DE2F.4090607@fer.hr> X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-31.8700 TC:1F TRN:74 TV:5.5.1026(16168.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] about draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org Hi Ana, Ana Kukec escribi=F3: > Hey Marcelo, > > There is a new version of draft (draft-ietf-csi-hash-threat-00), most = > paragraphs are changed compared to draft-kukec-csi-hash-threat-02. = oops, i guess i need to read that one next > Below are the comments for those parts of text which did not change. I = > think other questions are, at least partly, answered in the new parts = > of text. > ok, thanks > Thank you for the comments, and please see my comments below, and in = > the new version of draft. > > marcelo bagnulo braun wrote: >> >> First overall comment, i understand that the analysis of the attacks = >> affecting the hash functions are only about collision attacks, right? = >> I mean, we don't make the analysis of what could happen if other = >> attacks affecting other properties of the hash fucntion were = >> possible, right? > Right. >> >> However, in the section about the recommendation, i understand the = >> analysis is broader and we do perform an analysis about what type of = >> attacks woudl be possible to the new extension if the has function = >> was completely broken, right? > > Right. Scenarios in which the hash is completely broken are also = > described, but just for the comparation purposes. That is something = > what we were talking in Philadelphia -- do we have to solve all the = > attacks or just the attacks which are up to date possible in practice. = > We decided to mention in the draft all the attacks (including just = > theoretically possible ones), but to solve just practically possible = > attacks. > I still don't understand the analysis you have made is basically about collision attacks However, when we consider how to encode the hash function in send, we = also consider the attacks against other properties of the hash function, = in particular to the preimage attacks. I mean, bidding down attacks = being considered are not about collision free, but about the preimage = attacks afacit, right? >> >> In section 3.2. Attacks against PKIX certificates in ADD process it = >> reads >> >> Additionally, since identity field >> is humane readable data, certificates are not affected by collision >> attacks in practice. >> >> I don't understand this sentence, could you expand? > Is something like this better..? > "Attacks against the human-readable fields demand much more effort = > than the attacks against non human-readable fields, such as a public = > key field. In case of the identity field, an attacker is faced with = > the problem of the prediction and the generation of the false but = > meaningful identity data, which at the end might be revealed by the = > Certification Authority. Thus, in practice, collision attacks do not = > affect non human-readable parts of the certificate." much clearer > >> >> Implementations SHOULD use human-readable >> certificate extensions only if SeND certificate profile demands. >> >> >> I don't understand this recommendation, could you expand? > It should be something like this: "Implementations MUST use = > human-readable certificate extensions in accordance with = > [draft-krishnan-cert-eku..]." > So basically what you are saying is that the it is better to use only = human readable fields because they are harder to attack. A couple of comments. First, as i understand it, send certificates are never exposed to the = users, so, i am not sure who would verify that the fields are indeed = human readable. Second, i am not sure that this spec is a standard specification, so i = am not sure that normative lenguage is to be used in the document >> >> In the same section, it first states: >> >> In 2005 they succeeded to construct the original and the false >> certificate that had the same identity data and digital signature, >> but different public keys [new-hashes]. >> >> and then it states* >> * >> In 2007 were demonstrated certificates with the same identity data >> and signatures, which differed only in public keys. >> >> I don't understnad the difference between the attack in 2005 and the = >> one in 2007, could you explain that? > > Oh, typo. In 2005 - the same distinguished names, while in 2007 - = > different distinguished names. > > >> From the text that follows, that reads: >> Such attacks are >> potentially more dangerous, since attacker can decide about contents >> of human readable fields, and produce for example certificates with >> the same signatures, but different identities or validity periods. >> >> It seems to me that the description of the attack of 2007 is wrong, = >> since the two certificates not only differ in the public keys. = >> However, if that is the case, i don't understnad why the attack in = >> 2007 is worse than the one in 2005. I mean, if you can generate two = >> certs that only differen in the pk, then you can generate any two = >> certificates that differ in whatever you want, since the most = >> restricitve situation is when you can only change the pk afaiu. > > I am not sure i understand the last sentence. 2005 certificates differ = > only in public keys. The resulting hash value in 2005 attack is a = > random string. The only X.509 cert field in which such random string = > can be placed is pk. You can not generate any two certs that differ in = > whatever you want. And if you have two certificates that differ only = > in pk, i don't see what could you do with them. Those certificates has = > the same identities, the same validity periods, everything. The only = > thing you can do is to blame Certification Authority for the issuance = > of two certificates with different keys. > > In 2007 the Intermediate Hash Value is extended in the way that it can = > be placed in the X.509 human-readable field. So, you can claim you are = > someone else, you could change validities, etc. Which is potentially = > more dangerous, right? > ok, makes sense >> >> I find the section on the analysis on the certificates a bit = >> inconclusive. I mean, you describe a set of attacks, which all of = >> them are about to create two certs with more or less similar data and = >> with different pk. Do these attacks have some implications in send? = >> How would an attacker launch an attack to send using that? >> My understnading is that no new attack against send is possible = >> because of that. I mean, this basically affects non repudiation and = >> send does not provides or uses non repudiation features afaict. >> >> So, i would like to suggest to try to understand if these attacks = >> against certificates have some implication in send security and if = >> there are new attacks that can be launched against send and include = >> that in the document. > > IMO, the attacks which affect just pk do not have implications in = > send. But, attacks which affect human-readable data have implications = > in send. For example, the changed set of IP prefixes in the rfc3779 IP = > address extension, changed validity period. Up to date, no such attack = > has been demonstrated, but 2007 attack against identity field is on = > the way to such attacks. > so you should analyze the impact in send of these potentially possible = attacks and write them down in the document >> >> and the fact that in >> order to perform a succesful real-world attack he can not change a >> human-readable data. >> >> how is that? SeND is exectued without human intervention, so i am not = >> sure this argument applies >> (in addition, rephrase this cause it is hard to understand, in = >> particular, it is hard to follow the linking with the previous sentence) > My understanding is that, taking into account demonstrated collision = > attacks, it is hard to generate two useful, meaningful human-readable = > fields. Because, in the recent collision attacks, at least on of two = > messages has predefined shape, as described in section 2.1, rfc4270. > >> >> Question, wouldn't it be possible to modifiy the signature, so that = >> the hash algorithm field is not signed using a hash function at all? = >> i.e. is directly encrypted wihtout performing a hash before so, that = >> in order to change the hash funtion field you need to break the pk = >> encryption but not the hash algorithm? >> >> (not sure if you are following what i am saying here, but i think it = >> may be possible) >> > Yes, i think it may be possible, with both the hash algorithm field, = > and the digital signature field. Should we analyze this case? > please do regards, marcelo > Ana > > _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext From cga-ext-bounces@ietf.org Fri Sep 19 14:03:50 2008 Return-Path: X-Original-To: cga-ext-archive@optimus.ietf.org Delivered-To: ietfarch-cga-ext-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B583A6A02; Fri, 19 Sep 2008 14:03:50 -0700 (PDT) X-Original-To: cga-ext@core3.amsl.com Delivered-To: cga-ext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5383A6879 for ; Fri, 19 Sep 2008 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 4FwUxp+iBu3w for ; Fri, 19 Sep 2008 14:03:48 -0700 (PDT) Received: from labs4.cc.fer.hr (labs4.cc.fer.hr [161.53.72.24]) by core3.amsl.com (Postfix) with ESMTP id 817183A681B for ; Fri, 19 Sep 2008 14:03:48 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs4.cc.fer.hr (8.14.2/8.14.2) with ESMTP id m8JL4ZwS026074 for ; Fri, 19 Sep 2008 23:04:37 +0200 (CEST) Received: from [192.168.1.121] ([89.164.5.16]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Sep 2008 23:03:57 +0200 Message-ID: <48D413BC.9000401@fer.hr> Date: Fri, 19 Sep 2008 23:03:56 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: marcelo bagnulo braun References: <48D128EA.3060503@it.uc3m.es> <48D3DE2F.4090607@fer.hr> <48D40A0C.2070707@it.uc3m.es> In-Reply-To: <48D40A0C.2070707@it.uc3m.es> X-OriginalArrivalTime: 19 Sep 2008 21:03:57.0201 (UTC) FILETIME=[3B2FC810:01C91A9B] X-Scanned-By: MIMEDefang 2.64 on 161.53.72.24 Cc: cga-ext@ietf.org Subject: Re: [CGA-EXT] about draft-kukec-csi-hash-threat-02 X-BeenThere: cga-ext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: CGA and SeND Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: cga-ext-bounces@ietf.org Errors-To: cga-ext-bounces@ietf.org marcelo bagnulo braun wrote: > >> Right. Scenarios in which the hash is completely broken are also >> described, but just for the comparation purposes. That is something >> what we were talking in Philadelphia -- do we have to solve all the >> attacks or just the attacks which are up to date possible in practice. >> We decided to mention in the draft all the attacks (including just >> theoretically possible ones), but to solve just practically possible >> attacks. >> >> > I still don't understand > > the analysis you have made is basically about collision attacks > > However, when we consider how to encode the hash function in send, we > also consider the attacks against other properties of the hash function, > in particular to the preimage attacks. I mean, bidding down attacks > being considered are not about collision free, but about the preimage > attacks afacit, right? > Right, it is. In the new version of draft, in the analysis part, are considered both the preimage and collision attacks. IMO, it might be useful to analyze both attacks, to clarify things more precisely, and also because of some possible future attacks. Contrary to the analysis part, IMO, the solution part should be based on the collision attacks. The downgrade attack is mentioned at the end, just as one additional plus. Do you agree for the analysis part to include both collision and preimage attack analysis? And, do you agree that the solution should be based on collision attacks only? >> So basically what you are saying is that the it is better to use only >> human readable fields because they are harder to attack. >> No. Just that non-human readable fields demand less effort to break them, since, it is easier to extend the IHV value to a random string, than to a meaningful data. > >> IMO, the attacks which affect just pk do not have implications in >> send. But, attacks which affect human-readable data have implications >> in send. For example, the changed set of IP prefixes in the rfc3779 IP >> address extension, changed validity period. Up to date, no such attack >> has been demonstrated, but 2007 attack against identity field is on >> the way to such attacks. >> >> > so you should analyze the impact in send of these potentially possible > attacks and write them down in the document > Ok, it will be added in the next version. > > >> Yes, i think it may be possible, with both the hash algorithm field, >> and the digital signature field. Should we analyze this case? >> >> > please do > > Ok, it will be added also. Thank you, Cheers Ana _______________________________________________ CGA-EXT mailing list CGA-EXT@ietf.org https://www.ietf.org/mailman/listinfo/cga-ext