idnits 2.17.1 draft-ietf-cat-kerb-key-derivation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC1510], [Horowitz96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1510' is mentioned on line 168, but not defined ** Obsolete undefined reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-02) exists of draft-horowitz-key-derivation-00 -- Possible downref: Normative reference to a draft: ref. 'Horowitz96' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Horowitz 3 Cygnus Solutions 4 Internet-Draft November, 1996 6 Key Derivation for Kerberos V5 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Distribution of this memo is unlimited. Please send comments to the 27 mailing list. 29 Abstract 31 In the Kerberos protocol [RFC1510], cryptographic keys are used in a 32 number of places. In order to minimize the effect of compromising a 33 key, it is desirable to use a different key for each of these places. 34 Key derivation [Horowitz96] can be used to construct different keys 35 for each operation from the keys transported on the network. For 36 this to be possible, a small change to the specification is 37 necessary. 39 Overview 41 Under RFC1510 as stated, key derivation could be specified as a set 42 of encryption types which share the same key type. The constant for 43 each derivation would be a function of the encryption type. However, 44 it is generally accepted that, for interoperability, key types and 45 encryption types must map one-to-one onto each other. (RFC 1510 is 46 being revised to address this issue.) Therefore, to use key 47 derivcation with Kerberos V5 requires a small change to the 48 specification. 50 For each place where a key is used in Kerberos, a ``key usage'' must 51 be specified for that purpose. The key, key usage, and 52 encryption/checksum type together describe the transformation from 53 plaintext to ciphertext, or plaintext to checksum. For backward 54 compatibility, old encryption types would be defined independently of 55 the key usage. 57 Key Usage Values 59 This is a complete list of places keys are used in the kerberos 60 protocol, with key usage values and RFC 1510 section numbers: 62 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 63 client key (section 5.4.1) 64 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 65 application session key), encrypted with the service key 66 (section 5.4.2) 67 3. AS-REP encrypted part (includes tgs session key or application 68 session key), encrypted with the client key (section 5.4.2) 70 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 71 session key (section 5.4.1) 72 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 73 authenticator subkey (section 5.4.1) 74 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 75 with the tgs session key (sections 5.3.2, 5.4.1) 76 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 77 authenticator subkey), encrypted with the tgs session key 78 (section 5.3.2) 79 8. TGS-REP encrypted part (includes application session key), 80 encrypted with the tgs session key (section 5.4.2) 81 9. TGS-REP encrypted part (includes application session key), 82 encrypted with the tgs authenticator subkey (section 5.4.2) 84 10. AP-REQ Authenticator cksum, keyed with the application session 85 key (section 5.3.2) 86 11. AP-REQ Authenticator (includes application authenticator 87 subkey), encrypted with the application session key (section 88 5.3.2) 89 12. AP-REP encrypted part (includes application session subkey), 90 encrypted with the application session key (section 5.5.2) 92 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 93 application (section 5.7.1) 94 14. KRB-CRED encrypted part, encrypted with a key chosen by the 95 application (section 5.6.1) 96 15. KRB-SAVE cksum, keyed with a key chosen by the application 97 (section 5.8.1) 99 16. Data which is defined in some specification outside of 100 Kerberos to be encrypted using an RFC1510 encryption type. 101 17. Data which is defined in some specification outside of 102 Kerberos to be checksummed using an RFC1510 checksum type. 104 A few of these key usages need a little clarification. A service 105 which receives an AP-REQ has no way to know if the enclosed Ticket 106 was part of an AS-REP or TGS-REP. Therefore, key usage 2 must always 107 be used for generating a Ticket, whether it is in response to an AS- 108 REQ or TGS-REQ. 110 There might exist other documents which define protocols in terms of 111 the RFC1510 encryption types or checksum types. Such documents would 112 not know about key usages. In order that these documents continue to 113 be meaningful until they are updated, key usages 16 and 17 must be 114 used to derive keys for encryption and checksums, respectively. New 115 protocols defined in terms of the Kerberos encryption and checksum 116 types should use their own key usages. Key usages may be registered 117 with IANA to avoid conflicts. Key usages shall be unsigned 32 bit 118 integers. Zero is not permitted. 120 Defining Cryptosystems Using Key Derivation 122 Kerberos requires that the ciphertext component of EncryptedData be 123 tamper-resistant as well as confidential. This implies encryption 124 and integrity functions, which must each use their own separate keys. 125 So, for each key usage, two keys must be generated, one for 126 encryption (Ke), and one for integrity (Ki): 128 Ke = DK(protocol key, key usage | 0xAA) 129 Ki = DK(protocol key, key usage | 0x55) 131 where the key usage is represented as a 32 bit integer in network 132 byte order. The ciphertest must be generated from the plaintext as 133 follows: 135 ciphertext = E(Ke, confounder | length | plaintext | padding) | 136 H(Ki, confounder | length | plaintext | padding) 138 The confounder and padding are specific to the encryption algorithm 139 E. 141 When generating a checksum only, there is no need for a confounder or 142 padding. Again, a new key (Kc) must be used. Checksums must be 143 generated from the plaintext as follows: 145 Kc = DK(protocol key, key usage | 0x99) 147 MAC = H(Kc, length | plaintext) 149 Note that each enctype is described by an encryption algorithm E and 150 a keyed hash algorithm H, and each checksum type is described by a 151 keyed hash algorithm H. HMAC, with an appropriate hash, is 152 recommended for use as H. 154 Security Considerations 156 This entire document addresses shortcomings in the use of 157 cryptographic keys in Kerberos V5. 159 Acknowledgements 161 I would like to thank Uri Blumenthal, Sam Hartman, and Bill 162 Sommerfeld for their contributions to this document. 164 References 166 [Horowitz96] Horowitz, M., "Key Derivation for Authentication, 167 Integrity, and Privacy", draft-horowitz-key-derivation-00.txt, 168 November 1996. [RFC1510] Kohl, J. and Neuman, C., "The Kerberos 169 Network Authentication Service (V5)", RFC 1510, September 1993. 171 Author's Address 173 Marc Horowitz 174 Cygnus Solutions 175 955 Massachusetts Avenue 176 Cambridge, MA 02139 178 Phone: +1 617 354 7688 179 Email: marc@cygnus.com