gssapi and replay cache

Will Fiveash will.fiveash at
Fri Sep 13 16:18:40 EDT 2013

On Fri, Sep 13, 2013 at 01:44:32AM -0400, Greg Hudson wrote:
> 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

Is "gssrpc_sec" equivalent to RPCSEC_GSS?  If so states:

"The RPCSEC_GSS protocol provides for protection from replay attack,
 yet tolerates out-of-order delivery or processing of messages and
 tolerates dropped requests."

That RFC also describes how the server maintains sequence numbers that
prevent replay.

Will Fiveash
Oracle Solaris Software Engineer

More information about the krbdev mailing list