Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients

[Karsten Meyer zu Selhausen <[e-mail]>]

Hi Jaimandeep,

I disagree with both of your points. See my comments inline.

Best regards,
Karsten

On 12.08.2022 05:40, Jaimandeep Singh wrote:
> Hi Mikheil,
> 1. Well explained by Brain. I will just add my perspective.
>
>     >From the practical perspective, if the confidential client got a
>     refresh
>     token for the offline access and sufficient time (e.g., for a
>     month), this
>     would be quite impractical and not very user-friendly to ask a lot
>     of users
>     to give consents again when the confidential client wants to
>     upgrade its
>     certificate. But seems like software vendors did not interpret the
>     RFC that
>     way.
>
> For confidential clients, authorization code flow is recommended. It 
> is a two step process. In the first step you get the authorization 
> code when the user provides his/her consent. In the second step you 
> use this authorization code along with client credentials to obtain 
> access tokens and refresh tokens. If the refresh token expires either 
> due to expiry of its lifetime or certificate, it only needs to follow 
> step two. So, the question of asking for consent again does not arise 
> unless the authorization code itself has limited lifespan.

IMHO authorization codes should always be implemented as one-time-use 
tokens. Even when there is a grace period allowing a client to redeem a 
code a second time (e.g., in case of network failure) this period should 
be very short - much shorter than the validity of refresh tokens in 
practice.

If the refresh token is expired, the client should start a new 
authorization flow and ask the user for consent again unless the AS 
provides a way for users to grant access for clients "permanently".

>
> 2.
>
>     While RFC 8705 indeed requires binding refresh token to the
>     certificate in
>     case of the public clients in Section 4 and Section 7.1
>
> The RFC 8705 talks about public clients and refresh tokens in the same 
> breath and seems to have legitimized the use of refresh tokens for 
> public clients. However, if we look at the original OAuth 2.0 
> specifications RFC 6749, Section 4.2, talks about implicit grant 
> optimized for public clients. It does not support issuing refresh 
> tokens by AS in the first place. I think there is a need to 
> deliberate on this issue in the next update / errata  for RFC 8705.

RFC 6749 is much older than RFC 8705. Both drafts "OAuth 2.0 Security 
Best Current Practice" (hopefully soon to be finished) and OAuth 2.1 
deprecate issuing access tokens from the authorization endpoint (which 
is more or less the implicit grant). Today's best practice is to use the 
authorization code grant for both confidential and public clients. 
Therefore, I do not think there is a need for an updated RFC replacing 8705.


>
> Regards and Best Wishes
> Jaimandeep Singh
>
>
> On Thu, Aug 11, 2022 at 11:46 PM <[e-mail]> wrote:
>
>     Hi Brian,
>
>     Thanks for the prompt response. We will work with our vendors to
>     get this done according to the RFC.
>
>     Best Regards,
>     Mikheil Kapanadze
>
>     From: Brian Campbell <[e-mail]>
>     Sent: ხუთშაბათი, 11 აგვისტო, 2022 21:04
>     To: [e-mail]
>     Cc: [e-mail]
>     Subject: Re: [OAUTH-WG] Certificate-bound refresh tokens and
>     certificate expiration handling in case of the confidential clients
>
>     Hi Mikheil,
>
>     Your assumption is the correct reading of the RFC. Or the intent
>     of the RFC anyway. For confidential clients, refresh tokens are
>     bound to the client id (not the certificate thumbprint or anything
>     else for that matter).
>
>     RFCs can't be changed after publication so adding more
>     clarification isn't really possible.
>
>
>
>     On Thu, Aug 11, 2022 at 9:11 AM <mailto:[e-mail]> wrote:
>     Hi,
>
>     I have noticed is that some OAuth2 AS implementations use certificate
>     thumbprints to bind not only access tokens but also refresh tokens
>     to client
>     certificates. This happens for both public and confidential
>     clients. As a
>     result, when the certificate is replaced (e.g., it is about to
>     expire soon),
>     both access and refresh tokens are drawn unusable.
>
>     While RFC 8705 indeed requires binding refresh token to the
>     certificate in
>     case of the public clients in Section 4 and Section 7.1, the
>     wording is not
>     that explicit for the confidential clients. More specifically,
>     Section 7.1
>     of the RFC 8705 is worded in a way which does not explicitly deny
>     keeping
>     refresh tokens alive after certificate change: it talks about
>     binding to
>     client ID, thus binding "indirectly" to the certificate. Also,
>     Section 6.3
>     requires access tokens to be invalidated after certificate change and
>     mentions refresh tokens as typical tools for renewing them.
>
>     >From the practical perspective, if the confidential client got a
>     refresh
>     token for the offline access and sufficient time (e.g., for a
>     month), this
>     would be quite impractical and not very user-friendly to ask a lot
>     of users
>     to give consents again when the confidential client wants to
>     upgrade its
>     certificate. But seems like software vendors did not interpret the
>     RFC that
>     way.
>
>     So, the questions:
>     1) Is my assumption correct and it will not be a violation of the
>     RFC if
>     refresh tokens issued to the confidential clients survive
>     certificate change
>     (e.g., by binding them to Client ID, not the certificate thumbprint)?
>     2) If the answer on the 1st question is “yes”, would it be better
>     to provide
>     more clarification in the section 7.1 to avoid misinterpretations
>     in the
>     future?
>
>     Best Regards,
>     Mikheil Kapanadze
>
>
>
>     _______________________________________________
>     OAuth mailing list
>     mailto:[e-mail]
>     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
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> --
> Regards and Best Wishes
> Jaimandeep Singh
> LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone:	+49 (0)234 / 54456499
Web:	https://hackmanit.de  | IT Security Consulting, Penetration Testing, Security Training

Is your OAuth or OpenID Connect application vulnerable to mix-up attacks? Find out more on our blog:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks

Hackmanit GmbH
Universitätsstraße 60 (Exzenterhaus)
44789 Bochum

Registergericht: Amtsgericht Bochum, HRB 14896
Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr. Juraj Somorovsky, Dr. Christian Mainka, Prof. Dr. Marcus Niemietz