9:02 a.m.
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#{{TERM[expand]Kerberos}}
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.
--
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
11:19 a.m.
--On Tuesday, April 15, 2008 5:02 PM +0100 Dominic Hargreaves
<dominic.hargreaves(a)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
11:50 a.m.
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.
1:32 p.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:15 p.m.
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.
2:31 p.m.
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/
2:39 p.m.
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.
6:11 a.m.
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
7:41 a.m.
--On Monday, April 21, 2008 3:11 PM +0200 Tim Tassonis <timtas(a)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
11:45 a.m.
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(a)u.washington.edu
12:41 p.m.
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.
--
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
5020
days inactive
5026
days old
openldap-software@openldap.org
10 comments
6 participants
participants (6)
-
Dominic Hargreaves -
Donn Cave -
Howard Chu -
Quanah Gibson-Mount -
Simon Wilkinson -
Tim Tassonis