Re: [VoT] Vectors of Trust: A Strawman

Rainer Hoerbe <rainer@hoerbe.at> Fri, 03 October 2014 19:57 UTC

Return-Path: <rainer@hoerbe.at>
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 24C6F1A88E1 for <vot@ietfa.amsl.com>; Fri, 3 Oct 2014 12:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.335
X-Spam-Level: **
X-Spam-Status: No, score=2.335 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DATE_IN_PAST_03_06=1.592, GB_I_LETTER=-2, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=2.393] 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 sFSTasq7HnlJ for <vot@ietfa.amsl.com>; Fri, 3 Oct 2014 12:57:43 -0700 (PDT)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.36]) (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 B9C571A88DF for <vot@ietf.org>; Fri, 3 Oct 2014 12:57:42 -0700 (PDT)
Received: from [195.50.142.210] (helo=[172.29.10.161]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.84) (envelope-from <rainer@hoerbe.at>) id 1Xa8yv-0007lK-Ua; Fri, 03 Oct 2014 21:57:40 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail-3F7D32ED-4087-4E37-93C4-1C0BE3481E13"
Content-Transfer-Encoding: 7bit
References: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org>
From: Rainer Hoerbe <rainer@hoerbe.at>
In-Reply-To: <42FAEF9E-37A4-4F3A-84C0-63C1FBC22EC6@mitre.org>
Message-Id: <578DFE15-222E-4C19-9E69-691F36EC42E0@hoerbe.at>
Date: Fri, 03 Oct 2014 17:42:27 +0200
To: "Richer, Justin P." <jricher@mitre.org>
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (12A405)
X-Df-Sender: cmFpbmVyQGhvZXJiZS5hdA==
Archived-At: http://mailarchive.ietf.org/arch/msg/vot/IXhERogeeRiV1oOCQKCWP1xDeM0
Cc: "vot@ietf.org" <vot@ietf.org>
Subject: Re: [VoT] Vectors of Trust: A Strawman
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: <http://www.ietf.org/mail-archive/web/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: Fri, 03 Oct 2014 19:57:47 -0000

A few observations:

The scope of the VoT straw man is similar to 800-63: controls to mitigate an RP's risk of identifying remote entities, limited to confidentiality and integrity. Some risks are excluded, such as availability, binding strength between subject and session, the user's risk. This is fine, but it should be made explicit that VoT does not cover all trust aspects between RP, user and IAM infrastructure. 

IMU the purpose of VoT is to allow more flexibility in mapping legacy and future RP policies to a common identity infrastructure (?). LoA being too inflexible, the controls shall be split into non-overlapping areas/vectors that feature linear scales again. 
In my experience from some mapping exercises I doubt, however, that linear scales will work at the level of IPV or credential strength. Some gross examples are remote IPV and KBA allowed LoA3 in the US, or SMS as 2nd factor at level 4 in some European states. BTW the new EU payment services directive is quite specific about the strengths and independence of factors for internet banking from 2015 onwards. 

From a risk management perspective the prescription of controls is risk mitigation, which is one of several options. In commercial settings, at least, risk transfer is much simpler, because the risk will be equated with a money value, not with a set of controls.  Enforcing specific controls is only necessary where legally required, e.g. by AML regulations. Therefore, outside highly regulated areas, liability and insurance arrangements are much more powerful means to take out complexity from identity assurance. 

Another point is, that since the invention of ISMSs the management system and risk management methodology are the leading concepts, whereas lists of controls are secondary. Considering that risk assessment in the enterprisy approach is not feasible in a federated world, the reduction of risk to an amount per login etc. should be investigated as an alternative method. 

For the remaining set of controls (that cannot be taken care of with liability) I have been proposing a bottom-up approach instead of top-down. Standardizing on a more granular level  will not allow easy mapping at an LoA/VoT level, which is likely to fail because of differing requirements; OTOH it should allow for an efficient partial mapping. That in turn can help IDPs to identify what additional measures would have to be implemented to serve new RPs. 

Rainer
> Cought we could take it. There was a pretty consistent notion that LoA as currently defined provides a handy shortcut but is usually insufficient and more often than not is grossly misused. 
> 
> With that in mind, I would like to kick off this mailing list with a strawman proposal for an alternative: Vectors of Trust. The core idea here is to factor out different aspects of what goes into the LoA calculation today and present them as orthogonal vectors. These vectors would need to be communicated in various protocols and environments. We would also need to have a way of describing (and perhaps cataloguing) certain sets of vector values into a single reference to be used in things like trust frameworks.
> 
> 
> 
> The first question is what vectors should there be? Embedded in this is how many there should be in the first place. Too few vectors and we end up with the overly-simplified and usually-misused problem that LoA has today. Too many vectors and we end up with an un-navigable set of values where everybody's niche concern is a special snowflake. We need to stay allergic to both cases and shoot for something "in the middle". In particular, my own personal gut instinct says we should shoot for 3 to 5 vectors. I'm going to propose 4 here, all of them linear scales. As a side note, it's a question whether all of these are even linear scales, but I think it's important that we define comparison metrics on each vector element as well as the overall values.
> 
> 
> 
> So what vectors should we have? The LoA definition in 800-63 gives us a few to work from as starting points, as well as some work that's been done in the UK. These were captured from the discussion in the Utrecht meeting:
> 
> Identity proofing: 
> 
> This covers how sure the IdP is of various attributes about the user on the way in, and how much they're willing to vouch for those attributes. 
> 
> 0: self-asserted / anonymous / randomized / no idea
> 1: consistent over time / pseudonymous
> 2: proofed in person
> 3: contractually bound
> 
> Credential strength:
> 
> This covers how strongly bound the primary credential is to an individual presenter, and how easily spoofed or stolen it is.
> 
> 0: no credential / public
> 1: shared secret / password
> 2: proof of key possession
> 3: multiple factors [and probably higher definitions here as well -- but we want to avoid all the little bespoke 2FA companies getting to define a special snowflake "credential strength" value or else this becomes useless]
> 
> Assertion presentation:
> 
> This covers how much the federation protocol leaks information over the network to various parties, and how much of that information could be tampered in transit without the RP noticing. 
> 
> 0: no protection / leaky
> 1: signed & verifiable through browser
> 2: signed & verifiable through back channel
> 3: target-encrypted to RP's own key
> 
> Operational management:
> 
> This covers a variety of information about the identity provider and its host organization. What's the OpSec policy of the IdP? Is there disaster recovery in place? How mature is the hosting organization? What kind of incident response can be expected? How strongly bound is a particular attribute to a particular credential [though maybe this fits under identity proofing]? You'll note that already this feels a lot less linear and a lot less defined than the other three. 
> 
> 
> 
> Next we need a way to combine and communicate these vectors across the wire. I propose a simple method of assigning each category a marker letter and each value within the category a numeric value, and combining them with a separator, such as:
> 
>   pseudonymous, multi-factor, strong assertion = P1:C3:A2
> 
> It's compact and unambiguous, though it's not really making use of any existing data structures languages like JSON. But I think there does need to be a simple and parseable means to convey this info. This way, clients that need information on a particular category can pull it out and ignore the others. We can present structures like this (especially if they serialize into strings like this example) as part of the assertions in a variety of protocols. Say you've got an OpenID Connect access token, you can add a "vot" member to the payload with "I1:C3:A2" as its value. Clients can parse or ignore this as they see fit.
> 
> 
> Next, I think we need a good way to label and categorize these combined vectors, especially as exemplary use cases. A handful of examples from my own deployment experience:
> 
> P3:C2:A1 - OpenID 2.0 account provided to current employees and protected by domain password
> 
> P1:C3:A2 - OpenID Connect account from dynamically introduced IdP bound to a medical record in an out-of-band process
> 
> P3:C3:A3 - Cross-domain OpenID Connect pilot (with contracts connecting the two orgs to enforce the semantics)
> 
> It is probably a mistake to try and smush these back into a linear scale like LoA, since that's exactly what we're trying to get away from. However, it would probably be a good and enlightening exercise to map the existing LoA definitions into these vectors.
> 
> 
> 
> Finally, I think we need to think about and discuss the notion of the assessment and trustmarks that would be powering the trust in all of these values. After all, if they're just self-asserted by the IdP, that doesn't really help anyone. However, if we had a discovery mechanism whereby a trustmark provider would be able to host a machine-readable definition of what vectors a particular IdP has been proven to be able to claim for any transaction, I think we've got a good leg up on the problem. First off, it would need to be discoverable from the IdP, so I'm proposing we add a component to the discovery document. An OIDC example:
> 
> {
>  "iss": "https://idp.example.org/",
>   "trustmark": "https://trustmark-provider.org/csp-123412"
>   ...
> }
> 
> The URI given in this document would contain information about which vectors the IdP is allowed to claim, according to the trustmark provider:
> 
> {
>   "iss": "https://idp.example.org/",
>   "P": [3],
>   "C": [1, 2, 3],
>   "A": [2, 3],
>   "O": [1, 4]
> }
> 
> Paranoid clients and clients dealing with many IdPs across an ecosystem would be able to grab the service discovery doc (step 1, and they probably need it anyway) and then checking with a trusted third party, the trustmark provider, if the IdP is on the up-and-up. If a client gets a claim for a vector value that's not attested to by a known/trusted trustmark provider, it can call shenanigans. 
> 
> 
> 
> This is far from comprehensive, but I think this is a fairly decent strawman to start with. So let's burn this down and see what's left. Be sure to invite your friends to the bonfire!
> 
>  -- Justin
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot