[security] OIC self-issued mode is insecure

Wed Feb 26 00:48:19 UTC 2014

Mike,

> Thanks for bringing this to our attention.  I agree with you that it
> would have been far better to have delimiters between the fields. The
> working group will investigate whether this actually creates an
> actionable attack surface or not, and if so, what action to take.
> 
> In the RSA case, I think this hinges on whether implementations would
> accept or reject keys and exponents with unusual sizes and values.  For
> instance, your first example modification creates a 2050 bit key and an
> 8 bit exponent whose value is 0 (since "AB") base64url decodes to a
> single zero-valued byte.  RSA libraries might reject 2050 bit keys and
> might reject an exponent of zero, or they might not.  That may be part
> of the working group's investigation.  I suspect that if the exponent
> is an empty string, that would almost certainly be rejected.  (Of the
> other possible shortened exponent strings, "QAB" results in an exponent
> of 16384 and "B" is not a legal base64url encoded string.)
> 
> Your second modification creates a key of less than 2048 bits, and so
> would be rejected by the JOSE minimum key size requirements.  It might
> be possible to shift bits from a 4096 bit key to the exponent, but
> again, investigation is needed whether enlarged exponents and non 2^N-
> length keys would be used or rejected.

A JOSE spec rule that RSA keys MUST be 2048 or larger will hopefully be heeded by most JOSE producers. I very much doubt it will be enforced by JOSE receivers (and I don't want to rely on that).

> Having implementations verify that RSA key lengths are powers of two
> seems like it could be one mitigation.

I don’t think so. There are 1536-bit keys (just as historically there were 768-bit keys). I’m sure some will pick 3072-bit keys.
Also, many supposedly 2048-bit keys are actually 2047-bit keys (still a product of two 1024-bit primes). Reject those and you will break things.

> I'm less worried about the Elliptic Curve case, since the two parts of
> the key must be of the same size and the parts are represented as
> fixed-length bit strings.  There's no way to move bits between the two
> parts.  (You could potentially move bits from the "crv" to the "x"
> field, but only if the truncated curve name was still a valid curve,
> and all the current curve names are of the form P-
> <digit><digit><digit>, so this wouldn't be the case.)

An elliptic curve will not save you. An attacker can use an RSA key that gives the same "sub" value as an EC key (it might have a rather short modulus, but that makes it easier to factor ;).

   "sub_jwk": {
     "kty":"RSA",
     "n": "P-256gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0
           SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFp",
     "e": "ps"
    }

> I'm not saying that the current design is ideal or perhaps shouldn't be
> changed.  All I'm saying is that I think some further investigation is
> warranted before deciding.

While the calculation of "sub" if fixed, how about NOT including it in the message? "sub" MUST be re-calculated from "sub_jwk" for security. The presence of "sub" can only entice implementations to ignore this MUST.

Mind you, this whole concept of a self-issued OP that only works in implicit mode and requires a key pair to be kept forever feels like a strange add-on to the rest of OpenID Connect.

> I and the other working group definitely appreciate you finding this
> issue.  Please keep reporting anything else you may find!
> 
> 				Best wishes,
> 				-- Mike

--
James Manger

> -----Original Message-----
> From: openid-security-bounces at lists.openid.net [mailto:openid-security-
> bounces at lists.openid.net] On Behalf Of Manger, James
> Sent: Monday, February 24, 2014 10:49 PM
> To: openid-security at lists.openid.net
> Subject: [security] OIC self-issued mode is insecure
> 
> OpenID Connect Core 1.0 section 7 "Self-Issued OpenID Provider" looks
> quite insecure.
> 
> The subject identifier "sub" (that RPs will use as the identifier for
> an account) is calculated from a hash of the concatenation of n & e
> (for an RSA key). However, the boundary between n & e is not preserved.
> Hence there are lots of other public keys that will give the same
> "sub". Using any of these other keys will allow an attacker to
> impersonate the user of this self-issued OP. These other keys do not
> have the same security as the user's real key.
> 
> The example from the spec is below:
> 
>   {
>    "iss": "https://self-issued.me",
>    "sub": "wBy8QvHbPzUnL0x63h13QqvUYcOur1X0cbQpPVRqX5k",
>    "aud": "https://client.example.org/cb",
>    "nonce": "n-0S6_WzA2Mj",
>    "exp": 1311281970,
>    "iat": 1311280970,
>    "sub_jwk": {
>      "kty":"RSA",
>      "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
>      4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
>      tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
>      QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
>      SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
>      w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgw",
>      "e":"AQAB"
>     }
>   }
> 
> The same "sub" results even if the key (sub_jwk) is changed as follows
> to have a public exponent of 0. That makes it easy to sign! "AQ" is
> moved from the start of the "e" to the end of "n".
> 
>    "sub_jwk": {
>      "kty":"RSA",
>      "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
>      4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
>      tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2
>      QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
>      SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
>      w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgwAQ",
>      "e":"AB"
>     }
> 
> The same "sub" also results from the following key that has a modulus
> half the size (hence far far less security). Half the modulus is moved
> to the exponent.
> 
>    "sub_jwk": {
>      "kty":"RSA",
>      "n": "0vx7agoebGcQSuuPiLJXZptN9nndrQmbXEps2aiAFbWhM78LhWx
>      4cbbfAAtVT86zwu1RK7aPFFxuhDR1L6tSoc_BJECPebWKRXjBZCiFV4n3oknjhMs
>      tn64tZ_2W-5JsGY4Hc5n9yBXArwl93lqt7_RN5w6Cf0h4QyQ5v-65YGjQR0_FDW2",
>      "e":
> "QvzqY368QQMicAtaSqzs8KJZgnYb9c7d0zgdAZHzu6qMQvRL5hajrn1n91CbOpbI
>      SD08qNLyrdkt-bFTWhAI4vMQFh6WeZu0fM4lFd2NcRwr3XPksINHaQ-G_xBniIqb
>      w0Ls1jF44-csFCur-kEgU8awapJzKnqDKgwAQAB"
>     }
> 
> There are similar problems with elliptic curve keys, or even with
> replacing an elliptic curve key with a weak RSA key that gives the same
> "sub".
> [If we had a canonical form of JSON we could hash that, otherwise...
> include the key type and some delimiters]
> 
> --
> James Manger
> 
> _______________________________________________
> security mailing list
> security at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-security