gssapi and replay cache

[Greg Hudson]

On 09/12/2013 04:44 PM, Marcus Watts wrote:
> So my basic question here is what value is that replay cache 
> actually adding?  Is it actually useful to share one
> replay cache between contexts (is there really an attack
> that can happen between contexts that this is supposed to prevent?)

The only purpose of a replay cache, for GSSAPI usage, is to detect
replayed authenticators.  For that purpose, the replay cache must be
shared between contexts and also between processes.  (For clustered
server deployments, replay caches don't really work, which is one of the
reasons we don't like replay caches and wish we never needed them.)

> Doesn't gssrpc_sec with sessions, sequence numbers and such
> already prevent many of the same kinds of replay attacks?

We don't use the replay cache for per-message tokens.

I am not completely familiar with how gssrpc works.  It is possible that
it inherently doesn't require a replay cache, but that would require
some analysis.  It probably doesn't require a replay cache when acceptor
subkeys are used, but unfortunately that only happens with "newer"
enctypes (AES and later) as I understand the code.

Even if GSSRPC doesn't require a replay cache, if the server key could
be used by another application that does, it needs to write
authenticators to the replay cache in order to make sure that
authenticators sent to the GSSRPC server aren't replayed to the other
server.

> Clearly there's an "unlink" happening on the replay cache -
> I assume that's a side-effect of krb5_rc_dfl_recover_locked().

I am not certain what is causing the unlink in your use case.  Our code
should only unlink the file if krb5_rc_dfl_recover() fails for some
reason--typically if the replay cache doesn't exist.  Is it possible
that you have a tmp cleaner that operates on /var/tmp?

> If all these references really should be to the same file, couldn't
> they somehow all be using the same descriptor?

They could.  We would require global state to coordinate that, which we
ordinarily try to avoid.

I think there is a simpler and more valuable change, which is to destroy
the krb5 auth context (and therefore the replay cache handle) when we
finish establishing a context, either on the initiator side or the
acceptor side.  We don't use the krb5 auth context outside of
{init,accept,delete}_sec_context.c and ser_sctx.c (and there's no value
in including the auth context during serialization of completed GSS
contexts).

(Note that if a gss_cred_id_t is used to initiate or accept the sec
context, the replay cache handle is bound to the cred rather than the
context, and would persist until the GSS cred is destroyed.)

> I should also be able to identify gss_ctx_id_t
> that have expired tickets and reap those, if I can get at the
> ticket expiration timestamp.

gss_inquire_context() should give you the remaining lifetime of the
ticket used to establish the context--0 if it has expired.