1 2 3 4<Kerberos Working Group> Larry Zhu 5Internet Draft Microsoft 6Updates: 1964 Karthik Jaganathan 7Category: Standards Track Microsoft 8draft-ietf-krb-wg-gssapi-cfx-00.txt August 16, 2003 9 Expires: February 16, 2004 10 11 Crypto Profile Based Support for the Inclusion of New Encryption and 12 Checksum Algorithms in the Kerberos V5 GSSAPI Mechanism 13 14 15Status of this Memo 16 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33 341. Abstract 35 36 [KCRYPTO] introduced a generic framework for the inclusion of new 37 encryption and checksum algorithms to be used in the Kerberos V5 38 protocol. [AES-KRB5] describes a crypto profile (per [KCRYPTO]) for 39 AES. This document introduces a generic method for adding new 40 crypto-systems to the GSSAPI-KerberosV5 mechanism based on crypto 41 profiles as defined in [KCRYPTO]. It also describes the use of AES 42 encryption for GSSAPI as an example of this new method. 43 44 452. Conventions used in this document 46 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 49 this document are to be interpreted as described in RFC-2119 [2]. 50 51 523. Introduction 53 54 [GSSAPI-KRB5] describes the GSSAPI mechanism for Kerberos V5. It 55 defines the format of context initiation, per-message and context 56 deletion tokens. When adding new crypto system support, the 57 58 59Zhu Standards Trace - February 16, 2003 1 60 Crypto Profile Support for Kerberos GSSAPI August 2003 61 62 63 approach taken in [GSSAPI-KRB5] is to add algorithm identifiers for 64 each new cryptosystem. 65 66 The approach taken in this document is to use the same encryption 67 and checksum algorithms specified by the crypto profile for the 68 session key or subkey that is created during context negotiation. 69 Message layouts of the per-message and context deletion tokens are 70 revised to remove algorithm indicators and add extra information to 71 support the generic crypto framework [KCRYPTO]. 72 73 "Newer" encryption and checksum types MUST use the new token formats 74 defined in this document. Older encryption and checksum types SHALL 75 NOT use these new token formats. The term "newer" is more precisely 76 defined in [KRBCLAR]. 77 78 Note that in this document, "AES" is used for brevity to refer 79 loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 80 as defined in [AES-KRB5]. 81 824. Quality of Protection and Algorithm Identifiers 83 84 The GSSAPI specification [GSSAPI] provides for QOP values that can 85 be used by the application to request a certain type of encryption 86 or signing. A zero QOP value is used to indicate the "default" 87 protection; applications which use the default QOP are not 88 guaranteed to be portable across implementations or even inter- 89 operate with different deployment configurations of the same 90 implementation. Using an algorithm that is different from the one 91 for which the key is defined may not be appropriate. Therefore, when 92 the new method in this document is used, the QOP value is ignored. 93 94 The encryption and checksum algorithms in per-message and context 95 deletion tokens are now implicitly defined by the algorithms 96 associated with the session and subkey. Algorithms identifiers are 97 therefore no longer needed and removed from the token headers. 98 995. Key Derivation 100 101 To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 102 "entropy-preserving" derived keys, for different purposes or key 103 usages, from a base key or protocol key. This document defines four 104 key usage values below for signing and sealing messages: 105 106 Name value 107 ------------------------------------- 108 KG-USAGE-ACCEPTOR-SIGN 22 109 KG-USAGE-ACCEPTOR-SEAL 23 110 KG-USAGE-INITIATOR-SIGN 24 111 KG-USAGE-INITIATOR-SEAL 25 112 113 114 When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 115 used as the usage number in the key derivation function for deriving 116 keys to be used in MIC and context deletion tokens, and KG-USAGE- 117Zhu Standards Track - February 16, 2004 2 118 Crypto Profile Support for Kerberos GSSAPI August 2003 119 120 121 ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 122 the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 123 number in the key derivation function for MIC and context deletion 124 tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if 125 the Wrap token does not provide for confidentiality the same usage 126 values specified above are used. 127 1286. Token Formats and Definitions 129 130 The new token formats defined in this document are designed to 131 accommodate the requirements of newer crypto systems. Certain 132 implementations of GSSAPI, such as SSPI, allow for "scatter-gather" 133 and in-place encryption, mostly by leveraging low level details of 134 crypto systems. The token layouts have been designed to satisfy the 135 above requirements without incurring significant performance 136 penalties or loosing generality. 137 138 The design along with the rationale behind it, is discussed in 139 detail in the following sections. 140 1416.1. Sequence Number and Direction Indicators 142 143 The sequence number for any per-message or context deletion token is 144 a 64 bit integer (expressed in big endian order). One separate byte 145 is used as the directional indicator: the hex value FF if the sender 146 is the context acceptor, 00 otherwise. Both the sequence number and 147 the directional indicator are protected as specified in section 6.2. 148 1496.2. Encryption and Checksum Operations 150 151 The encryption algorithms defined by the crypto profiles provide for 152 integrity protection. Therefore no separate checksum is needed. 153 154 In Wrap tokens that provide for confidentiality, the "header" (the 155 first 16 bytes of the Wrap token) is appended to the plaintext data 156 before encryption. Hence the resulting Wrap token is {"header" | 157 encrypt(plaintext-data | "header")}, where encrypt() is the 158 encryption operation defined in the crypto profile. In Wrap tokens 159 that do not provide for confidentiality, the checksum is calculated 160 over the plaintext data concatenated with the token header (the 161 first 16 bytes of the Wrap token). Hence the resulting Wrap token 162 is {"header" | plaintext-data | get_mic(plaintext-data | "header")}, 163 where get_mic() is the checksum operation defined in the crypto 164 profile. The parameters for the key and the cipher-state in the 165 encrypt() and get_mic() operations have been omitted for brevity. 166 167 The resulting Wrap tokens bind the data to the token header, 168 including the sequence number, directional indicator, and the 169 rotation count. 170 171 [With AEAD, Wrap tokens with confidentiality do not need to encrypt 172 the header and the overhead can be reduced slightly] 173 174 175Zhu Standards Track - February 16, 2004 3 176 Crypto Profile Support for Kerberos GSSAPI August 2003 177 178 179 For MIC tokens, the checksum is first calculated over the token 180 header (the first 16 bytes of the MIC token) and then the to-be- 181 signed plaintext data. 182 183 For context deletion tokens, the checksum is calculated over the 184 token header (the first 16 bytes of the context deletion token). 185 186 When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 187 checksum size is 12 bytes. Data is pre-pended with a 16 byte 188 confounder before encryption, and no padding is needed. 189 1906.3. RRC Field 191 192 A new field, called "RRC" (Right Rotation Count), is added to allow 193 the data to be encrypted in place. The resulting Wrap token in the 194 previous section, excluding the first 16 bytes of the token header, 195 is rotated to the right by "RRC" bytes. The net result is that 196 "RRC" bytes of trailing octets are moved toward the header. 197 Consider the following as an example of this rotation operation: 198 Assume that the RRC value is 3 and the token before the rotation is 199 {"header" | aa | bb | cc | dd | ee | ff | gg | hh}, the token after 200 rotation would be {"header" | ff | gg | hh | aa | bb | cc | dd | ee 201 }, where {aa | bb | cc |...| hh} is used to indicate the byte 202 sequence. 203 204 The RRC field is expressed as a two octet integer in big endian 205 order. 206 207 The rotation count value is chosen by the sender based on 208 implementation details, and the receiver MUST be able to interpret 209 all possible rotation count values. 210 2116.4. EC Field 212 213 The decryption operation in the crypto profile may not always return 214 the exact length of the plaintext data. An "EC"(Extra Count) field 215 is added to the Wrap() token header to indicate the number of bytes 216 that have been added to the end of the plaintext data before 217 encryption. The "EC" field is a two byte integer expressed in big 218 endian order and it should be 00 00 if confidentiality is not 219 provided for by the Wrap tokens. 220 2216.5. Seal Field 222 223 The Seal field in Wrap tokens is used to indicate whether 224 confidentiality is provided for. If confidentiality is provided for 225 by the Wrap token, this field contains the hex value FF, otherwise it 226 contains the hex value 00. 227 2286.6. Message Layout for Per-message and Context Deletion Tokens 229 230 The new message layouts are as follows. 231 232 MIC Token: 233Zhu Standards Track - February 16, 2004 4 234 Crypto Profile Support for Kerberos GSSAPI August 2003 235 236 237 238 Byte no Name Description 239 0..1 TOK_ID Identification field. 240 Tokens emitted by GSS_GetMIC() 241 contain the hex value 04 04 in 242 this field. 243 2..2 Direction Hex value FF if the sender is the 244 context acceptor, 00 otherwise. 245 3..7 Filler Contains 5 bytes of hex value FF. 246 8..15 SND_SEQ Sequence number field in 247 cleartext, in big endian order. 248 16.. SGN_CKSUM Checksum of byte 0..15 and the 249 "to-be-signed" data, where the 250 checksum algorithm is defined by 251 the crypto profile for the 252 session key or subkey. 253 254 255 The Filler field is included in the checksum calculation for 256 simplicity. This is common to both MIC and context deletion token 257 checksum calculations. 258 259 Wrap Token: 260 261 Byte no Name Description 262 0..1 TOK_ID Identification field. 263 Tokens emitted by GSS_Wrap() 264 contain the hex value 05 04 265 in this field. 266 2..2 Direction Hex value FF if the sender is the 267 context acceptor, 00 otherwise. 268 3..3 Seal Confidentiality indicator: hex 269 value FF if confidentiality is 270 provided for, 00 otherwise. 271 4..5 EC Contains the "extra count" field, 272 in big endian order as described in 273 section 6.4. 274 6..7 RRC Contains the "right rotation 275 count" in big endian order, as 276 described in section 6.3. 277 8..15 SND_SEQ Sequence number field in 278 cleartext, in big endian order. 279 16.. Data Encrypted or plaintext data, as 280 described in section 6.2, where 281 the encryption or checksum 282 algorithm is defined by the crypto 283 profile for the session key or 284 subkey. 285 286 287 Context Deletion Token: 288 289 Byte no Name Description 290Zhu Standards Track - February 16, 2004 5 291 Crypto Profile Support for Kerberos GSSAPI August 2003 292 293 294 0..1 TOK_ID Identification field. 295 Tokens emitted by 296 GSS_Delete_sec_context() contain 297 the hex value 04 05 in this 298 field. 299 2..2 Direction Hex value FF if the sender is the 300 context acceptor, 00 otherwise. 301 3..7 Filler Contains 5 bytes of hex value FF. 302 8..15 SND_SEQ Sequence number field in 303 cleartext, in big endian order. 304 16.. SGN_CKSUM Checksum of byte 0..15, where the 305 checksum algorithm is defined by 306 the crypto profile for the 307 session key or subkey. 308 309 3107. Backwards compatibility considerations 311 312 The new token formats defined in this document will only be 313 recognized by new implementations. A MIC or wrap token generated 314 with the algorithms defined in this document will not be recognized 315 by an older implementation that only recognizes the algorithms 316 defined in [GSSAPI-KRB5]. To address this, implementations can 317 always use the explicit sign or seal algorithm in [GSSAPI-KRB5] when 318 the key type corresponds to those algorithms. An alternative 319 approach might be to retry sending the message with the sign or seal 320 algorithm explicitly defined as in [GSSAPI-KRB5]. However this would 321 require the use of a mechanism such as [SPNEGO] to securely 322 negotiate the algorithm or the use out of band mechanism to choose 323 appropriate algorithms. For this reason, it is RECOMMENDED that the 324 use of the new token formats defined in this document be confined 325 only for "newer encryption and checksum" described by a crypto 326 profile. 327 3288. Security Considerations 329 330 It is possible that the KDC returns a session-key type that is not 331 supported by the GSSAPI implementation (either on the client and the 332 server). In this case the implementation MUST not try to use the key 333 with a supported cryptosystem. This will ensure that no security 334 weaknesses arise due to the use of an inappropriate key with an 335 encryption algorithm. 336 337 In addition the security problem described in [3DES] arising from 338 the use of a service implementation with a GSSAPI mechanism 339 supporting only DES and a Kerberos mechanism supporting both DES and 340 Triple DES is actually a more generic one. It arises whenever the 341 GSSAPI implementation does not support a stronger cryptosystem 342 supported by the Kerberos mechanism. KDC administrators desiring to 343 limit the session key types to support interoperability with such 344 GSSAPI implementations should carefully weigh the reduction in 345 protection offered by such mechanisms against the benefits of 346 interoperability. 347Zhu Standards Track - February 16, 2004 6 348 Crypto Profile Support for Kerberos GSSAPI August 2003 349 350 351 352 It is recommended by some cryptographers that the output of a 353 checksum used with an encryption algorithm should have the same 354 strength as the key in use. In this regard standardization work for 355 SHA-256 and SHA-512 to be used with AES is currently in progress. 356 This document retains the use of HMAC_SHA1_96 as specified in the 357 [AES-KRB5] draft. The use of SHA-256 or SHA-512 with AES will 358 require new crypto profiles and there should not be any further 359 changes needed to this document. 360 3619. Acknowledgments 362 363 364 The authors wish to acknowledge the contributions from the following 365 individuals: 366 367 Ken Raeburn and Nicolas Willams corrected many of our errors in the 368 use of generic profiles and were instrumental in the creation of this 369 draft. Sam Hartman and Ken Raeburn suggested the "floating trailer" 370 idea. 371 372 Sam Hartman and Nicolas Williams recommended the replacing our 373 earlier key derivation function for directional keys with different 374 key usage numbers for each direction as well as retaining the 375 directional bit for maximum compatibility. 376 377 Paul Leach provided numerous suggestions and comments. Scott Field, 378 Richard Ward, Dan Simon also provided valuable inputs on this draft. 379 38010. References 381 382 [AES] National Institute of Standards and Technology, U.S. 383 Department of Commerce, "Advanced Encryption Standard", Federal 384 Information Processing Standards Publication 197, Washington, DC, 385 November 2001. 386 387 [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft- 388 raeburn-krb-rijndael-krb-05.txt, June, 2003. Work in progress. 389 390 [DES3] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI 391 Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT 392 distribution, June 2000. 393 394 395 [GSSAPI] Linn, J., "Generic Security Service Application Program 396 Interface Version 2, Update 1", RFC 2743, January, 2000. 397 398 [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 399 RFC 1964, June, 1996. 400 401 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 402 Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in 403 progress. 404 405Zhu Standards Track - February 16, 2004 7 406 Crypto Profile Support for Kerberos GSSAPI August 2003 407 408 409 410 [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S., 411 Raeburn, K., "The Kerveros Network Authentication Service (V5)", 412 http://www.isi.edu/people/bcn/draft-kerberos-rev.html/krb- 413 clarifications-00-020222.txt, February,2002. Work in progress. 414 415 [SPNEGO] Baize, E., Pinkas D., "The Simple and Protected GSS-API 416 Negotiation Mechanism.", RFC 2478, December 1998. 417 41811. Author's Address 419 420 Larry Zhu 421 One Microsoft Way 422 Redmond, WA 98052 - USA 423 EMail: LZhu@microsoft.com 424 425 Karthik Jaganathan 426 One Microsoft Way 427 Redmond, WA 98052 - USA 428 EMail: karthikj@microsoft.com 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461Zhu Standards Track - February 16, 2004 8 462