Subject: kerberos-revisions: krb_priv and initialization vectors

From: Ken Raeburn <[email-masked]>
Date: Fri, 2 Jun 2000 22:03:49 -0400 (EDT)

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.

Ken
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]