Back to index
Limitations of the Kerberos Authentication System
Steven M. Bellovin and Michael Merritt, AT&T Bell Labs
One-line summary: Kerberos IV is widely distributed and
security is becoming more important, so we need to evaluate its limitations
(lack of features) and weaknesses (attack vulnerabilities), given that it's
being used in some systems whose underlying assumptions differed from MIT
Athena's. Some problems are fixed in proposed Kerberos V, but not all,
and others are introduced through new mechanisms that have not been thoroughly
analyzed for security.
Overview/Main Points
Weaknesses/Limitations (version 4 and 5)
- Biggest lose: assumption of secure time system, and resolution of synchronization
required. Could be fixed by challenge-response protocol during auth handshake.
- Password guessing: no authentication is required to request a ticket,
hence attacker can gather equivalent of /etc/passwd by requesting many tickets.
Could be fixed by D-H key exchange.
- Chosen plaintext: in CBC, prefix of an encryption is encryption of a
prefix, so attacker can disassemble messages and use just part of a message.
(Is this true for PCBC?) Doesn't work in Kerberos IV, since the data block
begins with a length byte and a string, destroying the prefix attack.
- Limitation: Not a host-to-host protocol. (Kerberos 5 is user-to-user;
Kerberos 4 is only user-to-server)
Weaknesses in proposed version 5 additions
- Inter-realm authentication is allowed by forwarding, but no way to derive
the complete "chain of trust", nor any way to do "authentication
routing" within the hierarchy of authentication servers.
- ENC_TKT_IN_SKEY of Kerberos 5 allows trivial cut & paste attack
that prevents mutual authentication
- Kerberos 5 CRC-32 checksum is not collision proof (as MD4 is thought
to be)
- K5 still uses timestamps to authentication KRB_SAFE and KRB_PRIV messages;
should use sequence numbers.
Recommendations
- Add challenge/response as alternative to time-based authentication
- Use a standard encoding for credentials (ASN.1), to avoid message ambiguity;
prevents having to re-analyze each change in light of the redundancy in
the binary encodings of various messages as a possible attack point (like
prefix attack above)
- Explicitly allow for handheld authenticators that answer a challenge
using Kc, rather than just using Kc to decrypt a ticket.
- Multi-session keys should be used to negotiate true one-time session
keys
- Support for special hardware (e.g. keystore)
- Don't distribute tickets without some minimal authentication
- No point in including IP address in credentials, since network is assumed
to be evil
Other
- Claim: a "smart card" must understand all of Kerberos, otherwise
if it decrypts a ticket and returns it to the host, keys are exposed. (I
think this is not true for Charon, since we zero out the embedded plaintext
session key of the decrypted ticket, but see below.)
- What if an attacker grabs the authenticator being transmitted from the
client to Charon? This authenticator can be encrypted except for the very
first time the transaction is done, when the secure channel hasn't been
set up yet. I think we should have Ian and/or Steve Bellovin read the Charon
paper.
Relevance
Kerberos IV is widely disseminated, so even the limitations/weaknesses fixed
in version 5 are worth addressing. Also, important to note that, just as
for sof tware correctness, any nontrivial change to the system results in
a whole new system whose security properties must be re-derived "from
first principles", or risk introducing security holes.
Flaws
Some of the limitations in Kerberos IV stem from its initial assumptions
in the MIT Athena environment, and some of the formal techniques for security
verification that lead to the discovery of certain attacks were not widely
known when it was designed. The attacks described on Kerberos 5 suggest
that a thorough verification using formal methods would be wise.
Back to index