idnits 2.17.1 draft-melnikov-sasl-scram-ldap-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 173. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 191. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 197. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '... Servers MUST validate format of the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 26, 2008) is 5661 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: 'RFC4422' is defined on line 144, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-newman-auth-scram-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SASL Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track October 26, 2008 5 Expires: April 29, 2009 7 LDAP schema for storing SCRAM secrets 8 draft-melnikov-sasl-scram-ldap-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 29, 2009. 35 Abstract 37 This memo describes LDAP schema for storing secrets used by Salted 38 Challenge Response (SCRAM) Simple Authentication and Security Layer 39 (SASL) Mechanism. 41 Note 43 A revised version of this draft document will be submitted to the RFC 44 editor as a Proposed Standard for the Internet Community. Discussion 45 and suggestions for improvement are requested, and should be sent to 46 ietf-sasl@imc.org. 48 Table of Contents 50 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Security Considerations . . . . . . . . . . . . . . . . . . . 3 54 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 58 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 4 60 5.2. Informative References . . . . . . . . . . . . . . . . . . . 4 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 4 63 Intellectual Property and Copyright Statements . . . . . . . 6 65 1. Overview 67 ( [[OID TBD by IANA]] 68 NAME 'saslSecretScram' 69 DESC 'SCRAM mechanism secret' 70 EQUALITY octetStringMatch 71 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 73 The saslSecretScram attribute is a dollar ("$") separated octet 74 string that contains information relevant for SCRAM [SCRAM] 75 authentication. The syntax of the string is as follows: 77 Hashing mechanism name, currently always "hmac-sha1". [[anchor2: 78 Add a reference to the IANA registry.]] 80 Iteration count. 82 base-64 [[anchor3: Add reference]] encoded salt. 84 base-64 [[anchor4: Add reference]] encoded StoredKey [SCRAM]. 86 base-64 [[anchor5: Add reference]] encoded ServerKey [SCRAM]. 88 Syntax of the attribute can be expressed using ABNF [RFC5234]: 90 scram-secret = hash-mech "$" iter-count "$" salt "$" 91 stored-key "$" server-key 93 hash-mech = "hmac-sha1" 95 iter-count = %x30-39 *DIGIT 96 ; a positive number without leading zeros 98 salt = <> 100 stored-key = <> 102 server-key = <> 104 [[anchor6: Add an example.]] 106 This attribute is multivalued. For example, it may contain multiple 107 SCRAM hashes for different hashing algorithms. 109 2. Security Considerations 111 Servers MUST validate format of the saslSecretScram attribute before 112 using it for performing a SCRAM authentication exchange. It is 113 possible that an attacker compromised the LDAP server or got access 114 to the entry containing the attribute in order to exploit a 115 vulnerability in the subsystem performing SCRAM authentication 116 exchange. Big iteration counts and invalid base-64 encoding are two 117 possible (but not the only) exploits in the format specified in the 118 document. 120 [[anchor7: TBD.]] 122 3. IANA Considerations 124 [[anchor8: TBD - assign OID for the new LDAP attribute.]] 126 4. Acknowledgements 128 The author gratefully acknowledges the feedback provided by 129 [[anchor10: XXX]]. 131 5. References 133 5.1. Normative References 135 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 136 Specifications: ABNF", STD 68, RFC 5234, January 2008. 138 [SCRAM] Menon-Sen, A. and C. Newman, "Salted Challenge Response 139 (SCRAM) SASL Mechanism", draft-newman-auth-scram-07.txt 140 (work in progress), July 2008. 142 5.2. Informative References 144 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 145 Security Layer (SASL)", RFC 4422, June 2006. 147 Author's Address 149 Alexey Melnikov 150 Isode Limited 151 5 Castle Business Village 152 36 Station Road 153 Hampton, Middlesex TW12 2BX 154 UK 156 Email: am.gate.i@googlemail.com 157 URI: http://www.melnikov.ca/ 159 Full Copyright Statement 161 Copyright (C) The IETF Trust (2008). 163 This document is subject to the rights, licenses and restrictions 164 contained in BCP 78, and except as set forth therein, the authors 165 retain all their rights. 167 This document and the information contained herein are provided on an 168 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 169 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 170 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 171 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 172 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 173 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 175 Intellectual Property 177 The IETF takes no position regarding the validity or scope of any 178 Intellectual Property Rights or other rights that might be claimed to 179 pertain to the implementation or use of the technology described in 180 this document or the extent to which any license under such rights 181 might or might not be available; nor does it represent that it has 182 made any independent effort to identify any such rights. Information 183 on the procedures with respect to rights in RFC documents can be 184 found in BCP 78 and BCP 79. 186 Copies of IPR disclosures made to the IETF Secretariat and any 187 assurances of licenses to be made available, or the result of an 188 attempt made to obtain a general license or permission for the use of 189 such proprietary rights by implementers or users of this 190 specification can be obtained from the IETF on-line IPR repository at 191 http://www.ietf.org/ipr. 193 The IETF invites any interested party to bring to its attention any 194 copyrights, patents or patent applications, or other proprietary 195 rights that may cover technology that may be required to implement 196 this standard. Please address the information to the IETF at 197 ietf-ipr@ietf.org.