On Wed, 2016-08-24 at 12:35 -0400, Michael B Allen wrote: > On Wed, Aug 24, 2016 at 2:36 AM, Rick van Rein <r...@openfortress.nl> wrote: > > Hey Mike, > > > >> But it would be even better if the client could (or had the option to) > >> do authentication with the service directly and thus eliminate the > >> numerous dependencies for clients (DNS, KDC access, stale tickets, > >> time sync...). > > > > I doubt you could use Kerberos without these components involved. > > You might forego DNS if you configured your client (which is certainly > > not everyone's favourite solution). You need the KDC to obtain a > > short-lasting credential, which is pretty much a cornerstone of > > Kerberos security. The stale tickets and time sync come with that. > > I'm proposing clients use the server as a surrogate for the KDC. So > the server would get a TGT on behalf of the client as well as a > service ticket (for itself) and return it to the client. The client > would then use that service ticket as normal. I understand that this > would all warrant new commands and logic.
The IAKERB mechanism was built for this scenario, but it seem like it didn't really pick up, it worked by tunneling AS requests/replies, so it is not the server that gets your TGT, which would be quite bad in the general case. > Yes, this is all tangential to what you're doing. > > >> I'm not sure if that is possible with HTTP being > >> stateless, but if is, it could be the basis for proper Internet > >> website security as well. > > > > It sounds to me like you are asking about preshared keys, which > > are accepted to be far less secure than the Kerberos road. > > Unfortunately I don't know all the nomenclature so I'll duck this one. The problem is name resolution is still a problem in 2016, mostly because of bad practices everywhere and a DNS system that has always been hard to use for the general public. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
