1 2 3NETWORK WORKING GROUP N. Williams 4Internet-Draft Sun 5Expires: December 30, 2004 July 2004 6 7 8 A PRF for the Kerberos V GSS-API Mechanism 9 draft-ietf-kitten-krb5-gssapi-prf-01.txt 10 11Status of this Memo 12 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 34 This Internet-Draft will expire on December 30, 2004. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 40Abstract 41 42 This document defines the Pseudo-Random Function (PRF) for the 43 Kerberos V mechanism for the Generic Security Service Application 44 Programming Interface (GSS-API), based on the PRF defined for the 45 Kerberos V cryptographic framework, for keying application protocols 46 given an established Kerberos V GSS-API security context. 47 48 49 50 51 52 53 54 55Williams Expires December 30, 2004 [Page 1] 56 57Internet-Draft A PRF for the Kerberos V Mech July 2004 58 59 60Table of Contents 61 62 1. Conventions used in this document . . . . . . . . . . . . . . . 3 63 2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . . 4 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 4. Normative References . . . . . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Intellectual Property and Copyright Statements . . . . . . . . . 7 68 69 70 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 111Williams Expires December 30, 2004 [Page 2] 112 113Internet-Draft A PRF for the Kerberos V Mech July 2004 114 115 1161. Conventions used in this document 117 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Williams Expires December 30, 2004 [Page 3] 168 169Internet-Draft A PRF for the Kerberos V Mech July 2004 170 171 1722. Kerberos V GSS Mechanism PRF 173 174 The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism [CFX] 175 shall be the output of a PRF+ function based on the enctype's PRF 176 function keyed with the negotiated session key of the security 177 context and key usage X (TBD). 178 179 The security context MUST be fully established, else the mechanism 180 MUST fail with GSS_S_FAILURE as the major status code and 181 GSS_KRB5_S_KG_CTX_INCOMPLETE as the minor status code. 182 183 This PRF+ MUST be keyed with a key derived, with key usage (TBD), 184 from the session used by the initiator and acceptor, after the 185 security context is fully established, to derive keys for per-message 186 tokens. For the current Kerberos V mechanism [CFX] this means that 187 the PRF+ MUST be keyed with the acceptor-asserted subkey, if it did 188 assert such a key, or the initiator's sub-session key otherwise. 189 190 The PRF+ function is a simple counter-based extension of the Kerberos 191 V pseudo-random function [KRB5-CRYPTO] for the enctype of the 192 security context's keys: 193 194 PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn) 195 196 Tn = pseudo-random-function(K, n || S) 197 198 where '||' is the concatenation operator, 'n' is encoded as a 199 network byte order 32-bit unsigned binary number, and where 200 truncate(L, S) truncates the input octet string S to length L. 201 202 The maximum output size of the Kerberos V mechanism's GSS-API PRF 203 then is, necessarily, 2^32 octets. 204 205 Implementations MUST support output size of up to 2^14 octets at 206 least. 207 208 If the implementation cannot produce the desired output then it MUST 209 output what it can. 210 211 The minimum input octet string length that implementations MUST 212 support is also 2^14 octets. If the input octet string is longer 213 than the maximum that an implementation can process then the 214 implementation MUST fail with GSS_S_FAILURE as the major status code 215 and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status code. 216 217 218 219 220 221 222 223Williams Expires December 30, 2004 [Page 4] 224 225Internet-Draft A PRF for the Kerberos V Mech July 2004 226 227 2283. Security Considerations 229 230 Kerberos V enctypes' PRF functions use a key derived from contexts' 231 session keys and should preserve the forward security properties of 232 the mechanisms' key exchanges. 233 234 Legacy Kerberos V enctypes may be weak, particularly the single-DES 235 enctypes. 236 237 See also [GSS-PRF] for generic security considerations of 238 GSS_Pseudo_random(). 239 240 The computational cost of computing this PRF+ may vary depending on 241 the Kerberos V enctypes being used, but generally the computation of 242 this PRF+ gets more expensive as the input and output octet string 243 lengths grow (note that the use of a counter in the PRF+ construction 244 allows for parallelization). This means that if an application can 245 be tricked into providing very large input octet strings and 246 requesting very long output octet strings then that may constitue a 247 denial of service attack on the application; therefore applications 248 SHOULD place appropriate limits on the size of any input octet 249 strings received from their peers without integrity protection. 250 2514 Normative References 252 253 [CFX] Zhu, L., Jaganathan, K. and S. Hartman, "The Kerberos 254 Version 5 GSS-API Mechanism: Version 2". 255 256 [GSS-PRF] Williams, N., "A PRF API extension for the GSS-API". 257 258 [KRB5-CRYPTO] 259 Raeburn, K., "Encryption and Checksum Specifications for 260 Kerberos 5". 261 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 264 265 [RFC2743] Linn, J., "Generic Security Service Application Program 266 Interface Version 2, Update 1", RFC 2743, January 2000. 267 268 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 269 C-bindings", RFC 2744, January 2000. 270 271 272Author's Address 273 274 Nicolas Williams 275 Sun Microsystems 276 277 278 279Williams Expires December 30, 2004 [Page 5] 280 281Internet-Draft A PRF for the Kerberos V Mech July 2004 282 283 284 5300 Riata Trace Ct 285 Austin, TX 78727 286 US 287 288 EMail: Nicolas.Williams@sun.com 289 290 291 292 293 294 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 335Williams Expires December 30, 2004 [Page 6] 336 337Internet-Draft A PRF for the Kerberos V Mech July 2004 338 339 340Intellectual Property Statement 341 342 The IETF takes no position regarding the validity or scope of any 343 Intellectual Property Rights or other rights that might be claimed to 344 pertain to the implementation or use of the technology described in 345 this document or the extent to which any license under such rights 346 might or might not be available; nor does it represent that it has 347 made any independent effort to identify any such rights. Information 348 on the procedures with respect to rights in RFC documents can be 349 found in BCP 78 and BCP 79. 350 351 Copies of IPR disclosures made to the IETF Secretariat and any 352 assurances of licenses to be made available, or the result of an 353 attempt made to obtain a general license or permission for the use of 354 such proprietary rights by implementers or users of this 355 specification can be obtained from the IETF on-line IPR repository at 356 http://www.ietf.org/ipr. 357 358 The IETF invites any interested party to bring to its attention any 359 copyrights, patents or patent applications, or other proprietary 360 rights that may cover technology that may be required to implement 361 this standard. Please address the information to the IETF at 362 ietf-ipr@ietf.org. 363 364 365Disclaimer of Validity 366 367 This document and the information contained herein are provided on an 368 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 369 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 370 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 371 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 372 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 373 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 374 375 376Copyright Statement 377 378 Copyright (C) The Internet Society (2004). This document is subject 379 to the rights, licenses and restrictions contained in BCP 78, and 380 except as set forth therein, the authors retain all their rights. 381 382 383Acknowledgment 384 385 Funding for the RFC Editor function is currently provided by the 386 Internet Society. 387 388 389 390 391Williams Expires December 30, 2004 [Page 7] 392 393 394