1 2 3 4NETWORK WORKING GROUP L. Zhu 5Internet-Draft P. Leach 6Updates: 4120 (if approved) K. Jaganathan 7Expires: January 20, 2006 Microsoft Corporation 8 July 19, 2005 9 10 11 Kerberos Cryptosystem Negotiation Extension 12 draft-zhu-kerb-enctype-nego-03 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on January 20, 2006. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2005). 42 43Abstract 44 45 This document specifies an extension to the Kerberos protocol where 46 the client can send a list of supported encryption types in 47 decreasing preference order, and the server then selects an 48 encryption type that is supported by both the client and the server. 49 50 51 52 53 54 55Zhu, et al. Expires January 20, 2006 [Page 1] 56 57Internet-Draft Enctype Negotiation July 2005 58 59 60Table of Contents 61 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 64 3. Negotiation Extension . . . . . . . . . . . . . . . . . . . . 3 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 70 Intellectual Property and Copyright Statements . . . . . . . . 7 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Zhu, et al. Expires January 20, 2006 [Page 2] 112 113Internet-Draft Enctype Negotiation July 2005 114 115 1161. Introduction 117 118 Under the current mechanism [RFC4120], the KDC must limit the ticket 119 session key encryption type (enctype) chosen for a given server to 120 one it believes is supported by both the client and the server. If 121 both the client and server understand a stronger enctype than the one 122 selected by the KDC, they can not negotiate it. As the result, the 123 protection of application traffic is often weaker than necessary when 124 the server can support different sets of enctypes depending on the 125 server application software being used. 126 127 This document specifies an extension to the Kerberos protocol to 128 allow clients and servers to negotiate a different and possible 129 stronger cryptosystem to be used in subsequent communication. 130 131 This extension utilizes an authorization data element in the 132 authenticator of the AP-REQ message [RFC4120]. The client sends the 133 list of enctypes that it supports to the server, the server then 134 informs the client its choice. The negotiated subkey is sent in the 135 AP-REP message [RFC4120]. 136 1372. Conventions Used in This Document 138 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 142 1433. Negotiation Extension 144 145 If the client prefers an enctype over that of the service ticket 146 session key, then it sends the list of enctypes it supports 147 (including the one selected by the KDC) in decreasing preference 148 order. 149 150 The client sends the enctype list via the authorization-data of the 151 authenticator in the AP-REQ [RFC4120]. A new authorization data 152 element type AD-ETYPE-NEGOTIATION is defined. 153 154 AD-ETYPE-NEGOTIATION 129 155 156 This authorization data element itself is enclosed in the AD-IF- 157 RELEVANT container, thus a correctly implemented server that does not 158 understand this element should ignore it [RFC4120]. The value of 159 this authorization element contains the DER [X690] encoding of the 160 following ASN.1 type: 161 162 163 164 165 166 167Zhu, et al. Expires January 20, 2006 [Page 3] 168 169Internet-Draft Enctype Negotiation July 2005 170 171 172 EtypeList ::= SEQUENCE OF Int32 173 -- Specifies the enctypes supported by the client. 174 -- This enctype list is in decreasing preference order 175 -- (favorite choice first). 176 -- Int32 is defined in [RFC4120]. 177 178 If the EtypeList is present and the server prefers an enctype from 179 the client's enctype list over that of the AP-REQ authenticator 180 subkey (if that is present) or the service ticket session key, the 181 server MUST create a subkey using that enctype. This negotiated 182 subkey is sent in the subkey field of AP-REP message and it is then 183 used as the protocol key or base key [RFC3961] for subsequent 184 communication. 185 186 This negotiation extension SHOULD NOT be used when the client does 187 not expect the subkey in the AP-REP message from the server. 188 189 A note on key generation: The KDC has a strong Pseudo-Random Number 190 Generator (PRNG), as such the client can take advantage of the 191 randomness provided by the KDC by reusing the KDC key data when 192 generating keys. Implementations SHOULD use the service ticket 193 session key value as a source of additional entropy when generating 194 the negotiated subkey. If the AP-REQ authenticator subkey is 195 present, it MAY also be used as a source of entropy. 196 197 The server MAY ignore the preference order indicated by the client. 198 The policy by which the client or the server chooses an enctype 199 (i.e., how the preference order for the supported enctypes is 200 selected) is a local matter. 201 2024. Security Considerations 203 204 The client's enctype list and the server's reply enctype are part of 205 encrypted data, thus the security considerations are the same as 206 those of the Kerberos encrypted data. 207 208 Both the EtypeList and the server's sub-session key are protected by 209 the session key or sub-session key used for the AP-REQ, and as a 210 result, if a key for a stronger enctype is negotiated underneath a 211 key for a weaker enctype, an attacker capable of breaking the weaker 212 enctype can also discover the key for the stronger enctype. The 213 advantage of this extension is to minimize the amount of cipher text 214 encrypted under a weak enctype to which an attacker has access. 215 2165. Acknowledgements 217 218 The authors would like to thank the following individuals for their 219 comments and suggestions: Luke Howard, Tom Yu, Love Hornquist 220 221 222 223Zhu, et al. Expires January 20, 2006 [Page 4] 224 225Internet-Draft Enctype Negotiation July 2005 226 227 228 Astrand, Sam Harman, Ken Raeburn and Martin Rex. 229 2306. IANA Considerations 231 232 No IANA actions are required for this document. 233 2347. Normative References 235 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 239 [RFC2743] Linn, J., "Generic Security Service Application Program 240 Interface Version 2, Update 1", RFC 2743, January 2000. 241 242 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 243 Kerberos 5", RFC 3961, February 2005. 244 245 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 246 Kerberos Network Authentication Service (V5)", RFC 4120, 247 July 2005. 248 249 [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules 250 (BER), Canonical Encoding Rules (CER) and Distinguished 251 Encoding Rules (DER), ITU-T Recommendation X.690 (1997) | 252 ISO/IEC International Standard 8825-1:1998. 253 254Authors' Addresses 255 256 Larry Zhu 257 Microsoft Corporation 258 One Microsoft Way 259 Redmond, WA 98052 260 US 261 262 Email: lzhu@microsoft.com 263 264 265 Paul Leach 266 Microsoft Corporation 267 One Microsoft Way 268 Redmond, WA 98052 269 US 270 271 Email: paulle@microsoft.com 272 273 274 275 276 277 278 279 280 281 282 283Zhu, et al. Expires January 20, 2006 [Page 5] 284 285Internet-Draft Enctype Negotiation July 2005 286 287 288 Karthik Jaganathan 289 Microsoft Corporation 290 One Microsoft Way 291 Redmond, WA 98052 292 US 293 294 Email: karthikj@microsoft.com 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339Zhu, et al. Expires January 20, 2006 [Page 6] 340 341Internet-Draft Enctype Negotiation July 2005 342 343 344Intellectual Property Statement 345 346 The IETF takes no position regarding the validity or scope of any 347 Intellectual Property Rights or other rights that might be claimed to 348 pertain to the implementation or use of the technology described in 349 this document or the extent to which any license under such rights 350 might or might not be available; nor does it represent that it has 351 made any independent effort to identify any such rights. Information 352 on the procedures with respect to rights in RFC documents can be 353 found in BCP 78 and BCP 79. 354 355 Copies of IPR disclosures made to the IETF Secretariat and any 356 assurances of licenses to be made available, or the result of an 357 attempt made to obtain a general license or permission for the use of 358 such proprietary rights by implementers or users of this 359 specification can be obtained from the IETF on-line IPR repository at 360 http://www.ietf.org/ipr. 361 362 The IETF invites any interested party to bring to its attention any 363 copyrights, patents or patent applications, or other proprietary 364 rights that may cover technology that may be required to implement 365 this standard. Please address the information to the IETF at 366 ietf-ipr@ietf.org. 367 368 369Disclaimer of Validity 370 371 This document and the information contained herein are provided on an 372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 374 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 375 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 376 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 379 380Copyright Statement 381 382 Copyright (C) The Internet Society (2005). This document is subject 383 to the rights, licenses and restrictions contained in BCP 78, and 384 except as set forth therein, the authors retain all their rights. 385 386 387Acknowledgment 388 389 Funding for the RFC Editor function is currently provided by the 390 Internet Society. 391 392 393 394 395Zhu, et al. Expires January 20, 2006 [Page 7] 396 397 398