Re: Confusion over MIT/Heimdal compatibility

[Simon Wilkinson <simon@sxw.org.uk>]

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.