Re: [VoT] Missing RP / IdP authentication entirely

Justin Richer <jricher@mit.edu> Tue, 28 November 2017 11:00 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: vot@ietfa.amsl.com
Delivered-To: vot@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB95126C23 for <vot@ietfa.amsl.com>; Tue, 28 Nov 2017 03:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 LZVA9xk4U4lA for <vot@ietfa.amsl.com>; Tue, 28 Nov 2017 03:00:21 -0800 (PST)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42564126BF0 for <vot@ietf.org>; Tue, 28 Nov 2017 03:00:21 -0800 (PST)
X-AuditID: 12074423-7bfff7000000581f-58-5a1d41c13c3b
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 9D.AD.22559.2C14D1A5; Tue, 28 Nov 2017 06:00:19 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id vASB0BiD007986; Tue, 28 Nov 2017 06:00:13 -0500
Received: from [192.168.100.121] ([90.102.70.148]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id vASB03gh014631 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Nov 2017 06:00:06 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <B80D5704-1F3A-4AC8-946C-547891AB6A2C@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FC37C6D-EEB3-487E-8CDC-2EBE7722B894"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 28 Nov 2017 12:00:06 +0100
In-Reply-To: <1327020467.20171128130110@CryptoPhoto.com>
Cc: Jim Fenton <fenton@bluepopcorn.net>, "Paul A. Grassi" <paul.grassi@nist.gov>, John Bradley <ve7jtb@ve7jtb.com>, Phil Hunt <phil.hunt@oracle.com>, "vot@ietf.org" <vot@ietf.org>, Leif Johansson <leifj@sunet.se>
To: Chris Drake <cnd@geek.net.au>
References: <201711280226.vAS2QFAF012604@outgoing.mit.edu> <1327020467.20171128130110@CryptoPhoto.com>
X-Mailer: Apple Mail (2.3273)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsUixG6nonvYUTbKYPFJMYuVn74zWnzrnMVs saB3K7PF8n45iwXzG9ktVt/9y2bR8PMBqwO7x9NVr5g8Lm2bwOyxZMlPJo9rJ/+yenx8eovF Y++mPnaP27c3sgSwR3HZpKTmZJalFunbJXBltLX+Yip4X1nx9eQB5gbGrtQuRk4OCQETiam9 M1i7GLk4hAQWM0lsbe9jgXA2Mko867zNCOGsZ5KYe+c3O0gLm4CqxPQ1LUxdjBwcvAJWEiv6 g0DCzAJJEudWbGCHCOtL9D5nBAkLC1hLTD2yBayTBajzw4cHzCA2p4CFxJ+zs8DGMwu8Z5T4 Pv8HWJGIgKLEpVf7WEBsIYEMia9rnjJCXCorcWv2JeYJjPyzkKybhbAOIqwtsWzha2YIW1Ni f/dyFkxxDYnObxNZFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI108vNLNFLTSndxAiOHBfl HYwv+7wPMQpwMCrx8L5wk4kSYk0sK67MPcQoycGkJMorYCwbJcSXlJ9SmZFYnBFfVJqTWnyI UYKDWUmEV9wCKMebklhZlVqUD5OS5mBREufdFrQrUkggPbEkNTs1tSC1CCYrw8GhJMG73AGo UbAoNT21Ii0zpwQhzcTBCTKcB2j4ZZAa3uKCxNzizHSI/ClGV45HN+7+YeLYcBNE7gOTz2a+ bmDmmHa1tYlZiCUvPy9VSpz3uj1QswBIc0ZpHtx8UIKMSnOb8opRHOhdYd4NICt4gMkVbsMr oOVMQMtv7pcGWV6SiJCSamCs43Ao46zY1bt4i/nRfUqcEauetzYuKGN5uez8RHOP8x1XvA0W Pjv7syXgNPsNS9bKqAu+ab78Ky6xzD/vptfBUeB6MnrO3h9JD9gE/0Yt9s+TyY8Ke+kbqb9S v9xMuUd1wgQXF+sjVv1NVVxOhgtecLCXezh9+fvq0L2pLxJKfq5nWtRbdEuJpTgj0VCLuag4 EQD2sA26awMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/vot/AJy_XIyniUIR7mrZPp_1ShHK2iw>
Subject: Re: [VoT] Missing RP / IdP authentication entirely
X-BeenThere: vot@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Nov 2017 11:00:24 -0000

Chris,

As I said, you can already communicate that the IdP is speaking to the user and not a proxy, and determining that is by and large the purpose of communicating the vector in the first place. In particular, the “C” component can tell you some details about verifier impersonation resistance in use during the primary authentication at the IdP.The “M” vector communicates how much you can expect that binding to last over time. Consequently, I’m not sure what you think is missing in the transmission capabilities. So using the NIST proposed vector definitions, you could have:

C2.Cm.Cv.Cs

Can you give me a concrete example of how you would propose communicating this instead?

I’m glad you brought up the concept of scope though, as I strongly believe in well-defined and limited scope for solutions. If you try to solve everything, you end up solving nothing. Trust and Identity is a *huge* problem space, and VoT is not trying to solve everything in that space. I believe the focus should be very specific, and trying to go far outside of that space is going to end up with a solution that doesn’t actually work. Instead, I think it’s more important and valuable to have point solutions that are meant to be composed. This is why the VoT value is explicitly anchored in the trustmark concept: from there, you can start to ask and answer the questions of how the vector should be processed, using technologies that are specific to the the channel that the vector was communicated over. If you’re doing OIDC, then you’re going to be using OIDC’s registration and discovery components to establish the base level of trust between the IdP and the RP. If you’re doing SAML, it’s the metadata endpoints for the IdP and SP/RP. After all, why would an RP trust anything from a given IdP, including a vector value? Solving that isn’t specific to VoT and is going to vary based on the technology, and we don’t want to tie VoT strongly to any specific identity federation protocol. 

You and I disagree about the value of VoT as it’s defined. Form my standpoint, it absolutely is improving the status quo for everyone who’s trying to communicate this same information using LoA. I also think that this needs to be combined with other elements to solve the larger problems.

 — Justin

> On Nov 28, 2017, at 4:01 AM, Chris Drake <cnd@geek.net.au>; wrote:
> 
> 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. 
> 
> --Justin
> 
> Sent from my phone
> 
> -------- Original message --------
> From: Chris Drake <cnd@geek.net.au>; 
> Date: 11/28/17 2:46 AM (GMT+01:00) 
> To: Jim Fenton <fenton@bluepopcorn.net>;, "Grassi, Paul A. (Fed)" <paul.grassi@nist.gov>; 
> Cc: vot@ietf.org, Justin Richer <jricher@mit.edu>;, John Bradley <ve7jtb@ve7jtb.com>;, Leif Johansson <leifj@sunet.se>;, Phil Hunt <phil.hunt@oracle.com>; 
> 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
> 
> 
>