idnits 2.17.1 draft-ietf-cat-krb5gss-mech2-00.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-25) 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. == 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 (7 August 1998) is 9393 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) == Unused Reference: 'RFC1510' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC1964' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC2078' is defined on line 699, 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: 9 errors (**), 0 flaws (~~), 4 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-00.txt 7 August 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. [XXX not quite yet because it's still missing some sections] 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. The rationale for not using ASN.1 in the inner token is that 67 some implementors may wish to implement this mechanism in a kernel or 68 other similarly constrained application where ASN.1 encoding may be 69 cumbersome. Also, ASN.1 encoders and decoders are very difficult to 70 implement completely correctly, so keeping ASN.1 usage to a minimum 71 decreases the probability of bugs in the implementation of the 72 mechanism. 74 All integer fields are in network byte order. All other fields have the 75 fixed size shown. 77 2.1. Packet Notation 79 The order of transmission of this protocol is described at the octet 80 level. Packet diagrams depict bits in the order of transmission, 81 assuming that individual octets are transmitted with the most 82 significant bit (MSB) first. The diagrams read from left to right and 83 from top to bottom, as in printed English. When bits are numbered, they 84 are numbered in the order of transmission, not the order of the 85 significance of the bits; thus, bit number 0 is the MSB of the first 86 octet. Numbers prefixed by the string "0x" are in hexadecimal notation, 87 as in the C programming language. Fixed-length fields that appear to be 88 aligned on 32-bit boundaries are not necessarily aligned if they follow 89 a variable length field. No padding should be used to force alignment 90 of such fields to a 32-bit boundary. 92 2.2. Mechanism OID 94 The Object Identifier (OID) of the new krb5 v2 mechanism is: 96 {iso(1) member-body(2) US(840) mit(113554) infosys(1) gssapi(2) 97 krb5v2(3)} 99 2.3. Context Establishment 101 2.3.1. Option Format 103 Options contained in context establishment tokens shall have the 104 following format: 106 0 1 2 3 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | option type | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | option length | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | option data | 114 / : / 115 / : / 116 | option data | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 option type (32 bits) 120 The type identifier of the following option. 122 option length (32 bits) 123 The length in bytes of the following option. 125 option data (variable length) 126 The actual option data. 128 Any number of options may appear in an initator or acceptor token. The 129 final option in a token must be the null option, in order to mark the 130 end of the list. 132 2.3.1.1. Delegated Credentials Option 134 Only the initiator may use this option. The format of the delegated 135 credentials option is as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | option type = 0x00000001 | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | KRB-CRED length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | KRB-CRED message | 145 / : / 146 / : / 147 | KRB-CRED message | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 option type (32 bits) 151 The option type for this option shall be 0x00000001. 153 KRB-CRED length (32 bits) 154 The length in bytes of the following KRB-CRED message. 156 KRB-CRED message (variable length) 157 The option data for this option shall be the KRB-CRED message that 158 contains the credentials being delegated (forwarded) to the context 159 acceptor. Only the initiator may use this option. 161 2.3.1.2. Null Option 163 The Null option terminates the option list: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | option type = 0 | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | length = 0 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 option type (32 bits) 174 The option type of this option must be zero. 176 option length (32 bits) 177 The length of this option must be zero. 179 2.3.2. Initial Token 181 This is the initial token sent by the context initiator, generated by 182 GSS_Init_sec_context(). 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | initial token id | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | flags | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | checksum type count | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | checksum type list | 194 / : / 195 / : / 196 | checksum type list | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | options | 199 / : / 200 / : / 201 | options | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | AP-REQ length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | AP-REQ data | 206 / : / 207 / : / 208 | AP-REQ data | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 initial token ID (32 bits) 212 Contains the integer 0x01010101, which identifies this as the 213 initial token in the context setup. 215 flags (32 bits) 216 Context establishment flags, with values as defined by RFC 1509. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | zero padding |I|C|S|R|M|D| 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 I GSS_C_INTEG_FLAG 0x00000020 225 C GSS_C_CONF_FLAG 0x00000010 226 S GSS_C_SEQUENCE_FLAG 0x00000008 227 R GSS_C_REPLAY_FLAG 0x00000004 228 M GSS_C_MUTUAL_FLAG 0x00000002 229 D GSS_C_DELEG_FLAG 0x00000001 231 The zero padding reserves bits for future expansion. The padding 232 bits shall be set to zero by the initator and ignored by the 233 acceptor. GSS_C_DELEG_FLAG ("D" flag) must be set if the 234 "delegated credentials" option is included. 236 checksum type count (32 bits) 237 The number of checksum types supported by the initiator. 239 checksum type list (variable length) 240 A list of Kerberos checksum types, as defined in RFC 1510 241 section 6.4. These checksum types must be collision-proof and 242 keyed with the context key. Each checksum type number shall be 32 243 bits wide. This list should contain all the checksum types 244 supported by the initiator. 246 options (variable length) 247 The option format will be described later. 249 AP-REQ length (32 bits) 250 The length of the following KRB_AP_REQ message. 252 AP-REQ data (variable length) 253 The AP-REQ message as described in RFC 1510. The checksum in the 254 authenticator will be computed over the items listed in the next 255 section. 257 The optional sequence number field shall be used in the AP-REQ. The 258 initiator should generate a subkey in the authenticator, and the 259 acceptor should generate a subkey in the AP-REP. The key used for the 260 per-message tokens will be the AP-REP subkey, or if that is not present, 261 the authenticator subkey, or if that is not present, the session key. 262 When subkeys are generated, it is strongly recommended that they be of 263 the same type as the associated session key. 265 2.3.2.1. Data to be Checksummed in AP-REQ 267 The checksum in the AP-REQ message is calculated over the following 268 items. Like in the actual tokens, no padding should be added to force 269 integer fields to align on 32 bit boundaries. This particular set of 270 data should not be sent as a part of any token; it merely specifies what 271 is to be checksummed in the AP-REQ. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | initiator address type | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | initiator address length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | initiator address | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | acceptor address type | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | acceptor address length | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | acceptor address | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | application data length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | application data | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | flags | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | checksum type count | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | checksum type list | 297 / : / 298 / : / 299 | checksum type list | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | options | 302 / : / 303 / : / 304 | options | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 initiator address type (32 bits) 308 The initiator address type, as defined in the Kerberos protocol 309 specification. 311 initiator address length (32 bits) 312 The length in bytes of the following initiator address. 314 initiator address (variable length) 315 The actual initiator address, in network byte order. 317 acceptor address type (32 bits) 318 The acceptor address type, as defined in the Kerberos protocol 319 specification. 321 initiator address length (32 bits) 322 The length in bytes of the following acceptor address. 324 initiator address (variable length) 325 The actual acceptor address, in network byte order. 327 application data length (32 bits) 328 The length of the following application data, if provided. If no 329 application data are passed as input channel bindings, this length 330 field should be set to zero. 332 applicatation data (variable length) 333 The actual application data, if provided. 335 flags (32 bits) 336 The context establishment flags from the initial token. 338 checksum type count (32 bits) 339 The number of checksum types supported by the initiator. 341 checksum type list (variable length) 342 The same list of checksum types contained in the initial token. 344 options (variable length) 345 The options list from the initial token. 347 2.3.3. Response Token 349 This is the reponse token sent by the context acceptor, if mutual 350 authentication is enabled. 352 0 1 2 3 353 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 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | response token id | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | flags | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | checksum type count | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | checksum type list | 362 / : / 363 / : / 364 | checksum type list | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | options | 367 / : / 368 / : / 369 | options | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | AP-REP or KRB-ERROR length | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | AP-REP or KRB-ERROR data | 374 / : / 375 / : / 376 | AP-REP or KRB-ERROR data | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | checksum type | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | checksum length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | checksum data | 383 / : / 384 / : / 385 | checksum data | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 response token id (32 bits) 389 Contains the integer 0x02020202, which identifies this as the 390 response token in the context setup. 392 flags (32 bits) 393 This currently is defined to only contain one flag, the error flag, 394 which has a value of 0x00000001. If this flag is set, then the 395 last field contains a KRB-ERROR message, otherwise, it contains an 396 AP-REP message. The other bits in the flags field are reserved; 397 they should be set to zero by the acceptor and ignored by the 398 initiator. 400 checksum type count (32 bits) 401 The number of checksum types supported by both the initiator and 402 the acceptor. 404 checksum type list (variable length) 405 A list of Kerberos checksum types, as defined in RFC 1510 406 section 6.4. These checksum types must be collision-proof and 407 keyed with the context key. Each checksum type number shall be 32 408 bits wide. This list should contain the intersection of the list 409 of checksum types specified by the initiator in the initial token 410 and the list of checksum types supported by the acceptor. 412 options (variable length) 413 The option list, as described earlier. At this time, no options 414 are defined, but an implementation might make use of these options 415 to acknowledge an option from the initial token. After all the 416 options are specified, a null option must be used to terminate the 417 list. 419 AP-REP or KRB-ERROR length (32 bits) 420 Depending on the value of the error flag, length in bytes of the 421 AP-REP or KRB-ERROR message. 423 AP-REP or KRB-ERROR data (variable length) 424 Depending on the value of the error flag, the AP-REP or KRB-ERROR 425 message as described in RFC 1510. If this field contains an AP-REP 426 message, the sequence number field in the AP-REP shall be filled. 427 If this is a KRB-ERROR message, no further fields will be in this 428 message. 430 checksum type (32 bits) 431 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This 432 checksum type must be collision-proof and keyed with the context 433 key. The checksum type implies the length of the checksum data. 435 checksum length (32 bits) 436 The number of bytes in the following checksum data field. 438 checksum data (variable length) 439 The checksum itself, as defined in RFC 1510 section 6.4, computed 440 over the concatenation of the flags and the options. XXX does this 441 need a new key usage as well? 443 2.4. Per-message Tokens 445 2.4.1. Sequence Number Usage Sequence numbers for per-message tokens 446 are 32 bit unsigned integers, which are incremented by 1 after each 447 token. An overflow condition should result in a wraparound of the 448 sequence number to zero. The initiator and acceptor each keep their own 449 sequence numbers per connection. 451 2.4.2. MIC Token 453 Use of the GSS_GetMIC() call yields a token, separate from the user data 454 being protected, which can be used to verify the integrity of that data 455 when it is received. The MIC token has the following format: 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | MIC token id | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | sequence number | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | direction | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | checksum type | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | checksum length | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | checksum data | 471 / : / 472 / : / 473 | checksum data | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 MIC token id (32 bits) 477 Contains the integer 0x03030303, which identifies this as a MIC 478 token. 480 sequence number (32 bits) 481 The sequence number. 483 direction (32 bits) 484 All bits in this field shall be zero if the message is sent from 485 the context initiator. If the message is sent from the context 486 acceptor, all bits shall be one. 488 checksum type (32 bits) 489 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This 490 checksum type must be collision-proof and keyed with the context 491 key. 493 checksum length (32 bits) 494 The number of bytes in the following checksum data field. 496 checksum data (variable length) 497 The checksum itself, as defined in RFC 1510 section 6.4. The 498 checksum is calculated as in the following section. 500 XXX A kerberos key usage needs to be registered for generating MIC 501 tokens. 503 The mechanism implementation should only use checksum types which it 504 knows to be valid for both peers. If mutual authentication is used, 505 then any checksum type specified by the acceptor may be used. If mutual 506 authentication is not used XXX what do we do then? This seems to be a 507 more general issue than just GSSAPI. What checksum type did we use for 508 the authenticator checksum? 509 2.4.2.1. Data to be Checksummed in MIC Token The checksum in the MIC 510 token shall be calculated over the following elements. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | sequence number | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | direction | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | application data | 520 / : / 521 / : / 522 | application data | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 sequence number (32 bits) 526 The sequence number. 528 direction (32 bits) 529 All bits in this field shall be zero if the message is sent from 530 the context initiator. If the message is sent from the context 531 acceptor, all bits shall be one. 533 application data (variable length) 534 The application-supplied data. 536 2.4.3. Wrap Token 538 Use of the GSS_Wrap() call yields a token which encapsulates the input 539 user data (optionally encrypted) along with associated integrity check 540 quantities. 542 2.4.3.1. Wrap Token With Integrity Only 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | integrity wrap token id | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | sequence number | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | direction | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | application data length | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | application data | 555 / : / 556 / : / 557 | application data | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | checksum type | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | checksum length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | checksum data | 564 / : / 565 / : / 566 | checksum data | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 integrity wrap token id (32 bits) 570 Contains the integer 0x04040404, which identifies this as a Wrap 571 token with integrity only. 573 sequence number (32 bits) 574 The sequence number. 576 direction (32 bits) 577 All bits in this field shall be zero if the message is sent from 578 the context initiator. If the message is sent from the context 579 acceptor, all bits shall be one. 581 application data length (32 bits) 582 The number of bytes in the following application data field. 584 application data (variable length) 585 The application-supplied data. 587 checksum type (32 bits) 588 A Kerberos checksum type, as defined in RFC 1510 section 6.4. This 589 checksum type must be collision-proof and keyed with the context 590 key. The checksum type implies the length of the checksum data. 592 checksum length (32 bits) 593 The number of bytes in the following checksum data field. 595 checksum data (variable length) 596 The checksum itself, as defined in RFC 1510 section 6.4, computed 597 over the concatenation of the sequence number, direction field, and 598 application data, as in the MIC token checksum in the previous 599 section. 601 The mechanism implementation should only use checksum types which it 602 knows to be valid for both peers, as described for MIC tokens. 604 2.4.3.2. Wrap Token With Integrity and Encryption 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | encrypted wrap token id | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | encrypted data length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | encrypted data | 614 / : / 615 / : / 616 | encrypted data | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 encrypted wrap token id (32 bits) 620 Contains the integer 0x05050505, which identifies this as a Wrap 621 token with integrity and encryption. 623 encrypted data length (32 bits) 624 The number of bytes in the following encrypted data field. 626 encrypted data (variable length) 627 The encrypted data itself, as defined in RFC 1510 section 6.3. The 628 encryption is performed using the key/enctype exchanged during 629 context setup. The actual data to be encrypted are specified 630 below. 632 2.4.3.2.1. Data to be Encrypted in Wrap Token 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | sequence number | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | direction | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | application data length | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | application data | 643 / : / 644 / : / 645 | application data | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 sequence number (32 bits) 649 The sequence number. 651 direction (32 bits) 652 All bits in this field shall be zero if the message is sent from 653 the context initiator. If the message is sent from the context 654 acceptor, all bits shall be one. 656 application data length (32 bits) 657 The number of bytes in the following application data field. 659 application data (variable length) 660 The application-supplied data. 662 XXX Two kerberos key usages need to be registered, one for integrity- 663 only tokens, and one for integrity-and-encryption tokens. 665 3. Kerberos Protocol Dependencies This protocol makes several 666 assumptions about the Kerberos protocol, which may require changes to 667 the successor of RFC 1510. 669 Sequence numbers, checksum types, and address types are assumed to be no 670 wider than 32 bits. The Kerberos protocol specification might need to 671 be modified to accomodate this. This obviously requires some further 672 discussion. 674 Key usages need to be registered within the Kerberos protocol for use 675 with GSSAPI per-message tokens. One may also need to be registered for 676 the checksum in the reply token during context establishment. 678 This protocol also makes the assumption that any cryptosystem used with 679 the session key will include integrity protection, i.e., it assumes that 680 no "raw" cryptosystems will be used. 682 4. Security Considerations The GSSAPI is a security protocol; 683 therefore, security considerations are discussed throughout this 684 document. The old Kerberos 5 GSSAPI mechanism's constraints on possible 685 cryptosystems and checksum types do not permit it to be readily expanded 686 to accomodate more secure technologies with larger checksums or 687 encryption block sizes. Sites are strongly encouraged to adopt the 688 mechanism specified in this document in the light of recent publicity 689 about the deficiencies of DES. 691 5. References 693 [RFC1510] Kohl, J., Neumann, C., "The Kerberos Network Authentication 694 Service (V5)", RFC 1510. 696 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 697 RFC 1964. 699 [RFC2078] Linn, J., "Generic Security Service Application Program 700 Interface, Version 2", RFC 2078 702 6. Author's Address 703 Tom Yu 704 Massachusetts Institute of Technology 705 Room E40-345 706 77 Massachusetts Avenue 707 Cambridge, MA 02139 708 USA 710 email: tlyu@mit.edu 711 phone: +1 617 253 1753