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

[John Bradley]

We were talking about sec 5.2.5 and sec 7 on the iGov call the other day. 

My concern really lies at the intersection of the two.

In conversations with people like Samsung SDS and even internally at Ping people are not necessarily interpreting verifier impersonation resistance correctly or there is a part missing.

In both above cases they had read Sec 5.2.5 and pointed to it as justification for there conclusions.

You may be aware Ping has a PingID app that uses push notification much like Duo, Microsoft Account, Yahoo mail and any number of others (Google has one but I cant remember the name).

In the case of PingID they decided to both pin the server certificate and use mutual TLS to pass the authentication challenge back to the server for authentication. 

In the Samsung SDS case they built a Fido Authentication app that is triggered by a push notification from the RP/SP that then performs UAF authentication and sends a signed fido token back to the SP based on facitID as the audience/key restriction per the spec.

I had to tell both of them that in my opinion that while they may be technically be meeting the letter of verifier impersonation resistance, because the short term token could not be intercepted and replayed, they were missing the spirit of the thing.   

Any phisher could intercept the access channel and then proxy to the real RP where they RP would trigger a authentication flow where the authentication token is passed on a separate communication channel meeting all the requirements of verifier impersonation resistence.  However once the RP gets the positive assertion from a verifier it then issues a session cookie to the attacker who is man in the middling the access channel.

There is a implicit assumption in the document that access and authentication happen on the same channel.

This is no longer guaranteed to be the case.  If we look at GSMA Mobile Connect all of the authentication is done out of band to the SIM app, USSD <https://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data> app or smart phone app using push. 
There are currently over 1B mobile accounts with mobile connect enabled and as people use it the attackers will notice if the access channel is unprotected.

 So I can by that these separate channel authentication methods are better than passwords,  so are phishing resistant in that the long term credential is not compromised, and that verifier impersonation resistance is a good thing for them to do in the back channel but it is not sufficient.

Now you may not be surprised that venders are not so happy to hear that advice, so some may prefer there reading.

In -2 for LOA 4 with mutual TLS over the aces channel and that key or certificate being bound to any assertion so that in effect the person presenting the assertion needed to be in possession of the same key that was used for the authentication and any subsequent cookies issued at the RP/SP could be bound to that TLS session essentially tying everything to the original key.

Now in practice that is hard to deploy, and you are doing a good job trying to separate out he issues.

One question is how to treat this out of band authentication.   I could make a good argument if not a popular one that it is in fact not authentication of the user on the access channel,  it might be authentication of the user for a authorization to do something like access a site, but should be considered only as a single factor or multi-factor authenticator.

I have recommended that from a enterprise perspective this could be combined with device certificates as a way to get you a legitimate AAL3 combination (there may be debate around the type of cert and if it is device or personal but those are details) 

For the Mobile connect use case you could cookie known devices for the user and provide warnings and some ceremony to make a device trusted, though users tend to click yes to everything so it is unclear how usefull that would be, but might help with risk based detection.

So I think there may be a gap in how authentication gets turned into access if they happen on different channels. 

I should also note that Sec 7 should also talk about binding cookies to Mutual TLS or via methods like token binding to prevent session hijacking for AAL3 or higher situations.

Let me know if you want to discuss this.

Regards
John B.


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