Subject: [OAUTH-WG] Dynamic registration draft

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 01 Jul 2014 14:40:20 -0700

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

---

From: John Bradley <[email-masked]>
Date: Tue, 1 Jul 2014 18:06:07 -0400

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 <[email-masked]> 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?
>  
>  
> 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
>

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 01 Jul 2014 16:26:20 -0700

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:[email-masked]] 
Sent: Tuesday, July 01, 2014 3:06 PM
To: Madjid Nakhjiri
Cc: [email-masked]
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 

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.

Hi all, John,

Am I missing something?

 

Thanks in advance,

Madjid

---

From: Justin Richer <[email-masked]>
Date: Tue, 1 Jul 2014 20:52:32 -0400

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 <[email-masked]> 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
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 01 Jul 2014 18:07:20 -0700

Thanks Justin for confirming. I was trying to figure out if I could turn the
public client into confidential client through this magic, but it does not
seem to be possible. If I have critical regulated data for a user exposed as
a result of token high jacking, then I am still in trouble whether it is one
copy of app or 10,000. As to your last comment below, not sure how the user
authorization change the situation: the access token is provided to client
AFTER the user provides grant. So another app can grab the token and present
it to auth server instead of the legitimate app. 

Final question is does the OAUTH token or its scope in anyway has anything
to do with HTTPS that would protect the data with the resource server?

Thanks,

Madjid

From: Justin Richer [mailto:[email-masked]] 
Sent: Tuesday, July 01, 2014 5:53 PM
To: Madjid Nakhjiri
Cc: John Bradley; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic registration draft

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

Hi John,

Madjid

John B.

Hi all, John,

Am I missing something?

 

Thanks in advance,

Madjid