Subject: LAST CALL COMMENT KCRYPTO general

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 15 Aug 2003 21:58:22 -0700

Ken, Nicolas, Sam, Paul, JK, and I were discussing various issues in
GSSAPI support for AES during the last few weeks, we made great progress
and the discussions were extremely productive.  It became evident that
we need to recall this kcrypto draft.  Here I outline some issues that
need to be addressed by kcrypto:

1)	the need of AEAD support. It is very common that a message has
some portions of it in clear text but signed, others encrypted. The
clear text portions are used primarily for one of the two reasons: a)
the data is used for bootstrapping purposes, such as setting up keys to
decrypt the encrypted data, thus need to be in clear text.  b) the data
only need to be signed and it has better performance that way.  Without
AEAD, applications that use the Kerberos crypto framework would have to
do "home grown" tactics, which is at best inefficient, or worse
error-prone.  Ken has expressed that it is technically straightforward
for kcrypto to support AEAD.  Paul Leach at Microsoft has gracefully
offered to lend a hand upon request.  It is worth noting that an
immediate application for AEAD is that we can use it to protect the
token header for Wrap() tokens.
2)	 More attributes are needed for the profiles to minimize
ambiguity and improve efficiency. For example, not knowing if Decrypt()
can return the precise length of the application data has been proven
awkward, we might need to encode the length information un-necessarily
for encryption types such as AES. In addition, not knowing the block
size of underlying ciphers might compromise efficiency unnecessarily.
These might be OK if Encrypt() is only used to encrypt ASN encoded data,
but appear to be less desirable for GSSAPI.  With AEAD, most of the
"meta-data" information can be put in clear text, thus it could be less
problematic.

Thx. Larry