idnits 2.17.1 draft-ietf-kitten-gssapi-prf-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 234), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 5 instances of lines with control characters in the document. 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 (July 2004) is 7223 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: 'RFC2743' is defined on line 172, but no explicit reference was found in the text == Unused Reference: 'RFC2744' is defined on line 175, but no explicit reference was found in the text == Unused Reference: 'RFC1750' is defined on line 183, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GGM1' -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Expires: December 30, 2004 July 2004 6 A PRF API extension for the GSS-API 7 draft-ietf-kitten-gssapi-prf-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 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 19 Internet-Drafts. 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." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document defines a Pseudo-Random Function (PRF) extension to the 41 Generic Security Service Applicatoin Programming Interface (GSS-API) 42 for keying application protocols given an established GSS-API 43 security context. The primary intended use of this function is to 44 key secure session layers that don't or cannot use GSS-API 45 per-message MIC (message integrity check) and wrap tokens for session 46 protection. 48 Table of Contents 50 1. Conventions used in this document . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 5 53 3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.1 Normative References . . . . . . . . . . . . . . . . . . . . . 8 57 5.2 Informative References . . . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . 9 61 1. Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2. Introduction 69 A need has arisen for users of the GSS-API to key applications' 70 cryptographic protocols using established GSS-API security contexts. 71 Such applications can use the GSS-API for authentication, but not for 72 transport security (for whatever reasons), and since the GSS-API does 73 not provide a method for obtaining keying material from established 74 security contexts such applications cannot make effective use of the 75 GSS-API. 77 To address this need we define a pseudo-random function (PRF) 78 extension to the GSS-API. 80 3. GSS_Pseudo_random() 82 Inputs: 84 o context CONTEXT handle, 85 o prf_in OCTET STRING, 86 o desired_output_len INTEGER 88 Outputs: 90 o major_status INTEGER, 91 o minor_status INTEGER, 92 o prf_out OCTET STRING 94 Return major_status codes: 95 o GSS_S_COMPLETE indicates no error. 96 o GSS_S_NO_CONTEXT indicates that a null context has been provided 97 as input. 98 o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been 99 provided as input. 100 o GSS_S_UNAVAILABLE indicates that the mechanism lacks support for 101 this function or, if the security context is not fully 102 established, that the context is not ready to compute the PRF. 103 o GSS_S_FAILURE indicates failure or lack of support; the minor 104 status code may provide additional information. 106 This function applies the established context's mechanism's keyed PRF 107 function to the input data (prf_in), keyed with key material 108 associated with the given security context and outputs the resulting 109 octet string (prf_out) of desired_output_len length. 111 The output string of this function MUST be a pseudo-random function 112 [GGM1][GGM2] of the input keyed with key material from the 113 established security context -- the chances of getting the same 114 output given different input parameters should be exponentially 115 small. 117 This function, applied to the same inputs by an initiator and 118 acceptor using the same established context, MUST produce the *same 119 results* for both, the initiator and acceptor, even if called 120 multiple times for the same context. 122 Mechanisms MAY limit the output of the PRF according, possibly in 123 ways related to the types of cryptographic keys available for the PRF 124 function, thus the prf_out output of GSS_Pseudo_random() MAY be 125 smaller than requested. 127 Mechanisms may be able to compute PRFs with security contexts that 128 are not fully established, therefore applications MAY call 129 GSS_Pseudo_random() with such security contexts. Such mechanisms 130 MUST return GSS_S_UNAVAILABLE when called on to compute a PRF given a 131 security context that is not fully established and also not ready for 132 PRF computation. Mechanisms that allow for PRF computation prior to 133 full security context establishment MUST use the same PRF and key 134 material, for any given security context, both, before and after full 135 context establishment, and the PRF and key material negotiation MUT 136 be authenticated when the security context is fully established. 138 3.1 C-Bindings 140 OM_uint32 gss_pseudo_random( 141 OM_uint32 *minor_status, 142 gss_ctx_id_t context, 143 const gss_buffer_t prf_in, 144 ssize_t desired_output_len, 145 gss_buffer_t prf_out 146 ); 148 4. Security Considerations 150 Care should be taken in properly designing a mechanism's PRF 151 function. 153 GSS mechanisms' PRF functions should use a key derived from contexts' 154 session keys and should preserve the forward security properties of 155 the mechanisms' key exchanges. 157 Some mechanisms may support the GSS PRF function with security 158 contexts that are not fully established, but applications MUST assume 159 that authentication, mutual or otherwise, has not completed until the 160 security context is fully established 162 5. References 164 5.1 Normative References 166 [GGM1] Goldreich, O., Goldwasser, S. and S. Micali, "How to 167 Construct Random Functions", October 1986. 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, March 1997. 172 [RFC2743] Linn, J., "Generic Security Service Application Program 173 Interface Version 2, Update 1", RFC 2743, January 2000. 175 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 176 C-bindings", RFC 2744, January 2000. 178 5.2 Informative References 180 [GGM2] Goldreich, O., Goldwasser, S. and S. Micali, "On the 181 Cryptographic Applications of Random Functions", 1985. 183 [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 184 Recommendations for Security", RFC 1750, December 1994. 186 Author's Address 188 Nicolas Williams 189 Sun Microsystems 190 5300 Riata Trace Ct 191 Austin, TX 78727 192 US 194 EMail: Nicolas.Williams@sun.com 196 Intellectual Property Statement 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at 218 ietf-ipr@ietf.org. 220 Disclaimer of Validity 222 This document and the information contained herein are provided on an 223 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 224 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 225 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 226 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 227 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 230 Copyright Statement 232 Copyright (C) The Internet Society (2004). This document is subject 233 to the rights, licenses and restrictions contained in BCP 78, and 234 except as set forth therein, the authors retain all their rights. 236 Acknowledgment 238 Funding for the RFC Editor function is currently provided by the 239 Internet Society.