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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
