Your point about refresh tokens having a different threat model to access tokens is taken, however, I think I'd stop short of saying a private key is always at the same risk.
I will be at OSW next week and look forward to your presentation. Hopefully it'll help me better understand the threat model and goals and constraints and etc. you are working with. As far as the document is concerned, there are folks that are interested in the cert-binding of refresh tokens for public clients. So I don't it should be removed. The text in -13 has a SHOULD for it so your case of not cert-binding RTs is still within the lines of the spec. But perhaps that SHOULD can be loosened and/or qualified somewhat so as to better accommodate that case. I was trying to avoid it, but introducing a client metadata flag to toggle the RT binding behavior is also a potential option. On Thu, Mar 14, 2019 at 1:49 PM Neil Madden <neil.mad...@forgerock.com> wrote: > 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.* > > -- _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
