[OpenID-specs-EAP] EAP call notes 8-Dec-16

[Mike Jones]

EAP call notes 8-Dec-16

Mike Jones
John Bradley
Brian Campbell

Agenda
              Review status of Token Binding specs
              Review status of ACR Values spec
              Next Call

Review status of Token Binding specs
              Brian has been building implementations of the Token Binding specs
                           This is pretty straightforward when supported end-to-end
              The tricky part is determining when Token Binding isn't supported versus there being an attack
              Brian believe that the boolean "supported" metadata values are insufficient
                           For instance, parties might support mutually inconsistent key types
              Brian wonders whether it's possible to distinguish between downgrades and not yet upgraded
              John said that it may just come down to policy decisions about whether you're willing to reject stuff
                           There are lots of things in the network that are going to break token binding
              People with middleware inspection boxes aren't happy with TLS or token binding
              Mike said that unless we have normative guidance that's practical, the attackers will win
              John said that the FAPI people might allow read access with bearer tokens but write requires Token Binding
              John said that unless the parties know what algorithms are used by participants, it's hopeless
                           Sequencing can cause connections to either succeed or fail
              John had wanted to make P256 MTI and mandatory to use to enable interop
                           We could do that in the Connect and OAuth Token Binding profiles
                           That would simplify a lot of things
                           Use P256 unless you have other out-of-band knowledge
              You're setting up the TLS connection before you even get the browser string to learn its capabilities
              John points out that older OSs such as Windows 7 likely won't get Token Binding
                           We'll have clients that don't support Token Binding for a long time
              We could ask the WG if they're willing to require use of P256
              Brian said that Andrei has said that storing keys in TPMs can require the use of RSA
              John said that you should know for an OAuth client in advance whether it supports Token Binding
                           Brian isn't sure that this is true
              John said that native apps aren't making HTTP connections directly
                           So Token Binding is problematic in this case
                           There would need to be APIs to expose the referred token binding to the application
                           For instance, it would need to be an exported platform-specific APIs on Android and Windows
                           Then the Native application could supply the referred token binding to the platform
                           This would be like a Web View with extra parameters for the callback
              The spec that we're writing can be used for server-to-server at present
                           At the moment, support is missing for native apps
                           Because there's no TLS channel, there would have to be an opaque token binding ID
                           John has discussed this with Google but not yet with Microsoft
              Mike asked what improvements we should next make to enable incremental progress
                           Brian said that making the metadata values more granular is a first step
                           John said that we should say in the security considerations why RSA will sometimes be used
                           But we should recommend use of P256 by default
                           Obviously if people want to propose security considerations text, go for it

Review status of ACR Values spec
              What's there is a first stab for people to react to
              We define phishing-resistant and phishing-resistant-hardware-backed
              John said that OTPs are phishing-resistant
                           Mike said that both PAPE and EAP use tighter definitions than that
                           "An authentication mechanism where a party potentially under the control of the Relying Party cannot gain sufficient information to be able to successfully authenticate to the End User's OpenID Provider as if that party were the End User."
              John is in discussions with the people updating SP 800-63
                           He finds the current 800-63 language confusing
                           Now they talk about "verifier impersonation", which includes audience restriction to the intended receiver
                           Without TLS binding, the approach is subject to DNS poisoning attacks
              John brought up Vectors of Trust, which NIST is considering
                           https://tools.ietf.org/html/draft-richer-vectors-of-trust
                           NIST can only refer to things that are standards
                           Apparently part of the conversation at NIST is referencing Vectors of Trust once it's referenceable
              We should engage with Vectors of Trust while it's still influenceable because it may limit our options
                           Structured authentication contexts could be part of the solution
                           John thinks that Justin and Leif don't have adequate feedback on Vectors of Trust
              John pointed out that we need to consider session hijacking attacks against the user's session
                           Some phishing-resistant methods don't necessarily protect the user's session
                           Our current definition does not necessarily cover all the attacks that are in the wild
                           NIST's response to this was their "verifier impersonation resistance" language
                                         Section 5.2.5 of SP 800-63-3b https://pages.nist.gov/800-63-3/sp800-63b.html
              When we wrote PAPE we didn't contemplate that the authentication channel and the access channel could be different
                           You may be accessing a site from your phone but with two channels
                                         The SIM card channel and the Internet channel are different

Next Call
              We will try to have the call on Thursday the 22nd in two weeks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-eap/attachments/20161208/a4086c06/attachment-0001.html>