On Mon, Jun 19, 2006 at 02:30:45PM -0500, Nicolas Williams wrote: > On Mon, Jun 19, 2006 at 01:31:21PM -0400, Sam Hartman wrote: > > I was intrigued by Phil Hallam-Baker's idea to separate HTTP > > authentication into two parts : one between a user and some > > authentication/identity service and one between the authentication > > service and the relying party. [...] > > Gosh, that sounds like a ticketing service... Like Kerberos, actually. > > Or we could make a ticketing service out of PKIX technologies. Or out > of SAML/XMLdsig/XMLenc. Or something totally new! > > Or we could try to re-use specs. > > :) > > Yes, I see why you suggest Kerberos. > > One argument I've seen against Kerberos is that it requires online > infrastructure, but I think it's now clear that all the good choices in > this space do (e.g., PKIX CRL and OCSP servers, online CAs, SACRED > servers, etc.).
However, not all good choices in this space have such tight time sychronization constraints as kerberos does. I think any proposal for digital identity based on kerberos needs to also propose some mechanism for relaxing the synchronized clock constraints that all the existing kerberos implementations I am aware of impose. I would really like to be able to use kerberos as a mechanism for authenticating to a wireless mesh network. But in practice, some percentage of the time there will be some node that has a fast or slow running clock, or just got rebooted and has a clock set to 2004. If you can solve authentication with a device with a fast or slow running clock, then maybe we could make this same infrastructure useable for some future deep space network in which relativistic effects on clocks and time start making a difference. I suppose the real question I am asking is can kerberos be securely extended to use relative timestamps instead of absolute timestamps, or does this somehow fundamentally break the security model? _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
