[Openid-specs-igov] Our conversation on SP-800-63-B

[John Bradley]

I suspect that we will disagree on the utility of token binding.

For inbound traffic yes people use deep packet inspection and those devices can support token binding/Fido in the same way that they support mutual TLS now.

Outbound inspection for DLP is more complicated, but there are some discussions around how that might be accomplished via a trusted proxy.

There may be other methods to detect man in the middle, but the RP/SP needs to be aware of what is happening and put appropriate mitigations in place.

I think that it is hard to argue that ignoring session hijacking is OK because there are some “legitimate” uses for it.

Banking malware is starting to modify users DNS entries to send them to phishing sites, home routers are also being compromised in similar ways.

In my opinion at some point in the not too distant future TLS everywhere  and detection of session hijacking will not just be for LOA 4 applications but also commonplace in financial and health applications.

Understanding the risks and mitigations is important.  

The Enhanced Authentication Profile (EAP) WG is working on Token Binding ID Tokens via the browser. http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html <http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html>
There will also be work on tying that to Fido.

My main point was that there is confusion about authentication channel session integrity and anti hijacking vs access channel integrity and anti hijacking.

Regards
John B.

> On Dec 4, 2016, at 9:15 AM, Chris Drake <cnd at geek.net.au> wrote:
> 
> Hi John,
> 
> TLS channels are never useful for anything, because no self-respecting organisation nowdays allows non-proxied internet access: malware over TLS is simply too dangerous (it *must* be scanned for), as is data exfiltration: everything is behind deep-packet-inspection nowdays; this includes most schools and universities, many business, government, and military organisations, as well as entire *countries* who are forced to install their government CA to get internet access.
> 
> So the problem is easy to break down: how do you guarantee end-to-end protection yet specifically *permit* these proxies?  Users need to be involved.
> 
> As you point out, typical users click "yes" when prompted, which presents another problem: how to protect users against themselves?  More than 90% of government web site have no TLS whatsoever (and 100% of people behind deep-packet-inspectors have no trustworthy TLS at all), making "SSL Strip" or any other kind of interception trivial - so how do you "save" an ordinary end user against authentication attack through http://A.gov when they *should* be authenticating through https://B.gov (in a situation where A.gov is malicious (or used maliciously via the proxy/intercept), and simply exists to trick the user into authenticating the attacker, who is on B.gov)?
> 
> Once again - the user needs to be involved.
> 
> In both user-involvement situations, they need to be "untrickable": no "yes/no" question should be presented.
> 
> One solution to all these problems is a browser-supported authentication component which generates a hash of the symmetric session key for the browser connection together with some unique-to-the-user local information from their device, and this hash is used as a key to present to the user some easy-to-solve puzzle (eg: click on the matching image; where the images shown are selected from a large set, the selection based on the hash), and the website wanting to be authenticated shows to the user the one image they need to click on to approve (the "challenge" image): in the event of any in-the-middle attack, *and/or* in the event of the malicious attacker wanting to trick the user, there will never be any matching image for the potential victim to click on - so we have a foolproof (literally) way to ensure that in-the-middle attacks are revealed - at which point the user can optionally then be prompted to accept or reject the identity of this intermediary (the deep-packet-inspection infrastructure's certificate): or more likely; in conjunction with the browser component, this can be either automatically rejected (e.g. for home users who do expect to be behind such things) or automatically accepted (for businesses who have deployed this to their worker machines) or for the discerning security-educated user - an actual prompt can be shown to allow them to examine the interception and approve if they so wish.
> The *two* subsequent sets of symmetric keys can then be used again to produce the hash, which this time *will* allow the user to match the challenge photo from the requesting web site.
> 
> Personally - I cannot see any point whatsoever in building anything that does not protect an ordinary user against some trickster scamming them into authenticating the trickster (via any means), and of course, there is literally no point building anything that can't work if your employer has deep-packet-inspection activated - heck - I'm an ordinary home user, and my wifi switch has this option installed and turned on by default *itself*.  And it's just plain dangerous to build something that purports to solve these problems, but then has them disabled later (cough, FIDO), on account of them not thinking the DPI problem through properly going live.
> 
> Kind Regards,
> Chris Drake
> 
> 
> Sunday, December 4, 2016, 3:50:29 AM, you wrote:
> 
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20161204/68dc07cf/attachment.html>