Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode

Daniel Fett <fett@danielfett.de> Mon, 06 January 2020 14:35 UTC

Return-Path: <fett@danielfett.de>
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 DC332120840 for <oauth@ietfa.amsl.com>; Mon, 6 Jan 2020 06:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=danielfett.de
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 KuGXz_Gwy1Gr for <oauth@ietfa.amsl.com>; Mon, 6 Jan 2020 06:35:57 -0800 (PST)
Received: from d3f.me (redstone.d3f.me [5.9.29.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA2F12082A for <oauth@ietf.org>; Mon, 6 Jan 2020 06:35:57 -0800 (PST)
Received: from authenticated-user (PRIMARY_HOSTNAME [PUBLIC_IP]) by d3f.me (Postfix) with ESMTPA id ABEEF12F1D for <oauth@ietf.org>; Mon, 6 Jan 2020 14:35:54 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578321354; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wGxY9NEZLUJszOBGeIJN35Qi0f/uCcNL3ifKr1cNIjk=; b=cIGXBoR1TuE+tK5HrHRC/Y0109nx/fSbbo/ONQz/B2Uw8kO9nOqo5R5L0HdrxmPVk5yKaE 6Om9tzbtlRlD46Sy8qcXPZbNRA6OfRXme5CiTSVoHD4QhbeRYhxrvAT8YoLmZq/TfaPZv+ btEN8Ug7U7d2Z43ICyKvoQyjRoqkRlM=
To: oauth@ietf.org
References: <0D6C9677-D8B5-4005-95FE-4F783EB28961@lodderstedt.net> <CFA2CC6C-4A09-4A7E-8D89-95F6F49DE267@gmail.com>
From: Daniel Fett <fett@danielfett.de>
Message-ID: <f6917f0b-6889-a471-e8dc-6a9e8a271243@danielfett.de>
Date: Mon, 06 Jan 2020 15:35:53 +0100
MIME-Version: 1.0
In-Reply-To: <CFA2CC6C-4A09-4A7E-8D89-95F6F49DE267@gmail.com>
Content-Type: multipart/alternative; boundary="------------7B1326A93687C9BCD66F2253"
Content-Language: de-DE
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=dkim; t=1578321355; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=wGxY9NEZLUJszOBGeIJN35Qi0f/uCcNL3ifKr1cNIjk=; b=MFcFqCetShBQ7jiqGNqyNWnmnE+8VOK57Jns+yWOU0CQ5zvatxjx/QfAU0G9vj5m0PkCvm SDG1iyfo9UwYOu7XEgjLyo6Sd1BgScq7bgx0nSdKsh+wDp5EEruePKgTbAqJcw9Av8hpWv ttWAGmxhFjrXBxxOEQA8YN/AX7VgXys=
ARC-Seal: i=1; s=dkim; d=danielfett.de; t=1578321355; a=rsa-sha256; cv=none; b=Ta0rbytCiOOmP9g3HY1UJ4Iio1IqZx7Z/C/WEt8LRAHCAsw9YgVQ/BbyMdxzEyKSxUNJoS1NKczjfu1AqfJSvNuhDPwZJXwKfg2gIF3eTnJ4SbHeiWWAmEDlyP90NaidEB+ptoFYdebXemUq1exfid/UDbZhJulHNZWyEtcknsU=
ARC-Authentication-Results: i=1; d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
Authentication-Results: d3f.me; auth=pass smtp.auth=fett@danielfett.de smtp.mailfrom=fett@danielfett.de
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xp-ZFr43xEnP_IzZmpwYymZwi0w>
Subject: Re: [OAUTH-WG] [EXTERNAL] -security-topics-13 and OIDC response types + form_post response mode
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: Mon, 06 Jan 2020 14:36:00 -0000

Am 27.12.19 um 23:27 schrieb Filip Skokan:
> Encrypted JARM responses are in a very similar position. Access Token
> value is not part of the URL and the response itself is protected.
> Such response is usually only consumed by a server side application.
> Same as any form_post response.

The encryption of JARM does not add much if the token leaks: An attacker
could just inject it into a flow on his device.

This is also why sender-constraining, even if it would be possible in
the "token id_token" scenario, would not help at all.

>
> We could go into further clarifying the client application topology to
> enable these uses but i don’t think it’s worth it. Why make excuses to
> keep implicit issued access tokens around in when code flow is the way
> the WG has decided to go. (Here we go again...)

+1

-Daniel

>
> Best,
> Filip
>
>> 27. 12. 2019 v 21:41, Torsten Lodderstedt
>> <torsten=40lodderstedt.net@dmarc.ietf.org>:
>>
>> 
>> As Brian said, we have discussed this several times and this text
>> found consensus.
>>
>> Using post reduces the attack surface but does not allow to bind the
>> access token to the legitimate client. We are recommending sender
>> constrained access tokens in the BCP. So recommending a flow that
>> does not support sender constrained access tokens is a contradiction.
>>
>> What do other WG members think?
>>
>>> Am 27.12.2019 um 21:28 schrieb Mike Jones
>>> <Michael.Jones=40microsoft.com@dmarc.ietf.org>:
>>>
>>> 
>>> I agree with Brian. Please update the text to describe this already
>>> safe usage.
>>>
>>> -- Mike
>>>
>>> ------------------------------------------------------------------------
>>> *From:* OAuth <oauth-bounces@ietf.org> on behalf of Brian Campbell
>>> <bcampbell=40pingidentity.com@dmarc.ietf.org>
>>> *Sent:* Friday, December 27, 2019 11:03:30 AM
>>> *To:* oauth <oauth@ietf.org>
>>> *Subject:* [EXTERNAL] [OAUTH-WG] -security-topics-13 and OIDC
>>> response types + form_post response mode
>>>  
>>> We have a-sometimes used scenario where a client makes an
>>> authorization/authentication request with a "token id_token"
>>> response type and "form_post" response mode (nonce is also sent and
>>> exact redirect URI matching is done at the AS). The access token is
>>> never exposed in any URLs and access token injection is prevented by
>>> the at_hash claim in the id token.
>>>
>>> That seems to me like a legitimate and reasonable usage scenario.
>>> However, it would fall on the wrong side of the SHOULD NOT in
>>> Section 3.1.2 of the Security BCP-to-be
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-13%23section-3..1...2&data=02%7C01%7CMichael.Jones%40microsoft.com%7Cee48992fa75642e2cbf908d78aff8d77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637130702523877347&sdata=LJfYSigLXqZjLNl%2Bx1ycBSHJn6UKJFXhr5As1zb1g98%3D&reserved=0>,
>>> which has:
>>>
>>>    In order to avoid these issues, clients SHOULD NOT use the implicit
>>>    grant (response type "token") or any other response type issuing
>>>    access tokens in the authorization response, such as "token id_token"
>>>    and "code token id_token", unless the issued access tokens are
>>>    sender-constrained and access token injection in the authorization
>>>    response is prevented.
>>>
>>> I know this particular text has been discussed over and over again
>>> so I hate to revisit it. But based on the aforementioned scenario I
>>> think maybe it still doesn't quite hit the mark. Access token
>>> injection is prevented. The token leakage scenarios mentioned in
>>> that section are all avoided. And while I know sender-constrained is
>>> recommended elsewhere in the draft, it's not really a realistic
>>> option for the majority of deployments.
>>>
>>> /CONFIDENTIALITY NOTICE: This email may contain confidential and
>>> privileged material for the sole use of the intended recipient(s).
>>> Any review, use, distribution or disclosure by others is strictly
>>> prohibited..  If you have received this communication in error,
>>> please notify the sender immediately by e-mail and delete the
>>> message and any file attachments from your computer. 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