Re: [VoT] Missing RP / IdP authentication entirely

Chris Drake <> Tue, 28 November 2017 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33E80128CF0 for <>; Mon, 27 Nov 2017 19:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.591
X-Spam-Status: No, score=-4.591 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_PASS=-0.001, URIBL_BLOCKED=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 v6WQJ-KbOo9w for <>; Mon, 27 Nov 2017 19:01:34 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AD3E124207 for <>; Mon, 27 Nov 2017 19:01:34 -0800 (PST)
Received: from ([]) (authenticated bits=0) by (8.13.8/8.13.8/CWT/DCE) with ESMTP id vAS31AcG023219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 28 Nov 2017 03:01:14 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20131023; t=1511838078; bh=iGmht38dp/4p6vPN/XSApBf6HmpVoq0bCZTAU9Jn1G8=; h=Date:From:To:CC:Subject:In-Reply-To:References; b=pOUyHnHsYvV7wZOOBY2ivBuQ6k3aDjmUlFzt5knqPBU73UvhProKj/rLLc7LH+CM3 6o8cscq0cpczni/CVfyc8W+XNlz+3IV2q4tos3V/7K96WCX7NQ1npRQyJGkN86YAJe zgxlKsAzDk7ETC3ceM+apiVAYFZrjNiEaHQK3XiuVlGthvYTMGKYLu8W1CZDz/gVT2 8jqxdASFHuG2RrrjOc/3mdXaVAJxnCQjGZ3u35D8NaFpEWxfoMq9z+uBThNcotVA5x L180637l4bpYaV0RCqmR4AeUeGP5U3WMLhE2A8Ap0Zy/ThwzbDrehJug6w3ulRm4b5 cusRtcU768jdQ==
Date: Tue, 28 Nov 2017 13:01:10 +1000
From: Chris Drake <>
Message-ID: <>
To: Justin Richer <>, Jim Fenton <>, "Grassi, Paul A. (Fed)" <>
CC: John Bradley <>, Phil Hunt <>, "" <>, Leif Johansson <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------02F1DA09129D2396F"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRWlGSWpSXmKPExsXS3XTyte63SzJRBi3XdS1Or97NbPGtcxaz xYZrL1ktFvRuZbZY3i9nsWB+I7vF6rt/2Swafj5gdeDweLrqFZPHkiU/mTyazhxl9rh28i+r x8ent1g8dt14zOKxd1Mfu8ft2xtZAjiiBCN0wzMyS1JzMotLrBRCgkJdEwQzvh7eylbwz6ai 999vxgbGo0ZdjBwcQgJJEisP63QxcnGwCKxjkbg+4SRTFyMnkKMq0fjmCjOIzSagLPHnzQRm kHpeAXOJiT/zQcJCAkoSd3s3sIPYIgJVEu+ad7KDzGEW6GCUePbkKytIQljAWmLqkS1gRZxA 9tpjM5ggmq0kOhqngNm8AoISJ2c+YQGxmQV8JBbfOcA6gZF3FpLULCSpBYxMqxgFi3PTiwv0 igsSc6sSC/SS83M3MQIDtp6BgXEHY1Nb2CFGAQ5GJR5eCyeZKCHWxLLiytxDjEwcnJcYzThY hPiLK4vjE3Ny8svjU3MTM3OEWPLy81KlhHkZGRgYhHgKUotyM0vii0pzUoth0SXVwBj8SuSx nqeGRNLXs0nl567P5nUpzL0Udu/ky5RftpND3nX/7y5jKz69RL/t1nOzhUfT9FYxv92cu+HL ffX+egNZ6dPfjx1zNE/NUa5kd6xaZ7F2e6XbmU1Nx3YlHeK/6P5znsv3SSpZX3JZDpvwl39R +K/E/vj1L8+foX9sb+Zu+9Ts8Idh01klluKMREMt5qLiRADIuoueVAIAAA==
X-Whitelist: TRUE
Archived-At: <>
Subject: Re: [VoT] Missing RP / IdP authentication entirely
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Vectors of Trust discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Nov 2017 03:01:36 -0000

Hi Justin,

This spec seems doomed to repeating the mistakes of OpenID - all the stuff they shoved into the "out of scope" basket came back to haunt them almost immediately.

Trust is a two-way street.  You can't call this "VoT" if you explicitly exclude half the trust.  VoT brings nothing if it has no desire to improve on the status quo!

" communicating the state of the transaction from the idp to the rp " *absolutely requires* that the RP has confidence that the IdP is communicating with the user and not a proxy.  This is a concept (impersonation resistance) not a technology (embedded hardware certificate devices) - VoT offers the chance for this vector to be communicated outside the vendor-obscured lines of technology.  If it's not included, communicating a valuable bit of state information (and one that's near-universally exploited in the wild!) is not going to be possible.

Kind Regards,
Chris Drake

Tuesday, November 28, 2017, 12:26:12 PM, Justin Richer wrote:

This spec isn't about solving primary authentication to the idp, it's about communication the state of the transaction from the idp to the rp. As you observed, this is very explicitly and deliberately about the user, not about the systems. We considered adding that kind of information in early on, but it was decided that such issues are better solved by discovery and registration protocols. VoT isn't the right tool for that, and any complete solution is going to have multiple tools working together. It should be in a standard but not here, working at a different level. This is about users, not machines. 

Verifier impersonation resistance can be communicated here already as the vector's C value can describe that the user underwent an authentication process that meets that standard. NIST's implementation of VoT under 800-63 does exactly that. VoT doesn't say how to meet that, that's what the rest of 800-63 is for, on the NIST side. Other trust frameworks will have their own anchors. 


 Sent from my phone

-------- Original message --------
From: Chris Drake <> 
Date: 11/28/17 2:46 AM (GMT+01:00) 
To: Jim Fenton <>et>, "Grassi, Paul A. (Fed)" <> 
Cc:, Justin Richer <>du>, John Bradley <>om>, Leif Johansson <>se>, Phil Hunt <> 
Subject: [VoT] Missing RP / IdP authentication entirely 

Hi All,

Completely missing from the standard are any "two directional" vectors:

100% of the work here is user-focussed, with no attention on RP / IdP legitimacy - a huge mistake, since 91% of successful attacks against authentication take advantage of the completely-missing "machine to user" authentication step (e.g. NIST "Verifier Impersonation Resistance").

I can't decide if this needs to be a new set of vectors, or if it makes sense to incorporate into one of the existing ones:

*. Who is the RP, and how certain is the User/IdP that the RP is legitimate ?
*. Who is the IdP, and how certain is the RP/User that the IdP is legitimate ?
*. What steps has the IdP taken to ensure the users and RPs are not duped ?

What I am certain about, is that it needs to be in the standard.  It makes NO SENSE to put all this effort into something that addresses only 9% of the problem.  NIST recently fixed this, so should we.

Kind Regards,
Chris Drake