Thank you Seán, this is an excellent analysis and makes this attack much easier to understand. I completely agree with your rewritten text, both that it better describes the situation as well as the conclusion that it ends up being a bit too general for the BCP.
--- Aaron Parecki https://aaronparecki.com https://oauth2simplified.com On Mon, Oct 26, 2020 at 2:19 PM Seán Kelleher <[email protected]> wrote: > I hadn't come across this idea before, it's an interesting angle and for > me it's a nice new example to help highlight the difference between authZ > and authN. It reminds me of sharing access cards to get into computer labs > in college. Some thoughts: > > - It took me a while to figure out the agent, victim, intent and > impact for the attack based on its name and description. The presented term > may already be accepted, but if not, would you consider the term > "authorization sharing attack"? I feel that this conveys the intent and > impact of the attack a bit more clearly. > > However, if the access token contains claims that allow the RS to uniquely >> identify the legitimate holder of the access token >> and if the RS only accepts access tokens that are able to uniquely >> identify the legitimate holder of the access token, then >> this attack can be mitigated since the client collaborative attack >> becomes an impersonation attack. > > > - Being pedantic, I don't think this mitigates the attack so much as > it reduces it to the mentioned impersonation attack. However, I'm not sure > that "impersonation attack" is the right term to use here, as this scenario > seems to imply that the subject consents to the impersonation, which is in > contrast to the standard impersonation attack where the subject is the > victim. > > For mitigating the collaborative attack, either a "sub" claim must be >> present or any combination of other claims allowing for the RS >> to uniquely identify the holder of the access token must be present >> inside an access token >> > > - A more general phrasing of this could be that "it should be possible > to use an access token to uniquely identify an individual". I say this > because this kind of identification can also be done using opaque tokens, > in which case the claims are not necessarily "inside" the access token. > > Under these conditions, it should be observed that the first user might be >> unlikely to be willing to collaborate since the other user would be able >> to perform actions on behalf of the first user and the first user would >> be held responsible of the actions of the second user. > > > - This seems to be the main justification as to why the above > mitigations are considered as such. I don't agree with the conclusion > because I feel it's based on debateable assumptions, the main one being > that the "first user might be unlikely to be willing to collaborate" if > they know that their access token identifies them, which tries to predict > human behaviour. It also depends on the user knowing whether access tokens > can be used to identify them. > - I'm again being pedantic, but I would also note that just being able > to identify a user from an access token is unlikely to be a sufficient > deterrent, it would need to be coupled with logging of all access token > usages for auditing purposes. Again though, this assumes that we can > predict human behaviour. > - Following on from one of my above points, I would remove the user > element from this section, and avoid calling it a mitigation. I'd instead > outline that if access tokens can be used to identify individuals then it > reduces possible authZ sharing attacks to authN sharing attacks. > > I think this is an interesting attack vector, particularly because it > requires the authZ sharer to have internal knowledge of how the RS > operates, and so has relatively niche applications. It also seems to assume > that the RS in question doesn't store user IDs with access logs, at which > point, is it simpler to just recommend that authN'd requests to an RS > should be logged with user IDs? > > I've written up an alternative for consideration: > > Authorization sharing attack >> >> If access tokens are not used to identify individuals, and if this >> information is known to an individual, then such an individual may use >> knowledge of this to share the authorization granted to them by access >> tokens. This may be done by sharing access tokens across clients and >> individuals, at which point the RS will not be able to distinguish between >> different subjects and clients using the same access token. >> >> If access tokens are used to identify individuals, and such identifying >> information (ideally user IDs) is stored with access logs for auditing >> purposes, then this reduces this attack to an authentication sharing attack. >> > > I think it's a bit too general for a BCP, and too vague around the notion > of an "individual", but it might give some food for further thought. > > Kind regards, > > Seán. > >> > On Mon, 26 Oct 2020 at 18:19, Denis <[email protected]> wrote: > >> Hi Daniel, >> >> Following the conversation we had today, hereafter is a proposal for >> addressing client collaborative attacks. >> I propose to add a new section 4.16. >> >> >> 4.16 Client collaborative attacks >> >> Two clients may agree to collaborate. In such a situation, one client >> transmits to another client an access token >> that it legitimately got and also accepts to perform all the >> cryptographic computations that the other client needs >> to use the access token, including when the access token is >> cryptographically bound to a key. >> >> Since OAuth 2.0 does not mandate the use of cryptographic devices, this >> kind of attack cannot be countered in the general case. >> >> However, if the access token contains claims that allow the RS to >> uniquely identify the legitimate holder of the access token >> and if the RS only accepts access tokens that are able to uniquely >> identify the legitimate holder of the access token, then >> this attack can be mitigated since the client collaborative attack >> becomes an impersonation attack. >> >> For mitigating the collaborative attack, either a "sub" claim must be >> present or any combination of other claims allowing for the RS >> to uniquely identify the holder of the access token must be present >> inside an access token, for example OpenID claims like: name, >> family_name, given_name, middle_name, nickname, preferred_username, >> gender, birthdate, email, email_verified, phone_number, >> phone_number_verified or address. >> >> On the contrary, for example, an access token that would only contain a >> claim stating that the holder of the access token is over 21 >> or a birthdate without any claim allowing the RS to uniquely identify >> the legitimate holder of the access token, should not be accepted by the RS. >> >> Under these conditions, it should be observed that the first user might >> be unlikely to be willing to collaborate since the other user would be able >> to perform actions on behalf of the first user and the first user would >> be held responsible of the actions of the second user. >> >> >> >> *Comment on section 4: "Validating JWT Access Tokens" * >> The JWT profile for OAuth 2.0 access tokens >> [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into >> an access token. >> However, this section does not mandate the RS to verify that claims >> allowing for the RS to uniquely identify the holder of the access token >> are indeed be present inside an access token. >> >> It might be useful to add it, so that the above text can refer to it. >> >> Denis >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
