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: [email protected]
[mailto:[email protected]] On Behalf Of Manger, James
Sent: Monday, February 24, 2014 10:49 PM
To: [email protected]
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
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
_______________________________________________
security mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-security
