Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98

Benjamin Kaduk <kaduk@mit.edu> Mon, 27 March 2017 21:52 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 0C04F127A91 for <oauth@ietfa.amsl.com>; Mon, 27 Mar 2017 14:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 tpvcccEaqq3a for <oauth@ietfa.amsl.com>; Mon, 27 Mar 2017 14:52:48 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 6BF19126D05 for <oauth@ietf.org>; Mon, 27 Mar 2017 14:52:48 -0700 (PDT)
X-AuditID: 1209190e-8f3ff7000000626d-e0-58d989aef564
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D7.58.25197.EA989D85; Mon, 27 Mar 2017 17:52:47 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v2RLqjW8024742; Mon, 27 Mar 2017 17:52:45 -0400
Received: from kduck.kaduk.org (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.13.8/8.12.4) with ESMTP id v2RLqfK0004558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Mar 2017 17:52:44 -0400
Date: Mon, 27 Mar 2017 16:52:41 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: Nat Sakimura <sakimura@gmail.com>, oauth@ietf.org
Message-ID: <20170327215240.GI30306@kduck.kaduk.org>
References: <148858532832.15846.17124635719619343122.idtracker@ietfa.amsl.com> <CY4PR21MB0504F842748771485358717AF5380@CY4PR21MB0504.namprd21.prod.outlook.com> <9905FF1B-0E4A-459B-8322-6AC143092D42@lodderstedt.net> <2452F93F-BC4D-4F42-AD4C-85A0672BFBE8@adobe.com> <CABzCy2D=0kTCOgV2VAmR+BLUzsp0x58yq8S8+mykRoqC2mtuQw@mail.gmail.com> <9c814ef0-4df3-35ed-5453-dd8cad91b910@free.fr> <CABzCy2AqK0rCRRZ1w_KXiKNbzjqwSx+OMS2nSXnfjLsuE-cgvg@mail.gmail.com> <45feb0e5-d1e3-ca5a-e8c1-f9b44768d09b@free.fr> <CABzCy2BFC5KaFpoEfDfMaU2cr6CJT+53Gkghmzjk75qzW+KKyA@mail.gmail.com> <4339d9a5-f886-bd75-7b2a-c714b0c9321f@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4339d9a5-f886-bd75-7b2a-c714b0c9321f@free.fr>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixG6noru+82aEwZXfUhbru+wsTr59xWZx 5tYKRgdmj/51n1k9ds66y+6xZMlPpgDmKC6blNSczLLUIn27BK6MudsnMRf84K04NnMFSwNj I3cXIyeHhICJROv+2SwgtpBAG5PEwmN1XYxcQPZGRokD7w+yQzhXmST2L7rJ2MXIwcEioCrR 9F8LpIFNQEWiofsyM4gtIiAnsereNTCbWcBUYsaan8wg5cICIRJt07xAwrxAu9btmsUEMfIr i8SnmUtYIRKCEidnPmGB6NWSuPHvJRNIL7OAtMTyfxwgYU4Ba4l9P/8xgtiiAsoSDTMeME9g FJiFpHsWku5ZCN0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrr5WaW6KWmlG5iBAUtpyTf DsZJDd6HGAU4GJV4eDX4b0YIsSaWFVfmHmKU5GBSEuWVswYK8SXlp1RmJBZnxBeV5qQWH2KU 4GBWEuF90gqU401JrKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeLU7gBoF i1LTUyvSMnNKENJMHJwgw3mAhueA1PAWFyTmFmemQ+RPMSpKifPKgiQEQBIZpXlwvaCkIpG9 v+YVozjQK8K8V0CqeIAJCa77FdBgJqDBh+ffABlckoiQkmpgXBP2NsbP5PfLpvUGx47qcFee Spgwy+/ffotZ96Ri2Lr8Lmk6/os5KPH3w/H191WYuvQvX2q3kwz/e0nLiq1WdedS3ZPXVQri g/YZ5RYKKu/edkFVTe9jzE4Oc+OAxTkyf6f2JP+bbvdba27e9Ihsz/ecjRMLfmSwBZoLKzZO 8Sjb+cD1zmZxJZbijERDLeai4kQAvZnZxgUDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/dSC2RoTxfbVBlneb3J8M3EEEXRo>
Subject: Re: [OAUTH-WG] oauth - Requested sessions have been scheduled for IETF 98
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 27 Mar 2017 21:52:50 -0000

On Mon, Mar 27, 2017 at 03:08:39PM +0200, Denis wrote:
> Hi Nat,
> > HI.
> >
> > As pointed out in saag, the OAuth WG is not dealing with ABC attack. 
> > It is out of scope for now at least.
> 
> A threat along the ABC attack is not mentioned in RFC 6819 : OAuth 2.0 
> Threat Model and Security Considerations (2013).
> Hence, nobody attempted to find a solution ... for a threat that had not 
> been identified.
> 
> draft-ietf-oauth-token-binding-02 is a document form the OAuth WG. Since 
> this threat has not been identified in RFC 6813,
> it does not contain any proposal to counter that threat. However, this 
> threat is now identified. Should this threat be addressed
> by sticking our heads in the sand ?

I am not sure that everyone in this conversation agrees on the same
definition of "threat model" that is in use.  The definition that I
am using involves choosing a specific set of attacker capabilities
to attempt to counter, and explictly does not include considering
an all-powerful attacker or considering all conceivable potential
"threats".  That is to say, the discovery of a new potential threat
need not necessate a modification to the threat model, as the new
threat  may require an attacker capability against which we are not
trying to defend.

-Ben

> A basic property of the current Token Binding mechanisms being developed 
> both by the OAuth WG and the Token Binding WG
> is that a specific piece of software voluntarily installed by a client 
> can export any token and perform all the needed computations
> so that any token can successfully be usedby another client. It is NOT 
> the replay of a token, since the token is not used at any
> time by the legitimate owner, but is used by an illegitimateuser.
>