[security] OIC self-issued mode is insecure

[Mike Jones]

Rather than using "," as the delimiter, a less arbitrary choice would be to use an agreed-upon legal JWK representation of the key as the value to be hashed.  So, for instance, for an RSA key the "sub" could be:
    BASE64URL(SHA-256('{"kty":"' || sub_jwk.kty || '","n":"' || sub_jwk.n || '","e":"' || sub_jwk.e || '"}'))
and the "sub" for an EC key could be:
    BASE64URL(SHA-256('{"kty":"' || sub_jwk.kty || '","crv":"' || sub_jwk.crv || '","x":"' || sub_jwk.x || '","y":"' || sub_jwk.y || '"}'))

Anyway, Pam's right that we should move discussion of this to the working group list so that a decision can be made.  I'll send a summary there later this morning, or you can do that, Nat.

				-- Mike

-----Original Message-----
From: openid-security-bounces at lists.openid.net [mailto:openid-security-bounces at lists.openid.net] On Behalf Of n-sakimura
Sent: Sunday, March 02, 2014 11:02 PM
To: openid-security at lists.openid.net
Subject: Re: [security] OIC self-issued mode is insecure

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.
_______________________________________________
security mailing list
security at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-security