Hello,
I'm in the process of deploying an OpenLDAP cluster with a (simple) syncrepl configuration, using Kerberos GSSAPI authentication between the slaves and master. In testing this has worked fine; however the original ticket expires the connection fails without the client noticing. This has already been discussed at the thread ending with
http://www.openldap.org/lists/openldap-software/200608/msg00342.html
so I'm not asking for a rehash of that. However I am puzzled by the discrepancy between the statement "As mentioned on this list numerous times, do *not* use MIT kerberos with OpenLDAP. Bad things happen. Use Heimdal Kerberos." and the advice given at
http://www.openldap.org/doc/admin24/install.html#%7B%7BTERM%5Bexpand%5DKerbe...
which suggests (or at least implies) that MIT kerberos is usable with OpenLDAP.
Is anything likely to change in this regard? Having looked into the issue it does seem that fixing this with MIT kerberos would require (at a minimum) changing the SASL library, and any such change would be a hack, since it doesn't look to the untrained eye like SASL provides a mechanism for getting information about connection lifetimes.
However, I do think it could be made clearer in the docs that MIT kerberos is not suitable for use with OpenLDAP.
[sidenote: I will be taking some of this up with the Debian cyrus-sasl2 maintainers too, as they do not seem to support Heimdal gssapi any more]
Thanks, Dominic.
--On Tuesday, April 15, 2008 5:02 PM +0100 Dominic Hargreaves dominic.hargreaves@oucs.ox.ac.uk wrote:
Is anything likely to change in this regard? Having looked into the issue it does seem that fixing this with MIT kerberos would require (at a minimum) changing the SASL library, and any such change would be a hack, since it doesn't look to the untrained eye like SASL provides a mechanism for getting information about connection lifetimes.
The advice against using MIT Kerberos was more related to thread safety issues than the credential expriation problem. I think the OpenLDAP list is the wrong place to ask what will happen with MIT Kerberos to fix problematic issues related to thread safety. I.e., the problems referenced are not on the OpenLDAP side of things. As for the credential expiration issue, as far as I'm aware, the MIT folks have no desire to change how things behave now. If you don't want to deal with the problem, use a cyrus-sasl linked against Heimdal instead of MIT on your OpenLDAP servers.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On 15 Apr 2008, at 19:19, Quanah Gibson-Mount wrote:
As for the credential expiration issue, as far as I'm aware, the MIT folks have no desire to change how things behave now. If you don't want to deal with the problem, use a cyrus-sasl linked against Heimdal instead of MIT on your OpenLDAP servers.
Unfortunately, I think OpenLDAP needs to fix this problem. Continuing to use a connection past the lifetime of its security context is a bug. Just because Heimdal currently permits it doesn't make it any less of a bug, and if Heimdal fixes its behaviour, OpenLDAP will break. Given that SASL has no way of renegotiating a connection, OpenLDAP needs to detect the connection failure, and close and reopen the connection.
I keep thinking about fixing this - at the moment, we just restart our slave slapds just before their credentials expire.
Cheers,
Simon.
Simon Wilkinson wrote:
On 15 Apr 2008, at 19:19, Quanah Gibson-Mount wrote:
As for the credential expiration issue, as far as I'm aware, the MIT folks have no desire to change how things behave now. If you don't want to deal with the problem, use a cyrus-sasl linked against Heimdal instead of MIT on your OpenLDAP servers.
Unfortunately, I think OpenLDAP needs to fix this problem. Continuing to use a connection past the lifetime of its security context is a bug.
As explained previously on this list, it's a difference in philosophy, not a bug. Heimdal and OpenLDAP follow the Unix philosophy - permission checking is done upon first access to a resource. Once you obtain access to the resource, it's yours until you give it up, no matter what other subsequent permission changes occur while you're using it. You may not like this behavior, but it's consistent and predictable.
You might argue that the MIT approach is more correct, but I would say that it's highly inconsistent, and inconsistency is highly undesirable in a security mechanism. For instance, by your thinking, if you decide that security contexts must all be invalidated whenever and wherever they are changed, then you also need to close all connections whenever somebody changes their password, because any sessions established with the old password must now be considered invalid. The fact that MIT Kerberos doesn't do this should be considered an inconsistency in their implementation, and a security bug.
Ultimately I think the MIT implementation reflects muddy thinking, at multiple levels.
Just because Heimdal currently permits it doesn't make it any less of a bug, and if Heimdal fixes its behaviour, OpenLDAP will break. Given that SASL has no way of renegotiating a connection, OpenLDAP needs to detect the connection failure, and close and reopen the connection.
I keep thinking about fixing this - at the moment, we just restart our slave slapds just before their credentials expire.
Cheers,
Simon.
On 15 Apr 2008, at 21:32, Howard Chu wrote:
As explained previously on this list, it's a difference in philosophy, not a bug. Heimdal and OpenLDAP follow the Unix philosophy - permission checking is done upon first access to a resource. Once you obtain access to the resource, it's yours until you give it up, no matter what other subsequent permission changes occur while you're using it.
I think you're conflating short and long term keys here, along with permission checks and cryptography.
When you're using a SASL security layer, you're (generally) using a cryptographically secured connection of some sort. Many cryptographic protocols have some form of restriction on the length of time you can use a key for. This may be based on the amount of data transmitted, or the designated lifetime of a key. Unfortunately, SASL has no way of communicating these restrictions to the application layer - the only way it can do so is by failing encode and decode operations. In this case, it is currently the applications responsibility to catch this failure, and negotiate a new security context.
You might argue that the MIT approach is more correct, but I would say that it's highly inconsistent, and inconsistency is highly undesirable in a security mechanism. For instance, by your thinking, if you decide that security contexts must all be invalidated whenever and wherever they are changed, then you also need to close all connections whenever somebody changes their password, because any sessions established with the old password must now be considered invalid.
Not at all. My password has no role in protecting that connection once it has been established. A short term encryption key does. Sites may have many reasons for the lifetimes they pick for short term keys and particular algorithms may require lifetime restrictions. Applications which use these keys should respect these wishes. For example, ssh rekeys its connections in accordance with the expiry of the keys which _protect_ that connection (in the ssh case, this isn't the Kerberos key).
However, coming back to OpenLDAP specifics. Whatever the rights and wrongs of the Kerberos particular case, OpenLDAP doesn't handle the situation where sasl_{en,de}code fails. The SASL layer is within its rights to fail these operations, so I believe the fact that this failure breaks syncrepl is a bug.
Simon.
Simon Wilkinson wrote:
On 15 Apr 2008, at 21:32, Howard Chu wrote:
As explained previously on this list, it's a difference in philosophy, not a bug. Heimdal and OpenLDAP follow the Unix philosophy - permission checking is done upon first access to a resource. Once you obtain access to the resource, it's yours until you give it up, no matter what other subsequent permission changes occur while you're using it.
I think you're conflating short and long term keys here, along with permission checks and cryptography.
When you're using a SASL security layer, you're (generally) using a cryptographically secured connection of some sort. Many cryptographic protocols have some form of restriction on the length of time you can use a key for. This may be based on the amount of data transmitted, or the designated lifetime of a key. Unfortunately, SASL has no way of communicating these restrictions to the application layer - the only way it can do so is by failing encode and decode operations. In this case, it is currently the applications responsibility to catch this failure, and negotiate a new security context.
You're presuming that negotiating a new context for the current session is an acceptable action. For Kerberos, there's no way to distinguish between the session key expiring, and the TGT expiring. In the former case, an app can transparently obtain a new service ticket, but in the latter case, the only recovery you can do requires visible user interaction.
You might argue that the MIT approach is more correct, but I would say that it's highly inconsistent, and inconsistency is highly undesirable in a security mechanism. For instance, by your thinking, if you decide that security contexts must all be invalidated whenever and wherever they are changed, then you also need to close all connections whenever somebody changes their password, because any sessions established with the old password must now be considered invalid.
Not at all. My password has no role in protecting that connection once it has been established.
No, but it allowed you to establish the connection in the first place. As such, by your logic, changing it should invalidate the connection.
A short term encryption key does. Sites may have many reasons for the lifetimes they pick for short term keys and particular algorithms may require lifetime restrictions. Applications which use these keys should respect these wishes. For example, ssh rekeys its connections in accordance with the expiry of the keys which _protect_ that connection (in the ssh case, this isn't the Kerberos key).
However, coming back to OpenLDAP specifics. Whatever the rights and wrongs of the Kerberos particular case, OpenLDAP doesn't handle the situation where sasl_{en,de}code fails. The SASL layer is within its rights to fail these operations, so I believe the fact that this failure breaks syncrepl is a bug.
ssh and GSSAPI may be analogous here. In that respect, these layers should renegotiate keys transparently so that upper layers never see it. The fact that SASL doesn't expose lifetime restrictions either means (a) apps aren't supposed to have to worry about them or (b) the SASL design is broken.
On 15 Apr 2008, at 22:31, Howard Chu wrote:
ssh and GSSAPI may be analogous here. In that respect, these layers should renegotiate keys transparently so that upper layers never see it. The fact that SASL doesn't expose lifetime restrictions either means (a) apps aren't supposed to have to worry about them or (b) the SASL design is broken.
Personally, I think the GSSAPI SASL design is broken, in that it doesn't attempt renegotiation. That's something that I know people are working on fixing.
However, all of this is really by the by. The key issue is that sasl_encode and sasl_decode are defined as returning an error code in what passes for the Cyrus SASL API documentation. At the moment, the OpenLDAP code doesn't handle those functions returning anything other than success.
S.
Howard Chu wrote:
You might argue that the MIT approach is more correct, but I would say that it's highly inconsistent, and inconsistency is highly undesirable in a security mechanism. For instance, by your thinking, if you decide that security contexts must all be invalidated whenever and wherever they are changed, then you also need to close all connections whenever somebody changes their password, because any sessions established with the old password must now be considered invalid.
Not at all. My password has no role in protecting that connection once it has been established.
No, but it allowed you to establish the connection in the first place. As such, by your logic, changing it should invalidate the connection.
Sorry, but this is rubbish. By your logic, if one joins a conspirative gathering using a secret password and then is told than in future there is a new secret passphrase, he would then be required to leave the room again an reenter it using the new passphrase. There is absolutely no security value in this, just a small entertainment value perhaps.
Reestablishing expired encryption keys clearly has a security value, due to brute force issues on current connection keys.
But if somebody has brute-forced your initial shared secret to establish the connection an you have changed it in the meantime, he will not be more able to establish a connection if you keep that old connection.
Bye Tim
--On Monday, April 21, 2008 3:11 PM +0200 Tim Tassonis timtas@cubic.ch wrote:
Sorry, but this is rubbish. By your logic, if one joins a conspirative gathering using a secret password and then is told than in future there is a new secret passphrase, he would then be required to leave the room again an reenter it using the new passphrase. There is absolutely no security value in this, just a small entertainment value perhaps.
Reestablishing expired encryption keys clearly has a security value, due to brute force issues on current connection keys.
But if somebody has brute-forced your initial shared secret to establish the connection an you have changed it in the meantime, he will not be more able to establish a connection if you keep that old connection.
I think you just argued for the point Howard was making. We aren't talking about establishing a *new* connection with an old encryption key. We are talking about maintaining a connection once the encryption key has expired. Heimdal lets you do this. MIT does not.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Apr 15, 2008, at 9:02 AM, Dominic Hargreaves wrote:
However, I do think it could be made clearer in the docs that MIT kerberos is not suitable for use with OpenLDAP.
Well, that err on the other side. There are plenty of situations where the MIT implementation is indeed suitable, and since it can be a gigantic hassle to build Heimdal just for slapd when the MIT libraries are already there, there's a cost on either side of over-simplifying this issue.
Donn Cave, donn@u.washington.edu
On Tue, Apr 15, 2008 at 05:02:13PM +0100, Dominic Hargreaves wrote:
[sidenote: I will be taking some of this up with the Debian cyrus-sasl2 maintainers too, as they do not seem to support Heimdal gssapi any more]
Please ignore this part; I misunderstood how the Debian heimdal-gssapi-sasl stuff was built.
Dominic.
openldap-software@openldap.org
-
Dominic Hargreaves -
Donn Cave -
Howard Chu -
Quanah Gibson-Mount -
Simon Wilkinson -
Tim Tassonis