1 2 3 4 5 6 7Kerberos Working Group K. Raeburn 8Category: Informational MIT 9Document: draft-raeburn-krb-gssapi-krb5-3des-01.txt November 24, 2000 10 11 12 Triple-DES Support for the Kerberos 5 GSSAPI Mechanism 13 14Status of this Memo 15 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. Internet-Drafts are 21 draft documents valid for a maximum of six months and may be updated, 22 replaced, or obsoleted by other documents at any time. It is 23 inappropriate to use Internet-Drafts as reference material or to cite 24 them other than as "work in progress." 25 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 31 321. Abstract 33 34 The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically 35 enumerates encryption and checksum types, independently of how such 36 schemes may be used in Kerberos. In the long run, a new Kerberos- 37 based mechanism, which does not require separately enumerating for 38 the GSSAPI mechanism each of the various encryption types defined by 39 Kerberos, is probably a better approach. Various people have 40 expressed interest in designing one, but the work has not yet been 41 completed. 42 43 The MIT Kerberos 5 release version 1.2 includes support for triple- 44 DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has 45 demonstrated the vulnerability of single-DES mechanisms to brute- 46 force attacks by sufficiently motivated and well-funded parties. So, 47 in the interest of providing increased security in the near term, MIT 48 is adding support for triple-DES to the existing mechanism 49 implementation we ship, as an interim measure. 50 51 52 53 54 55 56 57 58Raeburn [Page 1] 59 60INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 61 62 632. New Algorithm Identifiers 64 65 One new sealing algorithm is defined, for use in Wrap tokens. 66 67 68 +--------------------------------------------------------------------+ 69 | name octet values | 70 +--------------------------------------------------------------------+ 71 | DES3-KD 02 00 | 72 +--------------------------------------------------------------------+ 73 74 This algorithm uses triple-DES with key derivation, with a usage 75 value KG_USAGE_SEAL. (Unlike the EncryptedData definition in 76 [KrbRev], no integrity protection is needed, so this is "raw" triple- 77 DES, with no checksum attached to the encrypted data.) Padding is 78 still to 8-byte multiples, and the IV for encrypting application data 79 is zero. 80 81 One new signing algorithm is defined, for use in MIC, Wrap, and 82 Delete tokens. 83 84 85 +--------------------------------------------------------------------+ 86 | name octet values | 87 +--------------------------------------------------------------------+ 88 | HMAC SHA1 DES3-KD 04 00 | 89 +--------------------------------------------------------------------+ 90 91 This algorithm generates an HMAC using SHA-1 and a derived DES3 key 92 with usage KG_USAGE_SIGN, as described in [KrbRev]. 93 94 [N.B.: The current [KrbRev] description refers to expired I-Ds from 95 Marc Horowitz. The text in [KrbRev] may be inadequate to produce an 96 interoperable implementation.] 97 98 The checksum size for this algorithm is 20 octets. See section 4.3 99 below for the use of checksum lengths of other than eight bytes. 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114Raeburn [Page 2] 115 116INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 117 118 1193. Key Derivation 120 121 For purposes of key derivation, we add three new usage values to the 122 list defined in [KrbRev]; one for signing messages, one for sealing 123 messages, and one for encrypting sequence numbers: 124 125 126 +--------------------------------------------------------------------+ 127 | name value | 128 +--------------------------------------------------------------------+ 129 | KG_USAGE_SEAL 22 | 130 | KG_USAGE_SIGN 23 | 131 | KG_USAGE_SEQ 24 | 132 +--------------------------------------------------------------------+ 133 1344. Adjustments to Previous Definitions 135 1364.1. Quality of Protection 137 138 The GSSAPI specification [GSSAPI] says that a zero QOP value 139 indicates the "default". The original specification for the Kerberos 140 5 mechanism says that a zero QOP value (or a QOP value with the 141 appropriate bits clear) means DES encryption. 142 143 Rather than forcing the use of plain DES when the application doesn't 144 use mechanism-specific QOP values, we redefine the explicit DES QOP 145 value as a non-zero value, and define a triple-DES value as well. 146 Then a zero value continues to imply the default, which would be 147 triple-DES protection when given a triple-DES session key. 148 149 Our values are: 150 151 +--------------------------------------------------------------------+ 152 | name value meaning | 153 +--------------------------------------------------------------------+ 154 | GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 SHA-1 HMAC, using | 155 | key derivation | 156 | | 157 | GSS_KRB5_CONF_C_QOP_DES 0x0100 plain DES encryption | 158 | | 159 | GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 triple-DES with key | 160 | derivation | 161 +--------------------------------------------------------------------+ 162 163 Rather than attempt to specify a generic mechanism for deriving a key 164 of one type given a key of another type, and evaluate the security 165 implications of using a short key to generate a longer key to satisfy 166 the requested quality of protection, our implementation will simply 167 168 169 170Raeburn [Page 3] 171 172INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 173 174 175 return an error if the nonzero QOP value specified does not 176 correspond to the session key type. 177 1784.2. MIC Sequence Number Encryption 179 180 The sequence numbers are encrypted in the context key (as defined in 181 [GSSAPI-KRB5] -- this will be either the Kerberos session key or 182 asubkey provided by the context initiator), using whatever encryption 183 system is designated by the type of that context key. The IV is 184 formed from the first N bytes of the SGN_CKSUM field, where N is the 185 number of bytes needed for the IV. (With all algorithms described 186 here and in [GSSAPI-KRB5], the checksum is at least as large as the 187 IV.) 188 1894.3. Message Layout 190 191 Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an 192 checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was specified 193 as being 8 bytes long. We now change this size to be "defined by the 194 checksum algorithm", and retroactively amend the descriptions of all 195 the checksum algorithms described in [GSSAPI-KRB5] to explicitly 196 specify 8-byte output. Application data continues to immediately 197 follow the checksum field in the Wrap token. 198 199 The revised message descriptions are thus: 200 201 MIC token: 202 203 Byte # Name Description 204 ---------------------------------------------------------------------- 205 0..1 TOK_ID Identification field. 206 2..3 SGN_ALG Integrity algorithm indicator. 207 4..7 Filler Contains ff ff ff ff 208 8..15 SND_SEQ Sequence number field. 209 16..s+15 SGN_CKSUM Checksum of "to-be-signed 210 data", calculated according to 211 algorithm specified in SGN_ALG 212 field. 213 214 215 216 217 218 219 220 221 222 223 224 225 226Raeburn [Page 4] 227 228INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 229 230 231 Wrap token: 232 233 Byte # Name Description 234 ---------------------------------------------------------------------- 235 0..1 TOK_ID Identification field. Tokens 236 emitted by GSS_Wrap() contain the 237 hex value 02 01 in this field. 238 2..3 SGN_ALG Checksum algorithm indicator. 239 4..5 SEAL_ALG Sealing algorithm indicator. 240 6..7 Filler Contains ff ff 241 8..15 SND_SEQ Encrypted sequence number field. 242 16..s+15 SGN_CKSUM Checksum of plaintext padded data, 243 calculated according to algorithm 244 specified in SGN_ALG field. 245 s+16..last Data encrypted or plaintext padded data 246 247 248 Where "s" indicates the size of the checksum. 249 250 As indicated above in section 2, we define the HMAC SHA1 DES3-KD 251 checksum algorithm to produce a 20-byte output, so encrypted data 252 begins at byte 36. 253 2545. Backwards Compatibility Considerations 255 256 The context initiator should request of the KDC credentials using 257 session-key cryptosystem types supported by that implementation; if 258 the only types returned by the KDC are not supported by the mechanism 259 implementation, it should indicate a failure. This may seem obvious, 260 but early implementations of both Kerberos and the GSSAPI Kerberos 261 mechanism supported only DES keys, so the cryptosystem compatibility 262 question was easy to overlook. 263 264 Under the current mechanism, no negotiation of algorithm types 265 occurs, so server-side (acceptor) implementations cannot request that 266 clients not use algorithm types not understood by the server. 267 However, administration of the server's Kerberos data (e.g., the 268 service key) has to be done in communication with the KDC, and it is 269 from the KDC that the client will request credentials. The KDC could 270 therefore be tasked with limiting session keys for a given service to 271 types actually supported by the Kerberos and GSSAPI software on the 272 server. 273 274 This does have a drawback for cases where a service principal name is 275 used both for GSSAPI-based and non-GSSAPI-based communication (most 276 notably the "host" service key), if the GSSAPI implementation does 277 not understand triple-DES but the Kerberos implementation does. It 278 means that triple-DES session keys cannot be issued for that service 279 280 281 282Raeburn [Page 5] 283 284INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 285 286 287 principal, which keeps the protection of non-GSSAPI services weaker 288 than necessary. 289 290 It would also be possible to have clients attempt to get single-DES 291 session keys before trying to get triple-DES session keys, and have 292 the KDC refuse to issue the single-DES keys only for the most 293 critical of services, for which single-DES protection is considered 294 inadequate. However, that would eliminate the possibility of 295 connecting with the more secure cryptosystem to any service that can 296 be accessed with the weaker cryptosystem. 297 298 For MIT's 1.2 release, we chose to go with the former approach, 299 putting the burden on the KDC administration and gaining the best 300 protection possible for GSSAPI services, possibly at the cost of 301 weaker protection of non-GSSAPI Kerberos services running earlier 302 versions of the software. 303 3046. Security Considerations 305 306 Various tradeoffs arise regarding the mixing of new and old software, 307 or GSSAPI-based and non-GSSAPI Kerberos authentication. They are 308 discussed in section 5. 309 3107. References 311 312 [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of 313 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & 314 Associates, Inc., May, 1998. 315 316 [GSSAPI] Linn, J., "Generic Security Service Application Program 317 Interface Version 2, Update 1", RFC 2743, January, 2000. 318 319 [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 320 RFC 1964, June, 1996. 321 322 [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 323 Authentication Service (V5)", draft-ietf-cat-kerberos- 324 revisions-06.txt, July 4, 2000. 325 3268. Author's Address 327 328 Kenneth Raeburn Massachusetts Institute of Technology 77 329 Massachusetts Avenue Cambridge, MA 02139 330 3319. Full Copyright Statement 332 333 Copyright (C) The Internet Society (2000). All Rights Reserved. 334 335 336 337 338Raeburn [Page 6] 339 340INTERNET DRAFT Triple-DES for GSSAPI Kerberos November 2000 341 342 343 This document and translations of it may be copied and furnished to 344 others, and derivative works that comment on or otherwise explain it 345 or assist in its implementation may be prepared, copied, published 346 and distributed, in whole or in part, without restriction of any 347 kind, provided that the above copyright notice and this paragraph are 348 included on all such copies and derivative works. However, this 349 document itself may not be modified in any way, such as by removing 350 the copyright notice or references to the Internet Society or other 351 Internet organizations, except as needed for the purpose of 352 developing Internet standards in which case the procedures for 353 copyrights defined in the Internet Standards process must be 354 followed, or as required to translate it into languages other than 355 English. 356 357 The limited permissions granted above are perpetual and will not be 358 revoked by the Internet Society or its successors or assigns. 359 360 This document and the information contained herein is provided on an 361 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 362 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 363 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 364 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 365 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 366 36710. Document Change History 368 369>From -00 to -01: 370 371 Converted master to GNU troff and tbl, rewriting tables in the 372 process. 373 374 Specify informational category only. Modify some text to emphasize 375 that this document intends to describe MIT's extensions. 376 377 Point out that while EncryptedData for 3des-kd includes a checksum, 378 DES3-KD GSS encryption does not. 379 380 Shorten backwards-compatibility descriptions a little. 381 382 Submit to Kerberos working group rather than CAT. 383 384 385 386 387 388 389 390 391 392 393 394Raeburn [Page 7] 395 396