Re: [VoT] Vectors of Trust I-D feedback

Jim Fenton <fenton@bluepopcorn.net> Tue, 04 August 2015 14:27 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C2D1A000E for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 07:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mUYzyPZOxELe for <vot@ietfa.amsl.com>; Tue, 4 Aug 2015 07:27:39 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9A01A1B1C for <vot@ietf.org>; Tue, 4 Aug 2015 07:25:14 -0700 (PDT)
Received: from splunge.local ([216.9.110.11]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t74EP9i8014499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 4 Aug 2015 07:25:10 -0700
To: Rainer Hoerbe <rainer@hoerbe.at>
References: <569AD906E45DB44A8AFF11D61F5DA791014ADE44CF@WLGPRDMBX02.dia.govt.nz> <39A67012-222A-4C23-B92A-B7AB55744B2D@hoerbe.at> <55BA14B2.3070105@mit.edu> <C9563753-E9E2-4990-9B7C-3AFEE232BD01@hoerbe.at> <CABzCy2AUA4ycTcj0-kgu_YaceduJRJYjruXs=X2zE1nowryGEQ@mail.gmail.com> <55BFEBC2.7070209@bluepopcorn.net> <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at>
From: Jim Fenton <fenton@bluepopcorn.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <55C0CB49.5010104@bluepopcorn.net>
Date: Tue, 04 Aug 2015 07:25:13 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <10CB72ED-E445-4972-A851-D311FD5F883B@hoerbe.at>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1438698310; bh=HxhwXgnMF7lusQ5clhYAr4gErwgjreSuiA5yG2I1keY=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=XSs0bjT8MPKgSd0jLkfUlEe7xYMIqKIz8yph/v1rZSsi6m4XIASr9uV4GR6+lyGkv d7PzPchiDXlf2RRFBsgPVisXaMjI+mikQBT8If3U+YneN0kzN27HI6MzC1hG454Jo7 Pe0F585Nq+vUZuItnflelP+aUFrO/i9uo7oFmA8s=
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/VOUeWoDPaT_SZ6VP0qmLAvIKk_U>
Cc: "vot@ietf.org" <vot@ietf.org>
Subject: Re: [VoT] Vectors of Trust I-D feedback
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Vectors of Trust discussion list <vot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vot>, <mailto:vot-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vot/>
List-Post: <mailto:vot@ietf.org>
List-Help: <mailto:vot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vot>, <mailto:vot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 14:27:41 -0000

On 8/3/15 11:12 PM, Rainer Hoerbe wrote:
> Am 04.08.2015 um 00:31 schrieb Jim Fenton <fenton@bluepopcorn.net>:
>> To be entirely consistent with ISO/IEC 29115, we would need to rename Identity Proofing as Enrolment, and Credential Usage as Authentication.
>>
>> But ISO/IEC 29115 refers to these as phases: they occur at different times (or, in the case of Credential Management, over a long period of time) and have different threat models. But I would like to ask under which circumstances a Relying Party would act differently to an indication of less secure Credential Management vs. less secure Authentication.
> For a targeted attack the weak credential recovery will lower the adversary’s effort significantly, whereas in large numbers a 2F AuthN combined will still reduce the overall risk.

I have trouble understanding how an authentication with weak credential
recovery could ever be called two-factor.
>
>> There are credential management practices that would make a credential unsuitable for highly secure authentication, but why not just represent that as less secure authentication? VoT should be only as complex as required; it should not represent aspects of the process that the relying party does not need.
> +1. However, I remember a discussion at IIW where someone argued that an important use case for VoT is the combination of C4 (U2F) with  P1 (self-asserted) for social ids. But social networks are prioritizing usability over security with a weak recovery mechanism.

We need to make sure that it's clear to everyone that a recovery
mechanism is just another way of logging in, and if it's weaker than the
primary login method the authentication is weaker overall.

-Jim