Hey all, I'm not sure everyone in the Connect WG follows this list -- suggest we get it into the WG mailing list so it is visible to all the participants, and into bitbucket as a tracked issue, if it isn't already (I haven't seen the notice come through but may have just missed it).
On Thu, Feb 27, 2014 at 4:50 PM, Manger, James < [email protected]> wrote: > 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 > -- *Pamela Dingle* | Sr. Technical Architect *Ping**Identity* | www.pingidentity.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *O:* 303-999-5890 *M:* 303-999-5890 *Email:* [email protected] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - *Connect with Ping* Twitter: @pingidentity LinkedIn Group: Ping's Identity Cloud Facebook.com/pingidentitypage *Connect with me* Twitter: @pamelarosiedee
_______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
