[1091] in Kerberos_V5_Development
First draft of krb5/rfc1510 differences document
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Wed May 1 19:47:18 1996
Date: Wed, 1 May 1996 19:45:37 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krbdev@MIT.EDU
Cc: DEEngert@anl.gov, mullan_s@apollo.hp.com, walt@osf.org
Cc: sommerfeld@apollo.hp.com, bcn@isi.edu, linn@cam.ov.com
Cc: Alain Lavoie <allavoie@qc.bell.ca>
The following is a document documenting the differences between the
RFC-1510 specification, and the MIT implementation of Kerberos V5, with
some recommendations of how to address these differences. I invite your
comments.
I believe all of the technical details in this paper are correct,
although I need to do some more checking, particular with respect to the
DCE implemntation.
Cliff, could you please forward this to an appropriate person at
Cybersafe, and let me know who that person should be? Thanks!! I would
appreciate knowing what the compatibility issues are with respect to
Cybersafe's product and implementation.
- Ted
Differences between RFC-1510 and MIT Implementations.
=====================================================
A. Encryption Algorithms
A.1 DES-CBC-CRC
================
Used as default encryption algorithm by DCE, Beta 4, and Beta
5. It is used to encrypt tickets, authenticators, etc.
Differs from RFC-1510 in that it uses its key as the IV,
instead of zero IV.
Proposed deposition of difference: Deprecate use of
DES-CBC-CRC in RFC-1510bis. However, also document how most
implementations have implemented DES-CBC-CRC (with IV=key) and suggest
that implementations who wish to implement this deprecated encryption
algorithm continue to use the incorrect formulation for backwards
compatibility.
A.2 DES-CBC-MD4
================
<not implemented>
A.3 DES-CBC-MD5
================
Required to be supported by RFC-1510 as a mandatory encryption
algorithm. Supported by Beta 5 and Beta 6, but NOT by beta 4.
Required by RFC-1510.
Currectly implemented.
B. Checksum Algorithms
B.1 CRC-32
===========
In general, used as the mk_req checksum by Beta 4pl3.
Required by RFC-1510.
Correctly implemeted.
B.2 RSA-MD4
============
Used as default kdc_req_symtype by DCE
Used as default kdc_req_sumtype by Beta 5
Currectly implemented.
B.3 RSA-MD4-DES
================
Used as default (authcontext) cksumtype by Beta 5 and Beta 6.
i.e., it used for mk_safe, mk_req checksums, etc. In general used as
mk_safe checksum by Beta 4pl3, including for kprop.
Differs from RFC-1510 in the following ways:
1) does not include a confounder
2) does not xor the key with 0xF0F0F0....
3) uses the key as the IV, instead of a zero IV
This is true in all released distributions derived from MIT.
Some private development snapshots released by MIT only have problem
#3; Cygnus K5 CNS Release 96Q1 also only has problem #3.
Proposed solution #1: Change code to emit the correct
checksum, but verify old and new checksums (distinguished by the
length). This has the effect of breaking compatibility between kprop
and kpropd; a *new* kpropd will not be able to interoperate with a
*old* kprop. This happens the most frequently when user sets up a new
KDC, and then attempts to propagate the database from the old KDC to
the new KDC using kprop. There may be other incompatibilities based
on other programs using mk_safe/rd_safe. However, there are no known
applications (other than kprop) which use mk_safe today.
Proposed solution #2: Change the implementation to accept old
and new checksums, but continue sending the old (incorrect) checksum.
Allocate a new checksum type number for RSA-MD4-DES, and in
RFC-1510bis, deprecate the old checksum type number.
Proposed (preferred) solution #3: Same as #2, except deprecate
use of MD4-DES in RFC-1510bis in favor of MD5-DES. Do not allocate a
new checksum type number for RSA-MD4-DES. (Note: for mk_req
checksums, we should be using an unkeyed MD5 checksum anyway.)
B.4 DES-MAC
============
Required by RFC-1510.
Used by GSSAPI only. Also used internally by DCE for
non-Kerberos protocol messages.
Differs from RFC-1510 in that the key is used as the IV
instead of using a zero IV.
Proposed solution #1: change the implementation to emit the
correct checksum, and accept the correct or incorrect checksum. With
the publication of the GSSAPI Krb5 mechanism to proposed draft, the
mechanism specification mandates a change in the OID for other easons.
Use the new OID to mean use DES-MAC correctly, and use the old OID to
mean do things the old (incorrect) way.
Proposed (preferred) solution #2: same as #1, except continue
to emit the incorrect checksum, and allocate a new checksum type which
is guaranteed to do things correctly.
B.5 DES-MAC-K
===============
<not implemented by MIT>
Note: required to be implemented by RFC-1510.
B.6 RSA-MD4-DES-K
==================
<not implemented by MIT>
B.7 RSA-MD5
============
Used as default by KDC_REQ_SUMTYPE in Beta 6.
Implemented correctly. In RFC-1510bis, this should be mandatory.
B.8 RSA-MD5-DES
================
Required by RFC-1510.
Not used by any known code.
Differs from RFC-1510 in the following ways:
1) does not include a confounder
2) does not xor the key with 0xF0F0F0....
3) uses the key as the IV, instead of a zero IV
This is true in all released distributions derived from MIT.
Some private development snapshots released by MIT only have problem
#3; Cygnus K5 CNS Release 96Q1 also only has problem #3.
Proposed solution #1: Change code to emit the correct
checksum, but verify old and new checksums (distinguished by the
length). This will cause no known incompatibility, since no known
implementations are actually using this checksum type.
Proposed (prefered) solution #2: Change the implementation to
accept old and new checksums, but continue sending the old (incorrect)
checksum. Allocate a new checksum type number for RSA-MD5-DES, and in
RFC-1510bis, deprecate the old checksum type number. This should
eventually be the default checksum for mk_safe checksums.
