Re: [VoT] Vectors of Trust: A Strawman

[Mikael Linden <[e-mail]>]

>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]
<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