[OAUTH-WG] DPoP and MTLS - friends or foes?

Dmitry Telegin <dmitryt@backbase.com> Fri, 12 November 2021 16:38 UTC

Return-Path: <dmitryt@backbase.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 A41553A0C37 for <oauth@ietfa.amsl.com>; Fri, 12 Nov 2021 08:38:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_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=backbase.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 eUBsMp5DPcj7 for <oauth@ietfa.amsl.com>; Fri, 12 Nov 2021 08:38:25 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 E62063A0C57 for <oauth@ietf.org>; Fri, 12 Nov 2021 08:38:10 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id n12so14133412lfe.1 for <oauth@ietf.org>; Fri, 12 Nov 2021 08:38:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=backbase.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=pjJGYLyEnCvngaihnHyx+DeXXDB8zsS3WZDt67LD8w4=; b=RDDPVFtzFb2n2nUT1cdSGVOBz6+tFn16R7wni9dGk+MyyWFvAJsuxQXzdZPlXM6sg/ kt35GayjjcZWjCOQzP2L5ntv3JMBXQndrJNow1ozCEa9Ap7sE+wAkU4kruQ3hRMJyaMw 15IGHPjaoi8Y/kGfehrP7Sapj8ldNCZK3NSwjHAYTLbewq8D7WSI3NO0Jtch4h+t6O0w 2N6ZDRNXdKxzDW5oJWGs2mszXsFkUo+FAEInp+IBNIgo/xaSj4mQCO4BEbZ2KT4tSdNr zpAlc9UFillxkLZ11ySydQ0YdCe4mAsRKgLWifdpxMpL5Z+rkjqGKg9DPEzJ/gmvXFqb 2E+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=pjJGYLyEnCvngaihnHyx+DeXXDB8zsS3WZDt67LD8w4=; b=IcH42krJ7mocFIin3ChLnBMJdLUjce7j35QATAizC5/wl/rl7HwXG6h4OZF6X7tLrS cAeHMK4GsJW/efgcnIh573NtlLsCT7WBA3gATLs2HIMSWDIvnQhckor2FA74ixbbBmXW nZ1t3+R7HzCYJeQANqjeMmAghrj5lt+eleQl/vWPwH3uNl4VXzuk8dBPbAuLDSMQ19/O v1LtE4fCURHcyM4Ub79tGgHHy+pHy9psaDG1ot8olFSpYfxhR8+MkzMGURyE1Q8p+4u2 po4Ib4ZdMF09pFV4TvWgtcVRPAo+uGYcvmxN5TLtEVKIr1RTLgABXrvHLniRrFQ2GAB/ 1xGA==
X-Gm-Message-State: AOAM532YqszZ2wgKCzvq/uG4oWnmvnnMf/zlb7IxNiA3Xzz90x3oXMDZ +pvmx4mc1SD3YTKBB8MbVhRv7ly0+kdzV3lSojUMbmjmndfYWQ==
X-Google-Smtp-Source: ABdhPJzNOp43gQAuF8XkvN8YWJVnIGsHcMBZgSbR3uQ0JviCrs8pzRS6yh4311mEQmuzPRFv57EeP3XBey2Cg0YyZHA=
X-Received: by 2002:a05:6512:11cc:: with SMTP id h12mr15370415lfr.110.1636735088015; Fri, 12 Nov 2021 08:38:08 -0800 (PST)
MIME-Version: 1.0
From: Dmitry Telegin <dmitryt@backbase.com>
Date: Fri, 12 Nov 2021 19:37:57 +0300
Message-ID: <CAOtx8Dnq31Z+CRP+e3knnekev2q8on1dis=CBz+a82yhf27iZg@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008371ad05d09a15cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/M8TF-3oO8KxrKg8CgSa8v8gLhlI>
Subject: [OAUTH-WG] DPoP and MTLS - friends or foes?
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, 12 Nov 2021 16:38:30 -0000

As an implementer of one binding mechanism (DPoP) for the AS (Keycloak)
that already features another (MTLS), I'm running into the question whether
we should allow those two to be used simultaneously (which could be of
course extrapolated to other hypothetical mechanisms). By "simultaneously"
I mean binding a single token using both methods given that the material
for both has been provided with the request.

I guess currently mutual exclusivity is implied. Though in theory the "cnf"
section of the AT could contain both "jkt" and "x5t#S256", the mechanisms
are using different values for "token_type" and authentication scheme
("DPoP" for DPoP, "Bearer" for MTLS, though the latter might change to
"MTLS" in the future) and we define no mechanism to combine them (could be
"Bearer+DPoP" or "DPoP+MTLS" for example, which would be valid as per RFCs
7230 and 7235).

I apologize if the question has been asked before; didn't find anything
relevant in the ML. The implementer of MTLS for Keycloak also voted for
mutually exclusive behavior.

- Dmitry
Backbase / Keycloak