<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>