Re: [OAUTH-WG] requirement of redirect_uri in access token requests

"Freeman, Tim" <tim.freeman@hp.com> Mon, 02 May 2011 18:34 UTC

Return-Path: <tim.freeman@hp.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 E0CBDE06FA for <oauth@ietfa.amsl.com>; Mon, 2 May 2011 11:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5BamIfBLDvA for <oauth@ietfa.amsl.com>; Mon, 2 May 2011 11:34:41 -0700 (PDT)
Received: from g1t0027.austin.hp.com (g1t0027.austin.hp.com [15.216.28.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18FE06E6 for <oauth@ietf.org>; Mon, 2 May 2011 11:34:41 -0700 (PDT)
Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0027.austin.hp.com (Postfix) with ESMTPS id 0E4DF38508 for <oauth@ietf.org>; Mon, 2 May 2011 18:34:40 +0000 (UTC)
Received: from G4W1853.americas.hpqcorp.net (16.234.97.231) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 2 May 2011 18:33:19 +0000
Received: from GVW0432EXB.americas.hpqcorp.net ([16.234.32.146]) by G4W1853.americas.hpqcorp.net ([16.234.97.231]) with mapi; Mon, 2 May 2011 18:33:18 +0000
From: "Freeman, Tim" <tim.freeman@hp.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Date: Mon, 02 May 2011 18:33:16 +0000
Thread-Topic: [OAUTH-WG] requirement of redirect_uri in access token requests
Thread-Index: AcwHfbavTY9JB/rmQF28aGavrZ23jABdMjGA
Message-ID: <59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8@GVW0432EXB.americas.hpqcorp.net>
References: <BANLkTinLODGc4sK+pwg9iLqMHkakj-vYNg@mail.gmail.com> <BANLkTi=HKhPnxRpqg6XyqCG0pePg3CVs9A@mail.gmail.com>
In-Reply-To: <BANLkTi=HKhPnxRpqg6XyqCG0pePg3CVs9A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_59DD1BA8FD3C0F4C90771C18F2B5B53A65454DDBE8GVW0432EXBame_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests
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, 02 May 2011 18:34:43 -0000

The issues around redirect_uri seem muddled to me.  Here's what I know right now:

Brian Eaton apparently said:
>This provides a defense against authorization codes which have leaked due to open redirectors.

I looked for "redirector" in

   http://tools.ietf.org/html//draft-lodderstedt-oauth-security-01

which is apparently the latest draft of the security considerations document.  The only mention is in section 4.2.4 under "Threat: Open redirector", which I can quote in full:

   An attacker could use the end-user authorization endpoint and the
   redirect_uri parameter to abuse the authorization server as
   redirector.

   Impact?

   Countermeasure
   o  don't redirect to redirect_uri, if client identity or redirect_uri
      could not be verified

I don't know what this means.  The word "abuse" is vague, and the "Impact" section is blank.  At least in the bearer token version of the protocol, I believe we do all of our redirecting before verifying the client identity, so I don't see how we can know whether the client identity can be verified when we're deciding whether to redirect.   It would help to have a specific sequence of events that is undesired.  I can't tell if this only mention of "redirector" in Torsten Lodderstedt's document matches what Brian was talking about.

I talked some about whether we need the redirect_uri at:

   http://www.ietf.org/mail-archive/web/oauth/current/msg05733.html

Judging by the "Next by thread" link on that page, nobody replied to this.  I do not think the failure scenario I described involves an open redirector, so I think the problem I described (if the redirect_uri is not checked) is different from Brian's.  I haven't read the security considerations document carefully enough to know whether the failure scenario I described appears in it.

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Eaton
Sent: Saturday, April 30, 2011 2:29 PM
To: Doug Tangren
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] requirement of redirect_uri in access token requests

On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren <d.tangren@gmail.com<mailto:d.tangren@gmail.com>> wrote:
Is this required or not? In the example http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed in the example but not itemized as optional or required. It's not in the example for refreshing tokens http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-6 though that section links back to section 3.1 which does use a redirect_uri in the example.

Should the redirect_uri be a requirement for client authentication or is it optional?

It should be required when exchanging an authorization code for a refresh token.  This provides a defense against authorization codes which have leaked due to open redirectors.

It should not be present under other circumstances.