+1 for this work.

If you are one of those that think, as I did 20 years ago, that password
authentication is dying and practical replacements are just around the
corner, do not support this document. Otherwise, please do.

Asymmetric or augmented PAKE (aPAKE) protocols provide secure password
authentication in the common client-server case (where the server stores a
one-way mapping of the password) without relying on PKI - except during
user/password registration. Passwords remain secure regardless of which
middleboxes or endpoints spy into your decrypted TLS streams.  The server
never sees the password, not even during password registration.

To see real deployment of such protocols, they need to be integrated with
TLS which is what Barnes's draft facilitates. Not only this improve
significantly the protection of passwords and password authentication, but
aPAKE protocols also provide an hedge against PKI failures by enabling
mutual client-server authentication without relying on regular server
certificates.

Hugo


On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes <r...@ipv.sx> wrote:

> Hey TLS WG,
>
> In response to some of the list discussion since the last IETF, Owen and I
> revised our TLS PAKE draft.  In the current version, instead of binding to
> a single PAKE (SPAKE2+), it defines a general container that can carry
> messages for any PAKE that has the right shape.  And we think that "right
> shape" covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, ...
>
> The chairs have graciously allotted us 5min on the agenda for Thursday,
> where I'd like to ask for the WG to adopt the document.  So please speak up
> if you think this is an interesting problem for the TLS WG to work on, and
> if you think the approach in this document is a good starting point.  Happy
> for comments here or at the microphone on Thursday!
>
> Thanks,
> --Richard
>
>
> ---------- Forwarded message ---------
> From: <internet-dra...@ietf.org>
> Date: Mon, Jul 16, 2018 at 3:25 PM
> Subject: New Version Notification for draft-barnes-tls-pake-04.txt
> To: Richard Barnes <r...@ipv.sx>, Owen Friel <ofr...@cisco.com>
>
>
>
> A new version of I-D, draft-barnes-tls-pake-04.txt
> has been successfully submitted by Richard Barnes and posted to the
> IETF repository.
>
> Name:           draft-barnes-tls-pake
> Revision:       04
> Title:          Usage of PAKE with TLS 1.3
> Document date:  2018-07-16
> Group:          Individual Submission
> Pages:          11
> URL:            https://www.ietf.org/internet-
> drafts/draft-barnes-tls-pake-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
> Htmlized:       https://tools.ietf.org/html/draft-barnes-tls-pake-04
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-barnes-tls-pake
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04
>
> Abstract:
>    The pre-shared key mechanism available in TLS 1.3 is not suitable for
>    usage with low-entropy keys, such as passwords entered by users.
>    This document describes an extension that enables the use of
>    password-authenticated key exchange protocols with TLS 1.3.
>
>
>
>
> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to