Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt

Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 12 November 2017 03:55 UTC

Return-Path: <torsten@lodderstedt.net>
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 9E929127078 for <oauth@ietfa.amsl.com>; Sat, 11 Nov 2017 19:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 u_udDTf799MQ for <oauth@ietfa.amsl.com>; Sat, 11 Nov 2017 19:55:11 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39FD120721 for <oauth@ietf.org>; Sat, 11 Nov 2017 19:55:10 -0800 (PST)
Received: from [42.61.210.59] (helo=[10.10.4.143]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <torsten@lodderstedt.net>) id 1eDjMR-0001Ub-SV; Sun, 12 Nov 2017 04:55:08 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-Id: <D4C050B6-E267-4248-ABC1-E177124D6386@lodderstedt.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_E02C8707-42B2-471D-A1A9-BB73C72A1767"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 12 Nov 2017 11:55:04 +0800
In-Reply-To: <CA+k3eCT7u2SCnt=vQh5QbMWkg5XUt=Ly7aOG-e82j+7zj4PNrg@mail.gmail.com>
Cc: Takahiko Kawasaki <daru.tk@gmail.com>, oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell@pingidentity.com>
References: <150784500346.16836.10053591552617872796@ietfa.amsl.com> <CA+k3eCSD73-djpiUOq3u+arXjsUQ=aZsiA8Xv2tUM6mSecwvdA@mail.gmail.com> <83c305ab-4c3b-b16e-1385-7e0e3af6a556@connect2id.com> <CA+k3eCTGPiMKSqDmAoRjzjG8fgiq2=HU5vbwyaSXkDJXTxMO2Q@mail.gmail.com> <CAGpwqP9hsR51XNnueSfhwmD07cE6xZe5w8cMJ5Q1e7R3hiVWfA@mail.gmail.com> <CA+k3eCT7u2SCnt=vQh5QbMWkg5XUt=Ly7aOG-e82j+7zj4PNrg@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/H2X6vd2NuwQEhfEZ_0rM6NVKpPM>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 12 Nov 2017 03:55:14 -0000

> Am 09.11.2017 um 04:42 schrieb Brian Campbell <bcampbell@pingidentity.com>om>:
> 
> There is no special reason for the "mutual_tls_sender_constrained_access_tokens" name that I'm aware of. I believe Torsten chose the name and based it off of language in the draft. While "certificate_bound_access_tokens" does sound somewhat more natural, I'm hesitant to change it at this point. Unless there's support/consensus from the WG to make the change?

I choose „sender" because this is the terminology John and I use in https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.4.1.2 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-03#section-4.4.1.2> to describe a certain kind of mechanisms for token phishing prevention. I’m fine with using „certificate“ instead of „sender“ in this spec as the more precise term. I feel we need to keep a suitable prefix to indicate the connection to mutual tls or tls client auth, respectively, but I’m not bound to it.