RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt

Christian Huitema <huitema@microsoft.com> Fri, 29 November 2013 03:10 UTC

Return-Path: <huitema@microsoft.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2D1AE013 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2013 19:10:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-TUROA5mcSN for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2013 19:10:14 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0151.outbound.protection.outlook.com [207.46.163.151]) by ietfa.amsl.com (Postfix) with ESMTP id A91461A1DBD for <ipv6@ietf.org>; Thu, 28 Nov 2013 19:10:14 -0800 (PST)
Received: from BL2PR03CA014.namprd03.prod.outlook.com (10.141.66.22) by BL2PR03MB131.namprd03.prod.outlook.com (10.255.230.23) with Microsoft SMTP Server (TLS) id 15.0.820.5; Fri, 29 Nov 2013 03:10:12 +0000
Received: from BL2FFO11FD023.protection.gbl (2a01:111:f400:7c09::136) by BL2PR03CA014.outlook.office365.com (2a01:111:e400:c1b::22) with Microsoft SMTP Server (TLS) id 15.0.825.14 via Frontend Transport; Fri, 29 Nov 2013 03:10:12 +0000
Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.0.825.6 via Frontend Transport; Fri, 29 Nov 2013 03:10:12 +0000
Received: from TK5EX14MBXC272.redmond.corp.microsoft.com ([169.254.2.174]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0158.002; Fri, 29 Nov 2013 03:09:29 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Hosnieh Rafiee <ietf@rozanak.com>, 'Ray Hunter' <v6ops@globis.net>
Subject: RE: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt
Thread-Topic: FW: New Version Notification for draft-rafiee-6man-cga-attack-00.txt
Thread-Index: Ac7smeEVAgkCvPF12cG9eyx+VjbUAgAFOGeg
Date: Fri, 29 Nov 2013 03:09:27 +0000
Message-ID: <C91E67751B1EFF41B857DE2FE1F68ABA2FBC395D@tk5ex14mbxc272.redmond.corp.microsoft.com>
References: <005601ceec99$ed4cfc40$c7e6f4c0$@rozanak.com>
In-Reply-To: <005601ceec99$ed4cfc40$c7e6f4c0$@rozanak.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.32]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(189002)(199002)(66066001)(6806004)(79102001)(51856001)(20776003)(87936001)(31966008)(50466002)(47736001)(81542001)(65816001)(49866001)(74502001)(80976001)(54356001)(80022001)(23746002)(47446002)(4396001)(87266001)(53806001)(76482001)(46102001)(63696002)(74876001)(76786001)(77982001)(83072001)(55846006)(59766001)(33656001)(69226001)(44976005)(81686001)(74366001)(2656002)(83322001)(561944002)(50986001)(76796001)(81342001)(85306002)(81816001)(54316002)(77096001)(74662001)(47776003)(74706001)(47976001)(56776001)(90146001)(56816005); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB131; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0045236D47
X-OriginatorOrg: microsoft.com
Cc: 'marcelo bagnulo braun' <marcelo@it.uc3m.es>, "ipv6@ietf.org" <ipv6@ietf.org>, Erik Nordmark <nordmark@sonic.net>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2013 03:10:17 -0000

> Sec value 1 => 2^(59+16)  for brute force searching => for birthday paradox
> => 2^(30)     This is actually the total security you obtain with sec value
> 1 and we know that the other sec values are not ideal to use
> Sec value 2=> 2^(59+32) for brute force searching => for birthday paradox =>
> 2^(45.5)    So you dramatically decreased the performance but you only could
> gain 15 more bits. 

The birthday paradox really does not apply in the SEND case. It would allow an attacker to generates two keys that map to the same IPv6 address, but it would not allow the attacker to target a specific address, you will need the brute force attack for that.

There is a related attack, against a group. Suppose a subnet of, say, 1024 nodes using SEND. An attacker that generates random value has 1024 chances each time to find a match not for one specific node, but for some random member of the subnet. It will need about 2^49 trials with SEND.

Of course, your SSAS proposal is also susceptible to that attack. In your design, the 64 bits are directly derived from the key, without mixing any subnet prefix. Suppose an attacker lists 1 million SSAS address from the DNS. In 2^44 trials, it will be able to find a match for at least one of them. 

The value of the SEC field does not change the number of required trials, but it makes each trial 2*(16*SEC) times more expensive.

>> The CGA mechanism protects an IPv6 address. All the identifier bits are part of
>> the IPv6 address. If an attacker uses a different SEC value, it is not attacking
>> the protected IPv6 address, but a different one.
> 
> I guess I am repeating myself here as I explained it before that how this
> attack can happens

I think you are repeating yourself. If an address differs by a few bits, it is a different address. The CGA mechanism answers the question, "is the sender the legitimate owner of the specific address." To spoof the address, you have to present a candidate that matches the target completely, including the SEC bits.


-- Christian Huitema