<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I agree.<br>
<br>
I just wanted to point out the different protection goals of TLS and the ID token.<br><br><div class="gmail_quote"><br>
<br>
John Bradley <ve7jtb@ve7jtb.com> schrieb:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<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, 2
013, 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 ent
ire
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 /> &
nbsp;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 /> &
nbsp;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 /> &n
bsp;
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 ma
y
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 /> &n
bsp;
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 /> &n
bsp;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"> possi
bly
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"> pres
ented
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"> &n
bsp;
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 /> lo
ng 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 /></blockquote></div></body></html>