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.
Do you have any comments or explanation on the issue? Is there any
forum or mailing list where this problem is discussed?
The MIT krbdev mailing list would be a place to discuss that.
> This means that in future we will not need to check for this
> expiration time because the connection will not drop.
> Current libraries of course still do that, so we may have to keep
> doing something about this problem for people using older MIT
> libraries.
>
>
As you can see from previous e-mails and related tickets, handling of
GSSAPI ticket expiration is only one (and from my point of view least
important) item, I am trying to resolve by submitted patches.
I know, I just wanted to comment on that specific issue in light of
this recent decision from MIT Kerberos.
Simo.
--
Simo Sorce * Red Hat, Inc * New York