Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0

From: Mark Mcgloin <[email-masked]>
Date: Fri, 13 May 2011 11:40:33 +0100

Does anyone know of a formal security protocol analysis that has been
carried out for OAuth 2.0?

I could only find analysis done against 1.0a, like this one:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5762765

thanks
Mark

---

From: Francisco Corella <[email-masked]>
Date: Fri, 13 May 2011 09:58:01 -0700 (PDT)

We wrote a security analysis of double redirection protocols that has a section on OAuth 2.0 as of draft 11.  You can find it at http://pomcor.com/techreports/DoubleRedirection.pdf

Francisco

--- On Fri, 5/13/11, Mark Mcgloin <[email-masked]> wrote:

From: Mark Mcgloin <[email-masked]>
Subject: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0
To: [email-masked]
Date: Friday, May 13, 2011, 10:40 AM

thanks
Mark

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Doug Tangren <[email-masked]>
Date: Fri, 13 May 2011 13:49:52 -0400

-Doug Tangren
http://lessis.me

On Fri, May 13, 2011 at 12:58 PM, Francisco Corella <[email-masked]>wrote:

> We wrote a security analysis of double redirection protocols that has a
> section on OAuth 2.0 as of draft 11.  You can find it at
> http://pomcor.com/techreports/DoubleRedirection.pdf
>
>
Wow, this looks really informative. Thanks!

---

From: Mark Mcgloin <[email-masked]>
Date: Sat, 14 May 2011 12:09:52 +0100

Hi Francisco

Yes, I have seen that report in the past and it is good and informative but
is not a substitute for formal analysis. Here is another example of the
type of analysis I am looking for, this one covering Oauth 1.0a from our
research lab

http://domino.watson.ibm.com/library/cyberdig.nsf/papers/B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf

Regards
Mark

Francisco Corella <[email-masked]> wrote on 13/05/2011 17:58:01:

> Francisco Corella <[email-masked]>
> 13/05/2011 17:58
>
> Please respond to
> [email-masked]
>
> To
>
> [email-masked], Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> Subject
>
> Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0
>
> We wrote a security analysis of double redirection protocols that
> has a section on OAuth 2.0 as of draft 11.  You can find it at

---

From: Francisco Corella <[email-masked]>
Date: Sun, 15 May 2011 16:19:37 -0700 (PDT)

Hi Marc,

You're right, the report I referred to is not a formal analysis.

Thanks for the reference to the your lab's analysis of OAuth 1.0a.  I had a quick look at it, and at the Canetti tutorial on the underlying methodology that the paper refers to.  It's interesting, but so complicated!

It's a pity that your colleagues missed the flaw in OAuth 1.0a.  In section 5.4 they say "We assume that the Consumer and Service Providers have public keys (and certificates) and that the end-user communicates with theses server entities over secure channels (SSL/TLS)".  If instead of assuming it they had checked the spec they would have seen that that's not true for the consumer, and they would have been able to claim an important practical result :-)

Francisco

--- On Sat, 5/14/11, Mark Mcgloin <[email-masked]> wrote:

From: Mark Mcgloin <[email-masked]>
Subject: Re: [OAUTH-WG] Formal security protocol analysis of OAuth 2.0
To: [email-masked]
Cc: [email-masked]
Date: Saturday, May 14, 2011, 11:09 AM

Hi Francisco

Regards
Mark

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 16 May 2011 04:02:25 -0400

The approach looks right to me; the key is that the 1.0 state machine is 
rather simple.  A priori, I don't see the 2.0 as more complex (even 
though it involves an additional machine), and I think it should be 
straight-forward to build the machine and run the reachability analysis 
on the system graph.

The conclusions of this paper puzzle me though.  There are things that I 
simply do not understand. For instance, what does this mean: "The 
current OAuth specification uses nonce, timestamps and signatures to 
guard against possible attacks. If the API interfaces are secure, they 
are not needed. On the other hand, if the API interfaces are insecure, 
they are not sufficient to guarantee the desired security properties."

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 16 May 2011 04:45:23 -0400

Mark,

Many thanks for posting this.  I am thinking of the next step.

This paper proposes to use the Password-Based Asymmetric Key Exchange 
protocol.  Many messages ago, I had proposed to use the Password-Based 
DH key exchange for the symmetric key generation.

Another option is to mandate some  form of PKI for all OAuth actors.  

I did not want to bring this discussion until 2.0 is finished and 
published. (I do believe that the current security analysis and 
considerations lead by Torsten has been comprehensive, and therefore 2.0 
ought to move to conclusion.) 

For the future, maybe you could work with your colleagues to compare the 
PBAKE and PAK specifically as they apply to OAuth? You might also 
consider publishing PBAKE in the IETF.

Igor

Mark Mcgloin wrote:
> ...
> Here is another example of the

---

From: Mark Mcgloin <[email-masked]>
Date: Mon, 16 May 2011 11:52:52 +0100

Hi Igor, comments Inline below

Igor Faynberg <[email-masked]> wrote on 16/05/2011
09:02:25:

> Igor Faynberg <[email-masked]>
> 16/05/2011 09:02
>
> Please respond to
> [email-masked]
>
> To
>
> Mark Mcgloin/Ireland/IBM@IBMIE
>
> cc
>
> [email-masked]
>
> Subject
>

I think the part of the 2.0 spec most people would like to scrutinise is
the implicit grant flow with no secret although I suspect the conclusion
may be that the user has to 100% trust the consumer povider

> they are not sufficient to guarantee the desired security properties."

So they claim that signing is ineffective over http!

---

From: Mark Mcgloin <[email-masked]>
Date: Mon, 16 May 2011 11:53:59 +0100

Hi Igor, I will pass on your comments

Regards
Mark

09:45:23:

> 16/05/2011 09:45
> [email-masked], [email-masked]
>
> Subject
>
> > http://domino.watson.ibm.com/library/cyberdig.nsf/papers/
> B0D33665257DD3A0852576410043BCDD/$File/rc24856.pdf
> >
> >
> >
> >