Creating a new pre-authentication plugin

[Greg Hudson]

On 08/02/2012 03:44 AM, Alejandro Perez Mendez wrote:
> Anyway, COOKIEs must be protected (i.e. encrypted), thus clients cannot
> modify data inside.

There's a limit to how well a cookie can be protected without state.
You can wrap it with a timestamp in an authenticated encryption token
to prevent fabrication of cookies by clients, but cookie values can
still be played back to the KDC multiple times within the window of the
timestamp.  You don't want to leave open memory attacks like:

  C: AS request (no preauth)
     (KDC creates sec context)
  K: Error reply (preauth needed) w/ cookie pointer to sec context
  C: AS request (preauth, cookie)
     (sec context is complete; KDC deletes it)
  K: AS reply
  C: Replay AS request (preauth, same cookie)
     (KDC accesses sec context which is no longer valid)

A single KDC could, of course, maintain a table of cookies which are
still valid.  But that's state, and has the same problem in a multi-KDC
environment as any other kind of state.

(Sam has suggested in the past that perhaps KDC implementations should
evolve using distributed multi-master DBs.  But that makes some
connectivity assumptions which I'm pretty sure are false in some
environments.  Also, I think the distributed databases you'd use either
perform too poorly for the KDC workload, or rely on eventual consistency
guarantees which aren't strong enough to get the security properties you
want.  That's kind of a big research topic.)