<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://3248/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sorry yes it went back and forth. <div><br></div><div>The question is if we should override the OAuth RFC's requirement for TLS on the client in favour of allowing adoption of connect by those web sites that don't implement TLS for login and session cookies.</div><div><br></div><div>If a site has no TLS and can have it's cookies and passwords leaked, then Connect without TLS is arguably no worse than the current situation and arguably better because at-least the user is not leaking the password.</div><div><br></div><div>So do we allow the bad thing to prevent the worse thing?</div><div><br></div><div>This makes code more likely to leak, and there is no real protection possible other than using a hmac of the device fingerprint as the nonce, but a TLS cert for the client is much simpler.</div><div><br></div><div>John B.</div><div><br><div><div>On 2013-10-24, at 11:37 AM, Mike Jones <<a href="mailto:Michael.Jones@microsoft.com">Michael.Jones@microsoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">John, you wrote: “</span>At the IIW F2F we took a decision that we should match the RFC and require the client to have a TLS endpoint if using a http redirect.(not a custom scheme)<span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">”. While the working group was leaning that way early in the discussion, Naveen and others pushed back, and that doesn’t actually match the decision that we recorded in the notes, which say:<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "> OP may prevent registration of redirect_uris that do not use https<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "> A confidential client needs to be required to use http<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "> We will discuss this further on the list<o:p></o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Consider this the start of the further discussion on the list. What do people think?<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> -- Mike<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span></div><div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0in 0in; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "><span class="Apple-converted-space"> </span><a href="mailto:openid-specs-ab-bounces@lists.openid.net" style="color: purple; text-decoration: underline; ">openid-specs-ab-bounces@lists.openid.net</a><span class="Apple-converted-space"> </span>[mailto:openid-<a href="mailto:specs-ab-bounces@lists.openid.net" style="color: purple; text-decoration: underline; ">specs-ab-bounces@lists.openid.net</a>]<span class="Apple-converted-space"> </span><b>On Behalf Of<span class="Apple-converted-space"> </span></b>John Bradley<br><b>Sent:</b><span class="Apple-converted-space"> </span>Thursday, October 24, 2013 5:42 AM<br><b>To:</b><span class="Apple-converted-space"> </span>Vladimir Dzhuvinov / NimbusDS<br><b>Cc:</b><span class="Apple-converted-space"> </span><a href="mailto:openid-specs-ab@lists.openid.net" style="color: purple; text-decoration: underline; ">openid-specs-ab@lists.openid.net</a><br><b>Subject:</b><span class="Apple-converted-space"> </span>Re: [Openid-specs-ab] First Release Candidates for final OpenID Connect specifications<o:p></o:p></span></div></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Snip<o:p></o:p></div><div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">On 2013-10-24, at 1:36 AM, "Vladimir Dzhuvinov / NimbusDS" <<a href="mailto:vladimir@nimbusds.com" style="color: purple; text-decoration: underline; ">vladimir@nimbusds.com</a>> wrote:<o:p></o:p></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><br><o:p></o:p></div><div id="wmQuoteWrapper"><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div style="margin-left: 0.5in; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-family: Calibri, sans-serif; "><br><br>"When using this flow, the redirection URI MAY use the http scheme, provided that the Client Type is confidential, as defined in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https scheme" - This, surprisingly enough, is relaxed in comparison to<a href="http://tools.ietf.org/html/rfc6749#section-10.5" target="_blank" style="color: purple; text-decoration: underline; "><span style="color: purple; ">http://tools.ietf.org/html/rfc6749#section-10.5</span></a>.<br><br>RFC 6749 states: "Authorization codes operate as plaintext bearer credentials, used to verify that the resource owner who granted authorization at the authorization server is the same resource owner returning to the client to complete the process. Therefore, if the client relies on the authorization code for its own resource owner authentication, the client redirection endpoint MUST require the use of TLS."<br><br>Why is Connect, in this particular case, less restrictive than OAuth?<o:p></o:p></span></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "> </span><span style="font-family: Calibri, sans-serif; "><o:p></o:p></span></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">John, can you speak to why we’re allowing http redirect_uri values when apparently OAuth doesn’t?</span><span style="font-family: Calibri, sans-serif; "><o:p></o:p></span></div></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">I had some questions on this point as well. I believe the thinking is that since the client is protecting the secret and the code is sent to the /token endpoint with client authentication, even if someone was able to hijack the code value they couldn't exchange it for the access (and possibly refresh) tokens. If we are trying to make things simpler, then just moving all of it to TLS makes sense. To me, the only exception is localhost.<span class="apple-converted-space"> </span><o:p></o:p></div></blockquote><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br>The attacker could inject the authorization code into the same application as used by the victim in order to impersonate her/him.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><br><span style="color: fuchsia; ">For this to happen the attacker should also have gained control over the RP (the application), i.e. have the RPs' authentication credentials.</span><br><br><o:p></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt; "><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></blockquote></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Early OAuth 2 inherited the idea from OAuth 1 that the client didn't need to have a TLS cert. We were matching that. At the IIW F2F we took a decision that we should match the RFC and require the client to have a TLS endpoint if using a http redirect.(not a custom scheme)<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">Earlier in this thread there is also a question about exact redirect_uri matching and if it is required for confidential clients. In the code flow if the token is leaked through an open redirector then it can be presented to the real client and the attacker gets in as the user.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">The OAuth AS side mitigation of this is the confidential client passing the redirect URI to the AS in the token request and the AS performing an exact match on the redirect URI, and failing if it is different. In the wild it appears AS are also not being sufficiently strict on matching that and causing some problems in deployments.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">The client side mitigation for this is using nonce in the signed token to allow the client to check on its own if it initiated the request through the same browser that presented the code. However that was left as optional for code.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">At the end of the day the reality is that some of the large IdP only allow exact matching of redirect_uri. If some are strict and some allow query parameters then clients using query parameters to carry state will fail and not be interoperable.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">The WG decided that the strict matching of the redirect_uri by those IDP is allowed by the RFC, rather than forcing them to change and do pattern matching for interoperability we precluded clients from hiding state in the query parameters and forced them to use the "state" parameter.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">So yes for a fully RFC compliant OAuth server with a client that is truly confidential and not just pretending, it would be secure for the AS to relax the matching for the redirect_uri in the request to the authorization server as long as it records that URI and is doing an exact string match on it aginst the one sent to the token endpoint. It is not however safe for a client to assume all AS are going to act that way. The only safe thing for the client is to assume exact string match.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">So while this relates to security issues the final decision was taken for interoperability of the client.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; ">John B.<o:p></o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><o:p> </o:p></div></div></div></div></blockquote></div><br></div></body></html>