Howard Chu hyc@symas.com writes:
Russ Allbery wrote:
True. The problem is that the Heimdal behavior is arguably wrong from a security standpoint. Once the ticket has expired, all products of that ticket should be treated as expired; otherwise, someone who's Kerberos principal has been revoked can continue to access services past the expiration of their ticket, which violates the Kerberos security model.
Perhaps, but it adheres to the Unix security model - that is, once you have access to a resource, you can use it until you're done with it. Likewise, slapd will not terminate connections for clients that are currently bound but whose credentials have subsequently been disabled, by whatever means. And, the per-connection group ACL caching means that whatever group privileges you had at the start of your session remain yours, even if someone removes you from various groups while your connection is active.
Yeah, I understand this perspective.
I've talked to Sam Hartman about the difference between MIT Kerberos's and Heimdal's behavior in the past, and I'm fairly sure that MIT Kerberos will never support continuing to use a GSSAPI context from an expired ticket because he believes it's the wrong thing to do in the Kerberos security model (although someone should double-check my understanding of that position with him before taking this as gospel). Rekeying is what everyone agrees is the Right Thing To Do. (For example, the latest GSSAPI patches for ssh rekey the session when the ticket changes locally, and as a special bonus, reforwards your credentials if delegation is enabled.)
It's possible to establish a new SASL security context on an existing LDAP session, just by starting a new SASL Bind.
The hard part is that the SASL layer itself can't know that the protocol will support that, so I think you need some sort of expiration callback at the SASL library layer that LDAP can hook into and provide the necessary higher-level protocol glue.
The SASL library could only handle this internally if there was something it could do entirely at the GSSAPI layer to rekey the connection without bothering the application, and that doesn't really fit either the GSSAPI or SASL API model where the calling application has control over all network traffic.
It's hard to get the glue to work right without making the application aware of the status of the ticket cache, which ideally it shouldn't have to know about.