Hi,
I'm wondering why krb5_validate defaults to false in sssd-krb5, and apparently it's the same default in the mit kerberos libraries (via verify_ap_req_nofail). It should solve the KDC impersonation attack, at the expense of a slightly more complicated setup (create the host principal, extract key, create keytab). Is it because of this added difficulty in setting up things, or does it not work on very common scenarios/applications? Or just one of those hard to do transitions?
On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote:
Hi,
I'm wondering why krb5_validate defaults to false in sssd-krb5, and apparently it's the same default in the mit kerberos libraries (via verify_ap_req_nofail). It should solve the KDC impersonation attack, at the expense of a slightly more complicated setup (create the host principal, extract key, create keytab). Is it because of this added difficulty in setting up things, or does it not work on very common scenarios/applications? Or just one of those hard to do transitions?
In my option, krb5_validate is broken. It chooses the name on first key in the keytab to attempt validation, rather than either the newest or the one matching ldap_sasl_authid (or an equivalent setting.) This causes issues where a host may have previously had a service principal but it got reassigned to another host, or due to renaming a host without removing the old name from the keytab. (RH support considered it "not a bug.")
V/r, James Cassell
On Mon, Apr 20, 2020 at 10:17:31AM -0400, James Cassell wrote:
On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote:
Hi,
I'm wondering why krb5_validate defaults to false in sssd-krb5, and apparently it's the same default in the mit kerberos libraries (via verify_ap_req_nofail). It should solve the KDC impersonation attack, at the expense of a slightly more complicated setup (create the host principal, extract key, create keytab). Is it because of this added difficulty in setting up things, or does it not work on very common scenarios/applications? Or just one of those hard to do transitions?
Hi,
the main reason why krb5_validate is not enable by default in the krb5 auth provider is basically mentioned below, you need a keytab. Since for plain classical Kerberos authentication a host keytab is not needed and might even not be available the validation is off by default. When using the AD or IPA provider where a keytab is created while joining the domain validation is switched on by default.
In my option, krb5_validate is broken. It chooses the name on first key in the keytab to attempt validation, rather than either the newest or the one matching ldap_sasl_authid (or an equivalent setting.) This causes issues where a host may have previously had a service principal but it got reassigned to another host, or due to renaming a host without removing the old name from the keytab. (RH support considered it "not a bug.")
I think the most straight forward solution here is to add a new option to give a principal which should be used for validation. ldap_sasl_authid is not strictly related, the LDAP code might even use a different keytab than libkrb5 would use for validation.
In general /etc/krb5.keytab should only contain entries which are currently valid. Old entries especially with weak encryption types should be removed. E.g. sshd is using /etc/krb5.keytab for GSSAPI based authentication as well so attackers might be able to use information about the old tickets to get access to your system.
bye, Sumit
V/r, James Cassell _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Tue, Apr 21, 2020, at 4:30 AM, Sumit Bose wrote:
On Mon, Apr 20, 2020 at 10:17:31AM -0400, James Cassell wrote:
On Mon, Apr 20, 2020, at 10:09 AM, Andreas Hasenack wrote:
Hi,
I'm wondering why krb5_validate defaults to false in sssd-krb5, and apparently it's the same default in the mit kerberos libraries (via verify_ap_req_nofail). It should solve the KDC impersonation attack, at the expense of a slightly more complicated setup (create the host principal, extract key, create keytab). Is it because of this added difficulty in setting up things, or does it not work on very common scenarios/applications? Or just one of those hard to do transitions?
Hi,
the main reason why krb5_validate is not enable by default in the krb5 auth provider is basically mentioned below, you need a keytab. Since for plain classical Kerberos authentication a host keytab is not needed and might even not be available the validation is off by default. When using the AD or IPA provider where a keytab is created while joining the domain validation is switched on by default.
In my option, krb5_validate is broken. It chooses the name on first key in the keytab to attempt validation, rather than either the newest or the one matching ldap_sasl_authid (or an equivalent setting.) This causes issues where a host may have previously had a service principal but it got reassigned to another host, or due to renaming a host without removing the old name from the keytab. (RH support considered it "not a bug.")
I think the most straight forward solution here is to add a new option to give a principal which should be used for validation. ldap_sasl_authid is not strictly related, the LDAP code might even use a different keytab than libkrb5 would use for validation.
I agree having a separate option for configuration here would be useful. I'd never considered that ldap might use a different keytab than kerberos. I wonder why that might be done?
In general /etc/krb5.keytab should only contain entries which are currently valid. Old entries especially with weak encryption types should be removed. E.g. sshd is using /etc/krb5.keytab for GSSAPI based authentication as well so attackers might be able to use information about the old tickets to get access to your system.
I agree in principle. Practice is harder, especially when dealing with hundreds of legacy systems... If there's a good/easy way to audit keytabs for weak encryption types, it might be worth pursuing... otherwise, I'll pray that FIPS mode saves the day :P
V/r, James Cassell
sssd-users@lists.fedorahosted.org
-
Andreas Hasenack -
James Cassell -
Sumit Bose