idnits 2.17.1 draft-ietf-kitten-krb5-gssapi-prf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 202. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 208. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 12, 2005) is 6922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CFX' is defined on line 156, but no explicit reference was found in the text == Unused Reference: 'RFC2743' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC2744' is defined on line 170, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CFX' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSS-PRF' Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP N. Williams 2 Internet-Draft Sun 3 Expires: November 13, 2005 May 12, 2005 5 A PRF for the Kerberos V GSS-API Mechanism 6 draft-ietf-kitten-krb5-gssapi-prf-03.txt 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 13, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). 37 Abstract 39 This document defines the Pseudo-Random Function (PRF) for the 40 Kerberos V mechanism for the Generic Security Service Application 41 Programming Interface (GSS-API), based on the PRF defined for the 42 Kerberos V cryptographic framework, for keying application protocols 43 given an established Kerberos V GSS-API security context. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Kerberos V GSS Mechanism PRF . . . . . . . . . . . . . . . . . 3 50 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 51 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 52 5. Normative References . . . . . . . . . . . . . . . . . . . . . 5 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 54 Intellectual Property and Copyright Statements . . . . . . . . 6 56 1. Introduction 58 This document specifies the Kerberos V GSS-API mechanism's pseudo- 59 random function corresponding to [GSS-PRF]. The function is a "PRF+" 60 style construction. 62 1.1 Conventions used in this document 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Kerberos V GSS Mechanism PRF 70 The GSS-API PRF [GSS-PRF] function for the Kerberos V mechanism 71 [RFC1964] shall be the output of a PRF+ function based on the 72 encryption type's PRF function keyed with the negotiated session key 73 of the security context corresponding to the 'prf_key' input 74 parameter of GSS_Pseudo_random(). 76 This PRF+ MUST be keyed with the key indicated by the 'prf_key' input 77 parameter as follows: 79 o GSS_C_PRF_KEY_FULL -- use the sub-session key asserted by the 80 acceptor, if any, or the sub-session asserted by the initiator, if 81 any, or the Ticket's session key 83 o GSS_C_PRF_KEY_PARTIAL -- use the sub-session key asserted by the 84 initiator, if any, or the Ticket's session key 86 The PRF+ function is a simple counter-based extension of the Kerberos 87 V pseudo-random function [RFC3961] for the encryption type of the 88 security context's keys: 90 PRF+(K, L, S) = truncate(L, T1 || T2 || .. || Tn) 92 Tn = pseudo-random(K, n || S) 94 where '||' is the concatenation operator, 'n' is encoded as a network 95 byte order 32-bit unsigned binary number, truncate(L, S) truncates 96 the input octet string S to length L, and pseudo-random() is the 97 Kerberos V pseudo-random function [RFC3961]. 99 The maximum output size of the Kerberos V mechanism's GSS-API PRF 100 then is, necessarily, 2^32 times the output size of the pseudo- 101 random() function for the encryption type of the given key. 103 When the input size is longer than 2^14 octets as per [GSS-PRF] and 104 exceeds an implementation's resources then the mechanism MUST return 105 GSS_S_FAILURE and GSS_KRB5_S_KG_INPUT_TOO_LONG as the minor status 106 code. 108 3. IANA Considerations 110 This document has no IANA considerations currently. If and when a 111 relevant IANA registry of GSS-API symbols and constants is created 112 then the GSS_KRB5_S_KG_INPUT_TOO_LONG minor status code should be 113 added to such a registry. 115 4. Security Considerations 117 Kerberos V encryption types' PRF functions use a key derived from 118 contexts' session keys and should preserve the forward security 119 properties of the mechanisms' key exchanges. 121 Legacy Kerberos V encryption types may be weak, particularly the 122 single-DES encryption types. 124 See also [GSS-PRF] for generic security considerations of 125 GSS_Pseudo_random(). 127 See also [RFC3961] for generic security considerations of the 128 Kerberos V cryptographic framework. 130 Care should be taken not to exceed the useful lifetime of an 131 established security context's session key's useful lifetime as 132 implementations are not required to prevent overuse of the 133 GSS_Pseudo_random() function. This can effectively be achieved by 134 limiting the number of GSS_Pseudo_random() calls to, say, a handful 135 of calls per-security context. 137 Use of Ticket session keys, rather than sub-session keys, when 138 initiators and acceptors fail to assert sub-session keys, is 139 dangerous as ticket reuse can lead to key reuse, therefore initiators 140 should assert sub-session keys always, and acceptors should assert 141 sub-session keys at least when initiators fail to do so.. 143 The computational cost of computing this PRF+ may vary depending on 144 the Kerberos V encryption types being used, but generally the 145 computation of this PRF+ gets more expensive as the input and output 146 octet string lengths grow (note that the use of a counter in the PRF+ 147 construction allows for parallelization). This means that if an 148 application can be tricked into providing very large input octet 149 strings and requesting very long output octet strings then that may 150 constitute a denial of service attack on the application; therefore 151 applications SHOULD place appropriate limits on the size of any input 152 octet strings received from their peers without integrity protection. 154 5. Normative References 156 [CFX] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 157 Version 5 GSS-API Mechanism: Version 2". 159 [GSS-PRF] Williams, N., "A PRF API extension for the GSS-API". 161 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 162 RFC 1964, June 1996. 164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 165 Requirement Levels", BCP 14, RFC 2119, March 1997. 167 [RFC2743] Linn, J., "Generic Security Service Application Program 168 Interface Version 2, Update 1", RFC 2743, January 2000. 170 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 171 C-bindings", RFC 2744, January 2000. 173 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 174 Kerberos 5", RFC 3961, February 2005. 176 Author's Address 178 Nicolas Williams 179 Sun Microsystems 180 5300 Riata Trace Ct 181 Austin, TX 78727 182 US 184 Email: Nicolas.Williams@sun.com 186 Intellectual Property Statement 188 The IETF takes no position regarding the validity or scope of any 189 Intellectual Property Rights or other rights that might be claimed to 190 pertain to the implementation or use of the technology described in 191 this document or the extent to which any license under such rights 192 might or might not be available; nor does it represent that it has 193 made any independent effort to identify any such rights. Information 194 on the procedures with respect to rights in RFC documents can be 195 found in BCP 78 and BCP 79. 197 Copies of IPR disclosures made to the IETF Secretariat and any 198 assurances of licenses to be made available, or the result of an 199 attempt made to obtain a general license or permission for the use of 200 such proprietary rights by implementers or users of this 201 specification can be obtained from the IETF on-line IPR repository at 202 http://www.ietf.org/ipr. 204 The IETF invites any interested party to bring to its attention any 205 copyrights, patents or patent applications, or other proprietary 206 rights that may cover technology that may be required to implement 207 this standard. Please address the information to the IETF at 208 ietf-ipr@ietf.org. 210 Disclaimer of Validity 212 This document and the information contained herein are provided on an 213 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 214 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 215 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 216 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 217 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 218 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 220 Copyright Statement 222 Copyright (C) The Internet Society (2005). This document is subject 223 to the rights, licenses and restrictions contained in BCP 78, and 224 except as set forth therein, the authors retain all their rights. 226 Acknowledgment 228 Funding for the RFC Editor function is currently provided by the 229 Internet Society.