1 2 3<Network Working Group> Larry Zhu 4Internet Draft Karthik Jaganathan 5Updates: 1964 Microsoft 6Category: Standards Track Sam Hartman 7draft-ietf-krb-wg-gssapi-cfx-04.txt MIT 8 November 21, 2003 9 Expires: May 21, 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 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 33Abstract 34 35 This memo defines protocols, procedures, and conventions to be 36 employed by peers implementing the Generic Security Service 37 Application Program Interface (GSS-API as specified in [RFC-2743]) 38 when using the Kerberos Version 5 mechanism (as specified in 39 [KRBCLAR]). 40 41 [RFC-1964] is updated and incremental changes are proposed in 42 response to recent developments such as the introduction of Kerberos 43 crypto framework [KCRYPTO]. These changes support the inclusion of 44 new cryptosystems based on crypto profiles [KCRYPTO], by defining 45 new per-message tokens along with their encryption and checksum 46 algorithms. 47 48Conventions used in this document 49 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in [RFC-2119]. 53 541. Introduction 55 56 57 58Zhu Internet Draft 1 59 Kerberos Version 5 GSS-API November 2003 60 61 62 [KCRYPTO] defines a generic framework for describing encryption and 63 checksum types to be used with the Kerberos protocol and associated 64 protocols. 65 66 [RFC-1964] describes the GSS-API mechanism for Kerberos Version 5. 67 It defines the format of context establishment, per-message and 68 context deletion tokens and uses algorithm identifiers for each 69 cryptosystem in per message and context deletion tokens. 70 71 The approach taken in this document obviates the need for algorithm 72 identifiers. This is accomplished by using the same encryption 73 algorithm, specified by the crypto profile [KCRYPTO] for the session 74 key or subkey that is created during context negotiation, and its 75 required checksum algorithm. Message layouts of the per-message 76 tokens are therefore revised to remove algorithm indicators and also 77 to add extra information to support the generic crypto framework 78 [KCRYPTO]. 79 80 Tokens transferred between GSS-API peers for security context 81 establishment are also described in this document. The data 82 elements exchanged between a GSS-API endpoint implementation and the 83 Kerberos KDC are not specific to GSS-API usage and are therefore 84 defined within [KRBCLAR] rather than within this specification. 85 86 The new token formats specified in this memo MUST be used with all 87 "newer" encryption types [KRBCLAR] and MAY be used with "older" 88 encryption types, provided that the initiator and acceptor know, 89 from the context establishment, that they can both process these new 90 token formats. 91 92 "Newer" encryption types are those which have been specified along 93 with or since the new Kerberos cryptosystem specification [KCRYPTO], 94 as defined in section 3.1.3 of [KRBCLAR]. The list of not-newer 95 encryption types is as follows [KCRYPTO]: 96 97 Encryption Type Assigned Number 98 ---------------------------------------------- 99 des-cbc-crc 1 100 des-cbc-md4 2 101 des-cbc-md5 3 102 des3-cbc-md5 5 103 des3-cbc-sha1 7 104 dsaWithSHA1-CmsOID 9 105 md5WithRSAEncryption-CmsOID 10 106 sha1WithRSAEncryption-CmsOID 11 107 rc2CBC-EnvOID 12 108 rsaEncryption-EnvOID 13 109 rsaES-OAEP-ENV-OID 14 110 des-ede3-cbc-Env-OID 15 111 des3-cbc-sha1-kd 16 112 rc4-hmac 23 113 114 Note that in this document, the term "little endian order" is used 115 for brevity to refer to the least-significant-octet-first encoding, 116 117 118Zhu Internet Draft 2 119 Kerberos Version 5 GSS-API November 2003 120 121 122 while the term "big endian order" is for the most-significant-octet- 123 first encoding. 124 1252. Key Derivation for Per-Message Tokens 126 127 To limit the exposure of a given key, [KCRYPTO] adopted "one-way" 128 "entropy-preserving" derived keys, for different purposes or key 129 usages, from a base key or protocol key. 130 131 This document defines four key usage values below that are used to 132 derive a specific key for signing and sealing messages, from the 133 session key or subkey [KRBCLAR] created during the context 134 establishment. 135 136 Name Value 137 ------------------------------------- 138 KG-USAGE-ACCEPTOR-SEAL 22 139 KG-USAGE-ACCEPTOR-SIGN 23 140 KG-USAGE-INITIATOR-SEAL 24 141 KG-USAGE-INITIATOR-SIGN 25 142 143 When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is 144 used as the usage number in the key derivation function for deriving 145 keys to be used in MIC tokens, and KG-USAGE-ACCEPTOR-SEAL is used 146 for Wrap tokens; similarly when the sender is the context initiator, 147 KG-USAGE-INITIATOR-SIGN is used as the usage number in the key 148 derivation function for MIC tokens, KG-USAGE-INITIATOR-SEAL is used 149 for Wrap Tokens. Even if the Wrap token does not provide for 150 confidentiality the same usage values specified above are used. 151 152 During the context initiation and acceptance sequence, the acceptor 153 MAY assert a subkey, and if so, subsequent messages MUST use this 154 subkey as the protocol key and these messages MUST be flagged as 155 "AcceptorSubkey" as described in section 4.2.2. 156 1573. Quality of Protection 158 159 The GSS-API specification [RFC-2743] provides for Quality of 160 Protection (QOP) values that can be used by applications to request 161 a certain type of encryption or signing. A zero QOP value is used 162 to indicate the "default" protection; applications which do not use 163 the default QOP are not guaranteed to be portable across 164 implementations or even inter-operate with different deployment 165 configurations of the same implementation. Using an algorithm that 166 is different from the one for which the key is defined may not be 167 appropriate. Therefore, when the new method in this document is 168 used, the QOP value is ignored. 169 170 The encryption and checksum algorithms in per-message tokens are now 171 implicitly defined by the algorithms associated with the session key 172 or subkey. Algorithms identifiers as described in [RFC-1964] are 173 therefore no longer needed and removed from the new token headers. 174 1754. Definitions and Token Formats 176 177 178Zhu Internet Draft 3 179 Kerberos Version 5 GSS-API November 2003 180 181 182 183 This section provides terms and definitions, as well as descriptions 184 for tokens specific to the Kerberos Version 5 GSS-API mechanism. 185 1864.1. Context Establishment Tokens 187 188 All context establishment tokens emitted by the Kerberos V5 GSS-API 189 mechanism will have the framing shown below: 190 191 GSS-API DEFINITIONS ::= 192 193 BEGIN 194 195 MechType ::= OBJECT IDENTIFIER 196 -- representing Kerberos V5 mechanism 197 198 GSSAPI-Token ::= 199 -- option indication (delegation, etc.) indicated within 200 -- mechanism-specific token 201 [APPLICATION 0] IMPLICIT SEQUENCE { 202 thisMech MechType, 203 innerToken ANY DEFINED BY thisMech 204 -- contents mechanism-specific 205 -- ASN.1 structure not required 206 } 207 208 END 209 210 Where the notation and encoding of this pseudo ASN.1 header, which 211 is referred as the generic GSS-API token framing later in this 212 document, are described in [RFC-2743], and the innerToken field 213 starts with a two-octet token-identifier (TOK_ID) expressed in big 214 endian order, followed by a Kerberos message. 215 216 Here are the TOK_ID values used in the context establishment tokens: 217 218 Token TOK_ID Value in Hex 219 ----------------------------------------- 220 KRB_AP_REQUEST 01 00 221 KRB_AP_REPLY 02 00 222 KRB_ERROR 03 00 223 224 Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR 225 are defined in [KRBCLAR]. 226 227 If an unknown token identifier (TOK_ID) is received in the initial 228 context estalishment token, the receiver MUST return 229 GSS_S_CONTINUE_NEEDED major status, and the returned output token 230 MUST contain a KRB_ERROR message with the error code 231 KRB_AP_ERR_MSG_TYPE [KRBCLAR]. 232 2334.1.1. Authenticator Checksum 234 235 236Zhu Internet Draft 4 237 Kerberos Version 5 GSS-API November 2003 238 239 240 The authenticator in the KRB_AP_REQ message MUST include the 241 optional sequence number and the checksum field. The checksum field 242 is used to convey service flags, channel bindings, and optional 243 delegation information. The checksum type MUST be 0x8003. The 244 length of the checksum MUST be 24 octets when delegation is not 245 used. When delegation is used, a ticket-granting ticket will be 246 transferred in a KRB_CRED message. This ticket SHOULD have its 247 forwardable flag set. The KRB_CRED message MUST be encrypted in the 248 session key of the ticket used to authenticate the context. 249 250 The format of the authenticator checksum field is as follows. 251 252 Octet Name Description 253 ----------------------------------------------------------------- 254 0..3 Lgth Number of octets in Bnd field; Currently 255 contains hex value 10 00 00 00 (16, represented 256 in little-endian order) 257 4..19 Bnd Channel binding information, as described in 258 section 4.1.1.2. 259 20..23 Flags Four-octet context-establishment flags in little- 260 endian order as described in section 4.1.1.1. 261 24..25 DlgOpt The Delegation Option identifier (=1) [optional] 262 26..27 Dlgth The length of the Deleg field [optional] 263 28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional] 264 2654.1.1.1. Checksum Flags Field 266 267 The checksum "Flags" field is used to convey service options or 268 extension negotiation information. The following context 269 establishment flags are defined in [RFC-2744]. 270 271 Flag Name Value 272 --------------------------------- 273 GSS_C_DELEG_FLAG 1 274 GSS_C_MUTUAL_FLAG 2 275 GSS_C_REPLAY_FLAG 4 276 GSS_C_SEQUENCE_FLAG 8 277 GSS_C_CONF_FLAG 16 278 GSS_C_INTEG_FLAG 32 279 280 Context establishment flags are exposed to the calling application. 281 If the calling application desires a particular service option then 282 it requests that option via GSS_Init_sec_context() [RFC-2743]. An 283 implementation that supports a particular option or extension SHOULD 284 then set the appropriate flag in the checksum Flags field. 285 286 The most significant eight bits of the checksum flags are reserved 287 for future use. The receiver MUST ignore unknown checksum flags. 288 2894.1.1.2. Channel Binding Information 290 291 Channel bindings are user-specified tags to identify a given context 292 to the peer application. These tags are intended to be used to 293 294 295Zhu Internet Draft 5 296 Kerberos Version 5 GSS-API November 2003 297 298 299 identify the particular communications channel that carries the 300 context [RFC-2743] [RFC-2744]. 301 302 When using C language bindings, channel bindings are communicated to 303 the GSS-API using the following structure [RFC-2744]: 304 305 typedef struct gss_channel_bindings_struct { 306 OM_uint32 initiator_addrtype; 307 gss_buffer_desc initiator_address; 308 OM_uint32 acceptor_addrtype; 309 gss_buffer_desc acceptor_address; 310 gss_buffer_desc application_data; 311 } *gss_channel_bindings_t; 312 313 The member fields and constants used for different address types are 314 defined in [RFC-2744]. 315 316 The "Bnd" field contains the MD5 hash of channel bindings, taken 317 over all non-null components of bindings, in order of declaration. 318 Integer fields within channel bindings are represented in little- 319 endian order for the purposes of the MD5 calculation. 320 321 In computing the contents of the Bnd field, the following detailed 322 points apply: 323 324 (1) Each integer field shall be formatted into four octets, using 325 little endian octet ordering, for purposes of MD5 hash computation. 326 327 (2) All input length fields within gss_buffer_desc elements of a 328 gss_channel_bindings_struct even those which are zero-valued, shall 329 be included in the hash calculation; the value elements of 330 gss_buffer_desc elements shall be dereferenced, and the resulting 331 data shall be included within the hash computation, only for the 332 case of gss_buffer_desc elements having non-zero length specifiers. 333 334 (3) If the caller passes the value GSS_C_NO_BINDINGS instead of a 335 valid channel binding structure, the Bnd field shall be set to 16 336 zero-valued octets. 337 3384.2. Per-Message Tokens 339 340 Two classes of tokens are defined in this section: "MIC" tokens, 341 emitted by calls to GSS_GetMIC() and consumed by calls to 342 GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and 343 consumed by calls to GSS_Unwrap(). 344 345 The new per-message tokens introduced here do not include the 346 generic GSS-API token framing used by the context establishment 347 tokens. These new tokens are designed to be used with newer crypto 348 systems that can, for example, have variable-size checksums. 349 3504.2.1. Sequence Number 351 352 353Zhu Internet Draft 6 354 Kerberos Version 5 GSS-API November 2003 355 356 357 To distinguish intentionally-repeated messages from maliciously- 358 replayed ones, per-message tokens contain a sequence number field, 359 which is a 64 bit integer expressed in big endian order. After 360 sending a GSS_GetMIC() or GSS_Wrap() token, the sender's sequence 361 numbers are incremented by one. 362 3634.2.2. Flags Field 364 365 The "Flags" field is a one-octet integer used to indicate a set of 366 attributes for the protected message. For example, one flag is 367 allocated as the direction-indicator, thus preventing an adversary 368 from sending back the same message in the reverse direction and 369 having it accepted. 370 371 The meanings of bits in this field (the least significant bit is bit 372 0) are as follows: 373 374 Bit Name Description 375 --------------------------------------------------------------- 376 0 SentByAcceptor When set, this flag indicates the sender 377 is the context acceptor. When not set, 378 it indicates the sender is the context 379 initiator. 380 1 Sealed When set in Wrap tokens, this flag 381 indicates confidentiality is provided 382 for. It SHALL NOT be set in MIC tokens. 383 2 AcceptorSubkey A subkey asserted by the context acceptor 384 is used to protect the message. 385 386 The rest of available bits are reserved for future use and MUST be 387 cleared. The receiver MUST ignore unknown flags. 388 3894.2.3. EC Field 390 391 The "EC" (Extra Count) field is a two-octet integer field expressed 392 in big endian order. 393 394 In Wrap tokens with confidentiality, the EC field is used to encode 395 the number of octets in the filler, as described in section 4.2.4. 396 397 In Wrap tokens without confidentiality, the EC field is used to 398 encode the number of octets in the trailing checksum, as described 399 in section 4.2.4. 400 4014.2.4. Encryption and Checksum Operations 402 403 The encryption algorithms defined by the crypto profiles provide for 404 integrity protection [KCRYPTO]. Therefore no separate checksum is 405 needed. 406 407 The result of decryption can be longer than the original plaintext 408 [KCRYPTO] and the extra trailing octets are called "crypto-system 409 garbage". However, given the size of any plaintext data, one can 410 always find the next (possibly larger) size so that, when padding 411 412 413Zhu Internet Draft 7 414 Kerberos Version 5 GSS-API November 2003 415 416 417 the to-be-encrypted text to that size, there will be no crypto- 418 system garbage added [KCRYPTO]. 419 420 In Wrap tokens that provide for confidentiality, the first 16 octets 421 of the Wrap token (the "header", as defined in section 4.2.6), are 422 appended to the plaintext data before encryption. Filler octets can 423 be inserted between the plaintext data and the "header", and the 424 values and size of the filler octets are chosen by implementations, 425 such that there is no crypto-system garbage present after the 426 decryption. The resulting Wrap token is {"header" | 427 encrypt(plaintext-data | filler | "header")}, where encrypt() is the 428 encryption operation (which provides for integrity protection) 429 defined in the crypto profile [KCRYPTO], and the RRC field in the 430 to-be-encrypted header contains the hex value 00 00. 431 432 In Wrap tokens that do not provide for confidentiality, the checksum 433 is calculated first over the to-be-signed plaintext data, and then 434 the first 16 octets of the Wrap token (the "header", as defined in 435 section 4.2.6). Both the EC field and the RRC field in the token 436 header are filled with zeroes for the purpose of calculating the 437 checksum. The resulting Wrap token is {"header" | plaintext-data | 438 get_mic(plaintext-data | "header")}, where get_mic() is the 439 checksum operation for the required checksum mechanism of the chosen 440 encryption mechanism defined in the crypto profile [KCRYPTO]. 441 442 The parameters for the key and the cipher-state in the encrypt() and 443 get_mic() operations have been omitted for brevity. 444 445 For MIC tokens, the checksum is first calculated over the to-be- 446 signed plaintext data, and then the first 16 octets of the MIC 447 token, where the checksum mechanism is the required checksum 448 mechanism of the chosen encryption mechanism defined in the crypto 449 profile [KCRYPTO]. 450 451 The resulting Wrap and MIC tokens bind the data to the token header, 452 including the sequence number and the direction indicator. 453 4544.2.5. RRC Field 455 456 The "RRC" (Right Rotation Count) field in Wrap tokens is added to 457 allow the data to be encrypted in-place by existing [SSPI] 458 applications that do not provide an additional buffer for the 459 trailer (the cipher text after the in-place-encrypted data) in 460 addition to the buffer for the header (the cipher text before the 461 in-place-encrypted data). The resulting Wrap token in the previous 462 section, excluding the first 16 octets of the token header, is 463 rotated to the right by "RRC" octets. The net result is that "RRC" 464 octets of trailing octets are moved toward the header. Consider the 465 following as an example of this rotation operation: Assume that the 466 RRC value is 3 and the token before the rotation is {"header" | aa | 467 bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be 468 {"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb 469 | cc |...| hh} is used to indicate the octet sequence. 470 471 472Zhu Internet Draft 8 473 Kerberos Version 5 GSS-API November 2003 474 475 476 The RRC field is expressed as a two-octet integer in big endian 477 order. 478 479 The rotation count value is chosen by the sender based on 480 implementation details, and the receiver MUST be able to interpret 481 all possible rotation count values. 482 4834.2.6. Message Layouts 484 485 Per-message tokens start with a two-octet token identifier (TOK_ID) 486 field, expressed in big endian order. These tokens are defined 487 separately in subsequent sub-sections. 488 4894.2.6.1. MIC Tokens 490 491 Use of the GSS_GetMIC() call yields a token, separate from the user 492 data being protected, which can be used to verify the integrity of 493 that data as received. The token has the following format: 494 495 Octet no Name Description 496 ----------------------------------------------------------------- 497 0..1 TOK_ID Identification field. Tokens emitted by 498 GSS_GetMIC() contain the hex value 04 04 499 expressed in big endian order in this field. 500 2 Flags Attributes field, as described in section 501 4.2.2. 502 3..7 Filler Contains five octets of hex value FF. 503 8..15 SND_SEQ Sequence number field in clear text, 504 expressed in big endian order. 505 16..last SGN_CKSUM Checksum of octet 0..15 and the "to-be- 506 signed" data, as described in section 4.2.4. 507 508 The Filler field is included in the checksum calculation for 509 simplicity. 510 5114.2.6.2. Wrap Tokens 512 513 Use of the GSS_Wrap() call yields a token, which consists of a 514 descriptive header, followed by a body portion that contains either 515 the input user data in plaintext concatenated with the checksum, or 516 the input user data encrypted. The GSS_Wrap() token has the 517 following format: 518 519 Octet no Name Description 520 --------------------------------------------------------------- 521 0..1 TOK_ID Identification field. Tokens emitted by 522 GSS_Wrap() contain the the hex value 05 04 523 expressed in big endian order in this field. 524 2 Flags Attributes field, as described in section 525 4.2.2. 526 3 Filler Contains the hex value FF. 527 4..5 EC Contains the "extra count" field, in big 528 endian order as described in section 4.2.3. 529 6..7 RRC Contains the "right rotation count" in big 530 531 532Zhu Internet Draft 9 533 Kerberos Version 5 GSS-API November 2003 534 535 536 endian order, as described in section 4.2.5. 537 8..15 SND_SEQ Sequence number field in clear text, 538 expressed in big endian order. 539 16..last Data Encrypted data for Wrap tokens with 540 confidentiality, or plaintext data followed 541 by the checksum for Wrap tokens without 542 confidentiality, as described in section 543 4.2.4. 544 5454.3. Context Deletion Tokens 546 547 Context deletion tokens are empty in this mechanism. Both peers to 548 a security context invoke GSS_Delete_sec_context() [RFC-2743] 549 independently, passing a null output_context_token buffer to 550 indicate that no context_token is required. Implementations of 551 GSS_Delete_sec_context() should delete relevant locally-stored 552 context information. 553 5544.4. Token Identifier Assignment Considerations 555 556 Token identifiers (TOK_ID) from 0x60 0x00 through 0x60 0xFF 557 inclusive are reserved and SHALL NOT be assigned. Thus by examining 558 the first two octets of a token, one can tell unambiguously if it is 559 wrapped with the generic GSS-API token framing. 560 5615. Parameter Definitions 562 563 This section defines parameter values used by the Kerberos V5 GSS- 564 API mechanism. It defines interface elements in support of 565 portability, and assumes use of C language bindings per [RFC-2744]. 566 5675.1. Minor Status Codes 568 569 This section recommends common symbolic names for minor_status 570 values to be returned by the Kerberos V5 GSS-API mechanism. Use of 571 these definitions will enable independent implementers to enhance 572 application portability across different implementations of the 573 mechanism defined in this specification. (In all cases, 574 implementations of GSS_Display_status() will enable callers to 575 convert minor_status indicators to text representations.) Each 576 implementation should make available, through include files or other 577 means, a facility to translate these symbolic names into the 578 concrete values which a particular GSS-API implementation uses to 579 represent the minor_status values specified in this section. 580 581 It is recognized that this list may grow over time, and that the 582 need for additional minor_status codes specific to particular 583 implementations may arise. It is recommended, however, that 584 implementations should return a minor_status value as defined on a 585 mechanism-wide basis within this section when that code is 586 accurately representative of reportable status rather than using a 587 separate, implementation-defined code. 588 5895.1.1. Non-Kerberos-specific codes 590 591 592Zhu Internet Draft 10 593 Kerberos Version 5 GSS-API November 2003 594 595 596 597 GSS_KRB5_S_G_BAD_SERVICE_NAME 598 /* "No @ in SERVICE-NAME name string" */ 599 GSS_KRB5_S_G_BAD_STRING_UID 600 /* "STRING-UID-NAME contains nondigits" */ 601 GSS_KRB5_S_G_NOUSER 602 /* "UID does not resolve to username" */ 603 GSS_KRB5_S_G_VALIDATE_FAILED 604 /* "Validation error" */ 605 GSS_KRB5_S_G_BUFFER_ALLOC 606 /* "Couldn't allocate gss_buffer_t data" */ 607 GSS_KRB5_S_G_BAD_MSG_CTX 608 /* "Message context invalid" */ 609 GSS_KRB5_S_G_WRONG_SIZE 610 /* "Buffer is the wrong size" */ 611 GSS_KRB5_S_G_BAD_USAGE 612 /* "Credential usage type is unknown" */ 613 GSS_KRB5_S_G_UNKNOWN_QOP 614 /* "Unknown quality of protection specified" */ 615 6165.1.2. Kerberos-specific-codes 617 618 GSS_KRB5_S_KG_CCACHE_NOMATCH 619 /* "Client principal in credentials does not match 620 specified name" */ 621 GSS_KRB5_S_KG_KEYTAB_NOMATCH 622 /* "No key available for specified service principal" */ 623 GSS_KRB5_S_KG_TGT_MISSING 624 /* "No Kerberos ticket-granting ticket available" */ 625 GSS_KRB5_S_KG_NO_SUBKEY 626 /* "Authenticator has no subkey" */ 627 GSS_KRB5_S_KG_CONTEXT_ESTABLISHED 628 /* "Context is already fully established" */ 629 GSS_KRB5_S_KG_BAD_SIGN_TYPE 630 /* "Unknown signature type in token" */ 631 GSS_KRB5_S_KG_BAD_LENGTH 632 /* "Invalid field length in token" */ 633 GSS_KRB5_S_KG_CTX_INCOMPLETE 634 /* "Attempt to use incomplete security context" */ 635 6365.2. Buffer Sizes 637 638 All implementations of this specification shall be capable of 639 accepting buffers of at least 16K octets as input to GSS_GetMIC(), 640 GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting 641 the output_token generated by GSS_Wrap() for a 16K octet input 642 buffer as input to GSS_Unwrap(). Support for larger buffer sizes is 643 optional but recommended. 644 6456. Backwards Compatibility Considerations 646 647 The new token formats defined in this document will only be 648 recognized by new implementations. To address this, implementations 649 can always use the explicit sign or seal algorithm in [RFC-1964] 650 651 652Zhu Internet Draft 11 653 Kerberos Version 5 GSS-API November 2003 654 655 656 when the key type corresponds to "older" enctypes. An alternative 657 approach might be to retry sending the message with the sign or seal 658 algorithm explicitly defined as in [RFC-1964]. However this would 659 require either the use of a mechanism such as [RFC-2478] to securely 660 negotiate the method or the use out of band mechanism to choose 661 appropriate mechanism. For this reason, it is RECOMMENDED that the 662 new token formats defined in this document SHOULD be used only if 663 both peers are known to support the new mechanism during context 664 negotiation because of, for example, the use of "new" enctypes. 665 666 GSS_Unwrap() or GSS_Verify_MIC() can process a message token as 667 follows: it can look at the first octet of the token header, if it 668 is 0x60 then the token must carry the generic GSS-API pseudo ASN.1 669 framing, otherwise the first two octets of the token contain the 670 TOK_ID that uniquely identify the token message format. 671 6727. Security Considerations 673 674 Under the current mechanism, no negotiation of algorithm types 675 occurs, so server-side (acceptor) implementations cannot request 676 that clients not use algorithm types not understood by the server. 677 However, administration of the server's Kerberos data (e.g., the 678 service key) has to be done in communication with the KDC, and it is 679 from the KDC that the client will request credentials. The KDC 680 could therefore be given the task of limiting session keys for a 681 given service to types actually supported by the Kerberos and GSSAPI 682 software on the server. 683 684 This does have a drawback for cases where a service principal name 685 is used both for GSSAPI-based and non-GSSAPI-based communication 686 (most notably the "host" service key), if the GSSAPI implementation 687 does not understand (for example) AES [AES-KRB5] but the Kerberos 688 implementation does. It means that AES session keys cannot be 689 issued for that service principal, which keeps the protection of 690 non-GSSAPI services weaker than necessary. KDC administrators 691 desiring to limit the session key types to support interoperability 692 with such GSSAPI implementations should carefully weigh the 693 reduction in protection offered by such mechanisms against the 694 benefits of interoperability. 695 6968. Acknowledgments 697 698 Ken Raeburn and Nicolas Williams corrected many of our errors in the 699 use of generic profiles and were instrumental in the creation of this 700 memo. 701 702 The text for security considerations was contributed by Ken Raeburn. 703 704 Sam Hartman and Ken Raeburn suggested the "floating trailer" idea, 705 namely the encoding of the RRC field. 706 707 Sam Hartman and Nicolas Williams recommended the replacing our 708 earlier key derivation function for directional keys with different 709 710 711Zhu Internet Draft 12 712 Kerberos Version 5 GSS-API November 2003 713 714 715 key usage numbers for each direction as well as retaining the 716 directional bit for maximum compatibility. 717 718 Paul Leach provided numerous suggestions and comments. 719 720 Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided 721 valuable inputs on this memo. 722 723 Jeffrey Hutzelman provided comments on channel bindings and suggested 724 many editorial changes. 725 726 Luke Howard provided implementations of this memo for the Heimdal 727 code base, and helped inter-operability testing with the Microsoft 728 code base, together with Love Hornquist Astrand. These experiments 729 formed the basis of this memo. 730 731 Martin Rex provided suggestions of TOK_ID assignment recommendations 732 thus the token tagging in this memo is unambiguous if the token is 733 wrapped with the pseudo ASN.1 header. 734 735 This document retains some of the text of RFC-1964 in relevant 736 sections. 737 7389. References 739 7409.1. Normative References 741 742 [RFC-2026] Bradner, S., "The Internet Standards Process -- Revision 743 3", BCP 9, RFC 2026, October 1996. 744 745 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 748 [RFC-2743] Linn, J., "Generic Security Service Application Program 749 Interface Version 2, Update 1", RFC 2743, January 2000. 750 751 [RFC-2744] Wray, J., "Generic Security Service API Version 2: C- 752 bindings", RFC 2744, January 2000. 753 754 [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 755 RFC 1964, June 1996. 756 757 [KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for 758 Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in 759 progress. 760 761 [KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S., 762 Raeburn, K., "The Kerberos Network Authentication Service (V5)", 763 draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002. 764 Work in progress. 765 766 [AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft- 767 raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress. 768 769 770Zhu Internet Draft 13 771 Kerberos Version 5 GSS-API November 2003 772 773 774 775 [RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API 776 Negotiation Mechanism", RFC 2478, December 1998. 777 7789.2. Informative References 779 780 [SSPI] Leach, P., "Security Service Provider Interface", Microsoft 781 Developer Network (MSDN), April 2003. 782 78310. Author's Address 784 785 Larry Zhu 786 One Microsoft Way 787 Redmond, WA 98052 - USA 788 EMail: LZhu@microsoft.com 789 790 Karthik Jaganathan 791 One Microsoft Way 792 Redmond, WA 98052 - USA 793 EMail: karthikj@microsoft.com 794 795 Sam Hartman 796 Massachusetts Institute of Technology 797 77 Massachusetts Avenue 798 Cambridge, MA 02139 - USA 799 Email: hartmans@MIT.EDU 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826Zhu Internet Draft 14 827 Kerberos Version 5 GSS-API November 2003 828 829 830 831Full Copyright Statement 832 833 Copyright (C) The Internet Society (date). All Rights Reserved. 834 835 This document and translations of it may be copied and furnished to 836 others, and derivative works that comment on or otherwise explain it 837 or assist in its implementation may be prepared, copied, published 838 and distributed, in whole or in part, without restriction of any 839 kind, provided that the above copyright notice and this paragraph 840 are included on all such copies and derivative works. However, this 841 document itself may not be modified in any way, such as by removing 842 the copyright notice or references to the Internet Society or other 843 Internet organizations, except as needed for the purpose of 844 developing Internet standards in which case the procedures for 845 copyrights defined in the Internet Standards process must be 846 followed, or as required to translate it into languages other than 847 English. 848 849 The limited permissions granted above are perpetual and will not be 850 revoked by the Internet Society or its successors or assigns. 851 852 This document and the information contained herein is provided on an 853 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 854 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 855 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 856 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 857 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884Zhu Internet Draft 15 885