1 files changed, 250 insertions, 0 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
new file mode 100644
index 0000000..46a4158
--- /dev/null
+++ b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt
@@ -0,0 +1,250 @@
+
+
+
+
+
+Network Working Group                                        M. Horowitz
+<draft-ietf-cat-kerb-key-derivation-00.txt>             Cygnus Solutions
+Internet-Draft                                            November, 1996
+
+
+                     Key Derivation for Kerberos V5
+
+Status of this Memo
+
+   This document is an Internet-Draft.  Internet-Drafts are working
+   documents of the Internet Engineering Task Force (IETF), its areas,
+   and its working groups.  Note that other groups may also distribute
+   working documents as Internet-Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as ``work in progress.''
+
+   To learn the current status of any Internet-Draft, please check the
+   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
+   Directories on ds.internic.net (US East Coast), nic.nordu.net
+   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
+   Rim).
+
+   Distribution of this memo is unlimited.  Please send comments to the
+   <cat-ietf@mit.edu> mailing list.
+
+Abstract
+
+   In the Kerberos protocol [RFC1510], cryptographic keys are used in a
+   number of places.  In order to minimize the effect of compromising a
+   key, it is desirable to use a different key for each of these places.
+   Key derivation [Horowitz96] can be used to construct different keys
+   for each operation from the keys transported on the network.  For
+   this to be possible, a small change to the specification is
+   necessary.
+
+
+Overview
+
+   Under RFC1510 as stated, key derivation could be specified as a set
+   of encryption types which share the same key type.  The constant for
+   each derivation would be a function of the encryption type.  However,
+   it is generally accepted that, for interoperability, key types and
+   encryption types must map one-to-one onto each other.  (RFC 1510 is
+   being revised to address this issue.)  Therefore, to use key
+   derivcation with Kerberos V5 requires a small change to the
+   specification.
+
+   For each place where a key is used in Kerberos, a ``key usage'' must
+   be specified for that purpose.  The key, key usage, and
+   encryption/checksum type together describe the transformation from
+   plaintext to ciphertext, or plaintext to checksum.  For backward
+
+
+
+Horowitz                                                        [Page 1]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+   compatibility, old encryption types would be defined independently of
+   the key usage.
+
+
+Key Usage Values
+
+   This is a complete list of places keys are used in the kerberos
+   protocol, with key usage values and RFC 1510 section numbers:
+
+      1.  AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the
+          client key (section 5.4.1)
+      2.  AS-REP Ticket and TGS-REP Ticket (includes tgs session key or
+          application session key), encrypted with the service key
+          (section 5.4.2)
+      3.  AS-REP encrypted part (includes tgs session key or application
+          session key), encrypted with the client key (section 5.4.2)
+
+      4.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+          session key (section 5.4.1)
+      5.  TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs
+          authenticator subkey (section 5.4.1)
+      6.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed
+          with the tgs session key (sections 5.3.2, 5.4.1)
+      7.  TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs
+          authenticator subkey), encrypted with the tgs session key
+          (section 5.3.2)
+      8.  TGS-REP encrypted part (includes application session key),
+          encrypted with the tgs session key (section 5.4.2)
+      9.  TGS-REP encrypted part (includes application session key),
+          encrypted with the tgs authenticator subkey (section 5.4.2)
+
+      10. AP-REQ Authenticator cksum, keyed with the application session
+          key (section 5.3.2)
+      11. AP-REQ Authenticator (includes application authenticator
+          subkey), encrypted with the application session key (section
+          5.3.2)
+      12. AP-REP encrypted part (includes application session subkey),
+          encrypted with the application session key (section 5.5.2)
+
+      13. KRB-PRIV encrypted part, encrypted with a key chosen by the
+          application (section 5.7.1)
+      14. KRB-CRED encrypted part, encrypted with a key chosen by the
+          application (section 5.6.1)
+      15. KRB-SAVE cksum, keyed with a key chosen by the application
+          (section 5.8.1)
+
+      16. Data which is defined in some specification outside of
+          Kerberos to be encrypted using an RFC1510 encryption type.
+      17. Data which is defined in some specification outside of
+          Kerberos to be checksummed using an RFC1510 checksum type.
+
+   A few of these key usages need a little clarification.  A service
+   which receives an AP-REQ has no way to know if the enclosed Ticket
+   was part of an AS-REP or TGS-REP.  Therefore, key usage 2 must always
+
+
+
+Horowitz                                                        [Page 2]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+   be used for generating a Ticket, whether it is in response to an AS-
+   REQ or TGS-REQ.
+
+   There might exist other documents which define protocols in terms of
+   the RFC1510 encryption types or checksum types.  Such documents would
+   not know about key usages.  In order that these documents continue to
+   be meaningful until they are updated, key usages 16 and 17 must be
+   used to derive keys for encryption and checksums, respectively.  New
+   protocols defined in terms of the Kerberos encryption and checksum
+   types should use their own key usages.  Key usages may be registered
+   with IANA to avoid conflicts.  Key usages shall be unsigned 32 bit
+   integers.  Zero is not permitted.
+
+
+Defining Cryptosystems Using Key Derivation
+
+   Kerberos requires that the ciphertext component of EncryptedData be
+   tamper-resistant as well as confidential.  This implies encryption
+   and integrity functions, which must each use their own separate keys.
+   So, for each key usage, two keys must be generated, one for
+   encryption (Ke), and one for integrity (Ki):
+
+      Ke = DK(protocol key, key usage | 0xAA)
+      Ki = DK(protocol key, key usage | 0x55)
+
+   where the key usage is represented as a 32 bit integer in network
+   byte order.  The ciphertest must be generated from the plaintext as
+   follows:
+
+      ciphertext = E(Ke, confounder | length | plaintext | padding) |
+                   H(Ki, confounder | length | plaintext | padding)
+
+   The confounder and padding are specific to the encryption algorithm
+   E.
+
+   When generating a checksum only, there is no need for a confounder or
+   padding.  Again, a new key (Kc) must be used.  Checksums must be
+   generated from the plaintext as follows:
+
+      Kc = DK(protocol key, key usage | 0x99)
+
+      MAC = H(Kc, length | plaintext)
+
+   Note that each enctype is described by an encryption algorithm E and
+   a keyed hash algorithm H, and each checksum type is described by a
+   keyed hash algorithm H.  HMAC, with an appropriate hash, is
+   recommended for use as H.
+
+
+Security Considerations
+
+   This entire document addresses shortcomings in the use of
+   cryptographic keys in Kerberos V5.
+
+
+
+
+Horowitz                                                        [Page 3]
+
+Internet Draft       Key Derivation for Kerberos V5       November, 1996
+
+
+Acknowledgements
+
+   I would like to thank Uri Blumenthal, Sam Hartman, and Bill
+   Sommerfeld for their contributions to this document.
+
+
+References
+
+   [Horowitz96] Horowitz, M., "Key Derivation for Authentication,
+      Integrity, and Privacy", draft-horowitz-key-derivation-00.txt,
+      November 1996.  [RFC1510] Kohl, J. and Neuman, C., "The Kerberos
+      Network Authentication Service (V5)", RFC 1510, September 1993.
+
+
+Author's Address
+
+   Marc Horowitz
+   Cygnus Solutions
+   955 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone: +1 617 354 7688
+   Email: marc@cygnus.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Horowitz                                                        [Page 4]
+