<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">EAP call notes 8-Dec-16<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Mike Jones<o:p></o:p></p>
<p class="MsoNormal">John Bradley<o:p></o:p></p>
<p class="MsoNormal">Brian Campbell<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Agenda<o:p></o:p></p>
<p class="MsoNormal"> Review status of Token Binding specs<o:p></o:p></p>
<p class="MsoNormal"> Review status of ACR Values spec<o:p></o:p></p>
<p class="MsoNormal"> Next Call<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Review status of Token Binding specs<o:p></o:p></p>
<p class="MsoNormal"> Brian has been building implementations of the Token Binding specs<o:p></o:p></p>
<p class="MsoNormal"> This is pretty straightforward when supported end-to-end<o:p></o:p></p>
<p class="MsoNormal"> The tricky part is determining when Token Binding isn't supported versus there being an attack<o:p></o:p></p>
<p class="MsoNormal"> Brian believe that the boolean "supported" metadata values are insufficient<o:p></o:p></p>
<p class="MsoNormal"> For instance, parties might support mutually inconsistent key types<o:p></o:p></p>
<p class="MsoNormal"> Brian wonders whether it's possible to distinguish between downgrades and not yet upgraded<o:p></o:p></p>
<p class="MsoNormal"> John said that it may just come down to policy decisions about whether you're willing to reject stuff<o:p></o:p></p>
<p class="MsoNormal"> There are lots of things in the network that are going to break token binding<o:p></o:p></p>
<p class="MsoNormal"> People with middleware inspection boxes aren't happy with TLS or token binding<o:p></o:p></p>
<p class="MsoNormal"> Mike said that unless we have normative guidance that's practical, the attackers will win<o:p></o:p></p>
<p class="MsoNormal"> John said that the FAPI people might allow read access with bearer tokens but write requires Token Binding<o:p></o:p></p>
<p class="MsoNormal"> John said that unless the parties know what algorithms are used by participants, it's hopeless<o:p></o:p></p>
<p class="MsoNormal"> Sequencing can cause connections to either succeed or fail<o:p></o:p></p>
<p class="MsoNormal"> John had wanted to make P256 MTI and mandatory to use to enable interop<o:p></o:p></p>
<p class="MsoNormal"> We could do that in the Connect and OAuth Token Binding profiles<o:p></o:p></p>
<p class="MsoNormal"> That would simplify a lot of things<o:p></o:p></p>
<p class="MsoNormal"> Use P256 unless you have other out-of-band knowledge<o:p></o:p></p>
<p class="MsoNormal"> You're setting up the TLS connection before you even get the browser string to learn its capabilities<o:p></o:p></p>
<p class="MsoNormal"> John points out that older OSs such as Windows 7 likely won't get Token Binding<o:p></o:p></p>
<p class="MsoNormal"> We'll have clients that don't support Token Binding for a long time<o:p></o:p></p>
<p class="MsoNormal"> We could ask the WG if they're willing to require use of P256<o:p></o:p></p>
<p class="MsoNormal"> Brian said that Andrei has said that storing keys in TPMs can require the use of RSA<o:p></o:p></p>
<p class="MsoNormal"> John said that you should know for an OAuth client in advance whether it supports Token Binding<o:p></o:p></p>
<p class="MsoNormal"> Brian isn't sure that this is true<o:p></o:p></p>
<p class="MsoNormal"> John said that native apps aren't making HTTP connections directly<o:p></o:p></p>
<p class="MsoNormal"> So Token Binding is problematic in this case<o:p></o:p></p>
<p class="MsoNormal"> There would need to be APIs to expose the referred token binding to the application<o:p></o:p></p>
<p class="MsoNormal"> For instance, it would need to be an exported platform-specific APIs on Android and Windows<o:p></o:p></p>
<p class="MsoNormal"> Then the Native application could supply the referred token binding to the platform<o:p></o:p></p>
<p class="MsoNormal"> This would be like a Web View with extra parameters for the callback<o:p></o:p></p>
<p class="MsoNormal"> The spec that we're writing can be used for server-to-server at present<o:p></o:p></p>
<p class="MsoNormal"> At the moment, support is missing for native apps<o:p></o:p></p>
<p class="MsoNormal"> Because there's no TLS channel, there would have to be an opaque token binding ID<o:p></o:p></p>
<p class="MsoNormal"> John has discussed this with Google but not yet with Microsoft<o:p></o:p></p>
<p class="MsoNormal"> Mike asked what improvements we should next make to enable incremental progress<o:p></o:p></p>
<p class="MsoNormal"> Brian said that making the metadata values more granular is a first step<o:p></o:p></p>
<p class="MsoNormal"> John said that we should say in the security considerations why RSA will sometimes be used<o:p></o:p></p>
<p class="MsoNormal"> But we should recommend use of P256 by default<o:p></o:p></p>
<p class="MsoNormal"> Obviously if people want to propose security considerations text, go for it<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Review status of ACR Values spec<o:p></o:p></p>
<p class="MsoNormal"> What's there is a first stab for people to react to<o:p></o:p></p>
<p class="MsoNormal"> We define phishing-resistant and phishing-resistant-hardware-backed<o:p></o:p></p>
<p class="MsoNormal"> John said that OTPs are phishing-resistant<o:p></o:p></p>
<p class="MsoNormal"> Mike said that both PAPE and EAP use tighter definitions than that<o:p></o:p></p>
<p class="MsoNormal"> "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."<o:p></o:p></p>
<p class="MsoNormal"> John is in discussions with the people updating SP 800-63<o:p></o:p></p>
<p class="MsoNormal"> He finds the current 800-63 language confusing<o:p></o:p></p>
<p class="MsoNormal"> Now they talk about "verifier impersonation", which includes audience restriction to the intended receiver<o:p></o:p></p>
<p class="MsoNormal"> Without TLS binding, the approach is subject to DNS poisoning attacks<o:p></o:p></p>
<p class="MsoNormal"> John brought up Vectors of Trust, which NIST is considering<o:p></o:p></p>
<p class="MsoNormal"> https://tools.ietf.org/html/draft-richer-vectors-of-trust<o:p></o:p></p>
<p class="MsoNormal"> NIST can only refer to things that are standards<o:p></o:p></p>
<p class="MsoNormal"> Apparently part of the conversation at NIST is referencing Vectors of Trust once it's referenceable<o:p></o:p></p>
<p class="MsoNormal"> We should engage with Vectors of Trust while it's still influenceable because it may limit our options<o:p></o:p></p>
<p class="MsoNormal"> Structured authentication contexts could be part of the solution<o:p></o:p></p>
<p class="MsoNormal"> John thinks that Justin and Leif don't have adequate feedback on Vectors of Trust<o:p></o:p></p>
<p class="MsoNormal"> John pointed out that we need to consider session hijacking attacks against the user's session<o:p></o:p></p>
<p class="MsoNormal"> Some phishing-resistant methods don't necessarily protect the user's session<o:p></o:p></p>
<p class="MsoNormal"> Our current definition does not necessarily cover all the attacks that are in the wild<o:p></o:p></p>
<p class="MsoNormal"> NIST's response to this was their "verifier impersonation resistance" language<o:p></o:p></p>
<p class="MsoNormal"> Section 5.2.5 of SP 800-63-3b https://pages.nist.gov/800-63-3/sp800-63b.html<o:p></o:p></p>
<p class="MsoNormal"> When we wrote PAPE we didn't contemplate that the authentication channel and the access channel could be different<o:p></o:p></p>
<p class="MsoNormal"> You may be accessing a site from your phone but with two channels<o:p></o:p></p>
<p class="MsoNormal"> The SIM card channel and the Internet channel are different<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Next Call<o:p></o:p></p>
<p class="MsoNormal"> We will try to have the call on Thursday the 22nd in two weeks<o:p></o:p></p>
</div>
</body>
</html>