[19379] in Kerberos_V5_Development
Re: replay of service tickets
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 16 11:16:47 2016
To: Sorin Manolache <sorinm@gmail.com>, krbdev@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <56E978D2.2040207@mit.edu>
Date: Wed, 16 Mar 2016 11:16:34 -0400
MIME-Version: 1.0
In-Reply-To: <56E92881.6000804@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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@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.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
