Hi George, client impersonation is covered extensively in RFC6749 already, with further recommendations in RFC6819. The basics of this attack have not changed since public clients where introduced, but, as you mention, on mobile operating systems we see new mechanics for authenticating clients (or the lack thereof).
I worked together with Joseph Heenan and Fabian Hauck to develop new best practices in this area [1]. I feel that the complexity of this whole topic would be much better dealt with in an update to BCP 212 (RFC 8252). Since the basics have been covered elsewhere, I do not see an immediate need to update the security BCP and quite frankly, I fear that this would set us back at least another year or so. -Daniel [1] https://danielfett.de/2020/11/27/improving-app2app/ Am 07.04.21 um 22:06 schrieb George Fletcher: > While this is mostly covered in section 8.6 of RFC 8252 for native > apps, I wonder if we shouldn't mention "Client Impersonation" in this > doc as well in that any public client can be easily impersonated. > Mobile OS's are providing additional mechanisms for "authenticating" > the client but it's unclear whether those will be made available in > desktop environments where native apps also exist. At this stage > Universal Links (iOS) and App Links (Android) should be best practice > for any mobile native app. Best practice for desktop apps is less clear. > > Impersonating a public client is very easy especially if the only > mechanism available for the callback is a custom scheme URL. > > Thoughts? > > On 4/6/21 9:15 AM, Daniel Fett wrote: >> Hi all, >> >> this version most importantly updates the recommendations for Mix-Up >> mitigation, building upon >> https://tools.ietf.org/html/draft-ietf-oauth-iss-auth-resp-00. The >> description of Mix-Up attacks has also been improved. >> >> Smaller changes: >> >> * Make the use of metadata RECOMMENDED for both servers and clients >> * Make announcing PKCE support in metadata the RECOMMENDED way >> (before: either metadata or deployment-specific way) >> * AS also MUST NOT expose open redirectors. >> * Mention that attackers can collaborate. >> * Make HTTPS mandatory for most redirect URIs. >> >> I'll present more details in the interim meeting next monday. >> >> As always, your feedback is appreciated. We hope that we can proceed >> to a WGLC for this document soon. >> >> -Daniel >> >> Am 06.04.21 um 15:06 schrieb internet-dra...@ietf.org: >>> 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 : OAuth 2.0 Security Best Current Practice >>> Authors : Torsten Lodderstedt >>> John Bradley >>> Andrey Labunets >>> Daniel Fett >>> Filename : draft-ietf-oauth-security-topics-17.txt >>> Pages : 52 >>> Date : 2021-04-06 >>> >>> Abstract: >>> This document describes best current security practice for OAuth 2.0. >>> It updates and extends the OAuth 2.0 Security Threat Model to >>> incorporate practical experiences gathered since OAuth 2.0 was >>> published and covers new threats relevant due to the broader >>> application of OAuth 2.0. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >>> >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-17.html >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-17 >>> >>> >>> 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 list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> >> -- >> https://danielfett.de >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > -- https://danielfett.de
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
