1 2 3 4 5 6 7 8 9 10Internet-Draft K. Raeburn 11Kerberos Working Group MIT 12Updates: RFC 1964 August 13, 2003 13Document: draft-ietf-krb-wg-gss-crypto-00.txt expires February 13, 2004 14 15 General Kerberos Cryptosystem Support 16 for the Kerberos 5 GSSAPI Mechanism 17 18Abstract 19 20 This document describes an update to the Kerberos 5 mechanism for 21 GSSAPI to allow the use of Kerberos-defined cryptosystems directly in 22 GSSAPI messages, without requiring further changes for each new 23 encryption or checksum algorithm that complies with the Kerberos 24 crypto framework specifications. 25 26Status of this Memo 27 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 30 are working documents of the Internet Engineering Task Force (IETF), 31 its areas, and its working groups. Note that other groups may also 32 distribute working documents as Internet-Drafts. Internet-Drafts are 33 draft documents valid for a maximum of six months and may be updated, 34 replaced, or obsoleted by other documents at any time. It is 35 inappropriate to use Internet-Drafts as reference material or to cite 36 them other than as "work in progress." 37 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 40 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 43 441. Introduction 45 46 Kerberos defines an encryption and checksum framework [KCRYPTO] that 47 provides for complete specification and enumeration of cryptosystem 48 specifications in a general way, to be used within Kerberos and 49 associated protocols. The GSSAPI Kerberos 5 mechanism definition 50 [GSSAPI-KRB5] sets up a framework for enumerating encryption and 51 checksum types, independently of how such schemes may be used in 52 Kerberos, thus requiring updates for any new encryption or checksum 53 algorithm not directly compatible with those already defined. 54 55 56 57 58Raeburn [Page 1] 59 60INTERNET DRAFT August 2003 61 62 63 This document describes an update to [GSSAPI-KRB5] to allow the use 64 of any Kerberos-defined cryptosystems directly in GSSAPI messages, 65 without requiring further changes for each new encryption or checksum 66 algorithm that complies with the framework specifications, and 67 without making assumptions concerning block sizes or other 68 characteristics of the underlying encryption operations. 69 702. Conventions Used in This Document 71 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in RFC 2119. 75 763. New Algorithm Identifiers 77 78 Two new sealing algorithm numbers and one new signing algorithm 79 number are defined, for use in MIC, Wrap and Delete tokens. 80 81 82 type name octet values 83 ----------------------------------------- 84 seal KERBEROS5-ENCRYPT 00 01 85 sign KERBEROS5-CHECKSUM 00 01 86 sign NONE ff ff 87 88 89 The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos 90 encryption type [KCRYPTO] indicated by the encryption key type (using 91 the session key or initiator's subkey, as described in [GSSAPI- 92 KRB5]), with a key usage value KG_USAGE_SEAL, defined below. All 93 Kerberos encryption types provide for integrity protection, and 94 specify any padding that might be required; neither needs to be done 95 at the GSS mechanism level when KERBEROS5-ENCRYPT is used. When 96 KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm 97 MUST be NONE. 98 99 The signing algorithm value NONE MUST be used only with a sealing 100 algorithm that incorporates integrity protection; currently, 101 KERBEROS5-ENCRYPT is the only such sealing algorithm. 102 103 The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases. 104 The contents of the SGN_CKSUM field are determined by computing a 105 Kerberos checksum [KCRYPTO], using the session key or subkey, and a 106 key usage value of KG_USAGE_SIGN. The Kerberos checksum algorithm to 107 be used is the required-to-implement checksum algorithm associated 108 with the encryption key type. It should be noted that the checksum 109 input data in this case is not the same as the "to-be-signed data" 110 described in section 1.2.1.1 of [GSSAPI-KRB5]; see below. 111 112 113 114Raeburn [Page 2] 115 116INTERNET DRAFT August 2003 117 118 119 The encryption or checksum output incorporated in the MIC and Wrap 120 tokens is the octet string output from the corresponding operation in 121 [KCRYPTO]; it should not be confused with the EncryptedData or 122 Checksum object in [KrbClar]. 123 124 For purposes of key derivation, we add two new usage values to the 125 list defined in [KrbClar]; one for signing messages, and one for 126 sealing messages: 127 128 129 name value 130 ---------------------- 131 KG_USAGE_SEAL 22 132 KG_USAGE_SIGN 23 133 134 1354. Adjustments to Previous Definitions 136 1374.1. Quality of Protection 138 139 The GSSAPI specification [GSSAPI] says that a zero QOP value 140 indicates the "default". The original specification for the Kerberos 141 5 mechanism says that a zero QOP value (or a QOP value with the 142 appropriate bits clear) means DES encryption. 143 144 Since the quality of protection cannot be improved without fully 145 reauthenticating with a stronger key type, the QOP value is now 146 ignored. 147 1484.2. Message Layout 149 150 The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed 151 an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte 152 block size, without integrity protection. In the crypto framework 153 described in [KCRYPTO], integrity protection is built into the 154 encryption operations. CBC mode is not assumed, and indeed there may 155 be no initial vector to supply. While the operations are performed 156 on messages of specific sizes, the underlying cipher may be a stream 157 cipher. 158 159 We modify the message definitions such that the portions after the 160 first 8 bytes (which specify the token identification and the signing 161 and sealing algorithms) are defined by the algorithms chosen. The 162 remaining bytes must convey sequence number and direction 163 information, and must protect the integrity of the token id and 164 algorithm indicators. For the DES-based algorithms specified in 165 [GSSAPI-KRB5], the definition for the remaining data is backwards 166 compatible. 167 168 169 170Raeburn [Page 3] 171 172INTERNET DRAFT August 2003 173 174 175 The revised message descriptions are thus as follows: 176 177 178 MIC token 179 Byte # Name Description 180 ------------------------------------------------------- 181 0..1 TOK_ID Identification field (01 01). 182 2..3 SGN_ALG Integrity algorithm indicator. 183 4..7 Filler Contains ff ff ff ff 184 8..N Dependent on SGN_ALG. 185 186 If SGN_ALG is 0000, 0100, 0200: 187 8..15 SND_SEQ Sequence number/direction 188 field, encrypted. 189 16..23 SGN_CKSUM Checksum of bytes 0..7 and 190 application data, as described 191 in [GSSAPI-KRB5]. 192 If SGN_ALG is 0001: 193 8..15 SND_SEQ Sequence number/direction 194 field, NOT encrypted. 195 16..N SGN_CKSUM Checksum of bytes 0..15 and 196 application data, with key 197 usage KG_USAGE_SIGN. 198 199 200 Suggestions from Microsoft: Moving to 64-bit sequence numbers 201 would be better for long sessions with many messages. Using the 202 direction flag to perturb the encryption or integrity protection 203 is safer than simply including a flag which a buggy but mostly 204 working implementation might fail to check. 205 206 I am considering changing to use 64-bit sequence numbers, and 207 omitting the direction flag from the transmitted cleartext data. 208 How it would factor into the encrypted Wrap token, I haven't 209 figured out yet. 210 211 - Change the key usage values based on the direction? It's 212 suggested in [KCRYPTO], perhaps not strongly enough, that the key 213 usage numbers should perturb the key, but DES ignores them, 214 although DES shouldn't use this extension. 215 216 - Add a direction flag byte in encrypted data? Either depends on 217 an implementor remembering to add the check. Adding it to 218 checksummed data requires that the implementor get it right. 219 220 - Generate one or two new keys using PRF and random-to-key 221 operations, using different keys for each direction? Pulling the 222 DK function out of the simplified profile is probably not a good 223 224 225 226Raeburn [Page 4] 227 228INTERNET DRAFT August 2003 229 230 231 way to do this. 232 233 The filler bytes are included in the checksum calculation for 234 simplicity. There is no security benefit from including them. 235 236 In the Wrap token, the initial bytes, sequence number and direction 237 are incorporated into the data to be encrypted. In most cases, this 238 is likely to be more efficient in terms of space and computing power 239 than using unencrypted sequence number and direction fields, adding a 240 checksum, and doing the additional work to authenticate that the 241 checksum and encrypted data are part of the same message. (The 242 framework in [KCRYPTO] has no support for integrity protection of a 243 block of data only some of which is encrypted, except by treating the 244 two portions independently and using some additional means to ensure 245 that the two parts continue to be associated with one another.) 246 247 The length is also included, as a 4-byte value in network byte order, 248 because the decryption operation in the Kerberos crypto framework 249 does not recover the exact length of the original input. Thus, 250 messages with application data larger than 4 gigabytes are not 251 supported. 252 253 [Q: Should this length be 8 bytes? ASN.1 wrapper?] 254 255 256 Wrap token 257 Byte # Name Description 258 ------------------------------------------------------------- 259 0..1 TOK_ID Identification field (02 01). 260 2..3 SGN_ALG Integrity algorithm indicator. 261 4..5 SEAL_ALG Sealing algorithm indicator. 262 6..7 Filler Contains ff ff 263 8..last Dependent on SEAL_ALG and SGN_ALG. 264 265 If SEAL_ALG is 0000: 266 8..15 SND_SEQ Encrypted sequence number field. 267 16..23 SGN_CKSUM Checksum of plaintext padded data, 268 calculated according to algorithm 269 specified in SGN_ALG field. (RFC 270 1964) 271 24..last Data Encrypted padded data. 272 273 If SEAL_ALG is 0001 and SGN_ALG is ffff: 274 8..last Data Encrypted bytes 0..5, 2-byte 275 direction flag, sequence number, 276 4-byte data length, and data. 277 278 279 280 281 282Raeburn [Page 5] 283 284INTERNET DRAFT August 2003 285 286 287 If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200: 288 8..15 SND_SEQ Encrypted sequence number field. 289 16..23 SGN_CKSUM Checksum of plaintext padded data, 290 as in RFC 1964. 291 24..last Data plaintext padded data 292 293 If SEAL_ALG if ffff, and SGN_ALG is 0001: 294 8..15 SND_SEQ Sequence number/direction field, 295 NOT encrypted. 296 16..N SGN_CKSUM Checksum of bytes 0..15 and 297 application data, with key usage 298 KG_USAGE_SIGN. 299 N+1..last Data plaintext data 300 301 302 The direction flag, as in [GSSAPI-KRB5], is made up of bytes 303 indicating the party sending the token: 00 for the context initiator, 304 or hex FF for the context acceptor. In the KERBEROS5-ENCRYPT case, 305 only two bytes are used, and they replace the fixed filler bytes of 306 the token header, which need no protection; this reduces slightly the 307 redundancy of the data transmitted. 308 309 The context-deletion token is essentially a MIC token with no user 310 data and a different TOK_ID value. Thus, its modification is 311 straightforward. 312 313 314 Context deletion token 315 Byte # Name Description 316 ------------------------------------------------------- 317 0..1 TOK_ID Identification field (01 02). 318 2..3 SGN_ALG Integrity algorithm indicator. 319 4..7 Filler Contains ff ff ff ff 320 321 If SGN_ALG is 0000, 0100, 0200: 322 8..15 SND_SEQ Sequence number/direction 323 field, encrypted. 324 16..23 SGN_CKSUM Checksum of bytes 0..7, as 325 described in [GSSAPI-KRB5]. 326 327 If SGN_ALG is 0001: 328 8..15 SND_SEQ Sequence number/direction 329 field, NOT encrypted. 330 16..N SGN_CKSUM Checksum of bytes 0..15, with 331 key usage KG_USAGE_SIGN. 332 333 334 335 336 337 338Raeburn [Page 6] 339 340INTERNET DRAFT August 2003 341 342 3435. Backwards Compatibility Considerations 344 345 The context initiator should request of the KDC credentials using 346 session-key cryptosystem types supported by that implementation; if 347 the only types returned by the KDC are not supported by the mechanism 348 implementation, it should indicate a failure. This may seem obvious, 349 but early implementations of both Kerberos and the GSSAPI Kerberos 350 mechanism supported only DES keys, so the cryptosystem compatibility 351 question was easy to overlook. 352 353 Under the current mechanism, no negotiation of algorithm types 354 occurs, so server-side (acceptor) implementations cannot request that 355 clients not use algorithm types not understood by the server. 356 However, administration of the server's Kerberos data (e.g., the 357 service key) has to be done in communication with the KDC, and it is 358 from the KDC that the client will request credentials. The KDC could 359 therefore be given the task of limiting session keys for a given 360 service to types actually supported by the Kerberos and GSSAPI 361 software on the server. 362 363 This does have a drawback for cases where a service principal name is 364 used both for GSSAPI-based and non-GSSAPI-based communication (most 365 notably the "host" service key), if the GSSAPI implementation does 366 not understand (for example) AES but the Kerberos implementation 367 does. It means that AES session keys cannot be issued for that 368 service principal, which keeps the protection of non-GSSAPI services 369 weaker than necessary. 370 371 It would also be possible to have clients attempt to get DES session 372 keys before trying to get AES session keys, and have the KDC refuse 373 to issue the DES keys only for the most critical of services, for 374 which DES protection is considered inadequate. However, that would 375 eliminate the possibility of connecting with the more secure 376 cryptosystem to any service that can be accessed with the weaker 377 cryptosystem. We thus recommend the former approach, putting the 378 burden on the KDC administration and gaining the best protection 379 possible for GSSAPI services, possibly at the cost of weaker 380 protection of non-GSSAPI Kerberos services sharing service principal 381 names with GSSAPI services that have not been updated to support this 382 extension. 383 384 [optional:] 385 386 This mechanism extension MUST NOT be used with the DES encryption key 387 types described in [KCRYPTO], which ignore the key usage values. 388 389 390 391 392 393 394Raeburn [Page 7] 395 396INTERNET DRAFT August 2003 397 398 3996. Implementation Note 400 401 At least two implementations have been done of extensions to the RFC 402 1964 mechanism for specific non-DES encryption types. These are not 403 standards-track extensions, but implementors may wish to implement 404 them as well for compatibility with existing products. No guidance 405 is provided as to when an implementation may wish to use these non- 406 standard extensions instead of the extension specified in this 407 document. 408 4097. Security Considerations 410 411 Various tradeoffs arise regarding the mixing of new and old software, 412 or GSSAPI-based and non-GSSAPI Kerberos authentication. They are 413 discussed in section 5. 414 415 Remember to check direction flag. Key usage numbers and direction 416 checks? Considerations depend on the approach taken.... 417 4188. Acknowledgements 419 420 Larry Zhu... 421 4229. Normative References 423 424 [GSSAPI] 425 Linn, J., "Generic Security Service Application Program Interface 426 Version 2, Update 1", RFC 2743, January, 2000. 427 428 [GSSAPI-KRB5] 429 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 430 June, 1996. 431 432 [KCRYPTO] 433 draft-ietf-krb-wg-crypto-XX -> RFC xxxx 434 435 [KrbClar] 436 draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx 437 438 [RFC2026] 439 RFC 2026 ... 440 441 [RFC2119] 442 RFC 2119 ... 443 444 445 446 447 448 449 450Raeburn [Page 8] 451 452INTERNET DRAFT August 2003 453 454 45510. Author's Address 456 457 Kenneth Raeburn 458 Massachusetts Institute of Technology 459 77 Massachusetts Avenue 460 Cambridge, MA 02139 461 462Full Copyright Statement 463 464 Copyright (C) The Internet Society (2003). All Rights Reserved. 465 466 This document and translations of it may be copied and furnished to 467 others, and derivative works that comment on or otherwise explain it 468 or assist in its implementation may be prepared, copied, published 469 and distributed, in whole or in part, without restriction of any 470 kind, provided that the above copyright notice and this paragraph are 471 included on all such copies and derivative works. However, this 472 document itself may not be modified in any way, such as by removing 473 the copyright notice or references to the Internet Society or other 474 Internet organizations, except as needed for the purpose of 475 developing Internet standards in which case the procedures for 476 copyrights defined in the Internet Standards process must be 477 followed, or as required to translate it into languages other than 478 English. 479 480 The limited permissions granted above are perpetual and will not be 481 revoked by the Internet Society or its successors or assigns. 482 483 This document and the information contained herein is provided on an 484 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 485 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 486 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 487 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 488 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 489 490Document Change History 491 492Version -XX: 493 494 Split up Abstract and create a real Introduction. Fix RFC 2026 495 reference in Status section. Added Conventions, Acknowledgements and 496 Implementation Note sections. Updated References with more 497 placeholders. Capitalize some uses of "must" etc. 498 499 Fill in case of Wrap token without integrity protection, using 500 KERBEROS5-CHECKSUM for SGN_ALG. Fix descriptions of which message 501 layout is used for which algorithms. 502 503 504 505 506Raeburn [Page 9] 507 508INTERNET DRAFT August 2003 509 510 511 Remove discussion of authenticated encryption with additional data. 512 513 Add discussion of 64-bit sequence numbers and data length, and 514 alternate handling of the direction flag. 515 516 517 Version -XX sent in early 2003 to Kerberos working group: 518 519 Initial revision. 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562Raeburn [Page 10] 563