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
