Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"

Vineet Banga <vineetbanga@google.com> Tue, 19 November 2019 05:39 UTC

Return-Path: <vineetbanga@google.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 BC89F120801 for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 21:39:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.499
X-Spam-Level:
X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxT2o9X4amXk for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 21:39:03 -0800 (PST)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1C1120013 for <oauth@ietf.org>; Mon, 18 Nov 2019 21:39:03 -0800 (PST)
Received: by mail-qt1-x836.google.com with SMTP id o3so23260371qtj.8 for <oauth@ietf.org>; Mon, 18 Nov 2019 21:39:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8nZc80IXL1LAHF0AktClVNQpnNKSb617AE497eJCeZA=; b=Q8gZn9pTjFX/9LTtbOpGDOOtJThqZvaldrPJCILzDcD8VnPlTQiqV/RAOhBEdyn1tX ZJabR3WSCbm7R6DNh3IL4+t0xLe4QLVuPoehRzOEBTcCU33Hm3Fxuaup0GueQt6hAZ1U D59HdRuab088QZfcPx1avzNgFR+Kja3PmM6d0cl9dtwyb9ElSr37Tl2R16T+7D1qeSe+ AsCsoCmArNNjtrtKVYtF7NTgpY644ir+3GlsYjlesFeY9l0hRpnfKaJXE/czdDgI7zNr DoPMuyOW3XYjJUesCKWUnhssustR1eiMe+ypuV5NwZfeRVWbb1U0M2VghcsHgFGFUGCS j3mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8nZc80IXL1LAHF0AktClVNQpnNKSb617AE497eJCeZA=; b=AbivAZGOOtHxhPhbuEDq0ruvC93rXHJTtow5g61zmsuw02iXlZMDr+ZX6yUqgFCsBl y73GZrThXUQm+voIZy+ZqzcZ07+ALoryWcf7ro0Wsol2vimM7U6cicF5xGVVRlbmMWsE jdENYXLlwNztT1tl3BPpK90koHOAJFLUnPYR8H4mu6oPiL7YV6QiWH82a6bS8DkXpI4c MzT3UWXTqWmeEsxOaO+BXRq3St4dZfF54gGzKBWgKH9IC2e0d/7ma3ya3cO8RivXHoLp ToE/IhonXrXC7Nz83eGM035iUPu0ZF2D7xukFRxL/gcqr+ICK+rFamT1vtdvmrHSey76 pX8g==
X-Gm-Message-State: APjAAAXwYNfjIhN1KrH17UkTnAc4yueNPLLziO5LPuhzNBtd1D3Lydkc +AhWhZ3qtdJAJQelw5NcxTKBpw6XMdBPysJS69nOgYibic39xA==
X-Google-Smtp-Source: APXvYqzVTj16kWdxSj4xg50SOt+eOmAP1VCV7AKXH8mKpviWZU5vGEfCGfKFA+glFN8FfPM+0jXzjjDMn3sWk8SZ65k=
X-Received: by 2002:ac8:2dbd:: with SMTP id p58mr31291788qta.281.1574141941680; Mon, 18 Nov 2019 21:39:01 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR08MB5360FBBAF0D3A38BDBED618BFA790@VI1PR08MB5360.eurprd08.prod.outlook.com> <CAPHqeLd4szopBOVFUyThhx5X7bW2izB+nPKCzZ+1b5efB3wF_g@mail.gmail.com> <3FE840EE-9261-414E-8AB7-B75BD8BA6F86@lodderstedt.net> <CAPHqeLeA00FwSLv-ry7pCKguS+4RfnOC-PEBh6t4eoTU_GbY-Q@mail.gmail.com> <1FA4D2C5-AE20-4A24-B5A3-2B7B55529C23@lodderstedt.net>
In-Reply-To: <1FA4D2C5-AE20-4A24-B5A3-2B7B55529C23@lodderstedt.net>
From: Vineet Banga <vineetbanga@google.com>
Date: Tue, 19 Nov 2019 13:38:49 +0800
Message-ID: <CAPHqeLeo8qeZqCMGzLAdFsYu3bHtvYuhxuGxoC3va8yRzZ1JBA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000042fd1f0597ac7b60"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/YVNLI0cZYl9YifjaTizV60zpD1s>
Subject: Re: [OAUTH-WG] WGLC for "OAuth 2.0 Security Best Current Practice"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 19 Nov 2019 05:39:15 -0000

> > >> On 16. Nov 2019, at 02:07, Vineet Banga <vineetbanga=
40google.com@dmarc.ietf.org> wrote:
> > >>
> > >> Just one comment/question at the moment:
> > > >3.1.1 - Is there any recommendation around leveraging state vs using
multiple URIs (with exact match) to remember the application state of the
client? I have seen exploding list of registered redirect URIs, but am not
aware of any security issues around this usage. But would like to check if
there are any opinions on this matter..
> >
> > >The BCP recommends transaction specific one time use state values for
CSRF prevention. To achieve the same protection level with redirect URI’s
and exact match, one would need to register per transaction redirect URI
values.
> >
> > >Do your redirect URIs meet those requirements?
> > No. I think the options are using state for purely csrf or using
[I-D.bradley-oauth-jwt-encoded-state], which is called our in the BCP.
Using encoded jwt can be used to limit the number of redirect uris.

> So you are saying "state" is used for CSRF. Then what is the rational of
your original question? To move towards application state encoded in
redirect URIs?

Let me restate my original question. I agree with the usage of state for
CSRF protection, but it can also be used to capture the application state
(as specified in: [I-D.bradley-oauth-jwt-encoded-state]). I am asking if
there is any recommendation between using state for both csrf and
application state Vs. relying completely on redirect URIs to
maintain application state.

As an OAuth provider, I lean towards avoiding long and dynamic list of
redirect URIs. But I do understand that using state for both CSRF
protection and application state adds burden on clients/app developers.

Vineet


On Tue, Nov 19, 2019 at 10:25 AM Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

>
>
> > On 17. Nov 2019, at 05:42, Vineet Banga <vineetbanga@google.com> wrote:
> >
> >
> > On Fri, Nov 15, 2019 at 11:51 PM Torsten Lodderstedt <
> torsten@lodderstedt.net> wrote:
> >
> > >> On 16. Nov 2019, at 02:07, Vineet Banga <vineetbanga=
> 40google.com@dmarc.ietf.org> wrote:
> > >>
> > >> Just one comment/question at the moment:
> > > >3.1.1 - Is there any recommendation around leveraging state vs using
> multiple URIs (with exact match) to remember the application state of the
> client? I have seen exploding list of registered redirect URIs, but am not
> aware of any security issues around this usage. But would like to check if
> there are any opinions on this matter..
> >
> > >The BCP recommends transaction specific one time use state values for
> CSRF prevention. To achieve the same protection level with redirect URI’s
> and exact match, one would need to register per transaction redirect URI
> values.
> >
> > >Do your redirect URIs meet those requirements?
> > No. I think the options are using state for purely csrf or using
> [I-D.bradley-oauth-jwt-encoded-state], which is called our in the BCP.
> Using encoded jwt can be used to limit the number of redirect uris.
>
> So you are saying "state" is used for CSRF. Then what is the rational of
> your original question? To move towards application state encoded in
> redirect URIs?
>
> >
> >
> >
> >
> >
> > >
> > >
> > > On Wed, Nov 6, 2019 at 12:27 AM Hannes Tschofenig <
> Hannes.Tschofenig@arm.com> wrote:
> > > Hi all,
> > >
> > > this is a working group last call for "OAuth 2.0 Security Best Current
> Practice".
> > >
> > > Here is the document:
> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13
> > >
> > > Please send you comments to the OAuth mailing list by Nov. 27, 2019.
> > > (We use a three week WGLC because of the IETF meeting.)
> > >
> > > Ciao
> > > Hannes & Rifaat
> > >
> > > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> > >
> > > _______________________________________________
> > > 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
> >
>
>