Re: Help with SASL/GSSAPI to remote Kerberos server

[Russ Allbery <rra@stanford.edu>]

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.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>