1
2
3
4
5
6
7Network Working Group                                        N. Williams
8Request for Comments: 4402                                           Sun
9Category: Standards Track                                  February 2006
10
11
12   A Pseudo-Random Function (PRF) for the Kerberos V Generic Security
13       Service Application Program Interface (GSS-API) Mechanism
14
15Status of This Memo
16
17   This document specifies an Internet standards track protocol for the
18   Internet community, and requests discussion and suggestions for
19   improvements.  Please refer to the current edition of the "Internet
20   Official Protocol Standards" (STD 1) for the standardization state
21   and status of this protocol.  Distribution of this memo is unlimited.
22
23Copyright Notice
24
25   Copyright (C) The Internet Society (2006).
26
27Abstract
28
29   This document defines the Pseudo-Random Function (PRF) for the
30   Kerberos V mechanism for the Generic Security Service Application
31   Program Interface (GSS-API), based on the PRF defined for the
32   Kerberos V cryptographic framework, for keying application protocols
33   given an established Kerberos V GSS-API security context.
34
35Table of Contents
36
37   1. Introduction ....................................................2
38      1.1. Conventions Used in This Document ..........................2
39   2. Kerberos V GSS Mechanism PRF ....................................2
40   3. IANA Considerations .............................................3
41   4. Security Considerations .........................................3
42   5. Normative References ............................................4
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58Williams                    Standards Track                     [Page 1]
59
60RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
61
62
631.  Introduction
64
65   This document specifies the Kerberos V GSS-API mechanism's [RFC4121]
66   pseudo-random function corresponding to [RFC4401].  The function is a
67   "PRF+" style construction.  For more information see [RFC4401],
68   [RFC2743], [RFC2744], and [RFC4121].
69
701.1.  Conventions Used in This Document
71
72   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
73   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
74   document are to be interpreted as described in [RFC2119].
75
762.  Kerberos V GSS Mechanism PRF
77
78   The GSS-API PRF [RFC4401] function for the Kerberos V mechanism
79   [RFC4121] shall be the output of a PRF+ function based on the
80   encryption type's PRF function keyed with the negotiated session key
81   of the security context corresponding to the 'prf_key' input
82   parameter of GSS_Pseudo_random().
83
84   This PRF+ MUST be keyed with the key indicated by the 'prf_key' input
85   parameter as follows:
86
87   o  GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the
88      acceptor, if any, or the sub-session asserted by the initiator, if
89      any, or the Ticket's session key
90
91   o  GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the
92      initiator, if any, or the Ticket's session key
93
94   The PRF+ function is a simple counter-based extension of the Kerberos
95   V pseudo-random function [RFC3961] for the encryption type of the
96   security context's keys:
97
98         PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn)
99
100         Tn = pseudo-random(K, n || S)
101
102   where '||' is the concatenation operator, 'n' is encoded as a network
103   byte order 32-bit unsigned binary number, truncate(L, S) truncates
104   the input octet string S to length L, and pseudo-random() is the
105   Kerberos V pseudo-random function [RFC3961].
106
107   The maximum output size of the Kerberos V mechanism's GSS-API PRF
108   then is, necessarily, 2^32 times the output size of the pseudo-
109   random() function for the encryption type of the given key.
110
111
112
113
114Williams                    Standards Track                     [Page 2]
115
116RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
117
118
119   When the input size is longer than 2^14 octets as per [RFC4401] and
120   exceeds an implementation's resources, then the mechanism MUST return
121   GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status
122   code.
123
1243.  IANA Considerations
125
126   This document has no IANA considerations currently.  If and when a
127   relevant IANA registry of GSS-API symbols and constants is created,
128   then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be
129   added to such a registry.
130
1314.  Security Considerations
132
133   Kerberos V encryption types' PRF functions use a key derived from
134   contexts' session keys and should preserve the forward security
135   properties of the mechanisms' key exchanges.
136
137   Legacy Kerberos V encryption types may be weak, particularly the
138   single-DES encryption types.
139
140   See also [RFC4401] for generic security considerations of
141   GSS_Pseudo_random().
142
143   See also [RFC3961] for generic security considerations of the
144   Kerberos V cryptographic framework.
145
146   Use of Ticket session keys, rather than sub-session keys, when
147   initiators and acceptors fail to assert sub-session keys, is
148   dangerous as ticket reuse can lead to key reuse; therefore,
149   initiators should assert sub-session keys always, and acceptors
150   should assert sub-session keys at least when initiators fail to do
151   so.
152
153   The computational cost of computing this PRF+ may vary depending on
154   the Kerberos V encryption types being used, but generally the
155   computation of this PRF+ gets more expensive as the input and output
156   octet string lengths grow (note that the use of a counter in the PRF+
157   construction allows for parallelization).  This means that if an
158   application can be tricked into providing very large input octet
159   strings and requesting very long output octet strings, then that may
160   constitute a denial of service attack on the application; therefore,
161   applications SHOULD place appropriate limits on the size of any input
162   octet strings received from their peers without integrity protection.
163
164
165
166
167
168
169
170Williams                    Standards Track                     [Page 3]
171
172RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
173
174
1755.  Normative References
176
177   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
178              Requirement Levels", BCP 14, RFC 2119, March 1997.
179
180   [RFC2743]  Linn, J., "Generic Security Service Application Program
181              Interface Version 2, Update 1", RFC 2743, January 2000.
182
183   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
184              C-bindings", RFC 2744, January 2000.
185
186   [RFC3961]  Raeburn, K., "Encryption and Checksum Specifications for
187              Kerberos 5", RFC 3961, February 2005.
188
189   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
190              Version 5 Generic Security Service Application Program
191              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
192              July 2005.
193
194   [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
195              Extension for the Generic Security Service Application
196              Program Interface (GSS-API)", RFC 4401, February 2006.
197
198Author's Address
199
200   Nicolas Williams
201   Sun Microsystems
202   5300 Riata Trace Ct
203   Austin, TX  78727
204   US
205
206   EMail: Nicolas.Williams@sun.com
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226Williams                    Standards Track                     [Page 4]
227
228RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
229
230
231Full Copyright Statement
232
233   Copyright (C) The Internet Society (2006).
234
235   This document is subject to the rights, licenses and restrictions
236   contained in BCP 78, and except as set forth therein, the authors
237   retain all their rights.
238
239   This document and the information contained herein are provided on an
240   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
242   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
243   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
244   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
246
247Intellectual Property
248
249   The IETF takes no position regarding the validity or scope of any
250   Intellectual Property Rights or other rights that might be claimed to
251   pertain to the implementation or use of the technology described in
252   this document or the extent to which any license under such rights
253   might or might not be available; nor does it represent that it has
254   made any independent effort to identify any such rights.  Information
255   on the procedures with respect to rights in RFC documents can be
256   found in BCP 78 and BCP 79.
257
258   Copies of IPR disclosures made to the IETF Secretariat and any
259   assurances of licenses to be made available, or the result of an
260   attempt made to obtain a general license or permission for the use of
261   such proprietary rights by implementers or users of this
262   specification can be obtained from the IETF on-line IPR repository at
263   http://www.ietf.org/ipr.
264
265   The IETF invites any interested party to bring to its attention any
266   copyrights, patents or patent applications, or other proprietary
267   rights that may cover technology that may be required to implement
268   this standard.  Please address the information to the IETF at
269   ietf-ipr@ietf.org.
270
271Acknowledgement
272
273   Funding for the RFC Editor function is provided by the IETF
274   Administrative Support Activity (IASA).
275
276
277
278
279
280
281
282Williams                    Standards Track                     [Page 5]
283
284