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

[Rick van Rein]

Hi,

> The HTTP/Negotiate protocol unfortunately does not prevent replay
> attacks, so It can be done if the other endpoint does not use a replay
> cache.
>
HTTP/Negotiate is indeed so sad that we've been working on an
alternative, that is to integrate Kerberos + Diffie-Hellman into TLS. 
Then, once you get TLS going for your HTTPS, you would have established
mutual trust and perfect forward secrecy.

This is work in active progress:
 - we're removing the last bugs from the GnuTLS-extension on
http://github.com/arpa2/gnutls-kdh
 - we hope to integrate the KDH branch into the TLS Pool soon from
https://github.com/arpa2/tlspool/tree/tls-kdh
 - we're preparing a HTTPS proxy on
https://github.com/arpa2/tlspool/blob/master/tool/https_proxy.py
 - we've got a generic TLS wrapper on
https://github.com/arpa2/tlspool/blob/master/tool/tlstunnel.c
 - we'll soon release a successor to
https://tools.ietf.org/html/draft-vanrein-tls-kdh-04

We also have plans for automatic realm crossover including client
identity pseudonymity.

But, alas, this is not ready to roll out yet.  We're still finishing the
work as we speak.


Cheers,

Rick van Rein
for the InternetWide.org / ARPA2.net project