Discussion:
[OAUTH-WG] Regarding using resource indicator to solve resource config issue
Phil Hunt (IDM)
2016-04-11 17:33:24 UTC
Permalink
I am finding I am not happy with solving the bad resource endpoint config issue with resource indicator. At best I see this as a special use draft for things like collab services or things which aren't resource owner centric.

Yet resource endpoint config is a concern for all clients that configure on the fly. Is it reasonable to make resource indicator mandatory for all clients? Probably not.

As OAuth depends primarily on TLS, it feels wrong not to have a solution that confirms the server host names are correct either via config lookup or some other mechanism.

Tokbind is also a solution but I suspect it may only appeal to large scale service providers and may be further off as we wait for load balancers to support tokbind. Also there are issues with tokbind on initial user binding where the mitm attack might itself establish its own token binding. I have to think this through some to confirm. But the issue of worry is what is happening on initialization and first use if the hacker has already interceded a mitm. That would make validation at config time still critical.

Hopefully somebody can arrive at an alternative for broader oauth use cases.

Phil
Brian Campbell
2016-04-11 19:18:26 UTC
Permalink
I'm not sure where the idea that it's only applicable to special uses like
collaboration services is coming from. The pattern described in the draft
(using a different parameter name but otherwise the same) is deployed and
in-use for normal OAuth cases including and especially the resource owner
centric ones.
Post by Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint config
issue with resource indicator. At best I see this as a special use draft
for things like collab services or things which aren't resource owner
centric.
Yet resource endpoint config is a concern for all clients that configure
on the fly. Is it reasonable to make resource indicator mandatory for all
clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a solution
that confirms the server host names are correct either via config lookup or
some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to large scale
service providers and may be further off as we wait for load balancers to
support tokbind. Also there are issues with tokbind on initial user binding
where the mitm attack might itself establish its own token binding. I have
to think this through some to confirm. But the issue of worry is what is
happening on initialization and first use if the hacker has already
interceded a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt (IDM)
2016-04-11 22:19:57 UTC
Permalink
I am objecting to modifying the protocol in the default case as a majority do not need RI in the case of fixed endpoints.

Migration would be challenging because the change is breaking and affects existing clients.

Dynamic discovery are up and coming cases and a relatively green field. Dealing with it at configuration/discovery makes broader sense as it has no impact on existing clients.

Phil
I'm not sure where the idea that it's only applicable to special uses like collaboration services is coming from. The pattern described in the draft (using a different parameter name but otherwise the same) is deployed and in-use for normal OAuth cases including and especially the resource owner centric ones.
Post by Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint config issue with resource indicator. At best I see this as a special use draft for things like collab services or things which aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that configure on the fly. Is it reasonable to make resource indicator mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a solution that confirms the server host names are correct either via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to large scale service providers and may be further off as we wait for load balancers to support tokbind. Also there are issues with tokbind on initial user binding where the mitm attack might itself establish its own token binding. I have to think this through some to confirm. But the issue of worry is what is happening on initialization and first use if the hacker has already interceded a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Sergey Beryozkin
2016-04-12 08:30:32 UTC
Permalink
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and affects existing clients.
How does it break the existing clients given this is an optional feature
? Can you please describe the situation where the existing clients get
broken ?

Brian, would it make sense to update the text to mention that the
clients do not have to be directly configured and instead it can be set
during the registration time, so that the property gets seamlessly
linked to client access tokens, etc, without the client applications
having to be set up with the resource indicators manually ?

Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/
John Bradley
2016-04-12 10:49:48 UTC
Permalink
We did agree in BA that if the client sends no resource the AS would audience the AT per configured policy and reply to the client with additional meta-data about what resources the AT can be used at.

It should be obvious that this is in no way a breaking change.

The only clients that need to provide a resource are ones that are asking for a token for a unknown resource, not something that is supported securely currently or by Pil’s spec. Or when down scoping a RT with multiple audiences so that the server can provide the correct token type/ claims / encryption/ signing. Can we agree that with symmetrically signed AT it is not a good thing to use the same key for all RS?

At the moment this can sort of be done with scopes but the client needs much more documentation about the scopes to understand the mapping between resource and scope, or possibly discovery of meta-data about the resource, something also not covered in Phil’s draft.

We can update the draft as an ID.

This is essentially the audience part of the POP key distribution with the addition of Nat’s meta-data for the token endpoint (in the existing JSON rather than a new header)

We need to address this. Discovery in general and Phil’s draft specifically are not a replacement, even if we were to adopt them.

To Phil’s other question about token binding, no an attacker can’t usefully MitM a token bound AT.
The private key is controlled by the client and never disclosed. You can give the token to a MitM attacker but they cannot use it anyplace even with themselves as they don’t have the private key. That is the security goal of token binding.

John B.
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt (IDM)
2016-04-12 16:00:45 UTC
Permalink
Phil
Post by John Bradley
We did agree in BA that if the client sends no resource the AS would audience the AT per configured policy and reply to the client with additional meta-data about what resources the AT can be used at.
We also agreed that was not a remedy for an attack where an attacker simply wants the token to use at the correct site to gain access to the resource.

RI is no remedy for misconfiguration esp if it should be optional for the client.
Post by John Bradley
It should be obvious that this is in no way a breaking change.
The only clients that need to provide a resource are ones that are asking for a token for a unknown resource, not something that is supported securely currently or by Pil’s spec. Or when down scoping a RT with multiple audiences so that the server can provide the correct token type/ claims / encryption/ signing. Can we agree that with symmetrically signed AT it is not a good thing to use the same key for all RS?
At the moment this can sort of be done with scopes but the client needs much more documentation about the scopes to understand the mapping between resource and scope, or possibly discovery of meta-data about the resource, something also not covered in Phil’s draft.
We can update the draft as an ID.
This is essentially the audience part of the POP key distribution with the addition of Nat’s meta-data for the token endpoint (in the existing JSON rather than a new header)
We need to address this. Discovery in general and Phil’s draft specifically are not a replacement, even if we were to adopt them.
To Phil’s other question about token binding, no an attacker can’t usefully MitM a token bound AT.
The private key is controlled by the client and never disclosed. You can give the token to a MitM attacker but they cannot use it anyplace even with themselves as they don’t have the private key. That is the security goal of token binding.
John B.
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt (IDM)
2016-04-12 16:06:57 UTC
Permalink
To be clear what I am saying... RI should be considered on its own merits as an optional protocol extension.

I do not believe it has merit when linking it to client mis-configuration detection. The issues should be kept separate.

Phil
Post by Phil Hunt (IDM)
Phil
Post by John Bradley
We did agree in BA that if the client sends no resource the AS would audience the AT per configured policy and reply to the client with additional meta-data about what resources the AT can be used at.
We also agreed that was not a remedy for an attack where an attacker simply wants the token to use at the correct site to gain access to the resource.
RI is no remedy for misconfiguration esp if it should be optional for the client.
Post by John Bradley
It should be obvious that this is in no way a breaking change.
The only clients that need to provide a resource are ones that are asking for a token for a unknown resource, not something that is supported securely currently or by Pil’s spec. Or when down scoping a RT with multiple audiences so that the server can provide the correct token type/ claims / encryption/ signing. Can we agree that with symmetrically signed AT it is not a good thing to use the same key for all RS?
At the moment this can sort of be done with scopes but the client needs much more documentation about the scopes to understand the mapping between resource and scope, or possibly discovery of meta-data about the resource, something also not covered in Phil’s draft.
We can update the draft as an ID.
This is essentially the audience part of the POP key distribution with the addition of Nat’s meta-data for the token endpoint (in the existing JSON rather than a new header)
We need to address this. Discovery in general and Phil’s draft specifically are not a replacement, even if we were to adopt them.
To Phil’s other question about token binding, no an attacker can’t usefully MitM a token bound AT.
The private key is controlled by the client and never disclosed. You can give the token to a MitM attacker but they cannot use it anyplace even with themselves as they don’t have the private key. That is the security goal of token binding.
John B.
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2016-04-12 16:09:06 UTC
Permalink
I am fine with keeping it separate, however proper audience restriction of bearer tokens or POP tokens are key mechanisms to protect AT from miss use from a number of attacks.

John B.
Post by Phil Hunt (IDM)
To be clear what I am saying... RI should be considered on its own merits as an optional protocol extension.
I do not believe it has merit when linking it to client mis-configuration detection. The issues should be kept separate.
Phil
Post by Phil Hunt (IDM)
Phil
Post by John Bradley
We did agree in BA that if the client sends no resource the AS would audience the AT per configured policy and reply to the client with additional meta-data about what resources the AT can be used at.
We also agreed that was not a remedy for an attack where an attacker simply wants the token to use at the correct site to gain access to the resource.
RI is no remedy for misconfiguration esp if it should be optional for the client.
Post by John Bradley
It should be obvious that this is in no way a breaking change.
The only clients that need to provide a resource are ones that are asking for a token for a unknown resource, not something that is supported securely currently or by Pil’s spec. Or when down scoping a RT with multiple audiences so that the server can provide the correct token type/ claims / encryption/ signing. Can we agree that with symmetrically signed AT it is not a good thing to use the same key for all RS?
At the moment this can sort of be done with scopes but the client needs much more documentation about the scopes to understand the mapping between resource and scope, or possibly discovery of meta-data about the resource, something also not covered in Phil’s draft.
We can update the draft as an ID.
This is essentially the audience part of the POP key distribution with the addition of Nat’s meta-data for the token endpoint (in the existing JSON rather than a new header)
We need to address this. Discovery in general and Phil’s draft specifically are not a replacement, even if we were to adopt them.
To Phil’s other question about token binding, no an attacker can’t usefully MitM a token bound AT.
The private key is controlled by the client and never disclosed. You can give the token to a MitM attacker but they cannot use it anyplace even with themselves as they don’t have the private key. That is the security goal of token binding.
John B.
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
John Bradley
2016-04-12 16:07:25 UTC
Permalink
Sorry I don’t recall agreeing that audience restricting the AT is not a remedy for an attacker getting the token to access a resource.

I don’t quite follow that.

John B.
Post by Phil Hunt (IDM)
Phil
Post by John Bradley
We did agree in BA that if the client sends no resource the AS would audience the AT per configured policy and reply to the client with additional meta-data about what resources the AT can be used at.
We also agreed that was not a remedy for an attack where an attacker simply wants the token to use at the correct site to gain access to the resource.
RI is no remedy for misconfiguration esp if it should be optional for the client.
Post by John Bradley
It should be obvious that this is in no way a breaking change.
The only clients that need to provide a resource are ones that are asking for a token for a unknown resource, not something that is supported securely currently or by Pil’s spec. Or when down scoping a RT with multiple audiences so that the server can provide the correct token type/ claims / encryption/ signing. Can we agree that with symmetrically signed AT it is not a good thing to use the same key for all RS?
At the moment this can sort of be done with scopes but the client needs much more documentation about the scopes to understand the mapping between resource and scope, or possibly discovery of meta-data about the resource, something also not covered in Phil’s draft.
We can update the draft as an ID.
This is essentially the audience part of the POP key distribution with the addition of Nat’s meta-data for the token endpoint (in the existing JSON rather than a new header)
We need to address this. Discovery in general and Phil’s draft specifically are not a replacement, even if we were to adopt them.
To Phil’s other question about token binding, no an attacker can’t usefully MitM a token bound AT.
The private key is controlled by the client and never disclosed. You can give the token to a MitM attacker but they cannot use it anyplace even with themselves as they don’t have the private key. That is the security goal of token binding.
John B.
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Phil Hunt (IDM)
2016-04-12 15:58:05 UTC
Permalink
John's assertion that RI can be used to detect mis-configured clients would make it mandatory.

To avoid that we need a config time solution for misconfiguration.

Phil
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
John Bradley
2016-04-12 16:04:53 UTC
Permalink
Yes clients that are dynamically configured would need to check the returned resources, or send the resource if you want to detect misconfiguration.

This check is at run time and can be enforced by the AS.

A discovery check is fake-able if the web-finger URI is compromised. Likely in my opinion if the resource is compromised in the config. It also can not be enforced. Other than that it is a fine idea.

John B.
Post by Phil Hunt (IDM)
John's assertion that RI can be used to detect mis-configured clients would make it mandatory.
To avoid that we need a config time solution for misconfiguration.
Phil
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
Sergey Beryozkin
2016-04-12 16:19:10 UTC
Permalink
Hi
Post by Phil Hunt (IDM)
John's assertion that RI can be used to detect mis-configured clients would make it mandatory.
This is an AS + RS decision, right (make the tokens bound to specific
RSs only) ? So if the client wants to access RS with (from now on)
stronger security restrictions then it is up to the client to ensure it
can do so.
Yes, if the client does not have this property (directly or indirectly)
available then it won't be able to access RS but I'm not sure it
qualifies as breaking the existing clients. (similarly, if the server
updates its server certificate then the client should be made aware of
it, etc)...
Post by Phil Hunt (IDM)
To avoid that we need a config time solution for misconfiguration.
How about setting the property at the AS Client registration process
time ? Or updating the existing client's registrations to ensure the
existing clients can stay operational ?

Cheers, Sergey
Post by Phil Hunt (IDM)
Phil
Hi
Post by Phil Hunt (IDM)
I am objecting to modifying the protocol in the default case as a
majority do not need RI in the case of fixed endpoints.
Migration would be challenging because the change is breaking and
affects existing clients.
How does it break the existing clients given this is an optional feature ? Can you please describe the situation where the existing clients get broken ?
Brian, would it make sense to update the text to mention that the clients do not have to be directly configured and instead it can be set during the registration time, so that the property gets seamlessly linked to client access tokens, etc, without the client applications having to be set up with the resource indicators manually ?
Thanks, Sergey
Post by Phil Hunt (IDM)
Dynamic discovery are up and coming cases and a relatively green field.
Dealing with it at configuration/discovery makes broader sense as it has
no impact on existing clients.
Phil
Post by Brian Campbell
I'm not sure where the idea that it's only applicable to special uses
like collaboration services is coming from. The pattern described in
the draft (using a different parameter name but otherwise the same) is
deployed and in-use for normal OAuth cases including and especially
the resource owner centric ones.
On Mon, Apr 11, 2016 at 11:33 AM, Phil Hunt (IDM)
I am finding I am not happy with solving the bad resource endpoint
config issue with resource indicator. At best I see this as a
special use draft for things like collab services or things which
aren't resource owner centric.
Yet resource endpoint config is a concern for all clients that
configure on the fly. Is it reasonable to make resource indicator
mandatory for all clients? Probably not.
As OAuth depends primarily on TLS, it feels wrong not to have a
solution that confirms the server host names are correct either
via config lookup or some other mechanism.
Tokbind is also a solution but I suspect it may only appeal to
large scale service providers and may be further off as we wait
for load balancers to support tokbind. Also there are issues with
tokbind on initial user binding where the mitm attack might itself
establish its own token binding. I have to think this through some
to confirm. But the issue of worry is what is happening on
initialization and first use if the hacker has already interceded
a mitm. That would make validation at config time still critical.
Hopefully somebody can arrive at an alternative for broader oauth use cases.
Phil
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/
Loading...