Challenging clients, why another ping-pong?

Rick van Rein rick at openfortress.nl
Thu Feb 6 08:42:43 EST 2014


Hi Nico,

Thanks for your extensive response!

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

In my RFC 4599 it says "The initial WWW-Authenticate header will not carry any gssapi-data.” and I was wondering if I missed some cryptographic reason to delay the challenge until later.

The reason I dislike it is that it causes a second submission and, if a ticket is not deemed sufficient proof that the sender actually _is_ the sender, another.  That’s three HTTP submissions, possibly with a body attached.  Dramatically inefficient.

Of course the sender does need to prove who he is… just sending a ticket is not using the session key and may therefore be the result of wiretapping.

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

Hmmm, I wonder if that would end up in implementations.  I have more quarrels with SPNEGO, among others that it does not incorporate anything from the HTTP context, so it makes no statement about its context *except* inasfar as can be deduced from its carrier protocol.

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

That *is* interesting, if they are public I’d love to see the pointers.  To be honest, I’m trying to understand the implications of SPNEGO.  As more often in the Kerberos world, I’m finding that there’s a lot of implied knowledge and assumptions.  Stuff like needing to trust the carrier protocol for binding the header-implied trust to whatever surrounds it.

> API compatibility and protocol interoperability must be maintained.

Of course ;-) but a more clever way could have been devised.  Alas, you’re working on SPNEGO extensions yourself, so clearly you understand my drift.

> OK, you're thinking about privacy protection for the initiator's
> identity.

Ehm, yes, I’d like to retain the authenticity that goes with a ticket.  Hence, the need I feel to challenge the request, the worries about the surrounding code and replay issues.  I am well aware that it all depends on accurate clocks too, and we all know how cautious most environments are in that respect.

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

Yep, that’s my conclusion too.  SPNEGO is too light-weight.  Ah well, it didn’t really originate at a security bastion, of course.

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

Who is discussing these matters?  Is this going in in an IETF WG?


Rick van Rein
OpenFortress


More information about the Kerberos mailing list