Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Feature: The cyrus-sasl GSSAPI plugin can query the SSF value for kerberos.
Reason: The cyrus-sasl GSSAPI plugin was using hardcode value 56 for SSF, which no longer reflects reality.
Result: The cyrus-sasl reports correct SSF values for GSSAPI mechanism with kerberos.
Description of problem:
Libvirtd uses the SASL library to provide authentication, and optionally session encryption. When using the GSSAPI mechanism it is possible to request a minimum security level for the session encryption by setting the 'min_ssf' parameter in the SASL_SECPROPS property. After negotiation takes place it is possible to query the actual security level via the SASL_SSF property.
Except these appear to be mostly hardcoded lies in the GSSAPI mechanism. The 'min_ssf' is does not appear to be checked against the actual kerberos security properties, rather the code checks against a compile time constant K5_MAX_SSF.
if (secprops->min_ssf > (K5_MAX_SSF + external)) {
return SASL_TOOWEAK;
Similarly when querying the SSF value it reports a fixed constant
/* FIX ME: Need to extract the proper value here */
oparams->mech_ssf = K5_MAX_SSF;
This constant is defined as follows
#ifdef WANT_KERBEROS5_3DES
/* Check if CyberSafe flag is defined */
#ifdef CSF_GSS_C_DES3_FLAG
#define K5_MAX_SSF 112
#endif
/* Heimdal and MIT use the following */
#ifdef GSS_KRB5_CONF_C_QOP_DES3_KD
#define K5_MAX_SSF 112
#endif
#endif
#ifndef K5_MAX_SSF
/* All Kerberos implementations support DES */
#define K5_MAX_SSF 56
#endif
Where 112 corresponds to the value for 3DES, while 56 corresponds to single-DES. So even if Kerberos is using the much strong AES-256 algorithm, SASL is at best going to report its SSF as 112, and if the app puts a min-SSF of greater than 112 in order to try to force use of AES-256, the auth request will fail.
This really limits the ability of applications like libvirtd to accurately control or report the SSF security options.
Version-Release number of selected component (if applicable):
cyrus-sasl-2.1.26-21
How reproducible:
Always
Steps to Reproduce:
1. Set min_ssf to 128 for SASL_SECPROPS
2. Negotiate a GSSAPI w/ Kerberos5 SASL handshake with session encryption, against a krb5 server/client using AES-256
3. Set min_ssf to 56 for SASL_SECPROPS
4. Try step 2 again
Actual results:
When min_ssf is set to 128, it will fail to complete a GSSAPI handshake due to too weak SSF, even if krb is using AES-256
When using min_ssf and querying the actal SSF it reports the hardcoded 56 / 112 value.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0777
Description of problem: Libvirtd uses the SASL library to provide authentication, and optionally session encryption. When using the GSSAPI mechanism it is possible to request a minimum security level for the session encryption by setting the 'min_ssf' parameter in the SASL_SECPROPS property. After negotiation takes place it is possible to query the actual security level via the SASL_SSF property. Except these appear to be mostly hardcoded lies in the GSSAPI mechanism. The 'min_ssf' is does not appear to be checked against the actual kerberos security properties, rather the code checks against a compile time constant K5_MAX_SSF. if (secprops->min_ssf > (K5_MAX_SSF + external)) { return SASL_TOOWEAK; Similarly when querying the SSF value it reports a fixed constant /* FIX ME: Need to extract the proper value here */ oparams->mech_ssf = K5_MAX_SSF; This constant is defined as follows #ifdef WANT_KERBEROS5_3DES /* Check if CyberSafe flag is defined */ #ifdef CSF_GSS_C_DES3_FLAG #define K5_MAX_SSF 112 #endif /* Heimdal and MIT use the following */ #ifdef GSS_KRB5_CONF_C_QOP_DES3_KD #define K5_MAX_SSF 112 #endif #endif #ifndef K5_MAX_SSF /* All Kerberos implementations support DES */ #define K5_MAX_SSF 56 #endif Where 112 corresponds to the value for 3DES, while 56 corresponds to single-DES. So even if Kerberos is using the much strong AES-256 algorithm, SASL is at best going to report its SSF as 112, and if the app puts a min-SSF of greater than 112 in order to try to force use of AES-256, the auth request will fail. This really limits the ability of applications like libvirtd to accurately control or report the SSF security options. Version-Release number of selected component (if applicable): cyrus-sasl-2.1.26-21 How reproducible: Always Steps to Reproduce: 1. Set min_ssf to 128 for SASL_SECPROPS 2. Negotiate a GSSAPI w/ Kerberos5 SASL handshake with session encryption, against a krb5 server/client using AES-256 3. Set min_ssf to 56 for SASL_SECPROPS 4. Try step 2 again Actual results: When min_ssf is set to 128, it will fail to complete a GSSAPI handshake due to too weak SSF, even if krb is using AES-256 When using min_ssf and querying the actal SSF it reports the hardcoded 56 / 112 value.