On Fri, 7 Feb 2003, Seth Arnold wrote: > The SSL handshake involves computing shared values from random sources > of information. So the handshake will look different with every SSL > connection. By the time that the application's data (login/passwd) is > sent, the two sides have negotiated a new shared key for the connection, > and are using new random initialization vectors, to ensure that > dictionary attacks and reply attacks cannot take place. > > Where SSL and Kerberos make the most sense is when you'd like the > traffic of the session to be private to the two endpoints. Kerberos does > a good job of providing authentication, but does nothing for secrecy of > the established connection. SSL can actually do both authentication and > secrecy, but is lacking the centralized framework of Kerberos.
Kerberos does secrecy as well -- most common Kerberized protocols provide an option to encrypt the entire session after authentication. Look at, for example, the -x and encrypt options to ktelnet. later, chris
