1NETWORK WORKING GROUP                                        N. Williams
2Internet-Draft                                                       Sun
3Expires: November 13, 2005                                  May 12, 2005
4
5
6               A PRF for the Kerberos V GSS-API Mechanism
7                draft-ietf-kitten-krb5-gssapi-prf-03.txt
8
9Status of this Memo
10
11   By submitting this Internet-Draft, each author represents that any
12   applicable patent or other IPR claims of which he or she is aware
13   have been or will be disclosed, and any of which he or she becomes
14   aware will be disclosed, in accordance with Section 6 of BCP 79.
15
16   Internet-Drafts are working documents of the Internet Engineering
17   Task Force (IETF), its areas, and its working groups.  Note that
18   other groups may also distribute working documents as Internet-
19   Drafts.
20
21   Internet-Drafts are draft documents valid for a maximum of six months
22   and may be updated, replaced, or obsoleted by other documents at any
23   time.  It is inappropriate to use Internet-Drafts as reference
24   material or to cite them other than as "work in progress."
25
26   The list of current Internet-Drafts can be accessed at
27   http://www.ietf.org/ietf/1id-abstracts.txt.
28
29   The list of Internet-Draft Shadow Directories can be accessed at
30   http://www.ietf.org/shadow.html.
31
32   This Internet-Draft will expire on November 13, 2005.
33
34Copyright Notice
35
36   Copyright (C) The Internet Society (2005).
37
38Abstract
39
40   This document defines the Pseudo-Random Function (PRF) for the
41   Kerberos V mechanism for the Generic Security Service Application
42   Programming Interface (GSS-API), based on the PRF defined for the
43   Kerberos V cryptographic framework, for keying application protocols
44   given an established Kerberos V GSS-API security context.
45
46
47
48
49
50
51
52Williams                Expires November 13, 2005               [Page 1]
53
54Internet-Draft        A PRF for the Kerberos V Mech             May 2005
55
56
57Table of Contents
58
59   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
60   1.1 Conventions used in this document  . . . . . . . . . . . . . .  3
61   2.  Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . .  3
62   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  4
63   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
64   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  5
65       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  5
66       Intellectual Property and Copyright Statements . . . . . . . .  6
67
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
108Williams                Expires November 13, 2005               [Page 2]
109
110Internet-Draft        A PRF for the Kerberos V Mech             May 2005
111
112
1131.  Introduction
114
115   This document specifies the Kerberos V GSS-API mechanism's pseudo-
116   random function corresponding to [GSS-PRF].  The function is a "PRF+"
117   style construction.
118
1191.1  Conventions used in this document
120
121   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
123   document are to be interpreted as described in [RFC2119].
124
1252.  Kerberos V GSS Mechanism PRF
126
127   The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism
128   [RFC1964] shall be the output of a PRF+ function based on the
129   encryption type's PRF function keyed with the negotiated session key
130   of the security context corresponding to the 'prf_key' input
131   parameter of GSS_Pseudo_random().
132
133   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
134   parameter as follows:
135
136   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
137      acceptor, if any, or the sub-session asserted by the initiator, if
138      any, or the Ticket's session key
139
140   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
141      initiator, if any, or the Ticket's session key
142
143   The PRF+ function is a simple counter-based extension of the Kerberos
144   V pseudo-random function [RFC3961] for the encryption type of the
145   security context's keys:
146
147         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
148
149         Tn = pseudo-random(K, n || S)
150
151   where '||' is the concatenation operator, 'n' is encoded as a network
152   byte order 32-bit unsigned binary number, truncate(L, S) truncates
153   the input octet string S to length L, and pseudo-random() is the
154   Kerberos V pseudo-random function [RFC3961].
155
156   The maximum output size of the Kerberos V mechanism's GSS-API PRF
157   then is, necessarily, 2^32 times the output size of the pseudo-
158   random() function for the encryption type of the given key.
159
160   When the input size is longer than 2^14 octets as per [GSS-PRF] and
161
162
163
164Williams                Expires November 13, 2005               [Page 3]
165
166Internet-Draft        A PRF for the Kerberos V Mech             May 2005
167
168
169   exceeds an implementation's resources then the mechanism MUST return
170   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
171   code.
172
1733.  IANA Considerations
174
175   This document has no IANA considerations currently.  If and when a
176   relevant IANA registry of GSS-API symbols and constants is created
177   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
178   added to such a registry.
179
1804.  Security Considerations
181
182   Kerberos V encryption types' PRF functions use a key derived from
183   contexts' session keys and should preserve the forward security
184   properties of the mechanisms' key exchanges.
185
186   Legacy Kerberos V encryption types may be weak, particularly the
187   single-DES encryption types.
188
189   See also [GSS-PRF] for generic security considerations of
190   GSS_Pseudo_random().
191
192   See also [RFC3961] for generic security considerations of the
193   Kerberos V cryptographic framework.
194
195   Care should be taken not to exceed the useful lifetime of an
196   established security context's session key's useful lifetime as
197   implementations are not required to prevent overuse of the
198   GSS_Pseudo_random() function.  This can effectively be achieved by
199   limiting the number of GSS_Pseudo_random() calls to, say, a handful
200   of calls per-security context.
201
202   Use of Ticket session keys, rather than sub-session keys, when
203   initiators and acceptors fail to assert sub-session keys, is
204   dangerous as ticket reuse can lead to key reuse, therefore initiators
205   should assert sub-session keys always, and acceptors should assert
206   sub-session keys at least when initiators fail to do so..
207
208   The computational cost of computing this PRF+ may vary depending on
209   the Kerberos V encryption types being used, but generally the
210   computation of this PRF+ gets more expensive as the input and output
211   octet string lengths grow (note that the use of a counter in the PRF+
212   construction allows for parallelization).  This means that if an
213   application can be tricked into providing very large input octet
214   strings and requesting very long output octet strings then that may
215   constitute a denial of service attack on the application; therefore
216   applications SHOULD place appropriate limits on the size of any input
217
218
219
220Williams                Expires November 13, 2005               [Page 4]
221
222Internet-Draft        A PRF for the Kerberos V Mech             May 2005
223
224
225   octet strings received from their peers without integrity protection.
226
2275.  Normative References
228
229   [CFX]      Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
230              Version 5 GSS-API Mechanism: Version 2".
231
232   [GSS-PRF]  Williams, N., "A PRF API extension for the GSS-API".
233
234   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
235              RFC 1964, June 1996.
236
237   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
238              Requirement Levels", BCP 14, RFC 2119, March 1997.
239
240   [RFC2743]  Linn, J., "Generic Security Service Application Program
241              Interface Version 2, Update 1", RFC 2743, January 2000.
242
243   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
244              C-bindings", RFC 2744, January 2000.
245
246   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
247              Kerberos 5", RFC 3961, February 2005.
248
249
250Author's Address
251
252   Nicolas Williams
253   Sun Microsystems
254   5300 Riata Trace Ct
255   Austin, TX  78727
256   US
257
258   Email: Nicolas.Williams@sun.com
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276Williams                Expires November 13, 2005               [Page 5]
277
278Internet-Draft        A PRF for the Kerberos V Mech             May 2005
279
280
281Intellectual Property Statement
282
283   The IETF takes no position regarding the validity or scope of any
284   Intellectual Property Rights or other rights that might be claimed to
285   pertain to the implementation or use of the technology described in
286   this document or the extent to which any license under such rights
287   might or might not be available; nor does it represent that it has
288   made any independent effort to identify any such rights.  Information
289   on the procedures with respect to rights in RFC documents can be
290   found in BCP 78 and BCP 79.
291
292   Copies of IPR disclosures made to the IETF Secretariat and any
293   assurances of licenses to be made available, or the result of an
294   attempt made to obtain a general license or permission for the use of
295   such proprietary rights by implementers or users of this
296   specification can be obtained from the IETF on-line IPR repository at
297   http://www.ietf.org/ipr.
298
299   The IETF invites any interested party to bring to its attention any
300   copyrights, patents or patent applications, or other proprietary
301   rights that may cover technology that may be required to implement
302   this standard.  Please address the information to the IETF at
303   ietf-ipr@ietf.org.
304
305
306Disclaimer of Validity
307
308   This document and the information contained herein are provided on an
309   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
310   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
311   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
312   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
313   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
314   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
315
316
317Copyright Statement
318
319   Copyright (C) The Internet Society (2005).  This document is subject
320   to the rights, licenses and restrictions contained in BCP 78, and
321   except as set forth therein, the authors retain all their rights.
322
323
324Acknowledgment
325
326   Funding for the RFC Editor function is currently provided by the
327   Internet Society.
328
329
330
331
332Williams                Expires November 13, 2005               [Page 6]
333
334
335