idnits 2.17.1 draft-ietf-krb-wg-gss-crypto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 6 months document validity. == 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1964, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 5 has weird spacing: '...-00.txt expir...' (Using the creation date from RFC1964, updated by this document, for RFC5378 checks: 1996-06-01) -- 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 (February 13, 2004) is 7378 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: 'RFC2119' is defined on line 365, but no explicit reference was found in the text -- No information found for draft-ietf-krb-wg-crypto-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KCRYPTO' -- No information found for draft-ietf-krb-wg-kerberos-clarifications-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'KrbClar' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft K. Raeburn 3 Kerberos Working Group MIT 4 Updates: RFC 1964 August 13, 2003 5 Document: draft-ietf-krb-wg-gss-crypto-00.txt expires February 13, 2004 7 General Kerberos Cryptosystem Support 8 for the Kerberos 5 GSSAPI Mechanism 10 Abstract 12 This document describes an update to the Kerberos 5 mechanism for 13 GSSAPI to allow the use of Kerberos-defined cryptosystems directly in 14 GSSAPI messages, without requiring further changes for each new 15 encryption or checksum algorithm that complies with the Kerberos 16 crypto framework specifications. 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 22 are working documents of the Internet Engineering Task Force (IETF), 23 its areas, and its working groups. Note that other groups may also 24 distribute working documents as Internet-Drafts. Internet-Drafts are 25 draft documents valid for a maximum of six months and may be updated, 26 replaced, or obsoleted by other documents at any time. It is 27 inappropriate to use Internet-Drafts as reference material or to cite 28 them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 1. Introduction 38 Kerberos defines an encryption and checksum framework [KCRYPTO] that 39 provides for complete specification and enumeration of cryptosystem 40 specifications in a general way, to be used within Kerberos and 41 associated protocols. The GSSAPI Kerberos 5 mechanism definition 42 [GSSAPI-KRB5] sets up a framework for enumerating encryption and 43 checksum types, independently of how such schemes may be used in 44 Kerberos, thus requiring updates for any new encryption or checksum 45 algorithm not directly compatible with those already defined. 47 This document describes an update to [GSSAPI-KRB5] to allow the use 48 of any Kerberos-defined cryptosystems directly in GSSAPI messages, 49 without requiring further changes for each new encryption or checksum 50 algorithm that complies with the framework specifications, and 51 without making assumptions concerning block sizes or other 52 characteristics of the underlying encryption operations. 54 2. Conventions Used in This Document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119. 60 3. New Algorithm Identifiers 62 Two new sealing algorithm numbers and one new signing algorithm 63 number are defined, for use in MIC, Wrap and Delete tokens. 65 type name octet values 66 ----------------------------------------- 67 seal KERBEROS5-ENCRYPT 00 01 68 sign KERBEROS5-CHECKSUM 00 01 69 sign NONE ff ff 71 The KERBEROS5-ENCRYPT algorithm encrypts using the Kerberos 72 encryption type [KCRYPTO] indicated by the encryption key type (using 73 the session key or initiator's subkey, as described in [GSSAPI- 74 KRB5]), with a key usage value KG_USAGE_SEAL, defined below. All 75 Kerberos encryption types provide for integrity protection, and 76 specify any padding that might be required; neither needs to be done 77 at the GSS mechanism level when KERBEROS5-ENCRYPT is used. When 78 KERBEROS5-ENCRYPT is used as the seal algorithm, the sign algorithm 79 MUST be NONE. 81 The signing algorithm value NONE MUST be used only with a sealing 82 algorithm that incorporates integrity protection; currently, 83 KERBEROS5-ENCRYPT is the only such sealing algorithm. 85 The KERBEROS5-CHECKSUM signing algorithm MAY be used in other cases. 86 The contents of the SGN_CKSUM field are determined by computing a 87 Kerberos checksum [KCRYPTO], using the session key or subkey, and a 88 key usage value of KG_USAGE_SIGN. The Kerberos checksum algorithm to 89 be used is the required-to-implement checksum algorithm associated 90 with the encryption key type. It should be noted that the checksum 91 input data in this case is not the same as the "to-be-signed data" 92 described in section 1.2.1.1 of [GSSAPI-KRB5]; see below. 94 The encryption or checksum output incorporated in the MIC and Wrap 95 tokens is the octet string output from the corresponding operation in 96 [KCRYPTO]; it should not be confused with the EncryptedData or 97 Checksum object in [KrbClar]. 99 For purposes of key derivation, we add two new usage values to the 100 list defined in [KrbClar]; one for signing messages, and one for 101 sealing messages: 103 name value 104 ---------------------- 105 KG_USAGE_SEAL 22 106 KG_USAGE_SIGN 23 108 4. Adjustments to Previous Definitions 110 4.1. Quality of Protection 112 The GSSAPI specification [GSSAPI] says that a zero QOP value 113 indicates the "default". The original specification for the Kerberos 114 5 mechanism says that a zero QOP value (or a QOP value with the 115 appropriate bits clear) means DES encryption. 117 Since the quality of protection cannot be improved without fully 118 reauthenticating with a stronger key type, the QOP value is now 119 ignored. 121 4.2. Message Layout 123 The definitions of the MIC and Wrap tokens in [GSSAPI-KRB5] assumed 124 an 8-byte checksum size, and a CBC-mode block cipher with an 8-byte 125 block size, without integrity protection. In the crypto framework 126 described in [KCRYPTO], integrity protection is built into the 127 encryption operations. CBC mode is not assumed, and indeed there may 128 be no initial vector to supply. While the operations are performed 129 on messages of specific sizes, the underlying cipher may be a stream 130 cipher. 132 We modify the message definitions such that the portions after the 133 first 8 bytes (which specify the token identification and the signing 134 and sealing algorithms) are defined by the algorithms chosen. The 135 remaining bytes must convey sequence number and direction 136 information, and must protect the integrity of the token id and 137 algorithm indicators. For the DES-based algorithms specified in 138 [GSSAPI-KRB5], the definition for the remaining data is backwards 139 compatible. 141 The revised message descriptions are thus as follows: 143 MIC token 144 Byte # Name Description 145 ------------------------------------------------------- 146 0..1 TOK_ID Identification field (01 01). 147 2..3 SGN_ALG Integrity algorithm indicator. 148 4..7 Filler Contains ff ff ff ff 149 8..N Dependent on SGN_ALG. 151 If SGN_ALG is 0000, 0100, 0200: 152 8..15 SND_SEQ Sequence number/direction 153 field, encrypted. 154 16..23 SGN_CKSUM Checksum of bytes 0..7 and 155 application data, as described 156 in [GSSAPI-KRB5]. 157 If SGN_ALG is 0001: 158 8..15 SND_SEQ Sequence number/direction 159 field, NOT encrypted. 160 16..N SGN_CKSUM Checksum of bytes 0..15 and 161 application data, with key 162 usage KG_USAGE_SIGN. 164 Suggestions from Microsoft: Moving to 64-bit sequence numbers 165 would be better for long sessions with many messages. Using the 166 direction flag to perturb the encryption or integrity protection 167 is safer than simply including a flag which a buggy but mostly 168 working implementation might fail to check. 170 I am considering changing to use 64-bit sequence numbers, and 171 omitting the direction flag from the transmitted cleartext data. 172 How it would factor into the encrypted Wrap token, I haven't 173 figured out yet. 175 - Change the key usage values based on the direction? It's 176 suggested in [KCRYPTO], perhaps not strongly enough, that the key 177 usage numbers should perturb the key, but DES ignores them, 178 although DES shouldn't use this extension. 180 - Add a direction flag byte in encrypted data? Either depends on 181 an implementor remembering to add the check. Adding it to 182 checksummed data requires that the implementor get it right. 184 - Generate one or two new keys using PRF and random-to-key 185 operations, using different keys for each direction? Pulling the 186 DK function out of the simplified profile is probably not a good 187 way to do this. 189 The filler bytes are included in the checksum calculation for 190 simplicity. There is no security benefit from including them. 192 In the Wrap token, the initial bytes, sequence number and direction 193 are incorporated into the data to be encrypted. In most cases, this 194 is likely to be more efficient in terms of space and computing power 195 than using unencrypted sequence number and direction fields, adding a 196 checksum, and doing the additional work to authenticate that the 197 checksum and encrypted data are part of the same message. (The 198 framework in [KCRYPTO] has no support for integrity protection of a 199 block of data only some of which is encrypted, except by treating the 200 two portions independently and using some additional means to ensure 201 that the two parts continue to be associated with one another.) 203 The length is also included, as a 4-byte value in network byte order, 204 because the decryption operation in the Kerberos crypto framework 205 does not recover the exact length of the original input. Thus, 206 messages with application data larger than 4 gigabytes are not 207 supported. 209 [Q: Should this length be 8 bytes? ASN.1 wrapper?] 211 Wrap token 212 Byte # Name Description 213 ------------------------------------------------------------- 214 0..1 TOK_ID Identification field (02 01). 215 2..3 SGN_ALG Integrity algorithm indicator. 216 4..5 SEAL_ALG Sealing algorithm indicator. 217 6..7 Filler Contains ff ff 218 8..last Dependent on SEAL_ALG and SGN_ALG. 220 If SEAL_ALG is 0000: 221 8..15 SND_SEQ Encrypted sequence number field. 222 16..23 SGN_CKSUM Checksum of plaintext padded data, 223 calculated according to algorithm 224 specified in SGN_ALG field. (RFC 225 1964) 226 24..last Data Encrypted padded data. 228 If SEAL_ALG is 0001 and SGN_ALG is ffff: 229 8..last Data Encrypted bytes 0..5, 2-byte 230 direction flag, sequence number, 231 4-byte data length, and data. 233 If SEAL_ALG is ffff, and SGN_ALG is 0000, 0100, 0200: 234 8..15 SND_SEQ Encrypted sequence number field. 235 16..23 SGN_CKSUM Checksum of plaintext padded data, 236 as in RFC 1964. 237 24..last Data plaintext padded data 239 If SEAL_ALG if ffff, and SGN_ALG is 0001: 240 8..15 SND_SEQ Sequence number/direction field, 241 NOT encrypted. 242 16..N SGN_CKSUM Checksum of bytes 0..15 and 243 application data, with key usage 244 KG_USAGE_SIGN. 245 N+1..last Data plaintext data 247 The direction flag, as in [GSSAPI-KRB5], is made up of bytes 248 indicating the party sending the token: 00 for the context initiator, 249 or hex FF for the context acceptor. In the KERBEROS5-ENCRYPT case, 250 only two bytes are used, and they replace the fixed filler bytes of 251 the token header, which need no protection; this reduces slightly the 252 redundancy of the data transmitted. 254 The context-deletion token is essentially a MIC token with no user 255 data and a different TOK_ID value. Thus, its modification is 256 straightforward. 258 Context deletion token 259 Byte # Name Description 260 ------------------------------------------------------- 261 0..1 TOK_ID Identification field (01 02). 262 2..3 SGN_ALG Integrity algorithm indicator. 263 4..7 Filler Contains ff ff ff ff 265 If SGN_ALG is 0000, 0100, 0200: 266 8..15 SND_SEQ Sequence number/direction 267 field, encrypted. 268 16..23 SGN_CKSUM Checksum of bytes 0..7, as 269 described in [GSSAPI-KRB5]. 271 If SGN_ALG is 0001: 272 8..15 SND_SEQ Sequence number/direction 273 field, NOT encrypted. 274 16..N SGN_CKSUM Checksum of bytes 0..15, with 275 key usage KG_USAGE_SIGN. 277 5. Backwards Compatibility Considerations 279 The context initiator should request of the KDC credentials using 280 session-key cryptosystem types supported by that implementation; if 281 the only types returned by the KDC are not supported by the mechanism 282 implementation, it should indicate a failure. This may seem obvious, 283 but early implementations of both Kerberos and the GSSAPI Kerberos 284 mechanism supported only DES keys, so the cryptosystem compatibility 285 question was easy to overlook. 287 Under the current mechanism, no negotiation of algorithm types 288 occurs, so server-side (acceptor) implementations cannot request that 289 clients not use algorithm types not understood by the server. 290 However, administration of the server's Kerberos data (e.g., the 291 service key) has to be done in communication with the KDC, and it is 292 from the KDC that the client will request credentials. The KDC could 293 therefore be given the task of limiting session keys for a given 294 service to types actually supported by the Kerberos and GSSAPI 295 software on the server. 297 This does have a drawback for cases where a service principal name is 298 used both for GSSAPI-based and non-GSSAPI-based communication (most 299 notably the "host" service key), if the GSSAPI implementation does 300 not understand (for example) AES but the Kerberos implementation 301 does. It means that AES session keys cannot be issued for that 302 service principal, which keeps the protection of non-GSSAPI services 303 weaker than necessary. 305 It would also be possible to have clients attempt to get DES session 306 keys before trying to get AES session keys, and have the KDC refuse 307 to issue the DES keys only for the most critical of services, for 308 which DES protection is considered inadequate. However, that would 309 eliminate the possibility of connecting with the more secure 310 cryptosystem to any service that can be accessed with the weaker 311 cryptosystem. We thus recommend the former approach, putting the 312 burden on the KDC administration and gaining the best protection 313 possible for GSSAPI services, possibly at the cost of weaker 314 protection of non-GSSAPI Kerberos services sharing service principal 315 names with GSSAPI services that have not been updated to support this 316 extension. 318 [optional:] 320 This mechanism extension MUST NOT be used with the DES encryption key 321 types described in [KCRYPTO], which ignore the key usage values. 323 6. Implementation Note 325 At least two implementations have been done of extensions to the RFC 326 1964 mechanism for specific non-DES encryption types. These are not 327 standards-track extensions, but implementors may wish to implement 328 them as well for compatibility with existing products. No guidance 329 is provided as to when an implementation may wish to use these non- 330 standard extensions instead of the extension specified in this 331 document. 333 7. Security Considerations 335 Various tradeoffs arise regarding the mixing of new and old software, 336 or GSSAPI-based and non-GSSAPI Kerberos authentication. They are 337 discussed in section 5. 339 Remember to check direction flag. Key usage numbers and direction 340 checks? Considerations depend on the approach taken.... 342 8. Acknowledgements 344 Larry Zhu... 346 9. Normative References 348 [GSSAPI] 349 Linn, J., "Generic Security Service Application Program Interface 350 Version 2, Update 1", RFC 2743, January, 2000. 352 [GSSAPI-KRB5] 353 Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 354 June, 1996. 356 [KCRYPTO] 357 draft-ietf-krb-wg-crypto-XX -> RFC xxxx 359 [KrbClar] 360 draft-ietf-krb-wg-kerberos-clarifications-XX -> RFC xxxx 362 [RFC2026] 363 RFC 2026 ... 365 [RFC2119] 366 RFC 2119 ... 368 10. Author's Address 370 Kenneth Raeburn 371 Massachusetts Institute of Technology 372 77 Massachusetts Avenue 373 Cambridge, MA 02139 375 Full Copyright Statement 377 Copyright (C) The Internet Society (2003). All Rights Reserved. 379 This document and translations of it may be copied and furnished to 380 others, and derivative works that comment on or otherwise explain it 381 or assist in its implementation may be prepared, copied, published 382 and distributed, in whole or in part, without restriction of any 383 kind, provided that the above copyright notice and this paragraph are 384 included on all such copies and derivative works. However, this 385 document itself may not be modified in any way, such as by removing 386 the copyright notice or references to the Internet Society or other 387 Internet organizations, except as needed for the purpose of 388 developing Internet standards in which case the procedures for 389 copyrights defined in the Internet Standards process must be 390 followed, or as required to translate it into languages other than 391 English. 393 The limited permissions granted above are perpetual and will not be 394 revoked by the Internet Society or its successors or assigns. 396 This document and the information contained herein is provided on an 397 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 398 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 399 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 400 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 401 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 403 Document Change History 405 Version -XX: 407 Split up Abstract and create a real Introduction. Fix RFC 2026 408 reference in Status section. Added Conventions, Acknowledgements and 409 Implementation Note sections. Updated References with more 410 placeholders. Capitalize some uses of "must" etc. 412 Fill in case of Wrap token without integrity protection, using 413 KERBEROS5-CHECKSUM for SGN_ALG. Fix descriptions of which message 414 layout is used for which algorithms. 416 Remove discussion of authenticated encryption with additional data. 418 Add discussion of 64-bit sequence numbers and data length, and 419 alternate handling of the direction flag. 421 Version -XX sent in early 2003 to Kerberos working group: 423 Initial revision.