Nat, An RP looking for self-issued RSA keys where e is not 65537 would be a cute way to try to detect attacks exploiting this flaw.
It is not a good "work around" to recommend, though. Attacks can still slip through. A self-issued OP using a P-256 elliptic curve, for instance, will expect a 128-bit security level. However, if an RP uses this work around the OP only gets 22-bit security! There is a about a 1 in 2^22 chance that an elliptic curve key can look like an RSA key with e=65537 (ie when the y component ends with ...AQAB). 128-bit to 22-bit is a catastrophic security fall. This work around gives self-issued OPs no way to know if an RP is safe. This work around will be hard to undo so e=65537 may well be fixed forever. That may be mostly harmless, but I am not confident. A better work around is to tell RPs to ignore "sub" (when "iss" is "https://self-issued.me";) and use "sub_jwk" as the account identifier. For RPs that want still want a "sub" value, you could suggest the *RP* changes sub = B64(SHA256(sub_jwk.n + sub_jwk.e)) or B64(SHA256(sub_jwk.crv + sub_jwk.x + sub_jwk.y)) To sub = B64(SHA256(sub_jwk.kty + "," + sub_jwk.n + "," sub_jwk.e)) or B64(SHA256(sub_jwk.kty + "," + sub_jwk.crv + "," + sub_jwk.x + "," + sub_jwk.y)) Or sub = B64(SHA256(JSON.canonical_stringify(sub_jwk))) I'm not sure there is any reasonable work around for self-issued OPs. Using separate keys for each RP helps a bit. I would recommend self-issued OPs omit "sub" from messages; under the assumption (hope) that RP using the flawed spec will reject the login, while RPs that have fixed it will accept the message (as they should ignore "sub", including ignoring its absence). -- James Manger ---------- From: "Nat Sakimura" <[email protected]> Date: Wed, Feb 26, 2014 7:11 pm ... Also, I was wondering if requiring exponent to be selected from small set of candidates or even just requiring one would help. i.e., either e={3, 5, 17, 257, 65537} or e=65537. Some specs requires e>=65537 so just requiring e=65537 is not unreasonable, I think. Also, there is a study [1] that over 95% of the e value used is 65537. Adding the fact that Windows' CAPI only accepts 65537 as e in key generation makes me think that most if not all libraries will accept 65537 as an input value for signature verification that in this particular case of self-issued provider, it would not hart to mandate that e be 65537. Do not you think it would help in the case of RSA? [1] https://eprint.iacr.org/2012/064.pdf _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
