Replies: 3 comments 12 replies
-
|
Keys was initially designed to have a single use to prevent any potential vulnerabilities around multiple uses of the same keys. However, I've been trying to think of a potential way keys that are used both of sign and enc could be a vulnerability, but haven't been able to come up with any issues there. If memory serves me right this came a bit out of the RSA/HMAC vulnerability in JWKs, but that's when a key is used for different algorithms, rather than different uses. There's still something that bothers me slightly about this, but can't provide any evidence, other than JWK specs do not permit multiple values for use. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not aware of any vulnerabilities around multiple uses of the same keys either. However, if the realm administrator chooses to use the same key for both signing and encryption, it would be easier to define the key once and specify the different uses instead of having to define the same key multiple times, one per use. The spec, defines: By default, a realm gets intialized with 2 distinct RSA keys: one for "sig" and one for "enc". then the result of the Just for comparison, with the current vanilla keycloak v15.0.2, if we add another rsa key for "sig" and also another one for "enc", and end up with this: then the same call to the jwks endpoint, gives you the following output: We submit a pull request with this change, to share this with the community |
Beta Was this translation helpful? Give feedback.
-
|
The pull request for the pr proposal 1 can be found here |
Beta Was this translation helpful? Give feedback.
-
@stianst your concern is valid and key reuse is not a recommended practice. For reference, I suggest the reading of The Dangers of Key Reuse: Practical Attacks on IPsec IKE. Even though we don't have any practical attacks against Keycloak, that's something to keep in mind. |
Beta Was this translation helpful? Give feedback.
-
|
I think the largest issue might come up in the future. If a key can have multiple uses what will prevent a key from being used for multiple algorithms in the future when we have to upgrade Keycloak to utilize a newer algorithm to prevent a, currently unknown, attack on RS256? Using a key for enc and sig (in the case of RSA) is not a problem but it might be a problem for future algos. |
Beta Was this translation helpful? Give feedback.
-
|
I’ve read the paper. Indeed, there is a chance that someone might perform a Bleichenbacher attack on the IKE, but the flaw they describe is actually in protocol(s) where there is a need to perform a key exchange. Is this really affecting the use of the same key in encryption and signing of let’s say SAML assertions? That’s something i'm missing. Checking the bibliography about that, i stumbled upon this nice presentation which includes some relevant research (published papers) on using the same RSA keys for encryption and signatures. However, what we propose, is not going to affect the existing default setup: each realm is always initialized with a different rsa key for encryption and signing. Whether extending the use of one of them to both uses, is a decision of the keycloak admin (should be on purpose changed from the admin UI). This can be already done in the existing vanilla keycloak by just duplicating the key for the other use. I personally believe that more problems arise from choosing to use legacy cryptosystems, rather than from reusing the same key in enc and sig. For instance, see here |
Beta Was this translation helpful? Give feedback.
-
|
Just to confirm.. We all agree that unique keys per-use is the ideal? However, in practice that's not always practical, and end of the day may not make much difference from a security perspective? |
Beta Was this translation helpful? Give feedback.
-
|
The confirmation popup makes it more obvious for sure, but perhaps a bit too intrusive. I'm okay with just making it clear in the tooltip. |
Beta Was this translation helpful? Give feedback.
-
|
+1 and makes sense to add that as a tooltip that's not something recommended. |
Beta Was this translation helpful? Give feedback.
-
|
Added to the tooltip (see file Attributes.java ) the following text: |
Beta Was this translation helpful? Give feedback.
-
|
Language hint: rather than not prohibited it should read not forbidden (Prohibited is by law) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tip jbman! I'll update the text as suggested! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Base PR for key uses
Additional PR for key protocol uses
Motivation:
Currently, Keycloak allows an administrator to define multiple keys of different type and priority, along with an intended use (for signing or encryption). Moreover, the current design allows the keys to be used exclusively for one use, either signing (sig) or encryption (enc). So, in case an admin has a RSA-256 key marked for sig, but wishes to use the same key for enc as well, he/she needs to duplicate this key value, which is not efficient.
Furthermore, it is currently not possible to configure different keys per authentication protocol, e.g. SAML, OpenID Connect (OIDC), kerberos, etc. For instance, SAML and OIDC certificates typically have different rotation requirements, i.e. in SAML every 10 years while in OIDC every 6 six months. So, we would like to propose an extension to allow the realm administrator to use different keys for each protocol.
Proposal:
We plan to contribute our changes in two pull requests:
Pull request 1:
So, for the first one, we change the exclusiveness of each key’s use for either “enc” or “sig”, and -instead- assign a list of uses for each key i.e. [“enc”, “sig”].
So, if an admin needs to use an existing key for more than one use, he/she just needs to add the appropriate use tag for that key, instead of replicating the whole key which requires more effort and is error-prone.
To achieve that, few changes are required:
Here’s a screenshot of the modified field (UI).
Pull request 2:
In the second pull request, we add support for different key uses by (auth) protocol. We plan to add an additional field (i.e “protocol-use”), having the same tagging design as the sig/enc use, but assigning a list of “permitted to use” with protocols.
Of course, as with the sig/enc modification, we
Protocol values should exist as an enum in the java code. For instance, the protocol enumerations could be {“oidc”, “saml”, “kerberos”, … , “other”}
For backwards compatibility in case of upgrades, if this new field is missing, it’ll be considered as “all”, but of course, the admin can easily edit it by adding the desired value(s).
Additional details and examples:
IMPORTANT: If keys are also linked to a protocol type (oidc, saml, kerberos, etc), without having multi-value fields, then the combinations escalate quickly, since an admin should need to define M*N keys, with M the # of uses {sig,enc} and N the # of protocols {oidc, saml, kerberos, ldap, ...}
So, instead of having a list of RS256 keys (for sake of simplicity, we omit HMAC, AES and ECDSA)
by using multi-value fields, an admin will be able to define the equivalent:
being able to add/remove tags from the “use” and “protocol” lists.
Currently, upon initialization (or realm creation), keycloak checks if the minimum required keys for keycloak to work exist in the realm, and if not, generates them.
With the proposed tagging scheme, keycloak will only need to check for one key of each type rsa,hsa,etc and assign the minimum tags required to work.
So, by default it would generate something like this for each new realm (including the “master”):
If an admin would like to change the RSA key for -let’s say- ldap, he should edit the existing row by removing the ldap tag from the rsa protocol list
and create a new entry with
Beta Was this translation helpful? Give feedback.
All reactions