On 06/17/2010 05:04 PM, Simo Sorce wrote:
On Thu, 17 Jun 2010 16:39:44 +0400
Eugene Indenbom<eindenbom(a)gmail.com> wrote:
> On 06/16/2010 06:47 PM, Simo Sorce wrote:
>
>> On Wed, 16 Jun 2010 10:43:08 +0400
>> Eugene Indenbom<eindenbom(a)gmail.com> wrote:
>>
>>
>>
>>> 0001-GSSAPI-ticket-expiry-time-is-returned-from-ldap_chil.patch
>>> A small utility patch saving GSSAPI ticket expiry time in
>>> sdap_handle for future use.
>>>
>>>
>> Just an FYI, in a recent meeting with the MIT krb5 folks, it was
>> finally decided to stop breaking GSSAPI sealed connections when the
>> original ticket expires. (Heimdal never did that either).
>>
>>
> That sounds really strange for me. Although it is OK to keep the
> connection on CLIENT side after ticket expiration, the connection
> should be broken on the SERVER side as permission to use the SERVICE
> granted by kerberos TGS is expired and ticket must be renewed before
> the SERVICE is resumed.
>
This is a very long discussion, and the server or even the client app
is entitle to do the check and kill the connection if it is wished.
But ticket expiration does not mean that the peer does not have anymore
access to the service. Whether killing the connection is appropriate or
not is a decision the application (both client and server side) should
make and not something the library should enforce regardless.
That's why the change is being done.
The situation is still unclear: as far as I remember, Cyrrus SASL do not
allow to access GSSAPI credentials. So how server applications are
supposed to handle ticket expiration?
Another thing: as LDAP server definitely should break the connection
after GSSAPI ticket expires, the cached LDAP connection should be
dropped by SSSD regardless of changes made to MIT Kerberos.
I hope that 389-ds team would support dropping expired GSSAPI connection
BEFORE changes to MIT Kerberos implementation become widely available.
Otherwise it will create a substantial hole in DS security.