Re: [TLS] [Cfrg] password-based key exchange
"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Tue, 20 December 2011 22:17 UTC
Return-Path: <sfluhrer@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4121F863E for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 14:17:39 -0800 (PST)
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 29+5b9o9-vK1 for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 14:17:38 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 48DC521F85EF for <tls@ietf.org>; Tue, 20 Dec 2011 14:17:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=3664; q=dns/txt; s=iport; t=1324419458; x=1325629058; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nPGmmEZ8L1UUqLUwo0LrooHlHbqIf3YznXyn/szOEak=; b=jbyL9uwLxerNR1r4f8HKBrpszfE3ivznHgpGwOYlh1CEiDjjOUpTrh54 sab9G2E9RwTTEcXMuudn71+jZTQ6Oz63Mmcb8ox7hef4mtIHvs+aFXz+R m/e6U7ECUwQcWnSd/58BV1fStSK2oN1DIKStyJAVkhiexfcck/K9cciUr M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArAAAMQI8U6rRDoG/2dsb2JhbABDmzCQVYEFgXIBAQEDAQEBAQ8BHQoxAwsMBAIBCA4DBAEBCwYIDwEGASYfCQgBAQQBEggBGYdYCJh4AZ4viHSCNWMEiDefGQ
X-IronPort-AV: E=Sophos;i="4.71,384,1320624000"; d="scan'208";a="21777492"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 20 Dec 2011 22:17:37 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pBKMHbHM030361; Tue, 20 Dec 2011 22:17:37 GMT
Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 14:17:36 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 20 Dec 2011 14:17:33 -0800
Message-ID: <EE0C2F9E065E634B84FC3BE36CF8A4B2086EB50C@xmb-sjc-23e.amer.cisco.com>
In-Reply-To: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Cfrg] password-based key exchange
Thread-Index: Acy/X7M8gT00/SasSmuwbuoIFdk5ugABQuWg
References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net>
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: Dan Harkins <dharkins@lounge.org>, cfrg@irtf.org
X-OriginalArrivalTime: 20 Dec 2011 22:17:36.0496 (UTC) FILETIME=[2D9FEF00:01CCBF65]
X-Mailman-Approved-At: Tue, 20 Dec 2011 14:47:24 -0800
Cc: tls@ietf.org
Subject: Re: [TLS] [Cfrg] password-based key exchange
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Dec 2011 22:17:39 -0000
One minor comment (which might be totally obvious): > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange > > > Hello, > > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 > > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). > > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: > > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: > > - E = HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x = H(y) returns a random stream, x, given some input, y. > > The key exchange works like this: > > 1. PE = HashToElement(local_ID | peer_ID | password) > gets a "password element" > > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. > > 2. generate 2 random numbers between 0 and the order of the group, q: > > 0 < local_rand, local_mask < q > > 3. compute a scalar and an element: > local_scalar = (local_rand + local_mask) mod q > local_element = 1/(PE^local_mask) mod p > > where p is the prime and q is the order. Send local_scalar and > local_element to other side > > 4. receive peer_scalar and peer_element from other side > > 5. compute shared key, K > > K = (PE^peer_scalar * peer_element)^local_rand mod p = > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > = > PE^(peer_rand*local_rand) mod p You probably should have an explicit test and rejection for K = 1 ('point at infinity' for EC groups)... > > 6. compute a confirmation > > local_confirm = H(K, local_scalar | local_element | > peer_scalar | peer_element) > > send confirmation to peer > > 7. receive peer's confirmation, calculate verifier > > verifier = H(K, peer_scalar | peer_element | local_scalar | > local_element) > > if verifier equals peer's confirmation the peer is authenticated. > > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". > > Thank you in advance for any analysis that can be provided on this > exchange. > > regards, > > Dan. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
- [TLS] password-based key exchange Dan Harkins
- Re: [TLS] [Cfrg] password-based key exchange Scott Fluhrer (sfluhrer)
- Re: [TLS] [Cfrg] password-based key exchange Dan Harkins
- Re: [TLS] [Cfrg] password-based key exchange Igoe, Kevin M.
- Re: [TLS] [Cfrg] password-based key exchange Dan Harkins
- Re: [TLS] password-based key exchange Jonathan Katz
- Re: [TLS] password-based key exchange Dan Harkins