idnits 2.17.1 draft-melnikov-sasl-scram-ldap-01.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 178. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 202. 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 109: '... 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 (November 19, 2008) is 5634 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 149, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3112 (ref. 'AUTHPASS') == Outdated reference: A later version (-13) exists of draft-newman-auth-scram-07 Summary: 3 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 November 19, 2008 5 Expires: May 23, 2009 7 LDAP schema for storing SCRAM secrets 8 draft-melnikov-sasl-scram-ldap-01 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 May 23, 2009. 35 Abstract 37 This memo describes how authPassword LDAP attribute can be used for 38 storing secrets used by Salted Challenge Response (SCRAM) Simple 39 Authentication and Security Layer (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 This memo defines a family of schema for authPassword attribute 68 defined in [AUTHPASS]. Non terminal references in the following ABNF 69 are defined in either [AUTHPASS] or [RFC5234]. 71 The "scheme" part of the authPassword attribute is the SCRAM 72 mechanism name, e.g. "SCRAM-HMAC-SHA-1". See [SCRAM] for the 73 exact syntax of SCRAM mechanism names. 75 The "authInfo" part of the authPassword attribute is the iteration 76 count, followed by ":" and base-64 [BASE64] encoded salt. 78 The "authValue" part of the authPassword attribute is the base-64 79 [BASE64] encoded StoredKey [SCRAM], followed by ":" and base-64 80 [BASE64] encoded ServerKey [SCRAM]. 82 Syntax of the attribute can be expressed using ABNF [RFC5234]: 84 scram-mech = "SCRAM-HMAC-SHA-1" 85 ;; Complies with ABNF for 87 scram-authInfo = iter-count ":" salt 88 ;; Complies with ABNF for 90 scram-authValue = stored-key ":" server-key 91 ;; Complies with ABNF for 93 iter-count = %x31-39 *DIGIT 94 ; a positive number without leading zeros 96 salt = <> 98 stored-key = <> 100 server-key = <> 102 [[anchor2: Add an example.]] 104 Note that the authPassword attribute is multivalued. For example, it 105 may contain multiple SCRAM hashes for different hashing algorithms. 107 2. Security Considerations 109 Servers MUST validate format of the saslSecretScram attribute before 110 using it for performing a SCRAM authentication exchange. It is 111 possible that an attacker compromised the LDAP server or got access 112 to the entry containing the attribute in order to exploit a 113 vulnerability in the subsystem performing SCRAM authentication 114 exchange. Big iteration counts and invalid base-64 encoding are two 115 possible (but not the only) exploits in the format specified in the 116 document. 118 [[anchor3: TBD.]] 120 3. IANA Considerations 122 No action is required from IANA. 124 4. Acknowledgements 126 The author gratefully acknowledges the feedback provided by Chris 127 Newman and Kurt Zeilenga. 129 5. References 131 5.1. Normative References 133 [AUTHPASS] 134 Zeilenga, K., "LDAP Authentication Password Schema", 135 RFC 3112, May 2001. 137 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 138 Encodings", RFC 4648, October 2006. 140 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 141 Specifications: ABNF", STD 68, RFC 5234, January 2008. 143 [SCRAM] Menon-Sen, A. and C. Newman, "Salted Challenge Response 144 (SCRAM) SASL Mechanism", draft-newman-auth-scram-07.txt 145 (work in progress), July 2008. 147 5.2. Informative References 149 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 150 Security Layer (SASL)", RFC 4422, June 2006. 152 Author's Address 154 Alexey Melnikov 155 Isode Limited 156 5 Castle Business Village 157 36 Station Road 158 Hampton, Middlesex TW12 2BX 159 UK 161 Email: alexey.melnikov@isode.com 162 URI: http://www.melnikov.ca/ 164 Full Copyright Statement 166 Copyright (C) The IETF Trust (2008). 168 This document is subject to the rights, licenses and restrictions 169 contained in BCP 78, and except as set forth therein, the authors 170 retain all their rights. 172 This document and the information contained herein are provided on an 173 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 174 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 175 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 176 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 177 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 178 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 180 Intellectual Property 182 The IETF takes no position regarding the validity or scope of any 183 Intellectual Property Rights or other rights that might be claimed to 184 pertain to the implementation or use of the technology described in 185 this document or the extent to which any license under such rights 186 might or might not be available; nor does it represent that it has 187 made any independent effort to identify any such rights. Information 188 on the procedures with respect to rights in RFC documents can be 189 found in BCP 78 and BCP 79. 191 Copies of IPR disclosures made to the IETF Secretariat and any 192 assurances of licenses to be made available, or the result of an 193 attempt made to obtain a general license or permission for the use of 194 such proprietary rights by implementers or users of this 195 specification can be obtained from the IETF on-line IPR repository at 196 http://www.ietf.org/ipr. 198 The IETF invites any interested party to bring to its attention any 199 copyrights, patents or patent applications, or other proprietary 200 rights that may cover technology that may be required to implement 201 this standard. Please address the information to the IETF at 202 ietf-ipr@ietf.org.