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

Neil Madden <neil.madden@forgerock.com> Fri, 22 November 2019 10:23 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 CE93A120822 for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 02:23:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 oA0gOFRF7L6l for <oauth@ietfa.amsl.com>; Fri, 22 Nov 2019 02:23:31 -0800 (PST)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 0E7D61207FD for <oauth@ietf.org>; Fri, 22 Nov 2019 02:23:30 -0800 (PST)
Received: by mail-wm1-x335.google.com with SMTP id 8so6985095wmo.0 for <oauth@ietf.org>; Fri, 22 Nov 2019 02:23:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MD4YNH3bske2KLjGsswKrFeJikR4PNVBGCD19qVxXPA=; b=OxMVPIPMKLk2uzajDsKveAtCs9bTGAgR0UFbJLa9aimNUkxK2qGgFIEzgwjxay7Udc 3lsMNTciN0zX2GUv22J6FlaBnD1g8/BmeTGrrESB0ep+bQWHzrQx0p9OLWZrAuGqBVlz jp4wffi24RykTYHG0UEeAUT8vQrjUfauZADWI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MD4YNH3bske2KLjGsswKrFeJikR4PNVBGCD19qVxXPA=; b=mYUJXBCQBXbeKElDlU8ufzYY2nNGcMKg630Jb7tO8qgwY+wCV7Fot1iDARuo9ZvKZ9 aaUBDTgbucBdn6nj5IbrDfWXrp77GcvcLrUQTqXPgWJcZ6fhYc46GILJumRpSHIINpaj AjuzwhQOoVYUULOORExhMK6coq9NoXqCun1Xpb2tOdaTdi8qpZnTy6/ClePRkC5oO6EO q9xIa98cctbKfKxj9iypY16MxKosvwumgj3/i9KrOwoGlFnEK6a3gkSWaMsA3Ete4QMX uFhL0VjtircuuqqHvdcDprdWGquz4FdKzEHgonjTyF3hxyQXuaQ/eFNgz1uDUN6kOgfl qk/w==
X-Gm-Message-State: APjAAAVvSuDnZhvoalBU5Qt5ZLBIx7c0wRIjWAB+sPDvD0UAiIvvkzp7 QzX6pwNp9/fKFNIC9DQNW1PGrA==
X-Google-Smtp-Source: APXvYqybNzNZzyHVBYijcCAI2lzX+Tk/+PnhrNQnH6K716RC+RNFNx7jAVGFU2gFbSdUM69WC+Bb4A==
X-Received: by 2002:a1c:23c1:: with SMTP id j184mr15134810wmj.83.1574418209398; Fri, 22 Nov 2019 02:23:29 -0800 (PST)
Received: from [192.168.1.64] (72.248.90.146.dyn.plus.net. [146.90.248.72]) by smtp.gmail.com with ESMTPSA id x7sm7071616wrq.41.2019.11.22.02.23.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Nov 2019 02:23:28 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Message-Id: <B15ABCF0-B931-4AEE-9109-A626278CD88C@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3F0BA50E-DD75-48F4-ADF3-40244582E78F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Fri, 22 Nov 2019 10:23:26 +0000
In-Reply-To: <CAGBSGjoSkwOJ2ajG=AeC-Z7H6noCMekRpi8jDJXd8uk2tOp=Ow@mail.gmail.com>
Cc: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>, oauth <oauth@ietf.org>
To: Aaron Parecki <aaron@parecki.com>
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com> <6DECA422-AACC-4DAA-8CD2-FF57CE02DE3E@mit.edu> <0235F8A2-83C4-4804-8805-F50305E263BB@lodderstedt.net> <D43D3929-F1B7-4A2C-ABEC-1326F3F0926C@forgerock.com> <CAGBSGjoSkwOJ2ajG=AeC-Z7H6noCMekRpi8jDJXd8uk2tOp=Ow@mail.gmail.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ZXhMv8VDVzfU9SpP71wtsX9pAyw>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.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: Fri, 22 Nov 2019 10:23:34 -0000

It's not a different threat profile. This is the same assumption people made when introducing HttpOnly cookies, which just led to attackers switching to proxy everything through the browser as per things like https://beefproject.com <https://beefproject.com/> . (This is actually nicer for the attacker as their requests then appear to come from the legitimate user, masking their true origin and allowing them to carry out attacks bypassing the corporate firewall). DPoP is not a protection against XSS and shouldn't be sold as such.

-- Neil

> On 22 Nov 2019, at 10:19, Aaron Parecki <aaron@parecki.com> wrote:
> 
> The main concern about token replay in a SPA is that the access token may be extracted from the app, such as via XSS. Using the Web Crypto API has the advantage of being able to generate a public private key pair where the JS code can't access the private key at all, it can only be used to sign things, making it impossible for an attacker to extract an access token and use it for anything. You might then say that if a JS app is vulnerable to XSS then the attacker could just call the signing API anyway, which is a concern, but that's a different threat profile. 
> 
> Aaron
> 
> 
> 
> 
> On Fri, Nov 22, 2019 at 6:08 PM Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> On 22 Nov 2019, at 07:53, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org <mailto:40lodderstedt.net@dmarc.ietf.org>> wrote:
> > 
> > 
> > 
> >> On 22. Nov 2019, at 15:24, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> >> 
> >> I’m going to +1 Dick and Annabelle’s question about the scope here. That was the one major thing that struck me during the DPoP discussions in Singapore yesterday: we don’t seem to agree on what DPoP is for. Some (including the authors, it seems) see it as a quick point-solution to a specific use case. Others see it as a general PoP mechanism. 
> >> 
> >> If it’s the former, then it should be explicitly tied to one specific set of things. If it’s the latter, then it needs to be expanded. 
> > 
> > as a co-author of the DPoP draft I state again what I said yesterday: DPoP is a mechanism for sender-constraining access tokens sent from SPAs only. The threat to be prevented is token replay.
> 
> I think the phrase "token replay" is ambiguous. Traditionally it refers to an attacker being able to capture a token (or whole requests) in use and then replay it against the same RS. This is already protected against by the use of normal TLS on the connection between the client and the RS. I think instead you are referring to a malicious/compromised RS replaying the token to a different RS - which has more of the flavour of a man in the middle attack (of the phishing kind).
> 
> But if that's the case then there are much simpler defences than those proposed in the current draft:
> 
> 1. Get separate access tokens for each RS with correct audience and scopes. The consensus appears to be that this is hard to do in some cases, hence the draft.
> 2. Make the DPoP token be a simple JWT with an "iat" and the origin of the RS. This stops the token being reused elsewhere but the client can reuse it (replay it) for many requests.
> 3. Issue a macaroon-based access token and the client can add a correct audience and scope restrictions at the point of use.
> 
> Protecting against the first kind of replay attacks only becomes an issue if we assume the protections in TLS have failed. But if DPoP is only intended for cases where mTLS can't be used, it shouldn't have to protect against a stronger threat model in which we assume that TLS security has been lost.
> 
> -- Neil
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> -- 
> ----
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com/>
> @aaronpk <http://twitter.com/aaronpk>
>