Re: [VoT] Security Problem with Primary Credential Usage

Chris <> Fri, 13 May 2016 00:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5AF8512B02F for <>; Thu, 12 May 2016 17:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xO9tLzXQuY_m for <>; Thu, 12 May 2016 17:57:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 763E912B009 for <>; Thu, 12 May 2016 17:57:50 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8/CWT/DCE) with ESMTP id u4D0vaJq023928 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 13 May 2016 00:57:39 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20131023; t=1463101061; bh=IV/5Yh5Z3IpXFIRxgb7xN2lVBP1aOf8paGOiIT4/NSM=; h=Date:From:To:CC:Subject:In-Reply-To:References; b=Rj6INKL1hKPCZWWWWuHPu+b7nT/v+Y9CWq+j/KeJyRJdsYCvr1omlFBV/OcT1X1uT I6viFJEoSAdEppWvUMoFYRTkrk4ZF13l9FVUYh65TmZTjMkA+o4GQ4g0sT5R4LKezz 1yDdhsHLpwYGKLvHTILtFtUODx08Jm10Ae2ftA8uHNOfsA9BYZbC5mfdwV5CHl1doU 3qMrRsy/1neKnkhInndZY6QBo/58tPDnOn6+Wtavty6H7B+LVTsKfmgnwPAeBzo3rU +rgY6/1s2dO6l/Nw56ojf5NeK7LdPthyTRYsw2XGAHpCD2tSbOyg1FoPMVrZDKoo+G 0FZirgXr+OSeA==
Date: Fri, 13 May 2016 10:57:43 +1000
From: Chris <>
X-Priority: 3 (Normal)
Message-ID: <>
To: Julian White <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------00F127190360078A7"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRWlGSWpSXmKPExsVSMX3BPN1MVdNwgzm/LCxOr97NbLHh2ktW i/XrTzFaNPx8wOrA4rFkyU8mj6YzR5k9Wj50sHnsuvGYJYAlijUzLym/IoE1492DdraCXVEV f2f9Zm5gXOvTxcjJISSQLHFyw0rmLkYuDhaBdSwSr7s/M4IkWARUJRa8OsoKYrMJyEpMb/jE DGJLCIhJTFj3C8zmFTCXaFy2jx1ikJLE3d4NYLYIkH22eyVYL7OAocSN821gcWEBR4n/zSeA bA4OToFAiZOXgkH2Cgl8Z5Q4uvAAE8RMQYmTM5+wQPT6SFzdfJ5xAiPfLCSpWUhSELa6xJ95 l5ghbHmJ5q2zgWwOIFtNYlmrErLwAka2VYxCZblmiXrJqUUlqbmJmTl6yfm5mxiBQVzPwMC4 g/HlUY9DjAIcjEo8vAlKpuFCrIllxZW5hxglOZiURHltP5iEC/El5adUZiQWZ8QXleakFh9i lOHgUJLgrQXGjpBgUWp6akVaZg4w6mDSTBychxglOHiURHibQWp4iwsSc4sz0yHypxglpcR5 z6gAJQRAEhmleXC9lxhFpYR5J0sB5XgKUotyM0sg4q8YxYEuFObtABnHk5lXAjftFdAiJqBF 1deNQBaVJCKkpBoY47Y0HnfMk16n8FLrkuKji6kZ66uDpivYrPopuHVqR2Jx+KGAKR03omZe Zahuvfe2M/W6lM6PXplJc7N0PXl3iPEwdURnaTJKdj5133K93jd1xa2Y3qUR7B9ZjKZfbZd3 z6pcEh0uo5ERH8KxwNR1rbFl4kMVxY/LVthm/5wz2VpauWmzq4kSS3FGoqEWc1FxIgArQl0t 5AIAAA==
Archived-At: <>
Cc:, Justin Richer <>
Subject: Re: [VoT] Security Problem with Primary Credential Usage
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 May 2016 00:57:52 -0000

Hi All,

I think this is unreasonable.

Trust is a two-way street.

The standard will be more-or-less useless to everyone when half of the necessary trust system is excluded/out-of-scope.

Decisions related to trust need technical data.  If I'm relying on an IdP - it makes a difference if the user typed a 4 digit PIN over HTTP, as opposed to using a biometric multi-factor auth over TLS with HSTS & Pinning with included anti-spoof and anti-malware protection.  "What went on" absolutely needs technical inclusion.

Kind Regards,
Chris Drake

Friday, May 13, 2016, 4:49:16 AM, you wrote:

That makes sense, tho that didn't come across in the description of the trustmark.
On 12 May 2016 19:45, "Justin Richer" <> wrote:
We explicitly left those kinds of things out of the vector as they’d really be related to the IdP itself and not the authentication transaction to which the VoT refers. In other words, the security of the IdP is related to the trust framework and assessment of the IdP and it can be published as part of the IdP’s discovery documents and associated trust marks. This is information that is going to remain the same regardless of the transaction. 

This is also part of why you need to have a trustmark context to interpret the VoT in.

 — Justin

On May 12, 2016, at 11:11 AM, Julian White <> wrote:


I have a number of comments and questions (see attached), many of which are related to the issues raised by Chris, some maybe my misunderstanding coming in half way through the drafting tho.

I, like Chris, also think there needs to be something more explicit around the "security" of the IdP authentication which includes the measures to try and detect 'odd' things (like MITM). I would also go one step further in that I also want to know about the maturity of the IdP's "security", its of no use to me if they have really good credentials but store all the data in the clear on their website or have a load of administrative back-doors that could let anyone generate a valid authentication response.

It feels like we need to do more work in this area.



On 8 May 2016 at 13:24, Chris <> wrote:
Hi All,

I think there is a critical flaw in section 3.2 of (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.


vot mailing list

vot mailing list