[security] OIC self-issued mode is insecure

[Mike Jones]

OPs would still send "sub", since the pair ("iss", "sub") is the universal account identifier for OpenID Connect.  It would just be computed in the specified manner.

				-- Mike

-----Original Message-----
From: Manger, James [mailto:James.H.Manger at team.telstra.com] 
Sent: Monday, March 03, 2014 2:37 PM
To: Mike Jones; n-sakimura; openid-security at lists.openid.net
Subject: RE: [security] OIC self-issued mode is insecure

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: openid-security-bounces at lists.openid.net 
> [mailto:openid-security- bounces at lists.openid.net] On Behalf Of Mike 
> Jones
> Sent: Monday, 3 March 2014 6:34 PM
> To: n-sakimura; openid-security at lists.openid.net
> 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: 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