1 2 3<Kerberos Working Group> Larry Zhu 4Internet Draft Karthik Jaganathan 5Updates: 1964 Microsoft 6Category: Standards Track Sam Hartman 7draft-ietf-krb-wg-gssapi-cfx-01.txt MIT 8 August 29, 2003 9 Expires: February 29, 2004 10 11 The Kerberos Version 5 GSS-API Mechanism: Version 2 12 13Status of this Memo 14 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of [RFC-2026]. 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 30 31 321. Abstract 33 34 [RFC-1964] defines protocols, procedures, and conventions to be 35 employed by peers implementing the Generic Security Service 36 Application Program Interface (as specified in [RFC-2743]) when 37 using the Kerberos Version 5 mechanism (as specified in [KRBCLAR]). 38 39 This memo obsoletes [RFC-1964] and proposes changes in response to 40 recent developments such as the introduction of Kerberos crypto 41 framework. It is intended that this memo or a subsequent version 42 will become the Kerberos Version 5 GSS-API mechanism specification 43 on the standards track. 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 this 49 document are to be interpreted as described in [RFC-2119]. 50 513. Introduction 52 53 [KCRYPTO] defines a generic framework for describing encryption and 54 checksum types to be used with the Kerberos protocol and associated 55 protocols. 56 57 58Zhu Standards Trace - February 16, 2003 1 59 Kerberos Version 5 GSS-API August 2003 60 61 62 [RFC-1964] describes the GSSAPI mechanism for Kerberos V5. It 63 defines the format of context initiation, per-message and context 64 deletion tokens and uses algorithm identifiers for each cryptosystem 65 in per message and context deletion tokens. 66 67 The approach taken in this document obviates the need for algorithm 68 identifiers. This is accomplished by using the same encryption and 69 checksum algorithms specified by the crypto profile [KCRYPTO] for 70 the session key or subkey that is created during context 71 negotiation. Message layouts of the per-message and context 72 deletion tokens are therefore revised to remove algorithm indicators 73 and also to add extra information to support the generic crypto 74 framework [KCRYPTO]. 75 76 Tokens transferred between GSS-API peers for security context 77 initiation are also described in this document. The data elements 78 exchanged between a GSS-API endpoint implementation and the Kerberos 79 KDC are not specific to GSS-API usage and are therefore defined 80 within [KRBCLAR] rather than within this specification. 81 82 The new token formats specified in this memo MUST be used with all 83 "newer" encryption types [KRBCLAR] and MAY be used with "older" 84 encryption types, provided that the initiator and acceptor know, 85 from the context establishment, that they can both process these new 86 token formats. 87 88 "Newer" encryption types are those which have been specified along 89 with or since the new Kerberos cryptosystem specification [KCRYPTO] 90 [KRBCLAR]. 91 92 Note that in this document, "AES" is used for brevity to refer 93 loosely to either aes128-cts-hmac-sha1-96 or aes256-cts-hmac-sha1-96 94 as defined in [AES-KRB5]. AES is used as an example of the new 95 method defined in this document. 96 974. Key Derivation for Per-Message and Context Deletion Tokens 98 99 To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 100 "entropy-preserving" derived keys, for different purposes or key 101 usages, from a base key or protocol key. This document defines four 102 key usage values below for signing and sealing messages: 103 104 Name value 105 ------------------------------------- 106 KG-USAGE-ACCEPTOR-SEAL 22 107 KG-USAGE-ACCEPTOR-SIGN 23 108 KG-USAGE-INITIATOR-SEAL 24 109 KG-USAGE-INITIATOR-SIGN 25 110 111 When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 112 used as the usage number in the key derivation function for deriving 113 keys to be used in MIC and context deletion tokens, and KG-USAGE- 114 ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is 115 the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage 116 117Zhu Standards Track - February 16, 2004 2 118 Kerberos Version 5 GSS-API August 2003 119 120 121 number in the key derivation function for MIC and context deletion 122 tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if 123 the Wrap token does not provide for confidentiality the same usage 124 values specified above are used. 125 1265. Quality of Protection 127 128 The GSSAPI specification [RFC-2743] provides for Quality of 129 Protection (QOP) values that can be used by the application to 130 request a certain type of encryption or signing. A zero QOP value 131 is used to indicate the "default" protection; applications which use 132 the default QOP are not guaranteed to be portable across 133 implementations or even inter-operate with different deployment 134 configurations of the same implementation. Using an algorithm that 135 is different from the one for which the key is defined may not be 136 appropriate. Therefore, when the new method in this document is 137 used, the QOP value is ignored. 138 139 The encryption and checksum algorithms in per-message and context 140 deletion tokens are now implicitly defined by the algorithms 141 associated with the session key or subkey. Algorithms identifiers 142 as described in [RFC-1964] are therefore no longer needed and 143 removed from the new token headers. 144 1456. Token Framing 146 147 Per [RFC-2743], all tokens emitted by the Kerberos V5 GSS-API 148 mechanism will have the framing shown below: 149 150 GSS-API DEFINITIONS ::= 151 152 BEGIN 153 154 MechType ::= OBJECT IDENTIFIER 155 -- representing Kerberos V5 mechanism 156 157 GSSAPI-Token ::= 158 -- option indication (delegation, etc.) indicated within 159 -- mechanism-specific token 160 [APPLICATION 0] IMPLICIT SEQUENCE { 161 thisMech MechType, 162 innerToken ANY DEFINED BY thisMech 163 -- contents mechanism-specific 164 -- ASN.1 structure not required 165 } 166 END 167 168 The innerToken field always starts with a two byte token-identifier 169 (TOK_ID). Here are the TOK_ID values: 170 171 Token TOK_ID Value in hex 172 ------------------------------------------- 173 KRB_AP_REQUEST 01 00 174 KRB_AP_REQPLY 02 00 175 176Zhu Standards Track - February 16, 2004 3 177 Kerberos Version 5 GSS-API August 2003 178 179 180 KRB_ERROR 03 00 181 [RFC-1964] MIC 01 01 182 [RFC-1964] Wrap 01 02 183 [RFC-1964] context deletion 02 01 184 MIC 04 04 185 Wrap 04 05 186 context deletion 05 04 187 188 1897. Context Initialization Tokens 190 191 For context initialization tokens, the body for the innerToken field 192 contains a Kerberos V5 message (KRB_AP_REQUEST, KRB_AP_REPLY, or 193 KRB_ERROR) as defined in [KRBCLAR]. 194 1957.1. Authenticator Checksum 196 197 The authenticator in the KRB_AP_REQ message MUST include the 198 optional sequence number and the checksum field. The checksum field 199 is used to convey service flags, channel binding, and optional 200 delegation information. It MUST have a type of 0x8003. The length 201 of the checksum MUST be 24 bytes when delegation is not used. When 202 delegation is used, a TGT with its FORWARDABLE flag set will be 203 transferred within the KRB_CRED [KRBCLAR] message. 204 205 The format of the authenticator checksum field is as follows. 206 207 Byte Name Description 208 ----------------------------------------------------------------- 209 0..3 Lgth Number of bytes in Bnd field; 210 Currently contains hex 10 00 00 00 211 (16, represented in little-endian form) 212 4..19 Bnd MD5 hash of channel bindings, taken over all 213 non-null components of bindings, in order 214 of declaration. Integer fields within channel 215 bindings are represented in little-endian order 216 for the purposes of the MD5 calculation. 217 20..23 Flags Bit vector of context-establishment flags, 218 as defined next. The resulting bit vector is 219 encoded into bytes 20..23 in little-endian form. 220 24..25 DlgOpt The Delegation Option identifier (=1) [optional] 221 26..27 Dlgth The length of the Deleg field [optional] 222 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional] 223 224 [we need to get input on how to allow additional data for 225 extensions. Nicolas will post some text for this. If that is the 226 case, do we need to change the checksum type?] 227 2287.1.1. Flags Field 229 230 The checksum flags are used to convey service options or extension 231 negotiation information. The bits in the Flags field are allocated 232 as follows (Most significant bit is bit 0): 233 234Zhu Standards Track - February 16, 2004 4 235 Kerberos Version 5 GSS-API August 2003 236 237 238 Bit Name Description 239 ---------------------------------------------------- 240 0..11 Mandatory Critical extension flags 241 12..15 Optional Non-critical extension flags 242 16..31 Standard Context establishment flags 243 244 An extension or context establishment flag can either be critical or 245 non-critical. When the context initiator desires a particular 246 extension or context establishment flag (either critical or non- 247 critical) it sets the appropriate checksum flag. The context 248 acceptor MUST ignore unsupported non-critical extensions or flags in 249 the initiator's context token (i.e., acceptors MUST NOT return an 250 error just because there were unsupported non-critical extensions or 251 flags in the initiator's token). The acceptor MUST return 252 GSS_S_UNAVAILABLE [RFC-2743] if there are unsupported critical 253 extensions or flags in the initiator's context token. 254 255 The following context establishment flags are defined in [RFC-2744] 256 257 Flag Name Value 258 --------------------------------- 259 GSS_C_DELEG_FLAG 1 260 GSS_C_MUTUAL_FLAG 2 261 GSS_C_REPLAY_FLAG 4 262 GSS_C_SEQUENCE_FLAG 8 263 GSS_C_CONF_FLAG 16 264 GSS_C_INTEG_FLAG 32 265 GSS_C_ANON_FLAG 64 266 267 Context establishment flags are exposed to the calling application. 268 If the calling application desires a particular service option then 269 it requests that option via GSS_Init_sec_context(). An 270 implementation that supports a particular extension SHOULD then set 271 the appropriate flag in the checksum Flags field. 272 273 All existing context establishment flags are non-critical, and it is 274 possible that a new context establishment flag can be added as a 275 critical flag. 276 2777.1.2. Channel Binding Information 278 279 In computing the contents of the "Bnd" field, the following detailed 280 points apply: 281 282 (1) Each integer field shall be formatted into four bytes, using 283 little-endian byte ordering, for purposes of MD5 hash computation. 284 285 (2) All input length fields within gss_buffer_desc [RFC-2744] 286 elements of a gss_channel_bindings_struct [RFC-2744], even those 287 which are zero-valued, shall be included in the hash calculation; 288 the value elements of gss_buffer_desc elements shall be 289 dereferenced, and the resulting data shall be included within the 290 hash computation, only for the case of gss_buffer_desc elements 291 having non-zero length specifiers. 292 293Zhu Standards Track - February 16, 2004 5 294 Kerberos Version 5 GSS-API August 2003 295 296 297 298 (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 299 valid channel bindings structure, the Bnd field shall be set to 16 300 zero-valued bytes. 301 302 [Nicolas suggested that the only change that might be needed here 303 was the use of SHA1 instead of MD5] 304 3058. Per-Message and Context Deletion Tokens 306 307 The new per-message and context deletion token formats defined in 308 this document are designed to accommodate the requirements of newer 309 crypto systems. The token layouts have also been designed to 310 facilitate scatter-gather and in-place encryption without incurring 311 significant performance penalties for implementations that do not 312 allow for either scatter-gather or in-place encryption. 313 314 The design along with the rationale behind it is discussed in detail 315 in the following sections. 316 3178.1. Sequence Number and Direction Indicator 318 319 The sequence number for any per-message or context deletion token is 320 a 64 bit integer (expressed in big endian order). One separate flag 321 is used as the direction-indicator as described in section 8.2. 322 Both the sequence number and the direction-indicator are protected 323 by the encryption and checksum procedures as specified in section 324 8.4. 325 3268.2. Flags Field 327 328 The Flags field is a one-byte bit vector used to indicate a set of 329 attributes. The meanings of the flags are: 330 331 Bit Name Description 332 --------------------------------------------------------------- 333 0 SentByAcceptor When set, this flag indicates the sender 334 is the context acceptor. When not set, 335 it indicates the sender is the context 336 initiator. 337 1 Sealed When set in Wrap tokens, this flag 338 indicates confidentiality is provided 339 for. It MUST not be set in MIC and 340 context deletion tokens. 341 342 The rest of available bits are reserved for future use. 343 3448.3. EC Field 345 346 The EC (Extra Count) field is a two-byte integer field expressed in 347 big endian order. 348 349 350 351Zhu Standards Track - February 16, 2004 6 352 Kerberos Version 5 GSS-API August 2003 353 354 355 In Wrap tokens with confidentiality, the EC field is used to encode 356 the size (in bytes) of the random filler, as described in section 357 8.4. 358 359 In Wrap tokens without confidentiality, the EC field is used to 360 encode the size (in bytes) of the trailing checksum, as described in 361 section 8.4. 362 363 When AES is used, the EC field contains the hex value 00 0C in Wrap 364 tokens without confidentiality, and 00 00 in Wrap tokens with 365 confidentiality. 366 3678.4. Encryption and Checksum Operations 368 369 The encryption algorithms defined by the crypto profiles provide for 370 integrity protection. Therefore no separate checksum is needed. 371 372 The result of decryption can be longer than the original plaintext 373 [KCRYPTO] and the extra trailing bytes are called "crypto-system 374 garbage". However, given the size of any plaintext data, one can 375 always find the next (possibly larger) size so that, when padding 376 the to-be-encrypted text to that size, there will be no crypto- 377 system garbage added [KCRYPTO]. 378 379 In Wrap tokens that provide for confidentiality, the "header" (the 380 first 16 bytes of the Wrap token) is appended to the plaintext data 381 before encryption. Random filler is inserted between the plaintext- 382 data and the "header", and there SHALL NOT be crypto-system garbage 383 added by the decryption operation. The resulting Wrap token is 384 {"header" | encrypt(plaintext-data | random-filler | "header")}, 385 where encrypt() is the encryption operation (which provides for 386 integrity protection) defined in the crypto profile [KCRYPTO]. 387 388 [A note from the design team (Sam, Nicolas, Ken, JK and Larry): 389 constraints need to be added to kcrypto to keep the header at the 390 end of the decrypted data. Without these constraints, we might have 391 the header pre-pended to the front of the data and encode an 8 byte 392 length for the plaintext data, which is less efficient. 393 394 Constraints to be added: Given the length of any plaintext data, 395 there should always exist the next (possibly larger) size for which, 396 when padding the to-be-encrypted data to that size, there will be no 397 cryptosystem garbage added, and the number of bytes needed to pad to 398 the next size is no larger than 64K. This is a small addition to 399 kcrypto and we will bring it up at the IETF last call for kcrypto] 400 401 In Wrap tokens that do not provide for confidentiality, the checksum 402 is calculated over the plaintext data concatenated with the token 403 header (the first 16 bytes of the Wrap token). The resulting Wrap 404 token is {"header" | plaintext-data | get_mic(plaintext-data | 405 "header")}, where get_mic() is the checksum operation defined in 406 the crypto profile [KCRYPTO]. 407 408 409Zhu Standards Track - February 16, 2004 7 410 Kerberos Version 5 GSS-API August 2003 411 412 413 The parameters for the key and the cipher-state in the encrypt() and 414 get_mic() operations have been omitted for brevity. 415 416 The resulting Wrap tokens bind the data to the token header, 417 including the sequence number and the directional indicator. 418 419 [With AEAD, Wrap tokens with confidentiality do not need to encrypt 420 the header and the overhead can be reduced slightly] 421 422 For MIC tokens, the checksum is first calculated over the token 423 header (the first 16 bytes of the MIC token) and then the to-be- 424 signed plaintext data. 425 426 For context deletion tokens, the checksum is calculated over the 427 token header (the first 16 bytes of the context deletion token). 428 429 When AES is used, the checksum algorithm is HMAC_SHA1_96 and the 430 checksum size is 12 bytes. Data is pre-pended with a 16 byte 431 confounder before encryption, and no padding is needed. 432 4338.5. RRC Field 434 435 The RRC (Right Rotation Count) field in Wrap tokens is added to 436 allow the data to be encrypted in-place by existing [SSPI] 437 applications that do not provide an additional buffer for the 438 trailer (the cipher text after the in-place-encrypted data) in 439 addition to the buffer for the header (the cipher text before the 440 in-place-encrypted data). The resulting Wrap token in the previous 441 section, excluding the first 16 bytes of the token header, is 442 rotated to the right by "RRC" bytes. The net result is that "RRC" 443 bytes of trailing octets are moved toward the header. Consider the 444 following as an example of this rotation operation: Assume that the 445 RRC value is 3 and the token before the rotation is {"header" | aa | 446 bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 447 {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 448 | cc |...| hh} is used to indicate the byte sequence. 449 450 The RRC field is expressed as a two-byte integer in big endian 451 order. 452 453 The rotation count value is chosen by the sender based on 454 implementation details, and the receiver MUST be able to interpret 455 all possible rotation count values. 456 4578.6. Message Layout for Per-message and Context Deletion Tokens 458 459 The new message layouts are as follows. 460 461 MIC Token: 462 463 Byte no Name Description 464 0..1 TOK_ID Identification field. 465 Tokens emitted by GSS_GetMIC() 466 contain the hex value 04 04 in 467 468Zhu Standards Track - February 16, 2004 8 469 Kerberos Version 5 GSS-API August 2003 470 471 472 this field. 473 2 Flags Attributes field, as described in 474 Section 8.2. 475 3..7 Filler Contains 5 bytes of hex value FF. 476 8..15 SND_SEQ Sequence number field in 477 cleartext, in big endian order. 478 16..last SGN_CKSUM Checksum of byte 0..15 and the 479 "to-be-signed" data, where the 480 checksum algorithm is defined by 481 the crypto profile for the 482 session key or subkey. 483 484 485 The Filler field is included in the checksum calculation for 486 simplicity. This is common to both MIC and context deletion token 487 checksum calculations. 488 489 Wrap Token: 490 491 Byte no Name Description 492 0..1 TOK_ID Identification field. 493 Tokens emitted by GSS_Wrap() 494 contain the hex value 05 04 495 in this field. 496 2 Flags Attributes field, as described in 497 Section 8.2. 498 3 Filler Contains the hex value FF. 499 4..5 EC Contains the "extra count" field, 500 in big endian order as described in 501 section 8.3. 502 6..7 RRC Contains the "right rotation 503 count" in big endian order, as 504 described in section 8.5. 505 8..15 SND_SEQ Sequence number field in 506 cleartext, in big endian order. 507 16..last Data Encrypted data or (plaintext data + 508 checksum), as described in section 509 8.4, where the encryption or 510 checksum algorithm is defined by 511 the crypto profile for the session 512 key or subkey. 513 514 515 Context Deletion Token: 516 517 Byte no Name Description 518 0..1 TOK_ID Identification field. 519 Tokens emitted by 520 GSS_Delete_sec_context() contain 521 the hex value 04 05 in this 522 field. 523 2 Flags Attributes field, as described in 524 Section 8.2. 525 526Zhu Standards Track - February 16, 2004 9 527 Kerberos Version 5 GSS-API August 2003 528 529 530 3..7 Filler Contains 5 bytes of hex value FF. 531 8..15 SND_SEQ Sequence number field in 532 cleartext, in big endian order. 533 16..N SGN_CKSUM Checksum of byte 0..15, where the 534 checksum algorithm is defined by 535 the crypto profile for the 536 session key or subkey. 537 538 5399. Parameter Definitions 540 541 This section defines parameter values used by the Kerberos V5 GSS- 542 API mechanism. It defines interface elements in support of 543 portability, and assumes use of C language bindings per [RFC-2744]. 544 5459.1. Minor Status Codes 546 547 This section recommends common symbolic names for minor_status 548 values to be returned by the Kerberos V5 GSS-API mechanism. Use of 549 these definitions will enable independent implementers to enhance 550 application portability across different implementations of the 551 mechanism defined in this specification. (In all cases, 552 implementations of GSS_Display_status() will enable callers to 553 convert minor_status indicators to text representations.) Each 554 implementation should make available, through include files or other 555 means, a facility to translate these symbolic names into the 556 concrete values which a particular GSS-API implementation uses to 557 represent the minor_status values specified in this section. 558 559 It is recognized that this list may grow over time, and that the 560 need for additional minor_status codes specific to particular 561 implementations may arise. It is recommended, however, that 562 implementations should return a minor_status value as defined on a 563 mechanism-wide basis within this section when that code is 564 accurately representative of reportable status rather than using a 565 separate, implementation-defined code. 566 5679.1.1. Non-Kerberos-specific codes 568 569 GSS_KRB5_S_G_BAD_SERVICE_NAME 570 /* "No @ in SERVICE-NAME name string" */ 571 GSS_KRB5_S_G_BAD_STRING_UID 572 /* "STRING-UID-NAME contains nondigits" */ 573 GSS_KRB5_S_G_NOUSER 574 /* "UID does not resolve to username" */ 575 GSS_KRB5_S_G_VALIDATE_FAILED 576 /* "Validation error" */ 577 GSS_KRB5_S_G_BUFFER_ALLOC 578 /* "Couldn't allocate gss_buffer_t data" */ 579 GSS_KRB5_S_G_BAD_MSG_CTX 580 /* "Message context invalid" */ 581 GSS_KRB5_S_G_WRONG_SIZE 582 /* "Buffer is the wrong size" */ 583 GSS_KRB5_S_G_BAD_USAGE 584 585Zhu Standards Track - February 16, 2004 10 586 Kerberos Version 5 GSS-API August 2003 587 588 589 /* "Credential usage type is unknown" */ 590 GSS_KRB5_S_G_UNKNOWN_QOP 591 /* "Unknown quality of protection specified" */ 592 5939.1.2. Kerberos-specific-codes 594 595 GSS_KRB5_S_KG_CCACHE_NOMATCH 596 /* "Principal in credential cache does not match desired 597 name" */ 598 GSS_KRB5_S_KG_KEYTAB_NOMATCH 599 /* "No principal in keytab matches desired name" */ 600 GSS_KRB5_S_KG_TGT_MISSING 601 /* "Credential cache has no TGT" */ 602 GSS_KRB5_S_KG_NO_SUBKEY 603 /* "Authenticator has no subkey" */ 604 GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 605 /* "Context is already fully established" */ 606 GSS_KRB5_S_KG_BAD_SIGN_TYPE 607 /* "Unknown signature type in token" */ 608 GSS_KRB5_S_KG_BAD_LENGTH 609 /* "Invalid field length in token" */ 610 GSS_KRB5_S_KG_CTX_INCOMPLETE 611 /* "Attempt to use incomplete security context" */ 612 6139.2. Buffer Sizes 614 615 All implementations of this specification shall be capable of 616 accepting buffers of at least 16K bytes as input to GSS_GetMIC(), 617 GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 618 the output_token generated by GSS_Wrap() for a 16K byte input buffer 619 as input to GSS_Unwrap(). Support for larger buffer sizes is 620 optional but recommended. 621 62210. Backwards Compatibility Considerations 623 624 The new token formats defined in this document will only be 625 recognized by new implementations. To address this, implementations 626 can always use the explicit sign or seal algorithm in [GSSAPI-KRB5] 627 when the key type corresponds to "older" algorithms. An alternative 628 approach might be to retry sending the message with the sign or seal 629 algorithm explicitly defined as in [GSSAPI-KRB5]. However this 630 would require the use of a mechanism such as [RFC-2478] to securely 631 negotiate the algorithm or the use out of band mechanism to choose 632 appropriate algorithms. For this reason, it is RECOMMENDED that the 633 new token formats defined in this document can be used only if both 634 peers are known during context negotiation to support the new 635 mechanism (either because of the use of "new" enctypes or because of 636 the use of Kerberos V extensions). 637 63811. Security Considerations 639 640 It is possible that the KDC returns a session-key type that is not 641 supported by the GSSAPI implementation (either on the client and the 642 server). In this case the implementation MUST not try to use the key 643 644Zhu Standards Track - February 16, 2004 11 645 Kerberos Version 5 GSS-API August 2003 646 647 648 with a supported cryptosystem. This will ensure that no security 649 weaknesses arise due to the use of an inappropriate key with an 650 encryption algorithm. 651 652 In addition the security problem described in [3DES] arising from 653 the use of a service implementation with a GSSAPI mechanism 654 supporting only DES and a Kerberos mechanism supporting both DES and 655 Triple DES is actually a more generic one. It arises whenever the 656 GSSAPI implementation does not support a stronger cryptosystem 657 supported by the Kerberos mechanism. KDC administrators desiring to 658 limit the session key types to support interoperability with such 659 GSSAPI implementations should carefully weigh the reduction in 660 protection offered by such mechanisms against the benefits of 661 interoperability. 662 663 66412. Acknowledgments 665 666 The authors wish to acknowledge the contributions from the following 667 individuals: 668 669 Ken Raeburn and Nicolas Willams corrected many of our errors in the 670 use of generic profiles and were instrumental in the creation of this 671 draft. 672 673 Sam Hartman and Ken Raeburn suggested the "floating trailer" idea. 674 675 Sam Hartman and Nicolas Williams recommended the replacing our 676 earlier key derivation function for directional keys with different 677 key usage numbers for each direction as well as retaining the 678 directional bit for maximum compatibility. 679 680 Paul Leach provided numerous suggestions and comments. 681 682 Scott Field, Richard Ward, Dan Simon also provided valuable inputs on 683 this draft. 684 68513. References 686 68713.1. Normative References 688 689 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 690 3", BCP 9, RFC 2026, October 1996. 691 692 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 694 695 [AES] National Institute of Standards and Technology, U.S. 696 Department of Commerce, "Advanced Encryption Standard", Federal 697 Information Processing Standards Publication 197, Washington, DC, 698 November 2001. 699 700 701 702Zhu Standards Track - February 16, 2004 12 703 Kerberos Version 5 GSS-API August 2003 704 705 706 [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft- 707 raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress. 708 709 [3DES] Raeburn, K., "Triple-DES Support for the Kerberos 5 GSSAPI 710 Mechanism", draft-raeburn-gssapi-krb5-3des-XX.txt in the MIT 711 distribution, June 2000. 712 713 [RFC-2743] Linn, J., "Generic Security Service Application Program 714 Interface Version 2, Update 1", RFC 2743, January 2000. 715 716 [RFC-2744] Wray, J., "Generic Security Service API Version 2 : C- 717 bindings", RFC 2744, January 2000. 718 719 [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 720 RFC 1964, June 1996. 721 722 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 723 Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in 724 progress. 725 726 [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S., 727 Raeburn, K., "The Kerveros Network Authentication Service (V5)", 728 draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 729 Work in progress. 730 731 [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 732 Negotiation Mechanism.", RFC 2478, December 1998. 733 73413.2. Informative References 735 736 [SSPI] Leach, P., Security Service Provider Interface, MSDN, April 737 2003 738 73914. Author's Address 740 741 Larry Zhu 742 One Microsoft Way 743 Redmond, WA 98052 - USA 744 EMail: LZhu@microsoft.com 745 746 Karthik Jaganathan 747 One Microsoft Way 748 Redmond, WA 98052 - USA 749 EMail: karthikj@microsoft.com 750 751 Sam Hartman 752 Massachusetts Institute of Technology 753 77 Massachusetts Avenue 754 Cambridge, MA 02139 - USA 755 Email: hartmans@MIT.EDU 756 757 758Zhu Standards Track - February 16, 2004 13 759 Kerberos Version 5 GSS-API August 2003 760 761 762 763Full Copyright Statement 764 765 "Copyright (C) The Internet Society (date). All Rights Reserved. 766 767 This document and translations of it may be copied and 768 furnished to others, and derivative works that comment on or 769 otherwise explain it or assist in its implementation may be 770 prepared, copied, published and distributed, in whole or in 771 part, without restriction of any kind, provided that the above 772 copyright notice and this paragraph are included on all such 773 copies and derivative works. However, this document itself may 774 not be modified in any way, such as by removing the copyright 775 notice or references to the Internet Society or other Internet 776 organizations, except as needed for the purpose of developing 777 Internet standards in which case the procedures for copyrights 778 defined in the Internet Standards process must be followed, or 779 as required to translate it into languages other than English. 780 781 The limited permissions granted above are perpetual and will 782 not be revoked by the Internet Society or its successors or 783 assigns. 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816Zhu Standards Track - February 16, 2004 14