Re: [Cfrg] aPAKE Analysis / Why System-Level-View

Björn Haase <bjoern.m.haase@web.de> Sun, 22 September 2019 19:31 UTC

Return-Path: <bjoern.m.haase@web.de>
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 62B0312002E for <cfrg@ietfa.amsl.com>; Sun, 22 Sep 2019 12:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.858
X-Spam-Level:
X-Spam-Status: No, score=-1.858 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, RCVD_IN_SBL=0.141, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=web.de
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 7vkqB-_5zvzu for <cfrg@ietfa.amsl.com>; Sun, 22 Sep 2019 12:31:23 -0700 (PDT)
Received: from mout-xforward.web.de (mout-xforward.web.de [82.165.159.35]) (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 9263A12000F for <cfrg@irtf.org>; Sun, 22 Sep 2019 12:31:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1569180677; bh=vj7joQ6lIoSKYytl2lipIKfro50QGIWSYP+wxeo02Yg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=cBqhVl3WlmkhRowRRVm0MejD7vl7r4mRRVCj9KEWhXz0brpaCA+C5oxhjMeX+UKEI QVMDOO4ZK7SiqMBaztQRbC5YsWXF1gK0zARArqavvX5Xxb7L/hIoFRGkqI4/rKX6WX pYXZGA3CqSJ4QiNCBwzrIcCKB0xnjcumv9v3D57w=
X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9
Received: from [192.168.2.161] ([94.218.65.48]) by smtp.web.de (mrweb103 [213.165.67.124]) with ESMTPSA (Nemesis) id 0LtWwK-1i22wz2JqG-010x3I for <cfrg@irtf.org>; Sun, 22 Sep 2019 21:31:17 +0200
To: cfrg@irtf.org
References: <VI1PR0501MB22558468E3C0549F452736CC838E0@VI1PR0501MB2255.eurprd05.prod.outlook.com> <CACykbs2-4XVJKZU_f90QN42XH-ec1HoUx02ts19gd3=AjjYTCA@mail.gmail.com> <CAAt2M1-zVqxQNQSts6PZmQrC7dcK4RKdn4vHKh_MeOAAK-=aPg@mail.gmail.com>
From: Björn Haase <bjoern.m.haase@web.de>
Message-ID: <8f1cca24-ee64-7999-58bb-b4c206284716@web.de>
Date: Sun, 22 Sep 2019 21:31:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAAt2M1-zVqxQNQSts6PZmQrC7dcK4RKdn4vHKh_MeOAAK-=aPg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:14utYmTUG5T5oQCO/+YR241+n3i5lFN1HTfJWX3V7UDiL442Go9 f+pQkgeGbHNSC7jFI9vknDCT4E7VEMJEfzFBwyKOExOCGsuaBlPQ73/lFdVO2T8Ixdrmh+k R7xvsrfe+JloXVkOp57/yMnog9noJTs47EsrHTZDFdFsvG9MgZVhQUeoWxtY5UbXTx2RALj lnkzuVtEoiaad440dy8Jg==
X-UI-Out-Filterresults: junk:10;V03:K0:cXUOjhJDtZQ=:ke1ySA4PKkCSFwA2anRXfxQm CMHFyrG2cCxEArU2D5zIW5dWc6wvsCxdeAuc1TGdrsiDHYiYsJMUHRavLbycXEPPRc0pb7GVV BrbuFNpYySWPShIVZua3WrCOlO5mcmdsYFMZ44k1SvdLU5nqqmK6TvbgQapQiIrH5iKXXovhN Q5Nv1uRpMbezpwtVHVZ2DmTlPK0ZfPYwrrrYBzi3pimpuQfU9wYizy27l2IRkgUg5155a+ydb t3e8fhtBLWEqinaEEkSX7/hlORW+QggjDwrfJAorrfgOkoKUI5s7fnzMM8gRDW+hI/XbvFAyz MiQ8MCpX2vEho0wL5ncwq+lvGYR8z4044TwmydbZgtwQeDEIq0XzxhazygOAnaUrkW4/0JTss h/Eu6spSRdCwYY2Ltd9MXuSMUrQMdIwVdjN8G+V9iCrWokwvMqBVCIRekpbhsMZC9JVJe9Rf7 PVY1VMqxWTP9jhsAPZGHwURoAkTAOOePiRSBTwhI+LaWhN4Rh2WmeD/ErFJT44ary9agn4ym7 wdrrF3alWaiygaXNjaydlqez1+arnoTzF80BriOoRdoZOYhNWTUSLb7/yMHR4ZUIqH8PxIi7J VLILShr4lSVhjfXQMAEjeBj79RzjAzO3s6EG/77lx56+dStBJXXKM/77AkSgZh4t5B7CuIWLU MhXhenzJDYx0OxuyJUi9cZ6PfqrvlBrLOsTNzvWabLbs9GshpZlsHduiDgmI2V/5+NCUXsNv3 G+r9OD39pZ8av3V11/BtvqQYmKL24IfsIMPYbaP07MB/h6dHoUTuX9213PjEj9Jm4dgNssQ6C xQB5cfBlfCXBB+8OWlkLtFCse7uowxI9PixVzTDVoJijGczosa7RQMAABY3PN6r1f3+tr9T9/ MvN5d9xeBWcocO7ztIW+PmktwEoH32wgwzlDtbx4+uPhRiZco+teYHfGqA5oGjbAY1XE6NTj4 FN5BL01MhZWzOqbTVGSxawZZ8qv3TluCxsGjEKAC9JzfV4zMfLZQmSnGjw1ErESJmctq/pwPl G2YLjurpZbSuH1A2fqy/dzz0eIKW5y5RBIezjv2IhQ9efAM36AtJEttz3Jc8tT+lz6B9uN6oC FXLv54LrSBOOTgzaudKIS0MuxRywZjMHpPTkM7sXRHKBPkfaVXkOYqqAr9lYloOtcv2mcFx6d c0qoaorvLmE8BbuZNLO9Ta1j3+tJBGS7NHQpYMUqygtVTTyOXcHWIaxIKevueW9BOFrW1RZ1J 24SgxBYZgP7+Hf0/cv+QfBjyFF9t3G/toTCAXStD23MvNhf1/o9MF6ei6A=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/OdyRufff7E7BwsdpfDADMYghQOc>
Subject: Re: [Cfrg] aPAKE Analysis / Why System-Level-View
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: Sun, 22 Sep 2019 19:31:24 -0000

> Being able to trigger a PAKE from a button press on your 2FA hardware
> token would also be a significant UX improvement over many of the
> other options with similar security level.
>
Do I correctly understand that you had in mind: The user first
establishes a normal https:// connection and then presses the 2FA
hardware switch in order to run a PAKE in addition to the previous
certificate-based authentication?

This is not what I assumed. What I had in mind is rather the following
procedure. The server knows its requirements regarding security, etc. .
The user and the browser don't know the required procedure in advance
when connecting. If the server is needing 2FA, it would arrange the
client to provide the aPAKE password entry mask and provide a "Please
press authentication token switch for authentication".

Did I actually mis-understand your post?