An "agreed-upon legal JWK representation" is a reasonable approach for RPs. Putting the JWK member names in alphabetical order would be the best rule, as it is not limited to the 2 current key types. Will this be in addition to self-issued OPs not sending "sub"?
-- James Manger > -----Original Message----- > From: [email protected] [mailto:openid-security- > [email protected]] On Behalf Of Mike Jones > Sent: Monday, 3 March 2014 6:34 PM > To: n-sakimura; [email protected] > Subject: Re: [security] OIC self-issued mode is insecure > > 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: [email protected] [mailto:openid-security- > [email protected]] On Behalf Of n-sakimura > Sent: Sunday, March 02, 2014 11:02 PM > To: [email protected] > 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 _______________________________________________ security mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-security
