applied cryptography - protocols, algorithms, and source code in c

Previous table of contents next certificates the

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: r knew his secret key and could decrypt the ticket and therefore the authenticator. The client and the server can encrypt future messages with the shared key, if desired. Since only they share this key, they both can assume that a recent message encrypted in that key originated with the other party. Kerberos Version 4 The previous sections discussed Kerberos Version 5. In the messages and the construction of the tickets and authenticators, Version 4 is slightly different. In Kerberos Version 4, the five messages looked like: 1. Client to Kerberos: 2. Kerberos to client: c, tgs {Kc, tgs, {Tc, tgs}Ktgs}Kc 3. Client to TGS: {Ac, s}Kc, tgs, {Tc, tgs}Ktgs, s 4. TGS to client: {Kc, s, {Tc, s}Ks}Kc, tgs 5. Client to server: {Ac, s}Kc, s, {Tc, s}Ks Tc, s = {s, c, a, v, l, Kc, s}Ks Ac, s = {c, a, t}Kc, s Messages 1, 3, and 5 are identical. The double encryption of the ticket in steps 2 and 4 has been removed in Version 5. The Version 5 ticket adds the possibility of multiple addresses, and it replaces a “lifetime” field, l, with a beginning and ending time. The Version 5 authenticator adds the option of including an additional key. Security of Kerberos Steve Bellovin and Michael Merritt discussed several potential security vulnerabilities of Kerberos [108]. Although this paper was written about the Version 4 protocols, many of their comments also apply to Version 5. It may be possible to cache and replay old authenticators. Although timestamps are supposed to prevent this, replays can be done during the lifetime of the ticket. Servers are supposed to store all valid tickets to prevent replays, but this is not always possible. And ticket lifetimes can be long; eight hours is typical. Authenticators rely on the fact that all the clocks in the network are more or less synchronized. If a host can be fooled about the correct time, then an old authenticator can be replayed without any problem. Most network time protocols are insecure, so this can be a serious problem. Kerberos is also vulnerable to password-guessing attacks. An intrude...
View Full Document

Ask a homework question - tutors are online