[OAUTH-WG] Resource Service metadata

[George Fletcher]

So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just leverage
RS metadata like we have AS metadata.

For an AS we require an 'iss' claim to use as an identifier of the AS.
We could do the same with RS metadata retrieving the metadata from a
.well-known location and including a claim of 'rsid' to use as an
identifier of the Resource Server.

This 'rsid' identifier could then be used for registration with the AS
and presentation by the client when requesting tokens.

This provides a separation between an identifier for a resource and the
specific endpoints the token will be sent to. A client could "discover"
the necessary endpoint on a periodic basis and use a single identifier
with the AS for any of the endpoints or scopes supported by the RS. If
desired the RS could expose the supported scopes in the RS metadata file.

Thoughts?

Thanks,
George

[Phil Hunt (IDM)]

George

Very good question...

I considered that the RS metadata discovery could be fake.

So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.

So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?

Thanks

Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the
metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't
be spoofed by another site

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS
rather than some unique endpoint (even if wildcards are allowed)

Another step that may be required is for the RS to return it's 'rsid' in
the realm field of the WWW-Authenticate response header. This allows a
client to discover metadata about the RS and it's endpoints. It also
allows the client to determine if the 'rsid' returned by the RS matches
the 'rsid' it is expecting.

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it can't be
mitm'd). Once the grant is obtained by the client, the threat comes
when the client uses the grant at a mitm'd token endpoint OR an access
token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows
us to extend trust to the RS discovery giving some assurance that a
client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid'
supported by the AS?

Post by George Fletcher
John's solution requires translating aud to res url and changes to
core oauth. He seems to imply there is a need for ongoing validation
of resource. I'm not yet convinced that is really needed. Maybe it is
needed because the client could be convinced to follow a link embedded
in a resource that is somehow not part of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the
AS. We could do the same with RS metadata retrieving the metadata
from a .well-known location and including a claim of 'rsid' to use as
an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the
AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and
the specific endpoints the token will be sent to. A client could
"discover" the necessary endpoint on a periodic basis and use a
single identifier with the AS for any of the endpoints or scopes
supported by the RS. If desired the RS could expose the supported
scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

Phil

@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

That said, I would have thought this is more ownerous than checking *.example.com matches the given URL by the client.

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.

IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter: http://twitter.com/gffletch <http://twitter.com/gffletch>
Office: [phone] Photos: http://georgefletcher.photography <http://georgefletcher.photography/>

[George Fletcher]

Inline...

Post by Phil Hunt
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve
the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery.
Yet the AS service provider doesn’t know where the client is using the
tokens. How would the client or the AS detect that the wrong iss was
given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and the
AS won't issue the token. This assumes the client is not talking to an
evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS
rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS
iss value is selfdefined by the AS, the rsid should be selfdefined by
the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how
the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking
*.example.com <http://example.com> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately
have endpoints on multiple domains. An RS may move endpoints from one
domain to another (say when moving from version 1 to version 2 of an
API). Using the rsid for audience restriction and as an indirect
mechanism for specifying actual endpoints, the RS has a much looser
coupling with the AS.

AS we move into "federated authorization" meaning that an RS outsources
it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Post by George Fletcher
Another step that may be required is for the RS to return it's 'rsid'
in the realm field of the WWW-Authenticate response header. This
allows a client to discover metadata about the RS and it's endpoints.
It also allows the client to determine if the 'rsid' returned by the
RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks
for the configuration metadata or when the client asks for tokens? I
think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do
that, the audience need to be specified everytime a token is requested.
I really don't the AS to have to manage the complex state of which
audiences have previously been issued to refresh_tokens and then
reconstruct the correct audience for a requested downscoped
access_token. It's much simpler, since the client knows which RS it's
going to send the token to, to provide that when requesting tokens.

The complication comes when exchanging the code for the tokens, it needs
to specify all possible audiences (rsid's) it might send the token to
based on the requested scopes. There will be a fair amount of complex
logic at the AS to ensure the correct behavior. I do worry about this
complexity.

Post by Phil Hunt

Post by George Fletcher

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it can't
be mitm'd). Once the grant is obtained by the client, the threat
comes when the client uses the grant at a mitm'd token endpoint OR
an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some assurance
that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to a
specific AS service designated by the customer paying for the resource
service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher

Post by George Fletcher
John's solution requires translating aud to res url and changes to
core oauth. He seems to imply there is a need for ongoing validation
of resource. I'm not yet convinced that is really needed. Maybe it
is needed because the client could be convinced to follow a link
embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the
AS. We could do the same with RS metadata retrieving the metadata
from a .well-known location and including a claim of 'rsid' to use
as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the
AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and
the specific endpoints the token will be sent to. A client could
"discover" the necessary endpoint on a periodic basis and use a
single identifier with the AS for any of the endpoints or scopes
supported by the RS. If desired the RS could expose the supported
scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

George,

Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru.

Interested to see what comes out.

Phil

@independentid

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the client will submit an rsid that isn't "registered" with the AS and the AS won't issue the token. This assumes the client is not talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS iss value is selfdefined by the AS, the rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking *.example.com <http://example.com/> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately have endpoints on multiple domains. An RS may move endpoints from one domain to another (say when moving from version 1 to version 2 of an API). Using the rsid for audience restriction and as an indirect mechanism for specifying actual endpoints, the RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS outsources it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do that, the audience need to be specified everytime a token is requested. I really don't the AS to have to manage the complex state of which audiences have previously been issued to refresh_tokens and then reconstruct the correct audience for a requested downscoped access_token. It's much simpler, since the client knows which RS it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it needs to specify all possible audiences (rsid's) it might send the token to based on the requested scopes. There will be a fair amount of complex logic at the AS to ensure the correct behavior. I do worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.
IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[John Bradley]

I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS.

That seems like a lot of work that clients are unlikely to do.

A AS might do it if it wanted to look up the identifier for a given resource.

Something like do get on resource get back Abstract identifier (probably well known location, as recently pointed out in another thread you can’t allow it to point to user content.)

The AS gets the file and maps the uri to a abstract identifier for audience.

I guess that would be one way that you could map AS URI to a abstract identifier, but I wouldn’t want to count on clients doing it.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the client will submit an rsid that isn't "registered" with the AS and the AS won't issue the token. This assumes the client is not talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS iss value is selfdefined by the AS, the rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking *.example.com <http://example.com/> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately have endpoints on multiple domains. An RS may move endpoints from one domain to another (say when moving from version 1 to version 2 of an API). Using the rsid for audience restriction and as an indirect mechanism for specifying actual endpoints, the RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS outsources it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do that, the audience need to be specified everytime a token is requested. I really don't the AS to have to manage the complex state of which audiences have previously been issued to refresh_tokens and then reconstruct the correct audience for a requested downscoped access_token. It's much simpler, since the client knows which RS it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it needs to specify all possible audiences (rsid's) it might send the token to based on the requested scopes. There will be a fair amount of complex logic at the AS to ensure the correct behavior. I do worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.
IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

I’m assuming that in many cases, the “aud” concept is opaque or even non-existent to clients. It would be hard for them to translate one to the other.

However, it may be that in some resource discovery cases, they are passing a URI (an RSID?) to a discovery service and the discovery translates that into a real endpoint. **

At some point then, having obtained what the client thinks is the resource endpoint, either in the OAuth config lookup, or elsewhere (as John Proposes) in the AS interactions, the endpoint obtained by the client for the resource is checked to some degree (regex filter, domain name check, lookup, etc).

** I don’t want to make people’s head explode, but thinking about Tony’s idea on software statements... one of the possibilities is that the resource discovery could return a software statement describing the resource. It would include items like valid endpoints for the resource as well as its audience URI(s). The AS config endpoint then uses the statement itself (signed by a trusted party) as the translation method bridging aud to real endpoint URL.

Parsing a statement may be a bit more complex for the client, but it may solve scenarios that using a resource endpoint URL alone can’t address.

Would it be worth setting up a concall early next week? The objective would be to come up with a couple of ppt slides (e.g. swim lanes) we could talk about in BA.

Phil

@independentid

Post by John Bradley
I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS.
That seems like a lot of work that clients are unlikely to do.
A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier (probably well known location, as recently pointed out in another thread you can’t allow it to point to user content.)
The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract identifier, but I wouldn’t want to count on clients doing it.
John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the client will submit an rsid that isn't "registered" with the AS and the AS won't issue the token. This assumes the client is not talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS iss value is selfdefined by the AS, the rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking *.example.com <http://example.com/> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately have endpoints on multiple domains. An RS may move endpoints from one domain to another (say when moving from version 1 to version 2 of an API). Using the rsid for audience restriction and as an indirect mechanism for specifying actual endpoints, the RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS outsources it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do that, the audience need to be specified everytime a token is requested. I really don't the AS to have to manage the complex state of which audiences have previously been issued to refresh_tokens and then reconstruct the correct audience for a requested downscoped access_token. It's much simpler, since the client knows which RS it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it needs to specify all possible audiences (rsid's) it might send the token to based on the requested scopes. There will be a fair amount of complex logic at the AS to ensure the correct behavior. I do worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.
IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[John Bradley]

The aud of the access token is completely opaque to the client in all cases, with the possible exception of someone who is using scopes to represent resources and the client has some mapping of scopes granted to RS endpoints. I am just trying to find a less confusing way to do that without the client needing a mapping.

Opaque audiences are how a client can get confused and present a token to a endpoint that is not part of the audience.

I don’t know that software statements for resources (need a different name at-least) are that useful. That starts sounding a lot like SAML SP meta-data signed by a federation.
There might be a reason to do it but it is probably overkill for the immediate problems. I don’t think that OAuth should require a central trusted authority to be securely deployed.

I am in the UK at meetings next week but will try to join if a call is set up.

John B.

Post by Phil Hunt
I’m assuming that in many cases, the “aud” concept is opaque or even non-existent to clients. It would be hard for them to translate one to the other.
However, it may be that in some resource discovery cases, they are passing a URI (an RSID?) to a discovery service and the discovery translates that into a real endpoint. **
At some point then, having obtained what the client thinks is the resource endpoint, either in the OAuth config lookup, or elsewhere (as John Proposes) in the AS interactions, the endpoint obtained by the client for the resource is checked to some degree (regex filter, domain name check, lookup, etc).
** I don’t want to make people’s head explode, but thinking about Tony’s idea on software statements... one of the possibilities is that the resource discovery could return a software statement describing the resource. It would include items like valid endpoints for the resource as well as its audience URI(s). The AS config endpoint then uses the statement itself (signed by a trusted party) as the translation method bridging aud to real endpoint URL.
Parsing a statement may be a bit more complex for the client, but it may solve scenarios that using a resource endpoint URL alone can’t address.
Would it be worth setting up a concall early next week? The objective would be to come up with a couple of ppt slides (e.g. swim lanes) we could talk about in BA.
Phil
@independentid

Post by John Bradley
I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS.
That seems like a lot of work that clients are unlikely to do.
A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier (probably well known location, as recently pointed out in another thread you can’t allow it to point to user content.)
The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract identifier, but I wouldn’t want to count on clients doing it.
John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the client will submit an rsid that isn't "registered" with the AS and the AS won't issue the token. This assumes the client is not talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS iss value is selfdefined by the AS, the rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking *.example.com <http://example.com/> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately have endpoints on multiple domains. An RS may move endpoints from one domain to another (say when moving from version 1 to version 2 of an API). Using the rsid for audience restriction and as an indirect mechanism for specifying actual endpoints, the RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS outsources it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do that, the audience need to be specified everytime a token is requested. I really don't the AS to have to manage the complex state of which audiences have previously been issued to refresh_tokens and then reconstruct the correct audience for a requested downscoped access_token. It's much simpler, since the client knows which RS it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it needs to specify all possible audiences (rsid's) it might send the token to based on the requested scopes. There will be a fair amount of complex logic at the AS to ensure the correct behavior. I do worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.
IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

[George Fletcher]

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.

I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some support
for dynamically accepting RS's and their endpoints.

For clients that only support a single AS we are saying they can get the
AS identifier out-of-band and use that. We can easily do the same thing
for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but we
shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use the
same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.

My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.

Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.

Wildcard'ing the endpoint URLs or only using domains, I don't think will
work as we've proven that open redirect holes break this thinking. It
needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the overall
picture of this for BA — even if in very rough form given the
deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
www.independentid.com <http://www.independentid.com/>

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
www.independentid.com <http://www.independentid.com/>

Post by George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery.
Yet the AS service provider doesn’t know where the client is using
the tokens. How would the client or the AS detect that the wrong
iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not talking
to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the
RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking
*.example.com <http://example.com/> matches the given URL by the
client.

My problem with the URL level checking is that a RS may legitimately
have endpoints on multiple domains. An RS may move endpoints from
one domain to another (say when moving from version 1 to version 2
of an API). Using the rsid for audience restriction and as an
indirect mechanism for specifying actual endpoints, the RS has a
much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Post by George Fletcher
Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response header.
This allows a client to discover metadata about the RS and it's
endpoints. It also allows the client to determine if the 'rsid'
returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To
do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex state
of which audiences have previously been issued to refresh_tokens and
then reconstruct the correct audience for a requested downscoped
access_token. It's much simpler, since the client knows which RS
it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to a
specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be convinced
to follow a link embedded in a resource that is somehow not part
of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

George,

For the attacks we looked at in Darmstadt, we discussed that in order for the attack to succeed (at least as envisioned), the attacker needs to have the client invoke the real authorize endpoint in order for the user to be successful in issuing the grant.

Assuming that it is the case, the attacker can use a proxied token endpoint or a proxied resource endpoint. A client that doesn’t know what the real endpoint should be could be confused depending on how discovery occurs.

Keep in mind that the token endpoint and the resource communications happens in the back channel. The user is never going to see the URL that has been invoked. So….we need to make sure the set of endpoints are bound together or confirmed.

Note: This hasn’t been a big issue to date because current apps tend to work with fixed or singleton infrastructure.

One we expand OAuth out to scenarios where there are multiple service providers with different relationships with OAuth AS’s, we move into this dynamic category that opens the threat.

Phil

@independentid

I agree with Phil that the client can’t trust any abstract identifier that it might get from a bad RS unless it is were a URI that the client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to "trust" the AS identifier that is being returned by the AS as well as the value the client gets from discovery if it uses that method to obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't seem that difficult. This only applies to clients that have some support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get the AS identifier out-of-band and use that. We can easily do the same thing for an RS identifier. They can either get it out-of-band (i.e. hardcoded) or they can get them dynamically (not likely initially but we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier (probably well known location, as recently pointed out in another thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get those endpoints and if it's doing it dynamically, it will likely use the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new endpoint, that endpoint can't go live until each AS receives the endpoint and adds it to it's map. That is a deployment nightmare. The mapping of RS to current endpoints has to dynamic even if it's done by the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think will work as we've proven that open redirect holes break this thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the overall picture of this for BA — even if in very rough form given the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid

Post by George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier can't be spoofed by another site

So the attacker makes iss and url match for the resource discovery. Yet the AS service provider doesn’t know where the client is using the tokens. How would the client or the AS detect that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the client will submit an rsid that isn't "registered" with the AS and the AS won't issue the token. This assumes the client is not talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the relationship between as and rs discovery together to confirm the relationship is valid.

And what I'd like to see is the 'rsid' value used to represent the RS rather than some unique endpoint (even if wildcards are allowed)

Long term, I think this would be better. Do we have a way to issue RSID values in the works?

No, but that is what this email thread is contemplating:) Just as the AS iss value is selfdefined by the AS, the rsid should be selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata is a mirror of how the AS 'iss' claim is defined for the AS in it's metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than checking *.example.com <http://example.com/> matches the given URL by the client.

My problem with the URL level checking is that a RS may legitimately have endpoints on multiple domains. An RS may move endpoints from one domain to another (say when moving from version 1 to version 2 of an API). Using the rsid for audience restriction and as an indirect mechanism for specifying actual endpoints, the RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS outsources it's API authorization to one or more AS's, this will become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's 'rsid' in the realm field of the WWW-Authenticate response header. This allows a client to discover metadata about the RS and it's endpoints. It also allows the client to determine if the 'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client asks for the configuration metadata or when the client asks for tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens. To do that, the audience need to be specified everytime a token is requested. I really don't the AS to have to manage the complex state of which audiences have previously been issued to refresh_tokens and then reconstruct the correct audience for a requested downscoped access_token. It's much simpler, since the client knows which RS it's going to send the token to, to provide that when requesting tokens.
The complication comes when exchanging the code for the tokens, it needs to specify all possible audiences (rsid's) it might send the token to based on the requested scopes. There will be a fair amount of complex logic at the AS to ensure the correct behavior. I do worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS authorize endpoint to succeed in obtaining an access token(it can't be mitm'd). Once the grant is obtained by the client, the threat comes when the client uses the grant at a mitm'd token endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding allows us to extend trust to the RS discovery giving some assurance that a client has a correct set of endpoints including resource.

Are you recommending that the AS metadata provide a list of the 'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do discovery for multiple AS systems. E.g. to configure a client to a specific AS service designated by the customer paying for the resource service.
IOW. by providing a resource query, the meta-data config discovery actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes to core oauth. He seems to imply there is a need for ongoing validation of resource. I'm not yet convinced that is really needed. Maybe it is needed because the client could be convinced to follow a link embedded in a resource that is somehow not part of the defined audience?
Thanks
Phil

So, in thinking about all this AS restricting tokens to RS and "discovery" of RS endpoints, etc. I wondered why we don't just leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of the AS. We could do the same with RS metadata retrieving the metadata from a .well-known location and including a claim of 'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource and the specific endpoints the token will be sent to. A client could "discover" the necessary endpoint on a periodic basis and use a single identifier with the AS for any of the endpoints or scopes supported by the RS. If desired the RS could expose the supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter: http://twitter.com/gffletch <http://twitter.com/gffletch>
Office: [phone] Photos: http://georgefletcher.photography <http://georgefletcher.photography/>

[Hans Zandbelt]

I'm sorry to keep pushing on this but the attack is not opened up by
discovery, having two fixed ASes is already a threat: multiple ASes in
general leaves the client exposed. Discovery just increases the attack
surface.

Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter:http://twitter.com/gffletch
Office: [phone] Photos:http://georgefletcher.photography

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Justin Richer]

But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fall prey to this attack, but it’s much more likely in the dynamic sense. That’s why this attack was propagated against OIDC first, where dynamic discovery of server information is almost expected by client libraries, and clients are designed to be used across domains.

— Justin

I'm sorry to keep pushing on this but the attack is not opened up by discovery, having two fixed ASes is already a threat: multiple ASes in general leaves the client exposed. Discovery just increases the attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter:http://twitter.com/gffletch
Office: [phone] Photos:http://georgefletcher.photography

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Hans Zandbelt]

a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs (hence
my point about the dynamic scenario) the root cause is not related to
configuration: it is a runtime attack (well at least one of the
permutations is) on perfectly valid configurations

Hans.

Post by Justin Richer
But it’s less likely (or less easy?) to have a malicious combination of endpoints in a static configuration. What this all boils down to is managing a set of endpoints as a “thing” that represents an AS (and some would argue associated RS). You can create that set manually or dynamically and fall prey to this attack, but it’s much more likely in the dynamic sense. That’s why this attack was propagated against OIDC first, where dynamic discovery of server information is almost expected by client libraries, and clients are designed to be used across domains.
— Justin

I'm sorry to keep pushing on this but the attack is not opened up by discovery, having two fixed ASes is already a threat: multiple ASes in general leaves the client exposed. Discovery just increases the attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Chief Architect
AOL Inc. AIM: gffletch
Mobile: [phone] Twitter:http://twitter.com/gffletch
Office: [phone] Photos:http://georgefletcher.photography

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[George Fletcher]

Isn't the solution to that attack defined? I was not including that
attack in the thinking around audience restricted tokens and AS / RS
endpoint "discovery". I think that regardless of this current discussion
the requirement for the AS to return issuer and client_id needs to stay
as does the binding of state to code.

I looked at the current email thread to be addressing an additional
problem and that is how to help the client NOT send a token to an evil
RS. From my understanding this hasn't been addressed. If I missed that
discussion, feel free to point me to the thread.

Thanks,
George

Post by Hans Zandbelt
a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs
(hence my point about the dynamic scenario) the root cause is not
related to configuration: it is a runtime attack (well at least one of
the permutations is) on perfectly valid configurations
Hans.

But it’s less likely (or less easy?) to have a malicious combination
of endpoints in a static configuration. What this all boils down to
is managing a set of endpoints as a “thing” that represents an AS
(and some would argue associated RS). You can create that set
manually or dynamically and fall prey to this attack, but it’s much
more likely in the dynamic sense. That’s why this attack was
propagated against OIDC first, where dynamic discovery of server
information is almost expected by client libraries, and clients are
designed to be used across domains.
— Justin

On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
I'm sorry to keep pushing on this but the attack is not opened up by
discovery, having two fixed ASes is already a threat: multiple ASes
in general leaves the client exposed. Discovery just increases the
attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps
tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil
On Mar 16, 2016, at 08:57, George Fletcher

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the
endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Hans Zandbelt]

agreed, I'm not suggesting that the client-to-evil-RS problem is
addressed, I was objecting to the statement that Phil made about static
configurations not being a problem; I don't think agreement was reached
on a client-to-evil-AS solution either

Hans.

Post by George Fletcher
Isn't the solution to that attack defined? I was not including that
attack in the thinking around audience restricted tokens and AS / RS
endpoint "discovery". I think that regardless of this current discussion
the requirement for the AS to return issuer and client_id needs to stay
as does the binding of state to code.
I looked at the current email thread to be addressing an additional
problem and that is how to help the client NOT send a token to an evil
RS. From my understanding this hasn't been addressed. If I missed that
discussion, feel free to point me to the thread.
Thanks,
George

Post by Hans Zandbelt
a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs
(hence my point about the dynamic scenario) the root cause is not
related to configuration: it is a runtime attack (well at least one of
the permutations is) on perfectly valid configurations
Hans.

Post by Justin Richer
But it’s less likely (or less easy?) to have a malicious combination
of endpoints in a static configuration. What this all boils down to
is managing a set of endpoints as a “thing” that represents an AS
(and some would argue associated RS). You can create that set
manually or dynamically and fall prey to this attack, but it’s much
more likely in the dynamic sense. That’s why this attack was
propagated against OIDC first, where dynamic discovery of server
information is almost expected by client libraries, and clients are
designed to be used across domains.
— Justin

On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
I'm sorry to keep pushing on this but the attack is not opened up by
discovery, having two fixed ASes is already a threat: multiple ASes
in general leaves the client exposed. Discovery just increases the
attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil
On Mar 16, 2016, at 08:57, George Fletcher

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the
endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

[Phil Hunt]

Static deployments are a problem for mix-up. Agreed.

I’m objecting to the notion that we don’t have to worry about discovery threats and that we need to do mix-up first.

Rushing ahead with partial discovery so we can address mix-up seems like a *huge* mistake.

Mix-up depends on a bad insider to a large degree.

From my perspective, there are many publishers of software (both open source and proprietary) that have their software deployed in 10s of thousands of environments in many different scenarios using millions of clients. There is a huge discovery problem coming and a correspondingly huge threat as we moving away from center-of-universe scenarios like we had with Facebook.

From my perspective, bad configuration is a much larger threat. But maybe that’s just me.

Given that there is significant overlap in the solutions we should talk about mitigations for each and work to produce a set of documents that addresses all the threats together.

That is why some of us object to WGLC at this time. We would be publishing drafts that would require revision in a few months!

Phil

@independentid

agreed, I'm not suggesting that the client-to-evil-RS problem is addressed, I was objecting to the statement that Phil made about static configurations not being a problem; I don't think agreement was reached on a client-to-evil-AS solution either
Hans.

Post by George Fletcher
Isn't the solution to that attack defined? I was not including that
attack in the thinking around audience restricted tokens and AS / RS
endpoint "discovery". I think that regardless of this current discussion
the requirement for the AS to return issuer and client_id needs to stay
as does the binding of state to code.
I looked at the current email thread to be addressing an additional
problem and that is how to help the client NOT send a token to an evil
RS. From my understanding this hasn't been addressed. If I missed that
discussion, feel free to point me to the thread.
Thanks,
George

Post by Hans Zandbelt
a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs
(hence my point about the dynamic scenario) the root cause is not
related to configuration: it is a runtime attack (well at least one of
the permutations is) on perfectly valid configurations
Hans.

But it’s less likely (or less easy?) to have a malicious combination
of endpoints in a static configuration. What this all boils down to
is managing a set of endpoints as a “thing” that represents an AS
(and some would argue associated RS). You can create that set
manually or dynamically and fall prey to this attack, but it’s much
more likely in the dynamic sense. That’s why this attack was
propagated against OIDC first, where dynamic discovery of server
information is almost expected by client libraries, and clients are
designed to be used across domains.
— Justin

On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
I'm sorry to keep pushing on this but the attack is not opened up by
discovery, having two fixed ASes is already a threat: multiple ASes
in general leaves the client exposed. Discovery just increases the
attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps
tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/>www.independentid.com

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil
On Mar 16, 2016, at 08:57, George Fletcher

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<https://www.ietf.org/mailman/listinfo/oauth>https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect

[John Bradley]

I keep saying that the mixup mitigation draft doesn't require discovery.

The AS meta-data draft started before the mixup mitigation work and is not related, other than that they both use the concept of issuer, as do you.

The mixup doesn’t require discovery but it arguably makes it easier.

John B.

Post by Phil Hunt
Static deployments are a problem for mix-up. Agreed.
I’m objecting to the notion that we don’t have to worry about discovery threats and that we need to do mix-up first.
Rushing ahead with partial discovery so we can address mix-up seems like a *huge* mistake.
Mix-up depends on a bad insider to a large degree.
From my perspective, there are many publishers of software (both open source and proprietary) that have their software deployed in 10s of thousands of environments in many different scenarios using millions of clients. There is a huge discovery problem coming and a correspondingly huge threat as we moving away from center-of-universe scenarios like we had with Facebook.
From my perspective, bad configuration is a much larger threat. But maybe that’s just me.
Given that there is significant overlap in the solutions we should talk about mitigations for each and work to produce a set of documents that addresses all the threats together.
That is why some of us object to WGLC at this time. We would be publishing drafts that would require revision in a few months!
Phil
@independentid

agreed, I'm not suggesting that the client-to-evil-RS problem is addressed, I was objecting to the statement that Phil made about static configurations not being a problem; I don't think agreement was reached on a client-to-evil-AS solution either
Hans.

Post by George Fletcher
Isn't the solution to that attack defined? I was not including that
attack in the thinking around audience restricted tokens and AS / RS
endpoint "discovery". I think that regardless of this current discussion
the requirement for the AS to return issuer and client_id needs to stay
as does the binding of state to code.
I looked at the current email thread to be addressing an additional
problem and that is how to help the client NOT send a token to an evil
RS. From my understanding this hasn't been addressed. If I missed that
discussion, feel free to point me to the thread.
Thanks,
George

Post by Hans Zandbelt
a good AS (at first) may become compromised and attack another AS;
whilst I agree it is less likely and less easy in static configs
(hence my point about the dynamic scenario) the root cause is not
related to configuration: it is a runtime attack (well at least one of
the permutations is) on perfectly valid configurations
Hans.

But it’s less likely (or less easy?) to have a malicious combination
of endpoints in a static configuration. What this all boils down to
is managing a set of endpoints as a “thing” that represents an AS
(and some would argue associated RS). You can create that set
manually or dynamically and fall prey to this attack, but it’s much
more likely in the dynamic sense. That’s why this attack was
propagated against OIDC first, where dynamic discovery of server
information is almost expected by client libraries, and clients are
designed to be used across domains.
— Justin

On Mar 17, 2016, at 1:06 PM, Hans Zandbelt
I'm sorry to keep pushing on this but the attack is not opened up by
discovery, having two fixed ASes is already a threat: multiple ASes
in general leaves the client exposed. Discovery just increases the
attack surface.
Hans.

Post by Phil Hunt
George,
For the attacks we looked at in Darmstadt, we discussed that in order
for the attack to succeed (at least as envisioned), the attacker needs
to have the client invoke the real authorize endpoint in order for the
user to be successful in issuing the grant.
Assuming that it is the case, the attacker can use a proxied token
endpoint or a proxied resource endpoint. A client that doesn’t know
what the real endpoint should be could be confused depending on how
discovery occurs.
Keep in mind that the token endpoint and the resource communications
happens in the back channel. The user is never going to see the URL that
has been invoked. So….we need to make sure the set of endpoints are
bound together or confirmed.
Note: This hasn’t been a big issue to date because current apps
tend to
work with fixed or singleton infrastructure.
One we expand OAuth out to scenarios where there are multiple service
providers with different relationships with OAuth AS’s, we move into
this dynamic category that opens the threat.
Phil
@independentid
www.independentid.com <http://www.independentid.com/> <http://www.independentid.com <http://www.independentid.com/>>

Post by George Fletcher

I agree with Phil that the client can’t trust any abstract identifier
that it might get from a bad RS unless it is were a URI that the
client or AS could deference to get a list of the concrete URI for the RS.

I guess I'm confused on this front as we are asking the client to
"trust" the AS identifier that is being returned by the AS as well as
the value the client gets from discovery if it uses that method to
obtain the AS endpoints.
I don't understand why the same philosophy can't be used for Resource
Service identifier and endpoints.

That seems like a lot of work that clients are unlikely to do.

If I can discover the RS endpoints once and cache them, that doesn't
seem that difficult. This only applies to clients that have some
support for dynamically accepting RS's and their endpoints.
For clients that only support a single AS we are saying they can get
the AS identifier out-of-band and use that. We can easily do the same
thing for an RS identifier. They can either get it out-of-band (i.e.
hardcoded) or they can get them dynamically (not likely initially but
we shouldn't preclude it).

A AS might do it if it wanted to look up the identifier for a given
resource.
Something like do get on resource get back Abstract identifier
(probably well known location, as recently pointed out in another
thread you can’t allow it to point to user content.)

Yes, you could do it this way, though the client still needs to get
those endpoints and if it's doing it dynamically, it will likely use
the same method to discover the endpoints:)

The AS gets the file and maps the uri to a abstract identifier for
audience.
I guess that would be one way that you could map AS URI to a abstract
identifier, but I wouldn’t want to count on clients doing it.

This will work fine, if the client has hardcoded endpoints.
My main concern is that I don't want the AS to have to manage a map of
endpoint URLs for each RS it's supporting.
Think of an RS that supports multiple AS's. If the RS adds a new
endpoint, that endpoint can't go live until each AS receives the
endpoint and adds it to it's map. That is a deployment nightmare. The
mapping of RS to current endpoints has to dynamic even if it's done by
the AS rather than the client.
Wildcard'ing the endpoint URLs or only using domains, I don't think
will work as we've proven that open redirect holes break this
thinking. It needs to be an exact match.

John B.

Post by Phil Hunt
George,
Thanks. It would be good to get a draft that sketches out the
overall picture of this for BA — even if in very rough form given
the deadline is monday. Or, maybe just a PPT walkthru.
Interested to see what comes out.
Phil
@independentid
<http://www.independentid.com/ <http://www.independentid.com/>>www.independentid.com <http://www.independentid.com/>

On Mar 16, 2016, at 11:29 AM, George Fletcher
Inline...

Post by Phil Hunt
Phil
@independentid
<http://www.independentid.com/ <http://www.independentid.com/>>www.independentid.com <http://www.independentid.com/>

On Mar 16, 2016, at 10:59 AM, George Fletcher

Post by George Fletcher
George
Very good question...
I considered that the RS metadata discovery could be fake.

Same way that the 'iss' claim must "match" the url used to
retrieve the metadata would apply to the 'rsid' claim
-- I think that should suffice to ensuring the 'rsid' identifier
can't be spoofed by another site

So the attacker makes iss and url match for the resource
discovery. Yet the AS service provider doesn’t know where the
client is using the tokens. How would the client or the AS detect
that the wrong iss was given?

Because if the attacker makes the rsid and the url match, then the
client will submit an rsid that isn't "registered" with the AS and
the AS won't issue the token. This assumes the client is not
talking to an evil AS (as there are other mitigations for that case).

Post by Phil Hunt

Post by George Fletcher
So the final step in configuration validation is to bind the
relationship between as and rs discovery together to confirm the
relationship is valid.

And what I'd like to see is the 'rsid' value used to represent
the RS rather than some unique endpoint (even if wildcards are
allowed)

Long term, I think this would be better. Do we have a way to issue
RSID values in the works?

No, but that is what this email thread is contemplating:) Just as
the AS iss value is selfdefined by the AS, the rsid should be
selfdefined by the RS. Requiring a 'rsid' claim in the RS metadata
is a mirror of how the AS 'iss' claim is defined for the AS in it's
metadata.

Post by Phil Hunt
That said, I would have thought this is more ownerous than
checking *.example.com <http://example.com/> <http://example.com/ <http://example.com/>>matches the given URL
by the client.

My problem with the URL level checking is that a RS may
legitimately have endpoints on multiple domains. An RS may move
endpoints from one domain to another (say when moving from version
1 to version 2 of an API). Using the rsid for audience restriction
and as an indirect mechanism for specifying actual endpoints, the
RS has a much looser coupling with the AS.
AS we move into "federated authorization" meaning that an RS
outsources it's API authorization to one or more AS's, this will
become more important.

Post by Phil Hunt

Another step that may be required is for the RS to return it's
'rsid' in the realm field of the WWW-Authenticate response
header. This allows a client to discover metadata about the RS
and it's endpoints. It also allows the client to determine if the
'rsid' returned by the RS matches the 'rsid' it is expecting.

Agreed. This might work. But should the check be when the client
asks for the configuration metadata or when the client asks for
tokens? I think it only needs to happen at config time.

What I see here is that the desire is to audience protect tokens.
To do that, the audience need to be specified everytime a token is
requested. I really don't the AS to have to manage the complex
state of which audiences have previously been issued to
refresh_tokens and then reconstruct the correct audience for a
requested downscoped access_token. It's much simpler, since the
client knows which RS it's going to send the token to, to provide
that when requesting tokens.
The complication comes when exchanging the code for the tokens, it
needs to specify all possible audiences (rsid's) it might send the
token to based on the requested scopes. There will be a fair amount
of complex logic at the AS to ensure the correct behavior. I do
worry about this complexity.

Post by Phil Hunt

Post by George Fletcher
We are of course assuming that a hacker needs to use the real AS
authorize endpoint to succeed in obtaining an access token(it
can't be mitm'd). Once the grant is obtained by the client, the
threat comes when the client uses the grant at a mitm'd token
endpoint OR an access token at a mitm'd resource endpoint.
So the AS and its config set becomes the trust anchor. Binding
allows us to extend trust to the RS discovery giving some
assurance that a client has a correct set of endpoints including
resource.

Are you recommending that the AS metadata provide a list of the
'rsid' supported by the AS?

No. I think that is a bad idea. Better to use an identity oracle
function and say, give me the config for rsid=xyz

Good :)

Post by Phil Hunt
That also allows a common AS discovery endpoint to actually do
discovery for multiple AS systems. E.g. to configure a client to
a specific AS service designated by the customer paying for the
resource service.
IOW. by providing a resource query, the meta-data config discovery
actually looks more like discovery. :-)

Post by George Fletcher
John's solution requires translating aud to res url and changes
to core oauth. He seems to imply there is a need for ongoing
validation of resource. I'm not yet convinced that is really
needed. Maybe it is needed because the client could be
convinced to follow a link embedded in a resource that is
somehow not part of the defined audience?
Thanks
Phil
On Mar 16, 2016, at 08:57, George Fletcher

Post by George Fletcher
So, in thinking about all this AS restricting tokens to RS and
"discovery" of RS endpoints, etc. I wondered why we don't just
leverage RS metadata like we have AS metadata.
For an AS we require an 'iss' claim to use as an identifier of
the AS. We could do the same with RS metadata retrieving the
metadata from a .well-known location and including a claim of
'rsid' to use as an identifier of the Resource Server.
This 'rsid' identifier could then be used for registration with
the AS and presentation by the client when requesting tokens.
This provides a separation between an identifier for a resource
and the specific endpoints the token will be sent to. A client
could "discover" the necessary endpoint on a periodic basis and
use a single identifier with the AS for any of the endpoints or
scopes supported by the RS. If desired the RS could expose the
supported scopes in the RS metadata file.
Thoughts?
Thanks,
George
_______________________________________________
OAuth mailing list
<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
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

--
Hans Zandbelt | Sr. Technical Architect

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>