[391] in Kerberos
Re: Integrity
daemon@TELECOM.MIT.EDU (Steve Miller)
Tue Jun 7 14:41:43 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU, MILLER%erlang.DEC@DECWRL.DEC.COM
The Kerberos tickets are integrity protected, so attempts at modifying
them will be detected via causing invalid values for some/all of the
fields. In this case, the integrity protection is provided by using a
modified cipher-block-chaining modes of DES with the characteristic that
modifying a single bit of ciphertext will cause about 50% of all the
subsequent cleartext bits in the message to change. Then by placing
fields with constraints on their values, such as a timestamp or a constant,
at the end of the message, modification attempts will cause invalid field
values.
If you want to provide integrity protection for rlogin, you will have to
use some integrity mechanism, for example the one used for tickets. But
it is harder to integrate that with a character by character operation,
and it is not obvious how it interacts with the DES generated random
bit stream used for the XOR. DES has an integrity checksum mode, whose
exact name I forgot at the moment, but that requires a separate pass crypto
pass over the data, which is why we picked the technique described above for
the tickets -- no extra crypto.
A basic principle of providing integrity checks is to provide a redundant
copy of the data, usually in the form of a checksum, etc., and include that
in the data stream to be encrypted. Then it is virtually impossible to
modify both the data and its redundant copy in a consistent fashion, as long
as the checksum technique is well chosen. On decryption, the receiver
decrypts, then recomputes the checksum over the cleartext and compares
the computed value to the received value.
This is an interesting problem. Have fun.
Steve
