[OAUTH-WG] Security BCP and mTLS/PoP tokens

Neil Madden <neil.madden@forgerock.com> Wed, 29 January 2020 09:48 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 657C0120806 for <oauth@ietfa.amsl.com>; Wed, 29 Jan 2020 01:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id riK9_H85o6Iw for <oauth@ietfa.amsl.com>; Wed, 29 Jan 2020 01:48:23 -0800 (PST)
Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 2B48E12026E for <oauth@ietf.org>; Wed, 29 Jan 2020 01:48:22 -0800 (PST)
Received: by mail-wm1-x331.google.com with SMTP id g1so5441642wmh.4 for <oauth@ietf.org>; Wed, 29 Jan 2020 01:48:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=mXceTFefS8gV1jmQ2IpZDJAH0h1AVP8s5og0l1QrcEM=; b=U6aHrfOj81fusENaslX+RcoNMTBghUlhse2vvvXSlJNXMVr490Q6ksPv3KmFdDE5AT yeHCd5O4dvN4qvS3x8y0vb/cIp8cI+G/nESYS/ywMQifp8t4x9h0eRmWqFPfWN6WD4rl 2MSeTEcdPSfgtpZ0hw1Q6Vd5+uekodWO8H1ZA=
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:message-id:date:to; bh=mXceTFefS8gV1jmQ2IpZDJAH0h1AVP8s5og0l1QrcEM=; b=HtKwZilOB3taTpxvjlf9BihMylSuOeKJ2CmfgSkSGmGn19p39rGJg6Svjqm/NCBkE4 B3LofLcCPYaev5PogsEt+uIDs48Mko/17bkrAhjLrwNJN8RB32GCyF8GlrvxB+swmjK3 ZuI2CkijS8Fbs5swdls5A0m3KV2zh1NIxwhYB+nXxwXVB/63ZyYBqspCMQ5d254YOUiN /MSPaQRf6MBl49z3mZmCJ4/pVUaiSxdJAYmiVYpJNBVLbW9PZTuT15hiAEVWhJkKnmFh N0pLCUG1p8wbaDVrotig8T23sC9oH8LCBHNSx1KHKAe4qkQBFZBONeC3TiwDYSEV2uIZ KRnA==
X-Gm-Message-State: APjAAAUiwM49QwDEo1SAPOvdm1vJ759Gip4zw0LwHWizIn5fbOiTU7zn VQvP3fcFdTZNu8e6UYS4y31uidtpBI3GRTQw3KE1dIwV6vbnOKkqosbqRND9n0yhQwD2/ffB7Gp Bq3jMpInMz7UTVO3CHHc+jgSSgE9pLvVt/40/wv9f7Iw2wiNa3FC70w4tSJA5RAvppA==
X-Google-Smtp-Source: APXvYqxfPRA/wWB7niTBt8YcP0iLqll0taG+QELvsNgwUQ9hIy4gjg6wmWaDVM9Hovh2HQwz+G6pPA==
X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr10965608wmo.13.1580291300847; Wed, 29 Jan 2020 01:48:20 -0800 (PST)
Received: from [] ( []) by smtp.gmail.com with ESMTPSA id c15sm2131433wrt.1.2020. for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jan 2020 01:48:20 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8A61F5A5-5E35-4A95-919F-B3A2BDABA263"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Message-Id: <A31A449B-1DBD-4C0F-9A93-981EE3381B46@forgerock.com>
Date: Wed, 29 Jan 2020 09:48:19 +0000
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/oPNWfOSWth6iKZbHOTSGWUj6kwM>
Subject: [OAUTH-WG] Security BCP and mTLS/PoP tokens
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, 29 Jan 2020 09:48:25 -0000

I was wondering if the security BCP should mention something about what an RS should do if it encounters a token introspection response or JWT claims set that contains a "cnf" value, but either:

 * the RS doesn't support any kind of PoP/sender-constraints at all, or
 * the RS doesn't understand the particular confirmation method(s) in the "cnf" object

At the moment, the generic rules in RFC 7519 for processing JWTs say:

   Specific applications of JWTs will require implementations to
   understand and process some claims in particular ways.  However, in
   the absence of such requirements, all claims that are not understood
   by implementations MUST be ignored.

I think for confirmation keys we want to have specific requirements that say that an access token with a not-understood confirmation method should be rejected. Otherwise a client may be using a token on the understanding that it is PoP-protected/sender-constrained when the RS is silently ignoring these constraints.

In retrospect, it's a shame that JWT doesn't have something like "crit" for claims rather than headers. (We could perhaps bootstrap this by adding a new critical-claims header, which itself can be marked critical, but that won't help for normal JSON token introspection responses).

PS - the latest security BCP draft appears to have expired. Is a new version pending?