Hi John, On 28/02/16 01:15, John Bradley wrote: > If the malicious client is registering it’s own redirect URI then option A > won’t help. > > On the other hand the Good AS should identify the malicious client to the > user.
How could that be done in practice, especially with an AS that provides a channel for dynamic discovery and registration? > I think this is a separate problem of client impersonation being used for > Phishing. > > This is really a case of bad guy registers client and phishes the user to > login pretending to be some other client. > > That can all be done with the good client not being involved at all. OK. Vladimir > > John B. > >> On Feb 27, 2016, at 1:16 PM, Vladimir Dzhuvinov <vladi...@connect2id.com> >> wrote: >> >> Hi Brian, >> >> On 27/02/16 00:27, Brian Campbell wrote: >>> My preference is for Option A. >>> >>> The mix-up attack, in all it's variations, relies on there being no means >>> in OAuth for the AS to identify itself to the client when it returns the >>> user's browser to the client's redirect_uri. 'OAuth 2.0 Mix-Up Mitigation' >>> addresses that fundamental missing piece by including the 'iss' >>> authorization response parameter. >> This fundamental piece is indeed missing. I'm not sure measure "A" can >> also cover dynamic discovery and registration though. The mixup attack >> was originally described there, with OpenID Connect. >> >> How about this variation: >> >> Suppose the malicious IdP: >> >> 1. Registers the client under attack for >> a) malicious authz endpoint >> b) malicious token endpoint (optional) >> >> ... while also acting as proxy, where there are two variants: >> a) repeats the client registration with the honest IdP to obtain >> client_id + credentials that it keeps for itself; or >> b) is already registered as a client with the honest IdP >> >> Then: >> >> 1. When the authz request is made to the malicious authz endpoint, the >> request is rewritten with the client_id and redirect_uri which the >> malicious IdP has with the honest IdP. The state may or may not be replaced. >> >> 2. The browser is then given a second redirect with the rewritten >> parameters to the authz endpoint of the honest IdP. >> >> 3. The user doesn't notice this double redirect, and logs in / gives >> consent. >> >> 4. The honest IdP sends the browser back to the registered malicious >> redirect_uri. The attacker receives the code or tokens (depending on the >> response type) >> >> 5. A second redirect is made back to the redirect_uri of the client, >> with rewritten state, iss, client_id >> >> >> What is your take on this? >> >> The ideal fix for me would be one that covers dynamic discovery and >> registration as well. I'm not convinced option A does that. >> >> Cheers, >> >> Vladimir >> >>> During the course of the discussions in Darmstadt Hans and I independently >>> implemented and successfully interop tested the 'iss' and 'client_id' >>> authorization response parameters, which is what was anticipated to be in >>> the mitigation draft. Doing so was very simple and straightforward. And it >>> addresses the vulnerability. We decided, unfortunately, to pull that >>> functionality out of a looming a product release due to the churn in this >>> WG and the perceived risk of changes in what would eventually become the >>> standard solution. Of course, that kind of risk is always present with >>> draft standards but it's been very frustrating in this case to have worked >>> towards a simple solution to a known problem only to have progress get hung >>> up in lack of agreement in this WG. >>> >>> I'll also say that in many/most cases the AS doesn't explicitly know all of >>> the resources that tokens it issues can or will be used at (and there are >>> often more than one). So the ruri/Resource URI parameter isn't really a >>> workable option. >>> >>> >>> >>> On Thu, Feb 25, 2016 at 12:43 AM, Hannes Tschofenig < >>> hannes.tschofe...@gmx.net> wrote: >>> >>>> Vladimir, >>>> >>>> yes, we could do a formal analysis and it would be a very good idea. >>>> It would even go faster if a few of us work together on it. Anyone >>>> interested? >>>> >>>> This would be a good contribution for the workshop in July, btw. >>>> >>>> Ciao >>>> Hannes >>>> >>>> On 02/23/2016 10:09 AM, Vladimir Dzhuvinov wrote: >>>>> Hi Mike, >>>>> >>>>> You mention that you spent considerable time in research. I wonder if >>>>> there is existing theory, in communications or information theory, that >>>>> can be used to formally establish and prove (or disprove) the security >>>>> of the proposed OAuth measures? Perhaps some work that is totally >>>>> unrelated to identity and the web protocols, but could well apply here? >>>>> >>>>> My reasoning is that we have a closed system that is fairly simple, so >>>>> formal analysis must be entirely possible. >>>>> >>>>> 1. We have 5 parties (client, AS, RS, user, user agent). >>>>> >>>>> 2. The OAuth protocol follows a simple and well-defined pattern of >>>>> messages between the parties. >>>>> >>>>> 3. The points and the number of ways by which an adversary may break >>>>> into OAuth must therefore be finite. >>>>> >>>>> 4. The security requirement is essentially to guarantee the precedence >>>>> and authenticity of the messages from discovery endpoint to RS, and the >>>>> preferred way to do that is by establishing a binding between the >>>>> messages, which can be forward or backward binding. >>>>> >>>>> >>>>> Right now the WG concern is whether all possible attacks have been >>>>> recognised, and then taken care of. If we can have a formal model that >>>>> can reliably reveal and prove that, this will be a huge breakthrough. >>>>> >>>>> Cheers, >>>>> >>>>> Vladimir >>>>> >>>>> >>>>> >>>>> On 20/02/16 12:41, Mike Jones wrote: >>>>>> Suggesting that they be read is of course, the right long-term >>>> approach. But as someone who spent 20+ years as a researcher before >>>> switching to digital identity, I was sensitive to not wanting to upstage >>>> their work by copying too much of their material into our draft before >>>> their publications were widely known. I'll of course commit to working the >>>> researchers and the working group to create a self-contained concise >>>> description of the threats and mitigations in the working group document. >>>>>> Cheers, >>>>>> -- Mike >>>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] >>>>>> Sent: Saturday, February 20, 2016 2:25 AM >>>>>> To: Mike Jones <michael.jo...@microsoft.com>; William Denniss < >>>> wdenn...@google.com>; Phil Hunt (IDM) <phil.h...@oracle.com> >>>>>> Cc: oauth@ietf.org >>>>>> Subject: Re: [OAUTH-WG] Fixing the Authorization Server Mix-Up: Call >>>> for Adoption >>>>>> Hi Mike, >>>>>> >>>>>> On 02/20/2016 10:52 AM, Mike Jones wrote: >>>>>>> Have you read both of their publications? If not, do yourself a favor >>>>>>> and do. They're actually both very readable and quite informative. >>>>>> I have read both documents. In context of this discussion the question >>>> is whether we >>>>>> (a) require them to be read (in which case they should be a normative >>>> reference), or >>>>>> (b) suggest them to be read (since they provide additional background >>>> information). In this case they are an informative reference. >>>>>> I believe believe we want (b) for the OAuth WG document. While I >>>> encourage everyone to read the publications I also believe that there is >>>> lots of material in there that goes beyond the information our audience >>>> typically reads (such as the text about the formal analysis). >>>>>> There is probably also a middle-ground where we either copy relevant >>>> text from the papers into the draft or reference specific sections that are >>>> "must-read". >>>>>> One other issue: I actually thought that the threat that is outlined in >>>> the research paper is sufficiently well described but the second threat, >>>> which is called 'cut-and-paste attack', requires more work. >>>>>> I noted this in my summary mail to the list, see >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15697.html >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
