1CAT Working Group K. Raeburn 2Internet-draft MIT 3Category: July 14, 2000 4Updates: RFC 1964 5Document: draft-raeburn-cat-gssapi-krb5-3des-00.txt 6 7 Triple-DES Support for the Kerberos 5 GSSAPI Mechanism 8 9Status of this Memo 10 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC2026]. Internet-Drafts 13 are working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as 16 Internet-Drafts. Internet-Drafts are draft documents valid for a 17 maximum of six months and may be updated, replaced, or obsoleted by 18 other documents at any time. It is inappropriate to use 19 Internet-Drafts as reference material or to cite them other than as 20 "work in progress." 21 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 27 281. Abstract 29 30 The MIT Kerberos 5 release version 1.2 includes support for 31 triple-DES with key derivation [KrbRev]. Recent work by the EFF 32 [EFF] has demonstrated the vulnerability of single-DES mechanisms 33 to brute-force attacks by sufficiently motivated and well-funded 34 parties. 35 36 The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] 37 specifically enumerates encryption and checksum types, 38 independently of how such schemes may be used in Kerberos. In the 39 long run, a new Kerberos-based mechanism, which does not require 40 separately enumerating for the GSSAPI mechanism each of the 41 encryption types defined by Kerberos, appears to be a better 42 approach. Efforts to produce such a specification are under way. 43 44 In the interest of providing increased security in the interim, 45 however, MIT is proposing adding support for triple-DES to the 46 existing mechanism, as described here. 47 482. Conventions Used in this Document 49 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 52 this document are to be interpreted as described in RFC 2119. 53 543. New Algorithm Identifiers 55 56 One new sealing algorithm is defined, for use in WRAP tokens: 57 58 02 00 - DES3-KD 59 60 This algorithm uses triple-DES with key derivation, with a usage 61 value KG_USAGE_SEAL. Padding is still to 8-byte multiples, and the 62 IV for encrypting application data is zero. 63 64 One new signing algorithm is defined, for use in MIC, Wrap, and 65 Delete tokens: 66 67 04 00 - HMAC SHA1 DES3-KD 68 69 This algorithm generates an HMAC using SHA-1 and a derived DES3 key 70 with usage KG_USAGE_SIGN, as (ought to be described) in [KrbRev]. 71 72 [XXX: The current [KrbRev] description refers to expired I-Ds from 73 Marc Horowitz. The text in [KrbRev] may be inadequate to produce 74 an interoperable implementation.] 75 76 The checksum size for this algorithm is 20 octets. See section 5.3 77 below for the use of checksum lengths of other than eight bytes. 78 794. Key Derivation 80 81 For purposes of key derivation, we add three new usage values to the 82 list defined in [KrbRev]; one for signing messages, one for 83 sealing messages, and one for encrypting sequence numbers: 84 85 #define KG_USAGE_SEAL 22 86 #define KG_USAGE_SIGN 23 87 #define KG_USAGE_SEQ 24 88 895. Adjustments to Previous Definitions 90 915.1. Quality of Protection 92 93 The GSSAPI specification [GSSAPI] says that a zero QOP value 94 indicates the "default". The original specification for the 95 Kerberos 5 mechanism says that a zero QOP value (or a QOP value 96 with the appropriate bits clear) means DES encryption. 97 98 Rather than continue to force the use of plain DES when the 99 application doesn't use mechanism-specific QOP values, the better 100 choice appears to be to redefine the DES QOP value as some non-zero 101 value, and define a triple-DES value as well. Then a zero value 102 continues to imply the default, which would be triple-DES 103 protection when given a triple-DES session key. 104 105 Our values are: 106 107 GSS_KRB5_INTEG_C_QOP_HMAC_SHA1 0x0004 108 /* SHA-1 checksum encrypted with key derivation */ 109 110 GSS_KRB5_CONF_C_QOP_DES 0x0100 111 /* plain DES encryption */ 112 GSS_KRB5_CONF_C_QOP_DES3_KD 0x0200 113 /* triple-DES with key derivation */ 114 115 Rather than open the question of whether to specify means for 116 deriving a key of one type given a key of another type, and the 117 security implications of whether to generate a long key from a 118 shorter one, our implementation will simply return an error if the 119 QOP value specified does not correspond to the session key type. 120 121 [Implementation note: MIT's code does not implement QoP, and 122 returns an error for any non-zero QoP value.] 123 1245.2. MIC Sequence Number Encryption 125 126 The sequence numbers are encrypted in the context key (as defined 127 in [GSSAPI-KRB5] -- this will be either the Kerberos session key or 128 asubkey provided by the context initiator), using whatever 129 encryption system is designated by the type of that context key. 130 The IV is formed from the first N bytes of the SGN_CKSUM field, 131 where N is the number of bytes needed for the IV. (With all 132 algorithms described here and in [GSSAPI-KRB5], the checksum is at 133 least as large as the IV.) 134 1355.3. Message Layout 136 137 Both MIC and Wrap tokens, as defined in [GSSAPI-KRB5], contain an 138 checksum field SGN_CKSUM. In [GSSAPI-KRB5], this field was 139 specified as being 8 bytes long. We now change this size to be 140 "defined by the checksum algorithm", and retroactively amend the 141 descriptions of all the checksum algorithms described in 142 [GSSAPI-KRB5] to explicitly specify 8-byte output. Application 143 data continues to immediately follow the checksum field in the Wrap 144 token. 145 146 The revised message descriptions are thus: 147 148 MIC: 149 150 Byte no Name Description 151 0..1 TOK_ID Identification field. 152 2..3 SGN_ALG Integrity algorithm indicator. 153 4..7 Filler Contains ff ff ff ff 154 8..15 SND_SEQ Sequence number field. 155 16..s+15 SGN_CKSUM Checksum of "to-be-signed data", 156 calculated according to algorithm 157 specified in SGN_ALG field. 158 159 Wrap: 160 161 Byte no Name Description 162 0..1 TOK_ID Identification field. 163 Tokens emitted by GSS_Wrap() contain 164 the hex value 02 01 in this field. 165 2..3 SGN_ALG Checksum algorithm indicator. 166 4..5 SEAL_ALG Sealing algorithm indicator. 167 6..7 Filler Contains ff ff 168 8..15 SND_SEQ Encrypted sequence number field. 169 16..s+15 SGN_CKSUM Checksum of plaintext padded data, 170 calculated according to algorithm 171 specified in SGN_ALG field. 172 s+16..last Data encrypted or plaintext padded data 173 174 Where "s" indicates the size of the checksum. 175 176 As indicated above in section 2, we define the HMAC SHA1 DES3-KD 177 checksum algorithm to produce a 20-byte output, so encrypted data 178 begins at byte 36. 179 1806. Backwards Compatibility Considerations 181 182 The context initiator SHOULD request of the KDC credentials using 183 session-key cryptosystem types supported by that implementation; if 184 the only types returned by the KDC are not supported by the 185 mechanism implementation, it MUST indicate a failure. This may 186 seem obvious, but early implementations of both Kerberos and the 187 GSSAPI Kerberos mechanism supported only DES keys, so the 188 cryptosystem compatibility question was easy to overlook. 189 190 Under the current mechanism, no negotiation of algorithm types 191 occurs, so server-side (acceptor) implementations cannot request 192 that clients not use algorithm types not understood by the server. 193 However, administration of the server's Kerberos data has to be 194 done in communication with the KDC, and it is from the KDC that the 195 client will request credentials. The KDC could therefore be tasked 196 with limiting session keys for a given service to types actually 197 supported by the Kerberos and GSSAPI software on the server. 198 199 This does have a drawback for cases where a service principal name 200 is used both for GSSAPI-based and non-GSSAPI-based communication, 201 if the GSSAPI implementation does not understand triple-DES but the 202 Kerberos implementation does. It means that triple-DES session 203 keys cannot be issued for that service principal, which keeps the 204 protection of non-GSSAPI services weaker than necessary. However, 205 in the most recent MIT releases thus far, while triple-DES support 206 has been present, it has required additional work to enable, so it 207 is not likely to be in use for many services. 208 209 It would also be possible to have clients attempt to get single-DES 210 session keys before trying to get triple-DES session keys, and have 211 the KDC refuse to issue the single-DES keys only for the most 212 critical of services, for which single-DES protection is considered 213 inadequate. However, that would eliminate the possibility of 214 connecting with the more secure cryptosystem to any service that 215 can be accessed with the weaker cryptosystem. 216 217 We have chosen to go with the former approach, putting the burden 218 on the KDC administration and gaining the best protection possible 219 for GSSAPI services, possibly at the cost of protection of 220 non-GSSAPI Kerberos services running earlier versions of the 221 software. 222 2236. Security Considerations 224 225 Various tradeoffs arise regarding the mixing of new and old 226 software, or GSSAPI-based and non-GSSAPI Kerberos authentication. 227 They are discussed in section 5. 228 2297. References 230 231 [EFF] Electronic Frontier Foundation, "Cracking DES: Secrets of 232 Encryption Research, Wiretap Politics, and Chip Design", O'Reilly & 233 Associates, Inc., May, 1998. 234 235 [GSSAPI] Linn, J., "Generic Security Service Application Program 236 Interface Version 2, Update 1", RFC 2743, January, 2000. 237 238 [GSSAPI-KRB5] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 239 RFC 1964, June, 1996. 240 241 [KrbRev] Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network 242 Authentication Service (V5)", 243 draft-ietf-cat-kerberos-revisions-05.txt, March 10, 2000. 244 245 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 246 3", RFC 2026, October, 1996. 247 2488. Author's Address 249 250 Kenneth Raeburn 251 Massachusetts Institute of Technology 252 77 Massachusetts Avenue 253 Cambridge, MA 02139 254 2559. Full Copyright Statement 256 257 Copyright (C) The Internet Society (2000). All Rights Reserved. 258 259 This document and translations of it may be copied and furnished to 260 others, and derivative works that comment on or otherwise explain it 261 or assist in its implementation may be prepared, copied, published 262 and distributed, in whole or in part, without restriction of any 263 kind, provided that the above copyright notice and this paragraph 264 are included on all such copies and derivative works. However, this 265 document itself may not be modified in any way, such as by removing 266 the copyright notice or references to the Internet Society or other 267 Internet organizations, except as needed for the purpose of 268 developing Internet standards in which case the procedures for 269 copyrights defined in the Internet Standards process must be 270 followed, or as required to translate it into languages other than 271 English. 272 273 The limited permissions granted above are perpetual and will not be 274 revoked by the Internet Society or its successors or assigns. 275 276 This document and the information contained herein is provided on an 277 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 278 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 279 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 280 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 281 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 282