Subject: [VoT] Vectors of Trust: A Strawman

From: "Richer, Justin P." <[email-masked]>
Date: Thu, 2 Oct 2014 21:10:07 +0000

Hi all,

In Utrecht, many of us had a conversation about "Level of Assurance", its limitations, and where we thought 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

---

From: Jim Fenton <[email-masked]>
Date: Thu, 02 Oct 2014 15:07:35 -0700

Hi Justin,

Good kickoff!

On 10/2/14 2:10 PM, Richer, Justin P. wrote:
>
> 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.

I'd suggest s/vectors/dimensions/

But what you're saying is that within each dimension, the relationships
are well-ordered.
>
>
>
> 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.

A bit of history: 800-63 is a response to OMB M-04-04, which defined 4
levels of assurance. 800-63 is a response to the OMB document describing
how each of the assurance levels should be achieved. During the 800-63-1
revision, there was some discussion about doing something different,
particularly to support the NSTIC strategy's vision of separate identity
and attribute providers. Also, it would have been a major change and it
would have made it less clear how 800-63 is responsive to M-04-04, which
is its primary official purpose. So a paragraph was added to the
introduction (although it doesn't explicitly mention LoA):

> Current government systems do not separate functions related to
> identity proofing in registration from credential issuance. In some
> applications, credentials (used in authentication) and attribute
> information (established through identity proofing) could be provided
> by different parties. While a simpler model is used in this document,
> it does not preclude agencies from separating these functions.

>
>
> *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. 
>

"consistent over time/pseudonymous" is probably also self-asserted.

I notice that you don't have a value for online identity proofing. Was
that an intentional omission?

I'm curious what "contractually bound" is beyond in-person proofing.
>
> *Credential strength:*
>
> This covers how strongly bound the primary credential is to an
> individual presenter, and how easily spoofed or stolen it is.
>
> 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?
>
> *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

3 seems like it's addressing a different problem (secrecy) rather than
the verifiability of the assertion.

>
> *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.

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

I think this is very important, to be able to use vectors of trust with
legacy LOA-based systems. I made an effort to do a mapping like this a
couple of years back, based on a somewhat different vector:
http://www.slideshare.net/jim_fenton/nstic-loa (at slide 9).

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

-Jim

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 3 Oct 2014 08:36:03 +0900

> Good kickoff!

+1

> 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.
>
>
> would have made it less clear how 800-63 is responsive to M-04-04, which is
> its primary official purpose. So a paragraph was added to the introduction
> (although it doesn't explicitly mention LoA):
>
> Current government systems do not separate functions related to identity
> proofing in registration from credential issuance. In some applications,
> credentials (used in authentication) and attribute information (established
> through identity proofing) could be provided by different parties. While a
> simpler model is used in this document, it does not preclude agencies from
> separating these functions.
>
>
>
>
>
>
>  *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.
>

Not sure about it. There can be pseudonymous - time consistent identifier
which is based on well vetted core identity. A prime example is Austrian
eID. A sector specific pseudonym is generated from LoA4 Qualified
Certificate.

> that an intentional omission?

Right. Also, having proofed in person / online and the assurance level of
the proofing is kind of orthogonal. There are many cases of lousy in-person
proofing, and there are cases of excellent online proofing.

The same is true for the contractual binding. It depends on the quality of
contract.

OK. I am running out of time. I will respond to the below at a later time.

Cheers,

Nat

> 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]
>
>
>  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
> 3 seems like it's addressing a different problem (secrecy) rather than the
> verifiability of the assertion.
>

>  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.
>
>
>  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.
>
>
> 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.
>
>
> 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.
>
> -Jim
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Dave Crocker <[email-masked]>
Date: Thu, 02 Oct 2014 17:20:45 -0700

> I'd suggest s/vectors/dimensions/

I kept reading the message as saying vectors of thrust.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brian Arkills <[email-masked]>
Date: Fri, 3 Oct 2014 06:15:06 +0000

[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:

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:

[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

---

From: Leif Johansson <[email-masked]>
Date: Fri, 03 Oct 2014 08:27:40 +0200

> I kept reading the message as saying vectors of thrust.

It can be that too if you let it.

---

From: Rainer Hoerbe <[email-masked]>
Date: Fri, 3 Oct 2014 17:42:27 +0200

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

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 6 Oct 2014 14:23:37 +0000

[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 <[email-masked]<mailto:[email-masked]>> 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:

[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:

[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.

[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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

---

From: Mikael Linden <[email-masked]>
Date: Tue, 7 Oct 2014 07:41:38 +0300 (EEST)

>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:[email-masked]] On Behalf Of Richer, Justin P.
Sent: 6. lokakuuta 2014 17:24
To: Brian Arkills
Cc: [email-masked]
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 <[email-masked]
<mailto:[email-masked]> > 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.

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]

[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.

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
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/vot

---

From: Joni Brennan <[email-masked]>
Date: Thu, 9 Oct 2014 09:10:40 -0700

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:+1 732-266-8994
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 <[email-masked]> wrote:

> could be able to discover ahead of time using a trust framework or assessor
> type of setup (the last point in the strawman),
>
>
>
> 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.
>
>
>
> *From:* vot [mailto:[email-masked]] *On Behalf Of *Richer, Justin P.
> *Sent:* 6. lokakuuta 2014 17:24
> *To:* Brian Arkills
> *Cc:* [email-masked]
> *Subject:* Re: [VoT] Vectors of Trust: A Strawman
>
>
>
>
>
> *[BA] It seems that the operational management vector has
> 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.*
>
>
>
> 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
> On Oct 3, 2014, at 2:15 AM, Brian Arkills <[email-masked]> wrote:
>
>
>
> *[BA] **First, thanks a ton for putting this list together and hoisting a
> constructive effort at moving things forward. **J*
>
>
>
> *I've got a couple initial responses to parts of the proposal below ... *
>
>
>
> *Credential strength:*
>
>
>
> *[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
> 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*
>
>
>
> *[BA] It seems that the operational management vector has
> 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.*
>
>
>
> *[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*
>

---

From: Nicole Harris <[email-masked]>
Date: Thu, 09 Oct 2014 17:51:03 +0100

The SIRTFI stuff is currently over here:
https://wiki.refeds.org/display/GROUPS/SIRTFI.  Note new shiny REFEDS
wiki. 

The thing I really like about this is that is totally use-case driven
and focused in on the elements that a specific group really care about
to provide an assurance profile approach that is likely to gain traction
in the given community and that simply does not attempt to address other
things that might typically cause problems in the whole level approach. 

-- 
----------------
Project Development Officer
TERENA
Singel 468 D
Amsterdam, 1017 AW
The Netherlands

T: +31(0)20 5304488
F: +31(0)20 5304499 

mob: +31(0)646 105395
skype: harrisnv