[35737] in Kerberos
Re: Challenging clients, why another ping-pong?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Tue Feb 4 06:58:37 2014
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <52EFDF70.7020604@mit.edu>
Date: Tue, 4 Feb 2014 12:58:13 +0100
Message-Id: <E677F32F-D217-4C3D-88A7-0A9834320860@openfortress.nl>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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
