Inline > On 01/03/16 16:33, John Bradley wrote: > Inline > >> On Mar 1, 2016, at 5:51 AM, Vladimir Dzhuvinov <vladi...@connect2id.com> >> wrote: >> >> 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? >> > Yes that is the question. I think client impersonation by lying to the AS > when registering a client as part of a phishing attack is going to become > more common. > > Getting a trusted AS to say you are Tripit or some trusted client when you > are really a bad guy is becoming a real problem. > This is however not directly connected to the client mix up issue, and needs > to be addressed separately. > > One thing we added to dynamic client registration was a software statement > that can lock down redirect URI for a given client. > In the case of Mobile Connect for Mobile network operators the proposal is > to have a trusted registration authority that validates clients and issues > them software statements to register at individual AS. > > Validating the developer/client will probably need to be a business process, > more stringent than just getting a developer account based on an email > address. One possibility might be to check if the redirect URI has a EV > certificate indicating the organization, or trust frameworks set up to > register clients for conformance with European data protection laws (yes with > safe harbour going away something like that might be required by AS to keep > on the good side of the law. Germany did take a run at this once, but it did > not work for the internet in a practical way) > > The biggest issue will probably be identifying native apps. Custom scheme > redirects are not real useful. > > On iOS and Android(beta) there are now ways for an app to claim a https: URI > that is controlled by the developer. > https://tools.ietf.org/html/draft-ietf-oauth-native-apps-00#page-9 > That in combination with software statements might be a useful way to > identify the client and display something useful at the AS. > > We need to do more work on this in my opinion. Thanks John for the exhaustive answer! How do you see this additional work?
Vladimir > > John B. > > > >>> 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 >> _______________________________________________ >> 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
