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