Re: [VoT] Vectors of Trust: A Strawman

["Richer, Justin P." <[e-mail]>]

[BA] It seems that the operational management vector has intersections/overlaps with some of the other vectors, but maybe that’s just imagined on my part. If the operators of the component allow their cert to expire that affects some of the other vectors. Likewise, if they have very strong administrative practices, perhaps the credential strength is better than another provider using the same technologies. I’m struggling with whether I think it’s good to represent this as a separate vector or if this is just an aspect which influences the other vectors.

I agree that it's definitely different from the others, and originally I only had the other three listed. The conversation in Utrecht had a lot of input into this though.

I think an important metric might be "what do I care about this at runtime"? There are things in this space (like "disaster recovery") that an RP could be able to discover ahead of time using a trust framework or assessor type of setup (the last point in the strawman), but they're not going to ever change on a per-transaction or per-user basis. Other items like credential strength and proofing might be different each time though, depending on the population of users being served.

 -- Justin



On Oct 3, 2014, at 2:15 AM, Brian Arkills <[e-mail]<mailto:[e-mail]>> wrote:

[BA] First, thanks a ton for putting this list together and hoisting a strawman to kick things off. I think a lot of people have been thinking about the ways in which the existing LoA fall short, and I’m glad to see a constructive effort at moving things forward. :)

I’ve got a couple initial responses to parts of the proposal below …

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]

Anything here about how the secret key is protected? How about bearer assertions like cookies?

[BA] One of the stated aims of this vector is to reflect how easy it is to steal the credential, but none of the values really represent that aspect. One of the biggest security stories right now, the plethora of retailers with credit card breaches over the past year, seem to share several common elements, one of which involves leveraging the NTLM pass the hash credential replay. And if you’ve been following the NTLM pass the hash replay stuff, you’ll have taken note of the fact that enabling 2 factor on a given account doesn’t mitigate it at all. Of course, that replay is first dependent on compromising a system which has the desired credential, but the fact that a replay attack is part of the underlying credential design might mean your score should be lower here. You might have mitigations in place which partially or totally neutralize that, in which case your score should be less affected. I’m not yet sure how you’d represent this complexity in a better way via the suggested description for the values but I did want to call this out so better minds than mine could ponder it. :)

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.

[BA] It seems that the operational management vector has intersections/overlaps with some of the other vectors, but maybe that’s just imagined on my part. If the operators of the component allow their cert to expire that affects some of the other vectors. Likewise, if they have very strong administrative practices, perhaps the credential strength is better than another provider using the same technologies. I’m struggling with whether I think it’s good to represent this as a separate vector or if this is just an aspect which influences the other 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.

Yes: it's essential that we address the accreditation of the authentication and attribute providers in this structure. It's not clear that they're additional dimensions, though: a level 3 assertion from an entity that's only accredited at level 2 should probably just be treated at the lower level unless there's an indication of fraud. It's also possible that some providers might be accredited at different levels for different purposes: perhaps they have an accreditation at level 3 from the financial community, but only level 2 for health care.  We need to consider that.

[BA] I also wonder about vectors of trust in chained assertion scenarios. You assert X, then I assert X based on your assertion (and my evaluation of your assertion). Or do I somehow encapsulate your assertion inside mine and consuming apps know how to deal with this? Does the assertion’s strength change when I assert it (or encapsulate it) based on who I am?

Brian Arkills
University of Washington
_______________________________________________
vot mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/vot