replay of service tickets

[Sorin Manolache]

Hello,

My apologies if it is not the right mailing list for asking this question.

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

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.

Next, the Client invokes the Backend and passes the obtained service ticket.

The Backend executes

gss_accept_sec_context().

The Client<->Authentication Server and Client<->Backend are HTTP. The
Client is oblivious to the fact that the data item it receives/sends is
a kerberos service ticket. For it it's just opaque data, so the Client
uses no GSS/Kerberos stack.

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?

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.

Which implementation obeys the standard? The Java one or the MIT GSS
stack? Are both approaches correct and is it just a matter of
configuring the two stacks?

Thank you in advance,
Sorin
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Sorin Manolache
My apologies if it is not the right mailing list for asking this question.

The right list is ***@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.

Post by Sorin Manolache
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.

Post by Sorin Manolache
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.

Post by Sorin Manolache
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.

Post by Sorin Manolache
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 ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev