Comments in-line: > On 14 Mar 2019, at 18:50, Brian Campbell <bcampb...@pingidentity.com> wrote: > > Certificate-binding refresh tokens issued to *public clients* (those that > don't have authentication credentials established with the AS, a.k.a. clients > configured or registered with the "none" authentication method, which will > typically be native apps on a phone or similar) adds protections against > malicious use or reuse of those refresh tokens where no protections would > otherwise exist.
Refresh tokens have a different threat model to access tokens as they are only communicated directly between the client and the AS over a secure channel.. The main risk is of them being compromised on the client [*], but then a private key is at the same risk. Even if you generate the private key in a TPM on the device (eg mobile device with secure hardware), any malicious actor that is able to extract the refresh token from the client is also presumably in a position to either proxy requests through an existing TLS connection on that client or else interact with the TPM to create a new one. [*] Or by a compromise of TLS, but that breaks everything. > It's true that certificate rotation in that situation would invalidate the > refresh token. But not being able to rotate a strong asymmetric credential > without invaliding the refresh token seems a very reasonable trade off vs. > not having a credential bound to the token at all. I would not make that trade-off. If you are at OSW next week, I am presenting some cases for OAuth mTLS in a kubernetes environment that have public clients with long-lived grants that use refresh tokens to periodically rotate certs. > I guess I would say that what is returned when introspecting such a refresh > token is an implementation detail that is at the discretion of said > implementation. That seems consistent with the level of guidance in > introspection for refresh tokens currently. And there's not really an > interoperability angle that I can see. So that seems fine. Also, some form of > authorization is required to access the introspection endpoint so I'm not > sure how a refresh token issued to a public client would realistically get > introspected. I guess, if I'm being honest, I don't really get refresh token > introspection in general so probably better that I stop opining on the > subject. Ok, I’m happy to just ignore that aspect for refresh tokens then. — Neil > > > > > > >> On Thu, Mar 14, 2019 at 7:13 AM Neil Madden <neil.mad...@forgerock.com> >> wrote: >> It’s not clear to me how this works or what problem it is solving.. If a >> refresh token is bound to the certificate, does that mean that a call to the >> introspection endpoint with that refresh token should also return a “cnf” >> claim as per >> https://tools.ietf.org/html/draft-ietf-oauth-mtls-13#section-3.2 ? >> >> It also seems problematic to implement this for refresh tokens. As mentioned >> by Filip, rotation of the certificate is out of the question. Currently in >> our implementation a client could present a new certificate when using the >> refresh token and this would result in the newly issued access token being >> bound to the new certificate. If the refresh token is bound to the original >> certificate, then this would be ruled out (the new certificate would be >> rejected) and certificate rotation becomes impossible in all cases. Am I >> missing something? >> >> — Neil >> >> > On 14 Mar 2019, at 12:28, Brian Campbell <bcampb...@pingidentity.com> >> > 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 <neil.mad...@forgerock.com> >> > 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 <panva...@gmail.com> 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 <panva....@gmail.com> 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=40pingidentity....@dmarc.ietf.org> 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=40auth0....@dmarc.ietf.org> 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 >> >> 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 >> >> _______________________________________________ >> >> 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. >> > > 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
