[OAUTH-WG] DPoP followup I: freshness and coverage of signature

Brian Campbell <bcampbell@pingidentity.com> Wed, 02 December 2020 20:49 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 D4E1E3A149F for <oauth@ietfa.amsl.com>; Wed, 2 Dec 2020 12:49:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_RATIO_06=0.001, 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 (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 IHG5xWWg7dGu for <oauth@ietfa.amsl.com>; Wed, 2 Dec 2020 12:49:28 -0800 (PST)
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 2A3A93A1491 for <oauth@ietf.org>; Wed, 2 Dec 2020 12:49:27 -0800 (PST)
Received: by mail-lf1-x12b.google.com with SMTP id s30so6903111lfc.4 for <oauth@ietf.org>; Wed, 02 Dec 2020 12:49:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=jgcSgrw3o4j9YX870NqvjTbOn507oHfg2sbuZihgZow=; b=V7D1UaVCtxg/v2BqiSGSpLdwvzYQijzaTb5IlUg5WSkh4E3BcgPhXXVBUb4uNQjLls QZSJn+dBGqUvheKSLxZevGSSXPNFFE1AONuD6P45bdp144O5J/hVt5WB3WTxu/9W/Hd+ 2nBmqAEnYrYf4t2q5++GtZthaI/OI96RhrjjWp4YaTp4O/geniniz+XrdenknGQWKlfg LL1B/0axXZcXrXhjHUniXZ4iJDgDDBKOTR0y3U6yozOI61oX+E9oUL9jzh91RahmYzgg EHAyUjrn6BM5g/d61IezhTgVdHOywd2MNHCd3FwU8w6yrsLbGeQSWbh8ThI4GknMF6z7 BKkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jgcSgrw3o4j9YX870NqvjTbOn507oHfg2sbuZihgZow=; b=d/klge2txaoApw4qg/IF4JEnyWyc1serEmOQdVu7Irgn0fAQRkayx/ccPnGUDFH6Qa tiLyQkNloaWVaqzW5SnCArHCtB5W9eDgk8VWtZcipqFE9SY9dc5Z01pVTdZH0XvijMpT kD7tp7Z+/nM09V3cdK97qcFACRcdiSz1qfvgmnJSXaf3ycuxD5qwjW/D23WbigZBW27m 3tvJbR7mj6LlP04z9bRMP4YWllw/H/VU3n2RuH0I/QWvWdAQI7fbPAhrsHlNR0ZvBxx1 FNg6zoUp1t/iwr/YrUvTdqylBoElPVfSDq6DYWhKfAP29wf4KELjIQ3+gv7dAPcq3640 3A+A==
X-Gm-Message-State: AOAM533WuuNb9fi9es8iWS4PfTH3WWL2KUUdpWkZeoqol66qZgodRr6Z T4nWuyU5DQvlGGLgHoZhug27FD45dDfC/hIDuyQm8jsXKSFjYUzU7pny2V4hOYo30yQEMQRw1RD fiq1fcad2eV+ivLs845eOAA==
X-Google-Smtp-Source: ABdhPJzhsaxETF68YVJmi3fz+rpVp/gWw14gOg3vW4zJLoy+vBHIL+dJe6bGM+e2p/rVbDaAcfvU50OZa4uxg8ywH9Y=
X-Received: by 2002:a19:5215:: with SMTP id m21mr2002985lfb.407.1606942164057; Wed, 02 Dec 2020 12:49:24 -0800 (PST)
MIME-Version: 1.0
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 2 Dec 2020 13:48:57 -0700
Message-ID: <CA+k3eCSyMWyLYorWH7KY+XR1syAQUi4tQXdUuevKz4Y6xNMheA@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/related; boundary="000000000000dd6c6d05b581600c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/QKMHo6gGRAaANadsAWWlSuRDzXA>
Subject: [OAUTH-WG] DPoP followup I: freshness and coverage of signature
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: Wed, 02 Dec 2020 20:49:30 -0000

There were a few items discussed somewhat during the recent interim
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
that I committed to bringing back to the list. The slide below (also
available as slide #17 from the interim presentation
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
is the first one of them, which is difficult to summarize but kinda boils
down to how much assurance there is that the DPoP proof was 'freshly'
created and that can dovetail into the question of whether the token is
covered by the signature of the proof.
There are many directions a "resolution" here could go but my sense of the
room during the meeting was that the contending options were:

   1.  It's sufficiently okay as it is
   2.  Include a hash of the access token in the DPoP proof (when an access
   token is present)


Going with #2 would mean the draft would also have to define how the
hashing is done and deal with or at least speak to algorithm agility.
Options (that I can think of) include:

   - 2a) Use the at_hash claim defined in OIDC core
   https://openid.net/specs/openid-connect-core-1_0.html#CodeIDToken. Using
   something that already exists is appealing. But its hash alg selection
   routine can be a bit of a pain. And the algorithm agility based on the
   signature that it's supposed to provide hasn't worked out as well as hoped
   in practice for "new" JWS signatures
   https://bitbucket.org/openid/connect/issues/1125/_hash-algorithm-for-eddsa-id-tokens
   - 2b) Define a new claim ("ah", "ath", "atd", "ad" or something like
   that maybe) and just use SHA-256. Explain why it's good enough for now and
   the foreseeable future. Also include some text about introducing a new
   claim in the future if/when SHA-256 proves to be insufficient. Note that
   this is effectively the same as how the confirmation claim value is
   currently defined in this document and in RFC8705.
   - 2c) Define a new claim with its own hash algorithm agility scheme
   (likely similar to how the Digest header value or Subresource Integrity
   string is done).


I'm requesting that interested WG participants indicate their preference
for #1 or #2. And among a, b, and c, if the latter.

I also acknowledge that an ECDH approach could/would ameliorate the issues
in a fundamentally different way. But that would be a distinct protocol. If
there's interest in pursuing the ECDH idea, I'm certainly open to it and
even willing to work on it. But as a separate effort and not at the expense
of derailing DPoP in its general current form.
[image: Slide17.jpeg]

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