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

From: Takahiko Kawasaki <[email-masked]>
Date: Wed, 8 Nov 2017 11:34:50 +0000

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 <[email-masked]>:

> 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 <
> [email-masked]> 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: <[email-masked]> <[email-masked]>
>> Date: Thu, Oct 12, 2017 at 3:50 PM
>> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-04.txt
>> To: [email-masked]
>> Cc: [email-masked]
>>
>>
>>
>> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [email-masked]
>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 8 Nov 2017 13:42:10 -0700

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 <[email-masked]> wrote:

> sounds more natural than "mutual_tls_sender_constrained_access_tokens".
> Is there any special reason for the parameter name?
>
>> Thanks for the review, Vladimir. And yes, sender-constrained access
>> tokens should also work in a token exchange scenario.
>>
>>> Superb! Thanks for putting down everything that was discussed. I read
>>> the new version and have zero comments about it.
>>>

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 12 Nov 2017 11:55:04 +0800

> Am 09.11.2017 um 04:42 schrieb Brian Campbell <[email-masked]>:
> 
> 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.