replay of service tickets

[Greg Hudson]

On 03/16/2016 05:33 AM, Sorin Manolache wrote:
> My apologies if it is not the right mailing list for asking this question.

The right list is kerberos at mit.edu, but I'll go ahead and answer here.
krbdev is for collaboration between developers of MIT krb5, while
kerberos is appropriate for discussions about any Kerberos implementation.

> I have a system consisting of an Authentication Server, a Backend and a 
> Client.

This terminology is a little confusing, as "Authentication Server" is a
Kerberos term indicating one of the functions of the KDC (see RFC 4120).
 But I can still follow.

> The Client first invokes the Authentication Server.
> 
> The Authentication Server executes
> 
> gss_acquire_cred()
> gss_init_sec_context()
> 
> As a result, it obtains a kerberos service ticket that it sends to the 
> Client.

"Kerberos service ticket" is again a technical term.  It would be more
correct to say that the client obtains a GSS-API context initialization
token for the krb5 mech.  This token contains a Kerberos service ticket,
but also contains an authenticator encrypted in the ticket session key.
 RFC 4120 section 5.5.1 shows what is in an authenticator; most
importantly for this conversation, it contains a client timestamp.

> Assuming that the service ticket expires in N seconds, may the Client 
> perform several requests to the Backend using the same service ticket 
> (that is without making new requests to the Authentication Server) 
> during the N seconds until the ticket expiration?

It may not.  First of all, authenticators basically "expire"
immediately; they are only accepted for the five-minute window of clock
skew, and that window may be shorter than five minutes if the server's
clock is a bit faster than the client's (or it may be longer if the
server's clock is slower).  Second, servers may implement a replay cache
so that the same authenticator won't be accepted more than once.

> I'm asking the question because I have two backends with two GSS stacks. 
> The backend with the binary GSS stack of MIT accepts the ticket several 
> times with no error. The second backend uses a Java GSS stack. It 
> accepts the ticket once but if I attempt a second request with the same 
> ticket then I get an exception indicating that I'm trying to replay the 
> ticket which it does not accept. Apparently the Java stack "remembers" 
> the ticket and rejects requests if it finds the ticket in its cache.

MIT krb5 does implement a replay cache (although it has a number of
problems), so I wouldn't expect the same token to work multiple times.
However, it's possible that the server application disables the replay
cache for performance reasons.

I don't know much about the Java GSS stack.  From what you say, it
sounds like it also implements a replay cache.