[security] OIC self-issued mode is insecure

[n-sakimura]

Hi James,

Sorry for a tardy reply. I was travelling back to Tokyo, then got sick 
over the weekend.

Your email reminded me of how it was designed in the beginning.

The sub creation was based on the public keys solely to create 
more-or-less globally unique string which is short enough that would not 
overflow "sub" field prepared for the standard case. The authentication 
was meant to be done by the public key, which is going to be stored in 
the RP.

Then, the statlessness requirment kicked in and ended up with an 
authentication scheme that compares the sub and the public key provided. 
(This, by itself, is a bit problematic since we can now not rotate the 
private key, but statelessness took precidence.)

Also, when I first wrote it, it was using PEM for the public key format. 
Though it would still have the key rotation problems, it would not have 
the problem you have pointed out. However, it was later swapped to JWK. 
Now, we are having this problem.

For the time being, as you suggested, using public key itself to 
identify the user would be the way to go.

In the mean time, though it is my personal opinion only, an errata 
process should be started.

By the way, is there a particular reason to use "," as the delemiter?

Nat

(2014/02/28 9:50), Manger, James 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
>


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信 
することを意図しております。意図された受取人以外の方によるこれらの情報の 
開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メール 
を受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受 
信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended 
for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby 
notified that any review, dissemination, distribution or duplication of 
this message is strictly prohibited. If you have received this message 
in error, please notify the sender immediately and delete your copy from 
your system.