Re: [VoT] Security Problem with Primary Credential Usage

[Julian White <[e-mail]>]

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 <[e-mail]> 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" <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/vot
>>>
>>>
>> <draft-richer-vectors-of-trust-02.docx>
>> _______________________________________________
>> vot mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vot
>>
>>
>>