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