Re: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.txt)

Fabrice <fabrice.gautier@gmail.com> Thu, 07 November 2013 22:37 UTC

Return-Path: <fabrice.gautier@gmail.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 D159821E8172 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 14:37:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 fueNL9g8hl1R for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 14:37:30 -0800 (PST)
Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C68F221E816F for <tls@ietf.org>; Thu, 7 Nov 2013 14:37:30 -0800 (PST)
Received: by mail-pd0-f175.google.com with SMTP id g10so1238827pdj.20 for <tls@ietf.org>; Thu, 07 Nov 2013 14:37:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/MKb8SB5gnfDdnCiwZUixpKTn61jgih1/sec7xtdW/I=; b=ORnNZItQQrIIIiFN+DBcEqbX5K1CiHQoMlqA42Rfk4hfzxJ3pcCFAUtD2/1Y0bB3vK scjBxinHqDiXRsh+mrTyRDd51hnBRLoFs7BorKPdF/DtruaSac0cnEL5gt6kK2Wdv6ht eV7z47qr6hxkXQk++OcPdm3TZS9dad2F3WtPkSSuZ14zqm/Jer3UtwQBapjqqJ5SIQ0e sIrTmM+xihHNO5xHfyQMUfFBbMHpsiyAfe9R1Ow4AvsGMiN+vfX08LSBntqrcAbEw2qe Lo3XUN1beSBw4oM0cTBpHD4OuJelo4b+aKN7U43sca1/vxZPQOa321qsA7Qcus9s4IT5 Yhsw==
X-Received: by 10.68.13.202 with SMTP id j10mr11304958pbc.147.1383863850410; Thu, 07 Nov 2013 14:37:30 -0800 (PST)
Received: from [17.244.7.96] ([17.244.7.96]) by mx.google.com with ESMTPSA id at4sm7456823pbc.30.2013.11.07.14.37.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 14:37:28 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-E42E981B-84E0-4879-A499-3C502F496C82"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11B504)
In-Reply-To: <CAEKgtqnSgdouYAmSa5DbN1sME=65wi3PpM17b2+Bybsz8PzBow@mail.gmail.com>
Date: Thu, 07 Nov 2013 14:37:39 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <07A9A949-2A96-4401-B640-A0E1C438A8E8@gmail.com>
References: <CAEKgtqmfHpzNye_DCgyzJ7PmsGRFWCHAtjX=HOLKo0OEoEi0gQ@mail.gmail.com> <CANOyrg-LzPbft+DMH8h3HatAJAwTqx6PRBG_n=3MrSfWHcMSqg@mail.gmail.com> <CAEKgtqnSgdouYAmSa5DbN1sME=65wi3PpM17b2+Bybsz8PzBow@mail.gmail.com>
To: SeongHan Shin <seonghan.shin@aist.go.jp>
Cc: 古原和邦 <k-kobara@aist.go.jp>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Augmented PAKE (Re: New Version Notification for draft-shin-tls-augpake-01.txt)
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: Thu, 07 Nov 2013 22:37:31 -0000

> On Nov 7, 2013, at 10:36, SeongHan Shin <seonghan.shin@aist.go.jp> wrote:
> 
> Hi Fabrice,
> 
> Thank you for your comment!
> 
> Section 5.1 can be used in TLS 1.3 handshake (?) as in Eric's presentation :)

I haven't seen anything in the TLS1.3 flows document that would allow that.

> 
> >How does the client knows which group to use ?
> As you pointed out, we need to change Section 5.1 for the current tls version.
> A naive approach is to add one round exchange after ServerHello.
> Any other good ideas?

I guess you could only require the extra round trip for the first connection and have the client cache the group parameters somehow. 

But then you probably need a way for the client to tell the server which parameter it is using, so it can signal if the parameters match without going through the whole handshake. 

Also, your draft don't define new ciphersuites, like TLS-SRP does, so I don't think it's complete. 

   Fabrice 


> 
> Regards,
> Shin
> 
> 
>> On Fri, Nov 8, 2013 at 1:20 AM, Fabrice Gautier <fabrice.gautier@gmail.com> wrote:
>> Hi,
>> 
>> How does the client knows which group to use ?
>> 
>> As the client would need to know the group before sending the
>> ClientHello, it seems that the client needs to remember the groups
>> parameters along with the password, which seems impractical.
>> 
>> 
>> -- Fabrice
>> 
>> 
>> On Wed, Nov 6, 2013 at 11:25 AM, SeongHan Shin <seonghan.shin@aist.go.jp> wrote:
>> > Dear all,
>> >
>> > For anyone who are interested in PAKE, pls see the below I-D regarding
>> > augmented PAKE.
>> >
>> > IMO, two reasons that SRP was published as RFC 2945 and included in IEEE
>> > 1363.2 and ISO/IEC 11770-4 are 1) SRP is an augmented PAKE and 2) the
>> > server's computation cost of SRP is a minimum.
>> > (Though SRP has no provable security)
>> >
>> > The AugPAKE in the below I-D is provably secure and more efficient than
>> > other augmented PAKEs (including SRP and AMP).
>> >
>> > Of course, augmented PAKE provides additional security property over
>> > (balanced) PAKE.
>> >
>> > Best regards,
>> > Shin
>> >
>> >
>> > On Wed, Sep 4, 2013 at 6:39 PM, SeongHan Shin <seonghan.shin@aist.go.jp>
>> > wrote:
>> >>
>> >> Dear all,
>> >>
>> >> I submitted a new version of our I-D regarding augmented PAKE (AugPAKE)
>> >> and its integration into TLS.
>> >> I added some features of AugPAKE in Appendix.
>> >> Any comments are welcome!
>> >>
>> >> Best regards,
>> >> Shin
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: <internet-drafts@ietf.org>
>> >> Date: Wed, Sep 4, 2013 at 6:26 PM
>> >> Subject: New Version Notification for draft-shin-tls-augpake-01.txt
>> >> To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin
>> >> <seonghan.shin@aist.go.jp>
>> >>
>> >>
>> >>
>> >> A new version of I-D, draft-shin-tls-augpake-01.txt
>> >> has been successfully submitted by SeongHan Shin and posted to the
>> >> IETF repository.
>> >>
>> >> Filename:        draft-shin-tls-augpake
>> >> Revision:        01
>> >> Title:           Augmented Password-Authenticated Key Exchange for
>> >> Transport Layer Security (TLS)
>> >> Creation date:   2013-09-04
>> >> Group:           Individual Submission
>> >> Number of pages: 19
>> >> URL:
>> >> http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt
>> >> Status:          http://datatracker.ietf.org/doc/draft-shin-tls-augpake
>> >> Htmlized:        http://tools.ietf.org/html/draft-shin-tls-augpake-01
>> >> Diff:
>> >> http://www.ietf.org/rfcdiff?url2=draft-shin-tls-augpake-01
>> >>
>> >> Abstract:
>> >>    This document describes an efficient augmented password-authenticated
>> >>    key exchange (AugPAKE) protocol where a user remembers a low-entropy
>> >>    password and its verifier is registered in the intended server.  In
>> >>    general, the user password is chosen from a small set of dictionary
>> >>    whose space is within the off-line dictionary attacks.  The AugPAKE
>> >>    protocol described here is secure against passive attacks, active
>> >>    attacks and off-line dictionary attacks (on the obtained messages
>> >>    with passive/active attacks), and also provides resistance to server
>> >>    compromise (in the context of augmented PAKE security).  Based on the
>> >>    AugPAKE protocol, this document also specifies a new password-only
>> >>    authentication handshake for Transport Layer Security (TLS) protocol.
>> >>
>> >>
>> >>
>> >>
>> >> Please note that it may take a couple of minutes from the time of
>> >> submission
>> >> until the htmlized version and diff are available at tools.ietf.org.
>> >>
>> >> The IETF Secretariat
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> ------------------------------------------------------------------
>> >> SeongHan Shin
>> >> Research Institute for Secure Systems (RISEC),
>> >> National Institute of Advanced Industrial Science and Technology (AIST),
>> >> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> >> Tel : +81-29-861-2670/5284
>> >> Fax : +81-29-861-5285
>> >> E-mail : seonghan.shin@aist.go.jp
>> >> ------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> > --
>> > ------------------------------------------------------------------
>> > SeongHan Shin
>> > Research Institute for Secure Systems (RISEC),
>> > National Institute of Advanced Industrial Science and Technology (AIST),
>> > Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
>> > Tel : +81-29-861-2670/5284
>> > Fax : +81-29-861-5285
>> > E-mail : seonghan.shin@aist.go.jp
>> > ------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> >
> 
> 
> 
> -- 
> ------------------------------------------------------------------
> SeongHan Shin
> Research Institute for Secure Systems (RISEC),
> National Institute of Advanced Industrial Science and Technology (AIST),
> Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
> Tel : +81-29-861-2670/5284
> Fax : +81-29-861-5285
> E-mail : seonghan.shin@aist.go.jp
> ------------------------------------------------------------------