From hannes.tschofenig@gmx.net Tue Mar 5 06:21:31 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 826FD21F89A4 for ; Tue, 5 Mar 2013 06:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMnL6gespI7X for ; Tue, 5 Mar 2013 06:21:31 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7EB21F899E for ; Tue, 5 Mar 2013 06:21:31 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LmxXe-1Uic453gbM-00h3xC for ; Tue, 05 Mar 2013 15:21:29 +0100 Received: (qmail invoked by alias); 05 Mar 2013 14:21:27 -0000 Received: from dslb-188-107-233-245.pools.arcor-ip.net (EHLO [192.168.178.169]) [188.107.233.245] by mail.gmx.net (mp004) with SMTP; 05 Mar 2013 15:21:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18MT58Hsl8M72Z0qNW+XmIf7Z5B4e75IvNXbSdI2Y XQIlQ3E0pwNkRW Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) From: Hannes Tschofenig Date: Tue, 5 Mar 2013 16:21:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF Security Area Advisory Group X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Subject: [saag] Fwd: Alternative PKI Models Side Meeting X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 14:21:31 -0000 FYI Begin forwarded message: > From: Hannes Tschofenig > Date: March 5, 2013 4:19:51 PM GMT+02:00 > To: 86attendees@ietf.org > Cc: Hannes Tschofenig > Subject: Alternative PKI Models Side Meeting >=20 > Hi all, >=20 > When our security ADs scheduled the BOF on Certificate Transparency = (CT) [0] in Atlanta (IETF-85), some expressed interest in continuing the = discussions regarding improvements to the Web PKI. In the IAB, we have = been brainstorming about holding a workshop to progress the topic, but = with the announcement of the NIST workshop on Improving Trust in the = Online Marketplace [1] we decided to postpone our workshop. >=20 > The upcoming IETF-86 meeting is, however, a good opportunity to = discuss whether there is a need for additional investigations. In = particular, we have been wondering whether the IETF community has the = same level of understanding regarding the requirements, goals, and the = design assumptions. The emerging evolutionary alterations to the Web PKI = model -- i.e., DANE, CT, TACK, etc. -- superficially fit the model, but = they alter it in subtle and interesting ways. >=20 > If you are interested in a discussion you are welcome to join our side = meeting on Thursday evening (at 8pm*) in room Boca 4 (the IAB Office). >=20 > Ciao > Hannes & JeffH >=20 > References:=20 > [0] https://www.ietf.org/mailman/listinfo/therightkey > [1] http://www.nist.gov/itl/csd/ct/ca_workshop.cfm >=20 > PS: We picked 8pm since some of you may want to stop by at the = Bits-N-Bites event. From hartmans@painless-security.com Wed Mar 6 09:39:39 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A163921F8A56; Wed, 6 Mar 2013 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCqCV6BtmQAv; Wed, 6 Mar 2013 09:39:35 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 927A821F89B3; Wed, 6 Mar 2013 09:39:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1E01C2014B; Wed, 6 Mar 2013 12:39:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 83BE141CE; Wed, 6 Mar 2013 12:39:25 -0500 (EST) From: Sam Hartman To: abfab@ietf.org, radext@ietf.org, saag@ietf.org Date: Wed, 06 Mar 2013 12:39:25 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 07 Mar 2013 08:47:08 -0800 Subject: [saag] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:39:39 -0000 The ABFAB working group has been busy at work describing a federated identity and access management model that enables federated identity for a wide variety of use cases and applications; this work is currently drawing to a close. However, one of the typical problems in the federated world - and a problem that any ABFAB implementations needs to address - is managing the scaling of number of partners involved in the federation (this is because configuration changes need to be made at all interested partners when new entities join). Existing federation technologies attempt to solve this problem in a variety of ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has their own unique disadvantages. A much more elegant, flexible, and extensible way to achieve the same goals would be beneficial - especially for when scaling up to the potential number of entities in a community of ABFAB-enabled partners. Alongside this, operationally, there is also a need to separate the authentication process from the creation of a new partnership across a set of federated entities - so as to allow existing credentials to be used for new communities of users with minimal operation and infrastructure costs. This is crucial in driving adoption of federated technologies on a wide scale, and in reducing the cost of operating and being a part of federation on such a wide scale. Trust Router is an attempt to build an infrastructure that solves these - and other - problems (see the full problem statement for more details). Essentially, trust Router works by distributing information about new and existing trust relationships across a network of entities. It achieves this distribution using protocols with many similarities to existing routing protocols, and avoids any requirement for technologies such as PKI. The broad applicability of a general infrastructure for routing trust information between arbitrary entities and allowing them to communicate securely means that this is potentially quite an exciting topic, and one ripe for standardisation. Come join us to talk all about trust and trust routing at our Bar BOF - to be held on Thursday March 14th @ 11:30AM, located in Caribbean 7. Documents to read: * Trust Router problem statement - http://tools.ietf.org/html/ draft-howlett-abfab-trust-router-ps-02 * ABFAB Architecture document - http://tools.ietf.org/html/ draft-ietf-abfab-arch-05 * Trust router protocol overview - http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt From kwiereng@cisco.com Wed Mar 6 09:43:16 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B18D21F8CF5; Wed, 6 Mar 2013 09:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVbpoI31w+k4; Wed, 6 Mar 2013 09:43:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9021F8CEB; Wed, 6 Mar 2013 09:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1362591791; x=1363801391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DasIbZK0n/TPwikN7ER4p4l0Kkft1EBAWy+FQIhJH+4=; b=AbLj++XzO9fpH3gIsRwlLovpXHHbumzHmVSz0Ua2FGAtx21dCTLBNufU xkA1CGGX56mKbVr3kGG9YsOU1y3iFoZ9sRxbiLzrKL7HIZUof2MiMVKrS lfH3uHkCdupEa9mSlU0L4a7gtf6RLByvxFttmSQnW5h2+hjCxa2Ya1jvO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKZ+N1GtJV2c/2dsb2JhbAA7CcRGgVoWc4IqAQEBAwEBAQE3NAMBBwULAgEIEiQQJwsXDgIEDgUUh3kGDLx+jUoIgQczB4JfYQOWS4Eeij2FFYMI X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184270458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Mar 2013 17:43:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r26HhAPv015744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 17:43:11 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.138]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:43:10 -0600 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 Thread-Index: AQHOGpGXSYJnqNzinkOuD8EzixwzxZiY7v8G Date: Wed, 6 Mar 2013 17:43:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 07 Mar 2013 08:47:08 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:43:16 -0000 Sam, How does this relate to the trust router slot in Routing Area Open Meeting? Klaas Sent from my iPad On 6 mrt. 2013, at 18:39, "Sam Hartman" wr= ote: > The ABFAB working group has been busy at work describing a federated iden= tity > and access management model that enables federated identity for a wide va= riety > of use cases and applications; this work is currently drawing to a close. >=20 > However, one of the typical problems in the federated world - and a probl= em > that any ABFAB implementations needs to address - is managing the scaling= of > number of partners involved in the federation (this is because configurat= ion > changes need to be made at all interested partners when new entities join= ). > Existing federation technologies attempt to solve this problem in a varie= ty of > ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has t= heir > own unique disadvantages. A much more elegant, flexible, and extensible w= ay to > achieve the same goals would be beneficial - especially for when scaling = up to > the potential number of entities in a community of ABFAB-enabled partners= . >=20 > Alongside this, operationally, there is also a need to separate the > authentication process from the creation of a new partnership across a se= t of > federated entities - so as to allow existing credentials to be used for n= ew > communities of users with minimal operation and infrastructure costs. Thi= s is > crucial in driving adoption of federated technologies on a wide scale, an= d in > reducing the cost of operating and being a part of federation on such a w= ide > scale. >=20 > Trust Router is an attempt to build an infrastructure that solves these -= and > other - problems (see the full problem statement for more details). > Essentially, trust Router works by distributing information about new and > existing trust relationships across a network of entities. It achieves th= is > distribution using protocols with many similarities to existing routing > protocols, and avoids any requirement for technologies such as PKI. The b= road > applicability of a general infrastructure for routing trust information b= etween > arbitrary entities and allowing them to communicate securely means that t= his is > potentially quite an exciting topic, and one ripe for standardisation. >=20 > Come join us to talk all about trust and trust routing at our Bar BOF - t= o be > held on Thursday March 14th @ 11:30AM, located in Caribbean 7. >=20 > Documents to read: > * Trust Router problem statement - http://tools.ietf.org/html/ > draft-howlett-abfab-trust-router-ps-02 > * ABFAB Architecture document - http://tools.ietf.org/html/ > draft-ietf-abfab-arch-05 > * Trust router protocol overview - > http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Mar 6 09:46:01 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B4021F8CFA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylbPdggsiprA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3D21F8C12; Wed, 6 Mar 2013 09:45:56 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A30A12014B; Wed, 6 Mar 2013 12:45:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A20041CE; Wed, 6 Mar 2013 12:45:55 -0500 (EST) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: Date: Wed, 06 Mar 2013 12:45:55 -0500 In-Reply-To: (Klaas Wierenga's message of "Wed, 6 Mar 2013 17:43:10 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 07 Mar 2013 08:47:08 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [saag] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:46:01 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> Sam, How does this relate to the trust router slot in Routing Klaas> Area Open Meeting? we're going to introduce the topic and try and get routing folks to go to the bar bof. We think having routing clue review the trust router would be valuable. From klaas@wierenga.net Wed Mar 6 11:55:02 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177D21F8949; Wed, 6 Mar 2013 11:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-2XbCdbWZa5; Wed, 6 Mar 2013 11:54:57 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id D063A21F897A; Wed, 6 Mar 2013 11:54:44 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r26JseG9003213; Wed, 6 Mar 2013 20:54:40 +0100 Received: from 5355139f.cm-6-6a.dynamic.ziggo.nl ([83.85.19.159] helo=[192.168.1.87]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UDKP5-000KeL-Q5; Wed, 06 Mar 2013 20:53:31 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3B80CEB5-B1D0-4A3B-A9E9-C8AABD854BEE@wierenga.net> X-Mailer: iPad Mail (10B146) From: Klaas Wierenga Date: Wed, 6 Mar 2013 20:54:41 +0100 To: Sam Hartman X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vJ8jSEag - 288397efad06 - 20130306 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) X-Mailman-Approved-At: Thu, 07 Mar 2013 08:47:09 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" , "Klaas Wierenga \(kwiereng\)" , "saag@ietf.org" Subject: Re: [saag] [radext] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:55:02 -0000 On 6 mrt. 2013, at 18:45, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: > > Klaas> Sam, How does this relate to the trust router slot in Routing > Klaas> Area Open Meeting? > > we're going to introduce the topic and try and get routing folks to go > to the bar bof. > We think having routing clue review the trust router would be valuable. Agreed, makes a lot of sense. Klaas > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From stephen.farrell@cs.tcd.ie Mon Mar 11 10:05:20 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B015A11E8167 for ; Mon, 11 Mar 2013 10:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTu6ntX3wHPN for ; Mon, 11 Mar 2013 10:05:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40521F8A41 for ; Mon, 11 Mar 2013 10:05:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC06EBE2F for ; Mon, 11 Mar 2013 17:04:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOKe3CBi23iK for ; Mon, 11 Mar 2013 17:04:45 +0000 (GMT) Received: from [130.129.96.60] (dhcp-603c.meeting.ietf.org [130.129.96.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8A0FBE25 for ; Mon, 11 Mar 2013 17:04:45 +0000 (GMT) Message-ID: <513E0EAC.30308@cs.tcd.ie> Date: Mon, 11 Mar 2013 17:04:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "saag@ietf.org" References: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com> In-Reply-To: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <65453B05-7138-4146-BF08-E378DC32EADC@ssh.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 17:05:20 -0000 FYI. Not sure that this mail made it to the list, (can't see it in the archive). If you're interested and around we're meeting in Boca VIII right now S -------- Original Message -------- Subject: SSH Key Management Best Practice - Monday 13:00-14:00 at Boca 8 Date: Thu, 7 Mar 2013 04:34:02 +0200 From: Tatu Ylonen To: saag@ietf.org CC: ietf-ssh@netbsd.org We will be having a side meeting on SSH Key Management Best Practice at the IETF on Monday, 13:00 to 14:00. The assigned room is Boca 8. Welcome! I will present draft-ylonen-sshkeybcp-00 (http://tools.ietf.org/html/draft-ylonen-sshkeybcp-00) and we should have plenty of time for discussion. The draft illustrates threats due to poorly managed SSH user keys, provides a process for getting from an unmanaged environment into a managed environment, and presents recommendations for ongoing management and continuous monitoring. It also discusses the residual risks if any of the remediation steps are not taken. The draft focuses on managing large environments (100 - 100000+ servers) and is targeted at security architects, Unix/Linux operations managers, policy makers, and auditors. It also briefly addresses other technologies for automated access, as the several of the threats also apply to them. As background, the SSH protocol is widely used for managing Unix/Linux servers, telecommunications networks, routers, and many embedded systems. It is also widely used for file transfers (particularly with the SFTP protocol), and many systems management, security, and audit tools use it to access managed systems. Many organizations have thousands of custom scripts using SSH to perform administrative tasks and to automatically transfer data between applications. A lot of these uses are fully automated and run without an interactive user; keys (without passphrases) are usually used for authentication in those cases. Many large organizations have accumulated hundreds of thousands, in some cases millions, of authorized SSH user keys on their servers over the years. These keys have never been changed. Administrators don't know what each key is used for and cannot remove these keys because they don't know what applications would break if they remove a key. System administrators can use key-based access to circumvent privileged access management systems, creating essentially permanent backdoors to production servers. SSH user keys are already collected and used by various attack tools, and can help malware spread throughout an organization's server infrastructure in minutes. The problem is largely unrecognized and is not understood by compliance auditors and IT risk managers. The problem is not about managing keys but about managing access. SSH user keys are generally strong enough. The problem is that organizations do not know who can access what and many do not control who can add new authorized keys, do not audit key-based access to servers, and do not control what can be done with each key. Generally, organizations do not properly terminate access when an employee leaves or changes roles. Many organizations permit automated access from low-security hosts (e.g., development machines) to critical production systems. The draft documents the current best practice of managing SSH user keys. It is not a protocol document, but rather presents risks and recommendations for proper process and policy. Feedback on the draft is very welcome regardless of whether you will be able to attend the meeting. Please send comments directly to me. We want the draft to make a reasonable compromise between security and implementability in an organization. The plan is to eventually publish a future version of the document as a Best Current Practice. Best regards, Tatu Ylonen From mcr@sandelman.ca Tue Mar 12 11:20:28 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D888F11E810F; Tue, 12 Mar 2013 11:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQCxa3RJd2H8; Tue, 12 Mar 2013 11:20:28 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id DDEC111E80FB; Tue, 12 Mar 2013 11:20:27 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 1653922060; Tue, 12 Mar 2013 18:20:27 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EDEB1CA0C7; Tue, 12 Mar 2013 14:20:23 -0400 (EDT) From: Michael Richardson To: saag@ietf.org X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Mar 2013 14:20:23 -0400 Message-ID: <12252.1363112423@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, Ted Lemon , Ralph Droms Subject: [saag] security for multi-link subnets X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:20:29 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable It was pointed out in a private discussion that the inclusion of security parameters in the ROLL applicability statements might be surprising to some. For those who want a quick look: http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ http://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicabil= ity/ http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-= building/ Specifically, people wouldn't not normally think to look at applicability statements for a routing protocol to see that it is specifying not just security parameters for the routing protocol=20 itself, but in some cases, requirements on access to the LLN as well. I agreed that perhaps this needed additional socialization, which I'm trying to do with this email. Some of my logic of what we are doing is that by (securely) assembling a bunch of links into a multi-link subnet, that in effect the ROLL applicability statements are in effect a kind of IP-over-FOO document. To parallel it to other IP-over-FOO documents better, they often specify things like how to encapsulate, and how to do address resolution on the subnet.=20 RPL LLNs do not use stock-ND/ARP (which normally would be specified in an IP-over-FOO document), but rather use the RPL messages to discover other nodes on the subnet. I have asked that the applicability statements be clear about if they use RFC6775 (6lowpan-ND), and if so, how.=20 It was suggested really, we never did that before: specify security of the network in IP-over-FOO documents. Well, that's true, because we never did a an IP-over-802.11, because it was ethernet. When WIFI's various incarnations happened (remember borrowing 2Mb/s *FH* wireless PCICIA cards back at IETF46?), they tried hard to make it look like ethernet, with ethernet-like physical security (WEP =3D=3D "Wired Equi= valent Privacy"). It's too bad that we didn't get more involved at the time, in the end, we did EAP and keyprov in great part to get that part done right. I still think that the 802.11 security is largely a disaster.=20 It is possible that the problem is the word "applicability", and perhaps we should have a different term. I would welcome discussion here, or even just +1 that this is the right approach. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRP3HmAAoJEKD0KQ7Gj3P2fscH/0qBiwmHceSgQRLLMycvK10B TbAe0b/3DNf5Asiyh5aEYZvxF3ovs+fJbZTbPU4DFLHS5yKT82EljsouyqM7Fkjh BT4vX71jBKXEM6H44PTcLIfxtjRlgpsWPx40eRkcEVNiblnl4etVtWOvwKdsXGXN 4lRLIjDIi1S0WhY3czJCITcyK9U7jw+V02jzexevcVb2o5ZVlFfwzjnh85wMMsoA SgheXScsXvYvdRQ4Bzr4qHtt3bcFMu2HZdkaqEJhMhR/3pTIixBKsxtTdn4BanNL Z+ggTTAW8TIGdHyFjIk7H3NT0dxJuOH6D1exdhN5zWCnk/ZRW+qt6dlESj56A2w= =JLTP -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Mar 12 12:46:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C5011E80F0; Tue, 12 Mar 2013 12:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0mtxmscwFh0; Tue, 12 Mar 2013 12:46:08 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0EC11E8127; Tue, 12 Mar 2013 12:46:08 -0700 (PDT) Received: from sandelman.ca (unknown [130.129.16.118]) by relay.sandelman.ca (Postfix) with ESMTPS id 32E5722060; Tue, 12 Mar 2013 19:46:07 +0000 (UTC) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 347C9CA0BC; Tue, 12 Mar 2013 15:46:06 -0400 (EDT) From: Michael Richardson To: Ulrich Herberg In-reply-to: References: <12252.1363112423@sandelman.ca> Comments: In-reply-to Ulrich Herberg message dated "Tue, 12 Mar 2013 14:31:44 -0400." X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Mar 2013 15:46:05 -0400 Message-ID: <16795.1363117565@sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms Subject: Re: [saag] [Roll] security for multi-link subnets X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:46:08 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ulrich" =3D=3D Ulrich Herberg writes: Ulrich> I think it is also worth mentioning RFC4903, in particular: Ulrich> "A multi-link subnet model should be avoided. IETF working gro= ups Ulrich> using, or considering using, multi-link subnets today should Ulrich> investigate moving to one of the other models." Ulrich> Have the issues mentioned in RFC4903 been sufficiently addresse= d? I think that if we were going supposed to avoid a multi-link subnet, that would have been objected to already.=20=20 I think that 4903 concerns applied to all of 6lowpan and ROLL work, and I think that actually we did deal with all of these. =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJRP4X8AAoJEKD0KQ7Gj3P2ADkH/izSIOeAQAxgMoXcUttMLQDc sNS00G0ywTlgkyaHWEH1jb4frm3dQHN5ZMtttFJ/IF4quMM6dyPuVsghNLaIRMeA 5TNMw9QMW8d2mTLJhpDOWIv+7ED79wq6VDpwwcVe50dDZNB9HPPwTryfjzE//v2J lTlsgodUu/cZTKsEyE8Wc7jFXwdRHKYCRmjZVcf+iIBdUOoyQ02RaCrLS4mx+0QY TRwVuckrh1wpuPbyUscuMyh/r+4cCYdFSIOHSDA6en6ccgVg502Xrf8DsWhHe/Xu ewqg74/pMrMUKy8j2atyHF49R1/DYwL4L00pYQuA/GHdMtIrxcWN+Ql9AanRcco= =ovmM -----END PGP SIGNATURE----- --=-=-=-- From ulrich@herberg.name Tue Mar 12 11:31:46 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF211E8166 for ; Tue, 12 Mar 2013 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sLYJBfZfyi7 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by ietfa.amsl.com (Postfix) with ESMTP id A57F311E8164 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so135823vea.1 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3QDnNIGtnL7IyVT4Gy42llRn27yRE/3V0bWL7fcyi7w=; b=Gun6wHuC6D5RkcF5MNyqhnQ1Xl62IAurV6crJ7lV3jYKthD1GBy/k+hALFQ/JaFY9C nwlZ5y4Tbz6epqKAXFwHFj7gHE53VYqPeZF7i69kNEsQRx+mdntJBI1xyIkjbqaHQX0r yfY1mTvUNtjxYTCgxIgooa+FOKdgZbUYDegP0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=3QDnNIGtnL7IyVT4Gy42llRn27yRE/3V0bWL7fcyi7w=; b=Hjpjco6sQ/welwY7QLdjIkzhvwnBcvNTygix/PQyNFyRzoK63AhQrI1K2nCsSF2h20 ab96tHq58iwmRuvPpjGGQGrRhQmGpkRxcNBkiNTFEUa6uNMac/yuJOS9F5TqYn2ppRrS 1VvMt/VV12gHjD6MrPNbEcJc+gb9hWayHgHQWn8k1ljmxJqBYBqtCVW8hMC460jY3mU9 M4/bHeUkmU4xIh7ZQcqmFbiRfDWebgzq5Z5xbfwMwlIwnkKng8MO52FSZSeWbEQAdG22 iAyAOtEB+WSQ62VfKVDknF0owTPyVbzz2f/N/tG8X+45b2bpWAiAHf3ZijsPkmt/7BZ8 QHkw== MIME-Version: 1.0 X-Received: by 10.52.29.136 with SMTP id k8mr6015520vdh.40.1363113105105; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Tue, 12 Mar 2013 11:31:44 -0700 (PDT) In-Reply-To: <12252.1363112423@sandelman.ca> References: <12252.1363112423@sandelman.ca> Date: Tue, 12 Mar 2013 14:31:44 -0400 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlTb4giF3xj7Q3Ee6rjCPUWugkDIihuboXdF2s/eGOuVU1B+VmFbc8t3UE6DjHtjRGJPdpj X-Mailman-Approved-At: Wed, 13 Mar 2013 08:12:05 -0700 Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms Subject: Re: [saag] [Roll] security for multi-link subnets X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 18:31:46 -0000 Michael, I think it is also worth mentioning RFC4903, in particular: "A multi-link subnet model should be avoided. IETF working groups using, or considering using, multi-link subnets today should investigate moving to one of the other models." Have the issues mentioned in RFC4903 been sufficiently addressed? Best regards Ulrich On Tue, Mar 12, 2013 at 2:20 PM, Michael Richardson wrote: > > It was pointed out in a private discussion that the inclusion of > security parameters in the ROLL applicability statements might be > surprising to some. For those who want a quick look: > http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/ > http://datatracker.ietf.org/doc/draft-ietf-roll-rpl-industrial-applicability/ > http://datatracker.ietf.org/doc/draft-brandt-roll-rpl-applicability-home-building/ > > Specifically, people wouldn't not normally think to look at > applicability statements for a routing protocol to see that it is > specifying not just security parameters for the routing protocol > itself, but in some cases, requirements on access to the LLN as well. > > I agreed that perhaps this needed additional socialization, which I'm > trying to do with this email. > > Some of my logic of what we are doing is that by (securely) assembling > a bunch of links into a multi-link subnet, that in effect the ROLL > applicability statements are in effect a kind of IP-over-FOO document. > > To parallel it to other IP-over-FOO documents better, they often specify > things like how to encapsulate, and how to do address resolution on the > subnet. > > RPL LLNs do not use stock-ND/ARP (which normally would be specified in an > IP-over-FOO document), but rather use the RPL messages to discover other > nodes on the subnet. I have asked that the applicability statements > be clear about if they use RFC6775 (6lowpan-ND), and if so, how. > > It was suggested really, we never did that before: specify security of > the network in IP-over-FOO documents. Well, that's true, because we > never did a an IP-over-802.11, because it was ethernet. > > When WIFI's various incarnations happened (remember borrowing 2Mb/s *FH* > wireless PCICIA cards back at IETF46?), they tried hard to make it look > like ethernet, with ethernet-like physical security (WEP == "Wired Equivalent > Privacy"). It's too bad that we didn't get more involved at the time, > in the end, we did EAP and keyprov in great part to get that part done > right. I still think that the 802.11 security is largely a disaster. > > It is possible that the problem is the word "applicability", and perhaps > we should have a different term. I would welcome discussion here, or > even just +1 that this is the right approach. > > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From d.sturek@att.net Tue Mar 12 12:59:04 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C4C11E8184 for ; Tue, 12 Mar 2013 12:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cZ-LsHbf2UU for ; Tue, 12 Mar 2013 12:58:59 -0700 (PDT) Received: from nm16-vm0.access.bullet.mail.sp2.yahoo.com (nm16-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.166]) by ietfa.amsl.com (Postfix) with ESMTP id 5210211E810A for ; Tue, 12 Mar 2013 12:58:55 -0700 (PDT) Received: from [98.139.44.104] by nm16.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000 Received: from [98.138.226.241] by tm9.access.bullet.mail.sp2.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 12 Mar 2013 19:58:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1363118330; bh=OYxF7Qzv5vN5RDPaAPBglfGLxut3Bunp5AU71vPm4K4=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Fzs9mZXMW/M8ZjhBmGzn9f+RmWCOSRy6VTokj9qNrnmNLXqKM5F+Jd3bM9k/n2JbGzC2hI3+pjX1NpxhkFhhRIvEEHTelilEgIm/s7zqv1lhmNpfHZK7UQFZ+Y6KWI9DtkPCdXEOxdN5pfphGWfWSxKxVJboTXQDZPM9LlAqaT8= X-Yahoo-Newman-Id: 232035.222.bm@smtp112.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PaH4t0MVM1n8euOzwnY5Jbc9eGgC_Qw8dF9MWu7pCbsMm_V xRMy9rcwCK9QZoHXGSf2KKxEGz8RkvIadV.bH9uvf5BpPRMckEnT5em0kPTO lXewI8QcOHv9RMSSkY9KoMcOx8TfqvlzlhMJAKRd7EjVk3a8O1LBS6HAq8V8 aBnBb4ToUDrKUjCJskD2dtBjRnojmKAYiEI4V9QtIlD3cNSJQHR1j4SGyZDH 7veNW6RVNt6Z_zmOomlRJOH99neMyj35.l6ZDx5kvebd85VcMjCJ5iZbVcjT qd3EciS62lCSFHwPZBtWYzWKcEH56hPrXipaWqbC_OXbhwYwOFNuk6NGM3yy NSNHe820RiH_IYDWTNT1ovIrdo8ZM_1kSOFWSmB9g6p0g6sAYR8QqMk06Bhq Hu7DevPZH2BnS6_Ah_U_cbfh21yDdp.dglHMfELRKM3UxwdWBgmeVOrLGVMK ME_wdAbjxbS_IcphM X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.117] (d.sturek@66.27.60.174 with login) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 12 Mar 2013 12:58:50 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Tue, 12 Mar 2013 12:58:44 -0700 From: Don Sturek To: Michael Richardson , Ulrich Herberg Message-ID: Thread-Topic: [Roll] security for multi-link subnets In-Reply-To: <16795.1363117565@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Wed, 13 Mar 2013 08:12:05 -0700 Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms Subject: Re: [saag] [Roll] security for multi-link subnets X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:59:04 -0000 Hi Michael (and Ulrich), The area that I think needs more work around the multi-link subnets topic is the scope for site-local addresses. Since link locals are not that useful in multi-link subnets (routing wise) and not all devices in a 6LoWPAN/ROLL environment may want global addresses even if such a prefix were available, clear scoping rules (eg, routing, multicast propagation) on site local addresses is a major topic. If someone knows of an RFC (or even a draft) that starts to address the issue of identifying site local versus non-site prefixes/interfaces, that would be interesting. This topic is especially interesting in deployments with multiple prefixes (like that now being discussed in Homenet) as well as campus type environments. I also bring this up (on purpose) under the topic of "security for multi-link subnets" since turning on link security does not help securing these networks....... Don On 3/12/13 12:46 PM, "Michael Richardson" wrote: > >>>>>> "Ulrich" == Ulrich Herberg writes: > Ulrich> I think it is also worth mentioning RFC4903, in particular: > > Ulrich> "A multi-link subnet model should be avoided. IETF working >groups > Ulrich> using, or considering using, multi-link subnets today should > Ulrich> investigate moving to one of the other models." > > Ulrich> Have the issues mentioned in RFC4903 been sufficiently >addressed? > >I think that if we were going supposed to avoid a multi-link subnet, >that would have been objected to already. >I think that 4903 concerns applied to all of 6lowpan and ROLL work, and >I think that actually we did deal with all of these. > >-- >Michael Richardson >-on the road- > > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Tue Mar 12 13:36:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50E01F0C74 for ; Tue, 12 Mar 2013 13:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lHW9hOnCyBx for ; Tue, 12 Mar 2013 13:36:07 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7A01921F8C97 for ; Tue, 12 Mar 2013 13:36:07 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id k1so145935vck.24 for ; Tue, 12 Mar 2013 13:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FOp06LDqNC2OAeQtOlfytgoc6dVhly+Qv8Dt8u+jXTo=; b=zZ0xeCpLCSyxaQaOobOwYY/fa0+J0f4OjJZR/HBKPyW8Dh/6SjDPnBpwcPYjLnsMTM llRilkQxMPntQ/5arBlYnFHAC7xxxhqrzt75cCvPUNx+cLbuH4JyhFSBdtsUnftKPmQA 9E/P7Sct9TB5OFCmtNt0XGWWt2/J1szvDc3RM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FOp06LDqNC2OAeQtOlfytgoc6dVhly+Qv8Dt8u+jXTo=; b=WyzAzWpeQvGgt02jhNz4Mr4o1wvCTzYZejHLm73Qo29xY9+q77CF2rL8zrTJXvtT9g IYwyp2pyFBT7hJ+XiBSzN2B9FFDALAd5aP2jGT5kP1L0g9TYbchDngCnn5VmW/CYbSZH 5b1ZI8eZKseFIqrq+A6Y2BWHHzCENJoB0sKoI2FXL0a1koacY2bw0uvylBQTXbfws7OI RA8HOYI2fUN0jnXi5sxYxXpeor4EqjZ+LyTD3VPaPaLqpW+XfGaktXD0YWcRlRKPY8dO 4BfRe1H3C/YZ0Su1D0ElgFubX/7iQ2jqPo7SBbPhpz+1qL2aGv4o/V9McJ3X/coQ6ohI jirA== MIME-Version: 1.0 X-Received: by 10.58.188.48 with SMTP id fx16mr7285150vec.22.1363120566754; Tue, 12 Mar 2013 13:36:06 -0700 (PDT) Received: by 10.220.106.202 with HTTP; Tue, 12 Mar 2013 13:36:06 -0700 (PDT) In-Reply-To: <16795.1363117565@sandelman.ca> References: <12252.1363112423@sandelman.ca> <16795.1363117565@sandelman.ca> Date: Tue, 12 Mar 2013 16:36:06 -0400 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnri6narJkDabfYoEuvCuHUbA0b87h6+ezqM4IRj+ywajvglvzit+UQMDOYGbNVh6xOpN1C X-Mailman-Approved-At: Wed, 13 Mar 2013 08:12:05 -0700 Cc: roll@ietf.org, Ted Lemon , saag@ietf.org, Ralph Droms Subject: Re: [saag] [Roll] security for multi-link subnets X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:36:09 -0000 Michael, On Tue, Mar 12, 2013 at 3:46 PM, Michael Richardson wrote: > [...] > Ulrich> Have the issues mentioned in RFC4903 been sufficiently addressed? > > I think that if we were going supposed to avoid a multi-link subnet, > that would have been objected to already. > I think that 4903 concerns applied to all of 6lowpan and ROLL work, and > I think that actually we did deal with all of these. I must have missed that discussion. Can you please point me to where and how the issues have been solved, and why the advice of RFC4903 to not use multi-link subnets does not apply to LLNs / to RPL? Thanks Ulrich From leifj@mnt.se Wed Mar 13 11:13:40 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45C21F8E71 for ; Wed, 13 Mar 2013 11:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKk5G-Ca8EOJ for ; Wed, 13 Mar 2013 11:13:39 -0700 (PDT) Received: from mail-da0-x22b.google.com (mail-da0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9518521F8E6D for ; Wed, 13 Mar 2013 11:13:39 -0700 (PDT) Received: by mail-da0-f43.google.com with SMTP id u36so528252dak.2 for ; Wed, 13 Mar 2013 11:13:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=dFPBSeC1+rDEWT9hB0MqBnNB9Q1xB6RnxdzNC2VQnPI=; b=AryTYBc/V3Q6500Lnp+YDYsbRa8bGfw4OV7Liduop7OevTOqhFTflqE4G2EENQbjMi m/IrIaTlIl07VeObEzQgVacuwDuUUcyZmy7EFtKht7xRK5Dn4evzMyufqNV5h35DVDBX 2VVDlpuLr7M6FhQzosNypvXh73I94/+0BtPbgE/INUIPvtBXg2luv16QWAPutYrDVXce u89YlcerY+ensQMgqpfWoOK6yxTOrGA9dfnYqHTCsvSAt/Gc58ugXtkgXonC+n1vCBRU EiTghQy4FzHsXDymGAAM8xGmdv/oa3oxKhRb+VaL+kwQ6hUxITiIss6SIwX865JuCFAW NEng== X-Received: by 10.68.178.1 with SMTP id cu1mr30305107pbc.45.1363198418891; Wed, 13 Mar 2013 11:13:38 -0700 (PDT) Received: from ?IPv6:2001:df8:0:8:a950:65d9:b202:f2ff? ([2001:df8:0:8:a950:65d9:b202:f2ff]) by mx.google.com with ESMTPS id mz8sm30617439pbc.9.2013.03.13.11.13.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 11:13:37 -0700 (PDT) Message-ID: <5140C1CF.3030809@mnt.se> Date: Wed, 13 Mar 2013 19:13:35 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnmB9JdgP8QIgEd+choDVF35hHEBx26ztz1ImJxMD89Ds4NcfcE4y3bKKdiDbKFKio8kc+N Subject: [saag] abfab @ ietf86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:13:40 -0000 ABFAB met this week. The WG resolved a few outstanding issues on the EAP applicability stmt which is blocking publication of the core documents. Leif & Klaas From kent@bbn.com Wed Mar 13 11:43:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C314321F8D9A for ; Wed, 13 Mar 2013 11:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lmWAOX1HRmv for ; Wed, 13 Mar 2013 11:43:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 451B621F8B47 for ; Wed, 13 Mar 2013 11:43:17 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39883 helo=dhcp107-16-217-98.hil-mcowdes.orl.wayport.net) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UFqdw-000GFz-1o for saag@ietf.org; Wed, 13 Mar 2013 14:43:16 -0400 Message-ID: <5140C8C3.5080607@bbn.com> Date: Wed, 13 Mar 2013 14:43:15 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: saag Content-Type: multipart/alternative; boundary="------------090306050403050406020706" Subject: [saag] PKIX meeting notes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:43:18 -0000 This is a multi-part message in MIME format. --------------090306050403050406020706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit PKIX met once, for 1.5 hours, on Tuesday, 3/12, at IETF 86. This was the last scheduled meeting of PKIX, and it drew about 49 attendees. Since Atlanta, two RFCs were published: the update to 5280 (RFC 6818), and DNS CAA (RFC 6844). One document is undergoing Sec AD review (2560bis), and there is only one remaining document active in the WG (EST). Max Pritikin provided a brief overview of the status of EST, highlighting changes in the -05 version, and noting planned changes for an -06 version. He hopes that the -06 version will be ready for WGLC soon. It was noted that there are two, independent, interoperable implementations of EST already, which caused Sean to suggest that the protocol might progress very rapdily to a full standard, under the new rules. Stefan Santesson reviewed his individual draft for an X.509 extension to help map Subject identities across administrative boundaries in a federated identity environment. This work is motivated by real problems encountered in the European environment. The extension carries XML-encoded data, to represent SAML assertions. --------------090306050403050406020706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit PKIX met once, for 1.5 hours, on Tuesday, 3/12, at IETF 86.

This was the last scheduled meeting of PKIX, and it drew about 49 attendees.

Since Atlanta, two RFCs were published: the update to 5280 (RFC 6818), and DNS CAA (RFC 6844).
One document is undergoing Sec AD review (2560bis), and there is only one remaining document
active in the WG (EST).


Max Pritikin provided a brief overview of the status of EST, highlighting changes in the
-05 version, and noting planned changes for an -06 version. He hopes that the -06 version will
be ready for WGLC soon. It was noted that there are two, independent, interoperable implementations
of EST already, which caused Sean to suggest that the protocol might progress very rapdily to
a full standard, under the new rules.

Stefan Santesson reviewed his individual draft for an X.509 extension to help map Subject
identities across administrative boundaries in a federated identity environment. This work
is motivated by real problems encountered in the European environment. The extension carries
XML-encoded data, to represent SAML assertions. --------------090306050403050406020706-- From jsalowey@cisco.com Wed Mar 13 12:54:07 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437B421F8DC9 for ; Wed, 13 Mar 2013 12:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FleJuFZWq3AZ for ; Wed, 13 Mar 2013 12:54:06 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DEE6411E80D9 for ; Wed, 13 Mar 2013 12:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=592; q=dns/txt; s=iport; t=1363204441; x=1364414041; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fvy+l1e5dvBIVcnBe+6fUzswhbd5Ch/L9waJFHBidOU=; b=gD9KRc/FPB5b94WUEumW6UMOOj/CYiXSeHwb4mhhS0SSuBGfIMuCJmW+ I482PF1HL9FCcIoUYyUTicW4zskc6zmnW1bThynla+36JGd4L9ijGjxrV JO6Av80OnbDmriDpXMZpM8Muo/cypzEx23t+16ryet7figIpgeiTeVrY1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEHYQFGtJV2Y/2dsb2JhbAA5CsRZgVkWbQeCLAEEOi0kASoUQicEG4gMogqhGReNUoEKgxdhA6dMgwqCKA X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="186934671" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 13 Mar 2013 19:54:00 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2DJs07W025054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Mar 2013 19:54:00 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 14:54:00 -0500 From: "Joseph Salowey (jsalowey)" To: "saag@ietf.org" Thread-Topic: Meeting Summary for EMU Thread-Index: AQHOICSBNErDc4pNREqYBvRcUZg9DA== Date: Wed, 13 Mar 2013 19:53:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] Meeting Summary for EMU X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:54:07 -0000 EMU met on Tuesday. We will be starting WGLC on the Mutual Crypto Binding = draft after a minor revision is submitted. The EAP tunnel method WGLC has = completed and open issues have been resolved. A revision is being prepared= for submission to the IESG within the next few weeks. We had discussion o= f what should go in certificates that identify EAP servers and EAP peers. = There was discussion of new EKUs and Subject Alt Name types. Since the w= orking group probably had its last meeting this topic will be carried on ou= tside the working group if it is needed. =20 From ietf@rozanak.com Wed Mar 13 13:12:54 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7811E80A5 for ; Wed, 13 Mar 2013 13:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3P77uMKsWXs for ; Wed, 13 Mar 2013 13:12:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9511E80D2 for ; Wed, 13 Mar 2013 13:12:53 -0700 (PDT) Received: from kopoli (dhcp-51ef.meeting.ietf.org [130.129.81.239]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0Lrd4v-1UjeoQ0sbV-012yr2; Wed, 13 Mar 2013 16:12:52 -0400 From: "Hosnieh Rafiee" To: Date: Wed, 13 Mar 2013 21:12:47 +0100 Message-ID: <003801ce2027$22fe7d40$68fb77c0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CE202F.84C3A890" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4gJx8ZTKA7SsLoQsGpiEBs465WgA== Content-Language: en-us X-Provags-ID: V02:K0:3LYy3BaJ4WkLH4WHnjjOQEh1HBqyZkEYdrPtCTcdzwQ hKhVJS6IkYrJG/KQMi6QSNBLchlfCrrPOqp+XhK5Md/Jxjj9M5 8K8FGZLCUWG1ZQU11Mam9tohPZS6xVhMI+9Duzx+EONODcDArX QYd/Sga3pqZvRHkri22al5WpGRUfGjmmm7gwE3+00b9LXhUhbg DfqJvttKrAZQjEXS9FmSayNrbPJzyrOrz+0f2qWaTB4vxToXBI Tkl3TS49MK6DfkchmYsrP+0xQnreAtVMhOMllDoOD1GF4c49Df vaktNaWBuLAGZV/4Eqaja0zZO06gvjD4ZQ3MnXezVy6gUD99io 5CTNLKOIRNcE1Oxv/L4w= Subject: [saag] use of algorithms in security X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:12:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0039_01CE202F.84C3A890 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I would like to get together with some people who deal with security, especially dealing with the use of ECC, RSA and those with a good knowledge of CGA. If you are attending the IETF meetings and would be willing to enlighten me, please send me an email so that we can set up a time and place to meet in person. Thank you, Hosnieh ------=_NextPart_000_0039_01CE202F.84C3A890 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I would like = to get together with some people who deal with security, especially = dealing with the use of ECC, RSA and those with a good knowledge of CGA. = If you are attending the IETF meetings and would be willing to enlighten = me, please send me an email so that we can set up a time and place to = meet in person.

 

Thank = you,

Hosnieh

------=_NextPart_000_0039_01CE202F.84C3A890-- From shanna@juniper.net Wed Mar 13 13:44:25 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3E11E80D9 for ; Wed, 13 Mar 2013 13:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkd8fWF48N+o for ; Wed, 13 Mar 2013 13:44:23 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 80EA311E80A3 for ; Wed, 13 Mar 2013 13:44:19 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUUDlIRRgpr4DCb9jN7FVhS/QqUe45Igb@postini.com; Wed, 13 Mar 2013 13:44:19 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 13 Mar 2013 13:41:15 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 13 Mar 2013 13:41:15 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 13 Mar 2013 13:43:50 -0700 Received: from mail37-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE015.bigfish.com (10.9.40.35) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Mar 2013 20:41:14 +0000 Received: from mail37-tx2 (localhost [127.0.0.1]) by mail37-tx2-R.bigfish.com (Postfix) with ESMTP id ABBFA400E6 for ; Wed, 13 Mar 2013 20:41:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT005.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: 6 X-BigFish: PS6(z36e9nzzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h) Received: from mail37-tx2 (localhost.localdomain [127.0.0.1]) by mail37-tx2 (MessageSwitch) id 1363207272890771_3519; Wed, 13 Mar 2013 20:41:12 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.228]) by mail37-tx2.bigfish.com (Postfix) with ESMTP id CAFFF3E0098 for ; Wed, 13 Mar 2013 20:41:12 +0000 (UTC) Received: from BY2PRD0510HT005.namprd05.prod.outlook.com (157.56.236.101) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Mar 2013 20:41:12 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.5.91]) by BY2PRD0510HT005.namprd05.prod.outlook.com ([10.255.84.40]) with mapi id 14.16.0275.006; Wed, 13 Mar 2013 20:41:09 +0000 From: Stephen Hanna To: "saag@ietf.org" Thread-Topic: saag summary for nea Thread-Index: AQHOICsXjTby4PkLzUKsRbTvcH2mSQ== Date: Wed, 13 Mar 2013 20:41:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [saag] saag summary for nea X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 20:44:25 -0000 The NEA working group did not meet at IETF 86. Last month, PT-TLS was published as RFC 6876. Our only remaining document is PT-EAP, which has passed IETF Last Call. We're working through IESG comments and expect to have it into the RFC Editor's queue fairly soon. Then it will sit for a bit waiting on a normative reference to TEAP. But our work will be done! From ynir@checkpoint.com Wed Mar 13 17:33:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0073B21F8C09 for ; Wed, 13 Mar 2013 17:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDCa7I4hKHM8 for ; Wed, 13 Mar 2013 17:33:17 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1BE21F8BE2 for ; Wed, 13 Mar 2013 17:33:16 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2E0XEow009959; Thu, 14 Mar 2013 02:33:14 +0200 X-CheckPoint: {514119F6-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.95]) with mapi id 14.02.0342.003; Thu, 14 Mar 2013 02:33:14 +0200 From: Yoav Nir To: "saag@ietf.org" Thread-Topic: HTTPAuth Summary for SAAG Thread-Index: AQHOIEuDlBmefmPoD0+Mpwu7uUdXCA== Date: Thu, 14 Mar 2013 00:33:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.156] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <4E6D8561ACF30A44BA6000F1E6ADBC7F@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Matthew Lepinski Subject: [saag] HTTPAuth Summary for SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 00:33:18 -0000 HTTPAuth met for the first time on Tuesday. As the proposed documents were presented in the BoF in Atlanta, we spent th= e time on discussing the ground rules for publishing experimental documents= .=20 We also found document editors for the standards-track BASIC and DIGEST aut= h documents (Thanks, Julian and PHB for volunteering). We will soon confirm= on the list that the group is willing to do work on the 5 candidate experi= mental documents.=20 Matt & Yoav= From paul.hoffman@vpnc.org Thu Mar 14 04:28:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 621FD21F8FB2 for ; Thu, 14 Mar 2013 04:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1AD0Z95IhUi for ; Thu, 14 Mar 2013 04:28:33 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id D830221F8F86 for ; Thu, 14 Mar 2013 04:28:32 -0700 (PDT) Received: from dhcp-4717.meeting.ietf.org (dhcp-4717.meeting.ietf.org [130.129.71.23]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r2EBSTHi087056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 14 Mar 2013 04:28:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <5978032F-7AE4-49BF-8600-A878ED371058@vpnc.org> Date: Thu, 14 Mar 2013 07:28:29 -0400 To: "saag@ietf.org Group" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [saag] IPSECME summary for IETF 86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 11:28:33 -0000 The IPsecME WG met on Tuesday and covered many topics. Our main = chartered work is auto-discovery VPNs, and the requirements document for = that has two outstanding clarifications that need to be covered on the = mailing list before we kick this back to our AD for IETF Last Call. We = will possibly drop the IKEv2-over-TCP document in favor of standardizing = what many vendors are doing now with fragmenting. We will probably be = adopting a few more short IKEv2 extensions and clarifications, and will = finish work on updating the AH and ESP cryptographic requirements. We = had a couple of short presentations on ideas that might feed into the AD = VPN protocol work. --Paul Hoffman= From kathleen.moriarty@emc.com Thu Mar 14 07:58:08 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F0711E8204 for ; Thu, 14 Mar 2013 07:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwK5NC5nev+8 for ; Thu, 14 Mar 2013 07:58:04 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43011E819F for ; Thu, 14 Mar 2013 07:58:03 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2EEw2uC000390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Mar 2013 10:58:02 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 14 Mar 2013 10:57:50 -0400 Received: from mxhub35.corp.emc.com (mxhub35.corp.emc.com [10.254.93.83]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2EEvoFU011845 for ; Thu, 14 Mar 2013 10:57:50 -0400 Received: from mx15a.corp.emc.com ([169.254.1.118]) by mxhub35.corp.emc.com ([::1]) with mapi; Thu, 14 Mar 2013 10:57:49 -0400 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Thu, 14 Mar 2013 10:57:37 -0400 Thread-Topic: MILE Meeting Summary Thread-Index: AQHOIMREQGpjrxORsEGFgaSPDDz5yw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5063677821E3B4F81ACFB7905573F24D79BE5F3MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [saag] MILE Meeting Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:58:08 -0000 --_002_F5063677821E3B4F81ACFB7905573F24D79BE5F3MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The MILE meeting summary is attached. Please let me know if you have any q= uestions. Best regards, Kathleen --_002_F5063677821E3B4F81ACFB7905573F24D79BE5F3MX15Acorpemccom_ Content-Type: text/plain; name="MILE-IETF86.txt" Content-Description: MILE-IETF86.txt Content-Disposition: attachment; filename="MILE-IETF86.txt"; size=1919; creation-date="Thu, 14 Mar 2013 14:57:45 GMT"; modification-date="Thu, 14 Mar 2013 14:57:45 GMT" Content-Transfer-Encoding: base64 TUlMRSBNZWV0aW5nIFN1bW1hcnkgLSBJRVRGIDg2IE9ybGFuZG8KV2VkbmVzZGF5LCBNYXJjaCAx MywgMjAxMywgMTM6MDAgRURUIChVVEMtNCkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0KClNlZSBzbGlkZXMgZm9yIGFsbCBhZ2VuZGEgaXRlbXM6IGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy84Ni9tYXRlcmlhbHMuaHRtbApNZWV0aW5nIG1pbnV0ZXMg aGF2ZSBiZWVuIHBvc3RlZC4KCk1JTEUgd2lsbCBiZSB1cGRhdGluZyB0aGUgY2hhcnRlciwgd2l0 aCBhbiBpbml0aWFsIHByb3Bvc2FsIHRvIGJlIHByb3ZpZGVkIGJ5IEZyaWRheSBvZiBuZXh0IHdl ZWsgdG8gaW5jbHVkZSBuZXcgd29yayBhbmQgc3RydWN0dXJlIHRoZSBzY29wZS9kZWZpbml0b24g b2YgdGhhdCB3b3JrLgoKV0cgZHJhZnRzIHdlcmUgcmV2aWV3ZWQsIHRoZSBTQ0kgZHJhZnQgaXMg bmVhciBjb21wbGV0aW9uLiAgQU4gTVRJIHdhcyBzZWxlY3RlZCBhcyBhbiBleHRlbnNpb24gdG8g SU9ERUYgdmlhIHRoZSBTQ0kgZHJhZnQgbWV0aG9kLiAgVGhlIE1USSBsZXQncyB5b3UgZXhjaGFu Z2UgbWFsd2FyZSBzYW1wbGVzIGluIElPREVGIHVzaW5nIE1NREVGLCB3aGljaCBpcyBjdXJyZW50 bHkgaW4gdXNlIGJ5IHRoZSBlQ3JpbWUgV0cgd2l0aCBJT0RFRi4gIFBvbGwgaGFzIHN0YXJ0ZWQg dG8gY29uZmlybSB0aGUgdm90ZSBvbiBsaXN0LgoKU2V2ZXJhbCBkcmFmdHMgdW5kZXIgY29uc2lk ZXJhdGlvbiB3ZXJlIHJldmlld2VkOgpSRkM1MDcwLWJpczogUm9tYW4gYW5kIFBhdWwgcHJlc2Vu dGVkIHRoZSB1cGRhdGVzLCB3aXRoIGEgZm9jdXMgb24gZ2V0dGluZyBjb25zZW5zdXMgb24gaG93 IHRoZSBkcmFmdCBzaG91bGQgYmUgc3RydWN0dXJlZCBnb2luZyBmb3J3YXJkIGluIHRoaXMgaXRl cmF0aW9uLiAgQ29uc2lkZXJhdGlvbnMgaW5jbHVkZSB3aGF0IHByb2JsZW1zIHdpbGwgYmUgc29s dmVkIGZvciB0aGlzIHJldmlzaW9uIGFuZCB3aGF0IGlzIHRoZSBsaW5lIGJldHdlZW4gd2hhdCBi ZWxvbmdzIGluIFJGQzUwNzAtYmlzIHZlcnN1cyB3aGF0IHNob3VsZCBiZSBpbiBhbiBleHRlbnNp b24uICBJcyBpdCBqdXN0IHRoZSBjb21tb25seSBzaGFyZWQgZGF0YSwgYW5kIGlmIHNvLCB3aGF0 IGlzIHRoYXQgZGF0YT8gIFF1ZXN0aW9ucyBhbmQgZGlzY3Vzc2lvbnMgZnJvbSB0aGUgbGlzdCB3 ZXJlIHJldmlld2VkIGFuZCB3aWxsIGNvbnRpbnVlIG9uIHRoZSBsaXN0IHRvIGdldCB3aWRlciBw YXJ0aWNpcGF0aW9uIHRvIGd1aWRlIHRoZSBkcmFmdCBkaXJlY3Rpb24uICBOZXcgY29uc2lkZXJh dGlvbnMgZm9yIGV4dGVuc2lvbnMgd2VyZSBkaXNjdXNzZWQsIHN1Y2ggYXMgc3VwcG9ydCBmb3Ig U01TIGFuZCBjYWxsZXIgSUQgYWJ1c2UuCgpST0xJRSBhbmQgdGhlIGVudW1lcmF0aW9uIGRyYWZ0 cyBhbmQgZGlzY3Vzc2VkIGFuZCB3aWxsIGJlIGluY2x1ZGVkIGluIGNoYXJ0ZXIgdXBkYXRlLiAg CgpSZXZpZXdzIGFuZCBjb21tZW50cyB3ZWxjb21lIGFuZCBlbmNvdXJhZ2VkIG9uIGFsbCBkb2N1 bWVudHMuCgpNdXJyYXkgbGVkIGEgZGlzY3Vzc2lvbiBvbiBpbmNsdWRpbmcgQVJGIGluIElPREVG LiAgVGhlIGlkZWEgaGVyZSBpcyB0byByZS11c2Ugd2hhdCBoYXMgYmVlbiBjcmVhdGVkIGFuZCBp cyBtYWludGFpbmVkIGJ5IHRoZSBtYWlsIGFidXNlIGNvbW11bml0eS4gIFRoaXMgd291bGQgZW5h YmxlIGEgc2VjdXJpdHkgb3IgQ0lSVCB0ZWFtIHJlY2VpdmluZyB0aGUgaW5mb3JtYXRpb24gdG8g YmUgYWJsZSB0byBmb3J3YXJkIHRoZSBkYXRhIHRvIHRoZSBtYWlsIGFidXNlIHRlYW0gaW4gYSBm b3JtYXQgdGhleSB1c2UgYWZ0ZXIgZXh0cmFjdGluZyB0aGUgQVJGIGluZm9ybWF0aW9uIGZyb20g dGhlIG92ZXJhbGwgY29udGV4dCBkYXRhIGZyb20gSU9ERUYuCgo= --_002_F5063677821E3B4F81ACFB7905573F24D79BE5F3MX15Acorpemccom_-- From bew@cisco.com Thu Mar 14 08:06:27 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CCE711E8259 for ; Thu, 14 Mar 2013 08:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsFBW0z0HvYd for ; Thu, 14 Mar 2013 08:06:15 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCA11E8243 for ; Thu, 14 Mar 2013 08:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=582; q=dns/txt; s=iport; t=1363273541; x=1364483141; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=Irm4VjnttLjb1WMlberX1uPvFUkwFiMPQOYVGCehhIQ=; b=lcptUU9T59gdinyvZ2RHSX5rmv7ymxUUC2zUTquEmVUq2AqH7BlSW09f j7hTWYdtVrVXQGLVKGfa6GWy+pIGxtSXQr4ZYVU1M5/Zg2HYHksZkNN/Y xXTxIbA6oJuVWSbPVV8rPVazue59E04vyVaD36fDK//WRJQRY4nu2lScH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAALmQVGrRDoH/2dsb2JhbABExloWbQeCa4F9iCagEKEnkXZhA5ZYhX2LBYMmIA X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="75403764" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 14 Mar 2013 15:05:41 +0000 Received: from [10.21.118.176] ([10.21.118.176]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2EF5eQb019524 for ; Thu, 14 Mar 2013 15:05:41 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <575B35A2-0C31-437B-8B1C-5C75F4930ADC@cisco.com> Date: Thu, 14 Mar 2013 11:00:53 -0400 To: "saag@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [saag] IETF 86 KARP Summary for SAAG X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:06:27 -0000 The KARP Routing Area WG is analyzing transport-level security and = describing key management methods for routing protocols. We met Tuesday = afternoon. This meeting we had two presentations of core KARP documents: = Key Tables and Operational Model. The former has completed WGLC and will = be forwarded to our AD soon; the latter will have a WGLC consensus call = soon. Acee Lindem then updated us on current work in the OSPF group = addressing gaps documented in the OSPF security analysis. We concluded = with 2 key management presentations related to individual I-Ds. From odonoghue@isoc.org Thu Mar 14 09:11:42 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26ECC11E810D for ; Thu, 14 Mar 2013 09:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1hIhgGsiRwV for ; Thu, 14 Mar 2013 09:11:38 -0700 (PDT) Received: from smtp128.ord.emailsrvr.com (smtp128.ord.emailsrvr.com [173.203.6.128]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17511E8267 for ; Thu, 14 Mar 2013 09:11:38 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id AD128198180 for ; Thu, 14 Mar 2013 12:11:37 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 7D5B9198117 for ; Thu, 14 Mar 2013 12:11:37 -0400 (EDT) Message-ID: <5141F6BB.3080106@isoc.org> Date: Thu, 14 Mar 2013 12:11:39 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: saag@ietf.org References: <5141F506.5000900@isoc.org> In-Reply-To: <5141F506.5000900@isoc.org> X-Forwarded-Message-Id: <5141F506.5000900@isoc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] JOSE WG summary for IETF86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:11:42 -0000 The JOSE WG met on Wednesday at 9:00 am EST. The four core documents (JWA, JWE, JWK, and JWS) were all updated and discussed as a set. The remaining open issues were discussed and either closed or definitive steps identified to resolve them. Updated drafts are expected in the near future with one more round of updates addressing the remaining issues expected prior to WGLC. In addition, drafts on use cases, JSON serialization, JSON Private and Symmetric keys were adopted pending approval of the updated charter. Drafts on using JSON to protect keys and a JSON Web Key for PKIX certs were discussed, and a presentation on a unified view for keys was discussed. An updated charter has been forwarded to the AD for IESG review/approval. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From turners@ieca.com Thu Mar 14 09:21:16 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D1611E80BF for ; Thu, 14 Mar 2013 09:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnxxnT0wtMyM for ; Thu, 14 Mar 2013 09:21:16 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.243.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3526E21F8DDD for ; Thu, 14 Mar 2013 09:21:16 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id B95249B106E56; Thu, 14 Mar 2013 11:20:54 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 8B44B9B106DA5 for ; Thu, 14 Mar 2013 11:20:54 -0500 (CDT) Received: from [130.129.84.34] (port=56350 helo=dhcp-5422.meeting.ietf.org) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGAu3-0002SV-Jj for saag@ietf.org; Thu, 14 Mar 2013 11:21:15 -0500 Message-ID: <5141F8FC.3020501@ieca.com> Date: Thu, 14 Mar 2013 12:21:16 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (dhcp-5422.meeting.ietf.org) [130.129.84.34]:56350 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] IETF 86 Slides Up X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:21:16 -0000 We've got the slides up for this afternoon's session: https://datatracker.ietf.org/meeting/86/materials.html#wg-saag spt From derek@ihtfp.com Thu Mar 14 10:09:43 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C447011E8126 for ; Thu, 14 Mar 2013 10:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGU9aWc2oYdI for ; Thu, 14 Mar 2013 10:09:43 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFCD21F8CD1 for ; Thu, 14 Mar 2013 10:09:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 36DC32602CF for ; Thu, 14 Mar 2013 13:09:42 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 14358-07 for ; Thu, 14 Mar 2013 13:09:37 -0400 (EDT) Received: from mocana.ihtfp.org (dhcp-430e.meeting.ietf.org [130.129.67.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 2365B26002A for ; Thu, 14 Mar 2013 13:09:37 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id r2EH9Yrt003035; Thu, 14 Mar 2013 13:09:34 -0400 From: Derek Atkins To: saag@ietf.org Date: Thu, 14 Mar 2013 13:09:33 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Subject: [saag] OAUTH summary (part 1) at IETF-86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:09:43 -0000 OAUTH met on Monday for its first session of the week; we meet again right after SAAG. We've updated our milestones based on completed documents and expectations for future document completion. The first discussion was about the fact that OAUTH has been creating frameworks instead of protocols, and the IESG has felt there has not been enough detail to have interoperable implementations. This led directly into a discussion of the assertion framework and the SAML tokens, and what can be done to improve the situation (e.g. addition defintions of how to compare fields). Next we discussed the Dynamic Registration protocol, but the document requires more changes and is not ready for WGLC. Last discussion was about testing. This brought us back to the implementation details. There was a point made about RFC2119 as conformance vs protocol definitions and how to use that in a test plan, but in the end all were agreed that Roland is doing it right. There is an open question about whether we can hold an Interop versus setting up an online test suite. More discussion will happen today after SAAG when we plan to discuss JWT and the security requirements. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From jsalowey@cisco.com Thu Mar 14 10:18:39 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963D321F8B18 for ; Thu, 14 Mar 2013 10:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMCIsXDZz7eL for ; Thu, 14 Mar 2013 10:18:38 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CBF7E21F8995 for ; Thu, 14 Mar 2013 10:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=355; q=dns/txt; s=iport; t=1363281518; x=1364491118; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=YcAEGBWO8L2QZtrEP17F5ijzuX0Dk35PneTnlGRFcyE=; b=QuNjSynCrq5wHnjETP32Bm5a+DYKtr4HukpWqJhx4AeLl2O/Ozy119gd l62AYB/TPYDBUC9B0yLEvmvMSm7XqoRF+/Xyd353LmvJVBVJStJjPJuJv 45KAp4gpsT265A1mhUQw1RtbIbz7lY1qFrKrOSPH411Ng1Wlr9R6ExbY1 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAYGQlGtJV2Y/2dsb2JhbABDxQGBZRZtB4ItAQQ6UQEqFEInBBuIDKBqoSqOZYMXYQOnWoMKgig X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="scan'208";a="187532440" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 14 Mar 2013 17:18:38 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2EHIctW028171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 17:18:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 12:18:38 -0500 From: "Joseph Salowey (jsalowey)" To: "saag@ietf.org" Thread-Topic: TLS Meeting Preview Thread-Index: AQHOINf2dbe1iCp+V0abDyc8rHuz3g== Date: Thu, 14 Mar 2013 17:18:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.223.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <18632EF9271D5A4684501FDBC1B0D8F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] TLS Meeting Preview X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:18:39 -0000 TLS will meet on Friday afternoon. The main topic of discussion will be th= e negotiation of application layer protocol using TLS extensions (NPN/ALPN)= . We will also work on progressing the cached information draft. Time p= ermitting, we will have some presentations on the use of DTCP certificates = and TLS over LLCP. =20 Thanks, Joe= From shawn.emery@oracle.com Thu Mar 14 11:06:05 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E0D11E8158 for ; Thu, 14 Mar 2013 11:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umyAZbC4wAzq for ; Thu, 14 Mar 2013 11:06:05 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE311E814C for ; Thu, 14 Mar 2013 11:06:05 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2EI64Ti021401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 14 Mar 2013 18:06:04 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EI637f020479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 14 Mar 2013 18:06:04 GMT Received: from abhmt114.oracle.com (abhmt114.oracle.com [141.146.116.66]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EI63u2016679 for ; Thu, 14 Mar 2013 13:06:03 -0500 Received: from dhcp-13ad.meeting.ietf.org (/130.129.19.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 11:06:03 -0700 Message-ID: <5142118B.60100@oracle.com> Date: Thu, 14 Mar 2013 12:06:03 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: saag@ietf.org References: <51420230.2010106@oracle.com> In-Reply-To: <51420230.2010106@oracle.com> X-Forwarded-Message-Id: <51420230.2010106@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [saag] Kitten Summary - IETF 86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:06:05 -0000 Co-chairs Attending: Sam Hartman and Shawn Emery The WG met for the morning session on Thursday (3.14.13). kitten and Krb-wg merger ------------------------ New charter has been approved. Krb-wg members have been migrated to the kitten list. Updated drafts should be prefixed with draft-kitten-*. draft-ietf-kitten-gssapi-extensions-iana ---------------------------------------- Leif had feed-back. Chairs will send through another WGLC to get more reviewers. An initial registry was suggested to provide guidance. draft-ietf-kitten-sasl-saml-ec ------------------------------ Update was made with simplified session key schema, random-to-key moved to endpoints, and advertisement of session key and enc types by acceptor. draft-ietf-krb-wg-kdc-model --------------------------- In RFC editor queue. Was needing updates based on RFC editor comments/questions. draft-ietf-krb-wg-pkinit-alg-agility ------------------------------------ RFC 3766 and RFC 6194 should be informative. Error code 82 conflict should be reassigned. Deployed code but impact unlikely. draft-ietf-krb-wg-kerberos-referrals ------------------------------------ Now RFC 6806. draft-sakane-dhc-dhcpv6-kdc-option ---------------------------------- Now RFC 6784. draft-ietf-krb-wg-camellia-cts ------------------------------ Now RFC 6803. draft-ietf-kitten-sasl-oauth ---------------------------- Jeff Hutzelman had made WGLC comments that entail an GSS-API abstract violation due to the use of the mutual authentication state to indicate that the application, not the mechanism has performed mutual authentication. The other two SASL mechanisms, OpenID and SAML, have similar issues. It was decided that there should be an interim meeting to discuss whether we update GS2 to provision for these mechanism types or do we remove the GS2 capabilities of these SASL mechanisms. draft-ietf-kitten-kerberos-iana-registries ------------------------------------------ New revision was made that specifies registry fields. Consensus during the session was made to NOT create registries for: Application tag numbers Transited encoding types New Drafts Proposed ------------------- draft-williams-kitten-channel-bound-flag Would not require a recharter as it corrects an existing issue with channel binding. draft-williams-kitten-krb5-extra-rt Would require a recharter. draft-williams-kitten-krb5-rcache-avoidance Already in the current charter. draft-yu-kitten-kerberos-kdc-does-aliases Would require a recharter. There wasn't enough review of the above drafts by members in the room to make a call to adopt the relevant drafts in the WG. Open Mic -------- No one came forward. GSS-Profile ----------- Sam had commented on this draft as being useful in simplifying the GSS-API. There were not enough reviewers in the room to make a call for adoption. Unfortunately a charter item (i.e. draft-yu-kitten-api-wishlist) similar to this was previously removed due to lack of feed-back or interest. Shawn. -- kitten co-chair From nico@cryptonector.com Thu Mar 14 11:18:07 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E39911E81C0 for ; Thu, 14 Mar 2013 11:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPwWlbKxdmA8 for ; Thu, 14 Mar 2013 11:18:07 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6B82111E80E9 for ; Thu, 14 Mar 2013 11:18:06 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 2CCD4BC049 for ; Thu, 14 Mar 2013 11:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dGIy32zgO027fGevlDSw t/24PFk=; b=n5c/HySCwSCZyw/9TSrCB7ndYwpZRY8s8CEa32pvPo/CmeYNNI8c 8INzeUsFyGp/8OzoRmlAk3JdjYSAgyD9MOefvwXs5qERpaAd8Upebbp1Q2LhUnuU fvVWG2UO0tN6y2qeBaAi6FyCf09FO6hRS3oUseOl5LJFA8axEQGE3XA= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 17408BC047 for ; Thu, 14 Mar 2013 11:18:06 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id bn7so3351561ieb.25 for ; Thu, 14 Mar 2013 11:18:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.181.201 with SMTP id dy9mr3193637igc.18.1363285085536; Thu, 14 Mar 2013 11:18:05 -0700 (PDT) Received: by 10.64.252.106 with HTTP; Thu, 14 Mar 2013 11:18:05 -0700 (PDT) In-Reply-To: <5142118B.60100@oracle.com> References: <51420230.2010106@oracle.com> <5142118B.60100@oracle.com> Date: Thu, 14 Mar 2013 13:18:05 -0500 Message-ID: From: Nico Williams To: Shawn M Emery Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] Kitten Summary - IETF 86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:18:07 -0000 On Thu, Mar 14, 2013 at 1:06 PM, Shawn M Emery wrote: > The WG met for the morning session on Thursday (3.14.13). Sorry I could not attend. > draft-ietf-kitten-sasl-oauth > ---------------------------- > Jeff Hutzelman had made WGLC comments that entail an GSS-API abstract > violation due to the > use of the mutual authentication state to indicate that the application, not > the mechanism > has performed mutual authentication. The other two SASL mechanisms, OpenID > and SAML, > have similar issues. It was decided that there should be an interim meeting > to discuss > whether we update GS2 to provision for these mechanism types or do we remove > the GS2 > capabilities of these SASL mechanisms. Basically, any mechanism that does not do mutual auth could still be used with GS2 if we relax the mutual auth requirement there, but we must not allow such mechanisms to be advertised as -PLUS mechanisms. > draft-williams-kitten-krb5-extra-rt > Would require a recharter. Some of it relates to rcache avoidance, FYI, which is in charter. Mind you, I think we should modify the charter. Also, if mechanism work is in charter then I'd think that maintenance/extensions work on existing mechanisms should be as well. If that's not already clearly stated in the charter, then we should make it so. > draft-williams-kitten-krb5-rcache-avoidance > Already in the current charter. > > draft-yu-kitten-kerberos-kdc-does-aliases > Would require a recharter. I support modifying the charter so we can adopt this I-D (as well as, unsurprisingly, mine). > Open Mic > -------- > No one came forward. FYI, Nathan McCallum has convinced me to specify a subset of the verto API (which is quite simple) for async GSS. > GSS-Profile > ----------- > Sam had commented on this draft as being useful in simplifying the GSS-API. > There were > not enough reviewers in the room to make a call for adoption. Unfortunately > a charter item > (i.e. draft-yu-kitten-api-wishlist) similar to this was previously removed > due to lack of > feed-back or interest. Which I-D was this? draft-williams-gss-profiles? Nico -- From kathleen.moriarty@emc.com Thu Mar 14 11:38:39 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C6021F910B for ; Thu, 14 Mar 2013 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4hgrpTvSjIl for ; Thu, 14 Mar 2013 11:38:38 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 341B021F910A for ; Thu, 14 Mar 2013 11:38:37 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2EIcYog002221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 14:38:35 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 14 Mar 2013 14:38:20 -0400 Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2EIcKem009729; Thu, 14 Mar 2013 14:38:20 -0400 Received: from mx15a.corp.emc.com ([169.254.1.118]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Thu, 14 Mar 2013 14:38:20 -0400 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Thu, 14 Mar 2013 14:37:53 -0400 Thread-Topic: SACM Meeting Summary Thread-Index: AQHOIOMJehVByckRTk+TE9CiyBb/2w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_F5063677821E3B4F81ACFB7905573F24D79BE5FAMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "dromasca@avaya.com" Subject: [saag] SACM Meeting Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:38:39 -0000 --_002_F5063677821E3B4F81ACFB7905573F24D79BE5FAMX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The SACM Meeting Summary is attached. Please let me know if you have any questions. Best regards, Kathleen= --_002_F5063677821E3B4F81ACFB7905573F24D79BE5FAMX15Acorpemccom_ Content-Type: text/plain; name="SACM-IETF86.txt" Content-Description: SACM-IETF86.txt Content-Disposition: attachment; filename="SACM-IETF86.txt"; size=1121; creation-date="Thu, 14 Mar 2013 18:38:12 GMT"; modification-date="Thu, 14 Mar 2013 18:38:12 GMT" Content-Transfer-Encoding: base64 U0FDTSBNZWV0aW5nIFN1bW1hcnkgLSBJRVRGIDg2IE9ybGFuZG8KVGh1cnNkYXksIE1hcmNoIDE0 LCAyMDEzLCAxMzowMCBFRFQgKFVUQy00KQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQoKU2VlIHNsaWRlcyBmb3IgYWxsIGFnZW5kYSBpdGVtczogaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9tZWV0aW5nLzg2L21hdGVyaWFscy5odG1sCgpUaGlzIGlzIHRoZSBzZWNv bmQgYW5kIGZpbmFsIFNBQ00gQm9GLCB3aXRoIGEgZm9jdXMgb24gdGhlIGNoYXJ0ZXIgcmV2aWV3 IGFuZCB0b3VnaCBxdWVzdGlvbnMuCiAgCkFkYW0gTW9udHZpbGxlIHByZXNlbnRlZCB0aGUgU0FD TSB1c2UgY2FzZSBkb2N1bWVudCBhbmQgRGF2ZSBXYWx0ZXJtaXJlIHByZXNlbnRlZCB0aGUgcHJv cG9zZWQgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LgpRVWVzdGlvbnMgb24gc2NvcGUgaW5jbHVkZWQg d2hldGhlciBvciBub3QgdGhlIHdvcmsgd291bGQgZXh0ZW5kIGJleW9uZCBkZXNrdG9wcyB0byBp bmNsdWRlIGRldmljZXMuICBXaGF0IHR5cGVzIG9mIHNlbnNvcnMgc2hvdWxkIGJlIGluY2x1ZGVk IGluIHRoZSBzY29wZSwgaXMgaXQganVzdCB0aGUgc3RhdGUgb2YgdGhlIHNlbnNvciBpdHNlbGY/ ICBCZWhhdmlvciBpcyBhc3Nlc3NlZCBvdmVyIGEgcGVyaW9kIG9mIHRpbWUgYW5kIGV4cGFuZHMg dGhlIHNjb3BlIChkaWZmZXJlbnQgdHlwZXMgb2YgYmVoYXZpb3IgZGlzY3Vzc2VkKS4gIFZpcnR1 YWwgbWFjaGluZXMgYXJlIGluIHNjb3BlLgoKVGhlcmUgd2VyZSBubyBjb250cmlidXRpb25zIG9u IHNvbHV0aW9ucyBzaW5jZSB0aGUgbGFzdCBtZWV0aW5nIChzb21lIHdlcmUgcHJlc2VudGVkIGF0 IHRoZSBmaXJzdCBCb0YgaW4gQXRsYW50YSkuCgpUaGUgY2hhcnRlciBhbmQgc2NvcGUgd2FzIHJl dmlld2VkLiAgRGlzY3Vzc2lvbiBmb2N1c2VkIG9uIHNjb3BlLgpFZGl0cyBhbmQgc2NvcGUgYWRq dXN0bWVudHMgd2VyZSBzdWdnZXN0ZWQuICBUaGUgaHVtIHdhcyBwb3NpdGl2ZSBmb3IgdGhlIGNo YXJ0ZXIgYW5kIHNjb3BlIHdpdGggYWRqdXN0bWVudHMgc3VnZ2VzdGVkLgoxMyBwZW9wbGUgdm9s dW50ZWVyZWQgdG8gYWN0aXZlbHkgY29udHJpYnV0ZSB3b3JrLgo= --_002_F5063677821E3B4F81ACFB7905573F24D79BE5FAMX15Acorpemccom_-- From shawn.emery@oracle.com Thu Mar 14 12:31:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC6511E81C9 for ; Thu, 14 Mar 2013 12:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RirQPyN4Qw1G for ; Thu, 14 Mar 2013 12:31:58 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1411E80BF for ; Thu, 14 Mar 2013 12:31:58 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2EJVu03017790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Mar 2013 19:31:56 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2EJVtrT017624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Mar 2013 19:31:56 GMT Received: from abhmt119.oracle.com (abhmt119.oracle.com [141.146.116.71]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2EJVtb9014666; Thu, 14 Mar 2013 14:31:55 -0500 Received: from dhcp-13ad.meeting.ietf.org (/130.129.19.173) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Mar 2013 12:31:55 -0700 Message-ID: <514225A1.3010909@oracle.com> Date: Thu, 14 Mar 2013 13:31:45 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nico Williams References: <51420230.2010106@oracle.com> <5142118B.60100@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: saag@ietf.org Subject: Re: [saag] Kitten Summary - IETF 86 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 19:31:58 -0000 On 3/14/13 12:18 PM, Nico Williams wrote: > On Thu, Mar 14, 2013 at 1:06 PM, Shawn M Emery wrote: >> The WG met for the morning session on Thursday (3.14.13). > <...> >> GSS-Profile >> ----------- >> Sam had commented on this draft as being useful in simplifying the GSS-API. >> There were >> not enough reviewers in the room to make a call for adoption. Unfortunately >> a charter item >> (i.e. draft-yu-kitten-api-wishlist) similar to this was previously removed >> due to lack of >> feed-back or interest. > Which I-D was this? draft-williams-gss-profiles? Yes, that was meant to be plural. Shawn. -- From Jeff.Hodges@KingsMountain.com Thu Mar 14 13:49:19 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348AC11E81D7 for ; Thu, 14 Mar 2013 13:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.632 X-Spam-Level: X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvunaG++aMic for ; Thu, 14 Mar 2013 13:49:18 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 8BDA411E819E for ; Thu, 14 Mar 2013 13:49:18 -0700 (PDT) Received: (qmail 7073 invoked by uid 0); 14 Mar 2013 20:48:57 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy13.unifiedlayer.com with SMTP; 14 Mar 2013 20:48:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=MVAwhDh4ljPS5pNmDf0auwid2fvUchvLGIjdPMzHAWY=; b=wj2l0ALZDTF25OL3HVxBzQkTqHHf52AqhzYZyWPjzDOjioo7Lvct1CHF/5154sP1U3wXH/WoRdmxr2a4Kx4vo5p0gitJOSBGgnOUB5I9AoAE5B4WlXkPED6uuU61RmMd; Received: from [130.129.19.55] (port=41576) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGF56-0006on-Ve for saag@ietf.org; Thu, 14 Mar 2013 14:48:57 -0600 Message-ID: <514237B7.9070905@KingsMountain.com> Date: Thu, 14 Mar 2013 13:48:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.19.55 authed with jeff.hodges+kingsmountain.com} Subject: [saag] Off-the-Record (OTR) Messaging Protocol version 2 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:49:19 -0000 Off-the-Record Messaging Protocol version 2 http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html From Jeff.Hodges@KingsMountain.com Thu Mar 14 13:51:22 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8625F11E81F5 for ; Thu, 14 Mar 2013 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXaOYuKCMQ8h for ; Thu, 14 Mar 2013 13:51:22 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id ECFA511E81F4 for ; Thu, 14 Mar 2013 13:51:21 -0700 (PDT) Received: (qmail 10583 invoked by uid 0); 14 Mar 2013 20:51:00 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 14 Mar 2013 20:51:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=jxVzUE5D4ZQzEmm5UcZ2fZGQyeCu1IDdBf4C0zz/EcQ=; b=KMSSQ70BmJaQwU6f2uO3LRcJFwx0++DV8ccY7K47izZhYmJVjVhD+J9MpgvcsTstZK8Rum5HNHnOPJmG9GUefyVQqDrOiv0WscN39MKi3Xttrv/8s6usAYUUDp4Mijhj; Received: from [130.129.19.55] (port=41603) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGF76-0001HW-J9 for saag@ietf.org; Thu, 14 Mar 2013 14:51:00 -0600 Message-ID: <51423833.1040501@KingsMountain.com> Date: Thu, 14 Mar 2013 13:50:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.19.55 authed with jeff.hodges+kingsmountain.com} Subject: [saag] Off-the-Record (OTR) Messaging Protocol version 3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:51:22 -0000 Off-the-Record Messaging Protocol version 3 http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html overall OTR project website: http://www.cypherpunks.ca/otr/ From ietf@rozanak.com Sat Mar 16 06:27:38 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6920721F8BCC; Sat, 16 Mar 2013 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3Eod3Zy0a4d; Sat, 16 Mar 2013 06:27:36 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A7EEB21F8BC5; Sat, 16 Mar 2013 06:27:36 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LaXZ9-1V0tKE40WF-00luVX; Sat, 16 Mar 2013 09:27:33 -0400 From: "Hosnieh Rafiee" To: , Date: Sat, 16 Mar 2013 14:27:20 +0100 Message-ID: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CE2252.63CA2D60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7g== Content-Language: en-us X-Provags-ID: V02:K0:0HWorsMdenrQCIvtzrIuQuT5W1uj6ZPb8s9u9AsvJjY /qt0Ebq4YUGorqefCGKYZAcjxjwRMcoL1iLYPXfWvPPtka8jAF TXtQaXIBlcx1NHZ9g3jIl26Dd1/eggZxFCHcup0Ez29TTvtXHD N0xpuhizT4FsSgvdMOWLHWNBKbjDRFybC8KA7O/UsZkKJzTEYT YQmOIT4wrldQs7kyJj4q+Xc/x2qMlI2cSfqdDUIAfjdvCfcExr wACUcPaZMcslwNdtbwWM3tIMrJdGVneTjlaUc/JI4KOgE6Femt wnM7NtdVgELRs7BBF9loYpNS9yyp7o4IIERPACtwXdfX2votaN Yrw4u2Vi30m1m+GMW82I= Cc: Erik Nordmark , alexandru.petrescu@gmail.com, Ray Hunter Subject: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 13:27:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CE2252.63CA2D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_0042_01CE2252.63CA2D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_0042_01CE2252.63CA2D60-- From turners@ieca.com Sat Mar 16 07:48:21 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4952721F89B2 for ; Sat, 16 Mar 2013 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.659 X-Spam-Level: X-Spam-Status: No, score=-101.659 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgG4swk+HCqS for ; Sat, 16 Mar 2013 07:48:20 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.137.88]) by ietfa.amsl.com (Postfix) with ESMTP id CF7F721F89E9 for ; Sat, 16 Mar 2013 07:48:20 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 261E189C7CAA8; Sat, 16 Mar 2013 09:47:57 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 170C689C7CA74 for ; Sat, 16 Mar 2013 09:47:57 -0500 (CDT) Received: from [198.180.150.142] (port=51011 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UGsPD-0006Vf-Tl; Sat, 16 Mar 2013 09:48:20 -0500 Message-ID: <51448633.2060303@ieca.com> Date: Sat, 16 Mar 2013 10:48:19 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: saag@ietf.org, cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [198.180.150.142]:51011 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [saag] Looking for an HOTP expert X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 14:48:21 -0000 I'd like some help resolving three errata on RFC 4226. If you think you can help please send me a private email. spt From huitema@microsoft.com Sat Mar 16 09:41:36 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D5521F88D1; Sat, 16 Mar 2013 09:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us6SBOUrsiNE; Sat, 16 Mar 2013 09:41:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0204.outbound.protection.outlook.com [207.46.163.204]) by ietfa.amsl.com (Postfix) with ESMTP id A2F5F21F88CC; Sat, 16 Mar 2013 09:41:33 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.161.202) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 16:37:17 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 16:37:17 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 16:36:34 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5Q Date: Sat, 16 Mar 2013 16:36:33 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> In-Reply-To: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF839TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(69226001)(59766001)(5343635001)(50986001)(55846006)(5343655001)(15202345001)(512954001)(76482001)(51856001)(56816002)(47976001)(65816001)(63696002)(47736001)(44976002)(20776003)(53806001)(74662001)(54356001)(33656001)(80022001)(49866001)(46102001)(66066001)(54316002)(16236675001)(79102001)(77982001)(56776001)(31966008)(74502001)(16406001)(4396001)(47446002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 Cc: Ray Hunter , Erik Nordmark , "alexandru.petrescu@gmail.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 16:41:36 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF839TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hos= nieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF839TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF839TK5EX14MBXC273r_-- From ietf@rozanak.com Sat Mar 16 10:59:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5509721F88BF; Sat, 16 Mar 2013 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQG+eDhFa3uH; Sat, 16 Mar 2013 10:59:54 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B963D21F88B9; Sat, 16 Mar 2013 10:59:54 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Lx8eP-1Uo5Nf3bZ3-016JMo; Sat, 16 Mar 2013 13:59:45 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> In-Reply-To: Date: Sat, 16 Mar 2013 18:59:29 +0100 Message-ID: <000901ce2270$08250b10$186f2130$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CE2278.69EAF9B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZmIQionA= Content-Language: en-us X-Provags-ID: V02:K0:gTNLtWxDdiqmmGZVPZqh9zUj4vc860dcMPwhncjKBLK MHBx6vkKPm9vNSFPg0qtaN1okNXMqGDZtm6f4zMKXwRswKtbbx xRNbtBPJPnOME54A8IVrKoRmLnb4vj3722EoS4SUZkruTjR9rd eHZZ+VtHuvbPsSCvZikJcmljnMlhL8atvs30o/tATf/EAeAAuP 7dCbsi9O2Sidly8/UZIUjGOHljENehRryOKmD2/TJ1tYCwFQV6 DD0Z6NU7E9lKTal3FDGEmX/JM5TVYj+jpLGsgbIyeV7902jMct 4iY+WaHOpUTNBzGgrViDOvBqC7JS798ppek4q8fs2lo9fHZif3 sEHXCGSn2OQw1910KG+Q= Cc: alexandru.petrescu@gmail.com, "Roque Gagliano \(rogaglia\)" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 17:59:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CE2278.69EAF9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_000A_01CE2278.69EAF9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

=

>Did you somehow crack = RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

=

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; = alexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_000A_01CE2278.69EAF9B0-- From huitema@microsoft.com Sat Mar 16 11:30:22 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C9521F888B; Sat, 16 Mar 2013 11:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xd00kYc+ZSFe; Sat, 16 Mar 2013 11:30:18 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5C121F8628; Sat, 16 Mar 2013 11:30:17 -0700 (PDT) Received: from BL2FFO11FD012.protection.gbl (10.173.161.200) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sat, 16 Mar 2013 18:30:10 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD012.mail.protection.outlook.com (10.173.161.18) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sat, 16 Mar 2013 18:30:10 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sat, 16 Mar 2013 18:30:06 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5QAAL5JoAAAOKbMA== Date: Sat, 16 Mar 2013 18:30:05 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> In-Reply-To: <000901ce2270$08250b10$186f2130$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF947TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454001)(74662001)(47976001)(16406001)(56776001)(512954001)(76482001)(79102001)(15202345001)(47446002)(56816002)(44976002)(5343635001)(31966008)(55846006)(5343655001)(16236675001)(53806001)(47736001)(49866001)(80022001)(54316002)(20776003)(74502001)(46102001)(66066001)(51856001)(4396001)(77982001)(54356001)(33656001)(59766001)(69226001)(65816001)(50986001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0787459938 Cc: "alexandru.petrescu@gmail.com" , "Roque Gagliano \(rogaglia\)" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 18:30:22 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF947TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Ri= chardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF947TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com= ]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Mic= hael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCF947TK5EX14MBXC273r_-- From ietf@rozanak.com Sat Mar 16 13:45:47 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC5A21F86C9; Sat, 16 Mar 2013 13:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFn4MI5x5Q-t; Sat, 16 Mar 2013 13:45:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 74BA621F86C5; Sat, 16 Mar 2013 13:45:42 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LnyHg-1UwbEu3g4G-00g50p; Sat, 16 Mar 2013 16:44:51 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> In-Reply-To: Date: Sat, 16 Mar 2013 21:44:36 +0100 Message-ID: <000901ce2287$18d71040$4a8530c0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CE228F.7AA08150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLphoNq6A Content-Language: en-us X-Provags-ID: V02:K0:YtVdYocprd/QCOulPtBd9REmqVjfm4HFFO8JrbQ8W5r INqZOVAsU01xef8xiHbiZnh/cV1pFx2M/8CE/dGgItgOlovyoE qwlUIMM400YvrmJG4+wQ7JCvQ8kVQpdaOXivBu29agxCbGvTo9 JP6etmElNHeGF6LGt8MAIgfXCki9/UdJhwd5l0YLHwltOjMVzX exD5vLN2quBsxSJb0z5kQZtNAo4VLp4ilgTVDidJLHXkHiAORW nN4GhI7Koh7HEBndx7g1PgCheAg/lOAWwNp6dUc+VMy1YAxU4D cS23g3+fcEWlOIzNHUEkDJPIy8qo0HcqE6PWiiv3lm2Qz5JwAA HPP7vWcvKOUtxINVmaIE= Cc: alexandru.petrescu@gmail.com, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:45:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01CE228F.7AA08150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit >The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_000A_01CE228F.7AA08150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>The “SEC” part of CGA is meant = to protect against a different attack, one in which the attacker has not = cracked the private key. Instead, the attacker uses a public/private key = pair of his own >choosing, and arrange for the hash of that key to = match the CGA address of the target. This “only” requires = O(2**(59+SEC*16)) operations, which even with large values of SEC is = still far less than >what is required to crack RSA or = ECC.

 

So according to what I = understand from what you wrote, the sec value makes the for an easier = attack against CGA as the attacker only needs to find the same value = generated by his own modifier and other parameters and matches this to = the IID of the node. Now the question again is, if this gives an = attacker a leg up in doing his brute force attacks why do we need to add = those steps to CGA. This was why I used the direct public key as a part = of IP address.

 

Thanks again = Christian.

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; = alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; = jeanmichel.combes@orange.com; Roque Gagliano = (rogaglia)
Subject: RE: security consideration of CGA and SSAS = - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack that you mention depends = on the strength of RSA or ECC. In fact, pretty much all of public key = cryptography depends on that strength. It is generally assumed that = cracking a long enough RSA or ECC key is nearly impossible. =

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which = the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own choosing, and arrange for the hash = of that key to match the CGA address of the target. This = “only” requires O(2**(59+SEC*16)) operations, which even = with large values of SEC is still far less than what is required to = crack RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 10:59 AM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

 

>Did you somehow = crack RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: RE: security consideration of CGA = and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_000A_01CE228F.7AA08150-- From huitema@microsoft.com Sun Mar 17 01:14:52 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C9D21F8771; Sun, 17 Mar 2013 01:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8-5FoNO9kp9; Sun, 17 Mar 2013 01:14:38 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0C21F871E; Sun, 17 Mar 2013 01:14:37 -0700 (PDT) Received: from BY2FFO11FD004.protection.gbl (10.1.15.201) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sun, 17 Mar 2013 08:14:35 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sun, 17 Mar 2013 08:14:34 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sun, 17 Mar 2013 08:14:08 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5QAAL5JoAAAOKbMAAE4acAABeL7YA= Date: Sun, 17 Mar 2013 08:14:07 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: <000901ce2287$18d71040$4a8530c0$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFE3ATK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(57704001)(377454001)(43784002)(199002)(189002)(50986001)(15202345001)(54316002)(47446002)(79102001)(16406001)(80022001)(56816002)(66066001)(74502001)(74662001)(4396001)(56776001)(33656001)(20776003)(49866001)(63696002)(5343635001)(59766001)(76482001)(47976001)(54356001)(5343655001)(47736001)(512954001)(77982001)(69226001)(44976002)(16236675001)(53806001)(51856001)(31966008)(65816001)(46102001)(55846006); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07880C4932 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 08:14:52 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFE3ATK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael R= ichardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFE3ATK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The attack is *rela= tively* easier. It is not “easy.” It is much harder to crac= k RSA than to find a matching hash. Cracking a 2048 bits RSA key probably r= equires on the order of 2^1024 trials, and that will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetime of the address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com= ]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Mi= chael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)= '
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SECR= 21; part of CGA is meant to protect against a different attack, one in whic= h the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. T= his “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than >what is required to c= rack RSA or ECC.

 

So according to what I= understand from what you wrote, the sec value makes the for an easier atta= ck against CGA as the attacker only needs to find the same value generated = by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if thi= s gives an attacker a leg up in doing his brute force attacks why do we nee= d to add those steps to CGA. This was why I used the direct public key as a= part of IP address.

 

Thanks again Christian= .

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFE3ATK5EX14MBXC273r_-- From ietf@rozanak.com Sun Mar 17 09:23:35 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B3121F8BD7; Sun, 17 Mar 2013 09:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wODuX7Bbf+sb; Sun, 17 Mar 2013 09:23:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0E921F8BBC; Sun, 17 Mar 2013 09:23:30 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LjqxF-1UsEnb3kj3-00bQcs; Sun, 17 Mar 2013 12:22:37 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Date: Sun, 17 Mar 2013 17:22:23 +0100 Message-ID: <001e01ce232b$a27f2310$e77d6930$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CE2334.044AB700" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLgJ/3rcyAgRh1nKYRWAnkA== Content-Language: en-us X-Provags-ID: V02:K0:RsVX0s15gGAY67zuMivbiTAUj0F3AmyRrNO3sAoaaPv gLPr9YkL/4MQAFX3rPKharR4H8YCT/32kDAT/C+IFGLDEpZyqe 1bILdjcI5Iw9HAgCTrIlbQuZnEKyy7EFPGqgvfiSGGroTpCK6C 9K6pmsER6NU6KA4F0iszfIC8Ew2LHXYztSSDFbkpYVrmq4K7PT x5SEpeCII+4DETQAONHc9Px57cAecE1sd/mcA5BvrxMNjV/2Bn BOQl7594VLy/sTBiMpMN/e5sq2SexoxOe9vJfikf7G6e/WpdBQ ZeLUDPKvo0Wp9DahgzzPICD0xXc4gMazBL+KmMWT7bil451gQg GMExFboFLn3wBr32/uWo= Cc: alexandru.petrescu@gmail.com, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:23:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001F_01CE2334.044AB700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Christian. You answered my question. This is what I wanted to know about security when directly using keys or using in the way CGA does. Both are difficult but the CGA way is relatively easier than cracking the RSA keys. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to crack RSA than to find a matching hash. Cracking a 2048 bits RSA key probably requires on the order of 2^1024 trials, and that will take you something like "forever." Cracking the hash requires only something on the order of 2^91 trials with SEC=2. That's obviously much less, but that's still a very large number. The exhausting search will take you many years, i.e. much more than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_001F_01CE2334.044AB700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Christian. You answered my question. This = is what I wanted to know about security when directly using keys or = using in the way CGA does. Both are difficult but the CGA way is = relatively easier than cracking the RSA keys.

 

Hosnieh

=

 

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Sunday, March 17, 2013 9:14 AM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; = alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; = jeanmichel.combes@orange.com; 'Roque Gagliano = (rogaglia)'
Subject: RE: security consideration of CGA and = SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *relatively* easier. It is = not “easy.” It is much harder to crack RSA than to find a = matching hash. Cracking a 2048 bits RSA key probably requires on the = order of 2^1024 trials, and that will take you something like = “forever.” Cracking the hash requires only something on the = order of 2^91 trials with SEC=3D2. That’s obviously much less, but = that’s still a very large number. The exhausting search will take = you many years, i.e. much more than the valid lifetime of the = address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 1:45 PM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SEC” part of CGA is meant = to protect against a different attack, one in which the attacker has not = cracked the private key. Instead, the attacker uses a public/private key = pair of his own >choosing, and arrange for the hash of that key to = match the CGA address of the target. This “only” requires = O(2**(59+SEC*16)) operations, which even with large values of SEC is = still far less than >what is required to crack RSA or = ECC.

 

So according to what I = understand from what you wrote, the sec value makes the for an easier = attack against CGA as the attacker only needs to find the same value = generated by his own modifier and other parameters and matches this to = the IID of the node. Now the question again is, if this gives an = attacker a leg up in doing his brute force attacks why do we need to add = those steps to CGA. This was why I used the direct public key as a part = of IP address.

 

Thanks again = Christian.

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack that you mention depends = on the strength of RSA or ECC. In fact, pretty much all of public key = cryptography depends on that strength. It is generally assumed that = cracking a long enough RSA or ECC key is nearly impossible. =

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which = the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own choosing, and arrange for the hash = of that key to match the CGA address of the target. This = “only” requires O(2**(59+SEC*16)) operations, which even = with large values of SEC is still far less than what is required to = crack RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 10:59 AM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

 

>Did you somehow = crack RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: RE: security consideration of CGA = and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_001F_01CE2334.044AB700-- From huitema@microsoft.com Sun Mar 17 09:46:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0DE21F8BF4; Sun, 17 Mar 2013 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9ef7puipik8; Sun, 17 Mar 2013 09:46:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 3C37221F8BF0; Sun, 17 Mar 2013 09:46:49 -0700 (PDT) Received: from BL2FFO11FD008.protection.gbl (10.173.161.203) by BL2FFO11HUB007.protection.gbl (10.173.160.227) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sun, 17 Mar 2013 16:46:46 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sun, 17 Mar 2013 16:46:46 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sun, 17 Mar 2013 16:46:27 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5QAAL5JoAAAOKbMAAE4acAABeL7YAAEZZHgAAAR0Nw Date: Sun, 17 Mar 2013 16:46:26 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> In-Reply-To: <001e01ce232b$a27f2310$e77d6930$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(43784002)(189002)(57704001)(377454001)(47446002)(50986001)(512954001)(53806001)(74662001)(66066001)(80022001)(74502001)(33656001)(16236675001)(20776003)(51856001)(63696002)(56776001)(5343655001)(49866001)(15202345001)(55846006)(47976001)(44976002)(69226001)(46102001)(65816001)(59766001)(5343635001)(4396001)(56816002)(16406001)(77982001)(79102001)(54356001)(47736001)(76482001)(54316002)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB007; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07880C4932 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 16:46:58 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the other hand, cracking SSAS is *much* easier than cracking RSA, or eve= n cracking CGA. SSAS builds the 64 bit identifier as follow: * Pick a random 16 bit number; * Use that number as an index in the bit array representing the pub= lic key; * Extract the 48 bits following the index; * Concatenate the random 16 bit number and the 48 bits of the key t= o build a 64 bit interface ID; * Prove possession of the public/private key pair when using the re= sulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by gener= ating a set of random public/private key pairs. For each generated key, th= ere is 2**-48 probability that the indexed bits match the 48 bit thumbprint= . In about 2**48 trials, the attacker will get a public key in which the 48= bits happen to match the 48 bit thumbprint in the IPv6 address. They can t= hen select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=3D0 algorithm, let= alone using SEC=3D1 or SEC=3D2. You may think that building public/private key pairs is a very expensive op= eration, but that is not true. The default algorithm for SSAS is RSA. Let's= suppose you use 2048 bit long RSA keys. The key generation start by genera= ting a set of 1024 bit long prime numbers. In theory, we need about 2*25 su= ch numbers. Add a margin to be on the safe side. These numbers can be gener= ated once, they don't have to be regenerated for every SSAS key being tried= . An RSA key is the product of two such numbers. 2*25 numbers allow you to co= mpute 2**48 products, i.e. 2**48 candidate public keys. Computing a long in= teger product does take a few computations, but not much more than computin= g a SHA hash. The search for a key that match the footprint will be very qu= ick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael R= ichardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know a= bout security when directly using keys or using in the way CGA does. Both a= re difficult but the CGA way is relatively easier than cracking the RSA key= s. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the other hand, cra= cking SSAS is *much* easier than cracking RSA, or even cracking CGA.=

 

SSAS builds the 64 bit= identifier as follow:

·         Pick a random = 16 bit number;

·         Use that numbe= r as an index in the bit array representing the public key;

·         Extract the 48= bits following the index;

·         Concatenate th= e random 16 bit number and the 48 bits of the key to build a 64 bit interfa= ce ID;

·         Prove possessi= on of the public/private key pair when using the resulting IPv6 address.

 

An attacker can obviou= sly break that scheme in about 2**48 trials, by generating a set of random&= nbsp; public/private key pairs. For each generated key, there is 2**-48 pro= bability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public k= ey in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 a= ddress. They can then select that key pair, and spoof the IPv6 SSAS address= at will.

 

2**48 is much less tha= n the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 o= r SEC=3D2.

 

You may think that bui= lding public/private key pairs is a very expensive operation, but that is n= ot true. The default algorithm for SSAS is RSA. Let’s suppose you use= 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we ne= ed about 2*25 such numbers. Add a margin to be on the safe side. These numb= ers can be generated once, they don’t have to be regenerated for ever= y SSAS key being tried.

 

An RSA key is the prod= uct of two such numbers. 2*25 numbers allow you to compute 2**48 products, = i.e. 2**48 candidate public keys. Computing a long integer product does tak= e a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint w= ill be very quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com= ]
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Mi= chael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)= '
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You = answered my question. This is what I wanted to know about security when dir= ectly using keys or using in the way CGA does. Both are difficult but the C= GA way is relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *rela= tively* easier. It is not “easy.” It is much harder to crac= k RSA than to find a matching hash. Cracking a 2048 bits RSA key probably r= equires on the order of 2^1024 trials, and that will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetime of the address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SECR= 21; part of CGA is meant to protect against a different attack, one in whic= h the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. T= his “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than >what is required to c= rack RSA or ECC.

 

So according to what I= understand from what you wrote, the sec value makes the for an easier atta= ck against CGA as the attacker only needs to find the same value generated = by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if thi= s gives an attacker a leg up in doing his brute force attacks why do we nee= d to add those steps to CGA. This was why I used the direct public key as a= part of IP address.

 

Thanks again Christian= .

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2TK5EX14MBXC273r_-- From ietf@rozanak.com Sun Mar 17 11:47:37 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC4121F8AE6; Sun, 17 Mar 2013 11:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSp2CM9EmYCr; Sun, 17 Mar 2013 11:47:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0E21F8AE3; Sun, 17 Mar 2013 11:47:29 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MEGA4-1UWk0P2RBo-00Fe3w; Sun, 17 Mar 2013 14:47:16 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> In-Reply-To: Date: Sun, 17 Mar 2013 19:47:02 +0100 Message-ID: <000301ce233f$d6c35380$8449fa80$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CE2348.3892B800" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLgJ/3rcyAgRh1nIB5BhzHAEy9iDWmCzRO8A= Content-Language: en-us X-Provags-ID: V02:K0:vR7qRw9T7bZgZotwKcy2U3Ln9n446cgLNhz2O0fTQC5 mw8FBk2waXh8/uAuAi4d6ZRvkl0DNAwRcD4Bp9pRFZQ9WSkkTd pASt3OJGWYwXslF3CSeNuZVpzvooqj1aSMsZRRmBEwAwYsW3Zk gnOeH6z2qdnzxkjI0VVZOWDfoVnu7DrJAG4aGtqN2/DrQNgy2j xrqeNoGR4JwzBG7vJeH71954sFNp1a8i8IvDaUzqdlq30ees/6 FZ6XNEcQD7t96Shqak2YVp4bJ/5IXVKB/nZy+SRN1UPvF5nlRe 2eY3/s5EmifmhPjieYNYAaqW7CVLr93k4BNX4CAx5Crz7j3r44 65GasZ9e6V+qofa8XhEg= Cc: alexandru.petrescu@gmail.com, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 18:47:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01CE2348.3892B800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks again for your response. I have some questions: - Choosing a random part of the public key does not help to increase the probability of matching the public key to the IID? if I am to improve this section and by saying we need to generate two, one byte random numbers such that the second byte must not be higher than the size of public key minus 6. - How many days does it take to break SSAS? I ask this because for privacy I consider changing the key pairs and creating a new IP address in a certain time frame. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 5:46 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas On the other hand, cracking SSAS is *much* easier than cracking RSA, or even cracking CGA. SSAS builds the 64 bit identifier as follow: . Pick a random 16 bit number; . Use that number as an index in the bit array representing the public key; . Extract the 48 bits following the index; . Concatenate the random 16 bit number and the 48 bits of the key to build a 64 bit interface ID; . Prove possession of the public/private key pair when using the resulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by generating a set of random public/private key pairs. For each generated key, there is 2**-48 probability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public key in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They can then select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=0 algorithm, let alone using SEC=1 or SEC=2. You may think that building public/private key pairs is a very expensive operation, but that is not true. The default algorithm for SSAS is RSA. Let's suppose you use 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we need about 2*25 such numbers. Add a margin to be on the safe side. These numbers can be generated once, they don't have to be regenerated for every SSAS key being tried. An RSA key is the product of two such numbers. 2*25 numbers allow you to compute 2**48 products, i.e. 2**48 candidate public keys. Computing a long integer product does take a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint will be very quick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know about security when directly using keys or using in the way CGA does. Both are difficult but the CGA way is relatively easier than cracking the RSA keys. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to crack RSA than to find a matching hash. Cracking a 2048 bits RSA key probably requires on the order of 2^1024 trials, and that will take you something like "forever." Cracking the hash requires only something on the order of 2^91 trials with SEC=2. That's obviously much less, but that's still a very large number. The exhausting search will take you many years, i.e. much more than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_0004_01CE2348.3892B800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks again for your response. I have some = questions:

-          = Choosing a random part of the public key does = not help to increase the probability of matching the public key to the = IID?

if I am to improve this section and by saying we = need to generate two, one byte random numbers such that the second byte = must not be higher than the size of public key minus 6. =

-          = How many days does it take to break SSAS? =  I ask this because for privacy I consider changing the key pairs = and creating a new IP address in a certain time = frame.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Sunday, March 17, 2013 5:46 PM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; = alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; = jeanmichel.combes@orange.com; 'Roque Gagliano = (rogaglia)'
Subject: RE: security consideration of CGA and = SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

On the other hand, cracking SSAS is = *much* easier than cracking RSA, or even cracking = CGA.

 

SSAS builds the 64 bit = identifier as follow:

·       &= nbsp; Pick a random 16 bit = number;

·       &= nbsp; Use that number as an index = in the bit array representing the public key;

·       &= nbsp; Extract the 48 bits following = the index;

·       &= nbsp; Concatenate the random 16 bit = number and the 48 bits of the key to build a 64 bit interface = ID;

·       &= nbsp; Prove possession of the = public/private key pair when using the resulting IPv6 = address.

 

An attacker can = obviously break that scheme in about 2**48 trials, by generating a set = of random  public/private key pairs. For each generated key, there = is 2**-48 probability that the indexed bits match the 48 bit thumbprint. = In about 2**48 trials, the attacker will get a public key in which the = 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They = can then select that key pair, and spoof the IPv6 SSAS address at = will.

 

2**48 is much less than = the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 = or SEC=3D2.

 

You may think that = building public/private key pairs is a very expensive operation, but = that is not true. The default algorithm for SSAS is RSA. Let’s = suppose you use 2048 bit long RSA keys. The key generation start by = generating a set of 1024 bit long prime numbers. In theory, we need = about 2*25 such numbers. Add a margin to be on the safe side. These = numbers can be generated once, they don’t have to be regenerated = for every SSAS key being tried.

 

An RSA key is the = product of two such numbers. 2*25 numbers allow you to compute 2**48 = products, i.e. 2**48 candidate public keys. Computing a long integer = product does take a few computations, but not much more than computing a = SHA hash. The search for a key that match the footprint will be very = quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian = Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You answered my question. This = is what I wanted to know about security when directly using keys or = using in the way CGA does. Both are difficult but the CGA way is = relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *relatively* easier. It is = not “easy.” It is much harder to crack RSA than to find a = matching hash. Cracking a 2048 bits RSA key probably requires on the = order of 2^1024 trials, and that will take you something like = “forever.” Cracking the hash requires only something on the = order of 2^91 trials with SEC=3D2. That’s obviously much less, but = that’s still a very large number. The exhausting search will take = you many years, i.e. much more than the valid lifetime of the = address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 1:45 PM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SEC” part of CGA is meant = to protect against a different attack, one in which the attacker has not = cracked the private key. Instead, the attacker uses a public/private key = pair of his own >choosing, and arrange for the hash of that key to = match the CGA address of the target. This “only” requires = O(2**(59+SEC*16)) operations, which even with large values of SEC is = still far less than >what is required to crack RSA or = ECC.

 

So according to what I = understand from what you wrote, the sec value makes the for an easier = attack against CGA as the attacker only needs to find the same value = generated by his own modifier and other parameters and matches this to = the IID of the node. Now the question again is, if this gives an = attacker a leg up in doing his brute force attacks why do we need to add = those steps to CGA. This was why I used the direct public key as a part = of IP address.

 

Thanks again = Christian.

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack that you mention depends = on the strength of RSA or ECC. In fact, pretty much all of public key = cryptography depends on that strength. It is generally assumed that = cracking a long enough RSA or ECC key is nearly impossible. =

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which = the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own choosing, and arrange for the hash = of that key to match the CGA address of the target. This = “only” requires O(2**(59+SEC*16)) operations, which even = with large values of SEC is still far less than what is required to = crack RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 10:59 AM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

 

>Did you somehow = crack RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: RE: security consideration of CGA = and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_0004_01CE2348.3892B800-- From huitema@microsoft.com Sun Mar 17 12:39:39 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0401621F857B; Sun, 17 Mar 2013 12:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5PIN+kqzwKe; Sun, 17 Mar 2013 12:39:27 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5F221F8A9E; Sun, 17 Mar 2013 12:39:25 -0700 (PDT) Received: from BY2FFO11FD001.protection.gbl (10.1.15.200) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.641.9; Sun, 17 Mar 2013 19:34:59 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Sun, 17 Mar 2013 19:34:58 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Sun, 17 Mar 2013 19:33:54 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5QAAL5JoAAAOKbMAAE4acAABeL7YAAEZZHgAAAR0NwAATGAwAAAYdeMA== Date: Sun, 17 Mar 2013 19:33:53 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> <000301ce233f$d6c35380$8449fa80$@rozanak.com> In-Reply-To: <000301ce233f$d6c35380$8449fa80$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD0077TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454001)(43784002)(57704001)(5343635001)(15202345001)(47736001)(20776003)(47446002)(79102001)(76482001)(74502001)(49866001)(63696002)(77982001)(65816001)(47976001)(512954001)(56776001)(31966008)(59766001)(74662001)(4396001)(16406001)(80022001)(69226001)(55846006)(56816002)(33656001)(5343655001)(54316002)(54356001)(53806001)(51856001)(66066001)(50986001)(16236675001)(561944001)(44976002)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07880C4932 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 19:39:39 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD0077TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think the index helps much. I suspect that SSAS could be broken in = minutes if someone did a parallel implementation on a GPU. Maybe seconds. Frankly, I believe that you have fallen in the trap of "inventing your own = crypto." Most of these inventions turn out to have flaws, and won't pass a = serious review. I would advise that you withdraw that specific proposal. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 11:47 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael R= ichardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks again for your response. I have some questions: - Choosing a random part of the public key does not help to increa= se the probability of matching the public key to the IID? if I am to improve this section and by saying we need to generate two, one = byte random numbers such that the second byte must not be higher than the s= ize of public key minus 6. - How many days does it take to break SSAS? I ask this because fo= r privacy I consider changing the key pairs and creating a new IP address i= n a certain time frame. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 5:46 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas On the other hand, cracking SSAS is *much* easier than cracking RSA, or eve= n cracking CGA. SSAS builds the 64 bit identifier as follow: * Pick a random 16 bit number; * Use that number as an index in the bit array representing the pub= lic key; * Extract the 48 bits following the index; * Concatenate the random 16 bit number and the 48 bits of the key t= o build a 64 bit interface ID; * Prove possession of the public/private key pair when using the re= sulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by gener= ating a set of random public/private key pairs. For each generated key, th= ere is 2**-48 probability that the indexed bits match the 48 bit thumbprint= . In about 2**48 trials, the attacker will get a public key in which the 48= bits happen to match the 48 bit thumbprint in the IPv6 address. They can t= hen select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=3D0 algorithm, let= alone using SEC=3D1 or SEC=3D2. You may think that building public/private key pairs is a very expensive op= eration, but that is not true. The default algorithm for SSAS is RSA. Let's= suppose you use 2048 bit long RSA keys. The key generation start by genera= ting a set of 1024 bit long prime numbers. In theory, we need about 2*25 su= ch numbers. Add a margin to be on the safe side. These numbers can be gener= ated once, they don't have to be regenerated for every SSAS key being tried= . An RSA key is the product of two such numbers. 2*25 numbers allow you to co= mpute 2**48 products, i.e. 2**48 candidate public keys. Computing a long in= teger product does take a few computations, but not much more than computin= g a SHA hash. The search for a key that match the footprint will be very qu= ick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know a= bout security when directly using keys or using in the way CGA does. Both a= re difficult but the CGA way is relatively easier than cracking the RSA key= s. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD0077TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t think th= e index helps much. I suspect that SSAS could be broken in minutes if someo= ne did a parallel implementation on a GPU. Maybe seconds.=

 

Frankly, I believe tha= t you have fallen in the trap of “inventing your own crypto.” M= ost of these inventions turn out to have flaws, and won’t pass a seri= ous review. I would advise that you withdraw that specific proposal.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com= ]
Sent: Sunday, March 17, 2013 11:47 AM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Mi= chael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)= '
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks again for your = response. I have some questions:

-&nb= sp;         Choosing a ran= dom part of the public key does not help to increase the probability of mat= ching the public key to the IID?

if I am to impr= ove this section and by saying we need to generate two, one byte random num= bers such that the second byte must not be higher than the size of public k= ey minus 6.

-&nb= sp;         How many days = does it take to break SSAS?  I ask this because for privacy I consider= changing the key pairs and creating a new IP address in a certain time fra= me.

 

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 5:46 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

On the other hand, cra= cking SSAS is *much* easier than cracking RSA, or even cracking CGA.=

 

SSAS builds the 64 bit= identifier as follow:

·Pick a random 16 bit number;

·Use that number as an index in the bit= array representing the public key;

·Extract the 48 bits following the inde= x;

·Concatenate the random 16 bit number a= nd the 48 bits of the key to build a 64 bit interface ID;=

·Prove possession of the public/private= key pair when using the resulting IPv6 address.

 

An attacker can obviou= sly break that scheme in about 2**48 trials, by generating a set of random&= nbsp; public/private key pairs. For each generated key, there is 2**-48 pro= bability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public k= ey in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 a= ddress. They can then select that key pair, and spoof the IPv6 SSAS address= at will.

 

2**48 is much less tha= n the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 o= r SEC=3D2.

 

You may think that bui= lding public/private key pairs is a very expensive operation, but that is n= ot true. The default algorithm for SSAS is RSA. Let’s suppose you use= 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we ne= ed about 2*25 such numbers. Add a margin to be on the safe side. These numb= ers can be generated once, they don’t have to be regenerated for ever= y SSAS key being tried.

 

An RSA key is the prod= uct of two such numbers. 2*25 numbers allow you to compute 2**48 products, = i.e. 2**48 candidate public keys. Computing a long integer product does tak= e a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint w= ill be very quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You = answered my question. This is what I wanted to know about security when dir= ectly using keys or using in the way CGA does. Both are difficult but the C= GA way is relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *rela= tively* easier. It is not “easy.” It is much harder to crac= k RSA than to find a matching hash. Cracking a 2048 bits RSA key probably r= equires on the order of 2^1024 trials, and that will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetime of the address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SECR= 21; part of CGA is meant to protect against a different attack, one in whic= h the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. T= his “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than >what is required to c= rack RSA or ECC.

 

So according to what I= understand from what you wrote, the sec value makes the for an easier atta= ck against CGA as the attacker only needs to find the same value generated = by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if thi= s gives an attacker a leg up in doing his brute force attacks why do we nee= d to add those steps to CGA. This was why I used the direct public key as a= part of IP address.

 

Thanks again Christian= .

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD0077TK5EX14MBXC273r_-- From SChokhani@cygnacom.com Sun Mar 17 18:36:34 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822DA21F8804; Sun, 17 Mar 2013 18:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAM9PqATtjTp; Sun, 17 Mar 2013 18:36:28 -0700 (PDT) Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id B8C2C21F8800; Sun, 17 Mar 2013 18:36:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,861,1355115600"; d="scan'208,217";a="4645795" Received: from unknown (HELO scygexch7.cygnacom.com) ([10.4.60.22]) by ipedge2.cygnacom.com with ESMTP; 17 Mar 2013 21:36:27 -0400 Received: from scygexch7.cygnacom.com ([::1]) by scygexch7.cygnacom.com ([::1]) with mapi; Sun, 17 Mar 2013 21:36:26 -0400 From: Santosh Chokhani To: Christian Huitema , Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Date: Sun, 17 Mar 2013 21:36:25 -0400 Thread-Topic: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: Ac4iRLmAApaYEg76TZ2U12de+21L7gAH2L5QAAL5JoAAAOKbMAAE4acAABeL7YAAJKq6cA== Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B83745DA469B7847811819C5005244AFF3DC9889scygexch7cygnac_" MIME-Version: 1.0 Cc: 'Ray Hunter' , "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 01:36:34 -0000 --_000_B83745DA469B7847811819C5005244AFF3DC9889scygexch7cygnac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2048 bit RSA security is overstated. Cracking it requires on the order of = 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2 Sectio= n 5.6.1. >From the description you provide on hashing, finding a second hash is a sec= ond pre-image attack and for SHA-1 the security strength is 160 bits, i.e.,= you need on the order of 2^160 operations. I do not know what hash function you are describing for the function you me= ntion and how you derived its security strength. From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Chr= istian Huitema Sent: Sunday, March 17, 2013 4:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik Nordma= rk'; 'Ray Hunter'; jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_B83745DA469B7847811819C5005244AFF3DC9889scygexch7cygnac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2048 bit RSA security is overstated.  Cracking it requir= es on the order of 2^112 operations.  You should look at NIST SP 800-5= 7 Part 2, Table 2 Section 5.6.1.

=  

From the description you provide on hashi= ng, finding a second hash is a second pre-image attack and for SHA-1 the se= curity strength is 160 bits, i.e., you need on the order of 2^160 operation= s.

=  

I do not know what hash function you are describing for the function yo= u mention and how you derived its security strength.

<= p class=3DMsoNormal> <= /p>

From: saag-bounces@ietf.org [mailto:saa= g-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: S= unday, March 17, 2013 4:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; = saag@ietf.org
Cc: alexandru.petrescu@gmail.com; 'Roque Gagliano (= rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com
= Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D ac= tion : draft-rafiee-6man-ssas

 

The attack is *relatively* easier. It is not “easy.̶= 1; It is much harder to crack RSA than to find a matching hash. Cracking a = 2048 bits RSA key probably requires on the order of 2^1024 trials, and that= will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetim= e of the address.

 

From: Hosnieh Rafiee [mailto:= ietf@rozanak.com]
Sent: Saturday, March 16, 2013 1:45 PM
= To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Er= ik Nordmark'; alexandru.pet= rescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagl= iano (rogaglia)'
Subject: RE: security consideration of CGA and S= SAS - Ii-D action : draft-rafiee-6man-ssas

 

>The “SEC” part of CGA is meant to protect again= st a different attack, one in which the attacker has not cracked the privat= e key. Instead, the attacker uses a public/private key pair of his own >= choosing, and arrange for the hash of that key to match the CGA address of = the target. This “only” requires O(2**(59+SEC*16)) operations, = which even with large values of SEC is still far less than >what is requ= ired to crack RSA or ECC.

 

So according to what I understand from what you = wrote, the sec value makes the for an easier attack against CGA as the atta= cker only needs to find the same value generated by his own modifier and ot= her parameters and matches this to the IID of the node. Now the question ag= ain is, if this gives an attacker a leg up in doing his brute force attacks= why do we need to add those steps to CGA. This was why I used the direct p= ublic key as a part of IP address.

 

Thanks again Christian.

Hosnieh=

 

From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafie= e; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray H= unter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia)
Subject:= RE: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas

&nbs= p;

As you say, = the attack that you mention depends on the strength of RSA or ECC. In fact,= pretty much all of public key cryptography depends on that strength. It is= generally assumed that cracking a long enough RSA or ECC key is nearly imp= ossible.

 

The “SEC” part of CGA is meant to protect against a = different attack, one in which the attacker has not cracked the private key= . Instead, the attacker uses a public/private key pair of his own choosing,= and arrange for the hash of that key to match the CGA address of the targe= t. This “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than what is required to crack= RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@= rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
T= o: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik N= ordmark'; alexandru.petresc= u@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (r= ogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii= -D action : draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou explain why you believe that retriev= ing the private key from the public key and a clear text/encrypted text pai= r is easier than breaking a hash?

 

Here we do not use any encryption and d= ecryption and we just sign the message using private key and verify the mes= sage using public key.

 

>Did you somehow crack RSA?

 

I do not say that i= t is easier to find the private key from the public key. Because for both S= SAS and CGA, public/private keys are used. I do say that the SHAx steps use= d for CGA generation do not increase the complexity when used against brute= force attacks. This is because an attacker only needs the private key and = does not need to find the modifier that was used in the generation of the n= ode’s IID nor is there a need for checking the condition of sec by 16= bits which should be equal to zero. In SSAS I just use the public/private = keys and the signature and nothing is encrypted/decrypted. In CGA some extr= a SHAx steps are used in the generation of their IID along with the signatu= re. I say that these steps are not needed as long as you include and send a= ll parameters, used in the SHAx process, in the packet for verification pur= poses. Some people feel that CGA  is secure enough when those steps ar= e used. Now what I want to point out here is that the CGA security level is= only dependent on the algorithm used for key pair and signature gen= eration and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such the = situation will be the same as it is for SSAS. I just removed the complexity= from the use of CGA in order to enable a more practical and faster generat= ion and verification process.

 

So the question isn’t how to break the= encrypted text but how to break the signature. In other word,  to fin= d the same public key as used by the generator node or how to break the RSA= or ECC. Based on my knowledge of hash algorithms, as I mentioned in my pri= or sentence, this will depend on the strength of the RSA or whatever other =  algorithm is used to generate these keys and sign the message. If you= or anyone else thinks otherwise, please contribute to this discussion and = share your opinions. I am just comparing the security aspects of SSAS, the = time efficient algorithm, to those of CGA.

 

Thank you,

Hosnieh

 <= /span>

 

From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee= ; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunte= r
Subject: RE: security consideration of CGA and SSAS - Ii-D acti= on : draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the private key, the size o= f the hash does not matter. But can you explain why you believe that retrie= ving the private key from the public key and a clear text/encrypted text pa= ir is easier than breaking a hash? Did you somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Ho= snieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To:= ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter=
Subject: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

=  

Hello,

There was a discussion during my presentation about security considerat= ions regarding the use of my algorithm compared with those of the use of CG= A. A big mistake that is made when considering CGA security is that the sec= value plays an important role and that an attacker will need to do brute f= orce attacks against the IID in order to generate the same IID as is genera= ted by the use of CGA. In a CGA analysis paper they talk about a CGA securi= ty vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is th= e exponential value and so they infer that by increasing the sec value used= with CGA it will be safer, but this Is not true.

I, as an attacker, just to need to find your private key. That= ’s it. This is because you have already included the CGA parameters (= public key, modifier, and other required parameters) in the  packet th= at was sent and I will have no problem in regenerating the CGA. My only pro= blem will be in generating the signature that can be verified by use of you= r public key. This means that you just increased the complexity and time re= quired for generating and verifying the IID while with SSAS you can obtain = the same security as when using CGA because its security also depends on th= e Hash function that is used to generate the key pair and signature. <= /o:p>

If you send the CGA parameters via a safe cha= nnel, like in establishing TLS etc., then, in that case, CGA would be more = secure than SSAS. But in practice all the data is sent in the same packet w= ithout encryption. If a secured channel would be used in the CGA process fo= r security reasons (sending CGA parameters), then the cost of using CGA wou= ld be much greater than the cost of using SSAS.

 

Now the questio= n is, Why not use a more cost efficient algorithm that afford you with the = same security level as when using CGA.

 

I have also included the secu= rity group in this email so that they can also give me any comments that th= ey might have.

 

Thank you,

Hosnieh=

= --_000_B83745DA469B7847811819C5005244AFF3DC9889scygexch7cygnac_-- From huitema@microsoft.com Sun Mar 17 18:44:15 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6057821F8AE3; Sun, 17 Mar 2013 18:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8C8Iwu1tqet; Sun, 17 Mar 2013 18:44:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1894B21F8759; Sun, 17 Mar 2013 18:44:02 -0700 (PDT) Received: from BY2FFO11FD005.protection.gbl (10.1.15.200) by BY2FFO11HUB031.protection.gbl (10.1.14.116) with Microsoft SMTP Server (TLS) id 15.0.641.9; Mon, 18 Mar 2013 01:43:52 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Mon, 18 Mar 2013 01:43:52 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 18 Mar 2013 01:43:48 +0000 From: Christian Huitema To: Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: AQHOI3FYEUMT0x83CkiFHU02F6DwE5iqof9g Date: Mon, 18 Mar 2013 01:43:47 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> <000301ce233f$d6c35380$8449fa80$@rozanak.com> <002001ce2371$425582e0$c70088a0$@rozanak.com> In-Reply-To: <002001ce2371$425582e0$c70088a0$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02A2TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(57704001)(199002)(377454001)(189002)(33656001)(47976001)(56816002)(69226001)(5343655001)(16406001)(55846006)(50986001)(16236675001)(561944001)(46102001)(80022001)(54356001)(53806001)(51856001)(54316002)(551544001)(66066001)(47446002)(76482001)(79102001)(49866001)(74502001)(44976002)(5343635001)(47736001)(15202345001)(20776003)(512954001)(56776001)(31966008)(63696002)(4396001)(74662001)(65816001)(77982001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07891BF289 Cc: "alexandru.petrescu@gmail.com" , "Francis.Dupont@fdupont.fr" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 01:44:15 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02A2TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hosnieh, making your own breaking code is a good exercise and you will cert= ainly learn a lot. However, you will only obtain a "maximum" estimate of th= e breaking time. For example, if you could break the algorithm in 1000 hou= rs, that mean opponents will be able to break it in 1000 hours *or less.*Of= ten, that will be much less. Key points in robustness are, for example: 1) How many bits? To give an example, 56 bits DES keys can be broken i= n seconds using special purpose equipment. AES uses 128 or 256 bit keys, es= pecially for that purpose. Generally, we want to increase the number of bit= s as Moore's law progresses. 2) Can it be parallelized? If it can, that means an attacker can solve= it much faster using more computers. Think for example of a GPU with the e= quivalent of 1000 parallel processors, or a botnet with 1M machines, or eve= n worse a botnet with 1M machines each with a GPU. 3) Can part of the solutions be computed in advance? The famous exampl= es are the "rainbow table" that could be used to crack hashes of passwords,= if these hashes were not protected by some "salt." SSAS is weak on all these counts. Part of the solution can be computed in a= dvance: 2^25 bit prime numbers about 1024 bit long occupy 2^32 octets, i.e.= a gigabyte. That can be stored, copied and distributed easily. The breakin= g algorithm can be parallelized trivially: have millions of nodes in the bo= tnet each pick random seeds, and explore different parts of the solution. T= he number of bits is fixed to 62 bits at most, which means that as Moore's = law progresses SSAS is bound to get ever weaker, with no space to grow. The SEC scheme in CGA was specifically designed to address these weaknesses= . Including the prefix in the hash prevents the use of "rainbow tables." Th= e hash only uses 59 bits because some bits are reserved for the SEC field, = but the SEC fields allows for robust extensions of the hash length as Moore= 's law progresses. This allows node to trade off robustness versus address = generation time. CGA implementers concerned with parallelized attacks have = the choice of making the hash virtually longer by using larger SEC values -= 20 extra bits will mitigate the 1M botnet. From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hos= nieh Rafiee Sent: Sunday, March 17, 2013 5:41 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; Francis.Dupont@fdupont.fr; 'Roque Gaglian= o (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks Christian, Here is what I propose. I have an implementation of SSAS and I will try to = break it to see how long it will take. (I will also share the code with oth= ers so that more people can try to break it.) Based on the mathematical c= alculations (of finding the expected value) the probability of it being bro= ken in one month is very low. Since we also want to use this for the integr= ation of privacy, then this is secure enough. But perhaps with my implement= ation of the attacks against SSAS I can learn the what happens in realtime= as opposed to mathematical theory. I have my doubts about what you said ab= out being able to break it in seconds. I am sorry but I feel that what you = said is really unrealistic. If you really are able to implement something t= hat does this, then you probably would be able to break CGA in seconds als= o. About the modifier that I have, I will also check to determine whether usin= g makes breaking it easier or harder. If it is easier. then I will use the = entire 64 bits of the public key (set bit u and g) and use the fixed part o= f the public key. I am not trying to create a new hash algorithm but only make improvements t= o my algorithm. Francis: SSAS also provides proof of IP address ownership as does CGA. The= question here is not that but is on the security considerations that are b= ased on my calculations with regard to the probability of being able to bre= ak it. I believe that what Christian says is not true, but I will have to t= ry it to prove him wrong. About other algorithms, CGA can use them as well = so you cannot compare the computational times based on the use of those alg= orithms. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 8:34 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas I don't think the index helps much. I suspect that SSAS could be broken in = minutes if someone did a parallel implementation on a GPU. Maybe seconds. Frankly, I believe that you have fallen in the trap of "inventing your own = crypto." Most of these inventions turn out to have flaws, and won't pass a = serious review. I would advise that you withdraw that specific proposal. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 11:47 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks again for your response. I have some questions: - Choosing a random part of the public key does not help to increa= se the probability of matching the public key to the IID? if I am to improve this section and by saying we need to generate two, one = byte random numbers such that the second byte must not be higher than the s= ize of public key minus 6. - How many days does it take to break SSAS? I ask this because fo= r privacy I consider changing the key pairs and creating a new IP address i= n a certain time frame. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 5:46 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas On the other hand, cracking SSAS is *much* easier than cracking RSA, or eve= n cracking CGA. SSAS builds the 64 bit identifier as follow: * Pick a random 16 bit number; * Use that number as an index in the bit array representing the pub= lic key; * Extract the 48 bits following the index; * Concatenate the random 16 bit number and the 48 bits of the key t= o build a 64 bit interface ID; * Prove possession of the public/private key pair when using the re= sulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by gener= ating a set of random public/private key pairs. For each generated key, th= ere is 2**-48 probability that the indexed bits match the 48 bit thumbprint= . In about 2**48 trials, the attacker will get a public key in which the 48= bits happen to match the 48 bit thumbprint in the IPv6 address. They can t= hen select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=3D0 algorithm, let= alone using SEC=3D1 or SEC=3D2. You may think that building public/private key pairs is a very expensive op= eration, but that is not true. The default algorithm for SSAS is RSA. Let's= suppose you use 2048 bit long RSA keys. The key generation start by genera= ting a set of 1024 bit long prime numbers. In theory, we need about 2*25 su= ch numbers. Add a margin to be on the safe side. These numbers can be gener= ated once, they don't have to be regenerated for every SSAS key being tried= . An RSA key is the product of two such numbers. 2*25 numbers allow you to co= mpute 2**48 products, i.e. 2**48 candidate public keys. Computing a long in= teger product does take a few computations, but not much more than computin= g a SHA hash. The search for a key that match the footprint will be very qu= ick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know a= bout security when directly using keys or using in the way CGA does. Both a= re difficult but the CGA way is relatively easier than cracking the RSA key= s. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02A2TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hosnieh, making your o= wn breaking code is a good exercise and you will certainly learn a lot. How= ever, you will only obtain a “maximum” estimate of the breaking= time.  For example, if you could break the algorithm in 1000 hours, that mean opponents will be able to break it in 1000 hours = *or less.*Often, that will be much less. Key points in robustness ar= e, for example:

 

1)&n= bsp;     How many bits?= To give an example, 56 bits DES keys can be broken in seconds using specia= l purpose equipment. AES uses 128 or 256 bit keys, especially for that purp= ose. Generally, we want to increase the number of bits as Moore’s law progresses.

2)&n= bsp;     Can it be para= llelized? If it can, that means an attacker can solve it much faster using = more computers. Think for example of a GPU with the equivalent of 1000 para= llel processors, or a botnet with 1M machines, or even worse a botnet with 1M machines each with a GPU.=

3)&n= bsp;     Can part of th= e solutions be computed in advance? The famous examples are the “rain= bow table” that could be used to crack hashes of passwords, if these = hashes were not protected by some “salt.”

 

SSAS is weak on all th= ese counts. Part of the solution can be computed in advance: 2^25 bit prime= numbers about 1024 bit long occupy 2^32 octets, i.e. a gigabyte. That can = be stored, copied and distributed easily. The breaking algorithm can be parallelized trivially: have millions of nod= es in the botnet each pick random seeds, and explore different parts of the= solution. The number of bits is fixed to 62 bits at most, which means that= as Moore’s law progresses SSAS is bound to get ever weaker, with no space to grow.

 

The SEC scheme in CGA = was specifically designed to address these weaknesses. Including the prefix= in the hash prevents the use of “rainbow tables.” The hash onl= y uses 59 bits because some bits are reserved for the SEC field, but the SEC fields allows for robust extensions of the hash= length as Moore’s law progresses. This allows node to trade off robu= stness versus address generation time. CGA implementers concerned with para= llelized attacks have the choice of making the hash virtually longer by using larger SEC values – 20 extra bits= will mitigate the 1M botnet.

 

From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Sunday, March 17, 2013 5:41 PM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: alexandru.petrescu@gmail.com; Francis.Dupont@fdupont.fr; 'Roque = Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@oran= ge.com
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian,=

Here is what I propose= . I have an implementation of SSAS and I will try to break it to see how lo= ng it will take. (I will also share the code with others so  that more= people can try to break it.)  Based on the mathematical calculations (of finding the expected value) the probability = of it being broken in one month is very low. Since we also want to use this= for the integration of privacy, then this is secure enough. But perhaps wi= th my implementation of the attacks against  SSAS I can learn the what happens in realtime as opposed to = mathematical theory. I have my doubts about what you said about being able = to break it in seconds. I am sorry but I feel that what you said is really = unrealistic. If you really are able to implement something that does this, then you  probably would be able = to break CGA in seconds also.

About the modifier tha= t I have, I will also check to determine whether using makes breaking it ea= sier or harder. If it is easier. then I will use the entire 64 bits of the = public key (set bit u and g) and use the fixed part of the public key.

I am not trying to cre= ate a new hash algorithm but only make improvements to  my algorithm.<= o:p>

 

Francis: SSAS also pro= vides proof of IP address ownership as does CGA.  The question here is= not that but is on the security considerations that are based on my calcul= ations with regard to the probability of being able to break it. I believe that what Christian says is not true, bu= t I will have to try it to prove him wrong. About other algorithms, CGA can= use them as well so you cannot compare the computational times based on th= e use of those algorithms.

 

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 8:34 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

I don’t think th= e index helps much. I suspect that SSAS could be broken in minutes if someo= ne did a parallel implementation on a GPU. Maybe seconds.=

 

Frankly, I believe tha= t you have fallen in the trap of “inventing your own crypto.” M= ost of these inventions turn out to have flaws, and won’t pass a seri= ous review. I would advise that you withdraw that specific proposal.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Sunday, March 17, 2013 11:47 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks again for your = response. I have some questions:

-    =       Choosing a random part of the public k= ey does not help to increase the probability of matching the public key to = the IID?

if I am to impr= ove this section and by saying we need to generate two, one byte random num= bers such that the second byte must not be higher than the size of public k= ey minus 6.

-    =       How many days does it take to break SS= AS?  I ask this because for privacy I consider changing the key pairs = and creating a new IP address in a certain time frame.

 

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 5:46 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

On the other hand, cra= cking SSAS is *much* easier than cracking RSA, or even cracking CGA.=

 

SSAS builds the 64 bit= identifier as follow:

·Pick a random 16 bit number;

·Use that number as an index in the bit= array representing the public key;

·Extract the 48 bits following the inde= x;

·Concatenate the random 16 bit number a= nd the 48 bits of the key to build a 64 bit interface ID;=

·Prove possession of the public/private= key pair when using the resulting IPv6 address.

 

An attacker can obviou= sly break that scheme in about 2**48 trials, by generating a set of random&= nbsp; public/private key pairs. For each generated key, there is 2**-48 pro= bability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public k= ey in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 a= ddress. They can then select that key pair, and spoof the IPv6 SSAS address= at will.

 

2**48 is much less tha= n the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 o= r SEC=3D2.

 

You may think that bui= lding public/private key pairs is a very expensive operation, but that is n= ot true. The default algorithm for SSAS is RSA. Let’s suppose you use= 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we ne= ed about 2*25 such numbers. Add a margin to be on the safe side. These numb= ers can be generated once, they don’t have to be regenerated for ever= y SSAS key being tried.

 

An RSA key is the prod= uct of two such numbers. 2*25 numbers allow you to compute 2**48 products, = i.e. 2**48 candidate public keys. Computing a long integer product does tak= e a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint w= ill be very quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You = answered my question. This is what I wanted to know about security when dir= ectly using keys or using in the way CGA does. Both are difficult but the C= GA way is relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *rela= tively* easier. It is not “easy.” It is much harder to crac= k RSA than to find a matching hash. Cracking a 2048 bits RSA key probably r= equires on the order of 2^1024 trials, and that will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetime of the address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SECR= 21; part of CGA is meant to protect against a different attack, one in whic= h the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. T= his “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than >what is required to c= rack RSA or ECC.

 

So according to what I= understand from what you wrote, the sec value makes the for an easier atta= ck against CGA as the attacker only needs to find the same value generated = by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if thi= s gives an attacker a leg up in doing his brute force attacks why do we nee= d to add those steps to CGA. This was why I used the direct public key as a= part of IP address.

 

Thanks again Christian= .

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02A2TK5EX14MBXC273r_-- From ietf@rozanak.com Sun Mar 17 18:51:48 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32B021F8AE3; Sun, 17 Mar 2013 18:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D497cloyX+6n; Sun, 17 Mar 2013 18:51:37 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 1390421F89CC; Sun, 17 Mar 2013 18:51:37 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MTjeS-1U8VIY21Ue-00R7Ry; Sun, 17 Mar 2013 21:51:33 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> <000301ce233f$d6c35380$8449fa80$@rozanak.com> <002001ce2371$425582e0$c70088a0$@rozanak.com> In-Reply-To: Date: Mon, 18 Mar 2013 02:51:18 +0100 Message-ID: <003701ce237b$1c085220$5418f660$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CE2383.7DD65710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLgJ/3rcyAgRh1nIB5BhzHAEy9iDWAc5CldoCu7fgvQIy/Ge/AgQq5DiX5z5CwA== Content-Language: en-us X-Provags-ID: V02:K0:EVUQjHvySyefh6RZX/4z86Ws+tk2O60USAYl1kRgk7g e2wfnPGoBh9Mqj+xjDcMuZddgDS+KYNwT6tT845HIqxJslSllo Wi9w78Si3GtTbfKqnhkPxUn9LzSsPW4o/OL+KFrpfcZC/qap0e fIvdj+MGRaIoTf/vrbpQppks762wvwvxIh4Nnh1urPMxRDzf/q tYbz5SLCqkuXiKA+txZAKubtZkbgITgjnsseMB9KTNuc3wCTGp b4mcMlZorFwPMkofR3Mul0zhhRUEjIUz/T8PQghwzoGzbdwqrq vsr1z92bY9HNlp+9H/2L/2H2WVcuImBfkdJMtO7gM7CLzEfNqb ZJZI6AlObuX5u3FfGU0g= Cc: alexandru.petrescu@gmail.com, Francis.Dupont@fdupont.fr, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 01:51:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0038_01CE2383.7DD65710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not try it in a standard pc. We have a powerful giant super computer, see here http://www.hpi.uni-potsdam.de/forschung/future_soc_lab/lab/the_lab_and_its_r esources.html?L=1 Thanks, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Monday, March 18, 2013 2:44 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; Francis.Dupont@fdupont.fr; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hosnieh, making your own breaking code is a good exercise and you will certainly learn a lot. However, you will only obtain a "maximum" estimate of the breaking time. For example, if you could break the algorithm in 1000 hours, that mean opponents will be able to break it in 1000 hours *or less.*Often, that will be much less. Key points in robustness are, for example: 1) How many bits? To give an example, 56 bits DES keys can be broken in seconds using special purpose equipment. AES uses 128 or 256 bit keys, especially for that purpose. Generally, we want to increase the number of bits as Moore's law progresses. 2) Can it be parallelized? If it can, that means an attacker can solve it much faster using more computers. Think for example of a GPU with the equivalent of 1000 parallel processors, or a botnet with 1M machines, or even worse a botnet with 1M machines each with a GPU. 3) Can part of the solutions be computed in advance? The famous examples are the "rainbow table" that could be used to crack hashes of passwords, if these hashes were not protected by some "salt." SSAS is weak on all these counts. Part of the solution can be computed in advance: 2^25 bit prime numbers about 1024 bit long occupy 2^32 octets, i.e. a gigabyte. That can be stored, copied and distributed easily. The breaking algorithm can be parallelized trivially: have millions of nodes in the botnet each pick random seeds, and explore different parts of the solution. The number of bits is fixed to 62 bits at most, which means that as Moore's law progresses SSAS is bound to get ever weaker, with no space to grow. The SEC scheme in CGA was specifically designed to address these weaknesses. Including the prefix in the hash prevents the use of "rainbow tables." The hash only uses 59 bits because some bits are reserved for the SEC field, but the SEC fields allows for robust extensions of the hash length as Moore's law progresses. This allows node to trade off robustness versus address generation time. CGA implementers concerned with parallelized attacks have the choice of making the hash virtually longer by using larger SEC values - 20 extra bits will mitigate the 1M botnet. From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Sunday, March 17, 2013 5:41 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; Francis.Dupont@fdupont.fr; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks Christian, Here is what I propose. I have an implementation of SSAS and I will try to break it to see how long it will take. (I will also share the code with others so that more people can try to break it.) Based on the mathematical calculations (of finding the expected value) the probability of it being broken in one month is very low. Since we also want to use this for the integration of privacy, then this is secure enough. But perhaps with my implementation of the attacks against SSAS I can learn the what happens in realtime as opposed to mathematical theory. I have my doubts about what you said about being able to break it in seconds. I am sorry but I feel that what you said is really unrealistic. If you really are able to implement something that does this, then you probably would be able to break CGA in seconds also. About the modifier that I have, I will also check to determine whether using makes breaking it easier or harder. If it is easier. then I will use the entire 64 bits of the public key (set bit u and g) and use the fixed part of the public key. I am not trying to create a new hash algorithm but only make improvements to my algorithm. Francis: SSAS also provides proof of IP address ownership as does CGA. The question here is not that but is on the security considerations that are based on my calculations with regard to the probability of being able to break it. I believe that what Christian says is not true, but I will have to try it to prove him wrong. About other algorithms, CGA can use them as well so you cannot compare the computational times based on the use of those algorithms. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 8:34 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas I don't think the index helps much. I suspect that SSAS could be broken in minutes if someone did a parallel implementation on a GPU. Maybe seconds. Frankly, I believe that you have fallen in the trap of "inventing your own crypto." Most of these inventions turn out to have flaws, and won't pass a serious review. I would advise that you withdraw that specific proposal. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 11:47 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks again for your response. I have some questions: - Choosing a random part of the public key does not help to increase the probability of matching the public key to the IID? if I am to improve this section and by saying we need to generate two, one byte random numbers such that the second byte must not be higher than the size of public key minus 6. - How many days does it take to break SSAS? I ask this because for privacy I consider changing the key pairs and creating a new IP address in a certain time frame. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 5:46 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas On the other hand, cracking SSAS is *much* easier than cracking RSA, or even cracking CGA. SSAS builds the 64 bit identifier as follow: . Pick a random 16 bit number; . Use that number as an index in the bit array representing the public key; . Extract the 48 bits following the index; . Concatenate the random 16 bit number and the 48 bits of the key to build a 64 bit interface ID; . Prove possession of the public/private key pair when using the resulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by generating a set of random public/private key pairs. For each generated key, there is 2**-48 probability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public key in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They can then select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=0 algorithm, let alone using SEC=1 or SEC=2. You may think that building public/private key pairs is a very expensive operation, but that is not true. The default algorithm for SSAS is RSA. Let's suppose you use 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we need about 2*25 such numbers. Add a margin to be on the safe side. These numbers can be generated once, they don't have to be regenerated for every SSAS key being tried. An RSA key is the product of two such numbers. 2*25 numbers allow you to compute 2**48 products, i.e. 2**48 candidate public keys. Computing a long integer product does take a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint will be very quick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know about security when directly using keys or using in the way CGA does. Both are difficult but the CGA way is relatively easier than cracking the RSA keys. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to crack RSA than to find a matching hash. Cracking a 2048 bits RSA key probably requires on the order of 2^1024 trials, and that will take you something like "forever." Cracking the hash requires only something on the order of 2^91 trials with SEC=2. That's obviously much less, but that's still a very large number. The exhausting search will take you many years, i.e. much more than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_0038_01CE2383.7DD65710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not try it in a standard pc. We have a = powerful giant super computer, see here http://www.hpi.uni-potsdam.de/forschung/f= uture_soc_lab/lab/the_lab_and_its_resources.html?L=3D1 =

 

Thanks,

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Monday, March 18, 2013 2:44 AM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: alexandru.petrescu@gmail.com; = Francis.Dupont@fdupont.fr; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; = 'Ray Hunter'; jeanmichel.combes@orange.com
Subject: RE: = security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hosnieh, making your own breaking code is a good = exercise and you will certainly learn a lot. However, you will only = obtain a “maximum” estimate of the breaking time.  For = example, if you could break the algorithm in 1000 hours, that mean = opponents will be able to break it in 1000 hours *or less.*Often, = that will be much less. Key points in robustness are, for = example:

 

1)      = How many bits? To give an example, = 56 bits DES keys can be broken in seconds using special purpose = equipment. AES uses 128 or 256 bit keys, especially for that purpose. = Generally, we want to increase the number of bits as Moore’s law = progresses.

2)      = Can it be parallelized? If it can, = that means an attacker can solve it much faster using more computers. = Think for example of a GPU with the equivalent of 1000 parallel = processors, or a botnet with 1M machines, or even worse a botnet with 1M = machines each with a GPU.

3)      = Can part of the solutions be = computed in advance? The famous examples are the “rainbow = table” that could be used to crack hashes of passwords, if these = hashes were not protected by some = “salt.”

 

SSAS is weak on all = these counts. Part of the solution can be computed in advance: 2^25 bit = prime numbers about 1024 bit long occupy 2^32 octets, i.e. a gigabyte. = That can be stored, copied and distributed easily. The breaking = algorithm can be parallelized trivially: have millions of nodes in the = botnet each pick random seeds, and explore different parts of the = solution. The number of bits is fixed to 62 bits at most, which means = that as Moore’s law progresses SSAS is bound to get ever weaker, = with no space to grow.

 

The SEC scheme in CGA = was specifically designed to address these weaknesses. Including the = prefix in the hash prevents the use of “rainbow tables.” The = hash only uses 59 bits because some bits are reserved for the SEC field, = but the SEC fields allows for robust extensions of the hash length as = Moore’s law progresses. This allows node to trade off robustness = versus address generation time. CGA implementers concerned with = parallelized attacks have the choice of making the hash virtually longer = by using larger SEC values – 20 extra bits will mitigate the 1M = botnet.

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Sunday, March 17, = 2013 5:41 PM
To: Christian Huitema; ipv6@ietf.org; saag@ietf.org
Cc: alexandru.petrescu@gmail.com= ; Francis.Dupont@fdupont.fr; = 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com=
Subject: RE: security consideration of CGA and SSAS - = Ii-D action : draft-rafiee-6man-ssas

 

Thanks Christian,

Here is what I propose. = I have an implementation of SSAS and I will try to break it to see how = long it will take. (I will also share the code with others so  that = more people can try to break it.)  Based on the mathematical = calculations (of finding the expected value) the probability of it being = broken in one month is very low. Since we also want to use this for the = integration of privacy, then this is secure enough. But perhaps with my = implementation of the attacks against  SSAS I can learn the what = happens in realtime as opposed to mathematical theory. I have my doubts = about what you said about being able to break it in seconds. I am sorry = but I feel that what you said is really unrealistic. If you really are = able to implement something that does this, then you  probably = would be able to break CGA in seconds also.

About the modifier that = I have, I will also check to determine whether using makes breaking it = easier or harder. If it is easier. then I will use the entire 64 bits of = the public key (set bit u and g) and use the fixed part of the public = key.

I am not trying to create a new hash algorithm = but only make improvements to  my = algorithm.

 

Francis: SSAS also = provides proof of IP address ownership as does CGA.  The question = here is not that but is on the security considerations that are based on = my calculations with regard to the probability of being able to break = it. I believe that what Christian says is not true, but I will have to = try it to prove him wrong. About other algorithms, CGA can use them as = well so you cannot compare the computational times based on the use of = those algorithms.

 

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 8:34 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

I don’t think the index helps much. I = suspect that SSAS could be broken in minutes if someone did a parallel = implementation on a GPU. Maybe seconds.

 

Frankly, I believe that = you have fallen in the trap of “inventing your own crypto.” = Most of these inventions turn out to have flaws, and won’t pass a = serious review. I would advise that you withdraw that specific = proposal.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Sunday, March 17, 2013 11:47 AM
To: Christian = Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks again for your response. I have some = questions:

-       &= nbsp;  Choosing a random part = of the public key does not help to increase the probability of matching = the public key to the IID?

if I am to = improve this section and by saying we need to generate two, one byte = random numbers such that the second byte must not be higher than the = size of public key minus 6.

-       &= nbsp;  How many days does it = take to break SSAS?  I ask this because for privacy I consider = changing the key pairs and creating a new IP address in a certain time = frame.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 5:46 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

On the other hand, cracking SSAS is = *much* easier than cracking RSA, or even cracking = CGA.

 

SSAS builds the 64 bit = identifier as follow:

·       &= nbsp; Pick a random 16 bit = number;

·       &= nbsp; Use that number as an index = in the bit array representing the public key;

·       &= nbsp; Extract the 48 bits following = the index;

·       &= nbsp; Concatenate the random 16 bit = number and the 48 bits of the key to build a 64 bit interface = ID;

·       &= nbsp; Prove possession of the = public/private key pair when using the resulting IPv6 = address.

 

An attacker can = obviously break that scheme in about 2**48 trials, by generating a set = of random  public/private key pairs. For each generated key, there = is 2**-48 probability that the indexed bits match the 48 bit thumbprint. = In about 2**48 trials, the attacker will get a public key in which the = 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They = can then select that key pair, and spoof the IPv6 SSAS address at = will.

 

2**48 is much less than = the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 = or SEC=3D2.

 

You may think that = building public/private key pairs is a very expensive operation, but = that is not true. The default algorithm for SSAS is RSA. Let’s = suppose you use 2048 bit long RSA keys. The key generation start by = generating a set of 1024 bit long prime numbers. In theory, we need = about 2*25 such numbers. Add a margin to be on the safe side. These = numbers can be generated once, they don’t have to be regenerated = for every SSAS key being tried.

 

An RSA key is the = product of two such numbers. 2*25 numbers allow you to compute 2**48 = products, i.e. 2**48 candidate public keys. Computing a long integer = product does take a few computations, but not much more than computing a = SHA hash. The search for a key that match the footprint will be very = quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian = Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You answered my question. This = is what I wanted to know about security when directly using keys or = using in the way CGA does. Both are difficult but the CGA way is = relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *relatively* easier. It is = not “easy.” It is much harder to crack RSA than to find a = matching hash. Cracking a 2048 bits RSA key probably requires on the = order of 2^1024 trials, and that will take you something like = “forever.” Cracking the hash requires only something on the = order of 2^91 trials with SEC=3D2. That’s obviously much less, but = that’s still a very large number. The exhausting search will take = you many years, i.e. much more than the valid lifetime of the = address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 1:45 PM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SEC” part of CGA is meant = to protect against a different attack, one in which the attacker has not = cracked the private key. Instead, the attacker uses a public/private key = pair of his own >choosing, and arrange for the hash of that key to = match the CGA address of the target. This “only” requires = O(2**(59+SEC*16)) operations, which even with large values of SEC is = still far less than >what is required to crack RSA or = ECC.

 

So according to what I = understand from what you wrote, the sec value makes the for an easier = attack against CGA as the attacker only needs to find the same value = generated by his own modifier and other parameters and matches this to = the IID of the node. Now the question again is, if this gives an = attacker a leg up in doing his brute force attacks why do we need to add = those steps to CGA. This was why I used the direct public key as a part = of IP address.

 

Thanks again = Christian.

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack that you mention depends = on the strength of RSA or ECC. In fact, pretty much all of public key = cryptography depends on that strength. It is generally assumed that = cracking a long enough RSA or ECC key is nearly impossible. =

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which = the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own choosing, and arrange for the hash = of that key to match the CGA address of the target. This = “only” requires O(2**(59+SEC*16)) operations, which even = with large values of SEC is still far less than what is required to = crack RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 10:59 AM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

 

>Did you somehow = crack RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: RE: security consideration of CGA = and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_0038_01CE2383.7DD65710-- From huitema@microsoft.com Sun Mar 17 19:04:24 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD0521F89A6; Sun, 17 Mar 2013 19:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1u0Glw+nRHV; Sun, 17 Mar 2013 19:04:17 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 356E821F88D8; Sun, 17 Mar 2013 19:04:16 -0700 (PDT) Received: from BY2FFO11FD016.protection.gbl (10.1.15.202) by BY2FFO11HUB040.protection.gbl (10.1.14.161) with Microsoft SMTP Server (TLS) id 15.0.641.9; Mon, 18 Mar 2013 02:04:13 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.148) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Mon, 18 Mar 2013 02:04:13 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Mon, 18 Mar 2013 02:03:47 +0000 From: Christian Huitema To: Santosh Chokhani , Hosnieh Rafiee , "ipv6@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: AQHOI3kFT84WiQdYAEK5wH5DPL02MJiqrZPw Date: Mon, 18 Mar 2013 02:03:46 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02E2TK5EX14MBXC273r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(43784002)(57704001)(377454001)(512954001)(77982001)(59766001)(76482001)(47976001)(47736001)(46102001)(16236675001)(53806001)(65816001)(51856001)(69226001)(31966008)(79102001)(66066001)(56816002)(16406001)(80022001)(5343635001)(47446002)(44976002)(54356001)(5343655001)(15202345001)(50986001)(561944001)(55846006)(54316002)(63696002)(49866001)(20776003)(74502001)(74662001)(4396001)(56776001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB040; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07891BF289 Cc: 'Ray Hunter' , "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , "jeanmichel.combes@orange.com" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 02:04:24 -0000 --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02E2TK5EX14MBXC273r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Santosh, I suppose we have to use more than 2048 bits for RSA then... But t= hat's not really the point of the debate. CGA is an algorithm specified for IPv6 "secure neighbor discovery" and is s= pecified in RFC 3972. CGA works by associating an IPv6 address with a publi= c key. The public key is hashed with the network prefix (first 64 bits of I= Pv6 address) and 59 bits of the hash are copied to the host identifier part= of the IPv6 address. In the most basic implementation, senders prove owner= ship of the address by demonstrating possession of a public/private key pai= r, and receiver verify also that the specified 59 bits of the hash match wh= at is in the address. Of course, 59 bits is a rather small number, and matching only 59 bits inst= ead of 160 seriously weakens the strength of the algorithm. The CGA spec in= cludes a "hash augmentation" mechanism, the "SEC" fields, which specifies a= n additional constraint on the content of the hash, namely that the hash be= gins by a set number of zeroes - 16 times the number in the SEC field. That= mechanism requires that the host generating a secure address spends some t= ime finding the right hash. Hosnieh proposes to replace that mechanism by simply copying in the IPv6 ad= dress a number of bits from the public key - 48 in the original proposal. From: Santosh Chokhani [mailto:SChokhani@cygnacom.com] Sent: Sunday, March 17, 2013 6:36 PM To: Christian Huitema; Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik Nordma= rk'; 'Ray Hunter'; jeanmichel.combes@orange.com Subject: RE: [saag] security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas 2048 bit RSA security is overstated. Cracking it requires on the order of = 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2 Sectio= n 5.6.1. >From the description you provide on hashing, finding a second hash is a sec= ond pre-image attack and for SHA-1 the security strength is 160 bits, i.e.,= you need on the order of 2^160 operations. I do not know what hash function you are describing for the function you me= ntion and how you derived its security strength. From: saag-bounces@ietf.org [mailto:saag-boun= ces@ietf.org] On Behalf Of Christian Huitema Sent: Sunday, March 17, 2013 4:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: alexandru.petrescu@gmail.com; 'Roq= ue Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@o= range.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to c= rack RSA than to find a matching hash. Cracking a 2048 bits RSA key probabl= y requires on the order of 2^1024 trials, and that will take you something = like "forever." Cracking the hash requires only something on the order of 2= ^91 trials with SEC=3D2. That's obviously much less, but that's still a ver= y large number. The exhausting search will take you many years, i.e. much m= ore than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.c= om; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one = in which the attacker has not cracked the private key. Instead, the attacke= r uses a public/private key pair of his own >choosing, and arrange for the = hash of that key to match the CGA address of the target. This "only" requir= es O(2**(59+SEC*16)) operations, which even with large values of SEC is sti= ll far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes = the for an easier attack against CGA as the attacker only needs to find the= same value generated by his own modifier and other parameters and matches = this to the IID of the node. Now the question again is, if this gives an at= tacker a leg up in doing his brute force attacks why do we need to add thos= e steps to CGA. This was why I used the direct public key as a part of IP a= ddress. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or E= CC. In fact, pretty much all of public key cryptography depends on that str= ength. It is generally assumed that cracking a long enough RSA or ECC key i= s nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one i= n which the attacker has not cracked the private key. Instead, the attacker= uses a public/private key pair of his own choosing, and arrange for the ha= sh of that key to match the CGA address of the target. This "only" requires= O(2**(59+SEC*16)) operations, which even with large values of SEC is still= far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key fr= om the public key and a clear text/encrypted text pair is easier than break= ing a hash? Here we do not use any encryption and decryption and we just sign the messa= ge using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key.= Because for both SSAS and CGA, public/private keys are used. I do say that= the SHAx steps used for CGA generation do not increase the complexity when= used against brute force attacks. This is because an attacker only needs t= he private key and does not need to find the modifier that was used in the = generation of the node's IID nor is there a need for checking the condition= of sec by 16 bits which should be equal to zero. In SSAS I just use the pu= blic/private keys and the signature and nothing is encrypted/decrypted. In = CGA some extra SHAx steps are used in the generation of their IID along wit= h the signature. I say that these steps are not needed as long as you inclu= de and send all parameters, used in the SHAx process, in the packet for ver= ification purposes. Some people feel that CGA is secure enough when those = steps are used. Now what I want to point out here is that the CGA security = level is only dependent on the algorithm used for key pair and signature ge= neration and that those extra steps do nothing enhance the security side of= things. The algorithms used can be RSA or ECC or whatever, and as such the= situation will be the same as it is for SSAS. I just removed the complexit= y from the use of CGA in order to enable a more practical and faster genera= tion and verification process. So the question isn't how to break the encrypted text but how to break the = signature. In other word, to find the same public key as used by the gener= ator node or how to break the RSA or ECC. Based on my knowledge of hash alg= orithms, as I mentioned in my prior sentence, this will depend on the stren= gth of the RSA or whatever other algorithm is used to generate these keys = and sign the message. If you or anyone else thinks otherwise, please contri= bute to this discussion and share your opinions. I am just comparing the se= curity aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-r= afiee-6man-ssas It is very clear that if the attacker finds the private key, the size of th= e hash does not matter. But can you explain why you believe that retrieving= the private key from the public key and a clear text/encrypted text pair i= s easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-boun= ces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafie= e-6man-ssas Hello, There was a discussion during my presentation about security considerations= regarding the use of my algorithm compared with those of the use of CGA. A= big mistake that is made when considering CGA security is that the sec val= ue plays an important role and that an attacker will need to do brute force= attacks against the IID in order to generate the same IID as is generated = by the use of CGA. In a CGA analysis paper they talk about a CGA security v= aulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the ex= ponential value and so they infer that by increasing the sec value used wit= h CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This i= s because you have already included the CGA parameters (public key, modifie= r, and other required parameters) in the packet that was sent and I will h= ave no problem in regenerating the CGA. My only problem will be in generati= ng the signature that can be verified by use of your public key. This means= that you just increased the complexity and time required for generating an= d verifying the IID while with SSAS you can obtain the same security as whe= n using CGA because its security also depends on the Hash function that is = used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS= etc., then, in that case, CGA would be more secure than SSAS. But in pract= ice all the data is sent in the same packet without encryption. If a secure= d channel would be used in the CGA process for security reasons (sending CG= A parameters), then the cost of using CGA would be much greater than the co= st of using SSAS. Now the question is, Why not use a more cost efficient algorithm that affor= d you with the same security level as when using CGA. I have also included the security group in this email so that they can also= give me any comments that they might have. Thank you, Hosnieh --_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02E2TK5EX14MBXC273r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Santosh, I suppose we = have to use more than 2048 bits for RSA then… But that’s not re= ally the point of the debate.

 

CGA is an algorithm sp= ecified for IPv6 “secure neighbor discovery” and is specified i= n RFC 3972. CGA works by associating an IPv6 address with a public key. The= public key is hashed with the network prefix (first 64 bits of IPv6 address) and 59 bits of the hash are copied to the host id= entifier part of the IPv6 address. In the most basic implementation, sender= s prove ownership of the address by demonstrating possession of a public/pr= ivate key pair, and receiver verify also that the specified 59 bits of the hash match what is in the address.<= o:p>

 

Of course, 59 bits is = a rather small number, and matching only 59 bits instead of 160 seriously w= eakens the strength of the algorithm. The CGA spec includes a “hash a= ugmentation” mechanism, the “SEC” fields, which specifies an additional constraint on the content of the hash, namel= y that the hash begins by a set number of zeroes – 16 times the numbe= r in the SEC field. That mechanism requires that the host generating a secu= re address spends some time finding the right hash.

 

Hosnieh proposes to re= place that mechanism by simply copying in the IPv6 address a number of bits= from the public key – 48 in the original proposal.

 

From: Santosh Chokhani [mailto:SChokhani@cygn= acom.com]
Sent: Sunday, March 17, 2013 6:36 PM
To: Christian Huitema; Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org<= br> Cc: alexandru.petrescu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik= Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com
Subject: RE: [saag] security consideration of CGA and SSAS - Ii-D ac= tion : draft-rafiee-6man-ssas

 

2048 bit RSA security = is overstated.  Cracking it requires on the order of 2^112 operations.=   You should look at NIST SP 800-57 Part 2, Table 2 Section 5.6.1.

 

From the description y= ou provide on hashing, finding a second hash is a second pre-image attack a= nd for SHA-1 the security strength is 160 bits, i.e., you need on the order= of 2^160 operations.

 

I do not know what has= h function you are describing for the function you mention and how you deri= ved its security strength.

 

From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Sunday, March 17, 2013 4:14 AM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: alexandru.petres= cu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik Nordmark'; 'Ray Hunter= '; jeanmichel.combes@orange.co= m
Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D ac= tion : draft-rafiee-6man-ssas

 

The attack is *rela= tively* easier. It is not “easy.” It is much harder to crac= k RSA than to find a matching hash. Cracking a 2048 bits RSA key probably r= equires on the order of 2^1024 trials, and that will take you something like “forever.” Cracking the hash requ= ires only something on the order of 2^91 trials with SEC=3D2. That’s = obviously much less, but that’s still a very large number. The exhaus= ting search will take you many years, i.e. much more than the valid lifetime of the address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 1:45 PM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.co= m; 'Roque Gagliano (rogaglia)'
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SECR= 21; part of CGA is meant to protect against a different attack, one in whic= h the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. T= his “only” requires O(2**(59+SEC*16)) operations, which eve= n with large values of SEC is still far less than >what is required to c= rack RSA or ECC.

 

So according to what I= understand from what you wrote, the sec value makes the for an easier atta= ck against CGA as the attacker only needs to find the same value generated = by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if thi= s gives an attacker a leg up in doing his brute force attacks why do we nee= d to add those steps to CGA. This was why I used the direct public key as a= part of IP address.

 

Thanks again Christian= .

Hosnieh

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack= that you mention depends on the strength of RSA or ECC. In fact, pretty mu= ch all of public key cryptography depends on that strength. It is generally= assumed that cracking a long enough RSA or ECC key is nearly impossible.

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which th= e attacker has not cracked the private key. Instead, the attacker uses a pu= blic/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This R= 20;only” requires O(2**(59+SEC*16)) operations, which even with l= arge values of SEC is still far less than what is required to crack RSA or = ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com]
Sent: Saturday, March 16, 2013 10:59 AM
To: Christian Huitema; ipv6@ietf.or= g; saag@ietf.org
Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.co= m; Roque Gagliano (rogaglia)
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou ex= plain why you believe that retrieving the private key from the public key a= nd a clear text/encrypted text pair is easier than breaking a hash?

 

Here we do not use any= encryption and decryption and we just sign the message using private key a= nd verify the message using public key.

 

>Did you somehow cr= ack RSA?

 

I do not say that it i= s easier to find the private key from the public key. Because for both SSAS= and CGA, public/private keys are used. I do say that the SHAx steps used f= or CGA generation do not increase the complexity when used against brute force attacks. This is because an attac= ker only needs the private key and does not need to find the modifier that = was used in the generation of the node’s IID nor is there a need for = checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys = and the signature and nothing is encrypted/decrypted. In CGA some extra SHA= x steps are used in the generation of their IID along with the signature. I= say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, = in the packet for verification purposes. Some people feel that CGA  is= secure enough when those steps are used. Now what I want to point out here= is that the CGA security level is only dependent on the algorithm used for key pair and signature gene= ration and that those extra steps do nothing enhance the security side of t= hings. The algorithms used can be RSA or ECC or whatever, and as such the s= ituation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to= enable a more practical and faster generation and verification process.

 

So the question isn= 217;t how to break the encrypted text but how to break the signature. In ot= her word,  to find the same public key as used by the generator node o= r how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend = on the strength of the RSA or whatever other  algorithm is used to gen= erate these keys and sign the message. If you or anyone else thinks otherwi= se, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS,= the time efficient algorithm, to those of CGA.

 

Thank you,<= /span>

Hosnieh

 

 

From: Christia= n Huitema [mailto:huitema@microsof= t.com]
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: RE: security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that = if the attacker finds the private key, the size of the hash does not matter= . But can you explain why you believe that retrieving the private key from = the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA?<= /o:p>

 

From: ipv6-bounces@ietf.org [mailt= o:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik Nordmark; a= lexandru.petrescu@gmail.com; Ray Hunter
Subject: security consideration of CGA and SSAS - Ii-D action : draf= t-rafiee-6man-ssas

 

Hello,

There was a discussion during my presentation about = security considerations regarding the use of my algorithm compared with tho= se of the use of CGA. A big mistake that is made when considering CGA secur= ity is that the sec value plays an important role and that an attacker will need to do brute force attacks ag= ainst the IID in order to generate the same IID as is generated by the use = of CGA. In a CGA analysis paper they talk about a CGA security vaulue of po= w (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by in= creasing the sec value used with CGA it will be safer, but this Is not true= .

I, as an attacker, just to need to find your private= key. That’s it. This is because you have already included the CGA pa= rameters (public key, modifier, and other required parameters) in the  = ;packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signatu= re that can be verified by use of your public key. This means that you just= increased the complexity and time required for generating and verifying th= e IID while with SSAS you can obtain the same security as when using CGA because its security also depends on t= he Hash function that is used to generate the key pair and signature.

If you send the CGA parameters via a safe channel, l= ike in establishing TLS etc., then, in that case, CGA would be more secure = than SSAS. But in practice all the data is sent in the same packet without = encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), = then the cost of using CGA would be much greater than the cost of using SSA= S.

 

Now the question is, Why not use a more cost effi= cient algorithm that afford you with the same security level as when using = CGA.

 

I have also included the security group in this emai= l so that they can also give me any comments that they might have.

 

Thank you,

Hosnieh

--_000_C91E67751B1EFF41B857DE2FE1F68ABA0BFD02E2TK5EX14MBXC273r_-- From Francis.Dupont@fdupont.fr Sun Mar 17 15:32:58 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AFC21F8B18; Sun, 17 Mar 2013 15:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpZ3N28JHkhY; Sun, 17 Mar 2013 15:32:58 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E529C21F8AF0; Sun, 17 Mar 2013 15:32:57 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2HMV3Lo073418; Sun, 17 Mar 2013 23:31:04 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303172231.r2HMV3Lo073418@givry.fdupont.fr> From: Francis Dupont To: Christian Huitema In-reply-to: Your message of Sun, 17 Mar 2013 08:14:07 GMT. Date: Sun, 17 Mar 2013 23:31:03 +0100 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 18 Mar 2013 09:57:15 -0700 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:32:58 -0000 I seconds Christian's argument: CGA was carefully designed to offer a security of the ownership property higher than you can get from a direct use of the interface ID. Of course this has a cost in CGA generation time (but not verification) at higher SEC values. Now about 48 bits of a RSA public key I am not a cryptographer nor believe this particular problem was analyzed but obviously the upper bound is 2**48 attempts with changing one of the two private primes and even checking primeness after differential multiply, i.e., a simple addition. I am afraid Christian is right and an attack is feasible in a delay shorter than usage duration (i.e., "weak" in the military crypto definition of this term). About RSA, signing is encryption of the message digest with a prefix so it is the same thing to break private key encryption or signing. About ECC, ECDSA has the interesting property than verifying is slower than signing. This comes from DSA itself, and ECDSA is as far as I know the only standard way to sign with ECC. Regards Francis.Dupont@fdupont.fr PS: of course I supports Christian's last advice (but you already know that :-). From Francis.Dupont@fdupont.fr Sun Mar 17 15:48:40 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBAB21F84E3; Sun, 17 Mar 2013 15:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOICjRVUgmYT; Sun, 17 Mar 2013 15:48:40 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 55A0A21F896E; Sun, 17 Mar 2013 15:48:39 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2HMkkjY074312; Sun, 17 Mar 2013 23:46:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303172246.r2HMkkjY074312@givry.fdupont.fr> From: Francis Dupont To: "Hosnieh Rafiee" In-reply-to: Your message of Sun, 17 Mar 2013 19:47:02 +0100. <000301ce233f$d6c35380$8449fa80$@rozanak.com> Date: Sun, 17 Mar 2013 23:46:46 +0100 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 18 Mar 2013 09:57:15 -0700 Cc: alexandru.petrescu@gmail.com, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , ipv6@ietf.org, 'Ray Hunter' , saag@ietf.org, jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Mar 2013 22:48:40 -0000 In your previous mail you wrote: > - Choosing a random part of the public key does not help to > increase the probability of matching the public key to the IID? => IMHO the main good effect of this is that it makes a dictionary of matching public key candidates not attractive... But this is not enough to make the problem hard to solve. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Mar 17 17:09:01 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDD721F86F0; Sun, 17 Mar 2013 17:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL9tCpIo4f-3; Sun, 17 Mar 2013 17:09:01 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5521F86E3; Sun, 17 Mar 2013 17:08:59 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2I077Re079359; Mon, 18 Mar 2013 01:07:07 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303180007.r2I077Re079359@givry.fdupont.fr> From: Francis Dupont To: Christian Huitema In-reply-to: Your message of Sun, 17 Mar 2013 19:33:53 GMT. Date: Mon, 18 Mar 2013 01:07:07 +0100 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 18 Mar 2013 09:57:15 -0700 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "jeanmichel.combes@orange.com" , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 00:09:01 -0000 In your previous mail you wrote: > I don't think the index helps much. I suspect that SSAS could be broken in > minutes if someone did a parallel implementation on a GPU. Maybe seconds. => you peak 2 primes for a standard RSA public key. You fix one and you divide the modulus to get an idea of the needed value for the second to match the 48 bits, and an increment for the bits to match position. Now you scan to get a prime which will give a matching modulus, using addition for computing the next modulus. The Hadamard-De la Vallee Poussin theorem (known in English as the prime number theorem says the distribution is n/ln(n), so as bc -l returns 710 for ln(2**1024) only at most 710 additions (which are as complex as carry propagation, so count for nothing) and primality checks are needed. I don't have the number for primality check speed but my i5 laptop checks 1000 times a 1024 bit prime (which is the worst case) in 7 seconds in a shell script. Regards Francis.Dupont@fdupont.fr From ietf@rozanak.com Sun Mar 17 17:41:15 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8F521F8B90; Sun, 17 Mar 2013 17:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dgmuvg42PEfW; Sun, 17 Mar 2013 17:41:06 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAAC21F8A3F; Sun, 17 Mar 2013 17:41:06 -0700 (PDT) Received: from kopoli (108-64-50-194.lightspeed.rcsntx.sbcglobal.net [108.64.50.194]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M91N7-1URXgd1aF3-00CPeT; Sun, 17 Mar 2013 20:41:02 -0400 From: "Hosnieh Rafiee" To: "'Christian Huitema'" , , References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> <000301ce233f$d6c35380$8449fa80$@rozanak.com> In-Reply-To: Date: Mon, 18 Mar 2013 01:40:46 +0100 Message-ID: <002001ce2371$425582e0$c70088a0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CE2379.A42164F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLgJ/3rcyAgRh1nIB5BhzHAEy9iDWAc5CldoCu7fgvZgIzgfg Content-Language: en-us X-Provags-ID: V02:K0:i7FqxbvG794BhwIXry6QUoZbMk75CM0hnOWiQ6LhvQ0 5CcZGl4CwlHHRJM8+H224RIBCGhO0U36uRen6khEzpuhu1bJeO QXN8FdqkmMhBarbVzYAC4LKCsmrPZJJtnQM1q5zpGM1FWjxjh7 PXV0ctStmOodrrSYu6SZFnkmyQzrWck4p0stndEqNtMxVTEjFe xIAKM8TNQa7bX5PTJVNATgOlw77N7cJCBRrs934Mmj6tx8bPWN Q3p/brWYTEDHw2xJWTQGohFZ6L1wMMWbwiRQry4cJUahEsiHtx iFluXrTt5xSsyGxxL28MuAUNrssj/1VMDbr1D0Em5oy22m7Y4W AaVE+ssDCT9ki9ug621c= X-Mailman-Approved-At: Mon, 18 Mar 2013 09:57:15 -0700 Cc: alexandru.petrescu@gmail.com, Francis.Dupont@fdupont.fr, "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , jeanmichel.combes@orange.com Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 00:41:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CE2379.A42164F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks Christian, Here is what I propose. I have an implementation of SSAS and I will try to break it to see how long it will take. (I will also share the code with others so that more people can try to break it.) Based on the mathematical calculations (of finding the expected value) the probability of it being broken in one month is very low. Since we also want to use this for the integration of privacy, then this is secure enough. But perhaps with my implementation of the attacks against SSAS I can learn the what happens in realtime as opposed to mathematical theory. I have my doubts about what you said about being able to break it in seconds. I am sorry but I feel that what you said is really unrealistic. If you really are able to implement something that does this, then you probably would be able to break CGA in seconds also. About the modifier that I have, I will also check to determine whether using makes breaking it easier or harder. If it is easier. then I will use the entire 64 bits of the public key (set bit u and g) and use the fixed part of the public key. I am not trying to create a new hash algorithm but only make improvements to my algorithm. Francis: SSAS also provides proof of IP address ownership as does CGA. The question here is not that but is on the security considerations that are based on my calculations with regard to the probability of being able to break it. I believe that what Christian says is not true, but I will have to try it to prove him wrong. About other algorithms, CGA can use them as well so you cannot compare the computational times based on the use of those algorithms. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 8:34 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas I don't think the index helps much. I suspect that SSAS could be broken in minutes if someone did a parallel implementation on a GPU. Maybe seconds. Frankly, I believe that you have fallen in the trap of "inventing your own crypto." Most of these inventions turn out to have flaws, and won't pass a serious review. I would advise that you withdraw that specific proposal. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 11:47 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks again for your response. I have some questions: - Choosing a random part of the public key does not help to increase the probability of matching the public key to the IID? if I am to improve this section and by saying we need to generate two, one byte random numbers such that the second byte must not be higher than the size of public key minus 6. - How many days does it take to break SSAS? I ask this because for privacy I consider changing the key pairs and creating a new IP address in a certain time frame. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 5:46 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas On the other hand, cracking SSAS is *much* easier than cracking RSA, or even cracking CGA. SSAS builds the 64 bit identifier as follow: . Pick a random 16 bit number; . Use that number as an index in the bit array representing the public key; . Extract the 48 bits following the index; . Concatenate the random 16 bit number and the 48 bits of the key to build a 64 bit interface ID; . Prove possession of the public/private key pair when using the resulting IPv6 address. An attacker can obviously break that scheme in about 2**48 trials, by generating a set of random public/private key pairs. For each generated key, there is 2**-48 probability that the indexed bits match the 48 bit thumbprint. In about 2**48 trials, the attacker will get a public key in which the 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They can then select that key pair, and spoof the IPv6 SSAS address at will. 2**48 is much less than the 2**59 figure for the CGA/Sec=0 algorithm, let alone using SEC=1 or SEC=2. You may think that building public/private key pairs is a very expensive operation, but that is not true. The default algorithm for SSAS is RSA. Let's suppose you use 2048 bit long RSA keys. The key generation start by generating a set of 1024 bit long prime numbers. In theory, we need about 2*25 such numbers. Add a margin to be on the safe side. These numbers can be generated once, they don't have to be regenerated for every SSAS key being tried. An RSA key is the product of two such numbers. 2*25 numbers allow you to compute 2**48 products, i.e. 2**48 candidate public keys. Computing a long integer product does take a few computations, but not much more than computing a SHA hash. The search for a key that match the footprint will be very quick! From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Sunday, March 17, 2013 9:22 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thanks Christian. You answered my question. This is what I wanted to know about security when directly using keys or using in the way CGA does. Both are difficult but the CGA way is relatively easier than cracking the RSA keys. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Sunday, March 17, 2013 9:14 AM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas The attack is *relatively* easier. It is not "easy." It is much harder to crack RSA than to find a matching hash. Cracking a 2048 bits RSA key probably requires on the order of 2^1024 trials, and that will take you something like "forever." Cracking the hash requires only something on the order of 2^91 trials with SEC=2. That's obviously much less, but that's still a very large number. The exhausting search will take you many years, i.e. much more than the valid lifetime of the address. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 1:45 PM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com; 'Roque Gagliano (rogaglia)' Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas >The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own >choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than >what is required to crack RSA or ECC. So according to what I understand from what you wrote, the sec value makes the for an easier attack against CGA as the attacker only needs to find the same value generated by his own modifier and other parameters and matches this to the IID of the node. Now the question again is, if this gives an attacker a leg up in doing his brute force attacks why do we need to add those steps to CGA. This was why I used the direct public key as a part of IP address. Thanks again Christian. Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 7:30 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas As you say, the attack that you mention depends on the strength of RSA or ECC. In fact, pretty much all of public key cryptography depends on that strength. It is generally assumed that cracking a long enough RSA or ECC key is nearly impossible. The "SEC" part of CGA is meant to protect against a different attack, one in which the attacker has not cracked the private key. Instead, the attacker uses a public/private key pair of his own choosing, and arrange for the hash of that key to match the CGA address of the target. This "only" requires O(2**(59+SEC*16)) operations, which even with large values of SEC is still far less than what is required to crack RSA or ECC. From: Hosnieh Rafiee [mailto:ietf@rozanak.com] Sent: Saturday, March 16, 2013 10:59 AM To: Christian Huitema; ipv6@ietf.org; saag@ietf.org Cc: 'Erik Nordmark'; alexandru.petrescu@gmail.com; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com; Roque Gagliano (rogaglia) Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hi Christian, > But can y toou explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Here we do not use any encryption and decryption and we just sign the message using private key and verify the message using public key. >Did you somehow crack RSA? I do not say that it is easier to find the private key from the public key. Because for both SSAS and CGA, public/private keys are used. I do say that the SHAx steps used for CGA generation do not increase the complexity when used against brute force attacks. This is because an attacker only needs the private key and does not need to find the modifier that was used in the generation of the node's IID nor is there a need for checking the condition of sec by 16 bits which should be equal to zero. In SSAS I just use the public/private keys and the signature and nothing is encrypted/decrypted. In CGA some extra SHAx steps are used in the generation of their IID along with the signature. I say that these steps are not needed as long as you include and send all parameters, used in the SHAx process, in the packet for verification purposes. Some people feel that CGA is secure enough when those steps are used. Now what I want to point out here is that the CGA security level is only dependent on the algorithm used for key pair and signature generation and that those extra steps do nothing enhance the security side of things. The algorithms used can be RSA or ECC or whatever, and as such the situation will be the same as it is for SSAS. I just removed the complexity from the use of CGA in order to enable a more practical and faster generation and verification process. So the question isn't how to break the encrypted text but how to break the signature. In other word, to find the same public key as used by the generator node or how to break the RSA or ECC. Based on my knowledge of hash algorithms, as I mentioned in my prior sentence, this will depend on the strength of the RSA or whatever other algorithm is used to generate these keys and sign the message. If you or anyone else thinks otherwise, please contribute to this discussion and share your opinions. I am just comparing the security aspects of SSAS, the time efficient algorithm, to those of CGA. Thank you, Hosnieh From: Christian Huitema [mailto:huitema@microsoft.com] Sent: Saturday, March 16, 2013 5:37 PM To: Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: RE: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas It is very clear that if the attacker finds the private key, the size of the hash does not matter. But can you explain why you believe that retrieving the private key from the public key and a clear text/encrypted text pair is easier than breaking a hash? Did you somehow crack RSA? From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Saturday, March 16, 2013 6:27 AM To: ipv6@ietf.org; saag@ietf.org Cc: Erik Nordmark; alexandru.petrescu@gmail.com; Ray Hunter Subject: security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hello, There was a discussion during my presentation about security considerations regarding the use of my algorithm compared with those of the use of CGA. A big mistake that is made when considering CGA security is that the sec value plays an important role and that an attacker will need to do brute force attacks against the IID in order to generate the same IID as is generated by the use of CGA. In a CGA analysis paper they talk about a CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and sec*16 * 59 is the exponential value and so they infer that by increasing the sec value used with CGA it will be safer, but this Is not true. I, as an attacker, just to need to find your private key. That's it. This is because you have already included the CGA parameters (public key, modifier, and other required parameters) in the packet that was sent and I will have no problem in regenerating the CGA. My only problem will be in generating the signature that can be verified by use of your public key. This means that you just increased the complexity and time required for generating and verifying the IID while with SSAS you can obtain the same security as when using CGA because its security also depends on the Hash function that is used to generate the key pair and signature. If you send the CGA parameters via a safe channel, like in establishing TLS etc., then, in that case, CGA would be more secure than SSAS. But in practice all the data is sent in the same packet without encryption. If a secured channel would be used in the CGA process for security reasons (sending CGA parameters), then the cost of using CGA would be much greater than the cost of using SSAS. Now the question is, Why not use a more cost efficient algorithm that afford you with the same security level as when using CGA. I have also included the security group in this email so that they can also give me any comments that they might have. Thank you, Hosnieh ------=_NextPart_000_0021_01CE2379.A42164F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Christian,

Here is what I propose. = I have an implementation of SSAS and I will try to break it to see how = long it will take. (I will also share the code with others so  that = more people can try to break it.)  Based on the mathematical = calculations (of finding the expected value) the probability of it being = broken in one month is very low. Since we also want to use this for the = integration of privacy, then this is secure enough. But perhaps with my = implementation of the attacks against  SSAS I can learn the what = happens in realtime as opposed to mathematical theory. I have my doubts = about what you said about being able to break it in seconds. I am sorry = but I feel that what you said is really unrealistic. If you really are = able to implement something that does this, then you  probably = would be able to break CGA in seconds also.

About the modifier that = I have, I will also check to determine whether using makes breaking it = easier or harder. If it is easier. then I will use the entire 64 bits of = the public key (set bit u and g) and use the fixed part of the public = key.

I am not trying to create a new hash algorithm = but only make improvements to  my = algorithm.

 

Francis: SSAS also = provides proof of IP address ownership as does CGA.  The question = here is not that but is on the security considerations that are based on = my calculations with regard to the probability of being able to break = it. I believe that what Christian says is not true, but I will have to = try it to prove him wrong. About other algorithms, CGA can use them as = well so you cannot compare the computational times based on the use of = those algorithms.

 

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com]
Sent: = Sunday, March 17, 2013 8:34 PM
To: Hosnieh Rafiee; = ipv6@ietf.org; saag@ietf.org
Cc: 'Erik Nordmark'; = alexandru.petrescu@gmail.com; 'Ray Hunter'; 'Michael Richardson'; = jeanmichel.combes@orange.com; 'Roque Gagliano = (rogaglia)'
Subject: RE: security consideration of CGA and = SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

I don’t think the index helps much. I = suspect that SSAS could be broken in minutes if someone did a parallel = implementation on a GPU. Maybe seconds.

 

Frankly, I believe that = you have fallen in the trap of “inventing your own crypto.” = Most of these inventions turn out to have flaws, and won’t pass a = serious review. I would advise that you withdraw that specific = proposal.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Sunday, March 17, 2013 11:47 AM
To: Christian = Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks again for your response. I have some = questions:

-       &= nbsp;  Choosing a random part = of the public key does not help to increase the probability of matching = the public key to the IID?

if I am to = improve this section and by saying we need to generate two, one byte = random numbers such that the second byte must not be higher than the = size of public key minus 6.

-       &= nbsp;  How many days does it = take to break SSAS?  I ask this because for privacy I consider = changing the key pairs and creating a new IP address in a certain time = frame.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 5:46 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

On the other hand, cracking SSAS is = *much* easier than cracking RSA, or even cracking = CGA.

 

SSAS builds the 64 bit = identifier as follow:

·       &= nbsp; Pick a random 16 bit = number;

·       &= nbsp; Use that number as an index = in the bit array representing the public key;

·       &= nbsp; Extract the 48 bits following = the index;

·       &= nbsp; Concatenate the random 16 bit = number and the 48 bits of the key to build a 64 bit interface = ID;

·       &= nbsp; Prove possession of the = public/private key pair when using the resulting IPv6 = address.

 

An attacker can = obviously break that scheme in about 2**48 trials, by generating a set = of random  public/private key pairs. For each generated key, there = is 2**-48 probability that the indexed bits match the 48 bit thumbprint. = In about 2**48 trials, the attacker will get a public key in which the = 48 bits happen to match the 48 bit thumbprint in the IPv6 address. They = can then select that key pair, and spoof the IPv6 SSAS address at = will.

 

2**48 is much less than = the 2**59 figure for the CGA/Sec=3D0 algorithm, let alone using SEC=3D1 = or SEC=3D2.

 

You may think that = building public/private key pairs is a very expensive operation, but = that is not true. The default algorithm for SSAS is RSA. Let’s = suppose you use 2048 bit long RSA keys. The key generation start by = generating a set of 1024 bit long prime numbers. In theory, we need = about 2*25 such numbers. Add a margin to be on the safe side. These = numbers can be generated once, they don’t have to be regenerated = for every SSAS key being tried.

 

An RSA key is the = product of two such numbers. 2*25 numbers allow you to compute 2**48 = products, i.e. 2**48 candidate public keys. Computing a long integer = product does take a few computations, but not much more than computing a = SHA hash. The search for a key that match the footprint will be very = quick!

 

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Sunday, March 17, 2013 9:22 AM
To: Christian = Huitema; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Thanks Christian. You answered my question. This = is what I wanted to know about security when directly using keys or = using in the way CGA does. Both are difficult but the CGA way is = relatively easier than cracking the RSA keys.

 

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Sunday, March 17, 2013 9:14 AM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

The attack is *relatively* easier. It is = not “easy.” It is much harder to crack RSA than to find a = matching hash. Cracking a 2048 bits RSA key probably requires on the = order of 2^1024 trials, and that will take you something like = “forever.” Cracking the hash requires only something on the = order of 2^91 trials with SEC=3D2. That’s obviously much less, but = that’s still a very large number. The exhausting search will take = you many years, i.e. much more than the valid lifetime of the = address.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 1:45 PM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; 'Michael Richardson'; jeanmichel.combes@orange.com= ; 'Roque Gagliano (rogaglia)'
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

>The “SEC” part of CGA is meant = to protect against a different attack, one in which the attacker has not = cracked the private key. Instead, the attacker uses a public/private key = pair of his own >choosing, and arrange for the hash of that key to = match the CGA address of the target. This “only” requires = O(2**(59+SEC*16)) operations, which even with large values of SEC is = still far less than >what is required to crack RSA or = ECC.

 

So according to what I = understand from what you wrote, the sec value makes the for an easier = attack against CGA as the attacker only needs to find the same value = generated by his own modifier and other parameters and matches this to = the IID of the node. Now the question again is, if this gives an = attacker a leg up in doing his brute force attacks why do we need to add = those steps to CGA. This was why I used the direct public key as a part = of IP address.

 

Thanks again = Christian.

Hosnieh

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 7:30 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

As you say, the attack that you mention depends = on the strength of RSA or ECC. In fact, pretty much all of public key = cryptography depends on that strength. It is generally assumed that = cracking a long enough RSA or ECC key is nearly impossible. =

 

The “SEC” = part of CGA is meant to protect against a different attack, one in which = the attacker has not cracked the private key. Instead, the attacker uses = a public/private key pair of his own choosing, and arrange for the hash = of that key to match the CGA address of the target. This = “only” requires O(2**(59+SEC*16)) operations, which even = with large values of SEC is still far less than what is required to = crack RSA or ECC.

 

From: Hosnieh Rafiee [mailto:ietf@rozanak.com] =
Sent: Saturday, March 16, 2013 10:59 AM
To: = Christian Huitema; ipv6@ietf.org; = saag@ietf.org
Cc: 'Erik = Nordmark'; alexandru.petrescu@gmail.com= ; 'Ray Hunter'; Michael Richardson; jeanmichel.combes@orange.com= ; Roque Gagliano (rogaglia)
Subject: RE: security = consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

Hi Christian,

 

> But can y toou = explain why you believe that retrieving the private key from the public = key and a clear text/encrypted text pair is easier than breaking a hash? =

 

Here we do not use any = encryption and decryption and we just sign the message using private key = and verify the message using public key.

 

>Did you somehow = crack RSA?

 

I do not say that it is = easier to find the private key from the public key. Because for both = SSAS and CGA, public/private keys are used. I do say that the SHAx steps = used for CGA generation do not increase the complexity when used against = brute force attacks. This is because an attacker only needs the private = key and does not need to find the modifier that was used in the = generation of the node’s IID nor is there a need for checking the = condition of sec by 16 bits which should be equal to zero. In SSAS I = just use the public/private keys and the signature and nothing is = encrypted/decrypted. In CGA some extra SHAx steps are used in the = generation of their IID along with the signature. I say that these steps = are not needed as long as you include and send all parameters, used in = the SHAx process, in the packet for verification purposes. Some people = feel that CGA  is secure enough when those steps are used. Now what = I want to point out here is that the CGA security level is only = dependent on the algorithm used for key pair and signature generation = and that those extra steps do nothing enhance the security side of = things. The algorithms used can be RSA or ECC or whatever, and as such = the situation will be the same as it is for SSAS. I just removed the = complexity from the use of CGA in order to enable a more practical and = faster generation and verification process.

 

So the question = isn’t how to break the encrypted text but how to break the = signature. In other word,  to find the same public key as used by = the generator node or how to break the RSA or ECC. Based on my knowledge = of hash algorithms, as I mentioned in my prior sentence, this will = depend on the strength of the RSA or whatever other  algorithm is = used to generate these keys and sign the message. If you or anyone else = thinks otherwise, please contribute to this discussion and share your = opinions. I am just comparing the security aspects of SSAS, the time = efficient algorithm, to those of CGA.

 

Thank = you,

Hosnieh

 

 

From:= = Christian Huitema [mailto:huitema@microsoft.com] =
Sent: Saturday, March 16, 2013 5:37 PM
To: Hosnieh = Rafiee; ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: RE: security consideration of CGA = and SSAS - Ii-D action : = draft-rafiee-6man-ssas

 

It is very clear that if the attacker finds the = private key, the size of the hash does not matter. But can you explain = why you believe that retrieving the private key from the public key and = a clear text/encrypted text pair is easier than breaking a hash? Did you = somehow crack RSA?

 

From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] = On Behalf Of Hosnieh Rafiee
Sent: Saturday, March 16, = 2013 6:27 AM
To: ipv6@ietf.org; saag@ietf.org
Cc: Erik = Nordmark; alexandru.petrescu@gmail.com= ; Ray Hunter
Subject: security consideration of CGA and = SSAS - Ii-D action : draft-rafiee-6man-ssas

 

Hello,

There was a = discussion during my presentation about security considerations = regarding the use of my algorithm compared with those of the use of CGA. = A big mistake that is made when considering CGA security is that the sec = value plays an important role and that an attacker will need to do brute = force attacks against the IID in order to generate the same IID as is = generated by the use of CGA. In a CGA analysis paper they talk about a = CGA security vaulue of pow (2, sec*16 * 59) where 2 is the base and = sec*16 * 59 is the exponential value and so they infer that by = increasing the sec value used with CGA it will be safer, but this Is not = true.

I, as an attacker, just to = need to find your private key. That’s it. This is because you have = already included the CGA parameters (public key, modifier, and other = required parameters) in the  packet that was sent and I will have = no problem in regenerating the CGA. My only problem will be in = generating the signature that can be verified by use of your public key. = This means that you just increased the complexity and time required for = generating and verifying the IID while with SSAS you can obtain the same = security as when using CGA because its security also depends on the Hash = function that is used to generate the key pair and signature. =

If you send the CGA parameters via a = safe channel, like in establishing TLS etc., then, in that case, CGA = would be more secure than SSAS. But in practice all the data is sent in = the same packet without encryption. If a secured channel would be used = in the CGA process for security reasons (sending CGA parameters), then = the cost of using CGA would be much greater than the cost of using = SSAS.

 

Now the question is, Why not use a more cost = efficient algorithm that afford you with the same security level as when = using CGA.

 

I have also = included the security group in this email so that they can also give me = any comments that they might have.

 

Thank = you,

Hosnieh

------=_NextPart_000_0021_01CE2379.A42164F0-- From Francis.Dupont@fdupont.fr Mon Mar 18 03:21:41 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F5721F8CB6; Mon, 18 Mar 2013 03:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VIxqv9kUNl5; Mon, 18 Mar 2013 03:21:41 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 6D72C21F8CB1; Mon, 18 Mar 2013 03:21:40 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2IAJgKP019293; Mon, 18 Mar 2013 11:19:42 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303181019.r2IAJgKP019293@givry.fdupont.fr> From: Francis Dupont To: "Hosnieh Rafiee" In-reply-to: Your message of Mon, 18 Mar 2013 01:40:46 +0100. <002001ce2371$425582e0$c70088a0$@rozanak.com> Date: Mon, 18 Mar 2013 11:19:41 +0100 Sender: Francis.Dupont@fdupont.fr X-Mailman-Approved-At: Mon, 18 Mar 2013 09:57:15 -0700 Cc: alexandru.petrescu@gmail.com, ipv6@ietf.org, 'Erik Nordmark' , 'Ray Hunter' , saag@ietf.org, jeanmichel.combes@orange.com, "'Roque Gagliano \(rogaglia\)'" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 10:21:41 -0000 In your previous mail you wrote: > About the modifier that I have, I will also check to determine whether using > makes breaking it easier or harder. If it is easier. then I will use the > entire 64 bits of the public key (set bit u and g) and use the fixed part of > the public key. => I don't believe 64 vs 48 bits will change a lot for a RSA public key. > Francis: SSAS also provides proof of IP address ownership as does CGA. The > question here is not that but is on the security considerations that are > based on my calculations with regard to the probability of being able to > break it. I believe that what Christian says is not true, but I will have to > try it to prove him wrong. About other algorithms, CGA can use them as well > so you cannot compare the computational times based on the use of those > algorithms. => I fully disagree with your security considerations. My math shows to build a matching RSA public key takes a similar time than to build a new RSA key pair. Note it won't be enough to go through a hash function and to take benefit of pre-image resistance because you doesn't have enough bit in the interface ID. My conclusion is you have to reinvent CGAs to get similar/equivalent security properties. Regards Francis.Dupont@fdupont.fr From jhutz@cmu.edu Mon Mar 18 13:06:41 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFD821F8FA6; Mon, 18 Mar 2013 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAAY1j4ASDvE; Mon, 18 Mar 2013 13:06:41 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF0621F90D9; Mon, 18 Mar 2013 13:06:40 -0700 (PDT) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r2IK5rdQ002552 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 18 Mar 2013 16:05:54 -0400 (EDT) Message-ID: <1363637153.2711.75.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Christian Huitema Date: Mon, 18 Mar 2013 16:05:53 -0400 In-Reply-To: <13436_1363538825_r2HGl36h022155_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2@TK5EX14MBXC273.redmond.corp.microsoft.com> References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <001e01ce232b$a27f2310$e77d6930$@rozanak.com> <13436_1363538825_r2HGl36h022155_C91E67751B1EFF41B857DE2FE1F68ABA0BFCFFA2@TK5EX14MBXC273.redmond.corp.microsoft.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 X-Mailman-Approved-At: Tue, 19 Mar 2013 08:22:36 -0700 Cc: "alexandru.petrescu@gmail.com" , "'Roque Gagliano \(rogaglia\)'" , 'Erik Nordmark' , 'Ray Hunter' , "saag@ietf.org" , "jeanmichel.combes@orange.com" , "ipv6@ietf.org" , jhutz@cmu.edu Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:06:41 -0000 On Sun, 2013-03-17 at 16:46 +0000, Christian Huitema wrote: > You may think that building public/private key pairs is a very > expensive operation, but that is not true. The default algorithm for > SSAS is RSA. Let's suppose you use 2048 bit long RSA keys. The key > generation start by generating a set of 1024 bit long prime numbers. In > theory, we need about 2*25 such numbers. Add a margin to be on the safe > side. These numbers can be generated once, they don't have to be > regenerated for every SSAS key being tried. Hold on. If I'm an attacker, who says my "primes" even have to be prime? From zhou.sujing@zte.com.cn Mon Mar 18 20:50:04 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD0021F8A64; Mon, 18 Mar 2013 20:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.395 X-Spam-Level: X-Spam-Status: No, score=-98.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xM0sOTN8YVRr; Mon, 18 Mar 2013 20:50:02 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4D21F8A56; Mon, 18 Mar 2013 20:50:01 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 393D2126020F; Tue, 19 Mar 2013 11:37:00 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 9CECA72653A; Tue, 19 Mar 2013 11:38:22 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r2J3nXCq081178; Tue, 19 Mar 2013 11:49:33 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Santosh Chokhani MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Tue, 19 Mar 2013 11:49:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-03-19 11:49:32, Serialize complete at 2013-03-19 11:49:32 Content-Type: multipart/alternative; boundary="=_alternative 0015123948257B33_=" X-MAIL: mse02.zte.com.cn r2J3nXCq081178 X-Mailman-Approved-At: Tue, 19 Mar 2013 08:22:36 -0700 Cc: "alexandru.petrescu@gmail.com" , "ipv6@ietf.org" , 'Erik Nordmark' , ipv6-bounces@ietf.org, 'Ray Hunter' , "jeanmichel.combes@orange.com" , "'Roque Gagliano \(rogaglia\)'" , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 03:50:04 -0000 This is a multipart message in MIME format. --=_alternative 0015123948257B33_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aXB2Ni1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMy0wMy0xOCAwOTozNjoyNToNCg0KPiAyMDQ4 IGJpdCBSU0Egc2VjdXJpdHkgaXMgb3ZlcnN0YXRlZC4gIENyYWNraW5nIGl0IHJlcXVpcmVzIG9u IHRoZSANCj4gb3JkZXIgb2YgMl4xMTIgb3BlcmF0aW9ucy4gIFlvdSBzaG91bGQgbG9vayBhdCBO SVNUIFNQIDgwMC01NyBQYXJ0IA0KPiAyLCBUYWJsZSAyIFNlY3Rpb24gNS42LjEuDQoNCkl0IGlz IGluIFBhcnQgMToNCmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84 MDAtNTcvc3A4MDAtNTdfcGFydDFfcmV2M19nZW5lcmFsLnBkZiANCg0KDQoNCj4gRnJvbSB0aGUg ZGVzY3JpcHRpb24geW91IHByb3ZpZGUgb24gaGFzaGluZywgZmluZGluZyBhIHNlY29uZCBoYXNo IA0KPiBpcyBhIHNlY29uZCBwcmUtaW1hZ2UgYXR0YWNrIGFuZCBmb3IgU0hBLTEgdGhlIHNlY3Vy aXR5IHN0cmVuZ3RoIGlzIA0KPiAxNjAgYml0cywgaS5lLiwgeW91IG5lZWQgb24gdGhlIG9yZGVy IG9mIDJeMTYwIG9wZXJhdGlvbnMuDQo+IA0KPiBJIGRvIG5vdCBrbm93IHdoYXQgaGFzaCBmdW5j dGlvbiB5b3UgYXJlIGRlc2NyaWJpbmcgZm9yIHRoZSBmdW5jdGlvbg0KPiB5b3UgbWVudGlvbiBh bmQgaG93IHlvdSBkZXJpdmVkIGl0cyBzZWN1cml0eSBzdHJlbmd0aC4NCj4gDQo+IEZyb206IHNh YWctYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIA0KPiBDaHJpc3RpYW4gSHVpdGVtYQ0KPiBTZW50OiBTdW5kYXksIE1hcmNoIDE3LCAy MDEzIDQ6MTQgQU0NCj4gVG86IEhvc25pZWggUmFmaWVlOyBpcHY2QGlldGYub3JnOyBzYWFnQGll dGYub3JnDQo+IENjOiBhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tOyAnUm9xdWUgR2FnbGlh bm8gKHJvZ2FnbGlhKSc7ICdFcmlrDQo+IE5vcmRtYXJrJzsgJ1JheSBIdW50ZXInOyBqZWFubWlj aGVsLmNvbWJlc0BvcmFuZ2UuY29tDQo+IFN1YmplY3Q6IFJlOiBbc2FhZ10gc2VjdXJpdHkgY29u c2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJaS1EIA0KPiBhY3Rpb24gOiBkcmFmdC1yYWZp ZWUtNm1hbi1zc2FzDQo+IA0KPiBUaGUgYXR0YWNrIGlzICpyZWxhdGl2ZWx5KiBlYXNpZXIuIEl0 IGlzIG5vdCChsGVhc3kuobEgSXQgaXMgbXVjaCANCj4gaGFyZGVyIHRvIGNyYWNrIFJTQSB0aGFu IHRvIGZpbmQgYSBtYXRjaGluZyBoYXNoLiBDcmFja2luZyBhIDIwNDggDQo+IGJpdHMgUlNBIGtl eSBwcm9iYWJseSByZXF1aXJlcyBvbiB0aGUgb3JkZXIgb2YgMl4xMDI0IHRyaWFscywgYW5kIA0K PiB0aGF0IHdpbGwgdGFrZSB5b3Ugc29tZXRoaW5nIGxpa2UgobBmb3JldmVyLqGxIENyYWNraW5n IHRoZSBoYXNoIA0KPiByZXF1aXJlcyBvbmx5IHNvbWV0aGluZyBvbiB0aGUgb3JkZXIgb2YgMl45 MSB0cmlhbHMgd2l0aCBTRUM9Mi4gDQo+IFRoYXShr3Mgb2J2aW91c2x5IG11Y2ggbGVzcywgYnV0 IHRoYXShr3Mgc3RpbGwgYSB2ZXJ5IGxhcmdlIG51bWJlci4gDQo+IFRoZSBleGhhdXN0aW5nIHNl YXJjaCB3aWxsIHRha2UgeW91IG1hbnkgeWVhcnMsIGkuZS4gbXVjaCBtb3JlIHRoYW4gDQo+IHRo ZSB2YWxpZCBsaWZldGltZSBvZiB0aGUgYWRkcmVzcy4NCj4gDQo+IEZyb206IEhvc25pZWggUmFm aWVlIFttYWlsdG86aWV0ZkByb3phbmFrLmNvbV0gDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAx NiwgMjAxMyAxOjQ1IFBNDQo+IFRvOiBDaHJpc3RpYW4gSHVpdGVtYTsgaXB2NkBpZXRmLm9yZzsg c2FhZ0BpZXRmLm9yZw0KPiBDYzogJ0VyaWsgTm9yZG1hcmsnOyBhbGV4YW5kcnUucGV0cmVzY3VA Z21haWwuY29tOyAnUmF5IEh1bnRlcic7IA0KPiAnTWljaGFlbCBSaWNoYXJkc29uJzsgamVhbm1p Y2hlbC5jb21iZXNAb3JhbmdlLmNvbTsgJ1JvcXVlIEdhZ2xpYW5vIA0KPiAocm9nYWdsaWEpJw0K PiBTdWJqZWN0OiBSRTogc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJ aS1EIGFjdGlvbiA6IA0KPiBkcmFmdC1yYWZpZWUtNm1hbi1zc2FzDQo+IA0KPiA+VGhlIKGwU0VD obEgcGFydCBvZiBDR0EgaXMgbWVhbnQgdG8gcHJvdGVjdCBhZ2FpbnN0IGEgZGlmZmVyZW50IA0K PiBhdHRhY2ssIG9uZSBpbiB3aGljaCB0aGUgYXR0YWNrZXIgaGFzIG5vdCBjcmFja2VkIHRoZSBw cml2YXRlIGtleS4gDQo+IEluc3RlYWQsIHRoZSBhdHRhY2tlciB1c2VzIGEgcHVibGljL3ByaXZh dGUga2V5IHBhaXIgb2YgaGlzIG93biANCj4gPmNob29zaW5nLCBhbmQgYXJyYW5nZSBmb3IgdGhl IGhhc2ggb2YgdGhhdCBrZXkgdG8gbWF0Y2ggdGhlIENHQSANCj4gYWRkcmVzcyBvZiB0aGUgdGFy Z2V0LiBUaGlzIKGwb25seaGxIHJlcXVpcmVzIE8oMioqKDU5K1NFQyoxNikpIA0KPiBvcGVyYXRp b25zLCB3aGljaCBldmVuIHdpdGggbGFyZ2UgdmFsdWVzIG9mIFNFQyBpcyBzdGlsbCBmYXIgbGVz cyANCj4gdGhhbiA+d2hhdCBpcyByZXF1aXJlZCB0byBjcmFjayBSU0Egb3IgRUNDLg0KPiANCj4g U28gYWNjb3JkaW5nIHRvIHdoYXQgSSB1bmRlcnN0YW5kIGZyb20gd2hhdCB5b3Ugd3JvdGUsIHRo ZSBzZWMgdmFsdWUNCj4gbWFrZXMgdGhlIGZvciBhbiBlYXNpZXIgYXR0YWNrIGFnYWluc3QgQ0dB IGFzIHRoZSBhdHRhY2tlciBvbmx5IA0KPiBuZWVkcyB0byBmaW5kIHRoZSBzYW1lIHZhbHVlIGdl bmVyYXRlZCBieSBoaXMgb3duIG1vZGlmaWVyIGFuZCBvdGhlcg0KPiBwYXJhbWV0ZXJzIGFuZCBt YXRjaGVzIHRoaXMgdG8gdGhlIElJRCBvZiB0aGUgbm9kZS4gTm93IHRoZSBxdWVzdGlvbg0KPiBh Z2FpbiBpcywgaWYgdGhpcyBnaXZlcyBhbiBhdHRhY2tlciBhIGxlZyB1cCBpbiBkb2luZyBoaXMg YnJ1dGUgDQo+IGZvcmNlIGF0dGFja3Mgd2h5IGRvIHdlIG5lZWQgdG8gYWRkIHRob3NlIHN0ZXBz IHRvIENHQS4gVGhpcyB3YXMgd2h5DQo+IEkgdXNlZCB0aGUgZGlyZWN0IHB1YmxpYyBrZXkgYXMg YSBwYXJ0IG9mIElQIGFkZHJlc3MuDQo+IA0KPiBUaGFua3MgYWdhaW4gQ2hyaXN0aWFuLg0KPiBI b3NuaWVoDQo+IA0KPiBGcm9tOiBDaHJpc3RpYW4gSHVpdGVtYSBbbWFpbHRvOmh1aXRlbWFAbWlj cm9zb2Z0LmNvbV0gDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXJjaCAxNiwgMjAxMyA3OjMwIFBNDQo+ IFRvOiBIb3NuaWVoIFJhZmllZTsgaXB2NkBpZXRmLm9yZzsgc2FhZ0BpZXRmLm9yZw0KPiBDYzog J0VyaWsgTm9yZG1hcmsnOyBhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tOyAnUmF5IEh1bnRl cic7IA0KPiBNaWNoYWVsIFJpY2hhcmRzb247IGplYW5taWNoZWwuY29tYmVzQG9yYW5nZS5jb207 IFJvcXVlIEdhZ2xpYW5vIA0KKHJvZ2FnbGlhKQ0KPiBTdWJqZWN0OiBSRTogc2VjdXJpdHkgY29u c2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJaS1EIGFjdGlvbiA6IA0KPiBkcmFmdC1yYWZp ZWUtNm1hbi1zc2FzDQo+IA0KPiBBcyB5b3Ugc2F5LCB0aGUgYXR0YWNrIHRoYXQgeW91IG1lbnRp b24gZGVwZW5kcyBvbiB0aGUgc3RyZW5ndGggb2YgDQo+IFJTQSBvciBFQ0MuIEluIGZhY3QsIHBy ZXR0eSBtdWNoIGFsbCBvZiBwdWJsaWMga2V5IGNyeXB0b2dyYXBoeSANCj4gZGVwZW5kcyBvbiB0 aGF0IHN0cmVuZ3RoLiBJdCBpcyBnZW5lcmFsbHkgYXNzdW1lZCB0aGF0IGNyYWNraW5nIGEgDQo+ IGxvbmcgZW5vdWdoIFJTQSBvciBFQ0Mga2V5IGlzIG5lYXJseSBpbXBvc3NpYmxlLiANCj4gDQo+ IFRoZSChsFNFQ6GxIHBhcnQgb2YgQ0dBIGlzIG1lYW50IHRvIHByb3RlY3QgYWdhaW5zdCBhIGRp ZmZlcmVudCANCj4gYXR0YWNrLCBvbmUgaW4gd2hpY2ggdGhlIGF0dGFja2VyIGhhcyBub3QgY3Jh Y2tlZCB0aGUgcHJpdmF0ZSBrZXkuIA0KPiBJbnN0ZWFkLCB0aGUgYXR0YWNrZXIgdXNlcyBhIHB1 YmxpYy9wcml2YXRlIGtleSBwYWlyIG9mIGhpcyBvd24gDQo+IGNob29zaW5nLCBhbmQgYXJyYW5n ZSBmb3IgdGhlIGhhc2ggb2YgdGhhdCBrZXkgdG8gbWF0Y2ggdGhlIENHQSANCj4gYWRkcmVzcyBv ZiB0aGUgdGFyZ2V0LiBUaGlzIKGwb25seaGxIHJlcXVpcmVzIE8oMioqKDU5K1NFQyoxNikpIA0K PiBvcGVyYXRpb25zLCB3aGljaCBldmVuIHdpdGggbGFyZ2UgdmFsdWVzIG9mIFNFQyBpcyBzdGls bCBmYXIgbGVzcyANCj4gdGhhbiB3aGF0IGlzIHJlcXVpcmVkIHRvIGNyYWNrIFJTQSBvciBFQ0Mu DQo+IA0KPiBGcm9tOiBIb3NuaWVoIFJhZmllZSBbbWFpbHRvOmlldGZAcm96YW5hay5jb21dIA0K PiBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTYsIDIwMTMgMTA6NTkgQU0NCj4gVG86IENocmlzdGlh biBIdWl0ZW1hOyBpcHY2QGlldGYub3JnOyBzYWFnQGlldGYub3JnDQo+IENjOiAnRXJpayBOb3Jk bWFyayc7IGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb207ICdSYXkgSHVudGVyJzsgDQo+IE1p Y2hhZWwgUmljaGFyZHNvbjsgamVhbm1pY2hlbC5jb21iZXNAb3JhbmdlLmNvbTsgUm9xdWUgR2Fn bGlhbm8gDQoocm9nYWdsaWEpDQo+IFN1YmplY3Q6IFJFOiBzZWN1cml0eSBjb25zaWRlcmF0aW9u IG9mIENHQSBhbmQgU1NBUyAtIElpLUQgYWN0aW9uIDogDQo+IGRyYWZ0LXJhZmllZS02bWFuLXNz YXMNCj4gDQo+IEhpIENocmlzdGlhbiwNCj4gDQo+ID4gQnV0IGNhbiB5IHRvb3UgZXhwbGFpbiB3 aHkgeW91IGJlbGlldmUgdGhhdCByZXRyaWV2aW5nIHRoZSBwcml2YXRlDQo+IGtleSBmcm9tIHRo ZSBwdWJsaWMga2V5IGFuZCBhIGNsZWFyIHRleHQvZW5jcnlwdGVkIHRleHQgcGFpciBpcyANCj4g ZWFzaWVyIHRoYW4gYnJlYWtpbmcgYSBoYXNoPyANCj4gDQo+IEhlcmUgd2UgZG8gbm90IHVzZSBh bnkgZW5jcnlwdGlvbiBhbmQgZGVjcnlwdGlvbiBhbmQgd2UganVzdCBzaWduIA0KPiB0aGUgbWVz c2FnZSB1c2luZyBwcml2YXRlIGtleSBhbmQgdmVyaWZ5IHRoZSBtZXNzYWdlIHVzaW5nIHB1Ymxp YyBrZXkuDQo+IA0KPiA+RGlkIHlvdSBzb21laG93IGNyYWNrIFJTQT8NCj4gDQo+IEkgZG8gbm90 IHNheSB0aGF0IGl0IGlzIGVhc2llciB0byBmaW5kIHRoZSBwcml2YXRlIGtleSBmcm9tIHRoZSAN Cj4gcHVibGljIGtleS4gQmVjYXVzZSBmb3IgYm90aCBTU0FTIGFuZCBDR0EsIHB1YmxpYy9wcml2 YXRlIGtleXMgYXJlIA0KPiB1c2VkLiBJIGRvIHNheSB0aGF0IHRoZSBTSEF4IHN0ZXBzIHVzZWQg Zm9yIENHQSBnZW5lcmF0aW9uIGRvIG5vdCANCj4gaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkgd2hl biB1c2VkIGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4gVGhpcyANCj4gaXMgYmVjYXVzZSBh biBhdHRhY2tlciBvbmx5IG5lZWRzIHRoZSBwcml2YXRlIGtleSBhbmQgZG9lcyBub3QgbmVlZCAN Cj4gdG8gZmluZCB0aGUgbW9kaWZpZXIgdGhhdCB3YXMgdXNlZCBpbiB0aGUgZ2VuZXJhdGlvbiBv ZiB0aGUgbm9kZaGvcyANCj4gSUlEIG5vciBpcyB0aGVyZSBhIG5lZWQgZm9yIGNoZWNraW5nIHRo ZSBjb25kaXRpb24gb2Ygc2VjIGJ5IDE2IGJpdHMNCj4gd2hpY2ggc2hvdWxkIGJlIGVxdWFsIHRv IHplcm8uIEluIFNTQVMgSSBqdXN0IHVzZSB0aGUgcHVibGljL3ByaXZhdGUNCj4ga2V5cyBhbmQg dGhlIHNpZ25hdHVyZSBhbmQgbm90aGluZyBpcyBlbmNyeXB0ZWQvZGVjcnlwdGVkLiBJbiBDR0Eg DQo+IHNvbWUgZXh0cmEgU0hBeCBzdGVwcyBhcmUgdXNlZCBpbiB0aGUgZ2VuZXJhdGlvbiBvZiB0 aGVpciBJSUQgYWxvbmcgDQo+IHdpdGggdGhlIHNpZ25hdHVyZS4gSSBzYXkgdGhhdCB0aGVzZSBz dGVwcyBhcmUgbm90IG5lZWRlZCBhcyBsb25nIGFzDQo+IHlvdSBpbmNsdWRlIGFuZCBzZW5kIGFs bCBwYXJhbWV0ZXJzLCB1c2VkIGluIHRoZSBTSEF4IHByb2Nlc3MsIGluIA0KPiB0aGUgcGFja2V0 IGZvciB2ZXJpZmljYXRpb24gcHVycG9zZXMuIFNvbWUgcGVvcGxlIGZlZWwgdGhhdCBDR0EgIGlz IA0KPiBzZWN1cmUgZW5vdWdoIHdoZW4gdGhvc2Ugc3RlcHMgYXJlIHVzZWQuIE5vdyB3aGF0IEkg d2FudCB0byBwb2ludCANCj4gb3V0IGhlcmUgaXMgdGhhdCB0aGUgQ0dBIHNlY3VyaXR5IGxldmVs IGlzIG9ubHkgZGVwZW5kZW50IG9uIHRoZSANCj4gYWxnb3JpdGhtIHVzZWQgZm9yIGtleSBwYWly IGFuZCBzaWduYXR1cmUgZ2VuZXJhdGlvbiBhbmQgdGhhdCB0aG9zZSANCj4gZXh0cmEgc3RlcHMg ZG8gbm90aGluZyBlbmhhbmNlIHRoZSBzZWN1cml0eSBzaWRlIG9mIHRoaW5ncy4gVGhlIA0KPiBh bGdvcml0aG1zIHVzZWQgY2FuIGJlIFJTQSBvciBFQ0Mgb3Igd2hhdGV2ZXIsIGFuZCBhcyBzdWNo IHRoZSANCj4gc2l0dWF0aW9uIHdpbGwgYmUgdGhlIHNhbWUgYXMgaXQgaXMgZm9yIFNTQVMuIEkg anVzdCByZW1vdmVkIHRoZSANCj4gY29tcGxleGl0eSBmcm9tIHRoZSB1c2Ugb2YgQ0dBIGluIG9y ZGVyIHRvIGVuYWJsZSBhIG1vcmUgcHJhY3RpY2FsIA0KPiBhbmQgZmFzdGVyIGdlbmVyYXRpb24g YW5kIHZlcmlmaWNhdGlvbiBwcm9jZXNzLg0KPiANCj4gU28gdGhlIHF1ZXN0aW9uIGlzbqGvdCBo b3cgdG8gYnJlYWsgdGhlIGVuY3J5cHRlZCB0ZXh0IGJ1dCBob3cgdG8gDQo+IGJyZWFrIHRoZSBz aWduYXR1cmUuIEluIG90aGVyIHdvcmQsICB0byBmaW5kIHRoZSBzYW1lIHB1YmxpYyBrZXkgYXMg DQo+IHVzZWQgYnkgdGhlIGdlbmVyYXRvciBub2RlIG9yIGhvdyB0byBicmVhayB0aGUgUlNBIG9y IEVDQy4gQmFzZWQgb24gDQo+IG15IGtub3dsZWRnZSBvZiBoYXNoIGFsZ29yaXRobXMsIGFzIEkg bWVudGlvbmVkIGluIG15IHByaW9yIA0KPiBzZW50ZW5jZSwgdGhpcyB3aWxsIGRlcGVuZCBvbiB0 aGUgc3RyZW5ndGggb2YgdGhlIFJTQSBvciB3aGF0ZXZlciANCj4gb3RoZXIgIGFsZ29yaXRobSBp cyB1c2VkIHRvIGdlbmVyYXRlIHRoZXNlIGtleXMgYW5kIHNpZ24gdGhlIA0KPiBtZXNzYWdlLiBJ ZiB5b3Ugb3IgYW55b25lIGVsc2UgdGhpbmtzIG90aGVyd2lzZSwgcGxlYXNlIGNvbnRyaWJ1dGUg DQo+IHRvIHRoaXMgZGlzY3Vzc2lvbiBhbmQgc2hhcmUgeW91ciBvcGluaW9ucy4gSSBhbSBqdXN0 IGNvbXBhcmluZyB0aGUgDQo+IHNlY3VyaXR5IGFzcGVjdHMgb2YgU1NBUywgdGhlIHRpbWUgZWZm aWNpZW50IGFsZ29yaXRobSwgdG8gdGhvc2Ugb2YgQ0dBLg0KPiANCj4gVGhhbmsgeW91LA0KPiBI b3NuaWVoDQo+IA0KPiANCj4gRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgW21haWx0bzpodWl0ZW1h QG1pY3Jvc29mdC5jb21dIA0KPiBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTYsIDIwMTMgNTozNyBQ TQ0KPiBUbzogSG9zbmllaCBSYWZpZWU7IGlwdjZAaWV0Zi5vcmc7IHNhYWdAaWV0Zi5vcmcNCj4g Q2M6IEVyaWsgTm9yZG1hcms7IGFsZXhhbmRydS5wZXRyZXNjdUBnbWFpbC5jb207IFJheSBIdW50 ZXINCj4gU3ViamVjdDogUkU6IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gb2YgQ0dBIGFuZCBTU0FT IC0gSWktRCBhY3Rpb24gOiANCj4gZHJhZnQtcmFmaWVlLTZtYW4tc3Nhcw0KPiANCj4gSXQgaXMg dmVyeSBjbGVhciB0aGF0IGlmIHRoZSBhdHRhY2tlciBmaW5kcyB0aGUgcHJpdmF0ZSBrZXksIHRo ZSANCj4gc2l6ZSBvZiB0aGUgaGFzaCBkb2VzIG5vdCBtYXR0ZXIuIEJ1dCBjYW4geW91IGV4cGxh aW4gd2h5IHlvdSANCj4gYmVsaWV2ZSB0aGF0IHJldHJpZXZpbmcgdGhlIHByaXZhdGUga2V5IGZy b20gdGhlIHB1YmxpYyBrZXkgYW5kIGEgDQo+IGNsZWFyIHRleHQvZW5jcnlwdGVkIHRleHQgcGFp ciBpcyBlYXNpZXIgdGhhbiBicmVha2luZyBhIGhhc2g/IERpZCANCj4geW91IHNvbWVob3cgY3Jh Y2sgUlNBPw0KPiANCj4gRnJvbTogaXB2Ni1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aXB2Ni1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+IEhvc25pZWggUmFmaWVlDQo+IFNlbnQ6 IFNhdHVyZGF5LCBNYXJjaCAxNiwgMjAxMyA2OjI3IEFNDQo+IFRvOiBpcHY2QGlldGYub3JnOyBz YWFnQGlldGYub3JnDQo+IENjOiBFcmlrIE5vcmRtYXJrOyBhbGV4YW5kcnUucGV0cmVzY3VAZ21h aWwuY29tOyBSYXkgSHVudGVyDQo+IFN1YmplY3Q6IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gb2Yg Q0dBIGFuZCBTU0FTIC0gSWktRCBhY3Rpb24gOiANCj4gZHJhZnQtcmFmaWVlLTZtYW4tc3Nhcw0K PiANCj4gSGVsbG8sDQo+IFRoZXJlIHdhcyBhIGRpc2N1c3Npb24gZHVyaW5nIG15IHByZXNlbnRh dGlvbiBhYm91dCBzZWN1cml0eSANCj4gY29uc2lkZXJhdGlvbnMgcmVnYXJkaW5nIHRoZSB1c2Ug b2YgbXkgYWxnb3JpdGhtIGNvbXBhcmVkIHdpdGggdGhvc2UNCj4gb2YgdGhlIHVzZSBvZiBDR0Eu IEEgYmlnIG1pc3Rha2UgdGhhdCBpcyBtYWRlIHdoZW4gY29uc2lkZXJpbmcgQ0dBIA0KPiBzZWN1 cml0eSBpcyB0aGF0IHRoZSBzZWMgdmFsdWUgcGxheXMgYW4gaW1wb3J0YW50IHJvbGUgYW5kIHRo YXQgYW4gDQo+IGF0dGFja2VyIHdpbGwgbmVlZCB0byBkbyBicnV0ZSBmb3JjZSBhdHRhY2tzIGFn YWluc3QgdGhlIElJRCBpbiANCj4gb3JkZXIgdG8gZ2VuZXJhdGUgdGhlIHNhbWUgSUlEIGFzIGlz IGdlbmVyYXRlZCBieSB0aGUgdXNlIG9mIENHQS4gSW4NCj4gYSBDR0EgYW5hbHlzaXMgcGFwZXIg dGhleSB0YWxrIGFib3V0IGEgQ0dBIHNlY3VyaXR5IHZhdWx1ZSBvZiBwb3cgDQo+ICgyLCBzZWMq MTYgKiA1OSkgd2hlcmUgMiBpcyB0aGUgYmFzZSBhbmQgc2VjKjE2ICogNTkgaXMgdGhlIA0KPiBl eHBvbmVudGlhbCB2YWx1ZSBhbmQgc28gdGhleSBpbmZlciB0aGF0IGJ5IGluY3JlYXNpbmcgdGhl IHNlYyB2YWx1ZQ0KPiB1c2VkIHdpdGggQ0dBIGl0IHdpbGwgYmUgc2FmZXIsIGJ1dCB0aGlzIElz IG5vdCB0cnVlLiANCj4gSSwgYXMgYW4gYXR0YWNrZXIsIGp1c3QgdG8gbmVlZCB0byBmaW5kIHlv dXIgcHJpdmF0ZSBrZXkuIFRoYXShr3MgaXQuDQo+IFRoaXMgaXMgYmVjYXVzZSB5b3UgaGF2ZSBh bHJlYWR5IGluY2x1ZGVkIHRoZSBDR0EgcGFyYW1ldGVycyAocHVibGljDQo+IGtleSwgbW9kaWZp ZXIsIGFuZCBvdGhlciByZXF1aXJlZCBwYXJhbWV0ZXJzKSBpbiB0aGUgIHBhY2tldCB0aGF0IA0K PiB3YXMgc2VudCBhbmQgSSB3aWxsIGhhdmUgbm8gcHJvYmxlbSBpbiByZWdlbmVyYXRpbmcgdGhl IENHQS4gTXkgb25seQ0KPiBwcm9ibGVtIHdpbGwgYmUgaW4gZ2VuZXJhdGluZyB0aGUgc2lnbmF0 dXJlIHRoYXQgY2FuIGJlIHZlcmlmaWVkIGJ5IA0KPiB1c2Ugb2YgeW91ciBwdWJsaWMga2V5LiBU aGlzIG1lYW5zIHRoYXQgeW91IGp1c3QgaW5jcmVhc2VkIHRoZSANCj4gY29tcGxleGl0eSBhbmQg dGltZSByZXF1aXJlZCBmb3IgZ2VuZXJhdGluZyBhbmQgdmVyaWZ5aW5nIHRoZSBJSUQgDQo+IHdo aWxlIHdpdGggU1NBUyB5b3UgY2FuIG9idGFpbiB0aGUgc2FtZSBzZWN1cml0eSBhcyB3aGVuIHVz aW5nIENHQSANCj4gYmVjYXVzZSBpdHMgc2VjdXJpdHkgYWxzbyBkZXBlbmRzIG9uIHRoZSBIYXNo IGZ1bmN0aW9uIHRoYXQgaXMgdXNlZCANCj4gdG8gZ2VuZXJhdGUgdGhlIGtleSBwYWlyIGFuZCBz aWduYXR1cmUuIA0KPiBJZiB5b3Ugc2VuZCB0aGUgQ0dBIHBhcmFtZXRlcnMgdmlhIGEgc2FmZSBj aGFubmVsLCBsaWtlIGluIA0KPiBlc3RhYmxpc2hpbmcgVExTIGV0Yy4sIHRoZW4sIGluIHRoYXQg Y2FzZSwgQ0dBIHdvdWxkIGJlIG1vcmUgc2VjdXJlIA0KPiB0aGFuIFNTQVMuIEJ1dCBpbiBwcmFj dGljZSBhbGwgdGhlIGRhdGEgaXMgc2VudCBpbiB0aGUgc2FtZSBwYWNrZXQgDQo+IHdpdGhvdXQg ZW5jcnlwdGlvbi4gSWYgYSBzZWN1cmVkIGNoYW5uZWwgd291bGQgYmUgdXNlZCBpbiB0aGUgQ0dB IA0KPiBwcm9jZXNzIGZvciBzZWN1cml0eSByZWFzb25zIChzZW5kaW5nIENHQSBwYXJhbWV0ZXJz KSwgdGhlbiB0aGUgY29zdA0KPiBvZiB1c2luZyBDR0Egd291bGQgYmUgbXVjaCBncmVhdGVyIHRo YW4gdGhlIGNvc3Qgb2YgdXNpbmcgU1NBUy4NCj4gDQo+IE5vdyB0aGUgcXVlc3Rpb24gaXMsIFdo eSBub3QgdXNlIGEgbW9yZSBjb3N0IGVmZmljaWVudCBhbGdvcml0aG0gDQo+IHRoYXQgYWZmb3Jk IHlvdSB3aXRoIHRoZSBzYW1lIHNlY3VyaXR5IGxldmVsIGFzIHdoZW4gdXNpbmcgQ0dBLiANCj4g DQo+IEkgaGF2ZSBhbHNvIGluY2x1ZGVkIHRoZSBzZWN1cml0eSBncm91cCBpbiB0aGlzIGVtYWls IHNvIHRoYXQgdGhleSANCj4gY2FuIGFsc28gZ2l2ZSBtZSBhbnkgY29tbWVudHMgdGhhdCB0aGV5 IG1pZ2h0IGhhdmUuDQo+IA0KPiBUaGFuayB5b3UsDQo+IA0KSG9zbmllaC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+ IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K --=_alternative 0015123948257B33_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAy MDEzLTAzLTE4IDA5OjM2OjI1Ojxicj4NCjxicj4NCiZndDsgMjA0OCBiaXQgUlNBIHNlY3VyaXR5 IGlzIG92ZXJzdGF0ZWQuICZuYnNwO0NyYWNraW5nIGl0IHJlcXVpcmVzIG9uDQp0aGUgPGJyPg0K Jmd0OyBvcmRlciBvZiAyXjExMiBvcGVyYXRpb25zLiAmbmJzcDtZb3Ugc2hvdWxkIGxvb2sgYXQg TklTVCBTUCA4MDAtNTcNClBhcnQgPGJyPg0KJmd0OyAyLCBUYWJsZSAyIFNlY3Rpb24gNS42LjEu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0 IGlzIGluIFBhcnQgMTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84MDAtNTcvc3A4MDAt NTdfcGFydDFfcmV2M19nZW5lcmFsLnBkZjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPg0KPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb20gdGhlIGRl c2NyaXB0aW9uIHlvdSBwcm92aWRlIG9uIGhhc2hpbmcsDQpmaW5kaW5nIGEgc2Vjb25kIGhhc2gg PGJyPg0KJmd0OyBpcyBhIHNlY29uZCBwcmUtaW1hZ2UgYXR0YWNrIGFuZCBmb3IgU0hBLTEgdGhl IHNlY3VyaXR5IHN0cmVuZ3RoIGlzDQo8YnI+DQomZ3Q7IDE2MCBiaXRzLCBpLmUuLCB5b3UgbmVl ZCBvbiB0aGUgb3JkZXIgb2YgMl4xNjAgb3BlcmF0aW9ucy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IEkgZG8gbm90IGtub3cgd2hhdCBoYXNoIGZ1bmN0aW9uIHlvdSBhcmUgZGVzY3JpYmlu Zw0KZm9yIHRoZSBmdW5jdGlvbjxicj4NCiZndDsgeW91IG1lbnRpb24gYW5kIGhvdyB5b3UgZGVy aXZlZCBpdHMgc2VjdXJpdHkgc3RyZW5ndGguPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBG cm9tOiBzYWFnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmdd DQpPbiBCZWhhbGYgT2YgPGJyPg0KJmd0OyBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsgU2Vu dDogU3VuZGF5LCBNYXJjaCAxNywgMjAxMyA0OjE0IEFNPGJyPg0KJmd0OyBUbzogSG9zbmllaCBS YWZpZWU7IGlwdjZAaWV0Zi5vcmc7IHNhYWdAaWV0Zi5vcmc8YnI+DQomZ3Q7IENjOiBhbGV4YW5k cnUucGV0cmVzY3VAZ21haWwuY29tOyAnUm9xdWUgR2FnbGlhbm8gKHJvZ2FnbGlhKSc7ICdFcmlr PGJyPg0KJmd0OyBOb3JkbWFyayc7ICdSYXkgSHVudGVyJzsgamVhbm1pY2hlbC5jb21iZXNAb3Jh bmdlLmNvbTxicj4NCiZndDsgU3ViamVjdDogUmU6IFtzYWFnXSBzZWN1cml0eSBjb25zaWRlcmF0 aW9uIG9mIENHQSBhbmQgU1NBUyAtIElpLUQNCjxicj4NCiZndDsgYWN0aW9uIDogZHJhZnQtcmFm aWVlLTZtYW4tc3NhczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz cDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlIGF0dGFjayBpcyAq cmVsYXRpdmVseSogZWFzaWVyLiBJdCBpcyBub3QNCqGwZWFzeS6hsSBJdCBpcyBtdWNoIDxicj4N CiZndDsgaGFyZGVyIHRvIGNyYWNrIFJTQSB0aGFuIHRvIGZpbmQgYSBtYXRjaGluZyBoYXNoLiBD cmFja2luZyBhIDIwNDgNCjxicj4NCiZndDsgYml0cyBSU0Ega2V5IHByb2JhYmx5IHJlcXVpcmVz IG9uIHRoZSBvcmRlciBvZiAyXjEwMjQgdHJpYWxzLCBhbmQNCjxicj4NCiZndDsgdGhhdCB3aWxs IHRha2UgeW91IHNvbWV0aGluZyBsaWtlIKGwZm9yZXZlci6hsSBDcmFja2luZyB0aGUgaGFzaA0K PGJyPg0KJmd0OyByZXF1aXJlcyBvbmx5IHNvbWV0aGluZyBvbiB0aGUgb3JkZXIgb2YgMl45MSB0 cmlhbHMgd2l0aCBTRUM9Mi4gPGJyPg0KJmd0OyBUaGF0oa9zIG9idmlvdXNseSBtdWNoIGxlc3Ms IGJ1dCB0aGF0oa9zIHN0aWxsIGEgdmVyeSBsYXJnZSBudW1iZXIuDQo8YnI+DQomZ3Q7IFRoZSBl eGhhdXN0aW5nIHNlYXJjaCB3aWxsIHRha2UgeW91IG1hbnkgeWVhcnMsIGkuZS4gbXVjaCBtb3Jl IHRoYW4NCjxicj4NCiZndDsgdGhlIHZhbGlkIGxpZmV0aW1lIG9mIHRoZSBhZGRyZXNzLjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRnJvbTogSG9zbmllaCBSYWZpZWUgW21haWx0bzppZXRm QHJvemFuYWsuY29tXQ0KPGJyPg0KJmd0OyBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTYsIDIwMTMg MTo0NSBQTTxicj4NCiZndDsgVG86IENocmlzdGlhbiBIdWl0ZW1hOyBpcHY2QGlldGYub3JnOyBz YWFnQGlldGYub3JnPGJyPg0KJmd0OyBDYzogJ0VyaWsgTm9yZG1hcmsnOyBhbGV4YW5kcnUucGV0 cmVzY3VAZ21haWwuY29tOyAnUmF5IEh1bnRlcic7IDxicj4NCiZndDsgJ01pY2hhZWwgUmljaGFy ZHNvbic7IGplYW5taWNoZWwuY29tYmVzQG9yYW5nZS5jb207ICdSb3F1ZSBHYWdsaWFubw0KPGJy Pg0KJmd0OyAocm9nYWdsaWEpJzxicj4NCiZndDsgU3ViamVjdDogUkU6IHNlY3VyaXR5IGNvbnNp ZGVyYXRpb24gb2YgQ0dBIGFuZCBTU0FTIC0gSWktRCBhY3Rpb24NCjogPGJyPg0KJmd0OyBkcmFm dC1yYWZpZWUtNm1hbi1zc2FzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7VGhlIKGw U0VDobEgcGFydCBvZiBDR0EgaXMgbWVhbnQgdG8gcHJvdGVjdA0KYWdhaW5zdCBhIGRpZmZlcmVu dCA8YnI+DQomZ3Q7IGF0dGFjaywgb25lIGluIHdoaWNoIHRoZSBhdHRhY2tlciBoYXMgbm90IGNy YWNrZWQgdGhlIHByaXZhdGUga2V5Lg0KPGJyPg0KJmd0OyBJbnN0ZWFkLCB0aGUgYXR0YWNrZXIg dXNlcyBhIHB1YmxpYy9wcml2YXRlIGtleSBwYWlyIG9mIGhpcyBvd24gPGJyPg0KJmd0OyAmZ3Q7 Y2hvb3NpbmcsIGFuZCBhcnJhbmdlIGZvciB0aGUgaGFzaCBvZiB0aGF0IGtleSB0byBtYXRjaCB0 aGUgQ0dBDQo8YnI+DQomZ3Q7IGFkZHJlc3Mgb2YgdGhlIHRhcmdldC4gVGhpcyChsG9ubHmhsSBy ZXF1aXJlcyBPKDIqKig1OStTRUMqMTYpKQ0KPGJyPg0KJmd0OyBvcGVyYXRpb25zLCB3aGljaCBl dmVuIHdpdGggbGFyZ2UgdmFsdWVzIG9mIFNFQyBpcyBzdGlsbCBmYXIgbGVzcw0KPGJyPg0KJmd0 OyB0aGFuICZndDt3aGF0IGlzIHJlcXVpcmVkIHRvIGNyYWNrIFJTQSBvciBFQ0MuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBTbyBhY2NvcmRpbmcgdG8gd2hhdCBJIHVuZGVyc3RhbmQgZnJv bSB3aGF0IHlvdQ0Kd3JvdGUsIHRoZSBzZWMgdmFsdWU8YnI+DQomZ3Q7IG1ha2VzIHRoZSBmb3Ig YW4gZWFzaWVyIGF0dGFjayBhZ2FpbnN0IENHQSBhcyB0aGUgYXR0YWNrZXIgb25seSA8YnI+DQom Z3Q7IG5lZWRzIHRvIGZpbmQgdGhlIHNhbWUgdmFsdWUgZ2VuZXJhdGVkIGJ5IGhpcyBvd24gbW9k aWZpZXIgYW5kIG90aGVyPGJyPg0KJmd0OyBwYXJhbWV0ZXJzIGFuZCBtYXRjaGVzIHRoaXMgdG8g dGhlIElJRCBvZiB0aGUgbm9kZS4gTm93IHRoZSBxdWVzdGlvbjxicj4NCiZndDsgYWdhaW4gaXMs IGlmIHRoaXMgZ2l2ZXMgYW4gYXR0YWNrZXIgYSBsZWcgdXAgaW4gZG9pbmcgaGlzIGJydXRlIDxi cj4NCiZndDsgZm9yY2UgYXR0YWNrcyB3aHkgZG8gd2UgbmVlZCB0byBhZGQgdGhvc2Ugc3RlcHMg dG8gQ0dBLiBUaGlzIHdhcyB3aHk8YnI+DQomZ3Q7IEkgdXNlZCB0aGUgZGlyZWN0IHB1YmxpYyBr ZXkgYXMgYSBwYXJ0IG9mIElQIGFkZHJlc3MuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBU aGFua3MgYWdhaW4gQ2hyaXN0aWFuLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBIb3NuaWVoPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNw OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBDaHJpc3RpYW4g SHVpdGVtYSBbbWFpbHRvOmh1aXRlbWFAbWljcm9zb2Z0LmNvbV0NCjxicj4NCiZndDsgU2VudDog U2F0dXJkYXksIE1hcmNoIDE2LCAyMDEzIDc6MzAgUE08YnI+DQomZ3Q7IFRvOiBIb3NuaWVoIFJh ZmllZTsgaXB2NkBpZXRmLm9yZzsgc2FhZ0BpZXRmLm9yZzxicj4NCiZndDsgQ2M6ICdFcmlrIE5v cmRtYXJrJzsgYWxleGFuZHJ1LnBldHJlc2N1QGdtYWlsLmNvbTsgJ1JheSBIdW50ZXInOyA8YnI+ DQomZ3Q7IE1pY2hhZWwgUmljaGFyZHNvbjsgamVhbm1pY2hlbC5jb21iZXNAb3JhbmdlLmNvbTsg Um9xdWUgR2FnbGlhbm8gKHJvZ2FnbGlhKTxicj4NCiZndDsgU3ViamVjdDogUkU6IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb24gb2YgQ0dBIGFuZCBTU0FTIC0gSWktRCBhY3Rpb24NCjogPGJyPg0KJmd0 OyBkcmFmdC1yYWZpZWUtNm1hbi1zc2FzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBBcyB5 b3Ugc2F5LCB0aGUgYXR0YWNrIHRoYXQgeW91IG1lbnRpb24gZGVwZW5kcw0Kb24gdGhlIHN0cmVu Z3RoIG9mIDxicj4NCiZndDsgUlNBIG9yIEVDQy4gSW4gZmFjdCwgcHJldHR5IG11Y2ggYWxsIG9m IHB1YmxpYyBrZXkgY3J5cHRvZ3JhcGh5IDxicj4NCiZndDsgZGVwZW5kcyBvbiB0aGF0IHN0cmVu Z3RoLiBJdCBpcyBnZW5lcmFsbHkgYXNzdW1lZCB0aGF0IGNyYWNraW5nIGENCjxicj4NCiZndDsg bG9uZyBlbm91Z2ggUlNBIG9yIEVDQyBrZXkgaXMgbmVhcmx5IGltcG9zc2libGUuIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlIKGwU0VDobEgcGFydCBvZiBDR0EgaXMgbWVhbnQgdG8g cHJvdGVjdA0KYWdhaW5zdCBhIGRpZmZlcmVudCA8YnI+DQomZ3Q7IGF0dGFjaywgb25lIGluIHdo aWNoIHRoZSBhdHRhY2tlciBoYXMgbm90IGNyYWNrZWQgdGhlIHByaXZhdGUga2V5Lg0KPGJyPg0K Jmd0OyBJbnN0ZWFkLCB0aGUgYXR0YWNrZXIgdXNlcyBhIHB1YmxpYy9wcml2YXRlIGtleSBwYWly IG9mIGhpcyBvd24gPGJyPg0KJmd0OyBjaG9vc2luZywgYW5kIGFycmFuZ2UgZm9yIHRoZSBoYXNo IG9mIHRoYXQga2V5IHRvIG1hdGNoIHRoZSBDR0EgPGJyPg0KJmd0OyBhZGRyZXNzIG9mIHRoZSB0 YXJnZXQuIFRoaXMgobBvbmx5obEgcmVxdWlyZXMgTygyKiooNTkrU0VDKjE2KSkNCjxicj4NCiZn dDsgb3BlcmF0aW9ucywgd2hpY2ggZXZlbiB3aXRoIGxhcmdlIHZhbHVlcyBvZiBTRUMgaXMgc3Rp bGwgZmFyIGxlc3MNCjxicj4NCiZndDsgdGhhbiB3aGF0IGlzIHJlcXVpcmVkIHRvIGNyYWNrIFJT QSBvciBFQ0MuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBIb3NuaWVoIFJhZmll ZSBbbWFpbHRvOmlldGZAcm96YW5hay5jb21dDQo8YnI+DQomZ3Q7IFNlbnQ6IFNhdHVyZGF5LCBN YXJjaCAxNiwgMjAxMyAxMDo1OSBBTTxicj4NCiZndDsgVG86IENocmlzdGlhbiBIdWl0ZW1hOyBp cHY2QGlldGYub3JnOyBzYWFnQGlldGYub3JnPGJyPg0KJmd0OyBDYzogJ0VyaWsgTm9yZG1hcmsn OyBhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tOyAnUmF5IEh1bnRlcic7IDxicj4NCiZndDsg TWljaGFlbCBSaWNoYXJkc29uOyBqZWFubWljaGVsLmNvbWJlc0BvcmFuZ2UuY29tOyBSb3F1ZSBH YWdsaWFubyAocm9nYWdsaWEpPGJyPg0KJmd0OyBTdWJqZWN0OiBSRTogc2VjdXJpdHkgY29uc2lk ZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJaS1EIGFjdGlvbg0KOiA8YnI+DQomZ3Q7IGRyYWZ0 LXJhZmllZS02bWFuLXNzYXM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEhpIENocmlzdGlh biw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgQnV0IGNhbiB5IHRvb3UgZXhwbGFp biB3aHkgeW91IGJlbGlldmUgdGhhdA0KcmV0cmlldmluZyB0aGUgcHJpdmF0ZTxicj4NCiZndDsg a2V5IGZyb20gdGhlIHB1YmxpYyBrZXkgYW5kIGEgY2xlYXIgdGV4dC9lbmNyeXB0ZWQgdGV4dCBw YWlyIGlzIDxicj4NCiZndDsgZWFzaWVyIHRoYW4gYnJlYWtpbmcgYSBoYXNoPyA8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7IEhlcmUgd2UgZG8gbm90IHVzZSBhbnkgZW5jcnlwdGlvbiBhbmQg ZGVjcnlwdGlvbg0KYW5kIHdlIGp1c3Qgc2lnbiA8YnI+DQomZ3Q7IHRoZSBtZXNzYWdlIHVzaW5n IHByaXZhdGUga2V5IGFuZCB2ZXJpZnkgdGhlIG1lc3NhZ2UgdXNpbmcgcHVibGljDQprZXkuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7RGlkIHlvdSBzb21laG93IGNyYWNrIFJTQT88 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEkgZG8gbm90IHNheSB0aGF0IGl0IGlzIGVhc2ll ciB0byBmaW5kIHRoZSBwcml2YXRlDQprZXkgZnJvbSB0aGUgPGJyPg0KJmd0OyBwdWJsaWMga2V5 LiBCZWNhdXNlIGZvciBib3RoIFNTQVMgYW5kIENHQSwgcHVibGljL3ByaXZhdGUga2V5cyBhcmUN Cjxicj4NCiZndDsgdXNlZC4gSSBkbyBzYXkgdGhhdCB0aGUgU0hBeCBzdGVwcyB1c2VkIGZvciBD R0EgZ2VuZXJhdGlvbiBkbyBub3QNCjxicj4NCiZndDsgaW5jcmVhc2UgdGhlIGNvbXBsZXhpdHkg d2hlbiB1c2VkIGFnYWluc3QgYnJ1dGUgZm9yY2UgYXR0YWNrcy4gVGhpcw0KPGJyPg0KJmd0OyBp cyBiZWNhdXNlIGFuIGF0dGFja2VyIG9ubHkgbmVlZHMgdGhlIHByaXZhdGUga2V5IGFuZCBkb2Vz IG5vdCBuZWVkDQo8YnI+DQomZ3Q7IHRvIGZpbmQgdGhlIG1vZGlmaWVyIHRoYXQgd2FzIHVzZWQg aW4gdGhlIGdlbmVyYXRpb24gb2YgdGhlIG5vZGWhr3MNCjxicj4NCiZndDsgSUlEIG5vciBpcyB0 aGVyZSBhIG5lZWQgZm9yIGNoZWNraW5nIHRoZSBjb25kaXRpb24gb2Ygc2VjIGJ5IDE2IGJpdHM8 YnI+DQomZ3Q7IHdoaWNoIHNob3VsZCBiZSBlcXVhbCB0byB6ZXJvLiBJbiBTU0FTIEkganVzdCB1 c2UgdGhlIHB1YmxpYy9wcml2YXRlPGJyPg0KJmd0OyBrZXlzIGFuZCB0aGUgc2lnbmF0dXJlIGFu ZCBub3RoaW5nIGlzIGVuY3J5cHRlZC9kZWNyeXB0ZWQuIEluIENHQQ0KPGJyPg0KJmd0OyBzb21l IGV4dHJhIFNIQXggc3RlcHMgYXJlIHVzZWQgaW4gdGhlIGdlbmVyYXRpb24gb2YgdGhlaXIgSUlE IGFsb25nDQo8YnI+DQomZ3Q7IHdpdGggdGhlIHNpZ25hdHVyZS4gSSBzYXkgdGhhdCB0aGVzZSBz dGVwcyBhcmUgbm90IG5lZWRlZCBhcyBsb25nDQphczxicj4NCiZndDsgeW91IGluY2x1ZGUgYW5k IHNlbmQgYWxsIHBhcmFtZXRlcnMsIHVzZWQgaW4gdGhlIFNIQXggcHJvY2VzcywgaW4NCjxicj4N CiZndDsgdGhlIHBhY2tldCBmb3IgdmVyaWZpY2F0aW9uIHB1cnBvc2VzLiBTb21lIHBlb3BsZSBm ZWVsIHRoYXQgQ0dBICZuYnNwO2lzDQo8YnI+DQomZ3Q7IHNlY3VyZSBlbm91Z2ggd2hlbiB0aG9z ZSBzdGVwcyBhcmUgdXNlZC4gTm93IHdoYXQgSSB3YW50IHRvIHBvaW50DQo8YnI+DQomZ3Q7IG91 dCBoZXJlIGlzIHRoYXQgdGhlIENHQSBzZWN1cml0eSBsZXZlbCBpcyBvbmx5IGRlcGVuZGVudCBv biB0aGUgPGJyPg0KJmd0OyBhbGdvcml0aG0gdXNlZCBmb3Iga2V5IHBhaXIgYW5kIHNpZ25hdHVy ZSBnZW5lcmF0aW9uIGFuZCB0aGF0IHRob3NlDQo8YnI+DQomZ3Q7IGV4dHJhIHN0ZXBzIGRvIG5v dGhpbmcgZW5oYW5jZSB0aGUgc2VjdXJpdHkgc2lkZSBvZiB0aGluZ3MuIFRoZSA8YnI+DQomZ3Q7 IGFsZ29yaXRobXMgdXNlZCBjYW4gYmUgUlNBIG9yIEVDQyBvciB3aGF0ZXZlciwgYW5kIGFzIHN1 Y2ggdGhlIDxicj4NCiZndDsgc2l0dWF0aW9uIHdpbGwgYmUgdGhlIHNhbWUgYXMgaXQgaXMgZm9y IFNTQVMuIEkganVzdCByZW1vdmVkIHRoZSA8YnI+DQomZ3Q7IGNvbXBsZXhpdHkgZnJvbSB0aGUg dXNlIG9mIENHQSBpbiBvcmRlciB0byBlbmFibGUgYSBtb3JlIHByYWN0aWNhbA0KPGJyPg0KJmd0 OyBhbmQgZmFzdGVyIGdlbmVyYXRpb24gYW5kIHZlcmlmaWNhdGlvbiBwcm9jZXNzLjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU28gdGhlIHF1ZXN0aW9uIGlzbqGvdCBob3cgdG8gYnJlYWsg dGhlIGVuY3J5cHRlZA0KdGV4dCBidXQgaG93IHRvIDxicj4NCiZndDsgYnJlYWsgdGhlIHNpZ25h dHVyZS4gSW4gb3RoZXIgd29yZCwgJm5ic3A7dG8gZmluZCB0aGUgc2FtZSBwdWJsaWMNCmtleSBh cyA8YnI+DQomZ3Q7IHVzZWQgYnkgdGhlIGdlbmVyYXRvciBub2RlIG9yIGhvdyB0byBicmVhayB0 aGUgUlNBIG9yIEVDQy4gQmFzZWQgb24NCjxicj4NCiZndDsgbXkga25vd2xlZGdlIG9mIGhhc2gg YWxnb3JpdGhtcywgYXMgSSBtZW50aW9uZWQgaW4gbXkgcHJpb3IgPGJyPg0KJmd0OyBzZW50ZW5j ZSwgdGhpcyB3aWxsIGRlcGVuZCBvbiB0aGUgc3RyZW5ndGggb2YgdGhlIFJTQSBvciB3aGF0ZXZl cg0KPGJyPg0KJmd0OyBvdGhlciAmbmJzcDthbGdvcml0aG0gaXMgdXNlZCB0byBnZW5lcmF0ZSB0 aGVzZSBrZXlzIGFuZCBzaWduIHRoZQ0KPGJyPg0KJmd0OyBtZXNzYWdlLiBJZiB5b3Ugb3IgYW55 b25lIGVsc2UgdGhpbmtzIG90aGVyd2lzZSwgcGxlYXNlIGNvbnRyaWJ1dGUNCjxicj4NCiZndDsg dG8gdGhpcyBkaXNjdXNzaW9uIGFuZCBzaGFyZSB5b3VyIG9waW5pb25zLiBJIGFtIGp1c3QgY29t cGFyaW5nIHRoZQ0KPGJyPg0KJmd0OyBzZWN1cml0eSBhc3BlY3RzIG9mIFNTQVMsIHRoZSB0aW1l IGVmZmljaWVudCBhbGdvcml0aG0sIHRvIHRob3NlIG9mDQpDR0EuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBUaGFuayB5b3UsPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IEhvc25pZWg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBGcm9tOiBDaHJpc3RpYW4gSHVpdGVtYSBbbWFp bHRvOmh1aXRlbWFAbWljcm9zb2Z0LmNvbV0NCjxicj4NCiZndDsgU2VudDogU2F0dXJkYXksIE1h cmNoIDE2LCAyMDEzIDU6MzcgUE08YnI+DQomZ3Q7IFRvOiBIb3NuaWVoIFJhZmllZTsgaXB2NkBp ZXRmLm9yZzsgc2FhZ0BpZXRmLm9yZzxicj4NCiZndDsgQ2M6IEVyaWsgTm9yZG1hcms7IGFsZXhh bmRydS5wZXRyZXNjdUBnbWFpbC5jb207IFJheSBIdW50ZXI8YnI+DQomZ3Q7IFN1YmplY3Q6IFJF OiBzZWN1cml0eSBjb25zaWRlcmF0aW9uIG9mIENHQSBhbmQgU1NBUyAtIElpLUQgYWN0aW9uDQo6 IDxicj4NCiZndDsgZHJhZnQtcmFmaWVlLTZtYW4tc3NhczwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgSXQgaXMgdmVyeSBjbGVhciB0aGF0IGlmIHRoZSBhdHRhY2tlciBmaW5kcyB0aGUNCnBy aXZhdGUga2V5LCB0aGUgPGJyPg0KJmd0OyBzaXplIG9mIHRoZSBoYXNoIGRvZXMgbm90IG1hdHRl ci4gQnV0IGNhbiB5b3UgZXhwbGFpbiB3aHkgeW91IDxicj4NCiZndDsgYmVsaWV2ZSB0aGF0IHJl dHJpZXZpbmcgdGhlIHByaXZhdGUga2V5IGZyb20gdGhlIHB1YmxpYyBrZXkgYW5kIGENCjxicj4N CiZndDsgY2xlYXIgdGV4dC9lbmNyeXB0ZWQgdGV4dCBwYWlyIGlzIGVhc2llciB0aGFuIGJyZWFr aW5nIGEgaGFzaD8gRGlkDQo8YnI+DQomZ3Q7IHlvdSBzb21laG93IGNyYWNrIFJTQT88L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmlwdjYtYm91bmNlc0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7IEhvc25pZWgg UmFmaWVlPGJyPg0KJmd0OyBTZW50OiBTYXR1cmRheSwgTWFyY2ggMTYsIDIwMTMgNjoyNyBBTTxi cj4NCiZndDsgVG86IGlwdjZAaWV0Zi5vcmc7IHNhYWdAaWV0Zi5vcmc8YnI+DQomZ3Q7IENjOiBF cmlrIE5vcmRtYXJrOyBhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tOyBSYXkgSHVudGVyPGJy Pg0KJmd0OyBTdWJqZWN0OiBzZWN1cml0eSBjb25zaWRlcmF0aW9uIG9mIENHQSBhbmQgU1NBUyAt IElpLUQgYWN0aW9uIDogPGJyPg0KJmd0OyBkcmFmdC1yYWZpZWUtNm1hbi1zc2FzPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyBIZWxsbyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgVGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBkdXJpbmcgbXkgcHJlc2VudGF0aW9uDQph Ym91dCBzZWN1cml0eSA8YnI+DQomZ3Q7IGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyB0aGUgdXNl IG9mIG15IGFsZ29yaXRobSBjb21wYXJlZCB3aXRoIHRob3NlPGJyPg0KJmd0OyBvZiB0aGUgdXNl IG9mIENHQS4gQSBiaWcgbWlzdGFrZSB0aGF0IGlzIG1hZGUgd2hlbiBjb25zaWRlcmluZyBDR0EN Cjxicj4NCiZndDsgc2VjdXJpdHkgaXMgdGhhdCB0aGUgc2VjIHZhbHVlIHBsYXlzIGFuIGltcG9y dGFudCByb2xlIGFuZCB0aGF0IGFuDQo8YnI+DQomZ3Q7IGF0dGFja2VyIHdpbGwgbmVlZCB0byBk byBicnV0ZSBmb3JjZSBhdHRhY2tzIGFnYWluc3QgdGhlIElJRCBpbiA8YnI+DQomZ3Q7IG9yZGVy IHRvIGdlbmVyYXRlIHRoZSBzYW1lIElJRCBhcyBpcyBnZW5lcmF0ZWQgYnkgdGhlIHVzZSBvZiBD R0EuDQpJbjxicj4NCiZndDsgYSBDR0EgYW5hbHlzaXMgcGFwZXIgdGhleSB0YWxrIGFib3V0IGEg Q0dBIHNlY3VyaXR5IHZhdWx1ZSBvZiBwb3cNCjxicj4NCiZndDsgKDIsIHNlYyoxNiAqIDU5KSB3 aGVyZSAyIGlzIHRoZSBiYXNlIGFuZCBzZWMqMTYgKiA1OSBpcyB0aGUgPGJyPg0KJmd0OyBleHBv bmVudGlhbCB2YWx1ZSBhbmQgc28gdGhleSBpbmZlciB0aGF0IGJ5IGluY3JlYXNpbmcgdGhlIHNl YyB2YWx1ZTxicj4NCiZndDsgdXNlZCB3aXRoIENHQSBpdCB3aWxsIGJlIHNhZmVyLCBidXQgdGhp cyBJcyBub3QgdHJ1ZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEks IGFzIGFuIGF0dGFja2VyLCBqdXN0IHRvIG5lZWQgdG8gZmluZCB5b3VyDQpwcml2YXRlIGtleS4g VGhhdKGvcyBpdC48YnI+DQomZ3Q7IFRoaXMgaXMgYmVjYXVzZSB5b3UgaGF2ZSBhbHJlYWR5IGlu Y2x1ZGVkIHRoZSBDR0EgcGFyYW1ldGVycyAocHVibGljPGJyPg0KJmd0OyBrZXksIG1vZGlmaWVy LCBhbmQgb3RoZXIgcmVxdWlyZWQgcGFyYW1ldGVycykgaW4gdGhlICZuYnNwO3BhY2tldA0KdGhh dCA8YnI+DQomZ3Q7IHdhcyBzZW50IGFuZCBJIHdpbGwgaGF2ZSBubyBwcm9ibGVtIGluIHJlZ2Vu ZXJhdGluZyB0aGUgQ0dBLiBNeSBvbmx5PGJyPg0KJmd0OyBwcm9ibGVtIHdpbGwgYmUgaW4gZ2Vu ZXJhdGluZyB0aGUgc2lnbmF0dXJlIHRoYXQgY2FuIGJlIHZlcmlmaWVkIGJ5DQo8YnI+DQomZ3Q7 IHVzZSBvZiB5b3VyIHB1YmxpYyBrZXkuIFRoaXMgbWVhbnMgdGhhdCB5b3UganVzdCBpbmNyZWFz ZWQgdGhlIDxicj4NCiZndDsgY29tcGxleGl0eSBhbmQgdGltZSByZXF1aXJlZCBmb3IgZ2VuZXJh dGluZyBhbmQgdmVyaWZ5aW5nIHRoZSBJSUQNCjxicj4NCiZndDsgd2hpbGUgd2l0aCBTU0FTIHlv dSBjYW4gb2J0YWluIHRoZSBzYW1lIHNlY3VyaXR5IGFzIHdoZW4gdXNpbmcgQ0dBDQo8YnI+DQom Z3Q7IGJlY2F1c2UgaXRzIHNlY3VyaXR5IGFsc28gZGVwZW5kcyBvbiB0aGUgSGFzaCBmdW5jdGlv biB0aGF0IGlzIHVzZWQNCjxicj4NCiZndDsgdG8gZ2VuZXJhdGUgdGhlIGtleSBwYWlyIGFuZCBz aWduYXR1cmUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJZiB5b3Ug c2VuZCB0aGUgQ0dBIHBhcmFtZXRlcnMgdmlhIGEgc2FmZSBjaGFubmVsLA0KbGlrZSBpbiA8YnI+ DQomZ3Q7IGVzdGFibGlzaGluZyBUTFMgZXRjLiwgdGhlbiwgaW4gdGhhdCBjYXNlLCBDR0Egd291 bGQgYmUgbW9yZSBzZWN1cmUNCjxicj4NCiZndDsgdGhhbiBTU0FTLiBCdXQgaW4gcHJhY3RpY2Ug YWxsIHRoZSBkYXRhIGlzIHNlbnQgaW4gdGhlIHNhbWUgcGFja2V0DQo8YnI+DQomZ3Q7IHdpdGhv dXQgZW5jcnlwdGlvbi4gSWYgYSBzZWN1cmVkIGNoYW5uZWwgd291bGQgYmUgdXNlZCBpbiB0aGUg Q0dBDQo8YnI+DQomZ3Q7IHByb2Nlc3MgZm9yIHNlY3VyaXR5IHJlYXNvbnMgKHNlbmRpbmcgQ0dB IHBhcmFtZXRlcnMpLCB0aGVuIHRoZSBjb3N0PGJyPg0KJmd0OyBvZiB1c2luZyBDR0Egd291bGQg YmUgbXVjaCBncmVhdGVyIHRoYW4gdGhlIGNvc3Qgb2YgdXNpbmcgU1NBUy48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IE5vdyB0aGUgcXVlc3Rpb24gaXMsIFdoeSBub3QgdXNlIGEgbW9yZSBj b3N0DQplZmZpY2llbnQgYWxnb3JpdGhtIDxicj4NCiZndDsgdGhhdCBhZmZvcmQgeW91IHdpdGgg dGhlIHNhbWUgc2VjdXJpdHkgbGV2ZWwgYXMgd2hlbiB1c2luZyBDR0EuIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgSSBoYXZlIGFsc28gaW5jbHVkZWQgdGhlIHNlY3VyaXR5IGdyb3VwIGlu IHRoaXMNCmVtYWlsIHNvIHRoYXQgdGhleSA8YnI+DQomZ3Q7IGNhbiBhbHNvIGdpdmUgbWUgYW55 IGNvbW1lbnRzIHRoYXQgdGhleSBtaWdodCBoYXZlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgVGhhbmsgeW91LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBIb3Nu aWVoLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcg bGlzdDxicj4NCiZndDsgaXB2NkBpZXRmLm9yZzxicj4NCiZndDsgQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Njxicj4NCiZn dDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQo8L2ZvbnQ+PC90dD4NCg== --=_alternative 0015123948257B33_=-- From jari.arkko@piuha.net Thu Mar 21 14:03:57 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A061421F88CA; Thu, 21 Mar 2013 14:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPrrRF3Ed-zi; Thu, 21 Mar 2013 14:03:57 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D83F021F896C; Thu, 21 Mar 2013 14:03:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2D47E2CC55; Thu, 21 Mar 2013 23:03:56 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vq-XF9zDKCiG; Thu, 21 Mar 2013 23:03:55 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 8AABA2CC5D; Thu, 21 Mar 2013 23:03:54 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: Date: Thu, 21 Mar 2013 22:19:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> To: Christian Huitema , Hosnieh Rafiee X-Mailer: Apple Mail (2.1503) Cc: Ray Hunter , ipv6@ietf.org, saag@ietf.org Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 21:03:57 -0000 Is there a conclusion of this thread? My read of it is that no amount of = tweaking how you calculate the IID help the fact that in 59/62 bits you = have a limited space to search. The Sec scheme does help, but increases = costs equally for both attackers and defenders.=20 FWIW, I'm struggling to understand the draft. But I couldn't make it to = the meeting. Jari From ietf@rozanak.com Thu Mar 21 14:30:46 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED9621F8CDD; Thu, 21 Mar 2013 14:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSiNB28rjZFU; Thu, 21 Mar 2013 14:30:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E5E8021F86EC; Thu, 21 Mar 2013 14:30:45 -0700 (PDT) Received: from kopoli (g225043192.adsl.alicedsl.de [92.225.43.192]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lnxom-1UuIbN46J6-00fs8s; Thu, 21 Mar 2013 17:30:01 -0400 From: "Hosnieh Rafiee" To: "'Jari Arkko'" References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Date: Thu, 21 Mar 2013 22:29:43 +0100 Message-ID: <000001ce267b$3c9391a0$b5bab4e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHXneMGHmAW5UB77SINLzK5mVzpEgIthurZAZLsffoB8ouRLgJ/3rcyAgRh1nICrLEMiAGREIGWAlfcl1mYF0zgYA== Content-Language: en-us X-Provags-ID: V02:K0:nu3Nhh8CFNEdbgbFAVdcSCHV+FgfmeCyWuXn9NnhoBU kRH1oG/cV+Aer90q0tptoDuNYRDZRrdPHYpH77xTnGxYi6FAPQ UrsOYLXvPBhKHWGBzbmBTDJfYiIoJGRgfH7epe0FoaoNJFCSeO MUZvrijdAwppErY+ulMOGco7XSSoaAlKNnQpk5WWtKV7Snzjnn U5iXJ89bm1YFaahZ7wdVUEMzeXIMLtkOo20RSq1gRqWj0BjQv6 ErMNyPXOisSO2ERXmIZg0W5o092z2SZlo1OcCphg7inOqyolDR 12djuiSx9RFtT3hDeGqV/AZK5IETcm1kYGKvskB5R8TsBRVAHi hwuXaHDzFPBPSaJgq4Bo= Cc: ipv6@ietf.org, Erik Nordmark , zhou.sujing@zte.com.cn, 'Ray Hunter' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 21:30:46 -0000 Hi Jeri, What is it that you don't understand. I will be happy to explain it to you. There has been no resolution to the topic of the thread... I have been traveling and will be traveling all of next week so I have not had nor will have an opportunity to work on the code that is needed to try to break the RSA. I do not agree with what Christian posed about being able to easily break it mathematically in a few seconds and I will work on proving him wrong. Hosnieh -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, March 21, 2013 9:19 PM To: Christian Huitema; Hosnieh Rafiee Cc: Santosh Chokhani; ipv6@ietf.org; saag@ietf.org; Ray Hunter Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Is there a conclusion of this thread? My read of it is that no amount of tweaking how you calculate the IID help the fact that in 59/62 bits you have a limited space to search. The Sec scheme does help, but increases costs equally for both attackers and defenders. FWIW, I'm struggling to understand the draft. But I couldn't make it to the meeting. Jari From ietf@rozanak.com Thu Mar 21 16:09:17 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7737321F8FD3; Thu, 21 Mar 2013 16:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvNSHZsVJ+fv; Thu, 21 Mar 2013 16:09:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id D240821F8F9F; Thu, 21 Mar 2013 16:09:16 -0700 (PDT) Received: from kopoli (g225043192.adsl.alicedsl.de [92.225.43.192]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MYhGE-1UDwtM2YKY-00VTPM; Thu, 21 Mar 2013 19:08:23 -0400 From: "Hosnieh Rafiee" To: "'Jari Arkko'" Date: Fri, 22 Mar 2013 00:08:02 +0100 Message-ID: <000001ce2688$fa38b070$eeaa1150$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4miO9wnDeN9z2TTPqHolB7zORLMA== Content-Language: en-us X-Provags-ID: V02:K0:L661bQnoGmHh9RSROwsUuPvBQ4aDSXXorhPWx2opNDX XIe6W6pV08O6Te5pjGOyErOMnFtEF3RKOL5mHmK+joJC1UyC85 OdP84HgYJrDOGXHfRHd2hnvY42i7X61x/K3FDls6ieLPEuVjlR EZwM7RLHHy9zK2o8rdU9wdR1KKq1fOhGuHCegXQiqGZMC0EzJe eQHl2QSF3azUN+vUG/bujHg+1Xkpp7Q5faiQze6x2RbCv1iU1d qSsV0JoaIgmAkj+ZE5U3zOHg8M1eYhc+CQSEvJ6ViC/W8sx3Xe SCOBGjD9GiGkZgAue8vX94zuimCKL/+SYDkLOXwiiGbWAgp1Nu oJ/RRx0uvMVr6uJCE7TY= Cc: ipv6@ietf.org, 'Erik Nordmark' , zhou.sujing@zte.com.cn, 'Ray Hunter' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:09:17 -0000 Jari, > What changes from RFC 3972 to your draft in this high-level analysis? The difference between my draft and that of RFC 3972 is that I make use of the public key in the IP address directly. Doing it the way I have explained in my draft eliminates the need for the use of those SHAx steps because I believe the use of those steps does not lend itself to improved security. My reason for this opinion is that RFC 3972 can only prevent DAD attacks and not the other types of attacks. This attack can also be prevented by using CGA if we add this extra verification step (that of the node checking the public key of the sender to his own), otherwise RPKI would be used. This is the same procedure as outlined in my draft. So the security of both depends on the security of the public/ private keys. After a successful verification (which could have resulted from a fast relay attack) the attacker's link-layer address is included in a cache as a legitimate address, and if routing is based on the link-layer address, then the node has no way of knowing that it was just a replay attack. Otherwise, the use of RPKI, where the node that has this IP address/or link layer is specified, would contain this public key. This is why, in this case, the keys' security is very important. Thanks, Hosnieh -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, March 21, 2013 10:56 PM To: Hosnieh Rafiee Cc: 'Jari Arkko'; 'Santosh Chokhani'; ipv6@ietf.org; saag@ietf.org; 'Ray Hunter'; 'Christian Huitema'; Erik Nordmark; zhou.sujing@zte.com.cn; 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hosnieh, > What is it that you don't understand. I will be happy to explain it to you. Thanks. I read the details, but I'm missing the big picture. I.e., some effort is required from the owner to create an address. By repeating that effort (2^59)/2 times, someone else is likely to hit the same key with a key pair that he or she controls, and an attack can be launched. What changes from RFC 3972 to your draft in this high-level analysis? > There has been no resolution to the topic of the thread. Ok. Well that clarifies at least the state of the discussion. Thanks. Jari From huitema@microsoft.com Thu Mar 21 16:46:38 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6343921F8934; Thu, 21 Mar 2013 16:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjGTTifEv96R; Thu, 21 Mar 2013 16:46:37 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id 6183321F8904; Thu, 21 Mar 2013 16:46:37 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.204) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.651.3; Thu, 21 Mar 2013 23:46:30 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Thu, 21 Mar 2013 23:46:29 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 21 Mar 2013 23:46:03 +0000 From: Christian Huitema To: Jari Arkko , Hosnieh Rafiee Thread-Topic: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: AQHOJnepStFjw06iREiCX/u2coogqpiwzyPQ Date: Thu, 21 Mar 2013 23:46:02 +0000 Message-ID: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(13464002)(4396001)(76482001)(55846006)(47976001)(16406001)(23726001)(46406002)(80022001)(53806001)(46102001)(54356001)(56776001)(54316002)(69226001)(51856001)(59766001)(66066001)(77982001)(31966008)(56816002)(44976002)(65816001)(49866001)(47446002)(33656001)(74662001)(20776003)(74502001)(63696002)(47736001)(50466001)(79102001)(47776003)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB013; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0792DBEAD0 Cc: Ray Hunter , "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:46:38 -0000 SEC does not " increases costs equally for both attackers and defenders." A= n increase of time T for the defender correspond to an increase of time T*2= ^59 for the attacker. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Thursday, March 21, 2013 1:19 PM To: Christian Huitema; Hosnieh Rafiee Cc: Santosh Chokhani; ipv6@ietf.org; saag@ietf.org; Ray Hunter Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : = draft-rafiee-6man-ssas Is there a conclusion of this thread? My read of it is that no amount of tw= eaking how you calculate the IID help the fact that in 59/62 bits you have = a limited space to search. The Sec scheme does help, but increases costs eq= ually for both attackers and defenders.=20 FWIW, I'm struggling to understand the draft. But I couldn't make it to the= meeting. Jari From huitema@microsoft.com Thu Mar 21 16:56:30 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C81721F8DDB; Thu, 21 Mar 2013 16:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5FxpYol89gz; Thu, 21 Mar 2013 16:56:29 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 6071F21F8D8D; Thu, 21 Mar 2013 16:56:24 -0700 (PDT) Received: from BY2FFO11FD028.protection.gbl (10.1.15.203) by BY2FFO11HUB012.protection.gbl (10.1.14.83) with Microsoft SMTP Server (TLS) id 15.0.651.3; Thu, 21 Mar 2013 23:56:21 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Thu, 21 Mar 2013 23:56:21 +0000 Received: from TK5EX14MBXC273.redmond.corp.microsoft.com ([169.254.1.69]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 21 Mar 2013 23:56:20 +0000 From: Christian Huitema To: Hosnieh Rafiee , 'Jari Arkko' Thread-Topic: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas Thread-Index: Ac4miO9wnDeN9z2TTPqHolB7zORLMAABYOmw Date: Thu, 21 Mar 2013 23:56:20 +0000 Message-ID: References: <000001ce2688$fa38b070$eeaa1150$@rozanak.com> In-Reply-To: <000001ce2688$fa38b070$eeaa1150$@rozanak.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(199002)(189002)(13464002)(164054002)(46406002)(79102001)(44976002)(20776003)(56816002)(23726001)(53806001)(31966008)(54356001)(4396001)(47446002)(56776001)(51856001)(55846006)(74662001)(561944001)(69226001)(49866001)(47776003)(74502001)(76482001)(46102001)(77982001)(47736001)(47976001)(59766001)(66066001)(50466001)(54316002)(80022001)(16406001)(63696002)(65816001)(33656001)(50986001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB012; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0792DBEAD0 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , "zhou.sujing@zte.com.cn" , 'Ray Hunter' , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 23:56:30 -0000 Hosnieh, You should probably split your proposal in two parts: the proposal to repla= ce CGA by just checking an extract of the address; and potential improvemen= ts to SEND that are independent of whether we use CGA or your direct compar= ison alternative.=20 Your replacement of CGA works by copying some bits of the public key in the= IID field, instead of using bits from a hash function. I think this is a r= eally bad idea, since the number of bits that you can copy is limited. Your= initial design copied just 48 bits; you could change that to 56 bits or ma= ybe 62 bits in an improved design. Cracking the 48 bit version is trivial. = Cracking the 62 bit version will take longer, but with Moore's law there wi= ll come a point in the future where this too will be easy to crack. In cont= rast, CGA implementations can simply in the future increment the SEC value = for added robustness. Your draft is making other contributions, such as added verification steps,= or caching o results to prevent DOS attacks. These contributions could be = used to improve SEND. It would be better to separate them from the debate a= bout hash functions. -- Christian -----Original Message----- From: Hosnieh Rafiee [mailto:ietf@rozanak.com]=20 Sent: Thursday, March 21, 2013 4:08 PM To: 'Jari Arkko' Cc: 'Santosh Chokhani'; ipv6@ietf.org; saag@ietf.org; 'Ray Hunter'; Christi= an Huitema; 'Erik Nordmark'; zhou.sujing@zte.com.cn; 'Jeffrey Hutzelman' Subject: RE: [saag] security consideration of CGA and SSAS - I-D action : d= raft-rafiee-6man-ssas Jari, > What changes from RFC 3972 to your draft in this high-level analysis? The difference between my draft and that of RFC 3972 is that I make use of = the public key in the IP address directly. Doing it the way I have explaine= d in my draft eliminates the need for the use of those SHAx steps because = I believe the use of those steps does not lend itself to improved security.= My reason for this opinion is that RFC 3972 can only prevent DAD attacks a= nd not the other types of attacks. This attack can also be prevented by usi= ng CGA if we add this extra verification step (that of the node checking th= e public key of the sender to his own), otherwise RPKI would be used. This = is the same procedure as outlined in my draft. So the security of both depe= nds on the security of the public/ private keys. After a successful verific= ation (which could have resulted from a fast relay attack) the attacker's l= ink-layer address is included in a cache as a legitimate address, and if ro= uting is based on the link-layer address, then the node has no way of know= ing that it was just a replay attack. Otherwise, the use of RPKI, where the= node that has this IP address/or link layer is specified, would contain th= is public key. This is why, in this case, the keys' security is very import= ant. Thanks, Hosnieh -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Thursday, March 21, 2013 10:56 PM To: Hosnieh Rafiee Cc: 'Jari Arkko'; 'Santosh Chokhani'; ipv6@ietf.org; saag@ietf.org; 'Ray Hu= nter'; 'Christian Huitema'; Erik Nordmark; zhou.sujing@zte.com.cn; 'Jeffrey= Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Hosnieh, > What is it that you don't understand. I will be happy to explain it to you. Thanks. I read the details, but I'm missing the big picture. I.e., some effort is required from the owner to create an address. By repeating that effort (2^59)/2 times, someone else is likely to hit the same key with a ke= y pair that he or she controls, and an attack can be launched. What changes from RFC 3972 to your draft in this high-level analysis? > There has been no resolution to the topic of the thread.=20 Ok. Well that clarifies at least the state of the discussion. Thanks. Jari From jari.arkko@piuha.net Thu Mar 21 23:38:57 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2760B11E80A5; Thu, 21 Mar 2013 23:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 322pJpXVOn43; Thu, 21 Mar 2013 23:38:56 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4716611E80A4; Thu, 21 Mar 2013 23:38:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 33ED52CC55; Fri, 22 Mar 2013 08:38:55 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtRONMQIQGPC; Fri, 22 Mar 2013 08:38:54 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 59FB82CC3B; Fri, 22 Mar 2013 08:38:54 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: Date: Fri, 22 Mar 2013 08:38:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> To: Christian Huitema X-Mailer: Apple Mail (2.1503) Cc: "ipv6@ietf.org" , Ray Hunter , Jari Arkko , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 06:38:57 -0000 Christian, > SEC does not " increases costs equally for both attackers and = defenders." An increase of time T for the defender correspond to an = increase of time T*2^59 for the attacker. Right. I was speaking about the relative effort increase. For Sec =3D 0, = I have to do 1 unit of work, the attacker 2^59 units of work. For Sec =3D = 1, I have to do 2^16 units of work, the attacker 2^16 * 2^59 units of = work. The difference in the amount of time I and the attacker have to do = is always 2^59, but with Sec we can change how much work that is. Jari From Francis.Dupont@fdupont.fr Fri Mar 22 01:57:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5DC21F8896; Fri, 22 Mar 2013 01:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKyw9ndBNWXv; Fri, 22 Mar 2013 01:57:13 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id F2F2621F85B4; Fri, 22 Mar 2013 01:57:12 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2M8ul6q013200; Fri, 22 Mar 2013 09:56:47 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303220856.r2M8ul6q013200@givry.fdupont.fr> From: Francis Dupont To: "Hosnieh Rafiee" In-reply-to: Your message of Thu, 21 Mar 2013 22:29:43 +0100. <000001ce267b$3c9391a0$b5bab4e0$@rozanak.com> Date: Fri, 22 Mar 2013 09:56:47 +0100 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org, Erik Nordmark , 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 08:57:13 -0000 In your previous mail you wrote: > ... nor will have an opportunity to work on the code that is needed > to try to break the RSA. I do not agree with what Christian posed > about being able to easily break it mathematically in a few seconds > and I will work on proving him wrong. => not only I agree with Christian Huitema but I showed a proof that in the RSA case the proposal can be broken in a time frame similar to the key pair generation one and independently of the number of bits, i.e., 48 as in the proposal or up to 64 which is the maximum from the Interface ID. So my conclusion is for the security an attempt to provide the same level than CGAs should only reinvent CGAs. About privacy I have the same concerns about the proposal than about RFC 3041/4941, i.e., to change the IID doesn't help when the assigned prefix is kept. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Mar 22 02:27:59 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3421F8A0D; Fri, 22 Mar 2013 02:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw-ntwDIvATv; Fri, 22 Mar 2013 02:27:58 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2B121F8936; Fri, 22 Mar 2013 02:27:58 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2M9Qsjs015144; Fri, 22 Mar 2013 10:26:54 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303220926.r2M9Qsjs015144@givry.fdupont.fr> From: Francis Dupont To: "Hosnieh Rafiee" In-reply-to: Your message of Fri, 22 Mar 2013 00:08:02 +0100. <000001ce2688$fa38b070$eeaa1150$@rozanak.com> Date: Fri, 22 Mar 2013 10:26:54 +0100 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org, 'Erik Nordmark' , 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:27:59 -0000 In your previous mail you wrote: > > What changes from RFC 3972 to your draft in this high-level analysis? > > The difference between my draft and that of RFC 3972 is that I make use of > the public key in the IP address directly. => this is IMHO a bad idea because it limits the search space in the best case (i.e., not when the structure of the public key allows trivial attacks as in the RSA case) to 2**64. > Doing it the way I have explained > in my draft eliminates the need for the use of those SHAx steps because I > believe the use of those steps does not lend itself to improved security. => I strongly disagree: the use of those SHAx steps is the way to extend the search space and until SHAx pre-images are broken for the worst case (i.e., no attack better than brute force). > My > reason for this opinion is that RFC 3972 can only prevent DAD attacks and > not the other types of attacks. This attack can also be prevented by using > CGA if we add this extra verification step (that of the node checking the > public key of the sender to his own), otherwise RPKI would be used. This is > the same procedure as outlined in my draft. So the security of both depends > on the security of the public/ private keys. After a successful verification > (which could have resulted from a fast relay attack) the attacker's > link-layer address is included in a cache as a legitimate address, and if > routing is based on the link-layer address, then the node has no way of > knowing that it was just a replay attack. Otherwise, the use of RPKI, where > the node that has this IP address/or link layer is specified, would contain > this public key. This is why, in this case, the keys' security is very > important. => this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against replay but provides message (aka connectionless) integrity so any use of CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and timestamps for anti-replay). BTW CGAs and SSASs are the same for this point. Regards Francis.Dupont@fdupont.fr PS: I don't say to put the public key in the address is intrinsically broken but it cannot be done this way. I suggest to look at Identity Based Cryptography (the SAAG could provide guidance). From ietf@rozanak.com Fri Mar 22 05:46:54 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6588321F8B35; Fri, 22 Mar 2013 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U13JGCh8Ry4O; Fri, 22 Mar 2013 05:46:53 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9005521F8AB8; Fri, 22 Mar 2013 05:46:46 -0700 (PDT) Received: from kopoli (g231250072.adsl.alicedsl.de [92.231.250.72]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lt0io-1UhsYP02SQ-012bGA; Fri, 22 Mar 2013 08:46:02 -0400 From: "Hosnieh Rafiee" To: References: Your message of Fri, 22 Mar 2013 00:08:02 +0100. <000001ce2688$fa38b070$eeaa1150$@rozanak.com> <201303220926.r2M9Qsjs015144@givry.fdupont.fr> In-Reply-To: <201303220926.r2M9Qsjs015144@givry.fdupont.fr> Date: Fri, 22 Mar 2013 13:45:44 +0100 Message-ID: <000601ce26fb$339606c0$9ac21440$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDReMsZNTrc8csAEknxvptBN2RYSJqq/fSA Content-Language: en-us X-Provags-ID: V02:K0:w/11Xt6c1JLQ6dydOgcIXY8V9N1I8iA7c1pMQL+PRnI 20+ngG1nTlUQwNq9ScfkVIV6bA1cugeG76UEVz/N1ZUvnXvnTg DnrBQtKJ7QBMWM+4Gb9HBbcOOJsfo6uiEd39SRNX86YTZWr2yh SrBoLgOlxu2IaoX32z5YdbMJKV2aCwqAVFmPmzU77a5zNKq0vf wXSp0CDCOi/C27M8Tkl4Kec6w+W8cSyxonuqlotrlWD5dUWr0K F4/eAQTvZR45ATubKOIn5Q3rjTHT4yy5rB9bb7ueJvJrePPQ6F bYEPiR0fvUz1+Vx2j4w1jgB442voIRDA2Qb6rSZ/JrH2b0c5M1 1p5QDenF7yjEQ9P7y8Bw= Cc: ipv6@ietf.org, 'Erik Nordmark' , 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:46:54 -0000 Francis, => I strongly disagree: the use of those SHAx steps is the way to extend the search space and until SHAx pre-images are broken for the worst case (i.e., no attack better than brute force). Be patient please. It takes time to prepare a response because I will need to work on code to break RSA and also SHAx (CGA) and currently I have no opportunity to work on this. => this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against replay but provides message (aka connectionless) integrity so any use of CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and timestamps for anti-replay). BTW CGAs and SSASs are the same for this point. Nonce and timestamp both cannot be much helpful for relay attacks. I mentioned a fast replay attack. You need to consider the clock skew for timestamp (two seconds or so). The other nodes do not know the nonce is for an attacker or for your node. I, as an attacker, can easily copy and paste the whole packet content in my message with my own link layer address and send it back to you. There is difference between SSAS and CGA in DAD process. There is no doubt that CGA verification needs improvements, I probably try to write another draft and improve that document too while at the same time as I am improving SSAS with the best design of RPKI (I will do that after my trip :-) so give me more time...). Thanks, Hosnieh From jari.arkko@piuha.net Thu Mar 21 14:55:44 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BAB21F84B2; Thu, 21 Mar 2013 14:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09xl53qgifLf; Thu, 21 Mar 2013 14:55:44 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 045A321F8CDD; Thu, 21 Mar 2013 14:55:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 05C7B2CC4A; Thu, 21 Mar 2013 23:55:37 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_btdR2oZfAK; Thu, 21 Mar 2013 23:55:36 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CD9FE2CC55; Thu, 21 Mar 2013 23:55:35 +0200 (EET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: <000001ce267b$3c9391a0$b5bab4e0$@rozanak.com> Date: Thu, 21 Mar 2013 23:55:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <000001ce267b$3c9391a0$b5bab4e0$@rozanak.com> To: "Hosnieh Rafiee" X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: ipv6@ietf.org, Erik Nordmark , zhou.sujing@zte.com.cn, 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2013 21:55:44 -0000 Hosnieh, > What is it that you don't understand. I will be happy to explain it to = you. Thanks. I read the details, but I'm missing the big picture. I.e., some = effort is required from the owner to create an address. By repeating = that effort (2^59)/2 times, someone else is likely to hit the same key = with a key pair that he or she controls, and an attack can be launched. = What changes from RFC 3972 to your draft in this high-level analysis? > There has been no resolution to the topic of the thread=85=20 Ok. Well that clarifies at least the state of the discussion. Thanks. Jari From zhou.sujing@zte.com.cn Thu Mar 21 19:18:29 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AFF21F8F4A; Thu, 21 Mar 2013 19:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.243 X-Spam-Level: X-Spam-Status: No, score=-98.243 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Nqd-uN4BrEg; Thu, 21 Mar 2013 19:18:29 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C297C21F8F3A; Thu, 21 Mar 2013 19:18:28 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 57ACE127BF60; Fri, 22 Mar 2013 10:04:36 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E23BC700360; Fri, 22 Mar 2013 10:05:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r2M2I3Ku073147; Fri, 22 Mar 2013 10:18:03 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Jari Arkko MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 22 Mar 2013 10:17:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-03-22 10:17:57, Serialize complete at 2013-03-22 10:17:57 Content-Type: multipart/alternative; boundary="=_alternative 000CB21A48257B36_=" X-MAIL: mse02.zte.com.cn r2M2I3Ku073147 X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: ipv6@ietf.org, saag@ietf.org, Erik Nordmark , 'Ray Hunter' , 'Jari Arkko' , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 02:18:29 -0000 This is a multipart message in MIME format. --=_alternative 000CB21A48257B36_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+INC009ogMjAxMy0wMy0yMiAwNTo1NToz NToNCg0KPiANCj4gSG9zbmllaCwNCj4gDQo+ID4gV2hhdCBpcyBpdCB0aGF0IHlvdSBkb24ndCB1 bmRlcnN0YW5kLiBJIHdpbGwgYmUgaGFwcHkgdG8gZXhwbGFpbiBpdCB0byANCnlvdS4NCj4gDQo+ IFRoYW5rcy4gSSByZWFkIHRoZSBkZXRhaWxzLCBidXQgSSdtIG1pc3NpbmcgdGhlIGJpZyBwaWN0 dXJlLiBJLmUuLCANCj4gc29tZSBlZmZvcnQgaXMgcmVxdWlyZWQgZnJvbSB0aGUgb3duZXIgdG8g Y3JlYXRlIGFuIGFkZHJlc3MuIEJ5IA0KPiByZXBlYXRpbmcgdGhhdCBlZmZvcnQgKDJeNTkpLzIg dGltZXMsIHNvbWVvbmUgZWxzZSBpcyBsaWtlbHkgdG8gaGl0IA0KU2hvdWxkIGJlIGxlc3MgdGhh biAoMl41OSkvMiB3aGljaCBpcyBhbiBlc3RpbWF0aW9uIGZvciBoYXNoIGNvbGxpc2lvbi4NCkZv ciB0aGUgc2NoZW1lIGluIHRoaXMgZHJhZnSjrA0KICAgdGhlIHByb2JhYmlsaXR5IG9mIGEgYSBz ZWNvbmQgcHVibGljIGtleSBpczogMS0oMS1wKV4oMl57MTAyNC00OH0pLCANCndoZXJlIHAgaXMg dGhlIHByb2JhYmlsaXR5IG9mIGEgcmFuZG9tIG51bWJlciBiZWluZyBhIFJTQSBwdWJsaWMga2V5 Lg0KRm9yIHRoZSBDR0EsIA0KICAgIHRoZSBwcm9iYWJpbGl0eSBvZiBhIHNlY29uZCBwdWJsaWMg a2V5ICAgaXM6Ml57LTI5LjV9KnAgDQoNClRoZSBmaXJzdCBwcm9iYWJpbGl0eSBzaG91bGQgYmUg cXVpdGUgcXVpdGUgYmlnZ2VyIHRoYW4gdGhlIHNlY29uZC4gDQoNCj4gdGhlIHNhbWUga2V5IHdp dGggYSBrZXkgcGFpciB0aGF0IGhlIG9yIHNoZSBjb250cm9scywgYW5kIGFuIGF0dGFjayANCj4g Y2FuIGJlIGxhdW5jaGVkLiBXaGF0IGNoYW5nZXMgZnJvbSBSRkMgMzk3MiB0byB5b3VyIGRyYWZ0 IGluIHRoaXMgDQo+IGhpZ2gtbGV2ZWwgYW5hbHlzaXM/DQo+IA0KPiA+IFRoZXJlIGhhcyBiZWVu IG5vIHJlc29sdXRpb24gdG8gdGhlIHRvcGljIG9mIHRoZSB0aHJlYWShrSANCj4gDQo+IE9rLiBX ZWxsIHRoYXQgY2xhcmlmaWVzIGF0IGxlYXN0IHRoZSBzdGF0ZSBvZiB0aGUgZGlzY3Vzc2lvbi4g VGhhbmtzLg0KPiANCj4gSmFyaQ0KPiANCj4gDQoNCg== --=_alternative 000CB21A48257B36_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5KYXJpIEFya2tvICZsdDtqYXJpLmFya2tvQHBp dWhhLm5ldCZndDsg0LTT2iAyMDEzLTAzLTIyDQowNTo1NTozNTo8YnI+DQo8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSG9zbmllaCw8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBXaGF0IGlzIGl0IHRo YXQgeW91IGRvbid0IHVuZGVyc3RhbmQuIEkgd2lsbCBiZSBoYXBweSB0byBleHBsYWluDQppdCB0 byB5b3UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcy4gSSByZWFkIHRoZSBkZXRhaWxzLCBi dXQgSSdtIG1pc3NpbmcgdGhlIGJpZyBwaWN0dXJlLiBJLmUuLA0KPGJyPg0KJmd0OyBzb21lIGVm Zm9ydCBpcyByZXF1aXJlZCBmcm9tIHRoZSBvd25lciB0byBjcmVhdGUgYW4gYWRkcmVzcy4gQnkg PGJyPg0KJmd0OyByZXBlYXRpbmcgdGhhdCBlZmZvcnQgKDJeNTkpLzIgdGltZXMsIHNvbWVvbmUg ZWxzZSBpcyBsaWtlbHkgdG8gaGl0DQo8YnI+DQpTaG91bGQgYmUgbGVzcyB0aGFuICgyXjU5KS8y IHdoaWNoIGlzIGFuIGVzdGltYXRpb24gZm9yIGhhc2ggY29sbGlzaW9uLjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Rm9yIHRoZSBzY2hlbWUgaW4gdGhpcyBkcmFmdKOsPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7dGhlIHByb2JhYmlsaXR5 IG9mIGEgYSBzZWNvbmQgcHVibGljDQprZXkgaXM6IDEtKDEtcCleKDJeezEwMjQtNDh9KSwgd2hl cmUgcCBpcyB0aGUgcHJvYmFiaWxpdHkgb2YgYSByYW5kb20gbnVtYmVyDQpiZWluZyBhIFJTQSBw dWJsaWMga2V5LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Rm9yIHRoZSBDR0Es IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyB0aGUgcHJv YmFiaWxpdHkgb2YgYSBzZWNvbmQgcHVibGljIGtleQ0KJm5ic3A7IGlzOjJeey0yOS41fSpwIDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhlIGZpcnN0IHByb2JhYmls aXR5IHNob3VsZCBiZSBxdWl0ZSBxdWl0ZSBiaWdnZXINCnRoYW4gdGhlIHNlY29uZC4gPC9mb250 PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IHRoZSBzYW1lIGtleSB3aXRo IGEga2V5IHBhaXIgdGhhdCBoZSBvciBzaGUgY29udHJvbHMsDQphbmQgYW4gYXR0YWNrIDxicj4N CiZndDsgY2FuIGJlIGxhdW5jaGVkLiBXaGF0IGNoYW5nZXMgZnJvbSBSRkMgMzk3MiB0byB5b3Vy IGRyYWZ0IGluIHRoaXMNCjxicj4NCiZndDsgaGlnaC1sZXZlbCBhbmFseXNpcz88YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyBUaGVyZSBoYXMgYmVlbiBubyByZXNvbHV0aW9uIHRvIHRoZSB0b3Bp YyBvZiB0aGUgdGhyZWFkoa0gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9rLiBXZWxsIHRoYXQgY2xh cmlmaWVzIGF0IGxlYXN0IHRoZSBzdGF0ZSBvZiB0aGUgZGlzY3Vzc2lvbi4gVGhhbmtzLjxicj4N CiZndDsgPGJyPg0KJmd0OyBKYXJpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48 L3R0Pg0K --=_alternative 000CB21A48257B36_=-- From v6ops@globis.net Fri Mar 22 02:02:19 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC721F855F; Fri, 22 Mar 2013 02:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIZu5vwmC7u2; Fri, 22 Mar 2013 02:02:17 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0564321F854F; Fri, 22 Mar 2013 02:02:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 22DED8700DE; Fri, 22 Mar 2013 10:02:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcKa0lY8EpS8; Fri, 22 Mar 2013 10:01:39 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 892AA87005B; Fri, 22 Mar 2013 10:01:39 +0100 (CET) Message-ID: <514C1DED.4070103@globis.net> Date: Fri, 22 Mar 2013 10:01:33 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Jari Arkko References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: "ipv6@ietf.org" , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 09:02:19 -0000 agreed. FWIW I suggested to Hosnieh earlier (in a private mail) to support multiple alternative authentication mechanisms, and to make this flexible for the future. This draft is effectively discussing tuning an authentication protocol to reduce the amount of work done by the defender (to make it faster than CGA) whilst keeping the amount of work the attacker has to do high enough to avoid common attacks. We can argue all we like about the current balance of power as of today, but that's not the main issue. IMHO Over the course of years that this type of protocol is in operation, the work has to increase for both defender and attacker (due to Moore's law) to keep the "amount of effort to break" constant. CGA allows this. The current draft does not. > Jari Arkko > 22 March 2013 07:38 > Christian, > > > Right. I was speaking about the relative effort increase. For Sec = 0, > I have to do 1 unit of work, the attacker 2^59 units of work. For Sec > = 1, I have to do 2^16 units of work, the attacker 2^16 * 2^59 units > of work. The difference in the amount of time I and the attacker have > to do is always 2^59, but with Sec we can change how much work that is. > > Jari > > Christian Huitema > 22 March 2013 00:46 > SEC does not " increases costs equally for both attackers and > defenders." An increase of time T for the defender correspond to an > increase of time T*2^59 for the attacker. > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Thursday, March 21, 2013 1:19 PM > To: Christian Huitema; Hosnieh Rafiee > Cc: Santosh Chokhani; ipv6@ietf.org; saag@ietf.org; Ray Hunter > Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D > action : draft-rafiee-6man-ssas > > Is there a conclusion of this thread? My read of it is that no amount > of tweaking how you calculate the IID help the fact that in 59/62 bits > you have a limited space to search. The Sec scheme does help, but > increases costs equally for both attackers and defenders. > > FWIW, I'm struggling to understand the draft. But I couldn't make it > to the meeting. > > Jari > > Jari Arkko > 21 March 2013 21:19 > Is there a conclusion of this thread? My read of it is that no amount > of tweaking how you calculate the IID help the fact that in 59/62 bits > you have a limited space to search. The Sec scheme does help, but > increases costs equally for both attackers and defenders. > > FWIW, I'm struggling to understand the draft. But I couldn't make it > to the meeting. > > Jari > > Christian Huitema > 18 March 2013 03:03 > > Santosh, I suppose we have to use more than 2048 bits for RSA then… > But that’s not really the point of the debate. > > CGA is an algorithm specified for IPv6 “secure neighbor discovery” and > is specified in RFC 3972. CGA works by associating an IPv6 address > with a public key. The public key is hashed with the network prefix > (first 64 bits of IPv6 address) and 59 bits of the hash are copied to > the host identifier part of the IPv6 address. In the most basic > implementation, senders prove ownership of the address by > demonstrating possession of a public/private key pair, and receiver > verify also that the specified 59 bits of the hash match what is in > the address. > > Of course, 59 bits is a rather small number, and matching only 59 bits > instead of 160 seriously weakens the strength of the algorithm. The > CGA spec includes a “hash augmentation” mechanism, the “SEC” fields, > which specifies an additional constraint on the content of the hash, > namely that the hash begins by a set number of zeroes – 16 times the > number in the SEC field. That mechanism requires that the host > generating a secure address spends some time finding the right hash. > > Hosnieh proposes to replace that mechanism by simply copying in the > IPv6 address a number of bits from the public key – 48 in the original > proposal. > > *From:* Santosh Chokhani [mailto:SChokhani@cygnacom.com] > *Sent:* Sunday, March 17, 2013 6:36 PM > *To:* Christian Huitema; Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org > *Cc:* alexandru.petrescu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik > Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com > *Subject:* RE: [saag] security consideration of CGA and SSAS - Ii-D > action : draft-rafiee-6man-ssas > > 2048 bit RSA security is overstated. Cracking it requires on the order > of 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2 > Section 5.6.1. > > From the description you provide on hashing, finding a second hash is > a second pre-image attack and for SHA-1 the security strength is 160 > bits, i.e., you need on the order of 2^160 operations. > > I do not know what hash function you are describing for the function > you mention and how you derived its security strength. > > *From:*saag-bounces@ietf.org > [mailto:saag-bounces@ietf.org] *On Behalf Of *Christian Huitema > *Sent:* Sunday, March 17, 2013 4:14 AM > *To:* Hosnieh Rafiee; ipv6@ietf.org ; > saag@ietf.org > *Cc:* alexandru.petrescu@gmail.com > ; 'Roque Gagliano (rogaglia)'; > 'Erik Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com > > *Subject:* Re: [saag] security consideration of CGA and SSAS - Ii-D > action : draft-rafiee-6man-ssas > > The attack is **relatively** easier. It is not “easy.” It is much > harder to crack RSA than to find a matching hash. Cracking a 2048 bits > RSA key probably requires on the order of 2^1024 trials, and that will > take you something like “forever.” Cracking the hash requires only > something on the order of 2^91 trials with SEC=2. That’s obviously > much less, but that’s still a very large number. The exhausting search > will take you many years, i.e. much more than the valid lifetime of > the address. > > *From:* Hosnieh Rafiee [mailto:ietf@rozanak.com] > *Sent:* Saturday, March 16, 2013 1:45 PM > *To:* Christian Huitema; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; 'Michael > Richardson'; jeanmichel.combes@orange.com > ; 'Roque Gagliano (rogaglia)' > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > >The “SEC” part of CGA is meant to protect against a different attack, > one in which the attacker has not cracked the private key. Instead, > the attacker uses a public/private key pair of his own >choosing, and > arrange for the hash of that key to match the CGA address of the > target. This “only” requires O(2**(59+SEC*16)) operations, which even > with large values of SEC is still far less than >what is required to > crack RSA or ECC. > > So according to what I understand from what you wrote, the sec value > makes the for an easier attack against CGA as the attacker only needs > to find the same value generated by his own modifier and other > parameters and matches this to the IID of the node. Now the question > again is, if this gives an attacker a leg up in doing his brute force > attacks why do we need to add those steps to CGA. This was why I used > the direct public key as a part of IP address. > > Thanks again Christian. > > Hosnieh > > *From:*Christian Huitema [mailto:huitema@microsoft.com] > *Sent:* Saturday, March 16, 2013 7:30 PM > *To:* Hosnieh Rafiee; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; Michael > Richardson; jeanmichel.combes@orange.com > ; Roque Gagliano (rogaglia) > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > As you say, the attack that you mention depends on the strength of RSA > or ECC. In fact, pretty much all of public key cryptography depends on > that strength. It is generally assumed that cracking a long enough RSA > or ECC key is nearly impossible. > > The “SEC” part of CGA is meant to protect against a different attack, > one in which the attacker has not cracked the private key. Instead, > the attacker uses a public/private key pair of his own choosing, and > arrange for the hash of that key to match the CGA address of the > target. This “only” requires O(2**(59+SEC*16)) operations, which even > with large values of SEC is still far less than what is required to > crack RSA or ECC. > > *From:* Hosnieh Rafiee [mailto:ietf@rozanak.com] > *Sent:* Saturday, March 16, 2013 10:59 AM > *To:* Christian Huitema; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; Michael > Richardson; jeanmichel.combes@orange.com > ; Roque Gagliano (rogaglia) > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > Hi Christian, > > > But can y toou explain why you believe that retrieving the private > key from the public key and a clear text/encrypted text pair is easier > than breaking a hash? > > Here we do not use any encryption and decryption and we just sign the > message using private key and verify the message using public key. > > >Did you somehow crack RSA? > > I do not say that it is easier to find the private key from the public > key. Because for both SSAS and CGA, public/private keys are used. I do > say that the SHAx steps used for CGA generation do not increase the > complexity when used against brute force attacks. This is because an > attacker only needs the private key and does not need to find the > modifier that was used in the generation of the node’s IID nor is > there a need for checking the condition of sec by 16 bits which should > be equal to zero. In SSAS I just use the public/private keys and the > signature and nothing is encrypted/decrypted. In CGA some extra SHAx > steps are used in the generation of their IID along with the > signature. I say that these steps are not needed as long as you > include and send all parameters, used in the SHAx process, in the > packet for verification purposes. Some people feel that CGA is secure > enough when those steps are used. Now what I want to point out here is > that the CGA security level is *only* dependent on the algorithm used > for key pair and signature generation and that those extra steps do > nothing enhance the security side of things. The algorithms used can > be RSA or ECC or whatever, and as such the situation will be the same > as it is for SSAS. I just removed the complexity from the use of CGA > in order to enable a more practical and faster generation and > verification process. > > So the question isn’t how to break the encrypted text but how to break > the signature. In other word, to find the same public key as used by > the generator node or how to break the RSA or ECC. Based on my > knowledge of hash algorithms, as I mentioned in my prior sentence, > this will depend on the strength of the RSA or whatever other > algorithm is used to generate these keys and sign the message. If you > or anyone else thinks otherwise, please contribute to this discussion > and share your opinions. I am just comparing the security aspects of > SSAS, the time efficient algorithm, to those of CGA. > > Thank you, > > Hosnieh > > *From:*Christian Huitema [mailto:huitema@microsoft.com] > *Sent:* Saturday, March 16, 2013 5:37 PM > *To:* Hosnieh Rafiee; ipv6@ietf.org ; > saag@ietf.org > *Cc:* Erik Nordmark; alexandru.petrescu@gmail.com > ; Ray Hunter > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > It is very clear that if the attacker finds the private key, the size > of the hash does not matter. But can you explain why you believe that > retrieving the private key from the public key and a clear > text/encrypted text pair is easier than breaking a hash? Did you > somehow crack RSA? > > *From:* ipv6-bounces@ietf.org > [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Hosnieh Rafiee > *Sent:* Saturday, March 16, 2013 6:27 AM > *To:* ipv6@ietf.org ; saag@ietf.org > > *Cc:* Erik Nordmark; alexandru.petrescu@gmail.com > ; Ray Hunter > *Subject:* security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > Hello, > > There was a discussion during my presentation about security > considerations regarding the use of my algorithm compared with those > of the use of CGA. A big mistake that is made when considering CGA > security is that the sec value plays an important role and that an > attacker will need to do brute force attacks against the IID in order > to generate the same IID as is generated by the use of CGA. In a CGA > analysis paper they talk about a CGA security vaulue of pow (2, sec*16 > * 59) where 2 is the base and sec*16 * 59 is the exponential value and > so they infer that by increasing the sec value used with CGA it will > be safer, but this Is not true. > > I, as an attacker, just to need to find your private key. That’s it. > This is because you have already included the CGA parameters (public > key, modifier, and other required parameters) in the packet that was > sent and I will have no problem in regenerating the CGA. My only > problem will be in generating the signature that can be verified by > use of your public key. This means that you just increased the > complexity and time required for generating and verifying the IID > while with SSAS you can obtain the same security as when using CGA > because its security also depends on the Hash function that is used to > generate the key pair and signature. > > If you send the CGA parameters via a safe channel, like in > establishing TLS etc., then, in that case, CGA would be more secure > than SSAS. But in practice all the data is sent in the same packet > without encryption. If a secured channel would be used in the CGA > process for security reasons (sending CGA parameters), then the cost > of using CGA would be much greater than the cost of using SSAS. > > ** > > *Now the question is, Why not use a more cost efficient algorithm that > afford you with the same security level as when using CGA. * > > I have also included the security group in this email so that they can > also give me any comments that they might have. > > Thank you, > > Hosnieh > > Santosh Chokhani > 18 March 2013 02:36 > > 2048 bit RSA security is overstated. Cracking it requires on the order > of 2^112 operations. You should look at NIST SP 800-57 Part 2, Table 2 > Section 5.6.1. > > From the description you provide on hashing, finding a second hash is > a second pre-image attack and for SHA-1 the security strength is 160 > bits, i.e., you need on the order of 2^160 operations. > > I do not know what hash function you are describing for the function > you mention and how you derived its security strength. > > *From:*saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] *On Behalf > Of *Christian Huitema > *Sent:* Sunday, March 17, 2013 4:14 AM > *To:* Hosnieh Rafiee; ipv6@ietf.org; saag@ietf.org > *Cc:* alexandru.petrescu@gmail.com; 'Roque Gagliano (rogaglia)'; 'Erik > Nordmark'; 'Ray Hunter'; jeanmichel.combes@orange.com > *Subject:* Re: [saag] security consideration of CGA and SSAS - Ii-D > action : draft-rafiee-6man-ssas > > The attack is **relatively** easier. It is not “easy.” It is much > harder to crack RSA than to find a matching hash. Cracking a 2048 bits > RSA key probably requires on the order of 2^1024 trials, and that will > take you something like “forever.” Cracking the hash requires only > something on the order of 2^91 trials with SEC=2. That’s obviously > much less, but that’s still a very large number. The exhausting search > will take you many years, i.e. much more than the valid lifetime of > the address. > > *From:* Hosnieh Rafiee [mailto:ietf@rozanak.com] > *Sent:* Saturday, March 16, 2013 1:45 PM > *To:* Christian Huitema; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; 'Michael > Richardson'; jeanmichel.combes@orange.com > ; 'Roque Gagliano (rogaglia)' > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > >The “SEC” part of CGA is meant to protect against a different attack, > one in which the attacker has not cracked the private key. Instead, > the attacker uses a public/private key pair of his own >choosing, and > arrange for the hash of that key to match the CGA address of the > target. This “only” requires O(2**(59+SEC*16)) operations, which even > with large values of SEC is still far less than >what is required to > crack RSA or ECC. > > So according to what I understand from what you wrote, the sec value > makes the for an easier attack against CGA as the attacker only needs > to find the same value generated by his own modifier and other > parameters and matches this to the IID of the node. Now the question > again is, if this gives an attacker a leg up in doing his brute force > attacks why do we need to add those steps to CGA. This was why I used > the direct public key as a part of IP address. > > Thanks again Christian. > > Hosnieh > > *From:*Christian Huitema [mailto:huitema@microsoft.com] > *Sent:* Saturday, March 16, 2013 7:30 PM > *To:* Hosnieh Rafiee; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; Michael > Richardson; jeanmichel.combes@orange.com > ; Roque Gagliano (rogaglia) > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > As you say, the attack that you mention depends on the strength of RSA > or ECC. In fact, pretty much all of public key cryptography depends on > that strength. It is generally assumed that cracking a long enough RSA > or ECC key is nearly impossible. > > The “SEC” part of CGA is meant to protect against a different attack, > one in which the attacker has not cracked the private key. Instead, > the attacker uses a public/private key pair of his own choosing, and > arrange for the hash of that key to match the CGA address of the > target. This “only” requires O(2**(59+SEC*16)) operations, which even > with large values of SEC is still far less than what is required to > crack RSA or ECC. > > *From:* Hosnieh Rafiee [mailto:ietf@rozanak.com] > *Sent:* Saturday, March 16, 2013 10:59 AM > *To:* Christian Huitema; ipv6@ietf.org ; > saag@ietf.org > *Cc:* 'Erik Nordmark'; alexandru.petrescu@gmail.com > ; 'Ray Hunter'; Michael > Richardson; jeanmichel.combes@orange.com > ; Roque Gagliano (rogaglia) > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > Hi Christian, > > > But can y toou explain why you believe that retrieving the private > key from the public key and a clear text/encrypted text pair is easier > than breaking a hash? > > Here we do not use any encryption and decryption and we just sign the > message using private key and verify the message using public key. > > >Did you somehow crack RSA? > > I do not say that it is easier to find the private key from the public > key. Because for both SSAS and CGA, public/private keys are used. I do > say that the SHAx steps used for CGA generation do not increase the > complexity when used against brute force attacks. This is because an > attacker only needs the private key and does not need to find the > modifier that was used in the generation of the node’s IID nor is > there a need for checking the condition of sec by 16 bits which should > be equal to zero. In SSAS I just use the public/private keys and the > signature and nothing is encrypted/decrypted. In CGA some extra SHAx > steps are used in the generation of their IID along with the > signature. I say that these steps are not needed as long as you > include and send all parameters, used in the SHAx process, in the > packet for verification purposes. Some people feel that CGA is secure > enough when those steps are used. Now what I want to point out here is > that the CGA security level is *only* dependent on the algorithm used > for key pair and signature generation and that those extra steps do > nothing enhance the security side of things. The algorithms used can > be RSA or ECC or whatever, and as such the situation will be the same > as it is for SSAS. I just removed the complexity from the use of CGA > in order to enable a more practical and faster generation and > verification process. > > So the question isn’t how to break the encrypted text but how to break > the signature. In other word, to find the same public key as used by > the generator node or how to break the RSA or ECC. Based on my > knowledge of hash algorithms, as I mentioned in my prior sentence, > this will depend on the strength of the RSA or whatever other > algorithm is used to generate these keys and sign the message. If you > or anyone else thinks otherwise, please contribute to this discussion > and share your opinions. I am just comparing the security aspects of > SSAS, the time efficient algorithm, to those of CGA. > > Thank you, > > Hosnieh > > *From:*Christian Huitema [mailto:huitema@microsoft.com] > *Sent:* Saturday, March 16, 2013 5:37 PM > *To:* Hosnieh Rafiee; ipv6@ietf.org ; > saag@ietf.org > *Cc:* Erik Nordmark; alexandru.petrescu@gmail.com > ; Ray Hunter > *Subject:* RE: security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > It is very clear that if the attacker finds the private key, the size > of the hash does not matter. But can you explain why you believe that > retrieving the private key from the public key and a clear > text/encrypted text pair is easier than breaking a hash? Did you > somehow crack RSA? > > *From:* ipv6-bounces@ietf.org > [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Hosnieh Rafiee > *Sent:* Saturday, March 16, 2013 6:27 AM > *To:* ipv6@ietf.org ; saag@ietf.org > > *Cc:* Erik Nordmark; alexandru.petrescu@gmail.com > ; Ray Hunter > *Subject:* security consideration of CGA and SSAS - Ii-D action : > draft-rafiee-6man-ssas > > Hello, > > There was a discussion during my presentation about security > considerations regarding the use of my algorithm compared with those > of the use of CGA. A big mistake that is made when considering CGA > security is that the sec value plays an important role and that an > attacker will need to do brute force attacks against the IID in order > to generate the same IID as is generated by the use of CGA. In a CGA > analysis paper they talk about a CGA security vaulue of pow (2, sec*16 > * 59) where 2 is the base and sec*16 * 59 is the exponential value and > so they infer that by increasing the sec value used with CGA it will > be safer, but this Is not true. > > I, as an attacker, just to need to find your private key. That’s it. > This is because you have already included the CGA parameters (public > key, modifier, and other required parameters) in the packet that was > sent and I will have no problem in regenerating the CGA. My only > problem will be in generating the signature that can be verified by > use of your public key. This means that you just increased the > complexity and time required for generating and verifying the IID > while with SSAS you can obtain the same security as when using CGA > because its security also depends on the Hash function that is used to > generate the key pair and signature. > > If you send the CGA parameters via a safe channel, like in > establishing TLS etc., then, in that case, CGA would be more secure > than SSAS. But in practice all the data is sent in the same packet > without encryption. If a secured channel would be used in the CGA > process for security reasons (sending CGA parameters), then the cost > of using CGA would be much greater than the cost of using SSAS. > > ** > > *Now the question is, Why not use a more cost efficient algorithm that > afford you with the same security level as when using CGA. * > > I have also included the security group in this email so that they can > also give me any comments that they might have. > > Thank you, > > Hosnieh > > ------------------------------------------------------------------------ From mcr@sandelman.ca Fri Mar 22 05:56:45 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2215E21F875C; Fri, 22 Mar 2013 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdCGK4vbRHvq; Fri, 22 Mar 2013 05:56:44 -0700 (PDT) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 6624A21F8511; Fri, 22 Mar 2013 05:56:44 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 088582016D; Fri, 22 Mar 2013 09:05:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 54802639D7; Fri, 22 Mar 2013 08:56:34 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4502F63827; Fri, 22 Mar 2013 08:56:34 -0400 (EDT) From: Michael Richardson To: "Hosnieh Rafiee" , ipv6@ietf.org, saag@ietf.org In-Reply-To: References: <004101ce224a$0203f0a0$060bd1e0$@rozanak.com> <000901ce2270$08250b10$186f2130$@rozanak.com> <000901ce2287$18d71040$4a8530c0$@rozanak.com> <000001ce267b$3c9391a0$b5bab4e0$@rozanak.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: 'Ray Hunter' , Erik Nordmark , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:56:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Jari" =3D=3D Jari Arkko writes: >> What is it that you don't understand. I will be happy to explain >> it to you. Jari> Thanks. I read the details, but I'm missing the big Jari> picture. I.e., some effort is required from the owner to Jari> create an address. By repeating that effort (2^59)/2 times, Jari> someone else is likely to hit the same key with a key pair Jari> that he or she controls, and an attack can be launched. What Jari> changes from RFC 3972 to your draft in this high-level Jari> analysis? To repeat your analysis, in part so that *I* understand as well: a) CGA too expensive (generating new RSA) to calculate for nodes that want mobility and/or privacy. yet: b) finding a hash collision takes, (2^59)/2 < effort to break RSA behind CGA. So the expensive of the CGA exceeds the (cryptographic) benefit. (a) is a concern for nodes that are moving, not for web servers. (b) makes CGA possibly uninteresting even web servers. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUUxU7IqHRg3pndX9AQKfegQA3ioauxz3nDZzWCtXghiaN9D0FUSi68EF VgbpitjPMHSlsVARTrsSQtHvPd+C/myx0nITItyFv9kNY9xksLoDYe7vc9BR1PDa NB5fBmcfmNtXniRPsWjURlyO6sJ1BC8NBq19AAoq5+d/PZloLdOv3az3mI0kAbBx BX++OuM4l9A= =cnl+ -----END PGP SIGNATURE----- --=-=-=-- From huitema@microsoft.com Fri Mar 22 07:47:52 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC79D21F8A18; Fri, 22 Mar 2013 07:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7R4TUgyQiXMc; Fri, 22 Mar 2013 07:47:52 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF3E21F863C; Fri, 22 Mar 2013 07:47:51 -0700 (PDT) Received: from BL2FFO11FD025.protection.gbl (10.173.161.202) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 22 Mar 2013 14:47:50 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 22 Mar 2013 14:47:49 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 22 Mar 2013 14:47:45 +0000 From: Christian Huitema To: "zhou.sujing@zte.com.cn" , Jari Arkko Thread-Topic: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas Thread-Index: AQHOJqOQV/nGtbzDKUag/Wns4Zx2opixyRZg Date: Fri, 22 Mar 2013 14:47:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(73894001)(4396001)(69226001)(54356001)(47976001)(76482001)(16406001)(66066001)(54316002)(46102001)(53806001)(80022001)(59766001)(56776001)(77982001)(51856001)(55846006)(23676001)(31966008)(44976002)(65816001)(49866001)(33656001)(47446002)(79102001)(74662001)(20776003)(74502001)(63696002)(50466001)(47736001)(47776003)(56816002)(50986001)(621065001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB013; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07935ACF08 X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: "ipv6@ietf.org" , Erik Nordmark , 'Ray Hunter' , 'Jari Arkko' , 'Jeffrey Hutzelman' , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:47:52 -0000 PiBGb3IgdGhlIHNjaGVtZSBpbiB0aGlzIGRyYWZ077yMIA0KPsKgIHRoZSBwcm9iYWJpbGl0eSBv ZiBhIGEgc2Vjb25kIHB1YmxpYyBrZXkgaXM6IDEtKDEtcCleKDJeezEwMjQtNDh9KSwgd2hlcmUg cCBpcyB0aGUgcHJvYmFiaWxpdHkgb2YgYSByYW5kb20gbnVtYmVyIGJlaW5nIGEgUlNBIHB1Ymxp YyBrZXkuIA0KDQpJIHdvdWxkIG5vdCBjb25zdHJ1Y3QgdGhlIGF0dGFjayBieSB0cnlpbmcgcmFu ZG9tIG51bWJlcnMgYW5kIGNoZWNraW5nIHRoZW0gZm9yIHdoZXRoZXIgdGhleSBhcmUgYSBwdWJs aWMga2V5LiBJIHdvdWxkIHN0YXJ0IHdpdGggYSByZXBvc2l0b3J5IG9mIHByaW1lIG51bWJlcnMs IGFuZCB0aGVuIGRvIHNvbWV0aGluZyBsaWtlOg0KDQpGb3IgZWFjaCB0cmlhbA0KCVBpY2sgdHdv IHByaW1lIG51bWJlcnMgZnJvbSB0aGUgY2F0YWxvZw0KCU11bHRpcGx5IHRoZSB0d28gbnVtYmVy cyB0byBnZXQgYSBjYW5kaWRhdGUgUlNBIGtleQ0KCUNoZWNrIHdoZXRoZXIgdGhlIHJlc3VsdGlu ZyBwYXR0ZXJuIG1hdGNoZXMgdGhlIDQ4IGJpdHMgaW4gdGhlIElJRA0KDQpJIHdpbGwgbmVlZCBh biBhdmVyYWdlIG9mICgyXjQ4KS8yIHN1Y2ggdHJpYWxzLCB3aGljaCBtZWFucyB0aGUgY2F0YWxv ZyBzaG91bGQgaGF2ZSBhIHNpemUgMl4yNCBvciBtb3JlLiBHcmFudGVkLCBlc3RhYmxpc2hpbmcg dGhhdCBjYXRhbG9nIHdpbGwgdGFrZSBzb21lIHRpbWUsIGJ1dCBpdCBjYW4gYmUgZG9uZSBvbmNl LCBpbiBhZHZhbmNlLCBiZWZvcmUgdGhlIElQdjYgYWRkcmVzcyBpcyBldmVyIHNlZW4uIFRoZSBz YW1lIGNhdGFsb2cgY2FuIGJlIHVzZWQgZm9yIGFueSBJUHY2IGFkZHJlc3MuDQoNCi0tIENocmlz dGlhbiBIdWl0ZW1hDQoNCg0K From jari.arkko@piuha.net Fri Mar 22 07:52:25 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62EF321F867A; Fri, 22 Mar 2013 07:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwV43oZLy8Ed; Fri, 22 Mar 2013 07:52:25 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id C3CFC21F8640; Fri, 22 Mar 2013 07:52:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A13152CC5B; Fri, 22 Mar 2013 16:52:23 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haWbkjOCc7Sx; Fri, 22 Mar 2013 16:52:23 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 2A8732CC55; Fri, 22 Mar 2013 16:52:23 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jari Arkko In-Reply-To: Date: Fri, 22 Mar 2013 16:52:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <30540E60-83B3-47B8-9FEB-324887E75354@piuha.net> References: To: Christian Huitema X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Fri, 22 Mar 2013 08:01:48 -0700 Cc: "ipv6@ietf.org" , Erik Nordmark , "zhou.sujing@zte.com.cn" , 'Ray Hunter' , Jari Arkko , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:52:25 -0000 Christian, >=20 > I would not construct the attack by trying random numbers and checking = them for whether they are a public key. I would start with a repository = of prime numbers, and then do something like: >=20 I agree with this as well. Jari From stephen.farrell@cs.tcd.ie Fri Mar 22 08:30:18 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D1621F8E77; Fri, 22 Mar 2013 08:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNonZ0evM2kz; Fri, 22 Mar 2013 08:30:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 87CE421F8E74; Fri, 22 Mar 2013 08:30:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92896BE78; Fri, 22 Mar 2013 15:29:55 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpFPVXuwVeTI; Fri, 22 Mar 2013 15:29:54 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.45.56.239]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7B032BE7E; Fri, 22 Mar 2013 15:29:51 +0000 (GMT) Message-ID: <514C78EF.3030805@cs.tcd.ie> Date: Fri, 22 Mar 2013 15:29:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Christian Huitema References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipv6@ietf.org" , Erik Nordmark , "zhou.sujing@zte.com.cn" , 'Ray Hunter' , Jari Arkko , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 15:30:18 -0000 On 03/22/2013 02:47 PM, Christian Huitema wrote: > Pick two prime numbers from the catalog > Multiply the two numbers to get a candidate RSA key > Check whether the resulting pattern matches the 48 bits in the IID I think you can be quicker than that. Generating primes is easy and starts from a random number. Picking two random numbers so their product matches a bit pattern is easy. So long as the bits you want from the RSA modulus aren't the least significant bits then you'll win the game easily given the actual distribution of primes. I've only briefly scanned the draft but it does seem to be vulnerable in this way. So I basically agree this approach seems fairly trivially broken and that that's been sufficiently demonstrated on this list that further discussion really ought wait for an updated I-D. S. From ietf@rozanak.com Fri Mar 22 10:24:04 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A1921F8F81; Fri, 22 Mar 2013 10:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGzcE+NGjiDo; Fri, 22 Mar 2013 10:24:03 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0B521F8F07; Fri, 22 Mar 2013 10:24:03 -0700 (PDT) Received: from kopoli (g231250072.adsl.alicedsl.de [92.231.250.72]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LkfVM-1Ur3Sq3eKa-00aP8d; Fri, 22 Mar 2013 13:24:01 -0400 From: "Hosnieh Rafiee" To: "'Stephen Farrell'" , "'Christian Huitema'" References: <514C78EF.3030805@cs.tcd.ie> In-Reply-To: <514C78EF.3030805@cs.tcd.ie> Date: Fri, 22 Mar 2013 18:23:42 +0100 Message-ID: <000101ce2722$0932ab50$1b9801f0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIy0FXHouEwZZs4cTzNOY9NXVAj0QFTIEenAT6ISZ0B0W113pfFiO2Q Content-Language: en-us X-Provags-ID: V02:K0:kkUKGQotkXT8hoFZtrRQ4M+NZ3D58XDVPxUfEPYiO2q 1xvLik9Ips6pwXkdo29w0fKvMZJ3HFPhMUMK3jmRv0ve358Pid 5gdagiI/OmWoTtcQe8htmj9Y0LUzKsEZ8UKOMzVfLHx6YdhDHD Uc0QiBNIvIzsH8XxSxXSWSZZGoHMgJ4RuWdiMroZ9adetpvccs rl0T2zKX+xCTB4TIq2nZN6IqQBTOgh3Lgbt7Eg/+VD8xlYS/E2 bc6bktTVqvqT4QanrOh9Xf+zHI/qj4ZVF3JFgtr58zqoM0Hxty qoVPNHS3THEBpSwZIuFJTlrpQgZPMYUlV1x7vF5IUA1pOIJS3C KU65JTk3TpDdg0JRU3f0= Cc: ipv6@ietf.org, 'Erik Nordmark' , zhou.sujing@zte.com.cn, 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 17:24:04 -0000 I want to table this discussion until I have the opportunity to code and implement software that will prove what it is that I am trying justify. I have just arrived home from the USA and Sunday I leave for another weeks' conference. Once I return from that conference I will have the opportunity to prove my case. I want to thank everyone for their contributions on this topic and I hope that you will bear with me and we can resume after I know something definite. Thanks again, Hosnieh From stephen.farrell@cs.tcd.ie Fri Mar 22 11:23:45 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6125421F8F4A for ; Fri, 22 Mar 2013 11:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvT-9v-tzul8 for ; Fri, 22 Mar 2013 11:23:44 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C540C21F8F35 for ; Fri, 22 Mar 2013 11:23:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0BA78BE6F for ; Fri, 22 Mar 2013 18:23:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xG+pfHNfWG6x for ; Fri, 22 Mar 2013 18:23:18 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.45.56.239]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65153BE35 for ; Fri, 22 Mar 2013 18:23:18 +0000 (GMT) Message-ID: <514CA196.9070705@cs.tcd.ie> Date: Fri, 22 Mar 2013 18:23:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] IETF-86 draft saag minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 18:23:45 -0000 Hi All, Thanks to Tero for taking notes. Draft minutes are at [1] Please send any corrections needed, Cheers, Stephen. From ynir@checkpoint.com Fri Mar 22 17:38:04 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3CD21F8F35 for ; Fri, 22 Mar 2013 17:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awIH-AIDs9IP for ; Fri, 22 Mar 2013 17:38:03 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D88D21F8BBB for ; Fri, 22 Mar 2013 17:38:02 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r2N0c183005906 for ; Sat, 23 Mar 2013 02:38:01 +0200 X-CheckPoint: {514CF811-0-1B221DC2-2FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sat, 23 Mar 2013 02:38:00 +0200 From: Yoav Nir To: "saag@ietf.org" Thread-Topic: [saag] IETF-86 draft saag minutes Thread-Index: AQHOJypp8KIXB+l4aUekYQuEvY70spiyTXOA Date: Sat, 23 Mar 2013 00:38:01 +0000 Message-ID: References: <514CA196.9070705@cs.tcd.ie> In-Reply-To: <514CA196.9070705@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.41] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-ID: <798B7E7F68D1754A802D0DFB71B9BD72@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [saag] IETF-86 draft saag minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:38:04 -0000 [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-saag On Mar 22, 2013, at 2:23 PM, Stephen Farrell wr= ote: >=20 > Hi All, >=20 > Thanks to Tero for taking notes. Draft minutes are at [1] > Please send any corrections needed, >=20 > Cheers, > Stephen. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From stephen.farrell@cs.tcd.ie Fri Mar 22 17:59:36 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D38621F8FF7 for ; Fri, 22 Mar 2013 17:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smKmtZkpVHmE for ; Fri, 22 Mar 2013 17:59:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 24F2D21F8FE8 for ; Fri, 22 Mar 2013 17:59:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EACABE78; Sat, 23 Mar 2013 00:59:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO-6l+XKn1P5; Sat, 23 Mar 2013 00:59:11 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.44.74.57]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5F7CBE77; Sat, 23 Mar 2013 00:59:11 +0000 (GMT) Message-ID: <514CFE5F.1000008@cs.tcd.ie> Date: Sat, 23 Mar 2013 00:59:11 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Yoav Nir References: <514CA196.9070705@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "saag@ietf.org" Subject: Re: [saag] IETF-86 draft saag minutes X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 00:59:36 -0000 Oops. Thanks. S On 03/23/2013 12:38 AM, Yoav Nir wrote: > [1] http://www.ietf.org/proceedings/86/minutes/minutes-86-saag > > On Mar 22, 2013, at 2:23 PM, Stephen Farrell wrote: > >> >> Hi All, >> >> Thanks to Tero for taking notes. Draft minutes are at [1] >> Please send any corrections needed, >> >> Cheers, >> Stephen. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From Francis.Dupont@fdupont.fr Sat Mar 23 04:44:48 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B8621F8A3F; Sat, 23 Mar 2013 04:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkULyXJ86V6o; Sat, 23 Mar 2013 04:44:48 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4DF21F8A3D; Sat, 23 Mar 2013 04:44:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2NBiMrE017981; Sat, 23 Mar 2013 12:44:22 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303231144.r2NBiMrE017981@givry.fdupont.fr> From: Francis Dupont To: "Hosnieh Rafiee" In-reply-to: Your message of Fri, 22 Mar 2013 13:45:44 +0100. <000601ce26fb$339606c0$9ac21440$@rozanak.com> Date: Sat, 23 Mar 2013 12:44:22 +0100 Sender: Francis.Dupont@fdupont.fr Cc: ipv6@ietf.org, 'Erik Nordmark' , 'Ray Hunter' , 'Jari Arkko' , saag@ietf.org, 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 11:44:49 -0000 In your previous mail you wrote: > => I strongly disagree: the use of those SHAx steps is the way to extend the > search space and until SHAx pre-images are broken for the worst case (i.e., > no attack better than brute force). > > Be patient please. It takes time to prepare a response because I will need > to work on code to break RSA and also SHAx (CGA) and currently I have no > opportunity to work on this. => I'll be very patient about the code to break CGAs (:-). > => this seems to be replay attacks. RFC 3972 (CGAs) doesn't protect against > replay but provides message (aka connectionless) integrity so any use of > CGAs can add an anti-replay device (RFC 3971 (SEND) uses nonces and > timestamps for anti-replay). BTW CGAs and SSASs are the same for this point. > > Nonce and timestamp both cannot be much helpful for relay attacks. I > mentioned a fast replay attack. You need to consider the clock skew for > timestamp (two seconds or so). The other nodes do not know the nonce is for > an attacker or for your node. => the nonce doesn't prove the origin but the signature does. > I, as an attacker, can easily copy and paste the whole packet > content in my message with my own link layer address and send it > back to you. => I have no problem with this way to improve the service. BTW the link-layer address ND option (vs the one in the Ethernet header) is protected by the signature so you can't change it. And I still can't see a difference between SSAS and CGA about this point: in both cases signatures covered the same fields. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 23 05:26:49 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279F021F8AF0 for ; Sat, 23 Mar 2013 05:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdAXcdNV7c5E for ; Sat, 23 Mar 2013 05:26:48 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 7196D21F8AE8 for ; Sat, 23 Mar 2013 05:26:48 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id r2NCQPGG020616; Sat, 23 Mar 2013 13:26:25 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201303231226.r2NCQPGG020616@givry.fdupont.fr> From: Francis Dupont To: Christian Huitema In-reply-to: Your message of Fri, 22 Mar 2013 14:47:44 GMT. Date: Sat, 23 Mar 2013 13:26:25 +0100 Sender: Francis.Dupont@fdupont.fr Cc: Erik Nordmark , "zhou.sujing@zte.com.cn" , 'Ray Hunter' , Jari Arkko , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - Ii-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 12:26:49 -0000 I have a simpler solution (assuming to-be-matched bits are high order, if they are not 2 must be replaced by 2**k) - pick one prime number - divide the modulus to get the second prime number range - for all odd numbers in the range (fast) check it is prime Note the standard RSA generation is: - pick a bunch of random bits of the wanted size - fast checks it is prime, if it is not retry, if it is got a prime Apply this twice to get the 2 primes, compute the modulus, private exponent and CRT coefficients with a (given too) public exponent. So I argue it is not significantly more expensive to break a SSAS (*) than to generate a new RSA key pair. Regards Francis.Dupont@fdupont.fr PS (*): the solved problem is to find a valid RSA key pair which shares N contiguous bits of the modulus, N << size(modulus) (verified for any SSAS like as 64 << 1024. PPS: Christian's argument applies for ECDSA (I expect ECDSA will replace by RSA in the SSAS proposal if it is not simply withdrawn) so if nobody has a quicker way the ECDSA problem complexity is 2**(N-1) (mean, max is 2**N). From zhou.sujing@zte.com.cn Sun Mar 24 21:06:33 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576ED21F8DF1; Sun, 24 Mar 2013 21:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.293 X-Spam-Level: X-Spam-Status: No, score=-98.293 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdVXudRxM-hY; Sun, 24 Mar 2013 21:06:32 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 75B2721F8E59; Sun, 24 Mar 2013 21:06:31 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2100A1287BB3; Mon, 25 Mar 2013 12:06:06 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id B43F071816D; Mon, 25 Mar 2013 12:06:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r2P464ZB001451; Mon, 25 Mar 2013 12:06:04 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: MIME-Version: 1.0 To: Christian Huitema X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: "Sujing Zhou" Date: Mon, 25 Mar 2013 12:06:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-03-25 12:05:52, Serialize complete at 2013-03-25 12:05:52 Content-Type: multipart/alternative; boundary="=_alternative 0016941948257B39_=" X-MAIL: mse02.zte.com.cn r2P464ZB001451 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , 'Ray Hunter' , 'Jari Arkko' , 'Jeffrey Hutzelman' , "saag@ietf.org" Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 04:06:33 -0000 This is a multipart message in MIME format. --=_alternative 0016941948257B39_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Q2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT4g0LTT2iAyMDEzLTAzLTIy IDA3OjU2OjIwOg0KDQo+IA0KPiBIb3NuaWVoLA0KPiANCj4gWW91IHNob3VsZCBwcm9iYWJseSBz cGxpdCB5b3VyIHByb3Bvc2FsIGluIHR3byBwYXJ0czogdGhlIHByb3Bvc2FsIA0KPiB0byByZXBs YWNlIENHQSBieSBqdXN0IGNoZWNraW5nIGFuIGV4dHJhY3Qgb2YgdGhlIGFkZHJlc3M7IGFuZCAN Cj4gcG90ZW50aWFsIGltcHJvdmVtZW50cyB0byBTRU5EIHRoYXQgYXJlIGluZGVwZW5kZW50IG9m IHdoZXRoZXIgd2UgDQo+IHVzZSBDR0Egb3IgeW91ciBkaXJlY3QgY29tcGFyaXNvbiBhbHRlcm5h dGl2ZS4gDQo+IA0KPiBZb3VyIHJlcGxhY2VtZW50IG9mIENHQSB3b3JrcyBieSBjb3B5aW5nIHNv bWUgYml0cyBvZiB0aGUgcHVibGljIGtleQ0KPiBpbiB0aGUgSUlEIGZpZWxkLCBpbnN0ZWFkIG9m IHVzaW5nIGJpdHMgZnJvbSBhIGhhc2ggZnVuY3Rpb24uIEkgDQo+IHRoaW5rIHRoaXMgaXMgYSBy ZWFsbHkgYmFkIGlkZWEsIHNpbmNlIHRoZSBudW1iZXIgb2YgYml0cyB0aGF0IHlvdSANCj4gY2Fu IGNvcHkgaXMgbGltaXRlZC4gWW91ciBpbml0aWFsIGRlc2lnbiBjb3BpZWQganVzdCA0OCBiaXRz OyB5b3UgDQo+IGNvdWxkIGNoYW5nZSB0aGF0IHRvIDU2IGJpdHMgb3IgbWF5YmUgNjIgYml0cyBp biBhbiBpbXByb3ZlZCBkZXNpZ24uDQo+IENyYWNraW5nIHRoZSA0OCBiaXQgdmVyc2lvbiBpcyB0 cml2aWFsLiBDcmFja2luZyB0aGUgNjIgYml0IHZlcnNpb24gDQo+IHdpbGwgdGFrZSBsb25nZXIs IGJ1dCB3aXRoIE1vb3JlJ3MgbGF3IHRoZXJlIHdpbGwgY29tZSBhIHBvaW50IGluIA0KPiB0aGUg ZnV0dXJlIHdoZXJlIHRoaXMgdG9vIHdpbGwgYmUgZWFzeSB0byBjcmFjay4gSW4gY29udHJhc3Qs IENHQSANCj4gaW1wbGVtZW50YXRpb25zIGNhbiBzaW1wbHkgaW4gdGhlIGZ1dHVyZSBpbmNyZW1l bnQgdGhlIFNFQyB2YWx1ZSBmb3INCj4gYWRkZWQgcm9idXN0bmVzcy4NCldoYXQgaXMgdGhlIHBv aW50aW5nIG9mIGFkZGluZyBzZWMgc2luY2UgdGhlIHJhdGlvIG9mIGVmZm9yIHJlcXVpcmVkIGJ5 IA0KYXR0YWNrZXIgYW5kIHVzZXIgaXMgYWx3YXlzIDJeNTksIGFzIEphcmkgYXJndWVkLg0KDQoN Cj4gDQo+IFlvdXIgZHJhZnQgaXMgbWFraW5nIG90aGVyIGNvbnRyaWJ1dGlvbnMsIHN1Y2ggYXMg YWRkZWQgdmVyaWZpY2F0aW9uDQo+IHN0ZXBzLCBvciBjYWNoaW5nIG8gcmVzdWx0cyB0byBwcmV2 ZW50IERPUyBhdHRhY2tzLiBUaGVzZSANCj4gY29udHJpYnV0aW9ucyBjb3VsZCBiZSB1c2VkIHRv IGltcHJvdmUgU0VORC4gSXQgd291bGQgYmUgYmV0dGVyIHRvIA0KPiBzZXBhcmF0ZSB0aGVtIGZy b20gdGhlIGRlYmF0ZSBhYm91dCBoYXNoIGZ1bmN0aW9ucy4NCj4gDQo+IC0tIENocmlzdGlhbg0K PiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSG9z bmllaCBSYWZpZWUgW21haWx0bzppZXRmQHJvemFuYWsuY29tXSANCj4gU2VudDogVGh1cnNkYXks IE1hcmNoIDIxLCAyMDEzIDQ6MDggUE0NCj4gVG86ICdKYXJpIEFya2tvJw0KPiBDYzogJ1NhbnRv c2ggQ2hva2hhbmknOyBpcHY2QGlldGYub3JnOyBzYWFnQGlldGYub3JnOyAnUmF5IEh1bnRlcic7 IA0KPiBDaHJpc3RpYW4gSHVpdGVtYTsgJ0VyaWsgTm9yZG1hcmsnOyB6aG91LnN1amluZ0B6dGUu Y29tLmNuOyANCidKZWZmcmV5SHV0emVsbWFuJw0KPiBTdWJqZWN0OiBSRTogW3NhYWddIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gb2YgQ0dBIGFuZCBTU0FTIC0gSS1EIA0KPiBhY3Rpb24gOiBkcmFm dC1yYWZpZWUtNm1hbi1zc2FzDQo+IA0KPiBKYXJpLA0KPiANCj4gPiBXaGF0IGNoYW5nZXMgZnJv bSBSRkMgMzk3MiB0byB5b3VyIGRyYWZ0IGluIHRoaXMgaGlnaC1sZXZlbCBhbmFseXNpcz8NCj4g DQo+IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gbXkgZHJhZnQgYW5kIHRoYXQgb2YgUkZDIDM5NzIg aXMgdGhhdCBJIG1ha2UgDQo+IHVzZSBvZiB0aGUgcHVibGljIGtleSBpbiB0aGUgSVAgYWRkcmVz cyBkaXJlY3RseS4gRG9pbmcgaXQgdGhlIHdheSBJDQo+IGhhdmUgZXhwbGFpbmVkIGluIG15IGRy YWZ0IGVsaW1pbmF0ZXMgdGhlIG5lZWQgZm9yIHRoZSB1c2Ugb2YgdGhvc2UgDQo+IFNIQXggc3Rl cHMgIGJlY2F1c2UgSSBiZWxpZXZlIHRoZSB1c2Ugb2YgdGhvc2Ugc3RlcHMgZG9lcyBub3QgbGVu ZCANCj4gaXRzZWxmIHRvIGltcHJvdmVkIHNlY3VyaXR5LiBNeSByZWFzb24gZm9yIHRoaXMgb3Bp bmlvbiBpcyB0aGF0IFJGQyANCj4gMzk3MiBjYW4gb25seSBwcmV2ZW50IERBRCBhdHRhY2tzIGFu ZCBub3QgdGhlIG90aGVyIHR5cGVzIG9mIA0KPiBhdHRhY2tzLiBUaGlzIGF0dGFjayBjYW4gYWxz byBiZSBwcmV2ZW50ZWQgYnkgdXNpbmcgQ0dBIGlmIHdlIGFkZCANCj4gdGhpcyBleHRyYSB2ZXJp ZmljYXRpb24gc3RlcCAodGhhdCBvZiB0aGUgbm9kZSBjaGVja2luZyB0aGUgcHVibGljIA0KPiBr ZXkgb2YgdGhlIHNlbmRlciB0byBoaXMgb3duKSwgb3RoZXJ3aXNlIFJQS0kgd291bGQgYmUgdXNl ZC4gVGhpcyBpcw0KPiB0aGUgc2FtZSBwcm9jZWR1cmUgYXMgb3V0bGluZWQgaW4gbXkgZHJhZnQu IFNvIHRoZSBzZWN1cml0eSBvZiBib3RoIA0KPiBkZXBlbmRzIG9uIHRoZSBzZWN1cml0eSBvZiB0 aGUgcHVibGljLyBwcml2YXRlIGtleXMuIEFmdGVyIGEgDQo+IHN1Y2Nlc3NmdWwgdmVyaWZpY2F0 aW9uICh3aGljaCBjb3VsZCBoYXZlIHJlc3VsdGVkIGZyb20gYSBmYXN0IHJlbGF5DQo+IGF0dGFj aykgdGhlIGF0dGFja2VyJ3MgbGluay1sYXllciBhZGRyZXNzIGlzIGluY2x1ZGVkIGluIGEgY2Fj aGUgYXMgDQo+IGEgbGVnaXRpbWF0ZSBhZGRyZXNzLCBhbmQgaWYgcm91dGluZyBpcyBiYXNlZCBv biB0aGUgbGluay1sYXllciANCj4gYWRkcmVzcywgIHRoZW4gdGhlIG5vZGUgaGFzIG5vIHdheSBv ZiBrbm93aW5nIHRoYXQgaXQgd2FzIGp1c3QgYSANCj4gcmVwbGF5IGF0dGFjay4gT3RoZXJ3aXNl LCB0aGUgdXNlIG9mIFJQS0ksIHdoZXJlIHRoZSBub2RlIHRoYXQgaGFzIA0KPiB0aGlzIElQIGFk ZHJlc3Mvb3IgbGluayBsYXllciBpcyBzcGVjaWZpZWQsIHdvdWxkIGNvbnRhaW4gdGhpcyANCj4g cHVibGljIGtleS4gVGhpcyBpcyB3aHksIGluIHRoaXMgY2FzZSwgdGhlIGtleXMnIHNlY3VyaXR5 IGlzIHZlcnkgDQppbXBvcnRhbnQuDQo+IA0KPiBUaGFua3MsDQo+IEhvc25pZWgNCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphcmkgQXJra28gW21haWx0bzpqYXJp LmFya2tvQHBpdWhhLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDIxLCAyMDEzIDEwOjU2 IFBNDQo+IFRvOiBIb3NuaWVoIFJhZmllZQ0KPiBDYzogJ0phcmkgQXJra28nOyAnU2FudG9zaCBD aG9raGFuaSc7IGlwdjZAaWV0Zi5vcmc7IHNhYWdAaWV0Zi5vcmc7IA0KPiAnUmF5IEh1bnRlcic7 ICdDaHJpc3RpYW4gSHVpdGVtYSc7IEVyaWsgTm9yZG1hcms7IHpob3Uuc3VqaW5nQHp0ZS4NCj4g Y29tLmNuOyAnSmVmZnJleSBIdXR6ZWxtYW4nDQo+IFN1YmplY3Q6IFJlOiBbc2FhZ10gc2VjdXJp dHkgY29uc2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJaS1EIGFjdGlvbiANCjoNCj4gZHJh ZnQtcmFmaWVlLTZtYW4tc3Nhcw0KPiANCj4gDQo+IEhvc25pZWgsDQo+IA0KPiA+IFdoYXQgaXMg aXQgdGhhdCB5b3UgZG9uJ3QgdW5kZXJzdGFuZC4gSSB3aWxsIGJlIGhhcHB5IHRvIGV4cGxhaW4g aXQgdG8NCj4geW91Lg0KPiANCj4gVGhhbmtzLiBJIHJlYWQgdGhlIGRldGFpbHMsIGJ1dCBJJ20g bWlzc2luZyB0aGUgYmlnIHBpY3R1cmUuIEkuZS4sIHNvbWUNCj4gZWZmb3J0IGlzIHJlcXVpcmVk IGZyb20gdGhlIG93bmVyIHRvIGNyZWF0ZSBhbiBhZGRyZXNzLiBCeSByZXBlYXRpbmcgDQp0aGF0 DQo+IGVmZm9ydCAoMl41OSkvMiB0aW1lcywgc29tZW9uZSBlbHNlIGlzIGxpa2VseSB0byBoaXQg dGhlIHNhbWUga2V5IHdpdGggYSANCmtleQ0KPiBwYWlyIHRoYXQgaGUgb3Igc2hlIGNvbnRyb2xz LCBhbmQgYW4gYXR0YWNrIGNhbiBiZSBsYXVuY2hlZC4gV2hhdCANCmNoYW5nZXMNCj4gZnJvbSBS RkMgMzk3MiB0byB5b3VyIGRyYWZ0IGluIHRoaXMgaGlnaC1sZXZlbCBhbmFseXNpcz8NCj4gDQo+ ID4gVGhlcmUgaGFzIGJlZW4gbm8gcmVzb2x1dGlvbiB0byB0aGUgdG9waWMgb2YgdGhlIHRocmVh ZC4gDQo+IA0KPiBPay4gV2VsbCB0aGF0IGNsYXJpZmllcyBhdCBsZWFzdCB0aGUgc3RhdGUgb2Yg dGhlIGRpc2N1c3Npb24uIFRoYW5rcy4NCj4gDQo+IEphcmkNCj4gDQo+IA0KDQo= --=_alternative 0016941948257B39_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBtaWNy b3NvZnQuY29tJmd0OyDQtNPaDQoyMDEzLTAzLTIyIDA3OjU2OjIwOjxicj4NCjxicj4NCiZndDsg PGJyPg0KJmd0OyBIb3NuaWVoLDxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Ugc2hvdWxkIHByb2Jh Ymx5IHNwbGl0IHlvdXIgcHJvcG9zYWwgaW4gdHdvIHBhcnRzOiB0aGUgcHJvcG9zYWwNCjxicj4N CiZndDsgdG8gcmVwbGFjZSBDR0EgYnkganVzdCBjaGVja2luZyBhbiBleHRyYWN0IG9mIHRoZSBh ZGRyZXNzOyBhbmQgPGJyPg0KJmd0OyBwb3RlbnRpYWwgaW1wcm92ZW1lbnRzIHRvIFNFTkQgdGhh dCBhcmUgaW5kZXBlbmRlbnQgb2Ygd2hldGhlciB3ZQ0KPGJyPg0KJmd0OyB1c2UgQ0dBIG9yIHlv dXIgZGlyZWN0IGNvbXBhcmlzb24gYWx0ZXJuYXRpdmUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBZ b3VyIHJlcGxhY2VtZW50IG9mIENHQSB3b3JrcyBieSBjb3B5aW5nIHNvbWUgYml0cyBvZiB0aGUg cHVibGljIGtleTxicj4NCiZndDsgaW4gdGhlIElJRCBmaWVsZCwgaW5zdGVhZCBvZiB1c2luZyBi aXRzIGZyb20gYSBoYXNoIGZ1bmN0aW9uLiBJIDxicj4NCiZndDsgdGhpbmsgdGhpcyBpcyBhIHJl YWxseSBiYWQgaWRlYSwgc2luY2UgdGhlIG51bWJlciBvZiBiaXRzIHRoYXQgeW91DQo8YnI+DQom Z3Q7IGNhbiBjb3B5IGlzIGxpbWl0ZWQuIFlvdXIgaW5pdGlhbCBkZXNpZ24gY29waWVkIGp1c3Qg NDggYml0czsgeW91DQo8YnI+DQomZ3Q7IGNvdWxkIGNoYW5nZSB0aGF0IHRvIDU2IGJpdHMgb3Ig bWF5YmUgNjIgYml0cyBpbiBhbiBpbXByb3ZlZCBkZXNpZ24uPGJyPg0KJmd0OyBDcmFja2luZyB0 aGUgNDggYml0IHZlcnNpb24gaXMgdHJpdmlhbC4gQ3JhY2tpbmcgdGhlIDYyIGJpdCB2ZXJzaW9u DQo8YnI+DQomZ3Q7IHdpbGwgdGFrZSBsb25nZXIsIGJ1dCB3aXRoIE1vb3JlJ3MgbGF3IHRoZXJl IHdpbGwgY29tZSBhIHBvaW50IGluDQo8YnI+DQomZ3Q7IHRoZSBmdXR1cmUgd2hlcmUgdGhpcyB0 b28gd2lsbCBiZSBlYXN5IHRvIGNyYWNrLiBJbiBjb250cmFzdCwgQ0dBDQo8YnI+DQomZ3Q7IGlt cGxlbWVudGF0aW9ucyBjYW4gc2ltcGx5IGluIHRoZSBmdXR1cmUgaW5jcmVtZW50IHRoZSBTRUMg dmFsdWUgZm9yPGJyPg0KJmd0OyBhZGRlZCByb2J1c3RuZXNzLjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+V2hhdCBpcyB0aGUgcG9pbnRpbmcgb2YgYWRkaW5nIHNlYyBzaW5jZSB0 aGUgcmF0aW8NCm9mIGVmZm9yIHJlcXVpcmVkIGJ5ICZuYnNwO2F0dGFja2VyIGFuZCB1c2VyIGlz IGFsd2F5cyAyXjU5LCBhcyBKYXJpIGFyZ3VlZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3VyIGRyYWZ0IGlzIG1ha2luZyBv dGhlciBjb250cmlidXRpb25zLCBzdWNoIGFzIGFkZGVkIHZlcmlmaWNhdGlvbjxicj4NCiZndDsg c3RlcHMsIG9yIGNhY2hpbmcgbyByZXN1bHRzIHRvIHByZXZlbnQgRE9TIGF0dGFja3MuIFRoZXNl IDxicj4NCiZndDsgY29udHJpYnV0aW9ucyBjb3VsZCBiZSB1c2VkIHRvIGltcHJvdmUgU0VORC4g SXQgd291bGQgYmUgYmV0dGVyIHRvDQo8YnI+DQomZ3Q7IHNlcGFyYXRlIHRoZW0gZnJvbSB0aGUg ZGViYXRlIGFib3V0IGhhc2ggZnVuY3Rpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSBDaHJp c3RpYW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IEhvc25pZWggUmFm aWVlIFttYWlsdG86aWV0ZkByb3phbmFrLmNvbV0gPGJyPg0KJmd0OyBTZW50OiBUaHVyc2RheSwg TWFyY2ggMjEsIDIwMTMgNDowOCBQTTxicj4NCiZndDsgVG86ICdKYXJpIEFya2tvJzxicj4NCiZn dDsgQ2M6ICdTYW50b3NoIENob2toYW5pJzsgaXB2NkBpZXRmLm9yZzsgc2FhZ0BpZXRmLm9yZzsg J1JheSBIdW50ZXInOw0KPGJyPg0KJmd0OyBDaHJpc3RpYW4gSHVpdGVtYTsgJ0VyaWsgTm9yZG1h cmsnOyB6aG91LnN1amluZ0B6dGUuY29tLmNuOyAnSmVmZnJleUh1dHplbG1hbic8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJFOiBbc2FhZ10gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNT QVMgLSBJLUQgPGJyPg0KJmd0OyBhY3Rpb24gOiBkcmFmdC1yYWZpZWUtNm1hbi1zc2FzPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEphcmksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hhdCBjaGFu Z2VzIGZyb20gUkZDIDM5NzIgdG8geW91ciBkcmFmdCBpbiB0aGlzIGhpZ2gtbGV2ZWwgYW5hbHlz aXM/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkaWZmZXJlbmNlIGJldHdlZW4gbXkgZHJhZnQg YW5kIHRoYXQgb2YgUkZDIDM5NzIgaXMgdGhhdCBJIG1ha2UNCjxicj4NCiZndDsgdXNlIG9mIHRo ZSBwdWJsaWMga2V5IGluIHRoZSBJUCBhZGRyZXNzIGRpcmVjdGx5LiBEb2luZyBpdCB0aGUgd2F5 DQpJPGJyPg0KJmd0OyBoYXZlIGV4cGxhaW5lZCBpbiBteSBkcmFmdCBlbGltaW5hdGVzIHRoZSBu ZWVkIGZvciB0aGUgdXNlIG9mIHRob3NlDQo8YnI+DQomZ3Q7IFNIQXggc3RlcHMgJm5ic3A7YmVj YXVzZSBJIGJlbGlldmUgdGhlIHVzZSBvZiB0aG9zZSBzdGVwcyBkb2VzIG5vdA0KbGVuZCA8YnI+ DQomZ3Q7IGl0c2VsZiB0byBpbXByb3ZlZCBzZWN1cml0eS4gTXkgcmVhc29uIGZvciB0aGlzIG9w aW5pb24gaXMgdGhhdCBSRkMNCjxicj4NCiZndDsgMzk3MiBjYW4gb25seSBwcmV2ZW50IERBRCBh dHRhY2tzIGFuZCBub3QgdGhlIG90aGVyIHR5cGVzIG9mIDxicj4NCiZndDsgYXR0YWNrcy4gVGhp cyBhdHRhY2sgY2FuIGFsc28gYmUgcHJldmVudGVkIGJ5IHVzaW5nIENHQSBpZiB3ZSBhZGQNCjxi cj4NCiZndDsgdGhpcyBleHRyYSB2ZXJpZmljYXRpb24gc3RlcCAodGhhdCBvZiB0aGUgbm9kZSBj aGVja2luZyB0aGUgcHVibGljDQo8YnI+DQomZ3Q7IGtleSBvZiB0aGUgc2VuZGVyIHRvIGhpcyBv d24pLCBvdGhlcndpc2UgUlBLSSB3b3VsZCBiZSB1c2VkLiBUaGlzDQppczxicj4NCiZndDsgdGhl IHNhbWUgcHJvY2VkdXJlIGFzIG91dGxpbmVkIGluIG15IGRyYWZ0LiBTbyB0aGUgc2VjdXJpdHkg b2YgYm90aA0KPGJyPg0KJmd0OyBkZXBlbmRzIG9uIHRoZSBzZWN1cml0eSBvZiB0aGUgcHVibGlj LyBwcml2YXRlIGtleXMuIEFmdGVyIGEgPGJyPg0KJmd0OyBzdWNjZXNzZnVsIHZlcmlmaWNhdGlv biAod2hpY2ggY291bGQgaGF2ZSByZXN1bHRlZCBmcm9tIGEgZmFzdCByZWxheTxicj4NCiZndDsg YXR0YWNrKSB0aGUgYXR0YWNrZXIncyBsaW5rLWxheWVyIGFkZHJlc3MgaXMgaW5jbHVkZWQgaW4g YSBjYWNoZSBhcw0KPGJyPg0KJmd0OyBhIGxlZ2l0aW1hdGUgYWRkcmVzcywgYW5kIGlmIHJvdXRp bmcgaXMgYmFzZWQgb24gdGhlIGxpbmstbGF5ZXIgPGJyPg0KJmd0OyBhZGRyZXNzLCAmbmJzcDt0 aGVuIHRoZSBub2RlIGhhcyBubyB3YXkgb2Yga25vd2luZyB0aGF0IGl0IHdhcyBqdXN0DQphIDxi cj4NCiZndDsgcmVwbGF5IGF0dGFjay4gT3RoZXJ3aXNlLCB0aGUgdXNlIG9mIFJQS0ksIHdoZXJl IHRoZSBub2RlIHRoYXQgaGFzDQo8YnI+DQomZ3Q7IHRoaXMgSVAgYWRkcmVzcy9vciBsaW5rIGxh eWVyIGlzIHNwZWNpZmllZCwgd291bGQgY29udGFpbiB0aGlzIDxicj4NCiZndDsgcHVibGljIGtl eS4gVGhpcyBpcyB3aHksIGluIHRoaXMgY2FzZSwgdGhlIGtleXMnIHNlY3VyaXR5IGlzIHZlcnkN CmltcG9ydGFudC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgSG9zbmll aDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZn dDsgRnJvbTogSmFyaSBBcmtrbyBbbWFpbHRvOmphcmkuYXJra29AcGl1aGEubmV0XTxicj4NCiZn dDsgU2VudDogVGh1cnNkYXksIE1hcmNoIDIxLCAyMDEzIDEwOjU2IFBNPGJyPg0KJmd0OyBUbzog SG9zbmllaCBSYWZpZWU8YnI+DQomZ3Q7IENjOiAnSmFyaSBBcmtrbyc7ICdTYW50b3NoIENob2to YW5pJzsgaXB2NkBpZXRmLm9yZzsgc2FhZ0BpZXRmLm9yZzsNCjxicj4NCiZndDsgJ1JheSBIdW50 ZXInOyAnQ2hyaXN0aWFuIEh1aXRlbWEnOyBFcmlrIE5vcmRtYXJrOyB6aG91LnN1amluZ0B6dGUu PGJyPg0KJmd0OyBjb20uY247ICdKZWZmcmV5IEh1dHplbG1hbic8YnI+DQomZ3Q7IFN1YmplY3Q6 IFJlOiBbc2FhZ10gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBvZiBDR0EgYW5kIFNTQVMgLSBJaS1E DQphY3Rpb24gOjxicj4NCiZndDsgZHJhZnQtcmFmaWVlLTZtYW4tc3Nhczxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhvc25pZWgsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgV2hh dCBpcyBpdCB0aGF0IHlvdSBkb24ndCB1bmRlcnN0YW5kLiBJIHdpbGwgYmUgaGFwcHkgdG8gZXhw bGFpbg0KaXQgdG88YnI+DQomZ3Q7IHlvdS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLiBJ IHJlYWQgdGhlIGRldGFpbHMsIGJ1dCBJJ20gbWlzc2luZyB0aGUgYmlnIHBpY3R1cmUuIEkuZS4s DQpzb21lPGJyPg0KJmd0OyBlZmZvcnQgaXMgcmVxdWlyZWQgZnJvbSB0aGUgb3duZXIgdG8gY3Jl YXRlIGFuIGFkZHJlc3MuIEJ5IHJlcGVhdGluZw0KdGhhdDxicj4NCiZndDsgZWZmb3J0ICgyXjU5 KS8yIHRpbWVzLCBzb21lb25lIGVsc2UgaXMgbGlrZWx5IHRvIGhpdCB0aGUgc2FtZSBrZXkNCndp dGggYSBrZXk8YnI+DQomZ3Q7IHBhaXIgdGhhdCBoZSBvciBzaGUgY29udHJvbHMsIGFuZCBhbiBh dHRhY2sgY2FuIGJlIGxhdW5jaGVkLiBXaGF0DQpjaGFuZ2VzPGJyPg0KJmd0OyBmcm9tIFJGQyAz OTcyIHRvIHlvdXIgZHJhZnQgaW4gdGhpcyBoaWdoLWxldmVsIGFuYWx5c2lzPzxicj4NCiZndDsg PGJyPg0KJmd0OyAmZ3Q7IFRoZXJlIGhhcyBiZWVuIG5vIHJlc29sdXRpb24gdG8gdGhlIHRvcGlj IG9mIHRoZSB0aHJlYWQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBPay4gV2VsbCB0aGF0IGNsYXJp ZmllcyBhdCBsZWFzdCB0aGUgc3RhdGUgb2YgdGhlIGRpc2N1c3Npb24uIFRoYW5rcy48YnI+DQom Z3Q7IDxicj4NCiZndDsgSmFyaTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90 dD4NCg== --=_alternative 0016941948257B39_=-- From huitema@microsoft.com Sun Mar 24 21:33:48 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A4E21F8DE6; Sun, 24 Mar 2013 21:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRFB5KWee3D8; Sun, 24 Mar 2013 21:33:48 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 00DC821F8DF1; Sun, 24 Mar 2013 21:33:44 -0700 (PDT) Received: from BL2FFO11FD025.protection.gbl (10.173.161.202) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 04:33:43 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 04:33:42 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 04:33:41 +0000 From: Christian Huitema To: Sujing Zhou Thread-Topic: RE: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas Thread-Index: AQHOKQ40Ao9WzYodkUGG5pw7HjV7xZi10Bzg Date: Mon, 25 Mar 2013 04:33:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(77982001)(31966008)(50466001)(47736001)(53806001)(16406001)(54356001)(59766001)(50986001)(47446002)(65816001)(74502001)(56816002)(44976002)(20776003)(56776001)(46102001)(63696002)(33656001)(54316002)(76482001)(49866001)(79102001)(69226001)(47776003)(55846006)(80022001)(51856001)(66066001)(47976001)(4396001)(23756002)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , 'Ray Hunter' , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 04:33:48 -0000 > What is the pointing of adding sec since the ratio of effor required by = =A0attacker and user is always 2^59, as Jari argued.=20 2^59 is a rather large number. Everything else being equal, another 1 secon= d of computation at the user translates into another 18 billion years at th= e attacker. -- Christian Huitema From zhou.sujing@zte.com.cn Sun Mar 24 22:55:10 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C029421F8E59; Sun, 24 Mar 2013 22:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.753 X-Spam-Level: X-Spam-Status: No, score=-94.753 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_BASE64_TEXT=2.796, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0ceWUwWaYi5; Sun, 24 Mar 2013 22:55:10 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 06E2E21F8E54; Sun, 24 Mar 2013 22:55:10 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8C57111508; Mon, 25 Mar 2013 13:54:40 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A79D4719405; Mon, 25 Mar 2013 13:54:38 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id r2P5sSJ7026043; Mon, 25 Mar 2013 13:54:28 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: MIME-Version: 1.0 To: Christian Huitema X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: "Sujing Zhou" Date: Mon, 25 Mar 2013 13:54:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-03-25 13:54:17, Serialize complete at 2013-03-25 13:54:17 Content-Type: multipart/alternative; boundary="=_alternative 002082A248257B39_=" X-MAIL: mse02.zte.com.cn r2P5sSJ7026043 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , 'Ray Hunter' , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 05:55:10 -0000 This is a multipart message in MIME format. --=_alternative 002082A248257B39_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Q2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAbWljcm9zb2Z0LmNvbT4g0LTT2iAyMDEzLTAzLTI1 IDEyOjMzOjQwOg0KDQo+ID4gV2hhdCBpcyB0aGUgcG9pbnRpbmcgb2YgYWRkaW5nIHNlYyBzaW5j ZSB0aGUgcmF0aW8gb2YgZWZmb3IgDQo+IHJlcXVpcmVkIGJ5ICBhdHRhY2tlciBhbmQgdXNlciBp cyBhbHdheXMgMl41OSwgYXMgSmFyaSBhcmd1ZWQuIA0KPiANCj4gMl41OSBpcyBhIHJhdGhlciBs YXJnZSBudW1iZXIuIEV2ZXJ5dGhpbmcgZWxzZSBiZWluZyBlcXVhbCwgYW5vdGhlciANCj4gMSBz ZWNvbmQgb2YgY29tcHV0YXRpb24gYXQgdGhlIHVzZXIgdHJhbnNsYXRlcyBpbnRvIGFub3RoZXIg MTggDQo+IGJpbGxpb24geWVhcnMgYXQgdGhlIGF0dGFja2VyLg0KQWdyZWUuIEhvdyBhYm91dCAy XjU2Pw0KTXkgcXVlc3Rpb24gaXMgc2luY2UgQ0dBIGhhcyAyXjU5IGFzIGEgc2VjdXJpdHkgZ3Vh cmFudGVlLCB3aHkgYm90aGVyIA0KaW5jcmVhc2Ugc2VjPw0KDQo+IA0KPiAtLSBDaHJpc3RpYW4g SHVpdGVtYQ0KPiANCj4gDQo+IA0KDQo= --=_alternative 002082A248257B39_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBtaWNy b3NvZnQuY29tJmd0OyDlhpnkuo4NCjIwMTMtMDMtMjUgMTI6MzM6NDA6PGJyPg0KPGJyPg0KJmd0 OyAmZ3Q7IFdoYXQgaXMgdGhlIHBvaW50aW5nIG9mIGFkZGluZyBzZWMgc2luY2UgdGhlIHJhdGlv IG9mIGVmZm9yIDxicj4NCiZndDsgcmVxdWlyZWQgYnkgJm5ic3A7YXR0YWNrZXIgYW5kIHVzZXIg aXMgYWx3YXlzIDJeNTksIGFzIEphcmkgYXJndWVkLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDJe NTkgaXMgYSByYXRoZXIgbGFyZ2UgbnVtYmVyLiBFdmVyeXRoaW5nIGVsc2UgYmVpbmcgZXF1YWws IGFub3RoZXINCjxicj4NCiZndDsgMSBzZWNvbmQgb2YgY29tcHV0YXRpb24gYXQgdGhlIHVzZXIg dHJhbnNsYXRlcyBpbnRvIGFub3RoZXIgMTggPGJyPg0KJmd0OyBiaWxsaW9uIHllYXJzIGF0IHRo ZSBhdHRhY2tlci48YnI+DQpBZ3JlZS4gSG93IGFib3V0IDJeNTY/PC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5NeSBxdWVzdGlvbiBpcyBzaW5jZSBDR0EgaGFzIDJeNTkgYXMgYSBz ZWN1cml0eSBndWFyYW50ZWUsDQp3aHkgYm90aGVyIGluY3JlYXNlIHNlYz88L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLSBDaHJpc3RpYW4g SHVpdGVtYTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48L3R0 Pg0K --=_alternative 002082A248257B39_=-- From v6ops@globis.net Sun Mar 24 23:35:45 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F82D21F8E87; Sun, 24 Mar 2013 23:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUMFhBS2mBLV; Sun, 24 Mar 2013 23:35:44 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9613221F8E7F; Sun, 24 Mar 2013 23:35:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D08F187005C; Mon, 25 Mar 2013 07:35:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsZqlp7qjuc0; Mon, 25 Mar 2013 07:35:11 +0100 (CET) Received: from Rays-iMac-2.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0B59D870099; Mon, 25 Mar 2013 07:35:11 +0100 (CET) Message-ID: <514FF018.3030506@globis.net> Date: Mon, 25 Mar 2013 07:35:04 +0100 From: Ray Hunter User-Agent: Postbox 3.0.7 (Macintosh/20130119) MIME-Version: 1.0 To: Sujing Zhou References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "ipv6@ietf.org" , 'Erik Nordmark' , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 06:35:45 -0000 > Sujing Zhou > 25 March 2013 06:54 > > Christian Huitema 写于 2013-03-25 12:33:40: > > > > What is the pointing of adding sec since the ratio of effor > > required by attacker and user is always 2^59, as Jari argued. > > > > 2^59 is a rather large number. Everything else being equal, another > > 1 second of computation at the user translates into another 18 > > billion years at the attacker. > Agree. How about 2^56? > My question is since CGA has 2^59 as a security guarantee, why bother > increase sec? > Because as processors get faster, the relative amount of work remains constant at 2^59, but the absolute amount of processing time per operation decreases for both attacker and defender. So the absolute amount of time required to mount a successful attack also decreases over the long term. At some point, the absolute amount of time required to mount an attack will eventually be comparable to the amount of time an address is in use, which makes attacks attractive. Eventually you either have to reduce the time the CGA address remains in use, or make the algorithm more complex for both attacker and defender [add sec]. c.f. DES -> triple DES. > > > > -- Christian Huitema > > > > > > > Christian Huitema > 25 March 2013 05:33 > > 2^59 is a rather large number. Everything else being equal, another 1 > second of computation at the user translates into another 18 billion > years at the attacker. > > -- Christian Huitema > > > > ------------------------------------------------------------------------ From huitema@microsoft.com Mon Mar 25 08:55:14 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63721F8FF3; Mon, 25 Mar 2013 08:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r20FKOLXAROM; Mon, 25 Mar 2013 08:55:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id A9D3C21E8048; Mon, 25 Mar 2013 08:55:10 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.173.161.200) by BL2FFO11HUB024.protection.gbl (10.173.161.48) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 15:55:01 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 15:55:01 +0000 Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 15:54:19 +0000 From: Christian Huitema To: Sujing Zhou Thread-Topic: RE: RE: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas Thread-Index: AQHOKR1YrAxcKrsw2UCmhib0fjHvcJi2jZUQ Date: Mon, 25 Mar 2013 15:54:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(66066001)(47736001)(56816002)(54356001)(55846006)(51856001)(50986001)(73894001)(77982001)(621065001)(44976002)(74502001)(47776003)(47446002)(16406001)(54316002)(53806001)(79102001)(47976001)(46102001)(63696002)(69226001)(49866001)(56776001)(33656001)(74662001)(80022001)(4396001)(59766001)(50466001)(76482001)(65816001)(31966008)(23676001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB024; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , 'Ray Hunter' , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 15:55:14 -0000 PiBNeSBxdWVzdGlvbiBpcyBzaW5jZSBDR0EgaGFzIDJeNTkgYXMgYSBzZWN1cml0eSBndWFyYW50 ZWUsIHdoeSBib3RoZXIgaW5jcmVhc2Ugc2VjPw0KDQpCZWNhdXNlIHRoZSBldmFsdWF0aW9uIG9m IHRoZSBoYXNoIGl0c2VsZiBpcyBhIHZlcnkgc21hbGwgbnVtYmVyLCBhbmQgZ2V0IHNtYWxsZXIg YW5kIHNtYWxsZXIgYXMgTW9vcmUncyBsYXcgcHJvZ3Jlc3Nlcy4NCg0KVW5kZXIgdGhlIHNhbWUg cHJvcG9ydGlvbmFsaXR5IHJ1bGUsIGlmIHRoZSB1c2VyIHNwZW5kcyAxIG1pY3Jvc2Vjb25kIHZl cmlmeWluZyB0aGUgaGFzaCwgdGhlIGF0dGFja2VyIHdpbGwgbmVlZCB0byBzcGVuZCAxOCwwMDAg eWVhcnMuIFRoYXQgc2VlbXMgYSBsb3QsIHVudGlsIHlvdSByZWFsaXplIHRoYXQgaWYgYSBib3Ru ZXQgaGFzIGFjY2VzcyB0byAxIG1pbGxpb24gY29tcHV0ZXJzLCB3ZSBhcmUgZG93biB0byBsZXNz IHRoYW4gNyBkYXlzLiBBbmQgaWYgdGhlc2UgY29tcHV0ZXJzIGluIHR1cm5zIGhhdmUgR1BVIHdp dGggMTAwMCBjb3JlcyBlYWNoLCB3ZSBhcmUgZG93biB0byAxNiBtaW51dGVzLg0KDQpUaGUgU0VD IHByb2Nlc3MgZW5zdXJlcyB0aGF0IHRoZSB1c2VyIHNwZW5kcyBlbm91Z2ggdGltZSB0byBtYWtl IHRoZSBhdHRhY2sgaW1wcmFjdGljYWwuDQoNCg0KDQpGcm9tOiBTdWppbmcgWmhvdSBbbWFpbHRv Onpob3Uuc3VqaW5nQHp0ZS5jb20uY25dIA0KU2VudDogU3VuZGF5LCBNYXJjaCAyNCwgMjAxMyAx MDo1NCBQTQ0KVG86IENocmlzdGlhbiBIdWl0ZW1hDQpDYzogaXB2NkBpZXRmLm9yZzsgJ0plZmZy ZXkgSHV0emVsbWFuJzsgJ0VyaWsgTm9yZG1hcmsnOyBzYWFnQGlldGYub3JnOyAnU2FudG9zaCBD aG9raGFuaSc7ICdSYXkgSHVudGVyJw0KU3ViamVjdDogUmU6IFJFOiBSRTogW3NhYWddIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gb2YgQ0dBIGFuZCBTU0FTIC0gSS1EIGFjdGlvbiA6IGRyYWZ0LXJh ZmllZS02bWFuLXNzYXMNCg0KDQpDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBtaWNyb3NvZnQu Y29tPiDlhpnkuo4gMjAxMy0wMy0yNSAxMjozMzo0MDoNCg0KPiA+IFdoYXQgaXMgdGhlIHBvaW50 aW5nIG9mIGFkZGluZyBzZWMgc2luY2UgdGhlIHJhdGlvIG9mIGVmZm9yIA0KPiByZXF1aXJlZCBi eSDCoGF0dGFja2VyIGFuZCB1c2VyIGlzIGFsd2F5cyAyXjU5LCBhcyBKYXJpIGFyZ3VlZC4gDQo+ IA0KPiAyXjU5IGlzIGEgcmF0aGVyIGxhcmdlIG51bWJlci4gRXZlcnl0aGluZyBlbHNlIGJlaW5n IGVxdWFsLCBhbm90aGVyIA0KPiAxIHNlY29uZCBvZiBjb21wdXRhdGlvbiBhdCB0aGUgdXNlciB0 cmFuc2xhdGVzIGludG8gYW5vdGhlciAxOCANCj4gYmlsbGlvbiB5ZWFycyBhdCB0aGUgYXR0YWNr ZXIuDQpBZ3JlZS4gSG93IGFib3V0IDJeNTY/IA0KTXkgcXVlc3Rpb24gaXMgc2luY2UgQ0dBIGhh cyAyXjU5IGFzIGEgc2VjdXJpdHkgZ3VhcmFudGVlLCB3aHkgYm90aGVyIGluY3JlYXNlIHNlYz8g DQoNCj4gDQo+IC0tIENocmlzdGlhbiBIdWl0ZW1hDQo+IA0KPiANCj4gDQo= From kathleen.moriarty@emc.com Mon Mar 25 11:36:34 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E4121F90C7 for ; Mon, 25 Mar 2013 11:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzw5-CWojYxR for ; Mon, 25 Mar 2013 11:36:33 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id CC2BB21F90B1 for ; Mon, 25 Mar 2013 11:36:32 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2PIaS3U026800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Mar 2013 14:36:30 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Mon, 25 Mar 2013 14:36:12 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.222.70.170]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2PIaCOe009772 for ; Mon, 25 Mar 2013 14:36:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.81]) by mxhub30.corp.emc.com ([128.222.70.170]) with mapi; Mon, 25 Mar 2013 14:36:12 -0400 From: "Moriarty, Kathleen" To: "saag@ietf.org" Date: Mon, 25 Mar 2013 14:36:11 -0400 Thread-Topic: New Version Notification for draft-moriarty-pkcs12v1-1-01.txt Thread-Index: Ac4phD4pEmg2SaomTkiGIWECGfzGfQAAwRzA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [saag] FW: New Version Notification for draft-moriarty-pkcs12v1-1-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 18:36:34 -0000 SGVsbG8sDQoNCkkgYmVsaWV2ZSB0aGUgYXR0YWNoZWQgdmVyc2lvbiBhZGRyZXNzZXMgYWxsIG9m IHRoZSBvdXRzdGFuZGluZyBxdWVzdGlvbnMuICBQbGVhc2UgbGV0IG1lIGtub3cgaWYgdGhlcmUg YXJlIGFueSBmdXJ0aGVyIGNvbW1lbnRzLiAgT25jZSB2ZXJzaW9uIDEuMCBpcyBwdWJsaXNoZWQs IHRoZW4gd2UgY2FuIHdvcmsgb24gdGhlIG1vcmUgZXh0ZW5zaXZlIGNoYW5nZXMgaW4gYSByZXZp c2lvbi4NCg0KVGhhbmsgeW91LA0KS2F0aGxlZW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE1hcmNoIDI1LCAyMDEzIDI6MTEgUE0NClRvOiBN b3JpYXJ0eSwgS2F0aGxlZW4NCkNjOiBtbnlzdHJvbUBtaWNyb3NvZnQuY29tOyBQYXJraW5zb24s IFNlYW47IFJ1c2NoLCBBbmRyZWFzOyBTY290dCwgTWljaGFlbDINClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbW9yaWFydHktcGtjczEydjEtMS0wMS50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbW9yaWFydHktcGtjczEydjEtMS0wMS50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2F0aGxlZW4gTS4gTW9yaWFydHkg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1t b3JpYXJ0eS1wa2NzMTJ2MS0xDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBQS0NTIDEyIHYxOiBQ ZXJzb25hbCBJbmZvcm1hdGlvbiBFeGNoYW5nZSBTeW50YXgNCkNyZWF0aW9uIGRhdGU6CSAyMDEz LTAzLTI1DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczog MjkNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbW9yaWFydHktcGtjczEydjEtMS0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tb3JpYXJ0eS1wa2NzMTJ2MS0xDQpIdG1s aXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcmlhcnR5LXBr Y3MxMnYxLTEtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtbW9yaWFydHktcGtjczEydjEtMS0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg c3RhbmRhcmQgZGVzY3JpYmVzIGEgdHJhbnNmZXIgc3ludGF4IGZvciBwZXJzb25hbCBpZGVudGl0 eQ0KICAgaW5mb3JtYXRpb24sIGluY2x1ZGluZyBwcml2YXRlIGtleXMsIGNlcnRpZmljYXRlcywg bWlzY2VsbGFuZW91cw0KICAgc2VjcmV0cywgYW5kIGV4dGVuc2lvbnMuICBNYWNoaW5lcywgYXBw bGljYXRpb25zLCBicm93c2VycywgSW50ZXJuZXQNCiAgIGtpb3NrcywgYW5kIHNvIG9uLCB0aGF0 IHN1cHBvcnQgdGhpcyBzdGFuZGFyZCB3aWxsIGFsbG93IGEgdXNlciB0bw0KICAgaW1wb3J0LCBl eHBvcnQsIGFuZCBleGVyY2lzZSBhIHNpbmdsZSBzZXQgb2YgcGVyc29uYWwgaWRlbnRpdHkNCiAg IGluZm9ybWF0aW9uLiAgVGhpcyBzdGFuZGFyZCBzdXBwb3J0cyBkaXJlY3QgdHJhbnNmZXIgb2Yg cGVyc29uYWwNCiAgIGluZm9ybWF0aW9uIHVuZGVyIHNldmVyYWwgcHJpdmFjeSBhbmQgaW50ZWdy aXR5IG1vZGVzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KDQo= From bob.hinden@gmail.com Mon Mar 25 09:02:36 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FC321F900F; Mon, 25 Mar 2013 09:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laeS7A7ANPNW; Mon, 25 Mar 2013 09:02:35 -0700 (PDT) Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 22E5521F900A; Mon, 25 Mar 2013 09:02:35 -0700 (PDT) Received: by mail-ve0-f169.google.com with SMTP id d10so1594008vea.0 for ; Mon, 25 Mar 2013 09:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=lAkK9lr3TGrvVaLV5aciLlHq4G1pDAELag0/YXPyXKg=; b=rFOCjHr94dbM1Q6XNueWZIpc5nxr0iKBBjLgZdHlGzyrT+auHxUUjPIzmJk9m0SfFY AHDbj1Owc+qj42+bGkRRRRxay4QKnCunA8zg7PqLkOe/IGJF46NymDdwR105ku+waJz4 PbWOcelPtDEtA2Cuw6Mo6QmzN7lHGYU6UlkuCqtPVBqRhsGbwNzonaN7hYbulWijBdfT d2I60KFHDRjONhsRXp8MrfbNMeIKAUcHukDfHZ1O5LVgSf/TwlFkpJY/wnIes0YFqlz7 9nHz4NPem94760wp2WSj6HI1qciuA4QuzEBgVQe3ZcdcbCUnvOxv9lZ8wqmhf4aPptvu dyEQ== X-Received: by 10.58.187.42 with SMTP id fp10mr3648014vec.46.1364227354585; Mon, 25 Mar 2013 09:02:34 -0700 (PDT) Received: from [10.0.0.23] (c-24-130-151-138.hsd1.ca.comcast.net. [24.130.151.138]) by mx.google.com with ESMTPS id d13sm21056642vdj.8.2013.03.25.09.02.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 25 Mar 2013 09:02:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Bob Hinden In-Reply-To: <514FF018.3030506@globis.net> Date: Mon, 25 Mar 2013 17:02:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <514FF018.3030506@globis.net> To: Ray Hunter X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Tue, 26 Mar 2013 08:02:25 -0700 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , Bob Hinden , Sujing Zhou , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 16:02:36 -0000 >>=20 >>=20 > Because as processors get faster, the relative amount of work remains > constant at 2^59, but the absolute amount of processing time per > operation decreases for both attacker and defender. So the absolute > amount of time required to mount a successful attack also decreases = over > the long term. For example, Graphic Processing Units (GPU) are being used to crack = passwords. They have thousands of cores that can be applied to this = kind of problem. Lots of material about this on the web. Bob From smb@cs.columbia.edu Tue Mar 26 11:06:37 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C5F21F8BC0; Tue, 26 Mar 2013 11:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShUstdvgf4wp; Tue, 26 Mar 2013 11:06:36 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6A21F8B90; Tue, 26 Mar 2013 11:06:36 -0700 (PDT) Received: from [10.9.0.102] (fireball.cs.columbia.edu [128.59.13.10]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id r2QI4ag2018354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 26 Mar 2013 14:04:43 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Steven Bellovin In-Reply-To: Date: Tue, 26 Mar 2013 14:04:36 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <514FF018.3030506@globis.net> To: Bob Hinden X-Mailer: Apple Mail (2.1503) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: "ipv6@ietf.org" , 'Erik Nordmark' , Sujing Zhou , Ray Hunter , "saag@ietf.org" , 'Jeffrey Hutzelman' Subject: Re: [saag] security consideration of CGA and SSAS - I-D action : draft-rafiee-6man-ssas X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 18:06:37 -0000 On Mar 25, 2013, at 12:02 PM, Bob Hinden wrote: >>>=20 >>>=20 >> Because as processors get faster, the relative amount of work remains >> constant at 2^59, but the absolute amount of processing time per >> operation decreases for both attacker and defender. So the absolute >> amount of time required to mount a successful attack also decreases = over >> the long term. >=20 > For example, Graphic Processing Units (GPU) are being used to crack = passwords. They have thousands of cores that can be applied to this = kind of problem. Lots of material about this on the web. >=20 See, for example, = http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standa= rd-windows-password-in-6-hours/ --Steve Bellovin, https://www.cs.columbia.edu/~smb From stephen.farrell@cs.tcd.ie Sat Mar 30 04:40:13 2013 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E6B21F84B0 for ; Sat, 30 Mar 2013 04:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUeZxXmLqcsl for ; Sat, 30 Mar 2013 04:40:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5B67721F84B2 for ; Sat, 30 Mar 2013 04:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B319BE4C; Sat, 30 Mar 2013 11:39:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WT7pW39zl3hh; Sat, 30 Mar 2013 11:39:42 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.45.54.41]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24263BE35; Sat, 30 Mar 2013 11:39:42 +0000 (GMT) Message-ID: <5156CEFC.3010007@cs.tcd.ie> Date: Sat, 30 Mar 2013 11:39:40 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "saag@ietf.org" , "cfrg@irtf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: Mark Nottingham Subject: [saag] Fwd: Fwd: Choosing a header compression algorithm X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 11:40:13 -0000 The httpbis wg are trying to figure out how to do compression in HTTP/2.0 in a way that's not so vulnerable to the CRIME attack. They'd like additional security eyeballs on what is quite a tricky problem. If you're willing and able to help then that'd be best done on the httpbis wg list. Any other questions feel free to ask me or Mark (httpbis wg chair, cc'd) offlist. S. -------- Original Message -------- Subject: Fwd: Choosing a header compression algorithm Date: Sat, 30 Mar 2013 16:50:32 +1100 From: Mark Nottingham To: Stephen Farrell , Sean Turner Any input from Security would be most welcome here… Cheers, Begin forwarded message: > Resent-From: ietf-http-wg@w3.org > From: James M Snell > Subject: Re: Choosing a header compression algorithm > Date: 30 March 2013 8:09:56 AM AEDT > To: Roberto Peon > Cc: RUELLAN Herve , "agl@google.com" , Mark Nottingham , "ietf-http-wg@w3.org Group" > Archived-At: > > +1 ... I have explored this a bit on this end also (and discussed it > with some security folks) and definitely align with Roberto's point of > view. At this point, any prefix matching proposal needs to be backed > with clear evidence as to it's safety. > > On Fri, Mar 29, 2013 at 11:39 AM, Roberto Peon wrote: >> Herve-- >> >> With the way you've implemented prefix matching, there are no guarantees on >> security whatsoever. >> In order to provide a guarantee of at least a minimum amount of effort on >> the part of the attacker, you MUST provide guarantees on the minimum >> subsequence sizes, as this relates directly to the amount of tries... >> As an example, >> foo.com/a/b/c >> will be exceptionally easy to figure out, as each subsequence will be >> guessed in a very small amount of time. >> >> There are many caveats and gotchas in this space, and I feel uncomfortable >> that you're making assertions about safety unless you've got some security >> folks looking at it critically. >> I've done that for the delta compressor, and I suggest you do the same. If >> it turns out that we do get consensus from security folks that some kind of >> prefix matching is safe, I'm happy to add it back into delta. Until then, I >> don't want to go down the rabbit hole! >> -=R >> >> >> On Fri, Mar 29, 2013 at 8:26 AM, RUELLAN Herve >> wrote: >>> >>> >>> >>>> -----Original Message----- >>>> From: Roberto Peon [mailto:grmocg@gmail.com] >>>> Sent: jeudi 28 mars 2013 20:17 >>>> To: RUELLAN Herve >>>> Cc: agl@google.com; Mark Nottingham; ietf-http-wg@w3.org Group >>>> Subject: Re: Choosing a header compression algorithm >>>> >>>> The net effect of the character-delimited prefix match you propose is >>>> that an >>>> attacker must only brute force each subsequence which matches [^/&=, >>>> ]*([^/&=, ]|$) , >>>> >>>> Running the numbers, that is: >>>> >>>> k^s * m >>>> >>>> where: >>>> >>>> k = possible characters >>>> s = subsequence length or characters not ending in [^/&= ,] or >>>> end- >>>> of-line >>>> m = number of subsequences >>>> >>>> >>>> >>>> instead of full atom matching, which is (is a good special case of above >>>> where >>>> m is always 1 and s is always n): >>>> >>>> k^n >>>> >>>> >>>> where: >>>> >>>> >>>> k = possible characters >>>> n = length of field >>>> >>>> >>>> >>>> In other words, full atom matching is *exponentially* more difficult (a >>>> desirable trait)! >>>> >>>> In the example above, assuming 27 commonly used characters per entry, >>>> I'm >>>> very likely to completely discover that data in: >>>> >>>> http://www.example.com/path/first/myfile >>>> >>>> in: >>>> >>>> 27^4 + 27^5 + 27^6 tries >>> >>> This is roughly 400 million tries. And this figure is obtained using >>> several assumptions that may not hold: >>> - The number of possible characters is only 27. >>> - The length of each chunk is known. >>> >>>> Note that it is likely that an attacker would be able to do >>>> substantially better >>>> than above if they know the letter frequency (very likely) or have >>>> similar >>>> data: >>>> In the case of a whole atom match, I'd discover the data in: >>>> >>>> >>>> 27^(17) tries >>>> >>>> >>>> So, full atom matching is ~ 5 quadrillion (5,353,441,417,462,320) times >>>> more >>>> difficult... that is a lot. >>> >>> True full atom matching is much harder, but limited prefix matching is >>> already very hard. >>> >>> We must also keep in mind that each try correspond to a request that the >>> attacker for the client to do. Such a huge number of requests should be >>> detected somewhere, just in order to prevent DoS attacks. >>> >>>> When I originally considered prefix matching in the past, this was the >>>> math >>>> that I did, and I decided that I was not confident that compressor >>>> implementors would ensure that their encoder prevents prefix matching >>>> when the subsequence lengths are too small (and thus easily attacked). >>>> The >>>> same consideration applies to dynamic huffman coding. It *CAN* be safe, >>>> but it requires complexity and computation, and I think there is >>>> significant >>>> risk that implementors may knowing or unknowingly sacrifice security. It >>>> is >>>> actually more safe to ignore delimiters and allow for a match of a >>>> prefix so >>>> long as it is greater than a certain length. At least in that case there >>>> is >>>> guarantee of the number of times that it must be brute forced... >>>> >>>> Full-atom matching is simply much more difficult to get wrong from a >>>> security >>>> perspective, and it results in pretty decent compression... >>> >>> I think that prefix matching with constrained ending is fairly secure: it >>> compels an attacker to used brute force to break it. In addition, it >>> provides very interesting results regarding compression. >> >> >>> >>> >>> Hervé. >>> >>>> -=R >>> >> > -- Mark Nottingham http://www.mnot.net/