gssapi and replay cache

Marcus Watts mdw at hic-haec-hoc.org
Thu Sep 12 16:44:50 EDT 2013


I have some questions about gssapi and the replay cache.

I've got an application (ganesha.nfsd) where I'm running
out of file descriptors.  For various reasons (which may or
may not be valid) I eventually wind up with many hundreds
of gss_ctx_id_t contexts.  Each context has a replay cache,
and each replay cache has a descriptor open to /var/tmp/nfs_0.
About a dozen of these point to the actual current file on /var/tmp/;
all the rest point to several dozen deleted copies of the same file.
All of these were initialized with gss_accept_sec_context.

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?)
Doesn't gssrpc_sec with sessions, sequence numbers and such
already prevent many of the same kinds of replay attacks?
Clearly there's an "unlink" happening on the replay cache -
I assume that's a side-effect of krb5_rc_dfl_recover_locked().
If all these references really should be to the same file, couldn't
they somehow all be using the same descriptor?

I gather I can disable the replay cache entirely by setting
the environment variable KRB5RCACHETYPE=none but that seems way
heavy-handed.  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.  There's apparently valid NFS
operation sequences that can require keeping a context around
potentially "forever" - so I'd prefer not to have to work around
any unnecessary limits on the # of contexts I have floating around.

For what it's worth, I'm currently using krb5-1.11.3+dfsg-3

				-Marcus Watts


More information about the krbdev mailing list