On Wed, Aug 24, 2016 at 7:09 PM, Rick van Rein <r...@openfortress.nl> wrote: > Hey, > >>> To be clear, the whole point of what I'm proposing is that the client >>> would have ZERO dependencies. Being able to do proper auth and then >>> get a TLS session that uses the crypto context established during auth >>> instead of traditional certificate would be a big deal. > > The general idea of IAKERB is that client-KDC traffic can travel over an > unprotected link, which might involve the server. It is still important > however, to have the long-term secret (the "password") established between > client and KDC to base the trust on.
Yes, the password would be required to get a service ticket. But it would get it through the server and once it has a ticket it can skip using the password for some time. More specifically, the client would open a TCP connection to the IP of the server, messages would be exchanged in a secure fashion using the password "to base the trust on", the resulting crypto context would be used instead of a traditional certificate for the TLS session and finally the client gets a service ticket that it can use to skip password authentication for 10 hours. But, again, the point is that the client would not be "joined" to a domain, it would not be required to have network access to a KDC, time on the client would not matter, the user would not necessarily have to run the client application in the context of the principal (meaning they would not have to "login" as a specific user first), the client would not have to do fancy SRV queries to find the right KDC and the client would not submit huge tickets with every single request. Mike -- Michael B Allen Java Active Directory Integration http://www.ioplex.com/ ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
