[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Confusion over MIT/Heimdal compatibility

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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/