[security] OIC self-issued mode is insecure

[Mike Jones]

Hi James,

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.

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

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.)

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.

I and the other working group definitely appreciate you finding this issue.  Please keep reporting anything else you may find!

				Best wishes,
				-- Mike

-----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