Re: [IPsec] PAKE selection: SPSK
"Dan Harkins" <dharkins@lounge.org> Wed, 26 May 2010 16:34 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9AA13A68BB for <ipsec@core3.amsl.com>; Wed, 26 May 2010 09:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.765
X-Spam-Level:
X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlhKD6RoO6AE for <ipsec@core3.amsl.com>; Wed, 26 May 2010 09:34:46 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B15D73A687C for <ipsec@ietf.org>; Wed, 26 May 2010 09:34:46 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9B53F1022404C; Wed, 26 May 2010 09:34:37 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 26 May 2010 09:34:37 -0700 (PDT)
Message-ID: <b04b32d1deae1ee28a02e89a982347d8.squirrel@www.trepanning.net>
In-Reply-To: <201005261418.56567.dennis.kuegler@bsi.bund.de>
References: <3ed604c92cb4ccc78ffaf0486db97ff7.squirrel@www.trepanning.net> <201005261418.56567.dennis.kuegler@bsi.bund.de>
Date: Wed, 26 May 2010 09:34:37 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Dennis Kügler <dennis.kuegler@bsi.bund.de>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: ipsec@ietf.org
Subject: Re: [IPsec] PAKE selection: SPSK
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2010 16:34:47 -0000
Hi Dennis, On Wed, May 26, 2010 5:18 am, Dennis Kügler wrote: > I finally had some time to have a look at your proposal and the > evaluation. > Please find some initial comments below. > > - The design of SPSK is very close to SPEKE. It is based on the > computation of > a (secret) group generator from a shared password. SPEKE is patented and > it > looks like the patent is also applicable to SPSK. If not please indicate > why > not. You don't mention any specific claim from the SPEKE patent so let me address the first independent claim (there are many claims dependent on that one). The patent I'm referring to is US 6,792,533 dated Sept 14, 2004. The claim says: "A cryptographic method for providing authentication, comprising: providing a password-based value to a first party and a second party; selecting a parameter based on said password-based value, said parameter defining one of a plurality of unauthenticated key distribution techniques; generating by said first party, in cooperation with said second party, a cryptographic key based on said one of the plurality of unauthenticated key distribution techniques, wherein said second party cooperates in generating said cryptographic key by using said one of the plurality of unauthenticated key distribution techniques defined by said first value; and providing authentication of said first party to said second party based on said cryptographic key." Now first of all, that is very broadly worded. Every password-based protocol provides a password to the first party and second party. But there's more to this claim so SPEKE doesn't cover every single protocol that distributes and uses passwords. The next part talks about selecting a parameter based on the password value and dragonfly certainly does that but the important part of this portion of the claim, and the following part of the claim, is the "plurality of unauthenticated key distribution techniques". What is that? There are different kinds of public key distribution systems where there is a "private key" and a "public key" which is based on the "private key". Earlier in the descriptive portion of the patent (which is not part of a claim but can be used to interpret a claim) it says "SPEKE can also use other unauthenticated public-key distribution systems, such as the Modified Diffie-Hellman" and goes on to show an example of that. I don't believe that the Modified D-H alone comprises a "plurality of unauthenticated key distribution techniques." I would also imagine that a static-ephemeral D-H or a static-static D-H that used a password-derived parameter to perform that particular type of unauthenticated key distribution technique would probably be covered. What is common on all these unauthenticated key distribution techniques is how a public key based on the private key is distributed to the other party. The private key is communicated in an obfuscated form based on the discrete logarithm problem-- e.g. pub = g^priv mod p. That is not done in dragonfly. In dragonfly the private key is obfuscated by adding it to a random number modulus the order of the group. The random number is unmasked in a fashion that gives the private key to the second party in a form that does not let it know the private key. Such a technique is new and novel and not part of any known "plurality of unauthenticated key distribution techniques". So it is my contention that for this claim to apply then both a password-based parameter must be used AND that password-based parameter must be used with a known technique of unauthenticated key distribution. It is not and this claim does not apply to dragonfly. If it was not claim 1 that you were referring to above then please say exactly what claim in the SPEKE patent you are talking about. > - "Dragonfly is secure and has received cryptographic review". Please > provide > a reference to the cryptographically reviewed document. Both the IEEE 802.11 TGs Draft and the EAP-pwd variant have been reviewed. > - The construction used for computing the group generator is susceptible > to > side channel (timing) attacks and may leak the shared password. I'd > therefore > recommend to replace the randomized search algorithm by a deterministc > algorithm. I had a discussion about that. The IEEE 802.11 TGs Draft had a password element created based on the password before the exchange started (it was computed a configuration time when a particular group was selected). Then, when the exchange started the identities of the two parties were run through the random function and used in the "scalar-op" to derive a pair-wise unique element with which to do dragonfly. This would foil the side channel attack. But I was convinced that this was not so important and eliminated the extra step to provide ease of analysis. If you think this is important the SPSK draft could certainly introduce this technique to get around a side channel attack. I'm not so sure how important that is though (basically I was convinced it's not so important). If you know I can find a solution to the curve the first time you can eliminate some passwords from the pool of potential passwords but you don't know which ones unless you have run them all through the algorithm beforehand. And even if you have run all possible password through the algorithm it certainly doesn't leak the shared password, it just allows the attacker to eliminate some passwords from the pool of potential passwords. And to do so this attack has to be mounted and that is not a trivial attack. regards, Dan.
- [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins
- Re: [IPsec] PAKE selection: SPSK Dennis Kügler
- Re: [IPsec] PAKE selection: SPSK Dan Harkins