[486] in Kerberos_Protocol

home help back first fref pref prev next nref lref last post

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)
Message-Id: <200006030203.WAA03140@dcl.mit.edu>
From: Ken Raeburn <raeburn@MIT.EDU>
To: bcn@isi.edu
Cc: krb-protocol@MIT.EDU, ietf-cat-wg@lists.stanford.edu

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

home help back first fref pref prev next nref lref last post