Subject: [VoT] Security Problem with Primary Credential Usage

From: Chris <[email-masked]>
Date: Sun, 8 May 2016 22:24:27 +1000

Hi All,

I think there is a critical flaw in section 3.2 of https://tools.ietf.org/html/draft-richer-vectors-of-trust-02 (Primary Credential Usage)

Mutual-authentication is missing.  When no provision is made to prevent man-in-the-middle, credential harvesting, spoof, phishing, malware, or other common threats, this renders all possible vectors C0, Ca, Cb, Cd, Ce, Cf, and others equally untrustworthy.

We should consider inclusion either for the overall strength of the authentication process, or some breakdown of either all the techniques used or the strength of protection employed to thwart at least common attack scenarios.

This problem gets tricky quite fast:

Do we identify the authentication technology vendor? (if yes - who works out their resistance strength to common attacks?  what about different modes?)
Do we broadly identify the techniques (whos opinions count as to whether or not the technique is effective and against what threats?)
Do we identify or classify the threats and indicate which ones were mitigated (who should be trusted to decide if these really were mitigated?)

For example - tamper-proof hardware digital certificate devices with biometrics unlocks are totally useless, if the user paid no attention to a broken SSL warning, or has malware.  They're also equally useless in most corporate environments that use deep-packet inspection firewalls - and "unexpected certificates" (eg. from DPI or malicious) carry their own privacy problems (eg: passwords are not as "protected" as you think).  Much more common authentication "protection" of course, are two-step or sms one time codes - which are equally useless when an end user can be tricked into revealing them to spoof sites.

91% of successful break-ins start from phishing.  Right now, every vector is pointing one way - we need at least one "Vector of Trust" to point back the other way!  

How about a 5th vector - "S" for "Security", which somehow allows an RP a level of confidence in the protection afforded to the user's actual authentication process, in terms of (or at least considering) a wide range of (and all common) modern threats.

Chris.

---

From: Julian White <[email-masked]>
Date: Thu, 12 May 2016 17:11:50 +0100

Hi,

I have a number of comments and questions (see attached), many of which are
related to the issues raised by Chris, some maybe my misunderstanding
coming in half way through the drafting tho.

I, like Chris, also think there needs to be something more explicit around
the "security" of the IdP authentication which includes the measures to try
and detect 'odd' things (like MITM). I would also go one step further in
that I also want to know about the maturity of the IdP's "security", its of
no use to me if they have really good credentials but store all the data in
the clear on their website or have a load of administrative back-doors that
could let anyone generate a valid authentication response.

It feels like we need to do more work in this area.

Regards,

Julian.

On 8 May 2016 at 13:24, Chris <[email-masked]> wrote:

> Hi All,
>
> I think there is a critical flaw in section 3.2 of
> https://tools.ietf.org/html/draft-richer-vectors-of-trust-02 (Primary
> Credential Usage)
>
> Mutual-authentication is missing.  When no provision is made to prevent
> man-in-the-middle, credential harvesting, spoof, phishing, malware, or
> other common threats, this renders all possible vectors C0, Ca, Cb, Cd, Ce,
> Cf, and others *equally* untrustworthy.
>
> We should consider inclusion either for the overall strength of the
> authentication process, or some breakdown of either all the techniques used
> or the strength of protection employed to thwart at least common attack
> scenarios.
>
> Do we identify the authentication technology vendor? (if yes - who works
> out their resistance strength to common attacks?  what about different
> modes?)
> Do we broadly identify the techniques (whos opinions count as to whether
> or not the technique is effective and against what threats?)
> Do we identify or classify the threats and indicate which ones were
> mitigated (who should be trusted to decide if these really were mitigated?)
>
> For example - tamper-proof hardware digital certificate devices with
> biometrics unlocks are totally useless, if the user paid no attention to a
> broken SSL warning, or has malware.  They're also equally useless in most
> corporate environments that use deep-packet inspection firewalls - and
> "unexpected certificates" (eg. from DPI or malicious) carry their own
> privacy problems (eg: passwords are not as "protected" as you think).  Much
> more common authentication "protection" of course, are two-step or sms one
> time codes - which are equally useless when an end user can be tricked into
> revealing them to spoof sites.
>
> 91% of successful break-ins start from phishing.  Right now, every vector
> is pointing one way - we need at least one "Vector of Trust" to point
> *back* the other way!
>
> How about a 5th vector - "S" for "Security", which somehow allows an RP a
> level of confidence in the protection afforded to the user's actual
> authentication process, in terms of (or at least considering) a wide range
> of (and all common) modern threats.
>
> Chris.
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 May 2016 13:45:29 -0500

We explicitly left those kinds of things out of the vector as they’d really be related to the IdP itself and not the authentication transaction to which the VoT refers. In other words, the security of the IdP is related to the trust framework and assessment of the IdP and it can be published as part of the IdP’s discovery documents and associated trust marks. This is information that is going to remain the same regardless of the transaction. 

This is also part of why you need to have a trustmark context to interpret the VoT in.

 — Justin

> On May 12, 2016, at 11:11 AM, Julian White <[email-masked]> wrote:
> 
> Hi,
> 
> I have a number of comments and questions (see attached), many of which are related to the issues raised by Chris, some maybe my misunderstanding coming in half way through the drafting tho.
> 
> I, like Chris, also think there needs to be something more explicit around the "security" of the IdP authentication which includes the measures to try and detect 'odd' things (like MITM). I would also go one step further in that I also want to know about the maturity of the IdP's "security", its of no use to me if they have really good credentials but store all the data in the clear on their website or have a load of administrative back-doors that could let anyone generate a valid authentication response.
> 
> On 8 May 2016 at 13:24, Chris <[email-masked] <mailto:[email-masked]>> wrote:
> Hi All,
> 
> I think there is a critical flaw in section 3.2 of https://tools.ietf.org/html/draft-richer-vectors-of-trust-02 <https://tools.ietf.org/html/draft-richer-vectors-of-trust-02> (Primary Credential Usage)
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/vot <https://www.ietf.org/mailman/listinfo/vot>
> 
> 
> <draft-richer-vectors-of-trust-02.docx>_______________________________________________
> vot mailing list
> [email-masked]

---

From: Julian White <[email-masked]>
Date: Thu, 12 May 2016 19:49:16 +0100

That makes sense, tho that didn't come across in the description of the
trustmark.

Julian
On 12 May 2016 19:45, "Justin Richer" <[email-masked]> wrote:

> We explicitly left those kinds of things out of the vector as they’d
> really be related to the IdP itself and not the authentication transaction
> to which the VoT refers. In other words, the security of the IdP is related
> to the trust framework and assessment of the IdP and it can be published as
> part of the IdP’s discovery documents and associated trust marks. This is
> information that is going to remain the same regardless of the transaction.
>
> I have a number of comments and questions (see attached), many of which
> are related to the issues raised by Chris, some maybe my misunderstanding
> <draft-richer-vectors-of-trust-02.docx>

---

From: Chris <[email-masked]>
Date: Fri, 13 May 2016 10:57:43 +1000

Hi All,

I think this is unreasonable.

Trust is a two-way street.

The standard will be more-or-less useless to everyone when half of the necessary trust system is excluded/out-of-scope.

Decisions related to trust need technical data.  If I'm relying on an IdP - it makes a difference if the user typed a 4 digit PIN over HTTP, as opposed to using a biometric multi-factor auth over TLS with HSTS & Pinning with included anti-spoof and anti-malware protection.  "What went on" absolutely needs technical inclusion.

Kind Regards,
Chris Drake

Friday, May 13, 2016, 4:49:16 AM, you wrote:

That makes sense, tho that didn't come across in the description of the trustmark.
Julian
On 12 May 2016 19:45, "Justin Richer" <[email-masked]> wrote:
We explicitly left those kinds of things out of the vector as they’d really be related to the IdP itself and not the authentication transaction to which the VoT refers. In other words, the security of the IdP is related to the trust framework and assessment of the IdP and it can be published as part of the IdP’s discovery documents and associated trust marks. This is information that is going to remain the same regardless of the transaction. 

 — Justin

Hi,

Regards,

Julian.

Chris.

---

From: Julian White <[email-masked]>
Date: Fri, 13 May 2016 08:52:55 +0100

Justin,

For my own clarity, can the RP pass a request for a specific trustmark, or
list of trustmarks that it will accept? The text seems to imply that they
will get whatever trustmark the IdP sends and have to make a decision based
on that each time. In reality, since the evaluation of the trustmark is a
cumbersome manual process I suspect RP's will whitelist trustmarks that
they will accept so then it seems inefficient for and IdP to return a
response under a trustmark the RP won't accept.

Thanks,

Julian.

On 12 May 2016 at 19:49, Julian White <[email-masked]> wrote:

>> I, like Chris, also think there needs to be something more explicit
>> around the "security" of the IdP authentication which includes the measures
>> to try and detect 'odd' things (like MITM). I would also go one step
>> further in that I also want to know about the maturity of the IdP's
>> "security", its of no use to me if they have really good credentials but
>> store all the data in the clear on their website or have a load of
>> administrative back-doors that could let anyone generate a valid
>> authentication response.
>>
>>> 91% of successful break-ins start from phishing.  Right now, every
>>> vector is pointing one way - we need at least one "Vector of Trust" to
>>> point *back* the other way!
>>>
>>> How about a 5th vector - "S" for "Security", which somehow allows an RP
>>> a level of confidence in the protection afforded to the user's actual

---

From: Chris <[email-masked]>
Date: Fri, 13 May 2016 19:48:21 +1000

Hi Julian,

It is like I said at the start.  The entirety of the trustmark idea evaluates to one single strength - everything is equally untrustworthy, because it's all only unidirectional.

You can't solve trust without fixing BOTH ends.  It is a two-way street.  For as long as a user and proxy are indistinguishable, C0 == Ca == Cb == Cd == Ce == Cf.

I know it sounds like a little problem, but so was the debris on that last Concorde's runway.  This is the show stopper.

Chris.

Friday, May 13, 2016, 5:52:55 PM, you wrote:

Justin,

For my own clarity, can the RP pass a request for a specific trustmark, or list of trustmarks that it will accept? The text seems to imply that they will get whatever trustmark the IdP sends and have to make a decision based on that each time. In reality, since the evaluation of the trustmark is a cumbersome manual process I suspect RP's will whitelist trustmarks that they will accept so then it seems inefficient for and IdP to return a response under a trustmark the RP won't accept.

Thanks,

Julian.

 — Justin

Hi,

Regards,

Julian.

Chris.

---

From: Julian White <[email-masked]>
Date: Fri, 13 May 2016 12:12:14 +0100

Chris,

Yes I see your point, so the RP should assert with which trustmarks it
complies too?

Regards,

On 13 May 2016 at 10:48, Chris <[email-masked]> wrote:

> Hi Julian,
>
> It is like I said at the start.  The entirety of the trustmark idea
> evaluates to one single strength - everything is equally untrustworthy,
> because it's all only unidirectional.
>
> You can't solve trust without fixing BOTH ends.  It is a *two-way *street.
> For as long as a user and proxy are indistinguishable, C0 == Ca == Cb == Cd
> == Ce == Cf.
>
> I know it sounds like a little problem, but so was the debris on that last
> Concorde's runway.  This is the show stopper.
>
> Chris.
>
>
>

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 May 2016 11:26:14 +0000

How does the IdP verify the RP’s authority to claim compliance?

From: vot [mailto:[email-masked]] On Behalf Of Julian White
Sent: 13 May 2016 12:12
To: Chris <[email-masked]>
Cc: [email-masked]; Justin Richer <[email-masked]>
Subject: Re: [VoT] Security Problem with Primary Credential Usage

Chris,

Yes I see your point, so the RP should assert with which trustmarks it complies too?

Regards,

On 13 May 2016 at 10:48, Chris <[email-masked]<mailto:[email-masked]>> wrote:
Hi Julian,

Chris.

Justin,

Thanks,

Julian.

On 12 May 2016 at 19:49, Julian White <[email-masked]<mailto:[email-masked]>> wrote:
That makes sense, tho that didn't come across in the description of the trustmark.
Julian
On 12 May 2016 19:45, "Justin Richer" <[email-masked]<mailto:[email-masked]>> wrote:
We explicitly left those kinds of things out of the vector as they’d really be related to the IdP itself and not the authentication transaction to which the VoT refers. In other words, the security of the IdP is related to the trust framework and assessment of the IdP and it can be published as part of the IdP’s discovery documents and associated trust marks. This is information that is going to remain the same regardless of the transaction.

— Justin

On May 12, 2016, at 11:11 AM, Julian White <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Julian.

On 8 May 2016 at 13:24, Chris <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

Chris.

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

<draft-richer-vectors-of-trust-02.docx>_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot

Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.

---

From: Julian White <[email-masked]>
Date: Fri, 13 May 2016 13:43:16 +0100

Josh,

That is a good question, and equally applicable to how would an RP verify
the claim of an IdP?

I think there are only a few usable options;

1) There is a direct relationship between the parties that assures the
trustworthiness between themselves outside of the assertion and will only
accept requests/responses from each other (via some means not defined here)
- this kind of makes the VoT value superfluous since the answer is already
known.

2) The trust schemes operate some sort of registry that the VoT links too -
but then there also needs to be something that makes it impossible for me
to impersonate a member of that scheme in the VoT, this is slightly more
challenging.

Does that make sense?

Julian

On 13 May 2016 at 12:26, Josh Howlett <[email-masked]> wrote:

> *From:* vot [mailto:[email-masked]] *On Behalf Of *Julian White
> *Sent:* 13 May 2016 12:12
> *To:* Chris <[email-masked]>
> *Cc:* [email-masked]; Justin Richer <[email-masked]>
> *Subject:* Re: [VoT] Security Problem with Primary Credential Usage
>
>
>
> Chris,
>
>
>
> Jisc is a registered charity (number 1149740) and a company limited by
> guarantee which is registered in England under Company No. 5747339, VAT No.
> GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill,
> Bristol, BS2 0JA. T 0203 697 5800.
>
> Jisc Services Limited is a wholly owned Jisc subsidiary and a company
> limited by guarantee which is registered in England under company number
> 2881024, VAT number GB 197 0632 86. The registered office is: One Castle
> Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
>

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 May 2016 14:57:17 +0000

Julian,

Yes, but note that (2) is actually an instance of (1), but where the number of parties happens to be greater than two. The choice of whether to use an internal or external registry is just an operational question. However, I don’t think this makes VoT superfluous: it still has value as a way of signalling alternate semantics defined within the trustmark agreement.

This does, however, suggest to me that VoT has limited utility when working across arbitrary trustmark agreements. And so to be candid, and without wishing to sound dispiriting, I suspect that working on the technical signalling without understanding how these agreements can be bound together is possibly premature; at least if you want something of general utility. More attention is needed on composable policy frameworks having compatible semantics, linked to an underlying legal architecture that works transitively across those agreements. Being the IETF, I understand that this probably isn’t the venue for that discussion ☺

Josh.

From: Julian White [mailto:[email-masked]]
Sent: 13 May 2016 13:43
To: Josh Howlett <[email-masked]>
Cc: Chris <[email-masked]>; [email-masked]; Justin Richer <[email-masked]>
Subject: Re: [VoT] Security Problem with Primary Credential Usage

Josh,

That is a good question, and equally applicable to how would an RP verify the claim of an IdP?

1) There is a direct relationship between the parties that assures the trustworthiness between themselves outside of the assertion and will only accept requests/responses from each other (via some means not defined here) - this kind of makes the VoT value superfluous since the answer is already known.

2) The trust schemes operate some sort of registry that the VoT links too - but then there also needs to be something that makes it impossible for me to impersonate a member of that scheme in the VoT, this is slightly more challenging.

Does that make sense?

Julian

On 13 May 2016 at 12:26, Josh Howlett <[email-masked]<mailto:[email-masked]>> wrote:
How does the IdP verify the RP’s authority to claim compliance?

From: vot [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Julian White
Sent: 13 May 2016 12:12
To: Chris <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Justin Richer <[email-masked]<mailto:[email-masked]>>
Subject: Re: [VoT] Security Problem with Primary Credential Usage

Chris,

Regards,

Chris.

Justin,

Thanks,

Julian.

— Justin

Hi,

Regards,

Julian.

Chris.

---

From: Andrew Hughes <[email-masked]>
Date: Fri, 13 May 2016 08:14:33 -0700

Josh: the discussion about compatible policy frameworks does already take
place, typically under the names: trust framework, federation agreements,
inter-federation. You see elements of this in national schemes in NZ, US,
UK, EU, CA and others - perhaps less so right now on the 'open internet' ,
but there's work happening in a number of pockets on this (R&E is quite
advanced).

The semantic compatibility is coming soon-ish. There's a convergence
underway on standardization of descriptions for roles, responsibilities,
business functions and business processes for identification,
authentication, authorization and access control systems ("Identity
Systems"). I'm contributing to diacc.ca and kantarainitiative.org along
these lines, and starting to learn what ISO/IEC JTC 1 SC 27 WG 5 (Identity
and Privacy) is developing.

andrew.

*Andrew Hughes *CISM CISSP
Independent Consultant
*In Turn Information Management Consulting*

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
[email-masked]
ca.linkedin.com/pub/andrew-hughes/a/58/682/
*Identity Management | IT Governance | Information Security *

On Fri, May 13, 2016 at 7:57 AM, Josh Howlett <[email-masked]>
wrote:

> Julian,
>
>
>
> Yes, but note that (2) is actually an instance of (1), but where the
> number of parties happens to be greater than two. The choice of whether to
> use an internal or external registry is just an operational question.
> However, I don’t think this makes VoT superfluous: it still has value as a
> way of signalling alternate semantics defined within the trustmark
> agreement.
>
>
>
> This does, however, suggest to me that VoT has limited utility when
> working across arbitrary trustmark agreements. And so to be candid, and
> without wishing to sound dispiriting, I suspect that working on the
> technical signalling without understanding how these agreements can be
> bound together is possibly premature; at least if you want something of
> general utility. More attention is needed on composable policy frameworks
> having compatible semantics, linked to an underlying legal architecture
> that works transitively across those agreements. Being the IETF, I
> understand that this probably isn’t the venue for that discussion J
>
>
>
> Josh.
>
>
>
> *From:* Julian White [mailto:[email-masked]]
> *Sent:* 13 May 2016 13:43
> *To:* Josh Howlett <[email-masked]>
> *Cc:* Chris <[email-masked]>; [email-masked]; Justin Richer <
> [email-masked]>
>
> 2) The trust schemes operate some sort of registry that the VoT links too
> - but then there also needs to be something that makes it impossible for me

---

From: Josh Howlett <[email-masked]>
Date: Fri, 13 May 2016 16:13:25 +0000

Andrew,

I was responsible for the activity that developed eduGAIN, whose policy framework interconnects the R&E federations, and so I’m pretty familiar the R&E space at least ☺. And so we do have these examples, as you rightly point out, where discussions do happen but these tend to happen within the (typically sector-specific) pockets of operators, such R&E, and not between them. That’s the forum we need if we’re ever going to serve the “open internet”.

Josh.

From: Andrew Hughes [mailto:[email-masked]]
Sent: 13 May 2016 16:15
To: Josh Howlett <[email-masked]>
Cc: Julian White <[email-masked]>; Chris <[email-masked]>; [email-masked]; Justin Richer <[email-masked]>
Subject: Re: [VoT] Security Problem with Primary Credential Usage

Josh: the discussion about compatible policy frameworks does already take place, typically under the names: trust framework, federation agreements, inter-federation. You see elements of this in national schemes in NZ, US, UK, EU, CA and others - perhaps less so right now on the 'open internet' , but there's work happening in a number of pockets on this (R&E is quite advanced).

The semantic compatibility is coming soon-ish. There's a convergence underway on standardization of descriptions for roles, responsibilities, business functions and business processes for identification, authentication, authorization and access control systems ("Identity Systems"). I'm contributing to diacc.ca<http://diacc.ca> and kantarainitiative.org<http://kantarainitiative.org> along these lines, and starting to learn what ISO/IEC JTC 1 SC 27 WG 5 (Identity and Privacy) is developing.

andrew.

Andrew Hughes CISM CISSP
Independent Consultant
In Turn Information Management Consulting

o  +1 650.209.7542
m +1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
[email-masked]<mailto:[email-masked]>
ca.linkedin.com/pub/andrew-hughes/a/58/682/<http://ca.linkedin.com/pub/andrew-hughes/a/58/682/>
Identity Management | IT Governance | Information Security

On Fri, May 13, 2016 at 7:57 AM, Josh Howlett <[email-masked]<mailto:[email-masked]>> wrote:
Julian,

Josh.

From: Julian White [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 13 May 2016 13:43
To: Josh Howlett <[email-masked]<mailto:[email-masked]>>
Cc: Chris <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Justin Richer <[email-masked]<mailto:[email-masked]>>

Josh,

Does that make sense?

Julian

Chris,

Regards,

Chris.

Justin,

Thanks,

Julian.

— Justin

Hi,

Regards,

Julian.

Chris.

---

From: Justin Richer <[email-masked]>
Date: Fri, 13 May 2016 17:39:16 -0500

That seems like a reasonable mechanism, though this is the first it’s been brought up. It was only in the last revision or so that we really tied the vector tightly to the trustmark concept, which itself needs to be more fully defined outside of the VoT concept.

 — Justin

> On May 13, 2016, at 2:52 AM, Julian White <[email-masked]> wrote:
> 
> Justin,
> 
> On 12 May 2016 at 19:49, Julian White <[email-masked] <mailto:[email-masked]>> wrote:
> On 12 May 2016 19:45, "Justin Richer" <[email-masked] <mailto:[email-masked]>> wrote:
>> On May 12, 2016, at 11:11 AM, Julian White <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>