idnits 2.17.1 draft-ietf-cat-krb5gss-mech2-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The abstract seems to indicate that this document obsoletes RFC1964, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 1998) is 9311 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNIVERSAL 4' is mentioned on line 693, but not defined == Unused Reference: 'RFC1510' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'RFC1964' is defined on line 782, but no explicit reference was found in the text == Unused Reference: 'RFC2078' is defined on line 785, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2078 (Obsoleted by RFC 2743) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Tom Yu 3 Common Authentication Technology WG MIT 4 draft-ietf-cat-krb5gss-mech2-01.txt 22 October 1998 6 The Kerberos Version 5 GSSAPI Mechanism, Version 2 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, and 12 its working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To view the entire list of current Internet-Drafts, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), 23 ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), 24 ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 26 Comments on this document should be sent to 27 "ietf-cat-wg@lists.stanford.edu", the IETF Common Authentication 28 Technology WG discussion list. 30 ABSTRACT 32 This specification defines protocols, procedures, and conventions to be 33 employed by peers implementing the Generic Security Service Application 34 Program Interface (as specified in RFC 2078) when using Kerberos 35 Version 5 technology (as specified in RFC 1510). This obsoletes 36 RFC 1964. 38 ACKNOWLEDGEMENTS 40 Much of the material in this specification is based on work done for 41 Cygnus Solutions by Marc Horowitz. 43 1. Introduction 45 The previous GSSAPI Kerberos V5 mechanism, described in RFC 1964, has 46 several flaws which make integrating new encryption types (enctypes) 47 more difficult. The context establishment token format requires that 48 the authenticator of AP-REQ messages contain a cleartext data structure 49 in its checksum field, which is a needless and potentially confusing 50 overloading of that field. The number assignments for checksum 51 algorithms are also inconsistent between the Kerberos protocol and the 52 GSSAPI mechanism. The previous mechanism also assumes that both 53 checksums and cryptosystem blocksizes are eight bytes. There are no 54 backward-compatible ways to remedy these shortcomings. 56 Defining all GSSAPI tokens for the new Kerberos V5 mechanism in terms of 57 the Kerberos protocol specification ensures that new encryption types 58 and checksum types may be automatically used as they are defined for the 59 Kerberos protocol. 61 2. Token Formats 63 All tokens, not just the initial token, are framed as the 64 InitialContextToken described in RFC 2078 section 3.1. The 65 innerContextToken element of the token will not itself be encoded in 66 ASN.1, with the exception of caller-provided application data. The 67 rationale for avoiding the use of ASN.1 in the inner token is that some 68 implementors may wish to implement this mechanism in a kernel or other 69 similarly constrained application where full ASN.1 encoding may be 70 cumbersome. Also, ASN.1 encoders and decoders are very difficult to 71 implement completely correctly, so keeping ASN.1 usage to a minimum 72 decreases the probability of bugs in the implementation of the 73 mechanism. 75 All integer fields are in network byte order. All other fields have the 76 fixed size shown. 78 2.1. Packet Notation 80 The order of transmission of this protocol is described at the octet 81 level. Packet diagrams depict bits in the order of transmission, 82 assuming that individual octets are transmitted with the most 83 significant bit (MSB) first. The diagrams read from left to right and 84 from top to bottom, as in printed English. When bits are numbered, they 85 are numbered in the order of transmission, not the order of the 86 significance of the bits; thus, bit number 0 is the MSB of the first 87 octet. Numbers prefixed by the string "0x" are in hexadecimal notation, 88 as in the C programming language. Fixed-length fields that appear to be 89 aligned on 32-bit boundaries are not necessarily aligned if they follow 90 a variable length field. No padding should be used to force alignment 91 of such fields to a 32-bit boundary. 93 2.2. Mechanism OID 95 The Object Identifier (OID) of the new krb5 v2 mechanism is: 97 {iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) 98 krb5v2(3)} 100 2.3. Context Establishment 102 2.3.1. Option Format 104 Context establishment tokens, i.e., the initial ones that the 105 GSS_Init_sec_context() and the GSS_Accept_sec_context() calls emit while 106 a security context is being set up, may contain options that influence 107 the subsequent behavior of the context. This document describes only a 108 small set of options, but additional types may be added by documents 109 intended to supplement this one. The generic format is as follows: 111 0 1 2 3 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | option type | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | option length | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | option data | 119 / : / 120 / : / 121 | option data | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 option type (32 bits) 125 The type identifier of the following option. 127 option length (32 bits) 128 The length in bytes of the following option. 130 option data (variable length) 131 The actual option data. 133 Any number of options may appear in an initator or acceptor token. The 134 final option in a token must be the null option, in order to mark the 135 end of the list. 137 2.3.1.1. Delegated Credentials Option 139 Only the initiator may use this option. The format of the delegated 140 credentials option is as follows: 142 0 1 2 3 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | option type = 0x00000001 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | KRB-CRED length | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | KRB-CRED message | 150 / : / 151 / : / 152 | KRB-CRED message | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 option type (32 bits) 156 The option type for this option shall be 0x00000001. 158 KRB-CRED length (32 bits) 159 The length in bytes of the following KRB-CRED message. 161 KRB-CRED message (variable length) 162 The option data for this option shall be the KRB-CRED message that 163 contains the credentials being delegated (forwarded) to the context 164 acceptor. Only the initiator may use this option. 166 2.3.1.2. Null Option 168 The Null option terminates the option list, and must be used by both the 169 initiator and the acceptor. Its format is as follows: 171 0 1 2 3 172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | option type = 0 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | length = 0 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 option type (32 bits) 180 The option type of this option must be zero. 182 option length (32 bits) 183 The length of this option must be zero. 185 2.3.2. Initial Token 187 This is the initial token sent by the context initiator, generated by 188 GSS_Init_sec_context(). 190 0 1 2 3 191 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | initial token id | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | reserved flag bits |I|C|S|R|M|D| 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | checksum type count | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | checksum type list | 200 / : / 201 / : / 202 | checksum type list | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | options | 205 / : / 206 / : / 207 | options | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | AP-REQ length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | AP-REQ data | 212 / : / 213 / : / 214 | AP-REQ data | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 initial token ID (32 bits) 218 Contains the integer 0x01010101, which identifies this as the 219 initial token in the context setup. 221 reserved flag bits (26 bits) 222 These bits are reserved for future expansion. They must be set to 223 zero by the initiator and be ignored by the acceptor. 225 I flag (1 bit) 226 0x00000020 -- GSS_C_INTEG_FLAG 228 C flag (1 bit) 229 0x00000010 -- GSS_C_CONF_FLAG 231 S flag (1 bit) 232 0x00000008 -- GSS_C_SEQUENCE_FLAG 234 R flag (1 bit) 235 0x00000004 -- GSS_C_REPLAY_FLAG 237 M flag (1 bit) 238 0x00000002 -- GSS_C_MUTUAL_FLAG 240 D flag (1 bit) 241 0x00000001 -- GSS_C_DELEG_FLAG; This flag must be set if the 242 "delegated credentials" option is included. 244 checksum type count (32 bits) 245 The number of checksum types supported by the initiator. 247 checksum type list (variable length) 248 A list of Kerberos checksum types, as defined in RFC 1510 249 section 6.4. These checksum types must be collision-proof and 250 keyed with the context key. Each checksum type number shall be 32 251 bits wide. This list should contain all the checksum types 252 supported by the initiator. 254 options (variable length) 255 The option format will be described later. 257 AP-REQ length (32 bits) 258 The length of the following KRB_AP_REQ message. 260 AP-REQ data (variable length) 261 The AP-REQ message as described in RFC 1510. The checksum in the 262 authenticator will be computed over the items listed in the next 263 section. 265 The optional sequence number field shall be used in the AP-REQ. The 266 initiator should generate a subkey in the authenticator, and the 267 acceptor should generate a subkey in the AP-REP. The key used for the 268 per-message tokens will be the AP-REP subkey, or if that is not present, 269 the authenticator subkey, or if that is not present, the session key. 270 When subkeys are generated, it is strongly recommended that they be of 271 the same type as the associated session key. 273 2.3.2.1. Data to be Checksummed in AP-REQ 275 The checksum in the AP-REQ message is calculated over the following 276 items. Like in the actual tokens, no padding should be added to force 277 integer fields to align on 32 bit boundaries. This particular set of 278 data should not be sent as a part of any token; it merely specifies what 279 is to be checksummed in the AP-REQ. 281 0 1 2 3 282 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | initiator address type | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | initiator address length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | initiator address | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | acceptor address type | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | acceptor address length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | acceptor address | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | application data | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | initial token id | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | flags | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | checksum type count | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | checksum type list | 305 / : / 306 / : / 307 | checksum type list | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | options | 310 / : / 311 / : / 312 | options | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 initiator address type (32 bits) 316 The initiator address type, as defined in the Kerberos protocol 317 specification. If no initiator address is provided, this must be 318 zero. 320 initiator address length (32 bits) 321 The length in bytes of the following initiator address. If there 322 is no inititator address provided, this must be zero. 324 initiator address (variable length) 325 The actual initiator address, in network byte order. 327 acceptor address type (32 bits) 328 The acceptor address type, as defined in the Kerberos protocol 329 specification. If no acceptor address is provided, this must be 330 zero. 332 acceptor address length (32 bits) 333 The length in bytes of the following acceptor address. This must 334 be zero is there is no acceptor address provided. 336 initiator address (variable length) 337 The actual acceptor address, in network byte order. 339 applicatation data (variable length) 340 The application data, if provided, encoded as a ASN.1 octet string 341 using DER. If no application data are passed as input channel 342 bindings, this shall be a zero-length ASN.1 octet string. 344 initial token ID (32 bits) 345 The initial token ID from the initial token. 347 flags (32 bits) 348 The context establishment flags from the initial token. 350 checksum type count (32 bits) 351 The number of checksum types supported by the initiator. 353 checksum type list (variable length) 354 The same list of checksum types contained in the initial token. 356 options (variable length) 357 The options list from the initial token. 359 2.3.3. Response Token 361 This is the reponse token sent by the context acceptor, if mutual 362 authentication is enabled. 364 0 1 2 3 365 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | response token id | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | reserved flag bits |D|E| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | checksum type count | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | checksum type list | 374 / : / 375 / : / 376 | checksum type list | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | options | 379 / : / 380 / : / 381 | options | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | AP-REP or KRB-ERROR length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | AP-REP or KRB-ERROR data | 386 / : / 387 / : / 388 | AP-REP or KRB-ERROR data | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | MIC length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | MIC data | 393 / : / 394 / : / 395 | MIC data | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 response token id (32 bits) 399 Contains the integer 0x02020202, which identifies this as the 400 response token in the context setup. 402 reserved flag bits (30 bits) 403 These bits are reserved for future expansion. They must be set to 404 zero by the acceptor and be ignored by the initiator. 406 D flag -- delegated creds accepted (1 bit) 407 0x00000002 -- If this flag is set, the acceptor processed the 408 delegated credentials, and GSS_C_DELEG_FLAG should be returned to 409 the caller. 411 E flag -- error (1 bit) 412 0x00000001 -- If this flag is set, a KRB-ERROR message shall be 413 present, rather than an AP-REP message. If this flag is not set, 414 an AP-REP message shall be present. 416 checksum type count (32 bits) 417 The number of checksum types supported by both the initiator and 418 the acceptor. 420 checksum type list (variable length) 421 A list of Kerberos checksum types, as defined in RFC 1510 422 section 6.4. These checksum types must be collision-proof and 423 keyed with the context key. Each checksum type number shall be 32 424 bits wide. This list should contain the intersection of the list 425 of checksum types specified by the initiator in the initial token 426 and the list of checksum types supported by the acceptor. 428 options (variable length) 429 The option list, as described earlier. At this time, no options 430 are defined for the acceptor, but an implementation might make use 431 of these options to acknowledge an option from the initial token. 432 After all the options are specified, a null option must be used to 433 terminate the list. 435 AP-REP or KRB-ERROR length (32 bits) 436 Depending on the value of the error flag, length in bytes of the 437 AP-REP or KRB-ERROR message. 439 AP-REP or KRB-ERROR data (variable length) 440 Depending on the value of the error flag, the AP-REP or KRB-ERROR 441 message as described in RFC 1510. If this field contains an AP-REP 442 message, the sequence number field in the AP-REP shall be filled. 443 If this is a KRB-ERROR message, no further fields will be in this 444 message. 446 MIC length (32 bits) 447 The number of bytes in the following MIC data field. 449 MIC data (variable length) 450 A MIC token, as described in section 2.4.2, computed over the 451 concatentation of the response token ID, flags, checksum length and 452 type fields, and all option fields. This field and the preceding 453 length field must not be present if the error flag is set. 455 2.4. Per-message Tokens 457 2.4.1. Sequence Number Usage 459 Sequence numbers for per-message tokens are 32 bit unsigned integers, 460 which are incremented by 1 after each token. An overflow condition 461 should result in a wraparound of the sequence number to zero. The 462 initiator and acceptor each keep their own sequence numbers per 463 connection. 465 2.4.2. MIC Token 467 Use of the GSS_GetMIC() call yields a token, separate from the user data 468 being protected, which can be used to verify the integrity of that data 469 when it is received. The MIC token has the following format: 471 0 1 2 3 472 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | MIC token id | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | sequence number | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | direction | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | checksum type | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | checksum length | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | checksum data | 485 / : / 486 / : / 487 | checksum data | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 MIC token id (32 bits) 491 Contains the integer 0x03030303, which identifies this as a MIC 492 token. 494 sequence number (32 bits) 495 The sequence number. 497 direction (32 bits) 498 All bits in this field shall be zero if the message is sent from 499 the context initiator. If the message is sent from the context 500 acceptor, all bits shall be one. 502 checksum type (32 bits) 503 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This 504 checksum type must be collision-proof and keyed with the context 505 key. 507 checksum length (32 bits) 508 The number of bytes in the following checksum data field. 510 checksum data (variable length) 511 The checksum itself, as defined in RFC 1510 section 6.4. The 512 checksum is calculated over the encoding described in the following 513 section. The key usage GSS_TOK_MIC -- 22 [XXX need to register 514 this] shall be used. 516 The mechanism implementation should only use checksum types which it 517 knows to be valid for both peers. If mutual authentication is used, 518 then any checksum type specified by the acceptor may be used. If mutual 519 authentication is not used XXX what do we do then? This seems to be a 520 more general issue than just GSSAPI. What checksum type did we use for 521 the authenticator checksum? 522 2.4.2.1. Data to be Checksummed in MIC Token 524 The checksum in the MIC token shall be calculated over the following 525 elements. This set of data is not actually included in the token as is; 526 the description only appears for the purpose of specifying the method of 527 calculating the checksum. 529 0 1 2 3 530 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | MIC token id | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | sequence number | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | direction | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | application data | 539 / : / 540 / : / 541 | application data | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 MIC token ID (32 bits) 545 The MIC token ID from the MIC message. 547 sequence number (32 bits) 548 The sequence number. 550 direction (32 bits) 551 All bits in this field shall be zero if the message is sent from 552 the context initiator. If the message is sent from the context 553 acceptor, all bits shall be one. 555 application data (variable length) 556 The application-supplied data, encoded as an ASN.1 octet string 557 using DER. 559 2.4.3. Wrap Token 561 Use of the GSS_Wrap() call yields a token which encapsulates the input 562 user data (optionally encrypted) along with associated integrity check 563 quantities. 565 2.4.3.1. Wrap Token With Integrity Only 566 0 1 2 3 567 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | integrity wrap token id | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | sequence number | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | direction | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | application data | 576 / : / 577 / : / 578 | application data | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | checksum type | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 | checksum length | 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | checksum data | 585 / : / 586 / : / 587 | checksum data | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 integrity wrap token id (32 bits) 591 Contains the integer 0x04040404, which identifies this as a Wrap 592 token with integrity only. 594 sequence number (32 bits) 595 The sequence number. 597 direction (32 bits) 598 All bits in this field shall be zero if the message is sent from 599 the context initiator. If the message is sent from the context 600 acceptor, all bits shall be one. 602 application data (variable length) 603 The application-supplied data, encoded as an ASN.1 octet string 604 using DER. 606 checksum type (32 bits) 607 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This 608 checksum type must be collision-proof and keyed with the context 609 key. The checksum type implies the length of the checksum data. 611 checksum length (32 bits) 612 The number of bytes in the following checksum data field. 614 checksum data (variable length) 615 The checksum itself, as defined in RFC 1510 section 6.4, computed 616 over the concatenation of the token ID, sequence number, direction 617 field, application data length, and application data, as in the MIC 618 token checksum in the previous section. The key usage 619 GSS_TOK_WRAP_INTEG -- 23 [XXX need to register this] shall be used. 621 The mechanism implementation should only use checksum types which it 622 knows to be valid for both peers, as described for MIC tokens. 624 2.4.3.2. Wrap Token With Integrity and Encryption 626 0 1 2 3 627 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | encrypted wrap token id | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | encrypted data | 632 / : / 633 / : / 634 | encrypted data | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 encrypted wrap token id (32 bits) 638 Contains the integer 0x05050505, which identifies this as a Wrap 639 token with integrity and encryption. 641 encrypted data length (32 bits) 642 The number of bytes in the following encrypted data field. 644 encrypted data (variable length) 645 The encrypted data itself, as defined in RFC 1510 section 6.3. 646 Note that this is not the ASN.1 type EncryptedData as defined in 647 RFC 1510 section 6.1, but rather the bare ciphertext without 648 framing, encryption type, or kvno information. The encryption is 649 performed using the key/enctype exchanged during context setup. 650 The key usage GSS_TOK_WRAP_PRIV -- 24 [XXX need to register this] 651 shall be used. The actual data to be encrypted are specified 652 below. 654 2.4.3.2.1. Data to be Encrypted in Wrap Token 656 0 1 2 3 657 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | sequence number | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | direction | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | application data | 664 / : / 665 / : / 666 | application data | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 sequence number (32 bits) 670 The sequence number. 672 direction (32 bits) 673 All bits in this field shall be zero if the message is sent from 674 the context initiator. If the message is sent from the context 675 acceptor, all bits shall be one. 677 application data (variable length) 678 The application-supplied data, encoded as an ASN.1 octet string 679 using DER. 681 3. ASN.1 Encoding of Octet Strings 683 In order to encode arbitirarly-sized application data, ASN.1 octet 684 string encoding is in this protocol. The Distinguished Encoding Rules 685 (DER) shall always be used in such cases. For reference purposes, the 686 DER encoding of an ASN.1 octet string, adapted from ISO/IEC 8825-1, 687 follows: 689 +--------+-------//-------+-------//-------+ 690 |00000100| length octets |contents octets | 691 +--------+-------//-------+-------//-------+ 692 | 693 +-- identifier octet = 0x04 = [UNIVERSAL 4] 695 In this section only, the bits in each octet shall be numbered as in the 696 ASN.1 specification, from 8 to 1, with bit 8 being the MSB of the octet, 697 and with bit 1 being the LSB of the octet. 699 identifier octet (8 bits) 700 Contains the constant 0x04, the tag for primitive encoding of an 701 octet string with the default (UNIVERSAL 4) tag. 703 length octets (variable length) 704 Contains the length of the contents octets, in definite form (since 705 this encoding uses DER). 707 contents octets (variable length) 708 The contents of the octet string. 710 The length octets shall consist of either a short form (one byte only), 711 which is to be used only if the number of octets in the contents octets 712 is less than or equal to 127, or a long form, which is to be used in all 713 other cases. The short form shall consist of a single octet with bit 8 714 (the MSB) equal to zero, and the remaining bits encoding the number of 715 contents octets (which may be zero) as an unsigned binary integer. 717 The long form shall consist of an initial octet and one or more 718 subsequent octets. The first octet shall have bit 8 (the MSB) set to 719 one, and the remaining bits shall encode the number of subsequent octets 720 in the length encoding as an unsigned binary integer. The length must 721 be encoded in the minimum number of octets. An initial octet of 0xFF is 722 reserved by the ASN.1 specification. Bits 8 to 1 of the first 723 subsequent octet, followed by bits 8 to 1 of each subsequent octet in 724 order, shall be the encoding of an unsigned binary integer, with bit 8 725 of the first octet being the most significant bit. Thus, the length 726 encoding within is in network byte order. 728 An initial length octet of 0x80 shall not be used, as that is reserved 729 by the ASN.1 specification for indefinite lengths in conjunction with 730 constructed contents encodings, which are not to be used with DER. 732 4. Name Types 734 The name types and forms for this mechanism will be basically identical 735 to those specified in RFC 1964. The actual text describing these will 736 be included later. 738 5. Kerberos Protocol Dependencies 740 This protocol makes several assumptions about the Kerberos protocol, 741 which may require changes to the successor of RFC 1510. 743 Sequence numbers, checksum types, and address types are assumed to be no 744 wider than 32 bits. The Kerberos protocol specification might need to 745 be modified to accomodate this. This obviously requires some further 746 discussion. 748 Key usages need to be registered within the Kerberos protocol for use 749 with GSSAPI per-message tokens. The current specification of the 750 Kerberos protocol does not include descriptions of key derivations or 751 key usages, but planned revisions to the protocol will include them. 753 This protocol also makes the assumption that any cryptosystem used with 754 the session key will include integrity protection, i.e., it assumes that 755 no "raw" cryptosystems will be used. 757 6. Security Considerations 759 The GSSAPI is a security protocol; therefore, security considerations 760 are discussed throughout this document. The old Kerberos 5 GSSAPI 761 mechanism's constraints on possible cryptosystems and checksum types do 762 not permit it to be readily extended to accomodate more secure 763 cryptographic technologies with larger checksums or encryption block 764 sizes. Sites are strongly encouraged to adopt the mechanism specified 765 in this document in the light of recent publicity about the deficiencies 766 of DES. 768 7. References 770 [ISOIEC8824-1:1995] ISO/IEC, "Information technology -- Abstract Syntax 771 Notation One (ASN.1): Specification of basic notation", 772 ISO/IEC 8824-1:1995. 774 [ISOIEC8825-1:1995] ISO/IEC, "Information technology -- ASN.1 encoding 775 rules: Specification of Basic Encoding Rules (BER), Canonical Encoding 776 Rules (CER) and Distinguished Encoding Rules (DER)", 777 ISO/IEC 8825-1:1995. 779 [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication 780 Service (V5)", RFC 1510. 782 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 783 RFC 1964. 785 [RFC2078] Linn, J., "Generic Security Service Application Program 786 Interface, Version 2", RFC 2078 788 8. Author's Address 789 Tom Yu 790 Massachusetts Institute of Technology 791 Room E40-345 792 77 Massachusetts Avenue 793 Cambridge, MA 02139 794 USA 796 email: tlyu@mit.edu 797 phone: +1 617 253 1753