Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.

A good future goal is to eliminate plaintext passwords being sent over TLS.

So a future TLS implementation based on a config setting, could abort a TLS
handshake if there is no preshared key authentication or certificate verify
sent by the client. It seems the OPAQUE-sign option (in the TLS Opaque
draft) supports this but the Exported Authenticators do not.

It seems difficult for a TLS client to know which of Exported
Authenticators with OPAQUE or plaintext password over TLS is being used.

Best regards,
Jonathan

On Tue, Jul 23, 2019 at 8:29 AM Owen Friel (ofriel) <ofriel@cisco.com>
wrote:

> Björn,
>
> Its worth reading
> https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque  which Nick
> presented at 104:
> https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls-opaque-00.
> It covers both OPAQUE in the TLS handshake, and OPAQUE via Exported
> Authenticators
> https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/
> at some point after TLS handshake has taken place. Its currently OPAQUE
> specific, but the EA model could probably be applied to other PAKEs. And
> finally,
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2-secondary-certs/
> covers how to use EA with HTTP2.
>
> Owen
>
> -----Original Message-----
> From: Cfrg <cfrg-bounces@irtf.org> On Behalf Of Björn Haase
> Sent: 23 July 2019 08:43
> To: Benjamin Kaduk <kaduk@mit.edu>; Watson Ladd <watsonbladd@gmail.com>
> Cc: CFRG <cfrg@irtf.org>; hugokraw@gmail.com
> Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration
> into TLS // slides.
>
> Dear Ben,
>
> >To build on that, a big motivation for wanting auth at the HTTP layer
> >is that most generic web servers aren't going to know *at TLS handshake
> >time* whether a given client is going to need to authenticate for the
> >HTTP requests that will subsequently be conveyed over that connection.
>
> I fully agree. When saying this, I think that we might better be careful
> not to mix-up two aspects:
>
> 1) The human at the client side mostly wants to be sure that the server
> side contents are authentic, from the very beginning.
> 2) The server side requires authentication often only when operations with
> privileges are requested.
>
> What we have here is something similar to what I'd be calling
> "re-authentication use-case" for password checks in a connection that is
> already established.
>
> Moreover I see differences regarding the use-cases A
> "End-customer-managed web servers (IoT)" and  B "Conventional Web-Shop
> use-cases (Web-PKI)". The main additional benefit of PAKE for use-case A is
> that the server-authentication (1.) above) is provided also without the
> need of Web-PKI integration of the server.
>
> I think that one might best try to realize the maximum possible re-use for
> authentication mechanisms in both use-cases A/B. Again this might be a
> reason for "outsourcing" all of the user-handling related stuff outside of
> the main TLS body. Also for use case "B" it might be worth to consider
> pulling out the password handling out from the main html application. Maybe
> one could use the same mechanisms of a "user authentication" module that we
> would be using for PAKE? For doing so again some kind of channel-linked
> tunnel mechanism through TLS might be helpful/necessary.
>
> Yours,
>
> Björn.
>
> P.S.: I have moved this discussion back to the main list. Sorry for
> starting this discussion with the "not yet publication-ready" slides.
>
>
> Mit freundlichen Grüßen I Best Regards
>
> Dr. Björn Haase
>
> Senior Expert Electronics | TGREH Electronics Hardware
> Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen
> Endress+| Germany
> Phone: +49 7156 209 377 | Fax: +49 7156 209 221 bjoern.haase@endress.com
> |  www.conducta.endress.com
>
>
>
> Endress+Hauser Conducta GmbH+Co.KG
> Amtsgericht Stuttgart HRA 201908
> Sitz der Gesellschaft: Gerlingen
> Persönlich haftende Gesellschafterin:
> Endress+Hauser Conducta Verwaltungsgesellschaft mbH
> Sitz der Gesellschaft: Gerlingen
> Amtsgericht Stuttgart HRA 201929
> Geschäftsführer: Dr. Manfred Jagiella
>
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (
> https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the material from any
> computer. This e-mail does not constitute a contract offer, a contract
> amendment, or an acceptance of a contract offer unless explicitly and
> conspicuously designated or stated as such.
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>