in Kerberos_Protocol
kerberos-revisions: krb_priv and initialization vectors
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Fri Jun 2 22:04:16 2000
Date: Fri, 2 Jun 2000 22:03:49 -0400 (EDT)
From: Ken Raeburn <raeburn@MIT.EDU>
Cc: krb-protocol@MIT.EDU, email@example.com
The RFC1510 description of KRB_PRIV provides for the possibility of
using a non-default IVEC -- which "might come from the last block of
the ciphertext from the previous KRB_PRIV message" but is not required
to -- at the application's request when encrypting KRB_PRIV messages.
The kerberos-revisions draft says no such thing. The descriptions of
the cryptosystems generally indicate the IVEC that "must" be used if
another one isn't specified, which implies that KRB_PRIV *must* use
the default IVEC always. Is this an intentional new restriction?
Relating to this--
* The 3des-kd definition gives "ciphertext" as the encryption output
plus the hash value. The "glossary of terms" defines ciphertext as
the output of encryption. Either we need to use a different term,
or define it so as to make it clear that more than simple encrypted
bits may be included.
* Since the "ciphertext", when it includes a checksum, may not be a
multiple of the basic encryption algorithm's block size, it can't
be divided into full-sized blocks. So "last block of the
ciphertext" isn't a very precisely defined term anyways at this
point. I would take it to mean the last <blocksize> octets, but
implicit in that is the notion that you're counting "blocks" from
the end, not the beginning.