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?

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 <Josh.Howlett@jisc.ac.uk> wrote:

> How does the IdP verify the RP’s authority to claim compliance?
>
>
>
> *From:* vot [mailto:vot-bounces@ietf.org] *On Behalf Of *Julian White
> *Sent:* 13 May 2016 12:12
> *To:* Chris <cnd@geek.net.au>
> *Cc:* vot@ietf.org; Justin Richer <jricher@mit.edu>
> *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 <cnd@geek.net.au> 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.
>
>
>
>
> 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.
>
> On 12 May 2016 at 19:49, Julian White <jwhite@nu-d.com> 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" <jricher@mit.edu> 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.
>
> 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 <jwhite@nu-d.com> 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.
>
> It feels like we need to do more work in this area.
>
> Regards,
>
> Julian.
>
> On 8 May 2016 at 13:24, Chris <cnd@geek.net.au> 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.
>
> 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.
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>
> <draft-richer-vectors-of-trust-02.docx>_______________________________________________
> vot mailing list
> vot@ietf.org
> https://www.ietf.org/mailman/listinfo/vot
>
>
>
>
> _______________________________________________
> vot mailing list
> vot@ietf.org
> 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.
>