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
