diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt | 250 |
1 files changed, 0 insertions, 250 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 deleted file mode 100644 index 46a4158..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerb-key-derivation-00.txt +++ /dev/null @@ -1,250 +0,0 @@ - - - - - -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] - |
