[OAUTH-WG] Re: Secdir last call review of draft-ietf-oauth-browser-based-apps-22

[Aaron Parecki]

Thanks for your review, Watson. We've published a new version of the draft
addressing your and others' feedback.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html

You can also see the more detailed commits and discussion on GitHub:
https://github.com/oauth-wg/oauth-browser-based-apps/issues/70

Responses inline:

Reviewer: Watson Ladd
> Review result: Has Issues


I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by theIESG. These
> comments
> were written primarily for the benefit of thesecurity area directors.
> Document
> editors and WG chairs should treat these comments just like any other last
> call
> comments.


The summary of the review is Has Issues. I wish it didn't have to be: it's a
> thoroughly written, and a model in many respects for carefully analyzing
> the
> security properties of a number of choices. However, I think that given the
> importance of the document it needs to be more accessible to people who
> are not
> experts, and there's a number of analysis choices I don't understand. I'm
> also
> not sure the title is quite right: it sounds like a big replacement, rather
> than a detailed guide to the security of OAuth in browser apps.


I hope that the abstract and first sentence of the introduction accurately
represent the scope of the document, and that it doesn't come across as a
big replacement for OAuth. The title is meant to mirror the older draft
"OAuth 2.0 for Native Applications".

As a reader I did not understand much of the scenario being discussed until
> the
> very end: the resource server is not on the same domain as the application
> is
> being retrieved from, and the oauth server might be a third domain from
> both. I
> had to wait until Section 7 to figure that out. For those of us unused to
> Oauth
> it might be worth spelling that out: typically my interactions with it are
> SSO
> where the resource and application are the same. Certain key acronyms like
> PCKE
> are not defined when first introduced, and used for quite some time, which
> also
> makes it difficult to understand some sections until getting to them. I
> think
> these can be straightened out without too much text.


We've updated all the acronyms to be referenced on first use and added them
to the terminology section.

There is a new paragraph in the introduction that should make the
cross-domain aspects of common OAuth deployments more clear.

I do have some concerns about the analysis. The attacks seem to be centered
> around Javascript injection. This gives the attacker incredible power.
> However,
> the capabilities of the attacker are then centered on 5 specific attacks.
> It is
> not clear to me why this is justified. Similarly, the presence of the
> relaying
> server does simplify the story around Oauth token management, but
> introduces a
> deputy that can be confused. While there are a bunch of security
> considerations
> added in 6.1.3, this one isn't there. There's a lot about cookies, but
> little
> about session fixation or other attacks that confuse the link between
> clients.
> This also affects the token mediating backend.


 We updated section 5 to clarify why these attacks in particular are
relevant to the document, essentially because it focuses on what is unique
about javascript injection in the context of OAuth flows. We also added a
mention of the relevance to session fixation.

Overall I think this is in pretty good shape.


Thank you for the feedback.

---
Aaron Parecki
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Artart last call review of draft-ietf-oauth-browser-based-apps-22

[Aaron Parecki]

Thanks for your review, Marc, we've published a new version addressing your
feedback.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html

You can also see the more detailed commits and discussion on GitHub:
https://github.com/oauth-wg/oauth-browser-based-apps/issues/72

Responses inline:

On Mon, Feb 3, 2025 at 8:00 AM Marc Blanchet via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Marc Blanchet
> Review result: Ready with Nits
>
> I've reviewed this document as an assigned ART reviewer. I'm not an expert
> in
> Oauth. I haven't seen any issue from the perspective of ART or i18n. I
> found
> this document comprehensive and detailed and useful for application
> architects
> and developers.
>
> I have the following comments.
>
> Substantive:
> - On my reading, it seems that the only foundation threat here is the
> ability
> for the attacker to inject malicious code. Okay. If this is the case, I
> think
> this should be pointed out clearly at the beginning of the document.


That is correct, this is now better explained in the intro to the threats
in Section 5.


> - On my
> reading, I see that this document discusses two topics: security issues and
> best practices for browser based apps that are using any kind of
> authentication
> mechanism and specific ones when using Oauth. I'm wondering if a) we
> already
> have any document that already describes the generic issues, in which
> case, we
> should refer or update;  b) if we don't have, given that a lot of this
> document
> is valuable for issues not specifically related to Oauth, that we could
> split
> the document in two: one for non-Oauth issues and then having the second
> one
> strictly on Oauth specific issues. That way, the first one can be
> referenced by
> non-Oauth work. Having said that, that suggestion may have been discussed
> already in the working group or may not make sense for reasons I don't
> know.
> Please discard if it does not make sense.
>

This has been clarified in Section 5, the intent is to discuss things
specifically in relation to OAuth, not general browser security
recommendations.


>
> Editorial:
> - Section 4. expand PKCE on first use and add reference. That expansion is
> done
> later in document in section 6.3.2.1, so then remove that expansion there.
> -
> DPoP similarly
>

References have been added throughout.
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Rtgdir last call review of draft-ietf-oauth-browser-based-apps-22

[Aaron Parecki]

Thanks for your review, Matthew, we appreciate the time!


On Tue, Feb 4, 2025 at 5:13 AM Matthew Bocci via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Matthew Bocci
> Review result: Ready
>
> Hi,
>
> I am the designated Routing Area Directorate reviewer for this draft. The
> draft
> provides guidelines and best practices for implementing OAuth 2.0 in
> browser
> based applications. I reviewed the draft from the perspective of whether it
> would affect or be affected by the routing protocols, which I believe are
> not
> affected or have any affect on the draft.
>
> The draft is well written and easy to understand from the perspective of
> someone more familiar with other areas of the internet architecture.
> Thanks!
>
> I believe it is ready to progress.
>
>
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-17.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-17.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

   Title:   Selective Disclosure for JWTs (SD-JWT)
   Authors: Daniel Fett
Kristina Yasuda
Brian Campbell
   Name:draft-ietf-oauth-selective-disclosure-jwt-17.txt
   Pages:   96
   Dates:   2025-03-01

Abstract:

   This specification defines a mechanism for the selective disclosure
   of individual elements of a JSON-encoded data structure used as the
   payload of a JSON Web Signature (JWS).  The primary use case is the
   selective disclosure of JSON Web Token (JWT) claims.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-17.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-17

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Status List Feature Request

[Vladimir Dzhuvinov / Connect2id]

Thanks, this looks like a good and reasonable conclusion.

Allowing for extensions is okay. Adding X.509 support, and this isn't 
exactly a backwards compatibility or bridging kind of feature, as an 
OAuth WG document would not be appropriate.


Vladimir Dzhuvinov

On 27/02/2025 17:41, Christian Bormann wrote:


Hi all,

We had a session on this topic in the OAuth Security Workshop

(with Brian, Filip and Mike present) and asked for feedback.

Everyone that voiced their opinion was against this extension in the 
scope of the current


draft and the OAuth Working Group, but there was the remark to make 
sure that this draft


allows for this feature if people wish to create this extension (as 
Filip also stated previously


here on the mailing list).

Slides we used with short notes on the Feedback we got:

https://docs.google.com/presentation/d/1NGYsJgwGOBDRbop9OLAbj6_0Aoo3FhAyabu-aE4ghyk/edit#slide=id.g33a15d709f8_0_331

Best Regards,

Christian

*From: *Michael Jones 
*Date: *Wednesday, 26. February 2025 at 18:05
*To: *Brian Campbell , Filip Skokan 


*Cc: *Christian Bormann , oauth 
*Subject: *RE: [OAUTH-WG] Re: Status List Feature Request

X.509 already has its own revocation infrastructure (in fact, more 
than one kind!).  We needn’t complicate this spec to add another one 
for X.509.


-- Mike

*From:*Brian Campbell 
*Sent:* Wednesday, February 26, 2025 4:46 PM
*To:* Filip Skokan 
*Cc:* Christian Bormann ; oauth 


*Subject:* [OAUTH-WG] Re: Status List Feature Request

I concur with Filip's perspective.

On Wed, Feb 26, 2025, 4:21 PM Filip Skokan > wrote:


I believe it is inappropriate and wildly out of scope for an oauth
document to define X.509 extensions, which IIUC is needed in order
to define the Status Claim for X.509? The important thing to make
sure is that the document does not preclude a future X.509
extension being drafted (wherever its appropriate place may be)
that makes use of the status list, and that already appears to be
the case.

S pozdravem,
*Filip Skokan*

On Fri, 7 Feb 2025 at 14:57, Christian Bormann
mailto:40gmx...@dmarc.ietf.org>> wrote:

Hi all,

While going through the feedback and issues on github, there
was one bigger discussion point that we would like to bring to
the mailing list. Steffen Schwalm asked for support for X.509
Certificate revocation with the Status List - in that case the
Status List describing the status of an X.509 Certificate
(relevant issue
https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243
).
That would mean defining an extension to X.509 to embed the
relevant information for a Status List (URI and index) and
creating validation rules etc.

While we understand the general motivation as is discussed in
more detail in the issue, it would be somewhat of a change of
scope for the Status List draft. We felt it might be out of
scope of the OAuth Working Group and rather in scope of other
working groups like lamps? Any comments/opinions would be
appreciated!

Best Regards,

Christian Bormann

___
OAuth mailing list -- oauth@ietf.org 
To unsubscribe send an email to oauth-le...@ietf.org


___
OAuth mailing list -- oauth@ietf.org 
To unsubscribe send an email to oauth-le...@ietf.org



*/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
To unsubscribe send an email tooauth-le...@ietf.org


smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: I-D Action: draft-ietf-oauth-selective-disclosure-jwt-17.txt

[Denis]

Below is my feedback about draft-ietf-oauth-selective-disclosure-jwt-17, 
grouped into four categories (A to D).


Six issues have been opened about 3 weeks ago, but no reply has been 
posted on them on github. There are still open.


A – *KB-JWT replay detection*

a) About KB-JWT replay detection in section 4.3 #547
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/547

The current description is incorrect and may lead to insecure 
implementations


b) KB-JWT replay detection is not correctly described: sections 4.3 and 
7.3 should be revised.

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/548

The current description is incorrect and incomplete and may lead to 
insecure implementations


*B – Checking SD-JWT suspension or revocation is missing in section 7.1 
(Verification of the SD-JWT) *

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/546

*C - Re-introduction of a reference to ISO 29100 and further 
implementation and architectural consequences*


1. In draft -14, ISO 29100 was mentioned in section 10 but has been 
removed in draft -15 #550

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/550

- In Section 1.2, the term End-User should be defined as it is a 
fundamental entity in ISO 29100 #557

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/557

- In Section 1.2, make the difference between an application and an 
End-User #558

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/558

- Figure 1 should illustrate the presence of an End-User and be closer 
to the data structures that are exchanged #559

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/559

- The definition of an Issuer would need to be polished #560
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/560

- Proposed rewording in Section 1.1 about SD-JWT+KB #561
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/561

*D. Minor change proposals*

- Editorial change. In section 10.3, both confidentiality and integrity 
during Transport are essential #551

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/551

- Add the wording "one-time use digital credentials" in the context of 
"batches of credentials" #562

https://github.com/oauth-wg/oauth-selective-disclosure-jwt/issues/562

Denis







Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-17.txt is now
available. It is a work item of the Web Authorization Protocol (OAUTH) WG of
the IETF.

Title:   Selective Disclosure for JWTs (SD-JWT)
Authors: Daniel Fett
 Kristina Yasuda
 Brian Campbell
Name:draft-ietf-oauth-selective-disclosure-jwt-17.txt
Pages:   96
Dates:   2025-03-01

Abstract:

This specification defines a mechanism for the selective disclosure
of individual elements of a JSON-encoded data structure used as the
payload of a JSON Web Signature (JWS).  The primary use case is the
selective disclosure of JSON Web Token (JWT) claims.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-17.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-17

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OAuth mailing list --oauth@ietf.org
To unsubscribe send an email tooauth-le...@ietf.org


___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Status List Feature Request

[Rohan Mahy]

I agree with Hannes that X.509 extensions need to be done in LAMPS, because
that is where the expertise is.
thanks,
-rohan

On Wed, Feb 26, 2025, 08:48 Hannes Tschofenig 
wrote:

> (chair hat off)
>
> Hi Filip, Hi all,
>
> this sounds like feature creep to me. I brought this work on status
> lists to the attention of the IETF LAMPS group, and there was zero
> interest from the PKI community in this type of solution. The PKIX
> community already has a wide range of established solutions for
> revocation and status checking.
>
> Steffen could propose such an extension within LAMPS, if he cares about
> it. LAMPS is the place to define extensions to X.509 certificates.
>
> Ciao
> Hannes
>
>
> Am 26.02.2025 um 17:18 schrieb Filip Skokan:
> > I believe it is inappropriate and wildly out of scope for an oauth
> > document to define X.509 extensions, which IIUC is needed in order to
> > define the Status Claim for X.509? The important thing to make sure is
> > that the document does not preclude a future X.509 extension being
> > drafted (wherever its appropriate place may be) that makes use of the
> > status list, and that already appears to be the case.
> >
> > S pozdravem,
> > *Filip Skokan*
> >
> >
> > On Fri, 7 Feb 2025 at 14:57, Christian Bormann
> >  wrote:
> >
> > Hi all,
> >
> > While going through the feedback and issues on github, there was
> > one bigger discussion point that we would like to bring to the
> > mailing list. Steffen Schwalm asked for support for X.509
> > Certificate revocation with the Status List - in that case the
> > Status List describing the status of an X.509 Certificate
> > (relevant issue
> > https://github.com/oauth-wg/draft-ietf-oauth-status-list/issues/243
> ).
> > That would mean defining an extension to X.509 to embed the
> > relevant information for a Status List (URI and index) and
> > creating validation rules etc.
> >
> > While we understand the general motivation as is discussed in more
> > detail in the issue, it would be somewhat of a change of scope for
> > the Status List draft. We felt it might be out of scope of the
> > OAuth Working Group and rather in scope of other working groups
> > like lamps? Any comments/opinions would be appreciated!
> >
> > Best Regards,
> >
> > Christian Bormann
> >
> > ___
> > OAuth mailing list -- oauth@ietf.org
> > To unsubscribe send an email to oauth-le...@ietf.org
> >
> >
> > ___
> > OAuth mailing list -- oauth@ietf.org
> > To unsubscribe send an email to oauth-le...@ietf.org
>
> ___
> OAuth mailing list -- oauth@ietf.org
> To unsubscribe send an email to oauth-le...@ietf.org
>
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] IETF122 - Draft OAuth WG Agenda for Bangkok

[Rifaat Shekh-Yusef]

All,

The following link has our draft agenda for the two OAuth WG sessions in
the coming IETF meeting in Bangkok.
https://datatracker.ietf.org/doc/agenda-122-oauth/

Take a look and let us know if you have any questions or comments.

Regards,
 Rifaat & Hannes
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

[OAUTH-WG] Re: Httpdir last call review of draft-ietf-oauth-browser-based-apps-22

[Aaron Parecki]

Thanks for your thorough review Martin! We've published version 23 of the
draft addressing your feedback.

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html

Notes on your feedback are inline. You can also see the specific feedback
and commits by following this GitHub issue:

https://github.com/oauth-wg/oauth-browser-based-apps/issues/73


On Thu, Jan 30, 2025 at 6:22 AM Martin Thomson via Datatracker <
nore...@ietf.org> wrote:

> Reviewer: Martin Thomson
> Review result: Ready with Nits
>
> Hey,
>
> I've been tasked with looking at this document for the HTTP directorate,
> for
> which I would just look at Section 6.1.3.2 and say "yup, that's how you do
> cookies right; even if the prohibition on domain seems unnecessary, it's
> not a
> useful feature anyway".  But I wanted to read the document to see if you
> had
> other HTTP uses in mind.  And it was an interesting perspective on how
> browsers
> work.
>
> For the most part, this a pretty good document and I see no problems with
> it
> proceeding.  This review is provided in the hopes that it can be made
> slightly
> better.
>

Thank you! I hope it has been made slightly better from this.


>
> The underlying premise here is that your browser app will run malicious
> code.
> Which is pretty challenging, because you have given away everything at that
> point.  Game over, man.
>
> Of course, there's a nice little save hidden in Section 5.1.4: proxying
> requests via an active browser is out of scope.  At first blush this seems
> like
> a cop-out, but I really appreciate the thoroughness of this documentation
> of
> how to limit the harm.  There's a bit more in Section 5.2.3 about how this
> attack might not always confer all the powers that an attacker might want.
>
> From my perspective, it might be good to be clearer up front about what
> can and
> cannot be achieved here.  Put differently, a little more clarity about the
> threat model up front might help.  That is something like an applicability
> statement might help:
>

We've added a variation of this paragraph:
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html#section-5


>
> > [...] malicious JavaScript code has the same privileges as the legitimate
> application code. All JS applications are exposed to this risk in some
> degree.
> Applications might also obtain OAuth tokens that confers authorization
> that are
> necessary to their functioning.  In combination, this effectively gives
> compromised code the ability to use that authorization for malicious ends
> > >
> Though the risk of attacker abuse of authorization is unavoidable, there
> are
> ways to limit the extent to which a compromised application can abuse that
> authorization. For instance, this access might be limited to times when the
> application is in active use by ensuring that tokens cannot be obtained by
> an
> attacker, by limiting the type of tokens that might be obtained, or by
> binding
> the tokens to the application.
>
> Beyond that, I have only quibbles.  And a few niggles.
>
> # Quibbles
>
> I found the use of "client" to be a little confused at times.  It wasn't
> always
> crisp about whether this was a person or a browser application.  Take
> Section
> 6.3.3.2, which says: "the authorization server SHOULD NOT process
> authorization
> requests automatically without user consent or interaction, except when the
> identity of the client can be assured".  That's a person.  In the previous
> section, "end-user" is used to refer to a person and "client" is the code
> that
> runs the browser.  Presumably in this case "client" refers to the identity
> of
> the entity that is asking for authorization.
>

"Client" is an OAuth term that refers to the application, not the end user.
"Identity of the client" is a phrase from RFC6749. We expanded this to
"client application" to hopefully not confuse this with the end user here.


>
> This in Section 6.3.4.2.1 makes no sense to me: "A practical implementation
> pattern can use a Web Worker [WebWorker] to isolate the refresh token, and
> provide the application with the access token making requests to resource
> servers."  I can't work out how this would help at all.
>

We added a sentence to clarify what this is meant to protect, which is only
preventing the attacker from using the application's refresh token:
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html#section-6.3.4.2.1


>
> None of this section makes sense to me.  The last paragraph says something
> about a "perfect storage mechanism", which implies that some set of
> criteria
> have been established whereby we could deem some storage "perfect".  This
> extends to Section 8, which also references some platonic ideal.
>

We've updated all mentions of "perfect storage" to phrases like "...even a
token storage mechanism that completely isolates the tokens from the
attacker..." Hopefully this is clearer.


>
> The advice about DPoP in Section 6.3.4.2.2 i

[OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-23.txt

[internet-drafts]

Internet-Draft draft-ietf-oauth-browser-based-apps-23.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth 2.0 for Browser-Based Applications
   Authors: Aaron Parecki
David Waite
Philippe De Ryck
   Name:draft-ietf-oauth-browser-based-apps-23.txt
   Pages:   66
   Dates:   2025-03-01

Abstract:

   This specification details the threats, attack consequences, security
   considerations and best practices that must be taken into account
   when developing browser-based applications that use OAuth 2.0.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-browser-based-apps.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-23.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-23

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org