Re: [Cfrg] password-based key exchange

Jonathan Katz <jkatz@cs.umd.edu> Thu, 05 January 2012 01:27 UTC

Return-Path: <jkatz@cs.umd.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D54C21F8746 for <cfrg@ietfa.amsl.com>; Wed, 4 Jan 2012 17:27:35 -0800 (PST)
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 j1489qX99I8G for <cfrg@ietfa.amsl.com>; Wed, 4 Jan 2012 17:27:34 -0800 (PST)
Received: from bacon.cs.umd.edu (router-304.cs.umd.edu [128.8.127.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3298521F856B for <cfrg@irtf.org>; Wed, 4 Jan 2012 17:27:34 -0800 (PST)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: jkatz) by bacon.cs.umd.edu (Postfix) with ESMTPSA id E96C8B4101E for <cfrg@irtf.org>; Wed, 4 Jan 2012 20:27:30 -0500 (EST)
Received: by iadj38 with SMTP id j38so93699iad.13 for <cfrg@irtf.org>; Wed, 04 Jan 2012 17:27:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.50.219.226 with SMTP id pr2mr68396348igc.30.1325726850542; Wed, 04 Jan 2012 17:27:30 -0800 (PST)
Received: by 10.231.49.65 with HTTP; Wed, 4 Jan 2012 17:27:30 -0800 (PST)
Date: Wed, 4 Jan 2012 20:27:30 -0500
Message-ID: <CAC7JQK0iBoc1QBEOtE=wuJKKEiR7T0C2PdHWbDGWS7dnmQ8H6Q@mail.gmail.com>
From: Jonathan Katz <jkatz@cs.umd.edu>
To: cfrg@irtf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.8 (bacon.cs.umd.edu [0.0.0.0]); Wed, 04 Jan 2012 20:27:31 -0500 (EST)
X-CSD-MailScanner-ID: E96C8B4101E.AAC6C
X-CSD-MailScanner: Found to be clean
X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00)
X-CSD-MailScanner-From: jkatz@cs.umd.edu
X-CSD-MailScanner-Watermark: 1326331651.33834@mMKKFFx+mthWbA1a+3ZXTQ
Cc: tls@ietf.org
Subject: Re: [Cfrg] password-based key exchange
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 01:27:35 -0000

You don't specify your threat model. One formal model for
password-based key exchange is the one introduced by Bellare,
Pointcheval, and Rogaway in 2000 and used in several papers since
then. What threat model did you have in mind?

(In fact, the protocol seems susceptible to attacks within the [BPR00]
model, although I didn't manage to find any full-fledged attack.)

Some other "obvious" things you may want to consider:
- It's usually considered a bad idea to let the final session key be
one that was also used for key confirmation. So you may want to add a
step where the final session key is derived (using a suitable KDF)
from the intermediate key K.
- To head off potential avenues of attack, it is probably a good idea
to have peer check that local_scalar \neq 0 and local_element \neq 1,
and vice versa.


> -----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
>
> 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