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

Brian Campbell <bcampbell@pingidentity.com> Wed, 08 November 2017 20:42 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 8A93F12957F for <oauth@ietfa.amsl.com>; Wed, 8 Nov 2017 12:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level:
X-Spam-Status: No, score=-2.44 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 0j_P5qk9xS8F for <oauth@ietfa.amsl.com>; Wed, 8 Nov 2017 12:42:41 -0800 (PST)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 BA956126579 for <oauth@ietf.org>; Wed, 8 Nov 2017 12:42:41 -0800 (PST)
Received: by mail-it0-x234.google.com with SMTP id p138so8497390itp.2 for <oauth@ietf.org>; Wed, 08 Nov 2017 12:42:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=laeZ77d06FxpnXiVTPI/PquaH8VmldQDFjhb70TiMao=; b=heYLfZ6jeNGWXvXcRCxvi0WB1A6HV3dyNMuxfpvUzlbQX0eMD+qP0D3jtO+nPxUwR6 BqKyLwetoj0PbJYtcRco4+RWIBLBKkfTXnyV5XH5uyFDBoTVU5F46WfCnuq8HOGKGVpe Ay6gRTh4BLTeExvX1/5NtmKvuj1VSvm93PA0c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=laeZ77d06FxpnXiVTPI/PquaH8VmldQDFjhb70TiMao=; b=ElcNHFH55+ebdso69nTdRwdYnd/o0EjKrxzVbSb7dfkTPkEGQTZidIEr2R1qTXmn+8 2ta+5i0sCVLU7M3FL22rKxywGvj9AnLtoIhOjMQV3VaW3q0DU1F275yfiUJjklMHJFc6 ciRKfOcPJ9fBo5j/mgx2ZUKZ4fUWZXLIMSeq5BgoAnkOtYCE60edPlgB/Y1F8gf6Bevl bEt4lPSi+6sYzvICYOr42ZWbBw6sICMWrIm/Quf57PgJtbcr4DtpJe2FQsd2535WFp37 JGRFTfnslhsoQmmyAIR8bjknvJCcN2z81kzZWS8q8O2UgckcGOENlKyo5Xt95Cg986QD 0fWA==
X-Gm-Message-State: AJaThX7NoVbOKRcLMFHDH1FaalJvuY+6v2q3ThoucT0jgiCGJ3gkErsl Hn/pi4dxlPx6a/QRR6zNn5Intc8rO6F3oKmjj2ig7MmX/QFczi+g6kTuNaCcD/Unq049dzs+gmm enAdYA7niRT8DlA==
X-Google-Smtp-Source: ABhQp+R1ke0KY+GinrCl8wb/7rZU7rimZmf7EVOyE6KLp0cLf/heo+2OO2GFxjVlPs3AbEjv8e4WvuH5IneNLy1zFS8=
X-Received: by 10.36.23.215 with SMTP id 206mr2383533ith.62.1510173760921; Wed, 08 Nov 2017 12:42:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.106.34 with HTTP; Wed, 8 Nov 2017 12:42:10 -0800 (PST)
In-Reply-To: <CAGpwqP9hsR51XNnueSfhwmD07cE6xZe5w8cMJ5Q1e7R3hiVWfA@mail.gmail.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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 8 Nov 2017 13:42:10 -0700
Message-ID: <CA+k3eCT7u2SCnt=vQh5QbMWkg5XUt=Ly7aOG-e82j+7zj4PNrg@mail.gmail.com>
To: Takahiko Kawasaki <daru.tk@gmail.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a114376ee91bdd7055d7eba1c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/T32IPCwquX0YcHMbqIIiMfnUHsE>
Subject: Re: [OAUTH-WG] Fwd: 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: Wed, 08 Nov 2017 20:42:44 -0000

Thank you for the review and comments, Takahiko.

I've made all the editorial fixes in the github working copy so they will
be in the next draft. I'll plan to publish that when the publication window
opens again.

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?

Section 6 of The OAuth 2.0 Authorization Framework / RFC 6749 requires that
refresh tokens be bound to the client to which they are issued. That
indirectly binds the refresh token to the client credentials, which would
be a certificate in the case of Mutual TLS OAuth Client Authentication. So
I don't believe any additional treatment of refresh tokens is needed in the
draft.



On Wed, Nov 8, 2017 at 4:34 AM, Takahiko Kawasaki <daru.tk@gmail.com> wrote:

> Dear Brian,
>
> I'd like to make some small comments.
>
> 2. / 1st paragraph / 4th line
> "for client authentications" --> "for client authentication"
> (remove 's' at the end)
>
> 2.1.1. / 1st paragraph / 4th line
> "used to indicated" -> "used to indicate"
> (remove 'd' at the end)
>
> 2.2. / 1st paragraph / 3rd line
> "a X.509 certificate" -> "an X.509 certificate"
> (replace "a" with "an")
>
> 2.2. / 1st paragraph / 11th line
> "info of one the" -> "info of one of the"
> (insert "of" between "one" and "the")
>
> 2.2. / 1st paragraph / 17th line
> "directly with at the" -> "directly at the"
> (remove "with")
>
> 2.2.1. / 1st paragraph / 4th line
> "used to indicated" -> "used to indicate"
> (remove 'd' at the end)
>
> 3.1. / 1st paragraph / 1st line
> "as a JSON Web Tokens" -> "as JSON Web Tokens"
> (remove 'a')
>
> 3.1. / 2nd paragraph / 6th-7th lines
> "are also sometimes also" -> "are sometimes also"
> (remove one "also")
>
> 3.3. & 3.4.
> After reading the specification, for me, "certificate_bound_access_tokens"
> sounds more natural than "mutual_tls_sender_constrained_access_tokens".
> Is there any special reason for the parameter name?
>
> 4.3. / 1st paragraph / 1st line
> "allows for the use" -> "allows use"
> (remove "for the", but I'm not sure because I'm not a native English
> speaker.)
>
> 6.1. / 1st paragraph / 2nd line
> "it is latest" -> "it is the latest"
> (insert "the" between "is" and "latest")
>
> By the way, isn't it necessary to define rules for REFRESH tokens? For
> example, "if a refresh token is issued, it MUST/SHOULD/MAY be also bound to
> the same certificate. When the token endpoint of the authorization server
> receives a refresh token request with a certificate-bound refresh token,
> ..."
>
> Best Regards,
> Taka
>
>
> 2017-10-13 17:31 GMT+01:00 Brian Campbell <bcampbell@pingidentity.com>om>:
>
>> Thanks for the review, Vladimir. And yes, sender-constrained access
>> tokens should also work in a token exchange scenario.
>>
>> On Fri, Oct 13, 2017 at 3:18 AM, Vladimir Dzhuvinov <
>> vladimir@connect2id.com> wrote:
>>
>>> Superb! Thanks for putting down everything that was discussed. I read
>>> the new version and have zero comments about it.
>>>
>>> Will sender-constrained access tokens also work in a token exchange
>>> scenario?
>>>
>>> (draft-ietf-oauth-token-exchange-09)
>>>
>>> Vladimir
>>>
>>> On 13/10/17 01:07, Brian Campbell wrote:
>>>
>>> I'm pleased to announce that a new draft of "Mutual TLS Profile for OAuth
>>> 2.0" has been published. The changes, based on feedback and discussion on
>>> this list over the last two months, are listed below.
>>>
>>>    draft-ietf-oauth-mtls-04<https://tools.ietf.org/html/draft-ietf-oauth-mtls-04> <https://tools.ietf.org/html/draft-ietf-oauth-mtls-04>
>>>
>>>    o  Change the name of the 'Public Key method' to the more accurate
>>>       'Self-Signed Certificate method' and also change the associated
>>>       authentication method metadata value to
>>>       "self_signed_tls_client_auth".
>>>    o  Removed the "tls_client_auth_root_dn" client metadata field as
>>>       discussed in https://mailarchive.ietf.org/arch/msg/oauth/<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> <https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
>>>       swDV2y0be6o8czGKQi1eJV-g8qc<https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc> <https://mailarchive.ietf.org/arch/msg/oauth/swDV2y0be6o8czGKQi1eJV-g8qc>
>>>    o  Update draft-ietf-oauth-discovery<https://tools.ietf.org/html/draft-ietf-oauth-discovery> <https://tools.ietf.org/html/draft-ietf-oauth-discovery> reference to
>>> -07
>>>    o  Clarify that MTLS client authentication isn't exclusive to the
>>>       token endpoint and can be used with other endpoints, e.g.  RFC<https://tools.ietf.org/html/rfc7009> <https://tools.ietf.org/html/rfc7009>
>>>       7009 <https://tools.ietf.org/html/rfc7009> <https://tools.ietf.org/html/rfc7009> revocation and 7662
>>> introspection, that utilize client
>>>       authentication as discussed in
>>>       https://mailarchive.ietf.org/arch/msg/oauth/<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> <https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>
>>>       bZ6mft0G7D3ccebhOxnEYUv4puI<https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI> <https://mailarchive.ietf.org/arch/msg/oauth/bZ6mft0G7D3ccebhOxnEYUv4puI>
>>>
>>>    o  Reorganize the document somewhat in an attempt to more clearly
>>>       make a distinction between mTLS client authentication and
>>>       certificate bound access tokens as well as a more clear
>>>       delineation between the two (PKI/Public key) methods for client
>>>       authentication
>>>    o  Editorial fixes and clarifications
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: <internet-drafts@ietf.org> <internet-drafts@ietf.org>
>>> Date: Thu, Oct 12, 2017 at 3:50 PM
>>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
>>> To: i-d-announce@ietf.org
>>> Cc: oauth@ietf.org
>>>
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>>>
>>>         Title           : Mutual TLS Profile for OAuth 2.0
>>>         Authors         : Brian Campbell
>>>                           John Bradley
>>>                           Nat Sakimura
>>>                           Torsten Lodderstedt
>>>         Filename        : draft-ietf-oauth-mtls-04.txt
>>>         Pages           : 18
>>>         Date            : 2017-10-12
>>>
>>> Abstract:
>>>    This document describes Transport Layer Security (TLS) mutual
>>>    authentication using X.509 certificates as a mechanism for OAuth
>>>    client authentication to the authorization sever as well as for
>>>    certificate bound sender constrained access tokens.
>>>
>>>
>>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>>>
>>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-04https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-04
>>>
>>> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-04
>>>
>>>
>>> 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.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.*
>>
>> _______________________________________________
>> 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.*