1 2 3 4 5 6Network Working Group M. Horowitz 7<draft-ietf-cat-kerb-key-derivation-00.txt> Cygnus Solutions 8Internet-Draft November, 1996 9 10 11 Key Derivation for Kerberos V5 12 13Status of this Memo 14 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 19 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 24 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 30 31 Distribution of this memo is unlimited. Please send comments to the 32 <cat-ietf@mit.edu> mailing list. 33 34Abstract 35 36 In the Kerberos protocol [RFC1510], cryptographic keys are used in a 37 number of places. In order to minimize the effect of compromising a 38 key, it is desirable to use a different key for each of these places. 39 Key derivation [Horowitz96] can be used to construct different keys 40 for each operation from the keys transported on the network. For 41 this to be possible, a small change to the specification is 42 necessary. 43 44 45Overview 46 47 Under RFC1510 as stated, key derivation could be specified as a set 48 of encryption types which share the same key type. The constant for 49 each derivation would be a function of the encryption type. However, 50 it is generally accepted that, for interoperability, key types and 51 encryption types must map one-to-one onto each other. (RFC 1510 is 52 being revised to address this issue.) Therefore, to use key 53 derivcation with Kerberos V5 requires a small change to the 54 specification. 55 56 For each place where a key is used in Kerberos, a ``key usage'' must 57 be specified for that purpose. The key, key usage, and 58 encryption/checksum type together describe the transformation from 59 plaintext to ciphertext, or plaintext to checksum. For backward 60 61 62 63Horowitz [Page 1] 64 65Internet Draft Key Derivation for Kerberos V5 November, 1996 66 67 68 compatibility, old encryption types would be defined independently of 69 the key usage. 70 71 72Key Usage Values 73 74 This is a complete list of places keys are used in the kerberos 75 protocol, with key usage values and RFC 1510 section numbers: 76 77 1. AS-REQ PA-ENC-TIMESTAMP padata timestamp, encrypted with the 78 client key (section 5.4.1) 79 2. AS-REP Ticket and TGS-REP Ticket (includes tgs session key or 80 application session key), encrypted with the service key 81 (section 5.4.2) 82 3. AS-REP encrypted part (includes tgs session key or application 83 session key), encrypted with the client key (section 5.4.2) 84 85 4. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 86 session key (section 5.4.1) 87 5. TGS-REQ KDC-REQ-BODY AuthorizationData, encrypted with the tgs 88 authenticator subkey (section 5.4.1) 89 6. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator cksum, keyed 90 with the tgs session key (sections 5.3.2, 5.4.1) 91 7. TGS-REQ PA-TGS-REQ padata AP-REQ Authenticator (includes tgs 92 authenticator subkey), encrypted with the tgs session key 93 (section 5.3.2) 94 8. TGS-REP encrypted part (includes application session key), 95 encrypted with the tgs session key (section 5.4.2) 96 9. TGS-REP encrypted part (includes application session key), 97 encrypted with the tgs authenticator subkey (section 5.4.2) 98 99 10. AP-REQ Authenticator cksum, keyed with the application session 100 key (section 5.3.2) 101 11. AP-REQ Authenticator (includes application authenticator 102 subkey), encrypted with the application session key (section 103 5.3.2) 104 12. AP-REP encrypted part (includes application session subkey), 105 encrypted with the application session key (section 5.5.2) 106 107 13. KRB-PRIV encrypted part, encrypted with a key chosen by the 108 application (section 5.7.1) 109 14. KRB-CRED encrypted part, encrypted with a key chosen by the 110 application (section 5.6.1) 111 15. KRB-SAVE cksum, keyed with a key chosen by the application 112 (section 5.8.1) 113 114 16. Data which is defined in some specification outside of 115 Kerberos to be encrypted using an RFC1510 encryption type. 116 17. Data which is defined in some specification outside of 117 Kerberos to be checksummed using an RFC1510 checksum type. 118 119 A few of these key usages need a little clarification. A service 120 which receives an AP-REQ has no way to know if the enclosed Ticket 121 was part of an AS-REP or TGS-REP. Therefore, key usage 2 must always 122 123 124 125Horowitz [Page 2] 126 127Internet Draft Key Derivation for Kerberos V5 November, 1996 128 129 130 be used for generating a Ticket, whether it is in response to an AS- 131 REQ or TGS-REQ. 132 133 There might exist other documents which define protocols in terms of 134 the RFC1510 encryption types or checksum types. Such documents would 135 not know about key usages. In order that these documents continue to 136 be meaningful until they are updated, key usages 16 and 17 must be 137 used to derive keys for encryption and checksums, respectively. New 138 protocols defined in terms of the Kerberos encryption and checksum 139 types should use their own key usages. Key usages may be registered 140 with IANA to avoid conflicts. Key usages shall be unsigned 32 bit 141 integers. Zero is not permitted. 142 143 144Defining Cryptosystems Using Key Derivation 145 146 Kerberos requires that the ciphertext component of EncryptedData be 147 tamper-resistant as well as confidential. This implies encryption 148 and integrity functions, which must each use their own separate keys. 149 So, for each key usage, two keys must be generated, one for 150 encryption (Ke), and one for integrity (Ki): 151 152 Ke = DK(protocol key, key usage | 0xAA) 153 Ki = DK(protocol key, key usage | 0x55) 154 155 where the key usage is represented as a 32 bit integer in network 156 byte order. The ciphertest must be generated from the plaintext as 157 follows: 158 159 ciphertext = E(Ke, confounder | length | plaintext | padding) | 160 H(Ki, confounder | length | plaintext | padding) 161 162 The confounder and padding are specific to the encryption algorithm 163 E. 164 165 When generating a checksum only, there is no need for a confounder or 166 padding. Again, a new key (Kc) must be used. Checksums must be 167 generated from the plaintext as follows: 168 169 Kc = DK(protocol key, key usage | 0x99) 170 171 MAC = H(Kc, length | plaintext) 172 173 Note that each enctype is described by an encryption algorithm E and 174 a keyed hash algorithm H, and each checksum type is described by a 175 keyed hash algorithm H. HMAC, with an appropriate hash, is 176 recommended for use as H. 177 178 179Security Considerations 180 181 This entire document addresses shortcomings in the use of 182 cryptographic keys in Kerberos V5. 183 184 185 186 187Horowitz [Page 3] 188 189Internet Draft Key Derivation for Kerberos V5 November, 1996 190 191 192Acknowledgements 193 194 I would like to thank Uri Blumenthal, Sam Hartman, and Bill 195 Sommerfeld for their contributions to this document. 196 197 198References 199 200 [Horowitz96] Horowitz, M., "Key Derivation for Authentication, 201 Integrity, and Privacy", draft-horowitz-key-derivation-00.txt, 202 November 1996. [RFC1510] Kohl, J. and Neuman, C., "The Kerberos 203 Network Authentication Service (V5)", RFC 1510, September 1993. 204 205 206Author's Address 207 208 Marc Horowitz 209 Cygnus Solutions 210 955 Massachusetts Avenue 211 Cambridge, MA 02139 212 213 Phone: +1 617 354 7688 214 Email: marc@cygnus.com 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249Horowitz [Page 4] 250 251