Yeah Filip, that's about right. Currently the text says to do it only for public clients (clients using "none").
On Thu, Mar 14, 2019 at 6:53 AM Filip Skokan <[email protected]> wrote: > Thank you for the clarification Brian, this makes sense. > > So for clients not using mtls (or is this only clients using "none"?) to > authenticate the tls_client_certificate_bound_access_tokens client metadata > property also conditions binding the refresh token. At the cost of the RT > being unusable if the client loses or rotates the certificate. > > Best, > *Filip* > > > On Thu, 14 Mar 2019 at 13:29, Brian Campbell <[email protected]> > wrote: > >> Yeah, so regular old RFC 6749 OAuth requires that a refresh token be >> bound to the client to whom it was issued. And that confidential clients >> (those having established authn credentials) authenticate to the AS when >> presenting a refresh token. Thus, for both MTLS methods of OAuth client >> authentication, refresh tokens are indirectly certificate-bound through >> their binding to a client and its credentials (and the client rotating its >> cert doesn't invalidate the refresh token). >> >> What was added in the -13 revision of the draft (in a new section >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-4) was a >> brief description of certificate binding refresh tokens for public clients. >> >> The ask from Vittorio was a mention of refresh tokens in abstract. Which >> seems reasonable. But the proper wording to succinctly and accurately >> convey the aforementioned subtleties is proving difficult for me. >> >> >> >> >> >> On Thu, Mar 14, 2019 at 2:26 AM Neil Madden <[email protected]> >> wrote: >> >>> Right - this is what we have implemented. No support for >>> certificate-bound refresh tokens, the client can be configured to require >>> TLS cert client authentication instead. >>> >>> Neil >>> >>> On 14 Mar 2019, at 08:09, Filip Skokan <[email protected]> wrote: >>> >>> Point being that since the refresh token is only usable on the IdP then >>> mtls client auth already covers this, and since RTs are long-lasting, it >>> does this better because cert rotation is possible for both mtls methods. >>> >>> S pozdravem, >>> *Filip Skokan* >>> >>> >>> On Thu, 14 Mar 2019 at 08:07, Filip Skokan <[email protected] >>> <[email protected]>> wrote: >>> >>>> Even before refresh tokens were mentioned in draft 13 i was about to >>>> implement this binding in nodejs oidc-provider, >>>> >>>> the thing i struggled with and ultimately didn't do this was >>>> >>>> 1) if the refresh token is bound to a specific cert then this cert >>>> rotation is out of the question >>>> 2) if having the RT somehow covered is needed, isn't MTLS client auth >>>> already the right thing to do? Especially given it supports cert rotation >>>> >>>> Now the normative language is SHOULD therefore disallowing cert >>>> rotation. Or am I missing something? >>>> >>>> S pozdravem, >>>> *Filip Skokan* >>>> >>>> >>>> On Thu, 14 Mar 2019 at 00:21, Brian Campbell <bcampbell= >>>> [email protected]> wrote: >>>> >>>>> As I kinda said on that call, I understand the ask and I do think it'd >>>>> be reasonable to mention refresh tokens in the abstract now that the >>>>> document does describe binding refresh tokens to the client certificate >>>>> with public clients. >>>>> >>>>> I'm struggling to see the fix as pretty easy, however, given the text >>>>> of the abstract (copied below for ease of reference) and the content and >>>>> scope of the document. >>>>> >>>>> Do you think changing the first sentence to have "certificate-bound >>>>> access and refresh tokens" is sufficient (and accurate)? >>>>> >>>>> Or something more or different? In which case proposed text is always >>>>> welcome. >>>>> >>>>> Abstract >>>>> >>>>> This document describes OAuth client authentication and certificate- >>>>> bound access tokens using mutual Transport Layer Security (TLS) >>>>> authentication with X.509 certificates. OAuth clients are provided a >>>>> mechanism for authentication to the authorization server using mutual >>>>> TLS, based on either self-signed certificates or public key >>>>> infrastructure (PKI). OAuth authorization servers are provided a >>>>> mechanism for binding access tokens to a client's mutual TLS >>>>> certificate, and OAuth protected resources are provided a method for >>>>> ensuring that such an access token presented to it was issued to the >>>>> client presenting the token. >>>>> >>>>> >>>>> On Mon, Mar 11, 2019 at 4:06 PM Vittorio Bertocci <vittorio.bertocci= >>>>> [email protected]> wrote: >>>>> >>>>>> Hi all, >>>>>> during today's office hours call I pointed out that oauth-mtls-13's >>>>>> abstract >>>>>> only mentions access token, although the spec does provide (some) >>>>>> guidance >>>>>> on refresh token binding as well.. >>>>>> Although in the end implementers would do the right thing, given that >>>>>> they have to read the spec in its entirety, having a mention of refresh >>>>>> tokens in the abstract as well would make it easier for superficial >>>>>> readers >>>>>> to learn that the spec does address RTs as well. Refresh tokens leakage >>>>>> is >>>>>> one of the top concerns of the customers I deal with, and those people >>>>>> rarely read specs from cover to cover: having language in the abstract >>>>>> explicitly calling out RTs might make some conversations easier. >>>>>> >>>>>> This is admittedly very minor, but the fix would also be pretty easy, >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> 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 protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> 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.* > > -- _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 protected] https://www.ietf.org/mailman/listinfo/oauth
