Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution

Benjamin Kaduk <kaduk@mit.edu> Sun, 28 April 2019 03:57 UTC

Return-Path: <kaduk@mit.edu>
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 43D991200E6 for <oauth@ietfa.amsl.com>; Sat, 27 Apr 2019 20:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7xrEVuTyW5aA for <oauth@ietfa.amsl.com>; Sat, 27 Apr 2019 20:57:38 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0385A120048 for <oauth@ietf.org>; Sat, 27 Apr 2019 20:57:37 -0700 (PDT)
Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3S3vWCA024923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Apr 2019 23:57:34 -0400
Date: Sat, 27 Apr 2019 22:57:32 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Luca Arnaboldi <Luca.Arnaboldi@arm.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <20190428035731.GE60332@kduck.mit.edu>
References: <DB8PR08MB39801EF8D75849CE0BC571678E3E0@DB8PR08MB3980.eurprd08.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <DB8PR08MB39801EF8D75849CE0BC571678E3E0@DB8PR08MB3980.eurprd08.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/XEa0qWBf4XwGWmx9GF4Gux1dlM8>
Subject: Re: [OAUTH-WG] Formal analysis of draft-ietf-oauth-pop-key-distribution
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: Sun, 28 Apr 2019 03:57:39 -0000

On Fri, Apr 26, 2019 at 10:51:53AM +0000, Luca Arnaboldi wrote:
> * I spoke with Hannes after the IETF meeting in Prague and he expressed the need to enhance our formal analysis (as presented at the OAuth Security Workshop) to verify whether it is necessary to demonstrate possession of the private key by the client to the authorization server.
> 
> 
> * The analysis checked whether it was necessary for a proof of possession to be performed between the client and AS to ensure security. The result was that even without verification by the AS the client would not be able to access the resource from the RS without possessing the secret key associated to the token (assuming the check is done correctly by the RS).

My apologies for not checking the model directly (I'm on a plane), but I'll
note that we have seen similar PoP scenarios in other protocols where a
misbehaving client will deliberately try to bind the (valid) key from
another party to a token it authorizes, which can sometimes result in the
other party taking actions different from the ones they intended.  So I'd
suggest being careful about what scope of attacks are considered.

Thanks,

Ben