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

Jonathan Trostle <jonattr@gmail.com> Wed, 07 August 2019 04:29 UTC

Return-Path: <jonattr@gmail.com>
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 1B1B7120104 for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 21:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnt8tt83QthS for <cfrg@ietfa.amsl.com>; Tue, 6 Aug 2019 21:29:28 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFFB12010E for <cfrg@irtf.org>; Tue, 6 Aug 2019 21:29:27 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id k10so17889635qtq.1 for <cfrg@irtf.org>; Tue, 06 Aug 2019 21:29:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WVZtjopG8MshBdOITd/GKST3pWbxwjFqsNSkV/tfAqM=; b=gSsfpRYmV9+ssmdxHA3+hSoLhgP5saKFpZKgluSv0V78rLZrLaZVDFLIZTdMwB1dDe dFWxTs2c4ls2tX8UTk+dnSqrHZ+uanPOIdBAlM5uh9E7TetrzMLxItH1TZOPhz2fXArm hW5T4LxPDBRiF7+Phy/4Q2IQvatrpxtnLsOnkiakjC6whKsostffn7utu24iY1zGSdpm A8N1SCfPtvsmzoO0vAQ469w/94fackmCMw4Np3oilok7NYf/3oYGG8B9hcgZ2HCBv3Cg EKQRRdoFfNJGbXKKzeXj0hytwNv1c2CYNlrqChA/xkxL8W/vmnZaUU4xsbJzg+0W9qZp Gwnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WVZtjopG8MshBdOITd/GKST3pWbxwjFqsNSkV/tfAqM=; b=fDOdfYndLmwdf9gzK98sfyg4rdoZNd+dnaCDUtmpp/TIT85qTMEBVtkC9t7fL83PIT yrn5c0mrAoYtWUcqy7nBleawe+zshN1blP4Dqau//gfqqG1pKZjmMoACOzaV7LRioXOv JJiLCZqjyLt8P/Pq/I5NnkOQYZpeKpZLwxpMtiNLvlPztuP1u0jF0HuKUZCVM0bQbewA NLRb/rR/Ahr2BpYgiKbb7a01h+ajhAlH0as+DoAdU9/dib2Ww+3wib4KrSyeF9ACfQ6O h5Anpf31Y1O26lAd4ir2ZoyuSLdkljSE5GytWyp6Y6PgTxMpbDS2aXqFoZdh/KBLs49c xn4A==
X-Gm-Message-State: APjAAAXQdQHy9xGVPMzV1J6avxizVj0JYzAuNloq9J1cCeAH1LDeCpgx 5pqfGZrf+xNVgrUr8j/neQ6U2blB0WKqcCTo2zw=
X-Google-Smtp-Source: APXvYqxSmKJ/nprfRmkoV/hdcHXt2r8T6Tk0XJ+nRPsP02UR1+gdFe5kScm10LaQAWfVjNqWqdmdV+gkaOeZR4GHPSM=
X-Received: by 2002:ac8:234a:: with SMTP id b10mr6355277qtb.261.1565152167042; Tue, 06 Aug 2019 21:29:27 -0700 (PDT)
MIME-Version: 1.0
References: <VI1PR0501MB225515FC68BD4CBF7C6F904E83C50@VI1PR0501MB2255.eurprd05.prod.outlook.com> <CACsn0ck3AhxHeu6=vAf9CMNLJcjkC59jhWDdGD-RP03DNqCfXA@mail.gmail.com> <20190723042811.GL99187@kduck.mit.edu> <VI1PR0501MB225501B52DC40DC41E6D590683C70@VI1PR0501MB2255.eurprd05.prod.outlook.com> <DM6PR11MB33855C114392B1A400D4C0B2DBC70@DM6PR11MB3385.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB33855C114392B1A400D4C0B2DBC70@DM6PR11MB3385.namprd11.prod.outlook.com>
From: Jonathan Trostle <jonattr@gmail.com>
Date: Tue, 6 Aug 2019 21:29:16 -0700
Message-ID: <CAB+1-SckMT6oSJPbuM4fvWqC+8vGVUSYg-qTMt+i4EHBbbn64A@mail.gmail.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
Cc: =?UTF-8?B?QmrDtnJuIEhhYXNl?= <bjoern.haase@endress.com>, Benjamin Kaduk <kaduk@mit.edu>, Watson Ladd <watsonbladd@gmail.com>, "hugokraw@gmail.com" <hugokraw@gmail.com>, CFRG <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000efa290058f7f6265"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/uA5MA9vf3wYH3djA816wRlSSz8A>
Subject: Re: [Cfrg] How to circumvent the obstacles for PAKE integration into TLS // slides.
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Aug 2019 04:29:31 -0000

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
>