That’s correct: if other apps on the device can steal the client’s secrets, then they can impersonate the client even if it’s dynamically registered. However, in that case, other apps can probably just steal the client’s tokens directly, or its private keys, or just the data after the client’s done all the hard work. All of these would be bad, too, and all of them require some form of protected storage or trust on the device itself. The difference is that different copies of an app get different secret keys, so you can at least limit impersonation to a given environment.
I’ll also note that even possession of a signed software statement doesn’t authenticate a client to be a particular piece of software. However, if used correctly, it could allow a client publisher to lock down a large set of client information (redirect URIs, display name, auth type, etc) so that any impersonating client is going to have to be able to act just like the real client. Also, keep in mind that ability to register with an auth server does not constitute access to data: a user still has to authorize the client application and it has to fetch and later present a valid token. — Justin On Jul 1, 2014, at 7:26 PM, Madjid Nakhjiri <m.nakhj...@samsung.com> wrote: > Hi John, > > Thanks again for your answer. Ok, so we agree that the “eve” app can take the > secret out of the “bob” app. This is a matter of security robustness on the > device and whether different applications running on the same OS on the same > device have access to each other’s data, even if you use unique ID and > secrets. So, I still don’t understand how dynamic registration prevents other > apps on the device from knowing the client secret? (i.e. qualifying the > client as confidential?) > > On the software verification, I agree with you on the need for OS or MDM > verification, unless signature verification can be done remotely, which is > also hard. > > On initial access token, are you saying that is for server side clients, > mostly? > On the device side clients (native apps) I see your point about the need for > trusted “proxy” on the device to provide the out of band element. > > Madjid > From: John Bradley [mailto:ve7...@ve7jtb.com] > Sent: Tuesday, July 01, 2014 3:06 PM > To: Madjid Nakhjiri > Cc: oauth@ietf.org > Subject: Re: Dynamic registration draft > > With native applications the response from the Authorization server can be > intercepted by other applications on the device. > This is a known attack. If the intercepting application knows the client_id > and client_secret of the legitimate application it can exchange the code for > access and or refresh tokens. > > Dynamic registration prevents other applications on the device from knowing > the client secret. This protects against some attacks. > > No you have no way to know if it is the legitimate application that is > registering. The only way to do that is with some OS or MDM resident code > that validates the applications signature. > > The software statement allows a software publisher to bundle a set of > configuration options together, and be known by the AS as coming from that > publisher, however it is still self asserted and doesn't > guarantee the software registering is legitimate. > > The initial access token enables the out of band trust relationship. It > works well with web clients that may register out of band proving who they > are and agreeing to terms of service, and then receving a access token to do > the automated registration. > > For a native application on a device this might be possible if there is > device management software that could push a bootstrap access token to the > application to do the registration. > > John B. > > On Jul 1, 2014, at 5:40 PM, Madjid Nakhjiri <m.nakhj...@samsung.com> wrote: > > > Hi all, John, > > So I reviewed the oauth-dyn-reg-17 with the goal of finding more info on the > following statement in your previous email > > “Since the publishing of this RFC we have also developed a spec for dynamic > client registration so it is possible to give every native client it's own > client_id and secret making them confidential clients.” > > If I understand the draft correctly, you can turn a native client from public > to confidential only if the following is true: > > 1) The client must be able to dynamically register with the registration > endpoint and download an instance-specific client ID and a temporary > (“expirable”) client secret on the fly. > 2) Although the client cannot maintain the secrecy of any secrets > packaged within client software, it needs to be able to maintain the secrecy > of a per-instance client secret. > > So here are my questions: I am not quite sure what provides the trust in this > scenario. The client is using a secret that it was just given by the > registration end point (essentially hosted by authorization server?) to > authenticate to the same authorization server? Unless an out of band trust > relationship was used (initial access token??), we don’t have any additional > trust in client or its ability to hold secrets. The only added benefit by > dynamic registration in the way of above is that (as I see it), because the > ID and secret are instance specific, their compromise only leads to the > compromise of just that client and just that user’s data, rather than the > entire populations. Or the point is that we are saying there are > clients/scenarios that can be trusted with short term secrets but not long > term secrets? > > Am I missing something? > > I could see that if we had required an out of band trust relationship, for > instance requirement of a protected dynamic registration (use of initial > access token that is client instance specific), not sure how the two above > helps an individual user? > > > My other comment regarding the drafts are as follows: > 1) The draft is somewhat asymmetric with respect to the use of software > statement versus initial access token. Although, the specs says that they are > both choices of methods of attestations, only Initial access token is > required for protected registration, while software statement is declared > orthogonal to open versus protected registration. Since spec is silent on > creation of initial access token generation, it is hard to see what qualifies > the initial access token but not software statement. > 2) Software statement is a signed/ MACed statement of a subset (or none, > since they are all optional) of client meta data but not the client software > itself. So question is do I have any protection if the client software itself > is modified maliciously (even though the metadata is still the same)? > > Thanks in advance, > Madjid > > _________________________________________________ > Madjid Nakhjiri | Technical Director, Security Architect > Samsung SDS Research America > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
