Challenging clients, why another ping-pong?

[Nico Williams]

On Tue, Feb 4, 2014 at 5:58 AM, Rick van Rein <rick at openfortress.nl> wrote:
> 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.

GSS-API exchanges always begin with an initial security context token.
 SPNEGO can carry an initial security context token for an
optimistically selected mechanism.

We could extend SPNEGO (or MSFT's NegoEx) to provide a challenge to be
used in some way (there's various GSS-API extensions -some
standardized, some proposed, some implemented-but-not-proposed, where
the challenge could be made available).

What is your goal?  I'm guessing: optimize Kerberos to avoid the need
for a replay cache.  If so, Roland Dowdeswell and I have some
proposals in that space.

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

API compatibility and protocol interoperability must be maintained.
Extensions which when used produce more optimal results are permitted.
 Flag-days are not permitted.

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

OK, you're thinking about privacy protection for the initiator's
identity.  There are better ways to do this, such as building perfect
forward security (PFS) into the mechanisms, into SPNEGO, or else into
a stackable mechanism.  The most likely of these to happen is to build
PFS into the mechanism.  If the initiator knew any sort of public key
that is suitable for encryption to the acceptor, then the client could
use that, PFS or no PFS.

(PFS means, of course, doing something like Diffie-Hellman key
agreement.  If you want the acceptor to be authenticated before the
acceptor is able to see the initiator's Ticket/credentials/name then
you'll want a public DH key to be made available to the initiator by a
trusted third party.)

>> 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 :)

The server clearly has the keys available at the point where an
authenticator checksum could be checked.

Nico
--