Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt

Neil Madden <neil.madden@forgerock.com> Sat, 07 November 2020 15:30 UTC

Return-Path: <neil.madden@forgerock.com>
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 742CB3A07D7 for <oauth@ietfa.amsl.com>; Sat, 7 Nov 2020 07:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=forgerock.com
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 zeiYMheGkuIk for <oauth@ietfa.amsl.com>; Sat, 7 Nov 2020 07:30:19 -0800 (PST)
Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F04A3A00C4 for <oauth@ietf.org>; Sat, 7 Nov 2020 07:30:19 -0800 (PST)
Received: by mail-wm1-x330.google.com with SMTP id h2so4212612wmm.0 for <oauth@ietf.org>; Sat, 07 Nov 2020 07:30:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:message-id:references:cc:in-reply-to :to:content-transfer-encoding; bh=WBM6sBWiXYjB9di9+7QBZLyTEpMF4tfTa62YauiWP0c=; b=dRnY7mUupptk4UuhWZyxKBDavqjsGtj7AndlVQK0ikUBG5y2xTGYgBoT9gSZbTju8k Rx9/IgOg80WJmCAdlVgkunn9cfkJGuXIKE9OsPG7RKYQO5LNITmEXiGxS4qy7JN554hu 9JPYuK1EVhvaAD2KQOJx+0IlsyeVFLk/x/LZg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to:content-transfer-encoding; bh=WBM6sBWiXYjB9di9+7QBZLyTEpMF4tfTa62YauiWP0c=; b=pzFoOejD/VcuxrgOTT1GjD2vkhMuN3ftU527XgDdgj6d4kuAURnq0sIpLmjRpD75Dj 09Boad5e/nEUNkc84DAMdYk9PvL+nsV3RoF6DDg8A6r90FID9XS6itQivWgTv4umtzcs Z5HaGgW7qWZVKsAAJ70liGaM57gZ10tysdOO0vlMaJ1nrS1pHiE7pNfRUlpV+aR65tKI gPfEJL4AXnjDkmGXze+fbgtt2pJZitsDD6ZpEpi84/Yogvo9gHFEWCkg74U7TI/OhJ7g JPwyosqleIFB6UZhv7zJBNOTcbU8BHdFgHmKIAIK78S8NSUxm3kXksZLcYONXAgO1EUg 1Jzw==
X-Gm-Message-State: AOAM532BU9iF2Y7M2V+IOIOlILmTEGziynYh6Ry2EuiAHB2X0ZCEFOC/ E/HeVv6xEd/imP12PZ5nVOB9Hiid05yYIa0Z4gHUeqF3wGpd6cCr03AeXZ028sDA9CBmKFzbiQ= =
X-Google-Smtp-Source: ABdhPJxPPRvb26ab9O35zZv/Jvv45tmMtQN41o9PtkSBhEI5viDXi6BqXZgVvU13rOVBpt4s/Vge6g==
X-Received: by 2002:a05:600c:21d5:: with SMTP id x21mr5538817wmj.133.1604763017463; Sat, 07 Nov 2020 07:30:17 -0800 (PST)
Received: from [10.0.0.5] ([213.31.218.193]) by smtp.gmail.com with ESMTPSA id b17sm6881860wru.12.2020.11.07.07.30.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 07 Nov 2020 07:30:15 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (1.0)
Date: Sat, 7 Nov 2020 15:30:14 +0000
Message-Id: <E693C788-ED95-42FF-8074-561A372EDF91@forgerock.com>
References: <CA+k3eCQZsWCbR_eqv2umTDDbWiHp5siu4NFnoONz8Y8sMiSnrg@mail.gmail.com>
Cc: oauth <oauth@ietf.org>
In-Reply-To: <CA+k3eCQZsWCbR_eqv2umTDDbWiHp5siu4NFnoONz8Y8sMiSnrg@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: iPhone Mail (17H35)
Content-Type: multipart/alternative; boundary=Apple-Mail-574B9628-E63C-4315-9F83-DA702C673342
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Fxr97Th_MlEzVp7lat7MLfQAC5M>
Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-dpop-01.txt
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: Sat, 07 Nov 2020 15:30:22 -0000


> On 6 Nov 2020, at 22:02, Brian Campbell <bcampbell@pingidentity.com> wrote:
> 
> 
> 
> 
>> On Tue, May 5, 2020 at 2:52 PM Brian Campbell <bcampbell@pingidentity.com> wrote:
>> 
>>> 
>>> 9.1:
>>> This would be a good place to mention BREACH as an example of how a DPoP proof (and AT) might leak, despite only being sent over a direct HTTPS channel. Note though that adding a random jti is an effective defence against this even if the server doesn’t check it.
>> 
>> Thanks for that note as a good reason to keep jti even if the requirements on checking it are relaxed. 
> 
> In trying to add some text that makes such mention I realized (again) that I don't have a very good understanding of BREACH. With a bit of reading of the overview and paper at http://breachattack.com/ it seems that BREACH is applicable to attacking compression for leaking sensitive information in HTTP responses. Whereas a DPoP proof is only defined to be sent in an HTTP request. And ATs are only in a response once and then used in requests. Perhaps it's a limitation of my own imagination or intellect but I don't see how BREACH is relevant here. If you can explain it to me "for dummies" style or better yet propose some text, we can certainly look at adding it. Short of that though, I'm not equipped to write anything legitimate about it and will just omit any such mention.  
>  

BREACH was primarily attacking web browser clients, which do indeed usually only allow compression in responses. But OAuth is used for other API clients and compression of requests, although by no means widespread, is sometimes used. For example [1] where it’s recommended that clients use compression for both requests and responses, and a Google search shows various other cases. 

So in these cases a BREACH-like attack could be used to recover a bearer token in those requests. However, on reflection it’s not a hugely likely attack vector for a number of reasons:

1. HTTP compression only compresses the request entity, not the headers or request URI. So this would only be a risk when sending the access token in the body as in [2]. And it’s not a risk for a DPoP proof as that’s always in a header. 

2. In order for the attack to work the attacker needs to be able to influence some part of the requests, which is generally a bit harder than influencing responses from a server. The most likely vector IMO would be XSS, in which case there are likely to be more direct ways to steal the token. 

I wouldn’t want to say that this is never a risk, but it perhaps doesn’t rise to the level that it’s worth spelling out. 

[1]: https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/intro_rest_compression.htm

[2]: https://tools.ietf.org/html/rfc6750#section-2.2

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>