idnits 2.17.00 (12 Aug 2021) /tmp/idnits53611/draft-melnikov-sasl-scram-ldap-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 8, 2009) is 4570 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-sasl-scram has been published as RFC 5802 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 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: Informational November 8, 2009 5 Expires: May 12, 2010 7 LDAP schema for storing SCRAM secrets 8 draft-melnikov-sasl-scram-ldap-04 10 Abstract 12 This memo describes how the "authPassword" LDAP attribute can be used 13 for storing secrets used by the Salted Challenge Response (SCRAM) 14 mechanism in the Simple Authentication and Security Layer (SASL) 15 framework. 17 Note 19 A revised version of this draft document will be submitted to the RFC 20 editor as a Proposed Standard for the Internet Community. Discussion 21 and suggestions for improvement are requested, and should be sent to 22 sasl@ietf.org mailing list. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on May 12, 2010. 47 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Conventions Used in This Document . . . . . . . . . . . . . . . 3 65 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 77 1. Conventions Used in This Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Overview 85 This document describes how the authPassword LDAP attribute 86 [AUTHPASS] can be used for storing secrets used by [SCRAM] Simple 87 Authentication and Security Layer [RFC4422] Mechanisms. 89 The "scheme" part of the authPassword attribute is the SCRAM 90 mechanism name (always without the "-PLUS" suffix), e.g. "SCRAM- 91 SHA-1". See [SCRAM] for the exact syntax of SCRAM mechanism 92 names. 94 The "authInfo" part of the authPassword attribute is the iteration 95 count (iter-count in the ABNF below), followed by ":" and base-64 96 [BASE64] encoded salt. 98 The "authValue" part of the authPassword attribute is the base-64 99 [BASE64] encoded StoredKey [SCRAM], followed by ":" and base-64 100 [BASE64] encoded ServerKey [SCRAM]. 102 Syntax of the attribute can be expressed using ABNF [RFC5234]. Non 103 terminal references in the following ABNF are defined in either 104 [AUTHPASS], [RFC4422] or [RFC5234]. 106 scram-mech = "SCRAM-SHA-1" / scram-mech-ext 107 ; Complies with ABNF for 108 ; defined in [AUTHPASS]. 110 scram-authInfo = iter-count ":" salt 111 ; Complies with ABNF for 112 ; defined in [AUTHPASS]. 114 scram-authValue = stored-key ":" server-key 115 ; Complies with ABNF for 116 ; defined in [AUTHPASS]. 118 iter-count = %x31-39 *DIGIT 119 ; SCRAM iteration count. 120 ; A positive number without leading zeros 122 salt = 124 stored-key = 125 ; See definition in [SCRAM] 127 server-key = 128 ; See definition in [SCRAM] 130 scram-mech-ext = "SCRAM-" 1*9mech-char 131 ; Other SCRAM mechanisms registered 132 ; in the IANA registry for SASL 133 ; mechanism names. 135 mech-char = 137 [[anchor2: Add an example.]] 139 Note that the authPassword attribute is multivalued. For example, it 140 may contain multiple SCRAM hashes for different hashing algorithms. 142 3. Security Considerations 144 This document defines how authPassword attribute can be used to store 145 SCRAM secrets. So security considerations relevant to [SCRAM] and 146 hash function used with it are also relevant to this document. 148 General security considerations related to authPassword attribute (as 149 specified in [AUTHPASS]) also apply to use of authPassword as 150 specified in this document. In particular values of authPassword 151 SHOULD be protected as if they were clear text passwords. A read 152 operation on this attribute which is not protected by a privacy layer 153 (such as IPSec or TLS) can expose this attribute to an attacker who 154 a). would be able to use the intercepted value to impersonate the 155 user to all servers providing SCRAM access using the same hash 156 function, password, iteration count and salt, or b) would be able to 157 perform an offline dictionary or brute-force attack in order to 158 recover the user's password. 160 Servers MUST validate the format of the authPassword attribute before 161 using it for performing a SCRAM authentication exchange. It is 162 possible that an attacker compromised the LDAP server or got access 163 to the entry containing the attribute in order to exploit a 164 vulnerability in the subsystem performing the SCRAM authentication 165 exchange. Big iteration counts and invalid base-64 encoding are two 166 possible (but not the only) exploits in the format specified in the 167 document. 169 4. IANA Considerations 171 No action is required from IANA. 173 5. Acknowledgements 175 The author gratefully acknowledges the feedback provided by Chris 176 Newman, Kurt Zeilenga, Chris Lonvick, Peter Saint-Andre, Barry Leiba 177 and Chris Ridd. 179 6. Normative References 181 [AUTHPASS] 182 Zeilenga, K., "LDAP Authentication Password Schema", 183 RFC 3112, May 2001. 185 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 186 Encodings", RFC 4648, October 2006. 188 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 189 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 192 Security Layer (SASL)", RFC 4422, June 2006. 194 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 195 Specifications: ABNF", STD 68, RFC 5234, January 2008. 197 [SCRAM] Menon-Sen, A., Newman, C., Melnikov, A., and N. Williams, 198 "Salted Challenge Response (SCRAM) SASL Mechanism", 199 draft-ietf-sasl-scram-07.txt (work in progress), 200 September 2009. 202 Author's Address 204 Alexey Melnikov 205 Isode Limited 206 5 Castle Business Village 207 36 Station Road 208 Hampton, Middlesex TW12 2BX 209 UK 211 Email: alexey.melnikov@isode.com 212 URI: http://www.melnikov.ca/