<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>That's true. However if an attacker can firesheep the user nothing is safe.</div><div><br></div><div>While I personally think giving every RP a free cert is the best solution to this issue, that probably won't happen (though <a href="http://www.startssl.com/?app=1">startssl certs</a> are free, I don't know what would happen if everyone asked for one.) The financial argument is weak, it is mostly a lazy RP argument and verry small hosted guys who cant run TLS on some free services.</div><div><br></div><div>Allowing http: to be an exception AS can make is not totally unreasonable, however Caution needs to be taken by the IdP not to be too loose about it. Offer a free cert first.</div><div><br></div><div>If they won't do TLS connect using the code flow and a confidential client is still better than a password.</div><div><br></div><div>John B.</div><div><br></div><div><br></div><div><br></div><div> </div><br>On Oct 27, 2013, at 1:29 PM, Torsten Lodderstedt <<a href="mailto:torsten@lodderstedt.net">torsten@lodderstedt.net</a>> wrote:<br><br><blockquote type="cite"><br>Vladimir Dzhuvinov / NimbusDS <<a href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>> schrieb:<br><blockquote type="cite">Here is the sentence you refer to:<br><br>"Therefore, if the client relies on the authorization code for its own<br>resource owner authentication, the client redirection endpoint MUST<br>require the use of TLS."<br><br>That note was meant for general OAuth 2.0. With OIDC we have the signed<br>ID token, so clients will be using that instead to authenticate the<br>resource owner.<br></blockquote><br>The ID token won't prevent an attacker to steal a code on the wire and use it to login with the victim's identity at the legitimate website (client). The Id token prevents a rough client from impersonating a user.<br><br><blockquote type="cite"><br>I read the entire section carefully, and it's fully in line with<br>section<br>3.1.2.1 that I quoted in my previous email, as well as with what<br>Connect<br>has now specified. I.e. there is a strong recommendation to use TLS,<br>but<br>there's also the understanding that TLS wouldn't be practical for a<br>number of clients and that's taken into account too.<br><br><br>Vladimir<br><br><br>On Fri, 2013-10-25 at 07:41 +0200, Torsten Lodderstedt wrote:<br><blockquote type="cite">What about <br><br><a href="http://tools.ietf.org/html/rfc6749#section-10.5">http://tools.ietf.org/html/rfc6749#section-10.5</a><br><br>second paragraph, last sentence? <br><br>We explicitly added this statement/requirement in order to address<br></blockquote>the<br><blockquote type="cite">specific risk associated with code theft when OAuth is used for<br>authentication.<br><br><br><br>Vladimir Dzhuvinov / NimbusDS <<a href="mailto:vladimir@nimbusds.com">vladimir@nimbusds.com</a>> schrieb:<br> Hi John, hi guys,<br><br> It looks like my previous email didn't get through.<br><br> The current OIDC spec doesn't actually relax the TLS<br></blockquote>requirement in<br><blockquote type="cite"> regard to the redirection endpoint:<br><br> <a href="http://tools.ietf.org/html/rfc6749#section-3.1.2.1">http://tools.ietf.org/html/rfc6749#section-3.1.2.1</a><br><br> 3.1.2.1. [Redirection] Endpoint Request Confidentiality<br><br> The redirection endpoint SHOULD require the use of TLS as<br></blockquote>described<br><blockquote type="cite"> in Section 1.6 when the requested response type is "code" or<br></blockquote>"token",<br><blockquote type="cite"> or when the redirection request will result in the<br></blockquote>transmission of<br><blockquote type="cite"> sensitive credentials over an open network. This<br></blockquote>specification does<br><blockquote type="cite"> not mandate the use of TLS because at the time of this<br></blockquote>writing,<br><blockquote type="cite"> requiring clients to deploy TLS is a significant hurdle for<br></blockquote>many<br><blockquote type="cite"> client developers. If TLS is not available, the<br></blockquote>authorization server<br><blockquote type="cite"> SHOULD warn the resource owner<br> about the insecure endpoint prior to<br> redirection (e.g., display a message during the authorization<br> request).<br><br> So we're actually fine with that.<br><br><br> This is the OIDC core redirect_uri spec for the "code" flow:<br><br><br></blockquote><a href="http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest">http://openid.bitbucket.org/openid-connect-core-1_0.html#AuthorizationRequest</a><br><blockquote type="cite"><br> redirect_uri<br> REQUIRED. .... When using this flow, the Redirection URI MAY<br></blockquote>use the<br><blockquote type="cite"> http scheme, provided that the Client Type is confidential,<br></blockquote>as defined<br><blockquote type="cite"> in Section 2.1 of OAuth 2.0; otherwise, it MUST use the https<br></blockquote>scheme. <br><blockquote type="cite"> state<br><br><br> And here for the "implicit" flow:<br><br><br></blockquote>http://openid.bitbucket.org/openid-connect-core-1_0.html#ImplicitAuthorizationRequest<br><blockquote type="cite"><br> redirect_uri<br> REQUIRED. ... When using this flow,<br> the Redirection URI MUST NOT use<br> the http scheme unless the Client is a native application, in<br></blockquote>which case<br><blockquote type="cite"> it MAY use the http: scheme with localhost as the hostname. <br><br><br> --<br> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com<br><br><br><br> -------- Original Message --------<br> Subject: Re: Whether to allow http redirection URIs for<br></blockquote>confidential<br><blockquote type="cite"> clients<br> From: John Bradley <ve7jtb@ve7jtb.com><br> Date: Thu, October 24, 2013 7:54 pm<br> To: Mike Jones <Michael.Jones@microsoft.com><br> Cc: Vladimir Dzhuvinov / NimbusDS <vladimir@nimbusds.com>,<br> "openid-specs-ab@lists.openid.net"<br></blockquote><openid-specs-ab@lists.openid.net><br><blockquote type="cite"><br> Sorry yes it went back and forth. <br><br> The question is if we should override the OAuth RFC's<br></blockquote>requirement for<br><blockquote type="cite"> TLS on the client in favour of allowing adoption of connect<br></blockquote>by those web<br><blockquote type="cite"> sites that don't implement TLS for login<br> and session cookies.<br><br><br> If a site has no TLS and can have it's cookies and passwords<br></blockquote>leaked,<br><blockquote type="cite"> then Connect without TLS is arguably no worse than the<br></blockquote>current situation<br><blockquote type="cite"> and arguably better because at-least the user is not leaking<br></blockquote>the<br><blockquote type="cite"> password.<br><br><br> So do we allow the bad thing to prevent the worse thing?<br><br><br> This makes code more likely to leak, and there is no real<br></blockquote>protection<br><blockquote type="cite"> possible other than using a hmac of the device fingerprint as<br></blockquote>the nonce,<br><blockquote type="cite"> but a TLS cert for the client is much simpler.<br><br><br> John B.<br><br> On 2013-10-24, at 11:37 AM, Mike Jones<br></blockquote><Michael.Jones@microsoft.com><br><blockquote type="cite"> wrote:<br><br> John, you wrote: “At the IIW F2F we took a decision that we<br></blockquote>should<br><blockquote type="cite"> match the RFC and require the client to have a TLS endpoint<br></blockquote>if using a<br><blockquote type="cite"> http redirect.(not a custom scheme)”. While the working<br></blockquote>group was<br><blockquote type="cite"> leaning that way early in the discussion, Naveen and others<br></blockquote>pushed back,<br><blockquote type="cite"> and that doesn’t actually match the decision that we recorded<br></blockquote>in the<br><blockquote type="cite"> notes, which say:<br> OP may prevent registration of redirect_uris that do not use<br> https<br> A confidential client needs to be required to use http<br> We will discuss this further on the list<br><br> Consider this the start of the further discussion on the<br></blockquote>list. What do<br><blockquote type="cite"> people think?<br><br> -- Mike<br><br> From: openid-specs-ab-bounces@lists.openid.net<br> [mailto:openid-specs-ab-bounces@lists.openid.net] On Behalf<br></blockquote>Of John<br><blockquote type="cite"> Bradley<br> Sent: Thursday, October 24, 2013 5:42 AM<br> To: Vladimir Dzhuvinov / NimbusDS<br> Cc: openid-specs-ab@lists.openid.net<br> Subject: Re: [Openid-specs-ab] First Release Candidates for<br></blockquote>final OpenID<br><blockquote type="cite"> Connect specifications<br><br><br><br> Snip<br> On 2013-10-24, at 1:36 AM, "Vladimir Dzhuvinov / NimbusDS"<br> <vladimir@nimbusds.com> wrote:<br><br><br><br><br><br><br> "When using this flow, the redirection URI<br> MAY use the http scheme,<br> provided that the Client Type is confidential, as defined in<br></blockquote>Section 2.1<br><blockquote type="cite"> of OAuth 2.0; otherwise, it MUST use the https scheme" -<br></blockquote>This,<br><blockquote type="cite"> surprisingly enough, is relaxed in comparison<br> tohttp://tools.ietf.org/html/rfc6749#section-10.5.<br><br> RFC 6749 states: "Authorization codes operate as plaintext<br></blockquote>bearer<br><blockquote type="cite"> credentials, used to verify that the resource owner who<br></blockquote>granted<br><blockquote type="cite"> authorization at the authorization server is the same<br></blockquote>resource owner<br><blockquote type="cite"> returning to the client to complete the process. Therefore,<br></blockquote>if the<br><blockquote type="cite"> client relies on the authorization code for its own resource<br></blockquote>owner<br><blockquote type="cite"> authentication, the client redirection endpoint MUST require<br></blockquote>the use of<br><blockquote type="cite"> TLS."<br><br> Why is Connect, in this particular case, less restrictive<br></blockquote>than OAuth?<br><blockquote type="cite"><br><br><br> John, can you speak to why we’re allowing http redirect_uri<br></blockquote>values<br><blockquote type="cite"> when apparently OAuth<br> doesn’t?<br><br> I had some questions on this point as well. I believe the<br></blockquote>thinking is<br><blockquote type="cite"> that since the client is protecting the secret and the code<br></blockquote>is sent to<br><blockquote type="cite"> the /token endpoint with client authentication, even if<br></blockquote>someone was able<br><blockquote type="cite"> to hijack the code value they couldn't exchange it for the<br></blockquote>access (and<br><blockquote type="cite"> possibly refresh) tokens. If we are trying to make things<br></blockquote>simpler, then<br><blockquote type="cite"> just moving all of it to TLS makes sense. To me, the only<br></blockquote>exception is<br><blockquote type="cite"> localhost. <br><br> The attacker could inject the authorization code into the<br></blockquote>same<br><blockquote type="cite"> application as used by the victim in order to impersonate<br></blockquote>her/him.<br><blockquote type="cite"><br><br> For this to happen the attacker should also have gained<br></blockquote>control over the<br><blockquote type="cite"> RP (the application), i.e. have the RPs' authentication<br></blockquote>credentials.<br><blockquote type="cite"><br><br><br><br><br><br> Early OAuth 2 inherited the idea from OAuth 1 that the client<br></blockquote>didn't<br><blockquote type="cite"> need to have a TLS cert. We were matching that. At the IIW<br></blockquote>F2F we took<br><blockquote type="cite"> a<br> decision that we should match the RFC and require the client<br></blockquote>to have a<br><blockquote type="cite"> TLS endpoint if using a http redirect.(not a custom scheme)<br><br><br><br> Earlier in this thread there is also a question about exact<br></blockquote>redirect_uri<br><blockquote type="cite"> matching and if it is required for confidential clients. In<br></blockquote>the code<br><blockquote type="cite"> flow if the token is leaked through an open redirector then<br></blockquote>it can be<br><blockquote type="cite"> presented to the real client and the attacker gets in as the<br></blockquote>user.<br><blockquote type="cite"><br><br><br> The OAuth AS side mitigation of this is the confidential<br></blockquote>client passing<br><blockquote type="cite"> the redirect URI to the AS in the token request and the AS<br></blockquote>performing an<br><blockquote type="cite"> exact match on the redirect URI, and failing if it is<br></blockquote>different. In<br><blockquote type="cite"> the wild it appears AS are also not being sufficiently strict<br></blockquote>on<br><blockquote type="cite"> matching that and causing some problems in deployments.<br><br><br><br> The client side mitigation for this is using nonce in the<br></blockquote>signed token<br><blockquote type="cite"> to allow the client to check on its own if it initiated the<br> request<br> through the same browser that presented the code. However<br></blockquote>that was left<br><blockquote type="cite"> as optional for code.<br><br><br><br> At the end of the day the reality is that some of the large<br></blockquote>IdP only<br><blockquote type="cite"> allow exact matching of redirect_uri. If some are strict<br></blockquote>and some<br><blockquote type="cite"> allow query parameters then clients using query parameters to<br></blockquote>carry<br><blockquote type="cite"> state will fail and not be interoperable.<br><br><br><br> The WG decided that the strict matching of the redirect_uri<br></blockquote>by those IDP<br><blockquote type="cite"> is allowed by the RFC, rather than forcing them to change<br></blockquote>and do<br><blockquote type="cite"> pattern matching for interoperability we precluded clients<br></blockquote>from hiding<br><blockquote type="cite"> state in the query parameters and forced them to use the<br></blockquote>"state"<br><blockquote type="cite"> parameter.<br><br><br><br> So yes for a fully RFC compliant OAuth server with a client<br></blockquote>that is<br><blockquote type="cite"> truly confidential and not just pretending, it would be<br></blockquote>secure for the<br><blockquote type="cite"> AS to relax the matching for the redirect_uri in the request<br></blockquote>to the<br><blockquote type="cite"> authorization server as<br> long as it records that URI and is doing an<br> exact string match on it aginst the one sent to the token<br></blockquote>endpoint. It<br><blockquote type="cite"> is not however safe for a client to assume all AS are going<br></blockquote>to act that<br><blockquote type="cite"> way. The only safe thing for the client is to assume exact<br></blockquote>string<br><blockquote type="cite"> match.<br><br><br><br> So while this relates to security issues the final decision<br></blockquote>was taken<br><blockquote type="cite"> for interoperability of the client.<br><br><br><br> John B.<br><br><br></blockquote>______________________________________________________________<br><blockquote type="cite"><br> Openid-specs-ab mailing list<br> Openid-specs-ab@lists.openid.net<br> http://lists.openid.net/mailman/listinfo/openid-specs-ab<br></blockquote></blockquote><br></blockquote><br></body></html>