Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-security-topics-17.txt

From: [email-masked]
Date: Tue, 06 Apr 2021 06:06:01 -0700

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/

---

From: Daniel Fett <[email-masked]>
Date: Tue, 6 Apr 2021 15:15:30 +0200

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 [email-masked]:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

-- 
https://danielfett.de

---

From: George Fletcher <[email-masked]>
Date: Wed, 7 Apr 2021 16:06:56 -0400

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:
> As always, your feedback is appreciated. We hope that we can proceed 
> to a WGLC for this document soon.
>
> -Daniel
>

---

From: Daniel Fett <[email-masked]>
Date: Thu, 8 Apr 2021 17:53:30 +0200

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.
>

-- 
https://danielfett.de