Subject: Re: [TLS] [Cfrg] I-D Action: draft-irtf-cfrg-augpake-00.txt

From: Trevor Perrin <[email-masked]>
Date: Fri, 6 Dec 2013 12:26:15 -0800

I really like this idea & can find no problems.

Since a single cursory opinion counts for CFRG consensus [1,2],
consider this approved by CFRG and our NSA overseers.

Thanks, come again!

Trevor

P.S. The treatment of random numbers could be improved, consider
referencing NIST SP 800-90A.

(psst Kevin ^^^ THIS is how it's done.  *FINESSE*, or you'll never
work the big leagues!)

[1] http://www.ietf.org/mail-archive/web/cfrg/current/msg03047.html
[2] http://www.ietf.org/proceedings/84/minutes/minutes-84-tls

On Sun, Sep 29, 2013 at 11:18 PM, SeongHan Shin
<[email-masked]> wrote:
> Dear all,
>
> We submitted our I-D regarding augmented PAKE
> that provides extra protection to server compromise compared to balanced
> PAKE.
> (Of course, it can be easily converted to the balanced one)
>
> Any comments are welcome!
>
> Best regards,
> Shin
>
>
> On Fri, Sep 6, 2013 at 4:45 PM, <[email-masked]> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>  This draft is a work item of the Crypto Forum Research Group Working
>> Group of the IETF.
>>
>>         Title           : Augmented Password-Authenticated Key Exchange
>> (AugPAKE)
>>         Author(s)       : SeongHan Shin
>>                           Kazukuni Kobara
>>         Filename        : draft-irtf-cfrg-augpake-00.txt
>>         Pages           : 17
>>         Date            : 2013-09-06
>>
>> Abstract:
>>    This document describes a secure and highly-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).  Also, this
>>    protocol provides resistance to server compromise in the context that
>>    an attacker, who obtained the password verifier from the server, must
>>    at least perform off-line dictionary attacks to gain any advantage in
>>    impersonating the user.  The AugPAKE protocol is not only provably
>>    secure in the random oracle model but also the most efficient over
>>    the previous augmented PAKE protocols (SRP and AMP).
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-irtf-cfrg-augpake
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-irtf-cfrg-augpake-00
>>
>>
>> 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.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Cfrg mailing list
>> [email-masked]
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>
>
>
> --
> ------------------------------------------------------------------
> 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 : [email-masked]
> ------------------------------------------------------------------
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 9 Dec 2013 11:41:08 -0800

Hi Shin,

Just to be clear - I was making fun of Kevin Igoe, not yourself -
AugPAKE seems like a great piece of work.

Couple questions:

 - There's obvious similarities with SRP.  Do you think the AugPAKE
proof techniques could be used to make a security proof for SRP?  (For
an elliptic curve SRP, you could imagine using the SRP verifier with
Elligator to encrypt the g^b value, instead of SRP's traditional "B =
kv + g^b").

 - There seems to be an ordering constraint between AugPAKE's client
and server messages, requiring the client to go first.  For TLS at
least, such a constraint is awkward.  It either requires an extra
round-trip for the server to communicate the salt and group values, or
requires the client to assume the group and use no salt (the approach
taken in your TLS draft [1]).  The latest version of SRP [2] was able
to remove this constraint.  Is it possible to do the same for AugPAKE?

Trevor

[1] http://tools.ietf.org/html/draft-shin-tls-augpake-01

[2]
 http://tools.ietf.org/html/rfc5054
 http://srp.stanford.edu/design.html
 http://srp.stanford.edu/srp6.ps