Hello.
I've configured domain membership for one linux server, and now I'm trying to understand one thing. I can't figure out how SASL-GSSAPI encrypts LDAP requests and GC interactions. As long as I understood Kerberos, it's a protocol solely for authentication, and SASL-GSSAPI gives it ability to encrypt all data transactions between authenticated hosts. But this encryption is not mandatory. I've done several queries via 'id' utility to generate traffic, and captured it. All I can see is LDAP traffic to 389/tcp and 3268/tcp, which is encrypted. I can decrypt it by loading host's keytab to Wireshark. We've disabled anonymous and insecure binds (without integrity checking or SSL/TLS encryption) in AD, and didn't adjust minssf/maxssf parameters on Linux. As long as I understood, AD does not require whole session encryption, neither does Linux. All authentication is done in SSSD (authconfig --enablesssd --enablesssdauth).
To summarize: I want to understand, why SASL-GSSAPI encrypts whole connection and not just auth phase, so I could be sure that one day all connections wouldn't appear in plaintext on the network. If I had more experience in programming, I've could find the answer in source code (all hail to opensource) to fullfill my curiosity, but unfortunately I can't do that, so I'll appreciate any help/hints/links on the topic.
Kind regards.
On 08/28/2015 06:25 PM, l@avc.su wrote:
Hello.
I've configured domain membership for one linux server, and now I'm trying to understand one thing. I can't figure out how SASL-GSSAPI encrypts LDAP requests and GC interactions. As long as I understood Kerberos, it's a protocol solely for authentication, and SASL-GSSAPI gives it ability to encrypt all data transactions between authenticated hosts. But this encryption is not mandatory. I've done several queries via 'id' utility to generate traffic, and captured it. All I can see is LDAP traffic to 389/tcp and 3268/tcp, which is encrypted. I can decrypt it by loading host's keytab to Wireshark. We've disabled anonymous and insecure binds (without integrity checking or SSL/TLS encryption) in AD, and didn't adjust minssf/maxssf parameters on Linux. As long as I understood, AD does not require whole session encryption, neither does Linux. All authentication is done in SSSD (authconfig --enablesssd --enablesssdauth).
To summarize: I want to understand, why SASL-GSSAPI encrypts whole connection and not just auth phase, so I could be sure that one day all connections wouldn't appear in plaintext on the network. If I had more experience in programming, I've could find the answer in source code (all hail to opensource) to fullfill my curiosity, but unfortunately I can't do that, so I'll appreciate any help/hints/links on the topic.
Kind regards. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
GSSAPI supports both authentication and encryption. It is a part of the standard. Please check GSSAPI documentation for more details. It is unfortunate that not many people use this encryption capability and know about it. Leveraging this encyption for the whole session allows avoiding use of the TLS for session confidentiality which requires additional overhead in dealing with certificates when there is really no need to do so. As it is a part of standard, I do not see a reason why suddenly your traffic would become plain text ever.
Dmitri Pal писал 2015-08-29 01:35:
On 08/28/2015 06:25 PM, l@avc.su wrote:
Hello.
I've configured domain membership for one linux server, and now I'm trying to understand one thing. I can't figure out how SASL-GSSAPI encrypts LDAP requests and GC interactions. As long as I understood Kerberos, it's a protocol solely for authentication, and SASL-GSSAPI gives it ability to encrypt all data transactions between authenticated hosts. But this encryption is not mandatory. I've done several queries via 'id' utility to generate traffic, and captured it. All I can see is LDAP traffic to 389/tcp and 3268/tcp, which is encrypted. I can decrypt it by loading host's keytab to Wireshark. We've disabled anonymous and insecure binds (without integrity checking or SSL/TLS encryption) in AD, and didn't adjust minssf/maxssf parameters on Linux. As long as I understood, AD does not require whole session encryption, neither does Linux. All authentication is done in SSSD (authconfig --enablesssd --enablesssdauth).
To summarize: I want to understand, why SASL-GSSAPI encrypts whole connection and not just auth phase, so I could be sure that one day all connections wouldn't appear in plaintext on the network. If I had more experience in programming, I've could find the answer in source code (all hail to opensource) to fullfill my curiosity, but unfortunately I can't do that, so I'll appreciate any help/hints/links on the topic.
Kind regards. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
GSSAPI supports both authentication and encryption. It is a part of the standard. Please check GSSAPI documentation for more details. It is unfortunate that not many people use this encryption capability and know about it. Leveraging this encyption for the whole session allows avoiding use of the TLS for session confidentiality which requires additional overhead in dealing with certificates when there is really no need to do so. As it is a part of standard, I do not see a reason why suddenly your traffic would become plain text ever.
Hi Dmitri. I've got couple of evenings to follow your advice, and I have interesting results. First of all, I've found out how SASL negotiates security of the context. In short: http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/sasl.intro-44/inde... (just picks the max value both side can use) This bothered me the most, cause I need to understand how can I disable 'switching to plain' accidentally or on purpose. And it really could happen if someone set 'maxssf=1' in ldap.conf, so I just need to specify ldap_sasl_minssf=56 in sssd.conf, or SASL_SECPROPS minssf=56 in ldap.conf.
Although I havent found any 'system-wide' setting for SASL, I still can configure it per-application.
Thank you for good responce and pointing me to right direction.
Here's couple of links that I found useful: http://tools.ietf.org/html/rfc2743 http://cyrusimap.org/docs/cyrus-sasl/2.1.23/gssapi.php http://docs.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html
On Sun, Aug 30, 2015 at 12:03:47PM +0300, l@avc.su wrote:
Dmitri Pal писал 2015-08-29 01:35:
On 08/28/2015 06:25 PM, l@avc.su wrote:
Hello.
I've configured domain membership for one linux server, and now I'm trying to understand one thing. I can't figure out how SASL-GSSAPI encrypts LDAP requests and GC interactions. As long as I understood Kerberos, it's a protocol solely for authentication, and SASL-GSSAPI gives it ability to encrypt all data transactions between authenticated hosts. But this encryption is not mandatory. I've done several queries via 'id' utility to generate traffic, and captured it. All I can see is LDAP traffic to 389/tcp and 3268/tcp, which is encrypted. I can decrypt it by loading host's keytab to Wireshark. We've disabled anonymous and insecure binds (without integrity checking or SSL/TLS encryption) in AD, and didn't adjust minssf/maxssf parameters on Linux. As long as I understood, AD does not require whole session encryption, neither does Linux. All authentication is done in SSSD (authconfig --enablesssd --enablesssdauth).
To summarize: I want to understand, why SASL-GSSAPI encrypts whole connection and not just auth phase, so I could be sure that one day all connections wouldn't appear in plaintext on the network. If I had more experience in programming, I've could find the answer in source code (all hail to opensource) to fullfill my curiosity, but unfortunately I can't do that, so I'll appreciate any help/hints/links on the topic.
Kind regards. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
GSSAPI supports both authentication and encryption. It is a part of the standard. Please check GSSAPI documentation for more details. It is unfortunate that not many people use this encryption capability and know about it. Leveraging this encyption for the whole session allows avoiding use of the TLS for session confidentiality which requires additional overhead in dealing with certificates when there is really no need to do so. As it is a part of standard, I do not see a reason why suddenly your traffic would become plain text ever.
Hi Dmitri. I've got couple of evenings to follow your advice, and I have interesting results. First of all, I've found out how SASL negotiates security of the context. In short: http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/sasl.intro-44/inde... (just picks the max value both side can use) This bothered me the most, cause I need to understand how can I disable 'switching to plain' accidentally or on purpose. And it really could happen if someone set 'maxssf=1' in ldap.conf, so I just need to specify ldap_sasl_minssf=56 in sssd.conf, or SASL_SECPROPS minssf=56 in ldap.conf.
You have to set minssf on the server-side to make sure that only properly encrypted connections are accepted by the server, see e.g. http://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictio... for an explanation how this can be done with the 389ds LDAP server.
On the client side SSSD by default use the settings from ldap.conf which is used by all other OpenLDAP based LDAP client programs as well. If you want to make sure that at least SSSD uses a secure connection you can additionally set ldap_sasl_minssf in sssd.conf.
HTH
bye, Sumit
Although I havent found any 'system-wide' setting for SASL, I still can configure it per-application.
Thank you for good responce and pointing me to right direction.
Here's couple of links that I found useful: http://tools.ietf.org/html/rfc2743 http://cyrusimap.org/docs/cyrus-sasl/2.1.23/gssapi.php http://docs.oracle.com/javase/jndi/tutorial/ldap/security/sasl.html
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sumit Bose писал 2015-08-31 12:01:
On Sun, Aug 30, 2015 at 12:03:47PM +0300, l@avc.su wrote:
Hi Dmitri. I've got couple of evenings to follow your advice, and I have interesting results. First of all, I've found out how SASL negotiates security of the context. In short: http://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/sasl.intro-44/inde... (just picks the max value both side can use) This bothered me the most, cause I need to understand how can I disable 'switching to plain' accidentally or on purpose. And it really could happen if someone set 'maxssf=1' in ldap.conf, so I just need to specify ldap_sasl_minssf=56 in sssd.conf, or SASL_SECPROPS minssf=56 in ldap.conf.
You have to set minssf on the server-side to make sure that only properly encrypted connections are accepted by the server, see e.g. http://directory.fedoraproject.org/docs/389ds/howto/howto-use-ssf-restrictio... for an explanation how this can be done with the 389ds LDAP server.
On the client side SSSD by default use the settings from ldap.conf which is used by all other OpenLDAP based LDAP client programs as well. If you want to make sure that at least SSSD uses a secure connection you can additionally set ldap_sasl_minssf in sssd.conf.
HTH
bye, Sumit
Hi Sumit.
Thank you for the info. I've already set ldap_sasl_minssf in sssd.conf, and in ldap.conf Since I'm using Microsoft AD, I can't specify minssf on the server side.
I've found couple of corresponding parameters in ldap.conf that contols GSSAPI: GSSAPI_SIGN <on/true/yes/off/false/no> GSSAPI_ENCRYPT <on/true/yes/off/false/no>
Although any of combinations seems to have no effect on SSSD.
Thank you for the tip.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
l＠avc.su -
Sumit Bose