Challenging clients, why another ping-pong?

[Greg Hudson]

On 02/03/2014 09:41 AM, Rick van Rein wrote:
> Looking at SPNEGO (and probably other protocols as well) I see that the server can take the initiative for an GSSAPI exchange, and when doing so, it could already challenge the client.

What are you looking at specifically?  GSSAPI exchanges begin with the
client.

> The way I see it, asking a client to decrypt *anything* is possible, as long as the result is unpredictable to the client of course.  For instance, a random byte series could be created by the server and sent to the client for decryption.  Whatever the block cipher makes of that, is the proper answer; the server can make the same computation when it receives the ticket (with the session key) and the response to the challenge (decrypted with the session key).

Even if the server could speak first in a GSSAPI exchange and provide a
challenge, you would need three legs to achieve mutual authentication
with krb5, because a server cannot authenticate itself to a client
without first receiving a ticket.

Also, the modern incarnation of the krb5 GSS mech is built on RFC 3961,
which does not assume direct access to the block cipher; you get an
authenticated encryption and decryption function instead.  So "please
decrypt this random block of data" would be difficult to fit there.
That's a minor point, though; if the server could speak first with a
challenge, preventing replays would be as simple as incorporating the
server challenge into the authenticator checksum.