[OAUTH-WG] Dynamic Client Registration with Native Apps
ce. (Again defined in the OpenID Connect > spec). > > 3. Once the native app instance has credentials, they can be used for > additional securing of app API transactions in addition to just the > OAuth2/OpenID Connect flows. > > Thanks, > George > On 11/27/18 3:28 PM, William Denniss wrote: > If the secret is dynamically provisioned then you have a confidential client. > Anyone reverse engineering their own installation of the native app would > only extract their own client's credentials, as opposed to the shared secret > of all installations. Having a confidential client means that requests to the > token endpoint (code, refresh) are client authenticated, so PKCE wouldn't be > needed. > > On Tue, Nov 27, 2018 at 1:44 AM, Christian Mainka > mailto:Christian.Mainka=40rub...@dmarc.ietf.org>> > wrote: > Hi, > > we just stumbled upon this [1] statement: > "Except when using a mechanism like Dynamic Client Registration >[RFC7591] to provision per-instance secrets, native apps are >classified as public clients ..." > > What does this mean for us? Native App + Dynamic Client Registration = > Confidential Client? > Which threats are covered if Dynamic Client Registration is used on > Native Apps? > > Best Regards, > Vladi/Christian > > [1]: https://tools.ietf.org/html/rfc8252#section-8.4 > > -- > Dr.-Ing. Christian Mainka > Horst Görtz Institute for IT-Security > Chair for Network and Data Security > Ruhr-University Bochum, Germany > > Universitätsstr. 150, ID 2/463 > D-44801 Bochum, Germany > > Telefon: +49 (0) 234 / 32-26796 > Fax: +49 (0) 234 / 32-14347 > http://nds.rub.de/chair/people/cmainka/ > @CheariX > > > ___ > 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 > > _______ > 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<https://www..ietf.org/mailman/listinfo/oauth> > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr-University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Dynamic Client Registration with Native Apps
Hi, we just stumbled upon this [1] statement: "Except when using a mechanism like Dynamic Client Registration [RFC7591] to provision per-instance secrets, native apps are classified as public clients ..." What does this mean for us? Native App + Dynamic Client Registration = Confidential Client? Which threats are covered if Dynamic Client Registration is used on Native Apps? Best Regards, Vladi/Christian [1]: https://tools.ietf.org/html/rfc8252#section-8.4 -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr-University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] draft-parecki-oauth-browser-based-apps-01
Hi Aaron, I just reviewed the latest update. Thank you for this very interesting guideline! Here are my thoughts: - Section 4: "For authorizing users within a browser-based application" I would like to know whether this guide is for JavaScript Applications (such as SPas), for Browser Extensions, or for both? - Section 5: "applicaiton" -> "application"; "an web email" -> "a web email" - Section 6: "and MUST use a unique value for each authorization request." I would prefer: 'The "state" parameter MUST be a unique value for each authorization request, which is bound to the end-user's HTTP session, and must be verified upon receiving it in the authorization response.' Otherwise, it sounds like a nonce for me. - Section 7.3: "If authorization servers restrict redirect URIs to a fixed set of absolute HTTPS URIs without wildcard domains or paths" Covert redirect can be used by abusing unprotected GET parameters (which are technically not the PATH). So maybe it would be better to say simply "without wildcards" or "without wildcard domains, paths, or querys"? - Section 7.6: "dynamic registration" -> "dynamic client registration" Best Regards Christian -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr-University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
Hi,
according to [1], countermeasure (1) describes to
> configure [the] authorization servers to return an AS identitifier
("iss") and the "client_id" for which a code or token was issued in the
authorization response.
So if an MixUp attack is running, the victim contacts A-AS but is
redirected to to H-AS [2].
The AS adds - according to the countermeasure - two additional
parameters to the authorization response: client_id and issuer. Both
values are set by H-AS, so it returns H-issuer and H-client_id.
But: during the registration of the client on A-AS (rfc7591), it can return:
HTTP/1.1 201 Created
{
"client_id": "H-client_id",
"redirect_uris": [
"https://client.example.org/honest-callback;,
}
So if the client receives the client_id in the authorization response,
it is unable to distinguish to which AS the client_id belongs to - they
have the same values.
This does not hold for the issuer parameter in the authorization
response, because it is set by H-AS and independent of and not set
during the Dynamic Client Registration Protocol.
So basically, it is the same problem as with the redirect_uri.
Regards
Christian
[1]:
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.2
[2]: Step 4 in
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-13#section-4.4.1
On 02.12.19 11:26, Daniel Fett wrote:
> Am 02.12.19 um 10:05 schrieb Christian Mainka:
>> I think this problem is not only restricted to the redirect_uri.
>> Regarding countermeasure (1), also the A-AS can return the same
>> client_id as the client uses on the H-AS.
>>
>> TL;DR: In countermeasure (1), only the issuer prevents MixUp, the
>> client_id parameter can be faked as well during the registration of the
>> client (especially if Dynamic Client Registration is used).
> What would be the issuer identifiers of A-AS and H-AS in this case be,
> as seen by the client?
>
> -Daniel
>
>
>
--
Dr.-Ing. Christian Mainka
Horst Görtz Institute for IT-Security
Chair for Network and Data Security
Ruhr-University Bochum, Germany
Universitätsstr. 150, ID 2/463
D-44801 Bochum, Germany
Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://nds.rub.de/chair/people/cmainka/
@CheariX
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth 2.0 Security Best Current Practice | Issue in Mix-Up Countermeasure
Hi Daniel, I think this problem is not only restricted to the redirect_uri. Regarding countermeasure (1), also the A-AS can return the same client_id as the client uses on the H-AS. TL;DR: In countermeasure (1), only the issuer prevents MixUp, the client_id parameter can be faked as well during the registration of the client (especially if Dynamic Client Registration is used). Regards Christian On 26.11.19 15:20, Daniel Fett wrote: > Hi Karsten, > > Very interesting observation! > > My gut feeling is that this is the real problem here: > > Am 26.11.19 um 14:24 schrieb Karsten Meyer zu Selhausen: >> 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. > The client uses untrusted, unverified data to make its decision on what > redirect URI to use. > > Nonetheless, we should definitely mention this in the BCP! > >> 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. > These are more intrusive changes than the per-AS redirect URI and may > require new parameters. > > Daniel > > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr-University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://nds.rub.de/chair/people/cmainka/ @CheariX ___ 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, I read the document, have no concerns, and support it. Christian On 01.05.21 22:46, Rifaat Shekh-Yusef 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 < 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/ 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 ___ 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 -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 https://nds.rub.de/chair/people/cmainka/ @CheariX OpenPGP_signature Description: OpenPGP digital signature ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53
Hi, we would like to request the inclusion of _in-browser communication security considerations_ in the OAuth security topics. We found that in-browser communications like the postMessage API is widely used by Clients and Authorization Servers as an alternative to the standardized HTTP redirects. If these techniques are used insecurely, OAuth token leaks and injections are possible. We publish our results soon at ACM CCS in November 2022. The paper is accessible [1]. We think that the paragraph about in-browser communications should be added to the security topics. We created a pull request [2] to help developers in understanding the risks and best practices of using in-browser communications in OAuth. We are happy to discuss the idea here or directly in the pull request. Best regards Christian [1]: "DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On, https://distinct-sso.com/paper.pdf [2]: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/53 -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 https://nds.rub.de/chair/people/cmainka/ @CheariX ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Security Topics | Incorporate in-browser communication security considerations | PR53
Hi, glad to hear that you like our work. If you have any questions or if we can do anything to help you with this, don't hesitate to ask. Best regards Christian On 26.10.22 17:13, Donna Chong Nee wrote: Hi, thanks so much. Will take my time amending this with some help. Smart E11 On Thu, 27 Oct 2022, 02:16 Daniel Fett, wrote: Hi Christian, thanks for bringing this to our attention! I think the recommendations in the PR are very helpful and we will consider adding the text to the document. -Daniel Am 25.10.22 um 15:37 schrieb Christian Mainka: Hi, we would like to request the inclusion of _in-browser communication security considerations_ in the OAuth security topics. We found that in-browser communications like the postMessage API is widely used by Clients and Authorization Servers as an alternative to the standardized HTTP redirects. If these techniques are used insecurely, OAuth token leaks and injections are possible. We publish our results soon at ACM CCS in November 2022. The paper is accessible [1]. We think that the paragraph about in-browser communications should be added to the security topics. We created a pull request [2] to help developers in understanding the risks and best practices of using in-browser communications in OAuth. We are happy to discuss the idea here or directly in the pull request. Best regards Christian [1]: "DISTINCT: Identity Theft using In-Browser Communications in Dual-Window Single Sign-On, https://distinct-sso.com/paper.pdf [2]: https://github.com/oauthstuff/draft-ietf-oauth-security-topics/pull/53 ___ 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 -- Dr.-Ing. Christian Mainka Horst Görtz Institute for IT-Security Chair for Network and Data Security Ruhr University Bochum, Germany Universitätsstr. 150, ID 2/463 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 https://nds.rub.de/chair/people/cmainka/ @CheariX ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
