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

Brian Campbell <bcampbell@pingidentity.com> Tue, 19 November 2019 07:44 UTC

Return-Path: <bcampbell@pingidentity.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 0B58512087C for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 23:44:02 -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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pingidentity.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 EyAroDtY_f-Q for <oauth@ietfa.amsl.com>; Mon, 18 Nov 2019 23:43:56 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 39B9E12084A for <oauth@ietf.org>; Mon, 18 Nov 2019 23:43:55 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id d5so22136750ljl.4 for <oauth@ietf.org>; Mon, 18 Nov 2019 23:43:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LrDzvtjJWn1hPszrBd4DkKaXGpoe5bym/OxRCY70/tk=; b=LLJMwe3/vgm9YHwktDY2CarFsDc+y0Y1OOi66asxhDqqjqrPsASDMLCd+h+ss8XbJF R5PhvvAN3LNAL5hCiXaBolpo9CTngGh2BvpNfQiK5BaXcSlqcY8TVwxWcyfeFOWen4wP YPKwiMCGev+3JFJCCBhjQEo/fzGrzzY+0/42IccoLmS5EBv5qLVlwTSyRUxQZYsKWsed E/vBVO7hyZg9WZuEU9mkw80wwJ6SXbyH7mMZive+roO+0N8qXEJnxAnInWpiVMKgSgn3 leRsStdmDYboDGIgdzD14OYFbF4U9+78XUAZJqg/SxXXhoSAGX5+lzyRvESd5ybIxR1+ bi7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LrDzvtjJWn1hPszrBd4DkKaXGpoe5bym/OxRCY70/tk=; b=U6OQBMcehxhpMPiElVT3s6tBpfPNCsw5myCLL6KBPUOoOk5iQbxLNMzEuVaNg6UVd3 FUNMNJNdBR+S1L489rqn8BQa6fXbCspep/8/ekKQtG/nuLpLxHSTpp0hDsBJQUzCKhEl KN84bbFLZZnNs/Zhvyfs0jkVnLdRQfP6co9WnuAJmxPd6FgCxJcb40U/1B87r0PrNY86 re4p38HPWsx02BgyV3BYgjJnaDIEEXTx6+xZB6WCPhf0Y0QmTAwxeTwf+yPt0Gm1cKIr pW2hEGaTu5ryO4412gXvv6naFaC16G+tSlBbDiJOTDcgFLOgiiQUrym1mNfYGxZV4if4 zJSQ==
X-Gm-Message-State: APjAAAXaGGqlvgaKYmg/eqEXxkLZD0U5EgJ0GQ6KaI3ne4HpLQ/ncyT4 VW+VJD7aTbJVTuWar8eCFycQPJtLAJU9bJCj511WdDDkRWhAt3hdF+SdxsvStYZ+5b+ygjgckii +5ZrJJrveBSEaCX1Hmd7f3Q==
X-Google-Smtp-Source: APXvYqzjy4iMlsKpfzG1CTkt+rFhkxOmNiTCrNABs6yaCuF5ttt0YXvam+0/9iiSX6oGTuOw47Mji0ef2oX6PWiMLrs=
X-Received: by 2002:a2e:8855:: with SMTP id z21mr2709810ljj.212.1574149433205; Mon, 18 Nov 2019 23:43:53 -0800 (PST)
MIME-Version: 1.0
References: <157254438077.30463.2012864551682668420.idtracker@ietfa.amsl.com> <CA+k3eCQrdDqMTHD6bgV-jOTC5DRn3tj2RME1=jdzR6H3W45+BA@mail.gmail.com> <B204C984-265C-41E8-9883-A3199FDFD09B@forgerock.com>
In-Reply-To: <B204C984-265C-41E8-9883-A3199FDFD09B@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 19 Nov 2019 15:43:26 +0800
Message-ID: <CA+k3eCQn1Rt59oee69R5fW_7iay=HFEheRr459CjqP9v3v216w@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ca41090597ae3927"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uQN32hK46PozOc6hg88aCfLpvT4>
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: Tue, 19 Nov 2019 07:44:02 -0000

On Thu, Nov 14, 2019 at 7:20 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> I can't attend Singapore either in person or remotely due to other
> commitments. I broadly support adoption of this draft, but I have some
> comments/suggestions about it.
>

Thanks Neil. And sorry to hear that you won't be in Singapore. This kind of
stuff is definitely more easily discussed in person (for me anyway). But
I'll try and comment on your comments here as best I can. I also plan to
also mention them in the Wednesday and/or Thursday presentation.


> Section 2 lists the main objective as being to harden against
> compromised/malicious AS or RS, which may attempt to replay captured tokens
> elsewhere. While this is a good idea, a casual reader might wonder why a
> simple audience claim in the access token/introspection response is not
> sufficient to prevent this. Because interactions between the client and RS
> are supposed to be over TLS, is the intended threat model one in which
> these protections have broken down? ("counterfeit" in the description
> suggests this). Or is the motivation that clients want to get a single
> broad-scoped access token (for usability/performance reasons) and use it to
> access multiple resource servers without giving each of them the ability to
> replay the token to the other servers? Or are we thinking of a
> phishing-type vulnerability were a general-purpose client might
> accidentally visit a malicious site which prompts for an access token that
> the client then blindly goes off and gets? (UMA?) It's not clear to me
> which of these scenarios is being considered, so it would be good to
> tighten up this section.
>

It is admittedly a bit loose and I agree it'd be good to tighten it up. But
part of why it's loose is that it tries to offer some protections for all
those scenarios and more such as a general lost/stolen token. It's
effectively trying to provide as many of the same types of
protections/assurances that you'd get with TLS based PoP mechanisms (like
OAuth MTLS or Token binding) to the extent that can be done at the HTTP
application layer. Which can't realistically be exactly the same but can
maybe be kinda close while actually being accessible and implementable
because it's all done at the application layer. There are trade-offs, of
course, and the document writers have endeavored to find a good balance in
the trade-off decisions we've made. But that doesn't mean they are
necessarily the right decisions or are closed to discussion. To the casual
reader I would say that it turns out that getting an appropriate simple
audience claim into an access token isn't nearly as simple as it might
seem. And while it will prevent RS to RS replay (as long as both RSs aren't
legit audiences) it doesn't help with preventing the use of tokens stolen
or leaked by other means (including for refresh tokens issued to public
clients).



> Another potential motivation is for mobile apps. Some customers of ours
> would like to tie access/refresh tokens to private key material generated
> on a secure element in the device, that can only be accessed after local
> biometric authentication (e.g. TouchID/FaceID on iOS). I have suggested
> using mTLS cert-bound tokens for this, but have heard some pushback due to
> the difficulty of configuring support for client certs across diverse
> infrastructure. A simple JWT-based solution like DPoP could fill this need.
>

It's maybe not stated in the draft but this kind of thing is among the
objectives (in my mind anyway).



> My main concerns with the draft though are about efficiency and
> scalability of the proposed approach:
>
> 1. The requirement to use public key signatures, along with the
> anti-replay nonce, means that the RS is required to perform an expensive
> signature verification check on every request. That is not going to scale
> up well. While there are more efficient schemes like Ed25519 now, these are
> still typically an order of magnitude slower than HMAC and the latency and
> CPU overhead is likely to be a non-starter for many APIs (especially when
> you're billed by CPU usage). Public key signatures are also notoriously
> fragile (see e.g. the history of nonce reuse/leakage vulnerabilities in
> ECDSA or
>

Yes, asymmetric is more processing intensive than symmetric. But if you
take away the distributed replay check (see next response), it will scale
out just fine. I'm not so sure latency is a real issue here - while these
operations are an order of magnitude slower we're still talking about times
that are not perceptible to a human. CPU usage/cost is a part of a
trade-off for the simplicity afforded by public/private keys.  And it is
significantly simpler. The design you sketched out is admittedly quite
clever but it's not even in the same ballpark with respect to complexity.
And, as you pointed out, the other suggestion around symmetric keys has
rather different security properties while still adding complexity. Adding
symmetric key support isn't something that can just be added on easily.



>
> 2. The advice for the RS to store a set of previously used nonces to
> prevent replay will also hamper scalability, especially in large
> deployments where such state would need to be replicated to all servers (or
> use sticky load balancing, which comes with its own problems). This
> violates the statelessness of HTTP, and it also potentially breaks
> idempotency of operations: Think of the case where the JWT validation and
> replay protection is done at an API gateway but then the call to the
> backend API server fails for a transient reason. The client (or a
> proxy/library) cannot simply replay the (idempotent) request in this case
> because it will be rejected by the gateway. It must instead recreate the
> DPoP JWT, incurring additional overheads.
>

The actual value of replay checking on jti is somewhat questionable. The
DPoP JWT only transits between client and server so a TLS MITM is likely
needed to steal a DPoP JWT. But we are assuming TLS works here. And an
active MITM could thwart this check by just being first to present DPoP
JWT. I think the jti check made its way into the draft mostly because it
seemed like something was needed to try and bring it closer to the TLS PoP
models. Being aware of the scalability concerns, I did endeavor to write
the text in such a way so as to leave some wiggle room in
implementations/deployments with text like '"jti" SHOULD be used by the
server for replay detection and prevention` and [ensure that] 'within a
reasonable consideration of accuracy and resource utilization, a JWT with
the same "jti" value has not been received previously'. The idea being that
using something eventually consistent or even local only to the runtime
instance would be permissible. Perhaps that allowance and the rational
could be made more clear? Or would you suggest to do away with the jti
replay stuff al? Or something else?



> 3. Minor: The use of a custom header for communicating the DPoP proof will
> require additional CORS configuration on top of that already done for the
> Authorization header, and so adds a small amount of additional friction for
> adoption. Given that CORS configuration changes often require approval by a
> security team, this may make more of an impact than you'd expect.
>

Feels really minor. I mean, we could try to roll everything up under one
header. But it does seem unwarranted and would complicate things - at least
in the model we've got now where the proof is sent the same way ono all
types of requests.


It's also not clear to me exactly what threat the anti-replay nonce is
> protecting against. It does nothing against the replay scenario discussed
> in section 2, as I understand it - which really seems to be more of a MitM
> scenario. Given that the connection between the client and the RS is
> supposed to be over TLS, and TLS is already protected against replay
> attacks, I think this part needs to be better motivated given the obvious
> costs of implementing it.
>
> I have a tentative suggestion for an alternative design which avoids these
> problems, but at a cost of potentially more complexity elsewhere. I'll
> summarise it here for consideration:
>
> 1. The client obtains an access token in the normal way. When calling the
> token endpoint it provides an EC/okp public key as the confirmation key to
> be associated with the access/refresh tokens.
>
> 2. The first time the client calls an RS it passes its access token in the
> Authorization: Bearer header as normal. (If the RS doesn't support DPoP
> then this would just succeed and no further action is required by the
> client - allowing clients to opportunistically ask for DPoP without needing
> a priori knowledge of RS capabilities).
>
> 3. The RS introspects the access token and learns the EC public key
> associated with the access token. As there is no DPoP proof with the access
> token, the RS will generate a challenge in the following way:
>     o The RS generates an ephemeral EC key pair for the same curve as the
> confirmation key (e.g. P-256 or X25519).
>     o The RS stores the ephemeral private key somewhere, associated with
> this access token (see below for a scalable implementation choice)
>     o The RS encodes the ephemeral public key into a JWK (epk) and
> base64url-encodes it. It uses this as a challenge to the client by sending
> back a 401 response with WWW-Authenticate: DPoP <encoded-epk>
>
> 4. The client decodes the epk challenge and performs an ECDH key agreement
> between its private key and the challenge epk as per the method described
> for the existing JWA ECDH-ES encryption algorithm. Rather than deriving an
> AES key however, it derives a HMAC key for HS256. The "apu" value is set to
> the access token (string value as ASCII bytes) and the "apv" value is set
> to the hostname of the RS (e.g. "api.example.com"). This ensures that the
> derived key is cryptographically bound to the context in which it is used.
>
> 5. The client uses the HMAC key to create a DPoP proof JWT much like the
> one in the current draft, but signed using the HS256 key. If a "kid" field
> was present in the challenge JWK sent by the RS then the same value MUST be
> used in the "kid" header of this discharge JWT. It retries its original
> request sending Authorization: DPoP <hmac-jwt> at=<access_token>.
>
> 6. The RS uses its stored ephemeral private key to derive the same HMAC
> key and verify the DPoP discharge JWT. If it validates and all fields are
> correct then the request is allowed.
>
> Efficient implementation trick:
> Because the client is required to copy and "kid" value from the challenge
> JWK, the RS can preemptively carry out the ECDH key agreement immediately
> and generate the derived HMAC key. The RS can then encrypt this derived key
> using a local authenticated encryption key (e.g. AES-GCM) and use that
> encrypted value as the "kid" value in the challenge (perhaps along with
> some context or an expiry time). That way the RS only needs to decrypt this
> kid value rather than performing the ECDH key agreement on every request.
> This also avoids the need for the RS to store any per-client state locally.
>
> The challenge-response nature of the scheme prevents traditional replay
> attacks in the case where a DPoP discharge JWT is accidentally leaked
> through server logs or some other flaw, without needing to store nonces on
> the server. Using the RS's hostname in the key derivation process prevents
> mitm attacks in a similar way to how FIDO/WebAuthn prevents this. Most
> importantly, once a HS256 key has been derived between a client and RS they
> can reuse that key for multiple requests, reducing the overhead of the ECDH
> key agreement step. Either side can decide as a matter of policy how long
> to let this occur and when to trigger a fresh challenge-response.
>
> Because this fits within the standard HTTP authentication framework, it
> also requires no additional CORS configuration and is relatively easy to
> plug in to existing HTTP client libraries.
>
> The main downside of this approach to me is the fact that you can't simply
> reuse an existing JWT library to implement it, and so it will take time for
> client libs to develop. (Although I think this might be achievable now with
> existing *COSE* libraries). This would increase the risk of people
> hand-rolling solutions, rather than using well-tested libraries. On the
> other hand, it uses fairly widely supported primitives so e.g. an
> implementation using WebCrypto is probably only a few dozen lines of code.
>
> -- Neil
>
>
> On 31 Oct 2019, at 19:20, Brian Campbell <
> bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
>
> Hello WG,
>
> Just a quick note to let folks know that -03 of the DPoP draft was
> published earlier today. The usual various document links are in the
> forwarded message below and the relevant snippet from the doc history with
> a summary of the changes is included here for convenience.
>
> Hopefully folks will have time to read the (relativity) short document
> before the meeting(s) in Singapore where (spoiler alert) I plan to ask that
> the WG consider adoption of the draft.
>
> Thanks,
>
>  -03
>    o  rework the text around uniqueness requirements on the jti claim in
>       the DPoP proof JWT
>    o  make tokens a bit smaller by using "htm", "htu", and "jkt" rather
>       than "http_method", "http_uri", and "jkt#S256" respectively
>    o  more explicit recommendation to use mTLS if that is available
>    o  added David Waite as co-author
>    o  editorial updates
>
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Thu, Oct 31, 2019 at 11:53 AM
> Subject: New Version Notification for draft-fett-oauth-dpop-03.txt
> To: Torsten Lodderstedt <torsten@lodderstedt.net>et>, Michael Jones <
> mbj@microsoft.com>gt;, John Bradley <ve7jtb@ve7jtb.com <ve7jtb@ve7jtb..com>>,
> Brian Campbell <bcampbell@pingidentity.com>om>, David Waite <
> david@alkaline-solutions.com>gt;, Daniel Fett <mail@danielfett.de>
>
>
>
> A new version of I-D, draft-fett-oauth-dpop-03.txt
> has been successfully submitted by Brian Campbell and posted to the
> IETF repository.
>
> Name:           draft-fett-oauth-dpop
> Revision:       03
> Title:          OAuth 2.0 Demonstration of Proof-of-Possession at the
> Application Layer (DPoP)
> Document date:  2019-10-30
> Group:          Individual Submission
> Pages:          15
> URL:
> https://www.ietf.org/internet-drafts/draft-fett-oauth-dpop-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-fett-oauth-dpop/
> Htmlized:       https://tools.ietf.org/html/draft-fett-oauth-dpop-03
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-fett-oauth-dpop
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-fett-oauth-dpop-03
>
> Abstract:
>    This document describes a mechanism for sender-constraining OAuth 2.0
>    tokens via a proof-of-possession mechanism on the application level.
>    This mechanism allows for the detection of replay attacks with access
>    and refresh tokens.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> *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
>
>
>

-- 
_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._