Bug 1431586 (rhel75-cyrus-sasl-kerberos)
| Summary: | GSSAPI mechanism does not correctly report or calculate SSF values for Kerberos | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Daniel Berrangé <berrange> |
| Component: | cyrus-sasl | Assignee: | Jakub Jelen <jjelen> |
| Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.4 | CC: | dzheng, jjelen, nmavrogi, pkis, ssorce |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | cyrus-sasl-2.1.26-22 | Doc Type: | Enhancement |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-04-10 13:18:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1472956 | ||
| Bug Blocks: | 1431589, 1476743 | ||
Related upstream work here: https://github.com/krb5/krb5/pull/625 And the cyrus-sasl side here: https://github.com/cyrusimap/cyrus-sasl/pull/429 Now merged upstream. Can we get it into 7.5 ? Ok added, I hope I did it right. 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.