[OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

[Tschofenig, Hannes]

Hi Daniel, Torsten, Andrey,

as part of the shepherd write-up, all authors of 

must confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 have been filed.

Here is the draft:
draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current 
Practice

Please, reply to this email, on the mailing list, and indicate if you are
aware of any IPRs associated with this document.

Ciao
Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Shepherd Review of draft-ietf-oauth-security-topics-23

[Tschofenig, Hannes]

Hi all,

here are some comments as part of my shepherd review of the OAuth Security BCP.

First, I want to send a big "Thanks" to everyone in the group for the work on 
this document and to the authors in particular. It has taken us a while to come 
up with such an impressive list of security recommendations for OAuth 2.0.

At this point in time my review comments can only be minor given the amount of 
feedback this documents has already received.

Here are a few remarks.

I believe we should indicate that the specification updates other OAuth RFCs. 
The obvious documents it updates are RFC 6749, RFC 6750 and RFC 6819.
You can set these "updates" in the template you are using.

In Section 1 you say:
"
It does not supplant the security advice given in
   [RFC6749], [RFC6750], and [RFC6819], but complements those documents.
"

In the subsequent paragraph you state that you "depreciate some modes of 
operation".

I believe you are need to be clear about what you are doing in relationship to 
these prior documents. It might also be useful to say something about OAuth 2.1.


Expand abbreviations on first use. Example: "AS" and "PKCE" in Section 2.1. The 
AS abbreviation is only expanded later in Section 3. Decide whether you want to 
use abbreviations or not. You mix them throughout the document without no 
reasons.
Listing the abbreviations in Section 1.2 may also be useful. There are not that 
many abbreviations anyway.


I have wording suggestions for this paragraph:

FROM:
"

   Authorization servers SHOULD use client authentication if possible.

   It is RECOMMENDED to use asymmetric (public-key based) methods for
   client authentication such as mTLS [RFC8705] or using signed JWTs
   ("Private Key JWT") in accordance with [RFC7521] and [RFC7523] (in
   [OpenID.Core] defined as the client authentication method
   private_key_jwt).  When such methods for client authentication are
   used, authorization servers do not need to store sensitive symmetric
   keys, making these methods more robust against a number of attacks.

"

TO:
"

   Authorization servers SHOULD enforce client authentication, if possible.

   It is RECOMMENDED to use asymmetric cryptography for
   client authentication, such as mTLS [RFC8705] or using signed JWTs
   ("Private Key JWT"), in accordance with [RFC7521] and [RFC7523] (in
   [OpenID.Core] defined as the client authentication method
   private_key_jwt).  When asymmetric cryptography for client authentication is
   used, authorization servers do not need to store sensitive symmetric
   keys, making client authentication more robust against leakage of keys.

"

(Note: For the reader it is always better if they are told what attacks
are prevented rather than saying "a number of attacks". You don't want the 
reader
to guess what you mean.)

Section 2 is a summary of what follows in Section 4. Maybe you can make this 
explicit
either in the title of Section 2 or in the first paragraph of Section 2.



Section 3.

You write:

"
   These attackers conform to the attacker model that was used in formal
   analysis efforts for OAuth [arXiv.1601.01229].  This is a minimal
   attacker model.  Implementers MUST take into account all possible
   types of attackers in the environment in which their OAuth
   implementations are expected to run.
"

When you say "these attackers" please clarify which attackers you are talking 
about.
Prior to this paragraph you have just spoken about various forms of network 
attackers.
Just before that you talked about network and web attackers.

Then, you introduce more attackers and you keep talking about "this attacker 
model" and
"these attackers". Make it easier for the reader by referring explictly which 
attackers
you are talking about in a specific paragraph.

Then, you conclude the section with a hint that there is an even stronger 
attacker model.
As a reader I might want to know what this stronger attacker model looks like 
and why you
do not consider it in this document.


Section 4.1.1:

You write:
"
Note: Vulnerabilities of this kind can also exist if the
   authorization server handles wildcards properly.
"

I believe you are saying that the vulnerabilities caused by incorrect redirect 
URI validation parsing when you refer to "this kind".
I would also remove the "note"


Section 4.1.3:

You write:

"
   *  Servers on which callbacks are hosted MUST NOT expose open
  redirectors (see Section 4.11).
"

Are you talking about authorization servers (which is what was referenced in 
the paragraph before)?


Section 4.10.1: Sender-constrained Access Tokens

The text gives the reader the impression that the token binding would be an 
option for developers to use.
I don't think that this is the case. I am particularly referring to this 
sentence:

"

   *  *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of-
  Possession at the Application Layer) outlines an application-level
  sender-constraining for access and refresh tokens that c

[OAUTH-WG] Implementation Status of the "OAuth 2.0 Security BCP"

[Tschofenig, Hannes]

Hi all,

as part of the shepherd write-up for the "OAuth 2.0 Security BCP" document,
we are looking for information about implementations of this draft.

Please let us know if there are implementations that follow the recommendations 
in the draft.
I know that the document is a bit special due to the broad scope. You might 
nevertheless be able to give us valuable information for the shepherd write-up.

Ciao
Hannes

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

[Tschofenig, Hannes]

In my earlier email I forgot to include John.

John, I also need your confirmation!

Von: OAuth  Im Auftrag von Tschofenig, Hannes
Gesendet: Mittwoch, 4. Oktober 2023 15:41
An: oauth@ietf.org
Betreff: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

Hi Daniel, Torsten, Andrey,

as part of the shepherd write-up, all authors of 

must confirm that any and all appropriate IPR disclosures required for full
conformance with the provisions of BCP 78 and BCP 79 have been filed.

Here is the draft:
draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current 
Practice

Please, reply to this email, on the mailing list, and indicate if you are
aware of any IPRs associated with this document.

Ciao
Hannes
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

[Daniel Fett]

I am not aware of any IPR associated with this document.

-Daniel

Am 04.10.23 um 17:10 schrieb Tschofenig, Hannes:


In my earlier email I forgot to include John.

John, I also need your confirmation!

*Von:*OAuth  *Im Auftrag von *Tschofenig, Hannes
*Gesendet:* Mittwoch, 4. Oktober 2023 15:41
*An:* oauth@ietf.org
*Betreff:* [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current 
Practice


Hi Daniel, Torsten, Andrey,

as part of the shepherd write-up, all authors of 



must confirm that any and all appropriate IPR disclosures required for 
full


conformance with the provisions of BCP 78 and BCP 79 have been filed.

Here is the draft:

draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current 
Practice 



Please, reply to this email, on the mailing list, and indicate if you are

aware of any IPRs associated with this document.

Ciao

Hannes


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--
Please use my new email address:m...@danielfett.de
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current Practice

[torsten=40lodderstedt . net]

I am not aware of any IPR associated with this document.
Am 4. Okt. 2023, 17:16 +0200 schrieb Daniel Fett 
:
> I am not aware of any IPR associated with this document.
> -Daniel
> Am 04.10.23 um 17:10 schrieb Tschofenig, Hannes:
> > In my earlier email I forgot to include John.
> >
> > John, I also need your confirmation!
> >
> > Von: OAuth  Im Auftrag von Tschofenig, Hannes
> > Gesendet: Mittwoch, 4. Oktober 2023 15:41
> > An: oauth@ietf.org
> > Betreff: [OAUTH-WG] IPR Disclosure - OAuth 2.0 Security Best Current 
> > Practice
> >
> > Hi Daniel, Torsten, Andrey,
> >
> > as part of the shepherd write-up, all authors of 
> > 
> > must confirm that any and all appropriate IPR disclosures required for full
> > conformance with the provisions of BCP 78 and BCP 79 have been filed.
> >
> > Here is the draft:
> > draft-ietf-oauth-security-topics-23 - OAuth 2.0 Security Best Current 
> > Practice
> >
> > Please, reply to this email, on the mailing list, and indicate if you are
> > aware of any IPRs associated with this document.
> >
> > Ciao
> > Hannes
> >
> > ___
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> --
> Please use my new email address: m...@danielfett.de
> ___
> 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

Re: [OAUTH-WG] Implementation Status of the "OAuth 2.0 Security BCP"

[torsten=40lodderstedt . net]

Hi,

the yes open banking ecosystem was implemented based on the Security BCP.

best regards,
Torsten.
Am 4. Okt. 2023, 16:46 +0200 schrieb Tschofenig, Hannes 
:
> Hi all,
>
> as part of the shepherd write-up for the "OAuth 2.0 Security BCP" document,
> we are looking for information about implementations of this draft.
>
> Please let us know if there are implementations that follow the 
> recommendations in the draft.
> I know that the document is a bit special due to the broad scope. You might 
> nevertheless be able to give us valuable information for the shepherd 
> write-up.
>
> Ciao
> Hannes
>
> ___
> 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