Creating a new pre-authentication plugin

[Alejandro Perez Mendez]

El 02/08/12 16:25, Greg Hudson escribió:
> 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)

You are right, though I think the flow wouldn't be exactly like that, 
but something similar to:

   C: AS request (no preauth)
   K: Error reply (preauth needed) w/ cookie hint-related cookie
   C: AS request (preauth, cookie)
      (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)


Anyway, I get the point.

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

That's true. I think moving to the alternative of having the 
COOKIE=partially established exported context may be a more feasible  
alternative due to the existing restrictions.