[security] OIC self-issued mode is insecure

[Pamela Dingle]

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 <
James.H.Manger at team.telstra.com> 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" <sakimura at gmail.com>
> 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
> security at lists.openid.net
> 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:* pdingle at pingidentity.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
*Connect with Ping*
Twitter: @pingidentity
LinkedIn Group: Ping's Identity Cloud
Facebook.com/pingidentitypage
*Connect with me*
Twitter: @pamelarosiedee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-security/attachments/20140302/082da731/attachment.html>