Kerberos and HTTP / HTTPS - Could Kerberos tickets be intercepted and misused?

[Michael B Allen]

On Wed, Aug 24, 2016 at 7:09 PM, Rick van Rein <rick at 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/