Re: [jose] Security Evaluation Request

Anders Rundgren <anders.rundgren.net@gmail.com> Tue, 10 July 2018 05:58 UTC

Return-Path: <anders.rundgren.net@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362BA130DFA for <jose@ietfa.amsl.com>; Mon, 9 Jul 2018 22:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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_DNSWL_NONE=-0.0001, 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 3MmIcgZQqkem for <jose@ietfa.amsl.com>; Mon, 9 Jul 2018 22:58:57 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 24057130EDF for <jose@ietf.org>; Mon, 9 Jul 2018 22:58:57 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id w16-v6so23173813wmc.2 for <jose@ietf.org>; Mon, 09 Jul 2018 22:58:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=vocx+SbwS9Qwo5Kq4K5MkNWdlFYyMq6Px4jdGhEr2Gs=; b=avQiP0b9Vjc4ci23noJmWxEH/nWGDXEe0edcFLHrzvEGNQy0QaWve+wgG4ao5acS95 NOT1Ju3M6K15gcSYwjAV+Fhkieu4bjs+FbtsfyLFguDfb3ocK0VmPhG/+2y7OD2bQJDy OatgdQtdPnkxbcN6/chqJEsqPOoavyWAkpVJk1VKpqERWfFSvBf2JJnRM+o5xCMuqLcC WzwBihLD+kNZBnE//JaFjMe+ERnfqHTcSn+w4Tn/Zva8hsMmhYXoHehkn/AbExZoM+Zx oYUKy/q8JuqQasrsQ2OChnb/08xFkXE7RbEvS5ScSViLkMUEy+Vn/lFlyWw8JbmH5aXs gWZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=vocx+SbwS9Qwo5Kq4K5MkNWdlFYyMq6Px4jdGhEr2Gs=; b=WtDBhai27ylP78+hT1xvaVJRJI7cB3vUfbls/99QTq1UDE9jwh8YmGCq8J8aeeGYLH 8jLb6lakHX+ZaPF3qb2wCCVFvpmSiNXxTj82YR0CA5MRwjxFIqSrrrOg34nhHnT7Znln lJh5+2J1FdshGSEmz7NZ0boyN6ZLCCOY/pu8umMGiyT+sfnhJ23oopXv/jZdmID03+fJ aWm+5CZXvnfxJo9/6q1Xstl/mUde458ksXKDytqF/sGHC8D4YZcO1Nm7r8IU4iiQk82J QbyErVwqnvZlnXyQr0E92w0+25sWc28lqTysNxipY0DS5Xr8jB9dK4Vq/IaIgy9Qajkm C6LA==
X-Gm-Message-State: APt69E3s/zPdmQf3pJ8vk5yz9qg672UDFN+tdAvAns2DN5u39+FfByaa Ket5C5ud9h6eKw0rt/VTZ6+ubQ==
X-Google-Smtp-Source: AAOMgpfCx0q5mYR/NgwkW3+1xPXOguugWFIq4OZX7EeFRdBI+xQVC2vhNwLAa1TgoTIf4Okd1BCTtQ==
X-Received: by 2002:a1c:b94c:: with SMTP id j73-v6mr14964590wmf.104.1531202335045; Mon, 09 Jul 2018 22:58:55 -0700 (PDT)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id 73-v6sm2622409wmu.37.2018.07.09.22.58.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 22:58:54 -0700 (PDT)
To: "Manger, James" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
References: <39b09bfa-1ff5-c47d-7dd8-8944eeee9189@gmail.com> <MEAPR01MB354279C123290AA06D1BE78AE55B0@MEAPR01MB3542.ausprd01.prod.outlook.com>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <48e2075b-b3a1-9347-eef5-3991c47666a8@gmail.com>
Date: Tue, 10 Jul 2018 07:58:53 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <MEAPR01MB354279C123290AA06D1BE78AE55B0@MEAPR01MB3542.ausprd01.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jose/poirtOfTjIZ3a9L3v2MDmRX3Z4o>
Subject: Re: [jose] Security Evaluation Request
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 05:59:00 -0000

Hi James,

Thank you very much for looking into this!

To begin with neither mine nor FIDO/W3C's scheme actually work for the simple reason that NFC in PCs died due to "malnutrition".  For FIDO a somewhat less convenient but workable alternative ought to be using BLE or USB cable.

The W3C/FIDO scheme does indeed not have the same [potential] security issues as my [1] scheme since it builds on "in-line" authentication, so why would anybody in their right mind bother with an OOB scheme?

Well, believe it or not, there are still people out there using client side PKI.  Most of these schemes build on a rather different model compared to FIDO where the entire security operation (including UI) is delegated to the mobile device, creating a unified system [2] for Mobile Web and Mobile+PC Web interactions.

This GUI "emulator" of a system in the workings, should give you an idea of what I'm talking about: https://cyberphone.github.io/doc/mobile-id/ui-demo/

The OOB scheme and associated unified UI would obviously work (assuming it isn't broken NB...), for FIDO as well since it was designed to be "neutral".

Cheers,
Anders

1] NFC version of schemes already deployed on a massive scale in for example Scandinavia.

2] The Saturn payment authorization scheme (https://cyberphone.github.io/doc/saturn/) is another example, making POS payments and Web payments identical through the use of high-level protocols rather than ISO 7816 based card protocols.

On 2018-07-10 02:28, Manger, James wrote:
> Hi Anders,
> 
> Isn't FIDO2 (aka W3C Web Authentication + CTAP) with an NFC authenticator a more thorough version of your site-PC-NFC-mobile scheme?
> Both have communications from a site to the PC/browser then over NFC to a mobile that has a crypto key. FIDO assumes the browser checks the web site authentication; your scheme has a "Web NFC driver" to do this task.
> The communication channels in the reverse direction are different: FIDO re-uses the same NFC channel; your scheme uses the mobile's own network. But as the security comes from the mobile's private key, there seems to be little benefit from having a separate channel - only a downside if it isn't available.
> 
> [1] DRAFT W3C Web Authentication; https://w3c.github.io/webauthn/
> [2] DRAFT FIDO 2.0 Client to Authenticator Protocol (CTAP): NFC; https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-client-to-authenticator-protocol-v2.0-id-20180227.html#nfc
> 
> --
> James Manger
> 
> -----Original Message-----
> From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Anders Rundgren
> Sent: Monday, 9 July 2018 10:17 PM
> To: jose@ietf.org
> Subject: [jose] Security Evaluation Request
> 
> If there is anybody out there interested in Web security schemes relying on OOB channels, I would very much appreciate a review or just comments:
> https://github.com/cyberphone/qr-replacement#a-better-qr
> 
> If you wonder who actually use such schemes, they currently involve a billion users or so although most of them are about payments rather than user authentication.
> 
> This posting is also meant to serve as a defensive publication.
> 
> thanx,
> Anders
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>