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
