Challenging clients, why another ping-pong?

[Rick van Rein]

Hello Greg,

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

I thought you might say that.  I was looking at SPNEGO, which embeds GSSAPI but where the initiative is (usually) taken by the server.  It’s a waste that SPNEGO doesn’t communicate a challenge at that time.

This is probably the result of embedding protocol into protocol into protocol, but there are no “real” reasons for not sending the challenge that I could think of.

I can imagine other embeddings of Kerberos could do better :)

> 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.

I’m actually not thinking about *mutual* authentication, but otherwise I’d agree of course.

Given that the KDC has told me how to securely communicate with a server, I am thinking about the client proving who he is, and that it is not using a ticket that it observed in transit.  Specifically SPNEGO seems fragile to me for leaked certificates, because the ticket is not used to decrypt anything — authenticaiton is accepted for every first one to provide the right ticket.  (AFAIK)

> 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.

…or the server could hold off client checking the response until it has the authenticated decryption function available — given the random input that’s simply retained, he’d be doing it after the client but with the exact same key material.  Yep, minor :)

-Rick