[524] in Kerberos
Re: Ticket Authentication
daemon@TELECOM.MIT.EDU (Steve Miller)
Wed Nov 2 10:59:31 1988
From: miller%erlang.DEC@DECWRL.DEC.COM (Steve Miller)
To: kerberos@ATHENA.MIT.EDU
(** This may be a duplicate, may mailer returned it to me claiming unsent. *)
This message is in response to Ted Anderson's mail of Oct 18, 1988.
I agree that the problem with the pcbc_encrypt should be fixed. However,
it is not a backwards compatible fix, and any tickets outstanding or
data stored encrypted with the old pcbc will be trashed.
There are a number of ways to fix it. You could add a DES MAC, quad_cksum,
CRC, or some other form of checksum computed over the cleartext message.
The checksum would then be encrypted as part of the message (ticket).
But any of the checksum or MAC type approaches both cost time for the
checksum computation, which is very significant in the case of a DES MAC,
and cost additional encryption overhead by lengthening the ticket.
I would therefore recommend fixing it by fixing the pcbc_encrypt routine
to properly detect swapped blocks. Basically, we got it wrong, but I don't
feel bad since the same wrong solution was published by others as well.
I talked to one of our crypto experts, and came up with a variation
that seems to work. The basic difference is that when encrypting block N,
instead of XORing the cleartext from block N-1 with the CLEARTEXT
for block N prior to encrypting block N, the cleartext from block N-1
is XORed with the CIPHERTEXT resulting from encrypting block N. I have
attached a schematic describing this at the end of this message. I hacked
up a version of this, and tried it out, and it did successfully detect
swapped ciphertext blocks and other modifications, propagating the errors
thru to the end of the decrypted cleartext.
In terms of the redundancy of the ticket, I believe that it is more than
adequate, given a fix to pcbc as outlined above. Ted's note underestimates
the effective redundancy in the ticket, since there are strong semantic
constraints on the values contained in the tickets above and beyond the fact
that the strings are null terminated, the key has parity, etc.
So I would not include a checksum. When encrypting arbitrary data with no
known semantic constraints a checksum/MAC should be used, but Kerberos
tickets are not in this category.
The server name in the ticket provides more than just redundancy. Without
it, if two different servers (or instances) happened to use the same master
key, and I got a ticket for one, it would also be valid at the other.
Since master keys are derived from strings typed in by people, it is likely
that multiple servers (or instances) would have the same key, especially
if an administrator is responsible for multiple servers.
Steve
Legend:
let P0...Pn represent blocks of plaintext
let C0...Cn represent blocks of ciphertext
let XOR be the XOR operation
let E be the DES ECB Encrypt operation
let D be the DES ECB Decrypt operation
let IV be the initialization vector
let K be the DES session key.
---------------------------------------------------------------------------
New pcbc encrypt, also detects misordered ciphertext blocks and insertions
P0 >-+ P1
| | |
| | |
v | v
IV --> XOR | +----->XOR
| | | |
| | | |
v | | v
K ---> E | | K -->E
| | | |
| | | |
v | | v
0 --> XOR +---|----->XOR
| | |
| | |
v | v
C0 >----+ C1
==============================================================================
Decrypt
C0 >-+ C1
| | |
| | |
v | v
0 --> XOR | +----->XOR
| | | |
| | | |
v | | v
K ---> D | | K -->D
| | | |
| | | |
v | | |
IV -->XOR +---|----->XOR
| | |
| | |
v | v
P0 >----+ P1
