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