s4:heimdal: import lorikeet-heimdal-202201172009 (commit 5a0b45cd723628b3690ea848548b...
[samba.git] / source4 / heimdal / doc / standardisation / rfc4402.txt
1
2
3
4
5
6
7 Network Working Group                                        N. Williams
8 Request for Comments: 4402                                           Sun
9 Category: 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
15 Status 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
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 Abstract
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
35 Table 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
58 Williams                    Standards Track                     [Page 1]
59 \f
60 RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
61
62
63 1.  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
70 1.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
76 2.  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
114 Williams                    Standards Track                     [Page 2]
115 \f
116 RFC 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
124 3.  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
131 4.  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
170 Williams                    Standards Track                     [Page 3]
171 \f
172 RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
173
174
175 5.  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
198 Author'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
226 Williams                    Standards Track                     [Page 4]
227 \f
228 RFC 4402           A PRF for the Kerberos V Mechanism      February 2006
229
230
231 Full 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
247 Intellectual 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
271 Acknowledgement
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
282 Williams                    Standards Track                     [Page 5]
283 \f