On Mon, Mar 27, 2017 at 03:08:39PM +0200, Denis wrote: > Hi Nat, > > HI. > > > > As pointed out in saag, the OAuth WG is not dealing with ABC attack. > > It is out of scope for now at least. > > A threat along the ABC attack is not mentioned in RFC 6819 : OAuth 2.0 > Threat Model and Security Considerations (2013). > Hence, nobody attempted to find a solution ... for a threat that had not > been identified. > > draft-ietf-oauth-token-binding-02 is a document form the OAuth WG. Since > this threat has not been identified in RFC 6813, > it does not contain any proposal to counter that threat. However, this > threat is now identified. Should this threat be addressed > by sticking our heads in the sand ?
I am not sure that everyone in this conversation agrees on the same definition of "threat model" that is in use. The definition that I am using involves choosing a specific set of attacker capabilities to attempt to counter, and explictly does not include considering an all-powerful attacker or considering all conceivable potential "threats". That is to say, the discovery of a new potential threat need not necessate a modification to the threat model, as the new threat may require an attacker capability against which we are not trying to defend. -Ben > A basic property of the current Token Binding mechanisms being developed > both by the OAuth WG and the Token Binding WG > is that a specific piece of software voluntarily installed by a client > can export any token and perform all the needed computations > so that any token can successfully be usedby another client. It is NOT > the replay of a token, since the token is not used at any > time by the legitimate owner, but is used by an illegitimateuser. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
