[OAUTH-WG] OAuth Security -- Next Steps

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 25 July 2016 10:59 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 8F98112D5BF for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2016 03:59:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 d2pDr_eEQnl4 for <oauth@ietfa.amsl.com>; Mon, 25 Jul 2016 03:59:27 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A484D12D1AA for <oauth@ietf.org>; Mon, 25 Jul 2016 03:59:26 -0700 (PDT)
Received: from [192.168.10.131] ([195.149.223.151]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Meutp-1bggS20QC9-00OXrV for <oauth@ietf.org>; Mon, 25 Jul 2016 12:59:23 +0200
To: "oauth@ietf.org" <oauth@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <5795F109.9040403@gmx.net>
Date: Mon, 25 Jul 2016 12:59:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="4ukuV2mOCUf4VI23v7qQOUoVJ51tHBMia"
X-Provags-ID: V03:K0:fY0mAKjI836f6INRedqjGx1SCNH12+ZLbsLPU5e/8+3I7ZF8EBL GN100J9iNrYXULJGrJf4eHgAP0p6OJmPXafFJg0L5Eht+VzSysxq0lyJ/4sBbZjz3X7QHP4 3lgo/IjEMPh/cAzZFBRE6WqlrgjpDMtl6CP8nd2ulj1zbdfuqx/SAPmSP47IDmTc7UGd7ZU Zo0Zm3YClh/ijggSMF0/A==
X-UI-Out-Filterresults: notjunk:1;V01:K0:ZNiZWlCOy9g=:0DMOM3ulyDQnjbtS/vrIv7 MbzkAhPZoAI0uiOF5UWP2WfJEgUqD9qQkD4Q89XAzW9at4vQkkKkFxIeYnh6yrOWKBscBPkXF Nytx2543jPyq+HBHPU5QPZsZdHYF5bYSdV5rHLLhQNhWgh9D8JLI7l9nt/fjsSPAqsuCMtSjH Jp/TtJGiZTT6Rg4EMmvaTYT0Wl27vr/6pf8YXI9nxYhAjjN97j1jkQRonvBGcfdjivGZ06pEo nYsYWpv9DnEDY6iXbFbhHeeUPQGCfxmXeQVqfzOpDGVw/R8lPuBYdK0N785lSuFhEYvcEnKgM C5L94J0hHBZoifguM0/yw+lQwscAqzJv6Ki8ZiUh980f0XrGyy4vDi1oNBTGFbEpd1T8ST+0M hYX6CArb4/ok3pibKcMD1Mjuu2BoFdThmrUgLvPgwSExfheImkfCtqK2Re1jMXZiDQK/1+nLy 5p5zAZgJRDhs0pNiahbT3F42n++2d//RFSarvxd5dviK4ZBW6wlxnsZeNdhpT+SxsVx8YDQdh Clg6nE0kWFtRXDswJ8a1KphpX/3lLFkKnTXQsuefiBrT73AOaXgzZ/8qQpR8cnk1GFopJGLT6 hCFgvFvopiTwmEQJyyWhJe/cnsGRCaWg3a+K3sKCU4iRokZuSLAt8Z0dkHC9o1dvcmkqF8P7A xe9WmVgWwUfAIJPvyVrjcXHQtziHOBKb/Eh3SMWsHzVltYDHQ06yIa6Mz8dtauN3GhrLm2Osj roN1sX6wk8skGOCYb1dTi9Z/W6o5Np3+w+WFMAMtzafrQX7d1QBklDxvFXk=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Wx1AxyMBb_yWAMkwFaDS3-fsCjw>
Subject: [OAUTH-WG] OAuth Security -- Next Steps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 25 Jul 2016 10:59:28 -0000

Hi all,

We had two working group sessions at the Berlin IETF meeting and I am
happy about the progress on many of the subjects. We managed to progress
token exchange, native apps, AMR, and authorization server meta-data. We
also identified new use cases to explore with the device flow document.

We also did a call for adoption of the OAuth token binding
functionality, which still needs to be confirmed on the mailing list.
(Further emails will follow.)

There are, however, aspects I am not happy with. I was hoping to make
some progress on the mix-up mitigation and on the wider range of
security documents.

Here is how I see the story after talking to some meeting participants.

1) It seems that the solution approach to deal with the mix-up attack
(only mix-up) described in draft-ietf-oauth-mix-up-mitigation-01 needs
to be modified to reflect the preference of the working group. My
impression (from speaking with participants at the meeting last week
privately) is that there is interest in a solution that does not require
protocol changes but rather relies on configuration. This may include a
combination of exact redirect_URI matching + per-AS redirect_URI +
session state checking. There are also other attacks
described in draft-ietf-oauth-mix-up-mitigation-01, which need to be
moved elsewhere to avoid confusion.

2) We need a new document, ideally a BCP, that serves as a
high-level write-up describing various security issues with OAuth that
points to the mostly existing documents for those who want to read the
background information. Torsten has posted a mail to the list providing
one possible outline of such a document.

How does this sound?

Ciao
Hannes