[OAUTH-WG] RFC7009: what to return when revoking a token which is not the client's?

Танги Ле Пенс <tangui.lepense@mail.ru> Thu, 25 July 2019 18:55 UTC

Return-Path: <tangui.lepense@mail.ru>
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 A10F212021F for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 11:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.ru
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 Fj1H7tyW7PJU for <oauth@ietfa.amsl.com>; Thu, 25 Jul 2019 11:55:23 -0700 (PDT)
Received: from smtp40.i.mail.ru (smtp40.i.mail.ru [94.100.177.100]) (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 253FA1201F8 for <OAuth@ietf.org>; Thu, 25 Jul 2019 11:55:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.ru; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=MX5zuQ8zeMmxW+UUelv0qDUsRY9WjmqmOUG6bsazjnc=; b=lP/jeJuedh1J8BRtmCZdsoketIpxRqmJedeqqSTbroippdReIb1vdMe/4zXITtX2wVvmGtPL/kxIvp8pTG3y6JNAjSNaJcP7zlCJDP9xLZmCDscJCpTDj4bZRqvyOq0oeZJbiP68CRm94shB1PB/7NzBNmiWuPdKywEnRoxN/jA=;
Received: by smtp40.i.mail.ru with esmtpa (envelope-from <tangui.lepense@mail.ru>) id 1hqitc-0001gq-P8 for OAuth@ietf.org; Thu, 25 Jul 2019 21:55:21 +0300
To: oauth <OAuth@ietf.org>
From: Танги Ле Пенс <tangui.lepense@mail.ru>
Message-ID: <c29dd5c2-1c80-dd90-48df-27354a0f5441@mail.ru>
Date: Thu, 25 Jul 2019 21:55:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Authentication-Results: smtp40.i.mail.ru; auth=pass smtp.auth=tangui.lepense@mail.ru smtp.mailfrom=tangui.lepense@mail.ru
X-77F55803: 260C666A7D66B36A5A78504BD2AC294173B0C787F0EA2BA198E7F487E88572BC68334DD289734B6F9380524CF741C8BF
X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE723C544A82E63DB9DEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637A61F0BAD8BCAD5198638F802B75D45FF5571747095F342E8C7A0BC55FA0FE5FC5B52A0C24483FED46AB2967D62766D7C848F3F70FB5908FF389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0E45F71884F0C27A38941B15DA834481FCF19DD082D7633A0E7DDDDC251EA7DABA471835C12D1D977725E5C173C3A84C33CCD70CEBBF18A22117882F4460429728AD0CFFFB425014E40A5AABA2AD371193AA81AA40904B5D9A18204E546F3947C91B80A194963C606AD7EC71F1DB884274AD6D5ED66289B52BA9C0B312567BB2376E601842F6C81A127C277FBC8AE2E8B8F84DE33370BFF23EC76A7562686271EBE1D6DAAD8F14AE1089D37D7C0E48F6C8AA50765F790063702CA68E78BD0E2C3C53DF2FDDED51211089D37D7C0E48F6C5571747095F342E857739F23D657EF2B6825BDBE14D8E7028C9DFF55498CEFB0BD9CCCA9EDD067B1EDA766A37F9254B7
X-Mailru-Sender: 14EA92FCC1671FFE4D769571F75AF8D4380E2C25BCA234BFD59E7652DC012465A626B283B0EE9978CA32051E784B72BD82C5FF2F5C0BFE3369E1CDCD713A0E3782281E5CC26A8A21A535606A78F2CC074D6D94805F93B69605CEE88C4A91FC465FEEDEB644C299C0ED14614B50AE0675
X-Mras: OK
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1Nqhz_GqIWLhcB5fQFdWzKsvANs>
Subject: [OAUTH-WG] RFC7009: what to return when revoking a token which is not the client's?
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: Thu, 25 Jul 2019 18:55:32 -0000

Hi,

In RFC7009 - section 2.1 
(https://tools.ietf.org/html/rfc7009#section-2.1), it is stated that:

    The authorization server first validates the client credentials (in
    case of a confidential client) and then verifies whether the token
    was issued to the client making the revocation request.  If this
    validation fails, the request is refused and the client is informed
    of the error by the authorization server as described below.

And then in section 2.2 (https://tools.ietf.org/html/rfc7009#section-2.2):

    The authorization server responds with HTTP status code 200 if the
    token has been revoked successfully or if the client submitted an
    invalid token.

Returning an error in the first case (and not the standard 200 HTTP 
status) would leak to another client that the token exists and is 
actually valid. Even though scanning tokens is hard if implemented with 
a sufficient entropy (timing attacks could probably help here), 
shouldn't it be preferable on a security perspective to return an HTTP 
200 code instead of an error?

Is there some historical discussion that I may have missed?

Regards,

-- 

Tangui