[VoT] Security Problem with Primary Credential Usage

Chris <cnd@geek.net.au> Sun, 08 May 2016 12:24 UTC

Return-Path: <cnd@geek.net.au>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E4F9212D09C for <vot@ietfa.amsl.com>; Sun, 8 May 2016 05:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.593
X-Spam-Status: No, score=-4.593 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_IADB_DK=-0.095, RCVD_IN_IADB_LISTED=-0.001, RCVD_IN_IADB_RDNS=-0.235, RCVD_IN_IADB_SENDERID=-0.001, RCVD_IN_IADB_SPF=-0.059, RCVD_IN_IADB_UT_CPR_MAT=-0.001, RCVD_IN_IADB_VOUCHED=-2.2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=geek.net.au
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QUNRqs_SpK63 for <vot@ietfa.amsl.com>; Sun, 8 May 2016 05:24:30 -0700 (PDT)
Received: from srve.com (srve.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E44912B021 for <vot@ietf.org>; Sun, 8 May 2016 05:24:30 -0700 (PDT)
Received: from [] (nsa.emsvr.com []) (authenticated bits=0) by srve.com (8.13.8/8.13.8/CWT/DCE) with ESMTP id u48COM1S029714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 8 May 2016 12:24:24 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=geek.net.au; s=20131023; t=1462710265; bh=FtO43k7lH3U/7sv92mbfbXR3peP4BwuMp8bpm1YDYPU=; h=Date:From:To:Subject; b=NFOPHD5ovIbaNC5HRVDBjHHFkgcN/CmzJeQ3v6Wcg197ZETYEt+2z18S+M/rmsh8K r2JEQ2MxMUMi/+EcH53szL9dEqW5fnx1sbfUeORrxO0QSafhDo1uVmP8MkpLL4mS4T p3dBI2xWvVt/A0bM/3zLDW3c14DRmnWtYPxqrN1EU+Qy00ZrDti5nPhFui0FsU/W11 uPOU/hdXNUeAzDbg+fLTRhzc2RaSUR9qMVpxvutxdq+4lCR/tUKsAyp07TJhJwpOT0 S81ndyHQ+UxAW/SjcPFEKdBULKphJMjaKUoWvHdj5aO/Dn9wFPMjx+97lGfI5Ars9K 6viwX5oyt7P5w==
Date: Sun, 8 May 2016 22:24:27 +1000
From: Chris <cnd@geek.net.au>
X-Priority: 3 (Normal)
Message-ID: <1523279479.20160508222427@CryptoPhoto.com>
To: vot@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------12616C0D522B73CB1"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRWlGSWpSXmKPExsVSMX3BPN2PevrhBndPyFucXr2b2aLh5wNW ByaPJUt+MnnsuvGYJYApijUzLym/IoE14+Zp4YLpGhVfW/6yNTA2KXUxcnIICSRL3F55j72L kYuDRWAKi8T2Rx3sIAkWARWJ298es4LYbAKyEtMbPjGD2BICYhIT1v0Cs3kFzCW+HlzMDjFI SeJu7wYwW0RAQKJn8Q8wWxioZn53NxtEvaDEyZlPWEBsZgEfidY/D1kmMHLPQpKahSQFYetI 7Nx6hw3ClpfY/nYOM4StLfHg/moU8QWMbKsYhcpyzRL1klOLSlJzEzNz9JLzczcxAoOqnoGB cQfjy6MehxgFOBiVeHgrqvTChVgTy4orcw8xSnIwKYnyujIChfiS8lMqMxKLM+KLSnNSiw8x ynBwKEnwcurrhwsJFqWmp1akZeYAowAmzcTBeYhRgoNHSYTXEaSGt7ggMbc4Mx0if4pRUkqc lx8kIQCSyCjNg+u9xCgqJcx7Vg0ox1OQWpSbWQIRf8UoDnShMK8TSBdPZl4J3LRXQIuYgBbJ sYEtKklESEk1ME51LHvR2HbqcsfKf/Lvd7x4/zcgs32Be+OlbV6moVmcx7kW5nF+vbJiqXD9 6QuvJq+23Vr72Ojm7inV6s+d9ggvKw0QC71z++iJq5UaDCtWVYnfvS391DX106ZHVjeSbC15 NviW/3TIelW36aWIlJD6jksi1uoN7X8WhBX5H9nRrh2gXub4RFWJpTgj0VCLuag4EQBuL4/r rAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/vot/hsJsJ2yx7ASpLN2iCBblVbhWMlk>
Subject: [VoT] Security Problem with Primary Credential Usage
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 08 May 2016 12:24:32 -0000

Hi All,

I think there is a critical flaw in section 3.2 of https://tools.ietf.org/html/draft-richer-vectors-of-trust-02 (Primary Credential Usage)

Mutual-authentication is missing.  When no provision is made to prevent man-in-the-middle, credential harvesting, spoof, phishing, malware, or other common threats, this renders all possible vectors C0, Ca, Cb, Cd, Ce, Cf, and others equally untrustworthy.

We should consider inclusion either for the overall strength of the authentication process, or some breakdown of either all the techniques used or the strength of protection employed to thwart at least common attack scenarios.

This problem gets tricky quite fast:

Do we identify the authentication technology vendor? (if yes - who works out their resistance strength to common attacks?  what about different modes?)
Do we broadly identify the techniques (whos opinions count as to whether or not the technique is effective and against what threats?)
Do we identify or classify the threats and indicate which ones were mitigated (who should be trusted to decide if these really were mitigated?)

For example - tamper-proof hardware digital certificate devices with biometrics unlocks are totally useless, if the user paid no attention to a broken SSL warning, or has malware.  They're also equally useless in most corporate environments that use deep-packet inspection firewalls - and "unexpected certificates" (eg. from DPI or malicious) carry their own privacy problems (eg: passwords are not as "protected" as you think).  Much more common authentication "protection" of course, are two-step or sms one time codes - which are equally useless when an end user can be tricked into revealing them to spoof sites.

91% of successful break-ins start from phishing.  Right now, every vector is pointing one way - we need at least one "Vector of Trust" to point back the other way!  

How about a 5th vector - "S" for "Security", which somehow allows an RP a level of confidence in the protection afforded to the user's actual authentication process, in terms of (or at least considering) a wide range of (and all common) modern threats.