Re: [OAUTH-WG] Auth Code Swap Attack

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 22 August 2011 05:54 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E50C21F86B1 for <oauth@ietfa.amsl.com>; Sun, 21 Aug 2011 22:54:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D53VW8Qh+k6 for <oauth@ietfa.amsl.com>; Sun, 21 Aug 2011 22:54:14 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id AB76E21F85A3 for <oauth@ietf.org>; Sun, 21 Aug 2011 22:54:14 -0700 (PDT)
Received: (qmail 18371 invoked from network); 22 Aug 2011 05:55:18 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.47) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Aug 2011 05:55:18 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Sun, 21 Aug 2011 22:55:18 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Phil Hunt <phil.hunt@oracle.com>, David Recordon <recordond@gmail.com>
Date: Sun, 21 Aug 2011 22:53:54 -0700
Thread-Topic: [OAUTH-WG] Auth Code Swap Attack
Thread-Index: AcxgjcIRXJJUdfv9R2iqyTyOj7ZYeQAAHTDQ
Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234518A292F66@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <B26C1EF377CB694EAB6BDDC8E624B6E723BA5043@SN2PRD0302MB137.namprd03.prod.outlook.com> <CA6AE9D9.17DE9%eran@hueniverse.com> <90C41DD21FB7C64BB94121FBBC2E7234502498CE8D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E72345029DFA961@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E5148A8.8070903@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E7234518A292F49@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAB_mRgOWL17a_JJ7hZ1xJv5032scJ7fGE=42S=gjeaf_FNds_w@mail.gmail.com> <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com>
In-Reply-To: <27FB3C06-942B-487C-B780-7733BF50D6E4@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Auth Code Swap Attack
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2011 05:54:15 -0000

> -----Original Message-----
> From: Phil Hunt [mailto:phil.hunt@oracle.com]
> Sent: Sunday, August 21, 2011 10:39 PM
> To: David Recordon
> Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Auth Code Swap Attack
> 
> I think the complication here is that CSRF issues are multi-site issues where
> the attacker cross connecting his client with a victims resource, or a victims
> client with the attackers resource.
> 
> So while an individual site (e.g. Facebook) may presume little or no risk -
> there is a network effect here. A CSRF attacker could be using facebook to
> attack another site. See Yaron's original text about Plaxo/Live at the start of
> this thread.

It's still just a CSRF attack.
 
> Would it be reasonable to assess whether a resource site could make it
> mandatory based on a pre-registered client?  IOW, would Facebook want to
> make state mandatory for Confidential clients, but not public clients?

That's irrelevant. The authorization server has absolutely no way of verifying if the client is implementing a CSRF protection properly. Making 'state' required does not accomplish such an enforcement. A client can pass the proposed text requirement with "state=ni".

> Would it be acceptable to change status from OPTIONAL to RECOMMENDED?

Parameters are either required or optional. We can makes it optional and recommended for a particular purpose which is consistent with the existing text.

It should be mandatory to implement CSRF protection. We agree on that and should add it to the text. We also agree that 'state' is a great way of implementing it and should recommend it. We already do that in the security consideration section and can enhance that when defining the 'state' parameter.

EHL