[4150] in Kerberos
Re: Kerberos V4 -vs- V5
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Tue Nov 8 10:25:32 1994
To: kerberos@MIT.EDU
Date: Tue, 08 Nov 1994 09:40:30
From: mamros@ftp.com (Shawn Mamros)
Reply-To: mamros@ftp.com
mikey@mongo.itg.ti.com writes:
>If this is in a FAQ, please forgive and point me there. I am looking,
>but have been unable to find, a list of the differences between
>version 4 and version 5. Specifically, what changes, functionally, were
>made between the two versions? What got fixed? What got broken? What
>got added?
I'll try to answer this, although this probably shouldn't be regarded
as definitive in any way...
For starters, Kerberos V5 is not simply a "software upgrade" of V4.
It is a completely different protocol, using a completely different
set of data interchange formats, and is not "backwards-compatible"
with V4 at all. Note that does NOT mean that the Kerberos server
or the application clients and servers can't be made to handle both
V4 and V5 - they can (and, in the case of the MIT-supplied KDC server
for V5, it does), but the code needs to be aware of the existence of
both in order to do so. In other words, V5-only clients won't work
with V4-only servers, and vice-versa.
The V5 protocol and data interchange formats allow for more flexibility
and functionality than V4's ever could. Here's just a sampling:
- Support for multiple encryption and checksumming mechanisms
- Stronger default encryption mechanism(s)
- uses random confounder to guard against known-plaintext attacks
- uses checksumming to ensure integrity of encrypted data
- Support for multi-homed, multi-protocol hosts
- Improved principal naming convention
- 40-character restrictions lifted
- multi-part principal names (not just principal.instance) allows for
use of X.500-style names
- full domain names used where applicable - avoids V4 name conflict
problem when a realm spans more than one DNS domain
- Better cross-realm support - key exchange with every other realm for
which cross-realm authentication desired is no longer needed
- Allows application clients and servers to choose own session key, rather
than relying on KDC-supplied one used for authenticators
- Better timestamp and lifetime representations - the protocol itself
imposes no practical upper limit on ticket lifetimes, other than
what the individual KDC implementations choose to impose
- Proxiable/forwardable/renewable tickets
- Pre-authentication optionally required for authentication service (AS)
ticket requests - can be used to guard against password dictionary
cracking-style attacks
- Optional authorization data in tickets and authenticators
- A document (RFC 1510) which provides a "standard" to follow - should help
avoid the nonsense caused by random silly incompatibilities in V4
implementations (like different string-to-key algorithms, different ways
of interpreting ticket lifetimes, differences in principal naming
conventions, etc.)
Note that the current public-domain V5 implementation may not support or
take advantage of all of these features just yet... but the protocol
allows for them.
One other feature provided by the V5 implementation (I forget whether
RFC 1510 mandates their use or not) is the use of replay caches, which
prevent attackers from replaying authenticators or private or safe messages.
Disadvantages? Well, the public-domain V5 code is still considered "beta"
software. It's also much larger than V4 was, but I guess that's somewhat
unavoidable given all of the above "new features" :-).
Hope this helps...
-Shawn Mamros
E-mail to: mamros@ftp.com
