Re: [VoT] Vectors of Trust: A Strawman

[Joni Brennan <[e-mail]>]

This has been a great thread.  I will spend more time to respond more
deeply...

I suggest that incident response could be very reasonable for a VoT.
Ideally we are not specifying the "how" but that there is a process with
reasonable rigor in place.

best,
- Joni

Best Regards,

Joni Brennan
Kantara Initiative | Executive Director
voice:[phone]
email: joni @ kantarainitiative.org

Connecting Identity for a more trustworthy Internet - Overview
<http://www.slideshare.net/kantarainitiative/kantara-overview2014-37969351>




On Mon, Oct 6, 2014 at 9:41 PM, Mikael Linden <[e-mail]> wrote:

> >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),
>
>
>
> CERN and the grid folks are pushing a framework for incident handling in
> federations (A Security Incident Response Trust
>
> Framework for Federated Identity -- Sir-T-Fi). They would like to have
> some assurance that the IdP admin is reactive (answers to mail, phone etc...)
> when an RP has faced an incident and needs the IdP's co-operation to
> resolve it.
>
>
>
> Is this another dimension for VoT?
>
>
>
> Cheers,
>
> mikael
>
>
>
> *From:* vot [mailto:[e-mail]] *On Behalf Of *Richer, Justin P.
> *Sent:* 6. lokakuuta 2014 17:24
> *To:* Brian Arkills
> *Cc:* [e-mail]
> *Subject:* Re: [VoT] Vectors of Trust: A Strawman
>
>
>
>
>
> *[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]> 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. **J*
>
>
>
> *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. *
> *J*
>
>
>
> *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]
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
> _______________________________________________
> vot mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vot
>
>