gssapi and replay cache

[Will Fiveash]

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
http://www.ietf.org/rfc/rfc2203.txt 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