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

sakimura <sakimura@gmail.com> Tue, 04 August 2015 06:42 UTC

Return-Path: <sakimura@gmail.com>
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 75ACE1B365E for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 23:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no
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 AnnGLSWA80Td for <vot@ietfa.amsl.com>; Mon, 3 Aug 2015 23:42:33 -0700 (PDT)
Received: from www.sakimura.org (www.sakimura.org [52.69.28.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EEAC1B365C for <vot@ietf.org>; Mon, 3 Aug 2015 23:42:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) (uid 33) by www.sakimura.org with local; Tue, 04 Aug 2015 06:44:19 +0000 id 00000000002437C1.0000000055C05F43.0000561C
To: vot@ietf.org
X-PHP-Originating-Script: 0:rcmail.php
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Date: Tue, 04 Aug 2015 15:44:19 +0900
From: sakimura <sakimura@gmail.com>
In-Reply-To: <10CB72ED-E445-4972-A851-D311FD5F883B@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>
Message-ID: <b7ac111fe780ea9a3949cd2ce0890967@imap.gmail.com>
X-Sender: sakimura@gmail.com
User-Agent: Roundcube Webmail/0.9.5
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/mGx3ePYfj4cQ9un7gRNDSQmkXzc>
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 06:42:34 -0000

2015-08-04 15:12 に Rainer Hoerbe さんは書きました:
> 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.

Actually, renaming it as Enrollment may have some merit. Identity 
Proofing is only a process within Enrollment.
There are whole bunch of other stuff that has to happen then.
Even if the Identity Proofing was done perfectly, if the act of creating 
the record to the identity register is broken, it is broken.

>> 
>> 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.

+1. That is one of the reason I feel it is worthwhile to differentiate 
them.

> 
>> 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.

In private sector, there are lots of cases where identity proofing in 
the traditional sense does not
matter but the secure authentication matters. I actually co-authored a 
paper on it last month.

> 
> - Rainer
> 
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot