Derek,
Just looking at the issue you mentioned earlier. I think you also wanted to add
in that a resource server A might be legitimately trying to re-use the token
with an unintended “audience”, resource server B. Correct?
If so, here is a possible amendment to the case in 3.1:
Original Text:
Imagine a scenario where a resource server that receives a valid
access token re-uses it with other resource server. The reason for
re-use may be malicious or may well be legitimate. In a legitimate
use case consider chaining of computations whereby a resource server
needs to consult other third party resource servers to complete the
requested operation. In both cases it may be assumed that the scope
of the access token is sufficiently large that it allows such a re-
use. For example, imagine a case where a company operates email
services as well as picture sharing services and that company had
decided to issue access tokens with a scope that allows access to
both services.
With this use case the desire is to prevent such access token re-use.
This also implies that the legitimate use cases require additional
enhancements for request chaining.
Proposed text:
Imagine a scenario where a resource server that receives a valid
access token re-uses it with another resource server. The reason for
re-use may be malicious or may well be legitimate. For example, in a
legitimate
use case consider chaining of computations whereby a resource server
needs to consult another third party resource servers to complete the
requested operation. In this case, the third-party is not the intended
audience (target) of
the access token issued to the client. In both cases it may be assumed that
the scope
of the access token is sufficiently large that it allows such a re-
use. For example, imagine a case where a company operates email
services as well as picture sharing services and that company had
decided to issue access tokens with a scope that allows access to
both services.
With this use case the desire is to prevent such access token re-use and to
ensure that only the intended client
and resource servers may wield the token.
This also implies that the legitimate use cases require additional
enhancements for request chaining.
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On Jul 10, 2015, at 10:48 PM, Derek Atkins de...@ihtfp.com wrote:
Hi,
In performing my shephard review of draft-ietf-oauth-pop-architecture I
found one issue that was bugging me: you talk about target naming too
late in the draft. I.e., as I was reading through section 3.1 about
token reuse I think it doesn't have enough detail about how you would
prevent server A asking the client for a token for a resource of server
B, and then server A acting as the client for server B? I.e., how do
you prevent server A acting as a MITM between the client and server B?
(This is sort of the same question that resulted in TLS channel
bindings).
I know this target (scope) protection exists, and it's even discussed a
bit later in the document but it's not even mentioned as a possible
threat in 3.1, which seems like a glaring ommission.
I'll create a more formal shephard review but I'd suggest some
additional text to at least mention this threat in 3.1; you can provide
a pointer to the protections then, too.
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
