Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback
That's an interesting use-case for relay mode and might be a reason to
cover it.
However, we believe the current code for the relay mode in
draft-sakimura-oauth-wmrm-01 does not work. The same-origin policy
should prevent this line from working:
messageTargetWindowReference =
e.source.document.getElementById(web_message_target);
"e.source" references the main window (e.g., client.example.com). This
means the (un)authenticated window (e.g., as.example.com) tries to
access "document.getElementById" for the cross-origin main window.
Due to the SOP the browser should throw a DOMException ("Failed to read
a named property 'document' from 'Window': Blocked a frame with origin
"https://as.example.com; from accessing a cross-origin frame.")
As I said in the other response, we would be really interested in taking
a look at existing implementations of draft-sakimura-oauth-wmrm-01 to
see how they solve this problem.
Best regards,
Karsten
On 10.01.2024 10:15, Filip Skokan wrote:
We do not consider the relay mode. The relay mode is motivated by
the use of the implicit grant which is discouraged nowadays.
Motivation aside, if my memory serves right (and that's a big IF in
this case), the relay mode was not limited to implicit responses and
was useful regardless of the response type, e.g. in cases where the
authorization request was triggered from an eTLD+1 top level window
but the target was authenticating a service that ran on its subdomain,
a landing page with a CTA to login sort of setup.
S pozdravem,
*Filip Skokan*
On Wed, 10 Jan 2024 at 09:47, Filip Skokan wrote:
our draft covers and is compatible to what's called "simple
mode" (both with and without prompt) in
draft-sakimura-oauth-wmrm-00/-01.
So a client that's using a simple mode with web_message today
could, without change, utilize your draft as well? That doesn't
seem likely given the message structure is not the same as in
draft-sakimura-oauth-wmrm. Is that an omission or intentional?
S pozdravem,
*Filip Skokan*
On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen |
Hackmanit wrote:
Hello Filip,
our draft covers and is compatible to what's called "simple
mode" (both with and without prompt) in
draft-sakimura-oauth-wmrm-00/-01.
We do not consider the relay mode. The relay mode is motivated
by the use of the implicit grant which is discouraged nowadays.
The main differences to draft-sakimura-oauth-wmrm-01 can be
summarized as follows:
* In general we do not focus on "modes" but instead on the
actual communication using the postMessage API. Our draft
contains examples for the format/structure for the
messages sent using the postMessage API.
* Our draft enables iframe flows with user interaction while
draft-sakimura-oauth-wmrm-01 only covers iframe flows
without user interaction.
* Our draft contains security considerations describing
threats and giving recommendations to address them.
* Our draft briefly discusses the implications of the 3rd
party cookie phaseout for iframes.
Our main motivation is the belief that there is a need for a
specification defining how to securely use the postMessage API
for OAuth auth. responses. The research of my co-authors
underlines this need [1].
As I said, at the last OSW there was agreement that it would
be a good idea to write an RFC for a postMessage-based
response mode. draft-sakimura-oauth-wmrm-00 was expired years
ago and seemed to be inactive when we started to work on our
own draft. In our opinion it is not a great option to rely on
an expired draft. As for customers I work with this is not an
option at all; they want to implement and use final RFCs
whenever possible.
We are looking for feedback from the WG and are open to
collaborate with the authors of draft-sakimura-oauth-wmrm if
they want to join the efforts.
Best regards,
Karsten
[1] https://distinct-sso.com/
On 04.01.2024 12:10, Filip Skokan wrote:
Hello Karsten,
Can you summarize in what ways is your draft compatible
with draft-sakimura-oauth-wmrm-00? Which of the described
modes in Nat's document does it cover?
There are existing implementations (both partial and full)
of draft-sakimura-oauth-wmrm-00 so if your draft is not
compatible I would recommend not using the same response mode
name/identifier in your proposal.
What prompted you to start a new draft rather than
using draft-sakimura-oauth-wmrm-00?
S pozdravem,
*Filip Skokan*
Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback
Hello Filip,
my bad, you are right. "Compatible" was the wrong word to use.
Yes, a client implementing draft-sakimura-oauth-wmrm-01 would expect a
different message structure than defined in our draft.
We are not fixed to the message structure in our current draft and are
open to discuss adjusting it. That's the type of feedback we are asking for.
We would be very interested in the implementations of
draft-sakimura-oauth-wmrm you mentioned. Can you point us to these
implementations?
Best regards,
Karsten
On 10.01.2024 09:47, Filip Skokan wrote:
our draft covers and is compatible to what's called "simple mode"
(both with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
So a client that's using a simple mode with web_message today could,
without change, utilize your draft as well? That doesn't seem likely
given the message structure is not the same as in
draft-sakimura-oauth-wmrm. Is that an omission or intentional?
S pozdravem,
*Filip Skokan*
On Wed, 10 Jan 2024 at 09:37, Karsten Meyer zu Selhausen | Hackmanit
wrote:
Hello Filip,
our draft covers and is compatible to what's called "simple mode"
(both with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
We do not consider the relay mode. The relay mode is motivated by
the use of the implicit grant which is discouraged nowadays.
The main differences to draft-sakimura-oauth-wmrm-01 can be
summarized as follows:
* In general we do not focus on "modes" but instead on the
actual communication using the postMessage API. Our draft
contains examples for the format/structure for the messages
sent using the postMessage API.
* Our draft enables iframe flows with user interaction while
draft-sakimura-oauth-wmrm-01 only covers iframe flows without
user interaction.
* Our draft contains security considerations describing threats
and giving recommendations to address them.
* Our draft briefly discusses the implications of the 3rd party
cookie phaseout for iframes.
Our main motivation is the belief that there is a need for a
specification defining how to securely use the postMessage API for
OAuth auth. responses. The research of my co-authors underlines
this need [1].
As I said, at the last OSW there was agreement that it would be a
good idea to write an RFC for a postMessage-based response mode.
draft-sakimura-oauth-wmrm-00 was expired years ago and seemed to
be inactive when we started to work on our own draft. In our
opinion it is not a great option to rely on an expired draft. As
for customers I work with this is not an option at all; they want
to implement and use final RFCs whenever possible.
We are looking for feedback from the WG and are open to
collaborate with the authors of draft-sakimura-oauth-wmrm if they
want to join the efforts.
Best regards,
Karsten
[1] https://distinct-sso.com/
On 04.01.2024 12:10, Filip Skokan wrote:
Hello Karsten,
Can you summarize in what ways is your draft compatible
with draft-sakimura-oauth-wmrm-00? Which of the described modes
in Nat's document does it cover?
There are existing implementations (both partial and full)
of draft-sakimura-oauth-wmrm-00 so if your draft is not
compatible I would recommend not using the same response mode
name/identifier in your proposal.
What prompted you to start a new draft rather than
using draft-sakimura-oauth-wmrm-00?
S pozdravem,
*Filip Skokan*
On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen |
Hackmanit wrote:
Hi all,
we would like to ask again for feedback on our draft for the
"web_message" response mode:
*https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
*
We think it would be very helpful for implementers and
developers to specify a secure standard for a postMessage
API-based response mode.
Best regards,
Karsten*
*
On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit
wrote:
Hi everyone,
at the last OSW the topic of a response mode based on the
postMessage API came up. This approach is already used by
multiple parties (e.g., Google) but lacks standardization.
There was some sense of agreement that it would be a good
idea to create an RFC defining this response mode to counter
security flaws in individual implementations and improve
interoperability.
Because the efforts in the past were long expired (draft -00
of
https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/
expired in 2016) we took the initiative and started to work
on a new ID for the "web_message"
Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback
Hello Filip,
our draft covers and is compatible to what's called "simple mode" (both
with and without prompt) in draft-sakimura-oauth-wmrm-00/-01.
We do not consider the relay mode. The relay mode is motivated by the
use of the implicit grant which is discouraged nowadays.
The main differences to draft-sakimura-oauth-wmrm-01 can be summarized
as follows:
* In general we do not focus on "modes" but instead on the actual
communication using the postMessage API. Our draft contains examples
for the format/structure for the messages sent using the postMessage
API.
* Our draft enables iframe flows with user interaction while
draft-sakimura-oauth-wmrm-01 only covers iframe flows without user
interaction.
* Our draft contains security considerations describing threats and
giving recommendations to address them.
* Our draft briefly discusses the implications of the 3rd party cookie
phaseout for iframes.
Our main motivation is the belief that there is a need for a
specification defining how to securely use the postMessage API for OAuth
auth. responses. The research of my co-authors underlines this need [1].
As I said, at the last OSW there was agreement that it would be a good
idea to write an RFC for a postMessage-based response mode.
draft-sakimura-oauth-wmrm-00 was expired years ago and seemed to be
inactive when we started to work on our own draft. In our opinion it is
not a great option to rely on an expired draft. As for customers I work
with this is not an option at all; they want to implement and use final
RFCs whenever possible.
We are looking for feedback from the WG and are open to collaborate with
the authors of draft-sakimura-oauth-wmrm if they want to join the efforts.
Best regards,
Karsten
[1] https://distinct-sso.com/
On 04.01.2024 12:10, Filip Skokan wrote:
Hello Karsten,
Can you summarize in what ways is your draft compatible
with draft-sakimura-oauth-wmrm-00? Which of the described modes in
Nat's document does it cover?
There are existing implementations (both partial and full)
of draft-sakimura-oauth-wmrm-00 so if your draft is not compatible I
would recommend not using the same response mode name/identifier in
your proposal.
What prompted you to start a new draft rather than
using draft-sakimura-oauth-wmrm-00?
S pozdravem,
*Filip Skokan*
On Thu, 4 Jan 2024 at 12:04, Karsten Meyer zu Selhausen | Hackmanit
wrote:
Hi all,
we would like to ask again for feedback on our draft for the
"web_message" response mode:
*https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/
*
We think it would be very helpful for implementers and developers
to specify a secure standard for a postMessage API-based response
mode.
Best regards,
Karsten*
*
On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit wrote:
Hi everyone,
at the last OSW the topic of a response mode based on the
postMessage API came up. This approach is already used by
multiple parties (e.g., Google) but lacks standardization.
There was some sense of agreement that it would be a good idea to
create an RFC defining this response mode to counter security
flaws in individual implementations and improve interoperability.
Because the efforts in the past were long expired (draft -00 of
https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/
expired in 2016) we took the initiative and started to work on a
new ID for the "web_message" response mode.
*We would like to to ask the members of the working group for
feedback on our draft:
https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/*
I see that "draft-sakimura-oauth-wmrm" has been recently updated.
However, there have not been any changes to its contents. What
are the plans of the authors for this draft?
Best regards
Karsten
--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone: +49 (0)234 / 54456499
Web:https://hackmanit.de | IT Security Consulting, Penetration
Testing, Security Training
Multi-Factor Authentication (MFA) significantly increases the security of
your accounts.
Learn in our blog posts what the best MFA options are and how FIDO2 goes
one step further to solve the world’s password problem:
https://www.hackmanit.de/en/blog-en/162-what-is-mfa
https://www.hackmanit.de/en/blog-en/165-what-is-fido2
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
--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone: +49 (0)234 / 54456499
Web:https://hackmanit.de | IT S
Re: [OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback
Hi all, we would like to ask again for feedback on our draft for the "web_message" response mode: *https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/ * We think it would be very helpful for implementers and developers to specify a secure standard for a postMessage API-based response mode. Best regards, Karsten* * On 23.11.2023 10:11, Karsten Meyer zu Selhausen | Hackmanit wrote: Hi everyone, at the last OSW the topic of a response mode based on the postMessage API came up. This approach is already used by multiple parties (e.g., Google) but lacks standardization. There was some sense of agreement that it would be a good idea to create an RFC defining this response mode to counter security flaws in individual implementations and improve interoperability. Because the efforts in the past were long expired (draft -00 of https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/ expired in 2016) we took the initiative and started to work on a new ID for the "web_message" response mode. *We would like to to ask the members of the working group for feedback on our draft: https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/* I see that "draft-sakimura-oauth-wmrm" has been recently updated. However, there have not been any changes to its contents. What are the plans of the authors for this draft? Best regards Karsten -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Multi-Factor Authentication (MFA) significantly increases the security of your accounts. Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem: https://www.hackmanit.de/en/blog-en/162-what-is-mfa https://www.hackmanit.de/en/blog-en/165-what-is-fido2 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 -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Multi-Factor Authentication (MFA) significantly increases the security of your accounts. Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem: https://www.hackmanit.de/en/blog-en/162-what-is-mfa https://www.hackmanit.de/en/blog-en/165-what-is-fido2 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 OpenPGP_0x4535C0E7DB16F148.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Draft for “web_message” Response Mode - Asking For Feedback
Hi everyone, at the last OSW the topic of a response mode based on the postMessage API came up. This approach is already used by multiple parties (e.g., Google) but lacks standardization. There was some sense of agreement that it would be a good idea to create an RFC defining this response mode to counter security flaws in individual implementations and improve interoperability. Because the efforts in the past were long expired (draft -00 of https://datatracker.ietf.org/doc/draft-sakimura-oauth-wmrm/ expired in 2016) we took the initiative and started to work on a new ID for the "web_message" response mode. *We would like to to ask the members of the working group for feedback on our draft: https://datatracker.ietf.org/doc/draft-meyerzuselha-oauth-web-message-response-mode/* I see that "draft-sakimura-oauth-wmrm" has been recently updated. However, there have not been any changes to its contents. What are the plans of the authors for this draft? Best regards Karsten -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Multi-Factor Authentication (MFA) significantly increases the security of your accounts. Learn in our blog posts what the best MFA options are and how FIDO2 goes one step further to solve the world’s password problem: https://www.hackmanit.de/en/blog-en/162-what-is-mfa https://www.hackmanit.de/en/blog-en/165-what-is-fido2 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 OpenPGP_0x4535C0E7DB16F148.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [External Sender] Re: Collective name for attacks on cross-device flows: Cross-Device Consent Phishing (CDCP)
+1 On 15.06.2023 17:05, George Fletcher wrote: I'm a +1 for the name On Thu, Jun 15, 2023 at 11:04 AM Aaron Parecki wrote: I like it, it's definitely the best out of the list. Aaron On Thu, Jun 15, 2023 at 7:57 AM Pieter Kasselman wrote: Hi folks, one of the discussion points at IETF 116 for the cross-device security BCP was finding a collective name for the exploits of the cross device flows we were seeing. We got several suggestions since then (see list below). We are thinking of adopting the term “Cross-Device Consent Phishing (CDCP)” given that it describes the scope of the attacks (cross-device), the purpose of the attacks (obtaining user consent), and the technique (phishing, and other social engineering techniques). Does this feel like a good descriptive name to adopt? The list of names that was suggested over the last few months: 1. Cross-Device Consent Phishing 2. Illicit Consent Grant Attack 3. Attacker-in-the-Middle Attack 4. Authorization Context Manipulation Attack 5. Authorization Context Manipulation Exploit 6. "Cross-Device Authorization Exploit" 7. "Social Engineering Token Theft" 8. "Authorization Flow Manipulation Exploit" 9. Context Manipulation Authorization Exploit 10. Zishing 11. Azishing 12. FlowJack 13. AuthJack 14. TokenJack 15. Permitphishing, 16. Authishing Cheers Pieter ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MiVGjrrSZVrFfqf5H3kVV6POC4gNvh4iM5j_St4tWh0T_-9MQOlgEBWH6kUuh1RtUeBGH_FynAidy_YXHRrQoFVGgaI2Y3MQ738ijjY$> ___ OAuth mailing list OAuth@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!FrPt2g6CO4Wadw!MiVGjrrSZVrFfqf5H3kVV6POC4gNvh4iM5j_St4tWh0T_-9MQOlgEBWH6kUuh1RtUeBGH_FynAidy_YXHRrQoFVGgaI2Y3MQ738ijjY$ The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ___ OAuth mailing list OAuth@ietf.org 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 Multi-Factor Authentication (MFA) increases the security of your account. Learn what the best MFA options are in our blog post:https://www.hackmanit.de/en/blog-en/162-what-is-mfa 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] audience parameter in client_credentials
These parameters seem to be similar to the "resource" parameter defined in RFC8707 (https://www.rfc-editor.org/rfc/rfc8707.html). Maybe the vendors implemented their non-standard extensions before the RFC was published. Best regards, Karsten On 17.04.2023 23:57, Evert Pot wrote: Hi list, I'm the author a OAuth2 client library[1]. I received a feature request to support the "audience" parameter on client_credentials, as seen on the following two server implementations: * Auth0: https://auth0.com/docs/api/authentication?http#authorization-code-flow-with-pkce45 * Kinde: https://kinde.com/docs/build/get-access-token-for-connecting-securely-to-kindes-api/ Is this parameter based on any standard or draft or are these non-standard vendor extensions? I'm hesitant blindly adding support for these without understanding the security implications. Evert [1]: https://github.com/badgateway/oauth2-client ___ OAuth mailing list OAuth@ietf.org 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 Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 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 OpenPGP_0x4535C0E7DB16F148.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt
Hi Pieter, I won't be able to attend IETF 116, so I ask my short question here: Why is there a difference between step (D) in Figure 1 (user transferred pattern) and steps (D) + (E) in Figure 2 (client transferred pattern)? Shouldn't the user authenticate to the authorization server and then grant the authorization in both patterns? FYI: I also created a PR <https://github.com/oauth-wg/oauth-cross-device-security/pull/38> with some typo fixes and minor suggestions. Best regards, Karsten On 13.03.2023 21:24, Pieter Kasselman wrote: Hi folks, this updated version of the cross-device security BCP will be the basis for discussion in Yokohama. The draft was updated to: 1. Provide more granularity on different cross-device flow patterns 2. Include information on the limitations of some of the proposed mitigations (none of them are silver bullets and they are most effective when deployed as part of a defence-in-depth approach) 3. Updated and added additional use cases and exploit examples 3. Fixes for typos, grammar etc. I also want to thank Aaron Parecki for helping us migrate the -00 draft to the Github repository. Cheers Pieter -Original Message- From: OAuth On Behalf ofinternet-dra...@ietf.org Sent: Monday, March 13, 2023 6:29 PM To:i-d-annou...@ietf.org Cc:oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-cross-device-security-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title : Cross-Device Flows: Security Best Current Practice Authors : Pieter Kasselman Daniel Fett Filip Skokan Filename: draft-ietf-oauth-cross-device-security-01.txt Pages : 40 Date: 2023-03-13 Abstract: This document describes threats against cross-device flows along with near term mitigations, protocol selection guidance and the analytical tools needed to evaluate the effectiveness of these mitigations. It serves as a security guide to system designers, architects, product managers, security specialists, fraud analysts and engineers implementing cross-device flows. The IETF datatracker status page for this Internet-Draft is: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-oauth-cross-device-security%2F=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=J4tksmhwl2n0sTgexdtIl8%2BO4fLAbcfRy9kWQ%2F%2BA4pY%3D=0 There is also an HTML version available at: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-oauth-cross-device-security-01.html=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8yOF0hi777CSOBrkEFqPiTRzhFde067zXxBW%2FPH7zgE%3D=0 A diff from the previous version is available at: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-oauth-cross-device-security-01=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=G5%2BH8H0thDW1202i30NgVR6MTqXivysbisDqXpXwXGo%3D=0 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ OAuth mailing list OAuth@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7Cpieter.kasselman%40microsoft.com%7C2177902f9a754bf06d1508db23f0ef5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638143289963685543%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=WYeoZK67zgwPLDektVwqS%2FI3%2FxAvRUZFD%2FLnAT9eWL4%3D=0 ___ OAuth mailing list OAuth@ietf.org 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 Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 Hackmanit GmbH Universitätsstraße 60 (Exzenterhaus) 44789 Bochum Registergericht: Amtsgericht Bochum, HRB 14896 Geschäftsführer: Prof. Dr. Jörg Schwenk, Prof. Dr.
Re: [OAUTH-WG] redirect uri and portals
The benefit of not storing the state of all users on the server-side is still present. The client only needs to store and use *one *key-pair for all JWTs. On 07.03.2023 15:57, Yannick Majoros wrote: I'm still missing the point: - any key used to sign or encrypt the state... is state itself - if we can store that key (or anything, like an url to go back to after login), why bother passing the state around? Le mar. 7 mars 2023 à 15:07, Hannes Tschofenig a écrit : Hi Yannick, Am 07.03.2023 um 14:25 schrieb Yannick Majoros: One possible solution: Store the redirect information in a signed JWT and place the JWT in the state parameter. I don't think this is written somewhere in the security BCP but I think this is a solutions used in the wild by multiple clients. Section 4.7.1 of the security BCP lists this solution as one possible countermeasure: * If|state|is used for carrying application state, and integrity of its contents is a concern, clients MUST protect|state|against tampering and swapping. This can be achieved by binding the contents of state to the browser session and/or signed/encrypted state values as discussed in the now-expired draft[I-D.bradley-oauth-jwt-encoded-state <https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt>].¶ <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.7.1-3.2.1> The referenced draft has, however, expired: https://www.ietf.org/archive/id/draft-bradley-oauth-jwt-encoded-state-09.txt Ciao Hannes -- Yannick Majoros Valuya sprl -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 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 OpenPGP_0x4535C0E7DB16F148.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] redirect uri and portals
But what would encrypt or sign that redirect information? How will we decrypt/validate it after redirection from the auth server? 1. The client takes the page from which the login was triggered, stores it in a JWT, signs the JWT using a private key stored on the client. 2. The client redirects the user to the authorization server with the authorization request and adds the JWT as the value of the state parameter. 3. When the authorization server redirects the user back to the client (more precisely to the redirect URI), the state parameter (containing the JWT) is sent along with the code. 4. The client verifies the signature of the JWT in the state parameter to ensure it was originally issued by itself. 5. The client redeems the code for tokens and OAuth flow is finished. 6. The client can finally redirect the user to the page stored in the JWT and be sure the page stored within was not tampered but added to the JWT by itself. Therefore, the client cannot be abused as an open redirector. This is the main goal of protecting the state with a signature. If the key is stored somewhere (browser storage, backend, whatever), then no need to pass that state information anyway. I don't understand this statement. The benefit of not storing the state of all users on the server-side is still present. The client only needs to store and use *one *key-pair for all JWTs. And we're back to our first problem: why would my application trust that stored information more than the redirect_uri, both needing validation anyway? I am not sure what your "application" 's role is in this case. The client or the authorization server? The validation of the JWT in the state is the responsibility of the client; the validation of the redirect URI is the responsibility of the authorization server. The client trusts the JWT in the state parameter because it has a valid signature created by itself. The authorization server does not inspect the state parameter at all, but simply sends it back to the client. If the authorization server allows wildcards in redirect URIs you *could *also include the JWT in the redirect URI instead of using the state parameter. However, as you noted in your initial question, authorization servers should not allow wildcards. On 07.03.2023 14:25, Yannick Majoros wrote: But what would encrypt or sign that redirect information? How will we decrypt/validate it after redirection from the auth server? If the key is stored somewhere (browser storage, backend, whatever), then no need to pass that state information anyway. And we're back to our first problem: why would my application trust that stored information more than the redirect_uri, both needing validation anyway? Could be me, but I'm not seeing a solution for my problem yet. Le mar. 7 mars 2023 à 09:55, Karsten Meyer zu Selhausen a écrit : - In a context where all redirect URIs are under our control, how is passing state and validating it back after login better, from a security point of view, than validating redirect uri in the routing implementation of the application? Both sound equally secure to me, though redirect_uri seems much easier to implement. There have been multiple problems in the past with non-strict redirect URIs. In short: Validation of flexible redirect URIs is complex and error prone. For example, this presentation shows many past issues in URL parsers: https://i.blackhat.com/asia-19/Fri-March-29/bh-asia-Wang-Make-Redirection-Evil-Again.pdf The advantage of using the state parameter for redirect information was mentioned by Vittorio: You can sign (and optionally encrypt) the redirect information to protect it against tampering (e.g., by using a JWT in the state parameter). - How can I implement that use case easily: after login, redirecting the user back to the originally requested page, including parameters? Is that somehow covered in the document you provided, or somewhere else? One possible solution: Store the redirect information in a signed JWT and place the JWT in the state parameter. I don't think this is written somewhere in the security BCP but I think this is a solutions used in the wild by multiple clients. - And regarding that document, isn't 4.1.1 easily mitigated by PKCE anyway? PKCE mitigates that an attacker can redeem a stolen code, but there are other issues. As Aaron pointed out open redirectors are a severe issue for web applications in general, not just in OAuth-related attacks like stealing codes or tokens. Think of the following example: Assume a user receives a phishing email. They are aware of such threats and inspect the URLs in the email before visiting them. Therefore, the user does not visit links to unknown website such as https://attacker.example. However, this link is to a legitima
Re: [OAUTH-WG] redirect uri and portals
ould have those mitigations: - checking at authorization server whether the redirect is to the same uri the request originally came from - PKCE will restrict reuse of the authorization code anyway What are your thoughts on how to implement that quite common feature? Best regards, -- Yannick Majoros Valuya sprl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Yannick Majoros Valuya sprl ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Yannick Majoros Valuya sprl ___ 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 -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Save the date: 11.-12.5.2023. Join us in celebrating the 5th anniversary of RuhrSec - the IT security conference in Bochum:https://www.ruhrsec.de/2023 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 OpenPGP_0x4535C0E7DB16F148.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption: Cross-Device Flows
I support adoption of this document. Karsten On 17.11.2022 02:50, Kristina Yasuda wrote: I support adoption of this document too. Kristina *From:* OAuth *On Behalf Of * Aaron Parecki *Sent:* Wednesday, November 16, 2022 5:16 PM *To:* OAuth WG *Subject:* Re: [OAUTH-WG] Call for adoption: Cross-Device Flows I support adoption of this document. Aaron On Wed, Nov 16, 2022 at 7:52 AM Mike Jones wrote: I support adoption of the cross-device flows document. -- Mike *From:* OAuth *On Behalf Of *Joseph Heenan *Sent:* Wednesday, November 16, 2022 4:34 AM *To:* oauth *Subject:* Re: [OAUTH-WG] Call for adoption: Cross-Device Flows Hi all I support adoption of this document. Thanks Joseph On 15 Nov 2022, at 14:43, Rifaat Shekh-Yusef wrote: All, During the IETF meeting last week, there was a strong support for the adoption of the following document as a WG document: https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kasselman-cross-device-security%2F=05%7C01%7CKristina.Yasuda%40microsoft.com%7C9d0efaebe86848e588d408dac8396670%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638042446137708100%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=5mJJmz4eFY5YqQwObUIO7rhERokTriRepiROmLSmuaQ%3D=0> This is to start a call for adoption for this document. Please, provide your feedback on the mailing list on whether you support the adoption of this document as a WG or not, by *Nov 29th*. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7CKristina.Yasuda%40microsoft.com%7C9d0efaebe86848e588d408dac8396670%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638042446137718737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8uGSGEGyF2dHAASRvo2XefBomD8IzMYv34M9RS6155k%3D=0> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7CKristina.Yasuda%40microsoft.com%7C9d0efaebe86848e588d408dac8396670%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638042446137718737%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=8uGSGEGyF2dHAASRvo2XefBomD8IzMYv34M9RS6155k%3D=0> ___ OAuth mailing list OAuth@ietf.org 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 API security is crucial for secure modern applications. Learn what the most critical risks are and how to mitigate them in your APIs: https://www.hackmanit.de/en/blog-en/155-how-to-secure-apis 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Certificate-bound refresh tokens and certificate expiration handling in case of the confidential clients
ot 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:OAuth@ietf.org 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 OAuth@ietf.org 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 OAuth@ietf.org 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 ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-03.txt
Hi all, Daniel and I published a new draft version for the iss parameter. Version 03 addresses the feedback from Roman's AD review, as well as, most of the feedback from Julian Reschke's (artart) and Yoav Nir's (secdir) reviews. The only comment I could not address is this nit because I don't know how to write the links in markdown so that they are processed by xml2rfc correctly. Section links to external documents do not appear to be marked up as such (and use a trailing dot in the section number which they should not) Best regards, Karsten Am 18.11.2021 um 20:59 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 Authorization Server Issuer Identification Authors : Karsten Meyer zu Selhausen Daniel Fett Filename: draft-ietf-oauth-iss-auth-resp-03.txt Pages : 11 Date: 2021-11-18 Abstract: This document specifies a new parameter iss that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-iss-auth-resp-03 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 -- Phone: (+49)(0)234 / 45930961 Fax:(+49)(0)234 / 45930960 Mail: karsten.meyerzuselhau...@hackmanit.de PGP:0EDA AAC6 01DE 3D7F 2123 70F8 4535 C0E7 DB16 F148 Web:www.hackmanit.de Hackmanit GmbH Universitätsstraße 150 (ID 2/469) 44801 Bochum, Germany Vertreten durch: Prof. Dr. Jörg Schwenk, Dr. Juraj Somorovsky, Dr. Christian Mainka, Marcus Niemietz Registergericht: Bochum OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Secdir last call review of draft-ietf-oauth-iss-auth-resp-02
Hi Yoav, thank you for your suggestion. We think its a valid point and followed it in a local branch. Best regards, Karsten On 06.11.2021 23:06, Yoav Nir via Datatracker wrote: Reviewer: Yoav Nir Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is clear and well-written. The Security Considerations section specifically is comprehensive and clear. My one suggestion would be to move the first paragraph in the Security Considerations section to the Introduction. It is about the attack and about the protocol in the document being effective against the attack. It's not really a consideration in the way that the rest of the section is. -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Artart last call partial review of draft-ietf-oauth-iss-auth-resp-02
Hi Julian, thank you for your comments. Answers inline We mostly addressed them locally and will publish a new version when all IESG reviews are available and addressed by us. Best regards, Karsten On 01.11.2021 11:33, Julian Reschke via Datatracker wrote: Review is partially done. Another assignment may be needed to complete it. Reviewer: Julian Reschke Review result: Almost Ready (I have reviewed this with zero knowledge of OAuth, so additional review probably would be good) Major issues: 2.4 "Clients MUST compare the extracted and URL-decoded value to the issuer identifier of the authorization server where the authorization request was sent to." I'm not sure that "URL-decoded" is correct with respect to decoding query parameters. Consider URLs containing "+" or "=". You probably need the encoding rules for application/x-www-form-urlencoded instead. Good point. We changed the text to refer to application/x-www-form-urlencoded. Minor issues: References to registries should not be listed as normative. +1 that was an editorial mistake. Fixed. Nits: Section links to external documents do not appear to be marked up as such (and use a trailing dot in the section number which they should not) I am acutally not sure how to fix this. I removed the trailing dot (thanks for the hint) but when converting markdown to XML the section is not automatically recognized. My markdown looks like this: The authorization response as specified in Section 4.1.2 of [@!RFC6749] The XML file like this: The authorization response as specified in Section 4.1.2 of target="RFC6749"> Is there some example how to link the sections in external RFCs or should we create the links manually? There are no Acks; so section 6 should be deleted (if there were acksm they should go into an unnumbered section at the end of the document) We added missing Acks and moved them to the appendix. -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [EXTERNAL] Rotating RTs and grace periods
is performing a refresh whenever it makes any connection to the AS. - As well as observing the request itself, an attacker may be able to observe the DNS lookup for the AS hostname instead, which is even more likely to be observable and also in plaintext most of the time. - An attacker in a position to steal RTs from e.g. localStorage, is probably also in a good position to either observe when the legitimate client refreshes or to actually force it to refresh early (e.g., by deleting the corresponding AT from the same storage). I know some people argue that a grace period is a reasonable trade-off between security and usability. But I think that this kind of attack would be quite easy to carry out in practice for the reasons I suggest above, so I think the security actually degrades extremely quickly if you allow a grace period of any reasonable length. On the other hand, if we discourage this entirely then people may use dubious workarounds instead (e.g., one proposal I’ve seen was to use an ID token with the JWT Bearer grant, effectively turning the ID Token into an ad-hoc RT with much fewer protections). As a strawman, what would people think of wording like the following: --- The AS MAY allow the original RT to be replayed for a short grace period to allow the client to recover if the response is not received due to a network problem or other transient issue. However, implementors should be aware that an attacker may be able to easily observe when the legitimate client makes a refresh request to the AS and so time their use of a stolen RT to occur within the grace period. Any grace period MUST be kept as short as possible, and MUST NOT exceed 60 seconds. Clients should prefer sender-constrained refresh tokens if recovery from network issues is a priority. — (The 60 seconds limit here is based on Auth0’s grace period). [1]: https://mailarchive.ietf.org/arch/msg/oauth/WXwKxQM2poW7bqOOGGp4POYolFk/ <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2FWXwKxQM2poW7bqOOGGp4POYolFk%2F=04%7C01%7Cpieter.kasselman%40microsoft.com%7Cbdb0969234774ba6f87608d99deba06c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637714457664531224%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=CDskCHwXxJxGdmudTW33gUT5f3%2B835uZDxyNEmKkiFc%3D=0> Kind regards, Neil ___ 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 -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] AD review of draft-ietf-oauth-iss-auth-resp-02
Thank you for the comments, Roman. Thank you for your suggestion, Warren. I prefer Roman's solution because I'd like to keep the policy/configuration/scenario part. I think it helps to explain _why_ these decisions are out of the scope for this specification. Best regards, Karsten On 27.10.2021 22:10, Warren Parad wrote: Would making it even simpler also work? (and is more consistent with the 6749 language) The decision of whether to accept such responses is beyond the scope of this specification. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress <https://authress.io/>. On Wed, Oct 27, 2021 at 9:41 PM Roman Danyliw wrote: Hi! I performed an AD review of draft-ietf-oauth-iss-auth-resp-02. Thanks for documenting this mitigation. The document is in good shape so I am advancing it to IETF LC. Please treat these minor comments as part of that feedback: ** Section 2.4. Editorial. The decision of whether to accept such responses is individual for every scenario and it is not in the scope of this specification. Would it be more clear to say: "Local policy or configuration can determine whether to accept such responses and specific guidance is out of scope for this specification." There is also similar language in the next paragraph. ** Section 5.1 and 5.2. Per the "Change Control" field, please s/IESG/IETF/ Thanks, Roman ___ 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 -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Shepherd writeup for draft-ietf-oauth-iss-auth-resp
Thank you RIfaat. Looks good to me, too. Best regards, Karsten On 08.10.2021 15:49, Daniel Fett wrote: Hi Rifaat, looks good to me! -Daniel Am 08.10.21 um 15:13 schrieb Rifaat Shekh-Yusef: All, The following is the first version of the shepherd writeup for the draft-ietf-oauth-iss-auth-resp document. https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/shepherdwriteup/ Please, take a look and let me know if I missed anything. I plan to ship it to the IESG next week. Regards, Rifaat ___ 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 -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification
Hi Rifaat, apologies for the delay. We published a new draft addressing your comments. We changed Section 2.4, paragraph 3 to: If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients MUST store the information which authorization server supports the iss parameter. Clients*MUST* reject authorization responses without the iss parameter from authorization servers which do support the parameter according to the client's configuration. *Clients SHOULD discard authorization responses with the iss parameter from authorization servers which do not indicate their support for the parameter. However, there might be legitimate authorization servers that provide the iss parameter without indicating their support in their metadata. The decision of whether to accept such responses is individual for every scenario and it is not in the scope of this specification.* Let us know if there is anything else we should work on. Best regards, Karsten On 26.09.2021 00:04, Rifaat Shekh-Yusef wrote: Karsten, Daniel, Can you please address my comments in a new version of the draft to allow me to progress it? Regards, Rifaat On Mon, Sep 6, 2021 at 6:50 AM Karsten Meyer zu Selhausen <mailto:karsten.meyerzuselhau...@hackmanit.de>> wrote: Hi Rifaat, thank you for the shepherd's review. Those are valid comments. We will have a second look on this paragraph. Best regards, Karsten On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote: Hi Karsten, Daniel, As the document shepherd, I have reviewed the document and I have the following comments on draft-ietf-oauth-iss-auth-resp-01 version: Section 2.4, paragraph 3, first sentence: "If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients SHOULD store the information which authorization server supports the "iss" parameter." Why is this a SHOULD? "Clients MUST reject authorization responses without the "iss" parameter from authorization servers which do support the parameter according to the client's configuration." What should the client do when it receives a response with "iss" parameter from an authorization server that did not indicate its support for this parameter? Section 7 RFC6479 should be replaced with *RFC6749* Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de <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 <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 -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] IPR Disclosures - OAuth 2.0 Authorization Server Issuer Identification
Hi Rifaat, sorry for the delay. I am not aware of any IPR related to the OAuth 2.0 Authorization Server Issuer Identification draft. Best regards, Karsten On 08.09.2021 18:44, Rifaat Shekh-Yusef wrote: Karsten, Daniel, Any update on this? Regards, Rifaat On Sat, Sep 4, 2021 at 10:30 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: Authors, As part of the shepherd write-up, all authors of the document must confirm that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. Please, reply to this email on the mailing list and indicate if you are aware of any IPRs associated with this document. Regards, Rifaat -- 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Doc Shepherd Review - OAuth 2.0 Authorization Server Issuer Identification
Hi Rifaat, thank you for the shepherd's review. Those are valid comments. We will have a second look on this paragraph. Best regards, Karsten On 04.09.2021 16:20, Rifaat Shekh-Yusef wrote: Hi Karsten, Daniel, As the document shepherd, I have reviewed the document and I have the following comments on draft-ietf-oauth-iss-auth-resp-01 version: Section 2.4, paragraph 3, first sentence: "If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients SHOULD store the information which authorization server supports the "iss" parameter." Why is this a SHOULD? "Clients MUST reject authorization responses without the "iss" parameter from authorization servers which do support the parameter according to the client's configuration." What should the client do when it receives a response with "iss" parameter from an authorization server that did not indicate its support for this parameter? Section 7 RFC6479 should be replaced with *RFC6749* Regards, Rifaat ___ OAuth mailing list OAuth@ietf.org 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 OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-01.txt
Hi all, thank you for your feedback. In this version we addressed your comments on the JARM note and clarified the mix-up description. We also changed the title of the draft to make it a little shorter. Best regards, Karsten On 08.06.2021 11:07, internet-dra...@ietf.org wrote: 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 Authorization Server Issuer Identification Authors : Karsten Meyer zu Selhausen Daniel Fett Filename: draft-ietf-oauth-iss-auth-resp-01.txt Pages : 10 Date: 2021-06-08 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The "iss" parameter serves as an effective countermeasure to "mix-up attacks". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-iss-auth-resp-01 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 -- Karsten Meyer zu Selhausen Senior IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Möchten Sie sich für ein Projekt mit dem Thema Single Sign-On oder den Standards OAuth und OpenID Connect vertraut machen? Dann melden Sie sich jetzt an für Ihre Einführung in Single Sign-On, OAuth und OpenID Connect am Mittwoch, 09.06.2021, von 10:00 - 14:30 Uhr! https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-in-single-sign-on-oauth-und-openid-connect 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, Dr. Marcus Niemietz OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00
Hi Brian,
thank you for your feedback.
I agree that the language is too strong here. What do you think about
this new note?
Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] defines a mechanism that conveys all authorization
response parameters in a JWT. This JWT contains an iss claim that
provides the same protection if it is validated as described in
Section 2.4. Therefore, an additional iss authorization response
parameter as defined by this document MUST NOT be used when JARM is used.
Best regards,
Karsten
On 15.05.2021 00:35, Brian Campbell wrote:
Overall it looks pretty good to me.
One little nit is that I don't love this text from the end of sec 2.4
that talks about JARM:
'Note: The "JWT Secured Authorization Response Mode for OAuth 2.0
(JARM)" [JARM] forbids the use of additional parameters in the
authorization response. Therefore, the iss parameter MUST NOT be used
when JARM is used. However, JARM responses contain an iss claim that
provides the same protection if it is validated as described in
Section 2.4.'
JARM doesn't exactly forbid additional parameters but rather just
wraps up all the authorization response parameters as claims in a JWT
which is itself sent as a single form/query/fragment parameter. So
really the iss authorization response parameter of this draft is still
sent as a claim of the JARM JWT. It just happens to be the same as the
iss claim value that JARM is already including.
On Sat, May 1, 2021 at 2:47 PM Rifaat Shekh-Yusef
mailto:rifaat.s.i...@gmail.com>> wrote:
All,
We have not seen any comments on this document.
Can you please review the document and provide feedback, or
indicate that you have reviewed the document and have no concerns.
Regards,
Rifaat & Hannes
On Thu, Apr 15, 2021 at 3:04 AM Karsten Meyer zu Selhausen
mailto:karsten.meyerzuselhau...@hackmanit.de>> wrote:
Hi all,
the latest version of the security BCP references
draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to
mix-up attacks.
There have not been any concerns with the first WG draft
version so far:
https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/
<https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/>
I would like to ask the WG if there are any comments on or
concerns with the current draft version.
Otherwise I hope we can move forward with the next steps and
hopefully finish the draft before/with the security BCP.
Best regards,
Karsten
--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone: +49 (0)234 / 54456499
Web:https://hackmanit.de <https://hackmanit.de> | IT Security
Consulting, Penetration Testing, Security Training
Is your OAuth or OpenID Connect client vulnerable to the severe impacts
of mix-up attacks? Learn how to protect your client in our latest blog post on
single sign-on:
https://www.hackmanit.de/en/blog-en/132-how-to-protect-your-oauth-client-against-mix-up-attacks
<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, Dr. Marcus Niemietz
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<https://www.ietf.org/mailman/listinfo/oauth>
___
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
<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./
--
Karsten Meyer zu Selhausen
Senior IT Security Consultant
Phone: +49 (0)234 / 54456499
Web:https://hackmanit.de | IT Security Consulting, Penetration Testing,
Security Training
Möchten Sie sich für ein Projekt mit dem Thema Single Sign-On oder den
Standards OAuth und OpenID Connect vertraut machen?
Dann melden Sie sich jetzt an für Ihre Einführung in Single Sign-On, OAuth und
OpenID Connect am Mittwoch, 09.06.2021, von 10:00 - 14:30 Uhr!
https://www.hackmanit.de/de/schulungen/uebersicht/139-einfuehrung-in
[OAUTH-WG] Call for Feedback on draft-ietf-oauth-iss-auth-resp-00
Hi all, the latest version of the security BCP references draft-ietf-oauth-iss-auth-resp-00 as a countermeasures to mix-up attacks. There have not been any concerns with the first WG draft version so far: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ I would like to ask the WG if there are any comments on or concerns with the current draft version. Otherwise I hope we can move forward with the next steps and hopefully finish the draft before/with the security BCP. Best regards, Karsten -- 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 client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on: 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, Dr. Marcus Niemietz OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Security of OAuth on Andriod [Was: Re: Token Mediating and session Information Backend For Frontend (TMI BFF)]
On 14 Feb 2021, at 13:48, Stoycho Sleptsov <mailto:stoycho.slept...@gmail.com> wrote: I would like to add my reasons about the "Why are developers creating BFF for their frontends to communicate with an AS", with the objective to verify if they are valid. I need the client app. to be authenticated at the AS (to determine if it is a first-party app., for example). If we decide to implement our client as a frontend SPA , then we have no other option except through a BFF, as PKCE does not help for authentication. Or is it considered a bad practice to do that? Regards, Stoycho. Sitz der Gesellschaft / Corporate Headquarters: Miles & More GmbH, Frankfurt am Main, Registereintragung / Registration: Amtsgericht Frankfurt am Main HRB 116409 Geschaeftsfuehrung / Management Board: Sebastian Riedle, Dr. Oliver Schmitt ___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> -- - Regards, Omkar Khair ___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Karsten Meyer zu Selhausen 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 client vulnerable to the severe impacts of mix-up attacks? Learn how to protect your client in our latest blog post on single sign-on: 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, Dr. Marcus Niemietz OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-iss-auth-resp-00.txt
Hi all, thank you for your support and the comments/feedback on the draft so far. The first official WG version does not contain any changes in comparison to our individual draft version -02. We would like to ask you for further feedback and comments on the draft. Best regards, Karsten On 06.01.2021 16:27, internet-dra...@ietf.org wrote: 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 Authorization Server Issuer Identifier in Authorization Response Authors : Karsten Meyer zu Selhausen Daniel Fett Filename: draft-ietf-oauth-iss-auth-resp-00.txt Pages : 10 Date: 2021-01-06 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-iss-auth-resp/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-iss-auth-resp-00.html 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 -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil: https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 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, Dr. Marcus Niemietz OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for Adoption - AS Issuer Identifier in Authorization Response
+1 On 08.12.2020 13:50, Rifaat Shekh-Yusef wrote: All, This is a call for adoption for the following AS Issuer Identifier in Authorization Response as a WG document: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ <https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/> Please, provide your feedback on the mailing list by Dec 22nd. Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil: https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 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, Dr. Marcus Niemietz OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt
Hi all, thank you for your valuable feedback on the last draft version. Daniel and I tried to address all comments in the new version. Changes in -02: * Incorporated WG feedback * Clarifications for unique issuer identifier * Clarifications when multiple issuer identifier could be present * Added note that iss parameter MUST NOT be used with JARM * Added note on error responses and example for error response * Editorial changes We would like to ask you for further feedback and comments on the new draft version. Best regards, Karsten Forwarded Message Subject: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt Date: Tue, 17 Nov 2020 03:42:02 -0800 From: internet-dra...@ietf.org To: Karsten zu Selhausen , Daniel Fett , Karsten Meyer zu Selhausen A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt has been successfully submitted by Karsten Meyer zu Selhausen and posted to the IETF repository. Name: draft-meyerzuselhausen-oauth-iss-auth-resp Revision: 02 Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response Document date: 2020-11-17 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.txt Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-02.html Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-02 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". 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. The IETF Secretariat -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Nehmen Sie an unserer nächsten Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 27.01 + 28.01.2021 teil: https://www.hackmanit.de/de/schulungen/127-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-27-01-28-01-2021 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, Dr. Marcus Niemietz ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Fwd: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt
Hi all, Daniel and I published a new version of the "iss" response parameter draft to address the feedback from the WG. Changes in -01: * Incorporated first WG feedback * Clarifications for use with OIDC * Added note that clients supporting just one AS are not vulnerable * Renamed metadata parameter * Various editorial changes We would like to ask you for further feedback and comments on the new draft version. Best regards, Karsten Forwarded Message Subject: New Version Notification for draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt Date: Sun, 01 Nov 2020 23:31:42 -0800 From: internet-dra...@ietf.org To: Karsten Meyer zu Selhausen , Karsten zu Selhausen , Daniel Fett A new version of I-D, draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt has been successfully submitted by Karsten Meyer zu Selhausen and posted to the IETF repository. Name: draft-meyerzuselhausen-oauth-iss-auth-resp Revision: 01 Title: OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response Document date: 2020-11-01 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt Status: https://datatracker.ietf.org/doc/draft-meyerzuselhausen-oauth-iss-auth-resp/ Html: https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.html Htmlized: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-meyerzuselhausen-oauth-iss-auth-resp-01 Abstract: This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up attacks". 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. The IETF Secretariat -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post: https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client 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, Dr. Marcus Niemietz ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] New draft: Mix-up prevention - adding "iss" parameter to the authorization response
Hello WG, adding the issuer identifier to the authorization response as a countermeasure to mix-up attacks is well-known on this list and already part of the security BCP (see 4.4.2 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#section-4.4.2>). However, the "iss" parameter is currently not properly specified. Daniel and I wrote an ID to solve this issue. We would like to ask the working group to give us feedback on our first draft version: https://tools.ietf.org/html/draft-meyerzuselhausen-oauth-iss-auth-resp-00 Abstract This document specifies a new parameter "iss" that is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization grant. If implemented correctly, the "iss" parameter serves as an effective countermeasure to "mix-up" attacks. The need for a proper specification of the "iss" parameter was discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/DQR2ZXtGKfa-8UGtuPYyZoAaBIc/ Best regards, Karsten -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Does your OAuth or OpenID Connect implementation use PKCE to strengthen the security? Learn more about the procetion PKCE provides and its limitations in our new blog post: https://www.hackmanit.de/en/blog-en/123-when-pkce-cannot-protect-your-confidential-oauth-client 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, Dr. Marcus Niemietz ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited
I am fairly new to this working group (and the IETF in general), so I will probably need some guidance, but I would be happy to help better defining mix-up preventions. I will start to work on an ID. Best regards, Karsten On 29.08.2020 14:34, Torsten Lodderstedt wrote: >> On 11. Aug 2020, at 08:20, Karsten Meyer zu Selhausen >> wrote: >> >> Hi all, >> >> I think we all agree that proper countermeasures of mix-up attacks should >> definitely be part of the BCP and 2.1 due to the severe impact successful >> mix-up attacks have. >> Theoretically speaking every client which supports multiple AS is >> potentially vulnerable to mix-up attacks. While in practice it might seem >> unlikely it is possible that one of the honest AS the client supports gets >> compromised and can be utilized for a mix-up attack. >> >> In a previous thread of last November >> (https://mailarchive.ietf.org/arch/msg/oauth/A7F5xSEa8DdfxHKWHW3Mqol_a4A/) I >> discussed why “use distinct redirect URIs for each AS” is not an effective >> countermeasure against mix-up attacks (if dynamic client registration is >> used). I would argue that this is especially important for mobile >> applications, SPAs, and other native applications because it is very common >> for them to use dynamic client registration. Many iOS applications now must >> support multiple AS since Apple forces the support for “Sign in with Apple” >> if any single sign-on provider is supported. This policy makes mix-up >> attacks applicable. >> >> I fully agree with Daniel, Brian, and Mike that it is important to define >> and register the “iss” parameter properly to ensure that both clients and AS >> understand and use it in the correct way. I understand that OAuth 2.1 is not >> meant to introduce and define new parameters but I strongly suggest that the >> “iss” parameter should be introduced and defined elsewhere so that it can be >> natively included in 2.1. In other words the “iss” parameter should be >> integrated in 2.1 the same way PKCE is: the initial definition of the >> parameter(s) is in another document (RFC 7636 in the case of PKCE) and then >> included in 2.1. >> >> What do you think would be the best place to define and register the “iss” >> parameter? Would it be worthwhile to reactivate and update >> “draft-ietf-oauth-mix-up-mitigation”? > That’s a decision of the authors. Alternatively, a new small draft (referring > to the BCP’s attack description) should do the job as well. Mind to write an > ID? :-) > >> Best regards, >> >> Karsten >> >> >> >> On 18.06.2020 22:49, Mike Jones wrote: >>> I support documenting the use of the issuer to mitigate mix-up attacks. >>> Note that while issuer was first defined by OpenID Connect, it became art >>> of OAuth 2.0 in RFC 8414 - OAuth 2.0 Authorization Server Metadata. >>> >>>-- Mike >>> >>> From: OAuth On Behalf Of Brian Campbell >>> Sent: Thursday, June 18, 2020 1:32 PM >>> To: Daniel Fett >>> Cc: oauth >>> Subject: [EXTERNAL] Re: [OAUTH-WG] Mix-Up Revisited >>> >>> In my (probably simplistic) understanding of things, the root underlying >>> issue that allows for mix-up in its variations is the lack of anything >>> identifying the AS in the authorization response. Following from that, >>> introducing and using an `iss` authorization response parameter has always >>> seemed like the most straightforward approach for mitigating the issue >>> (which was part of the draft-ietf-oauth-mix-up-mitigation but other >>> parameters were also included and, for reasons I'm not sure about, interest >>> in that work faded in favor of telling clients to use per AS redirect URIs) >>> . Though for the `iss` authorization response parameter to be effective, >>> all parties involved need to know about it and act on it. So I think it'd >>> need to be something more than a passing recommendation in the BCP. It >>> should be defined, registered, explained, etc.. Actually introducing a new >>> parameter is maybe going beyond the expected scope of the BCP (or 2.1). But >>> maybe that's ok, if we're at least more intentional about it. >>> >>> On Sun, Jun 7, 2020 at 7:53 AM Daniel Fett wrote: >>> Hi all, >>> I was wondering if we should move towards introducing and (more explicitly) >>> recommending the iss parameter in the security BCP, for the reasons laid >>> out below an
Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft
Hi all, I have two very small suggestions which I also raised as issues on Github: 1. There are no hints in front of example requests/responses if extra line breaks are used for display purposes. I think hints such as "(with extra line breaks for display purposes only)" should be added to the examples. (#64 <https://github.com/oauthstuff/draft-oauth-par/issues/64>) 2. In section 3 there is a typo in step 2. I think it should be "*Validate *the request object signature as specified in JAR [I-D.ietf-oauth-jwsreq], section 6.2." instead of "*Validates *the ...". The imperative is used in step 1, as well. (#65 <https://github.com/oauthstuff/draft-oauth-par/issues/65>) Best regards; Karsten On 12.08.2020 00:07, Rifaat Shekh-Yusef wrote: > All, > > This is a WGLC on the *Pushed Authorization Requests *document: > https://www.ietf.org/id/draft-ietf-oauth-par-03.html > > Please, take a look and provide feedback on the list by *August 25th.* > > Regards, > Rifaat & Hannes > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09: https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 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, Dr. Marcus Niemietz ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [EXTERNAL] Re: Mix-Up Revisited
tadata is not > used to resolve multiple issuers. Otherwise, per-*Issuer* > redirect URIs or the iss parameter MUST be used. > 2. PAR-enabled authorization servers can protect the > integrity better and protect against Mix-Up Attacks better > if they ONLY accept PAR requests. > 3. We should emphasize the importance of the iss parameter > (or issuer) in the authorization response. Maybe introduce > this parameter in the security BCP or another document? > 4. Sender-constrained access tokens help against mix-up > attacks when the access token is targeted. > 5. Sender-constraining the authorization code (PAR + > PAR-DPoP?) might be worth looking into. > > I would like to hear your thoughts! > > -Daniel > > > > ___ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth > > > > ___ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Karsten Meyer zu Selhausen IT Security Consultant Phone: +49 (0)234 / 54456499 Web:https://hackmanit.de | IT Security Consulting, Penetration Testing, Security Training Unsere nächste Live Online-Schulung zur Sicherheit von OAuth und OpenID Connect am 24.09 + 25.09: https://hackmanit.de/de/schulungen/109-live-online-schulung-single-sign-on-sicherheit-oauth-openid-connect-am-24-und-25-09-2020 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, Dr. Marcus Niemietz ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Comments on draft-ietf-oauth-v2-1-00 (The OAuth 2.1 Authorization Framework)
ection 7. Accessing Protected Resources - 7.2.1: The RS MUST NOT accept resource requests which use more than one method to transmit the access token. This should be stated more clearly here and not be included only in 7.2.3 Error Codes "invalid_request". - 7.4.2: - "As a further defense against token disclosure, the client MUST validate the TLS certificate chain when making requests to protected resources, including checking the Certificate Revocation List (CRL) [RFC5280]." The paragraph should also mention OCSP [RFC 6960] as an alternative to CRLs. - "Bearer tokens MUST NOT be stored in cookies that can be sent in the clear". Maybe state explicitly that only cookies with secure flag are allowed? - 7.4.3.4: Maybe add recommended cookie flags (secure, httpOnly, sameSite) with note "or equivalent measures" (to ensure that future cookie flags / alternatives are allowed). This is also discussed in this thread: https://mailarchive.ietf.org/arch/msg/oauth/f18vynrMXC4dj4tqck7SZIl4xp4/ Section 9. Security Considerations - 9.2: "Authorization servers MUST require clients to register" should be clarified to "Authorization servers MUST require **native app** clients to register" although this is already present in the headline of the section. - 9.7: Explicitly state that code_challenge / nonce must be bound to user agent, as well? - 9.15: Adjust text according to CSRF part in 9.7. - 9.21: Remove the section as the only present recommendation is redundant and already covered in 9.6. Appendix: - Appendix C: - Sort Extensions either alphabetically or depending on the RFC number (drafts below the RFCs). - Should RFC7592 (Dynamic Client Management) really be included as an "well-established extension"? It is only categorized as "experimental" RFC. General Comments: - Unify the order of client types: In 2.1 and 9 it is web application, browser-based application, native application, but the main section about native applications (10) is in front of the main section about browser-based applications (11). This should also be taken into account when sections are added to 9, 9.1, or 9.3. Currently 9.1.1, 9.2, and 9.3.1 are about native applications and sections about browser-based applications should be added in front of them (if there will be sections specifically about browser-based applications). - Is there any statement that it is allowed to add additional parameters in the authorization/token request/response? Part 2: Minor Mistakes (typos etc.) Section 1. Introduction - 1.5: "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (4) in Figure 2)." -> "If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (**2**) in Figure 2)." Section 4. Obtaining Authorization - 4.1.2: Note "(with extra line breaks for display purposes only)" is missing in front of example. - 4.2.2: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks. The note is not present in 4.1.2.1, 4.1.4, and 4.2.3, for example. Section 5. Issuing an Access Token - 5.2: "The provided authorization grant (e.g., authorization code, resource owner credentials)" -> "The provided authorization grant (e.g., authorization code, **client** credentials)" Section 6. Refreshing an Access Token - 6: Note "(with extra line breaks for display purposes only)" present but there are no extra line breaks. Section 7. Accessing Protected Resources - 7.2.2: Note "(with extra line breaks for display purposes only)" is missing in front of last example. Section 9. Security Considerations - 9.1.1: "public native app**s** clients" -> "public native app clients" - 9.4.2: Missing reference to "(#pop_tokens)". - 9.5: Missing reference to "(#refresh_token_protection)". - 9.7: - Missing references to "(#insufficient_uri_validation)", "(#open_redirector_on_client)", "(#csrf_countermeasures)", and "(#mix_up)" (twice). - "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization request was received from the correct authorization server." -> "Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization **response** was received from the correct authorization server." - 9.7.2 (and in general): Replace "user agent" (used 18 times) with "user-agent" (used 64 times). - 9.8: Missing reference to "(#secmodel)". - 9.18.1: Missing reference to "(#redir_uri_open_redir)". - 9.21: Missing reference to "(#client_
[OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
Hi,
we identified a possible issue regarding the Mix-Up attack
countermeasures described in the Security Best Current Practices.
Section 4.4.2 of the latest version of the BCP lists "AS-specific
redirect URIs" as a countermeasure for Mix-Up attacks.
This countermeasure can be bypassed if Dynamic Client Registration is
used by the client.
The bypass works as follows:
The client will use a unique redirect URI in the Client Registration
Request when it registers at the authorization server operated by the
attacker (A-AS).
However, the A-AS can replace this redirect URI with the same redirect
URI the client uses for the "honest" authorization server (H-AS).
According to RFC7591, the AS is explicitly allowed to replace the
client's requested metadata values and must return all registered
metadata to the client in the Client Information Response. The same
applies to the Client Information Response defined in RFC7592.
For example the client sends the following request:
POST /register HTTP/1.1
{
"redirect_uris": [
"https://client.example.org/attacker-as;],
...
}
The A-AS responds as follows:
HTTP/1.1 201 Created
{
"client_id": "s6BhdRkqt3",
"redirect_uris": [
"https://client.example.org/honest-as"], <-- redirect URI for H-AS
returned by A-AS
...
}
Neither RFC7591/RFC7592 nor the BCP state that the client should
validate the metadata contained in the Client Information Response in
any way.
Depending on its implementation the client might simply extract all data
contained in the Client Information Response and use it for
authorizations with the specific AS.
We were able to confirm that one popular open-source library behaves in
this exact way. It stores the redirect URI contained in the Client
Information Response and uses it for Authorization Requests with the
A-AS although it differs from the redirect URI in the Client
Registration Request.
In our opinion this makes the countermeasure "AS-specific redirect URIs"
obsolete and we believe the other countermeasure described in the BCP
(adding an AS identifier and the client_id of the intended recipient to
AS's responses) should be used to prevent Mix-Up attacks. If the
involved entities use the OIDC hybrid flow this countermeasure is
automatically applied.
Do we miss anything? Or what is your opinion about this?
Best regards,
Karsten Meyer zu Selhausen
--
Phone: (+49)(0)234 / 45930961
Fax:(+49)(0)234 / 45930960
Mail: karsten.meyerzuselhau...@hackmanit.de
PGP:0EDA AAC6 01DE 3D7F 2123 70F8 4535 C0E7 DB16 F148
Web:www.hackmanit.de
Hackmanit GmbH
Universitätsstraße 150 (ID 2/411)
44801 Bochum, Germany
Vertreten durch: Prof. Dr. Jörg Schwenk, Dr. Juraj Somorovsky, Dr. Christian
Mainka, Dr. Marcus Niemietz
Registergericht: Bochum
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
