Hi all, It’s worth adding that a per-instance dynamic registration of a native client can still imply a higher level of trust than a public client and registration isn’t necessarily unauthenticated. https://tools.ietf.org/html/rfc7591 defines an “initial access token”:
> OAuth 2.0 access token optionally issued by an authorization > server to a developer or client and used to authorize calls to the > client registration endpoint. The type and format of this token > are likely service specific and are out of scope for this > specification. The means by which the authorization server issues > this token as well as the means by which the registration endpoint > validates this token are out of scope for this specification. Use > of an initial access token is required when the authorization > server limits the parties that can register a client. This can be used [for example] to bind a client to a specific user, though the bootstrapping can be a little involved and potentially the bootstrapping still has weaknesses. Use of white box crypto (or other tools like device attestations) can potentially also bring dynamically registered native apps up to a sufficiently trusted level. Joseph > On 29 Nov 2018, at 14:02, Christian Mainka > <Christian.Mainka=40rub...@dmarc.ietf.org> wrote: > > Hi, > > thanks for pointing this out! > This was exactly what confused us during reading - the main threat we see and > which is not addressed is related to the app impersonation attack. > Even PKCE does not help against the app impersonation attack. > > So a "Native App + Dynamic Client Registration" can be seen at a different > "confidentiality level" than a "public client", because every native App can > dynamically register itself on the IdP. > The IdP cannot distinguish, for example, an honest native client from an > malicious client starting an app impersonation attack. > > We agree that, e.g., a leaked code cannot be redeemed unless you have the > respective client_id/client_secret. > > But... we asked ourselfs, in which cases does a code leak? > > 1) In the front-channel. In this case, it is true that no client credentials > leak and an attacker cannot redeem the code. > > 2) In the back-channel. But if this channel is insecure, you directly get > client credentials (unless client_secret_jwt is used as pointed out by > George). > > So, Dynamic Client Registration only helps if the code leaks alone (as in > 1.), or if it leaks on different levels (e.g. logfiles). > > On the opposite site, if Dynamic Registration is available, an attacker can > very easily do an app impersonation attack by registering on the IdP. To be > clear, it is not "impersonation" as in the "one secret per software" > scenario, because different client_id and client_secret is used, but to the > best of my knowledge, the IdP cannot distinguish between an honest app and an > app impersonation client that has simply registered. > > In addition, if the IdP supports the dynamic client registration: > How can the IdP distinguish between confidential and public/native clients? > With respect to the consent page, which must be shown every time for native > apps, this is an important issue, which should be addressed properly. > > Best Regards > Vladi/Christian > > Am 29.11.18 um 00:38 schrieb Richard Backman, Annabelle: >> It should be noted that “traditional” confidential clients with registered >> return URLs and server-side secrets may provide a higher degree of >> confidence in the true identity of the client that doesn’t carry over to >> confidential native app clients. A native app instance’s registration call >> is necessarily unauthenticated (for the same reasons that statically >> registered native app clients are public clients), so the Client >> Impersonation concerns described in section 8.6 of >> RFC8252<https://tools.ietf.org/html/rfc8252#section-8.6> >> <https://tools.ietf.org/html/rfc8252#section-8.6> still apply. >> -- >> Annabelle Richard Backman >> AWS Identity >> >> >> From: OAuth <oauth-boun...@ietf.org> <mailto:oauth-boun...@ietf.org> on >> behalf of Filip Skokan <panva...@gmail.com> <mailto:panva...@gmail.com> >> Date: Wednesday, November 28, 2018 at 9:11 AM >> To: George Fletcher <gffle...@aol.com> <mailto:gffle...@aol.com> >> Cc: oauth <oauth@ietf.org> <mailto:oauth@ietf.org> >> Subject: Re: [OAUTH-WG] Dynamic Client Registration with Native Apps >> >> Apologies, I missed the issued in "issued a shared secret", just reading >> "shared secret" alone is the exact opposite of a per-instance secret. The >> rest is clear and as you say it brings the benefit of the secret never being >> sent over the wire (except during the initial registration via TLS). >> >> Best, >> Filip >> >> >> On Wed, Nov 28, 2018 at 6:03 PM George Fletcher <gffle...@aol.com >> <mailto:gffle...@aol.com><mailto:gffle...@aol.com> >> <mailto:gffle...@aol.com>> wrote: >> It's "confidential" in that the shared secret is unique to that app instance >> registration (as Dennis described in his response). If an attacker gets my >> phone and compromises the data stored on my device, they only get the secret >> for my device. This is no different than a server side client having their >> client secret compromised through an attack (and in some ways is better >> because it's instance specific). >> >> The main point I was trying to make, is that the 'client_secret_jwt' method >> allows the client to never send the shared secret across the wire as is >> created in the default OAuth2 HTTP Basic Authentication method. >> >> Thanks, >> George >> On 11/28/18 11:03 AM, Filip Skokan wrote: >> Hi George, >> >> #2 doesn't seem confidential, it's still a secret shared amongst >> installations and anyone reverse engineering the apk, extracting the secret, >> can form the client_secret_jwt client_assertion with it just fine. >> >> Best, >> Filip >> >> On Wed, Nov 28, 2018 at 4:48 PM George Fletcher >> <gffletch=40aol....@dmarc.ietf.org >> <mailto:gffletch=40aol....@dmarc.ietf.org><mailto:40aol....@dmarc.ietf.org> >> <mailto:40aol....@dmarc.ietf.org>> wrote: >> In addition, a few additional patterns are enabled... >> >> 1. The native app can generate a public/private key pair and then use >> private_secret_jwt as the client credential validation method via the client >> credentials flow (defined in OpenID Connect). >> >> 2. Maybe more simply, if the native app is issued a shared secret, the app >> can use client_secret_jwt method for client authentication which ensures the >> shared secret never leaves the device. (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 >> <Christian.Mainka=40rub...@dmarc.ietf..org >> <mailto:Christian.Mainka=40rub...@dmarc.ietf..org><mailto:Christian.Mainka=40rub...@dmarc.ietf.org> >> <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 >> <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/ >> <http://nds.rub.de/chair/people/cmainka/> >> @CheariX >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org><mailto: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><mailto: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><mailto: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><mailto:OAuth@ietf.org> >> <mailto:OAuth@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth><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> > -- > 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/ > <http://nds.rub.de/chair/people/cmainka/> > @CheariX > _______________________________________________ > 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
