Hi Mike, Isn’t Nat’s "OAuth Response Metadata” spec enough to solve those issues? https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt <https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt>
> On Jan 12, 2016, at 05:40, Mike Jones <michael.jo...@microsoft.com> wrote: > > The specification describes this validation method (comparison of the issuer > received to the issuer recorded at registration time) in step 2 of Section 4 > (Validating the Response). In fact, I added this in response to your > feedback on an earlier draft, Hans. > > -----Original Message----- > From: Hans Zandbelt [mailto:hzandb...@pingidentity.com > <mailto:hzandb...@pingidentity.com>] > Sent: Monday, January 11, 2016 12:34 PM > To: Mike Jones <michael.jo...@microsoft.com > <mailto:michael.jo...@microsoft.com>>; George Fletcher <gffle...@aol.com > <mailto:gffle...@aol.com>>; oauth@ietf.org <mailto:oauth@ietf.org> > Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > I disagree that validating endpoints "at this step" (which refers to right > before making the token request) should be the default way of handling this. > The vast majority of OAuth client deployments connecting to more than one AS > will have a static configuration of the ASes issuer/endpoint information > anyhow and they just need to confirm that the issuer value received in the > authorization response is the same issuer as that the request was sent to. > > Hans. > > On 1/11/16 1:14 PM, Mike Jones wrote: >> Correct >> >> *From:*George Fletcher [mailto:gffle...@aol.com] >> *Sent:* Monday, January 11, 2016 12:13 PM >> *To:* Mike Jones <michael.jo...@microsoft.com>; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >> >> So just to make sure I understand... >> >> This specification requires the response from the Authorization Server >> to an successful /authorize call to pass back code=, state= and jwt= (?) >> or individually iss= and aud= as URL parameters on the 302 to the >> redirect_url. This way, before the client issues a call to the /token >> endpoint (with the code), it can verify that the token endpoint is correct. >> >> If the client doesn't validate the endpoints at this step, then it could >> disclose it's secret to a malicious endpoint. Correct? >> >> Thanks, >> George >> >> On 1/11/16 2:59 PM, Mike Jones wrote: >> >> The alternatives for the code flow are to return them either in a >> new JWT added to the reply containing them in the "iss" and "aud" >> claims or to return them in new individual "client_id" and "iss" >> authorization response parameters. Both alternatives are described >> in the draft. I'm sure that we'll now be having a good engineering >> discussion on the tradeoffs between the alternatives., >> >> In a separate draft, John Bradley will shortly also be describing >> the possibility of securing the "state" value using a "state_hash" >> value that works in a way that's similar to how "at_hash" and >> "c_hash" secure the "access_token" and "code" values in Connect. >> This would be an alternative means of binding the authorization >> request and response to the session - accomplishing the same thing >> that the Connect "nonce" does. >> >> While I fully get that some OAuth implementations want to avoid >> having to have crypto, it seems like at least support for >> cryptographic hashing (SHA-256, etc.) may be necessary to mitigate >> some of these attacks (at least for clients that use more than one >> authorization server). >> >> The other important engineering discussion I know we're going to >> have is whether, when an OAuth profile already returns the >> information needed for the mitigation, whether we want to specify >> that the client obtain it from the existing location, or whether to >> also return it in a duplicate location. I'll note that OpenID >> Connect already returns the client ID and issuer for the flows that >> return an ID Token in the authorization response, so this isn't a >> hypothetical question. >> >> Finally, I know that we'll need to discuss the impact of >> cut-and-paste attacks when the issuer and client ID are returned as >> individual authorization response parameters that are not >> cryptographically bound to the rest of the response. The >> cut-and-paste attack that returning the issuer and client_id values >> as separate parameters enables, even when state_hash or nonce is >> used, is for the attacker to capture the legitimate response >> containing "iss" and "client_id" results and substitute different >> values for these fields, then post that altered response to the >> legitimate client. The state and/or nonce values are protected >> against substitution but "iss" and "client_id" are not. >> >> And yes, I absolutely agree that good examples are essential. >> That's high on my list for the -01 version. >> >> Thanks a >> bunch, >> >> -- Mike >> >> *From:*George Fletcher [mailto:gffle...@aol.com] >> *Sent:* Monday, January 11, 2016 10:21 AM >> *To:* Mike Jones <michael.jo...@microsoft.com> >> <mailto:michael.jo...@microsoft.com >> <mailto:michael.jo...@microsoft.com>>; oauth@ietf.org <mailto:oauth@ietf.org> >> <mailto:oauth@ietf.org <mailto:oauth@ietf.org>> >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >> >> Thanks Mike. One question after reading about the different attack >> vectors and this spec... >> >> How are the 'iss' and 'aud' values returned with the 'code' and >> 'state' parameters. It seems the client needs to verify the >> endpoints before making the request to exchange the code for a >> token. If the client is using the default OAuth2 client_id and >> client_secret these values will be sent to the malicious endpoint if >> the client can't verify the endpoints before hand. >> >> Also, it would be nice to add some non-normative examples to the spec. >> >> Thanks, >> George >> >> On 1/11/16 4:27 AM, Mike Jones wrote: >> >> Yesterday Hannes Tschofenig announced an OAuth Security Advisory >> on Authorization Server Mix-Up >> >> <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w >> <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>>. >> This note announces the publication of the strawman OAuth 2.0 >> Mix-Up Mitigation draft he mentioned that mitigates the attacks >> covered in the advisory. The abstract of the specification is: >> >> This specification defines an extension to The OAuth 2.0 >> Authorization Framework that enables an authorization server to >> provide a client using it with a consistent set of metadata >> about itself. This information is returned in the authorization >> response. It can be used by the client to prevent classes of >> attacks in which the client might otherwise be tricked into >> using inconsistent sets of metadata from multiple authorization >> servers, including potentially using a token endpoint that does >> not belong to the same authorization server as the authorization >> endpoint used. Recent research publications refer to these as >> "IdP Mix-Up" and "Malicious Endpoint" attacks. >> >> The gist of the mitigation is having the authorization server >> return the client ID and its issuer identifier (a value defined >> in the OAuth Discovery specification >> <http://self-issued.info/?p=1496 <http://self-issued.info/?p=1496>>) >> so that the client can verify >> that it is using a consistent set of authorization server >> configuration information, that the client ID is for that >> authorization server, and in particular, that the client is not >> being confused into sending information intended for one >> authorization server to a different one. Note that these >> attacks can only be made against clients that are configured to >> use more than one authorization server. >> >> Please give the draft a quick read and provide feedback to the >> OAuth working group. This draft is very much a starting point >> intended to describe both the mitigations and the decisions and >> analysis remaining before we can be confident in standardizing a >> solution. Please definitely read the Security Considerations >> and Open Issues sections, as they contain important information >> about the choices made and the decisions remaining. >> >> Special thanks go to Daniel Fett (University of Trier), >> Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov >> (Ruhr-University Bochum), and Guido Schmitz (University of >> Trier) for notifying us of the attacks and working with us both >> on understanding the attacks and on developing mitigations. >> Thanks too to Hannes Tschofenig for organizing a meeting on this >> topic last month and to Torsten Lodderstedt and Deutsche Telekom >> for hosting the meeting. >> >> The specification is available at: >> >> *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >> <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00> >> >> An HTML-formatted version is also available at: >> >> >> *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html >> <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html> >> >> -- Mike >> >> P.S. This note was also posted at >> http://self-issued.info/?p=1524 <http://self-issued.info/?p=1524> and >> as @selfissued >> <https://twitter.com/selfissued <https://twitter.com/selfissued>>. >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org >> <mailto:OAuth@ietf.org>> >> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> >> >> >> -- >> >> Chief Architect >> >> Identity Services Engineering Work:george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com> <mailto:george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com>> >> >> AOL Inc. AIM: gffletch >> >> Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch >> <http://twitter.com/gffletch> >> >> Office: +1-703-265-2544 >> Photos:http://georgefletcher.photography <http://georgefletcher.photography/> >> >> >> >> -- >> >> Chief Architect >> >> Identity Services Engineering Work:george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com> <mailto:george.fletc...@teamaol.com >> <mailto:george.fletc...@teamaol.com>> >> >> AOL Inc. AIM: gffletch >> >> Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch >> <http://twitter.com/gffletch> >> >> Office: +1-703-265-2544 Photos:http://georgefletcher.photography >> <http://georgefletcher.photography/> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> > > -- > Hans Zandbelt | Sr. Technical Architect > hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com> | Ping Identity > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
