idnits 2.17.1 draft-melnikov-sasl-scram-ldap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (September 12, 2009) is 5333 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) ** Downref: Normative reference to an Informational RFC: RFC 3112 (ref. 'AUTHPASS') == Outdated reference: A later version (-11) exists of draft-ietf-sasl-scram-07 Summary: 2 errors (**), 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: Standards Track September 12, 2009 5 Expires: March 16, 2010 7 LDAP schema for storing SCRAM secrets 8 draft-melnikov-sasl-scram-ldap-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and 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 March 16, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo describes how authPassword LDAP attribute can be used for 47 storing secrets used by Salted Challenge Response (SCRAM) Simple 48 Authentication and Security Layer (SASL) Mechanism. 50 Note 52 A revised version of this draft document will be submitted to the RFC 53 editor as a Proposed Standard for the Internet Community. Discussion 54 and suggestions for improvement are requested, and should be sent to 55 sasl@ietf.org mailing list. 57 Table of Contents 59 1. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . . 4 71 6.2. Informative References . . . . . . . . . . . . . . . . . . . 5 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . 5 75 1. Conventions Used in This Document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 2. Overview 83 This document describes how authPassword LDAP attribute [AUTHPASS] 84 can be used for storing secrets used by [SCRAM] Simple Authentication 85 and Security Layer [RFC4422] Mechanisms. 87 The "scheme" part of the authPassword attribute is the SCRAM 88 mechanism name (always without the "-PLUS" suffix), e.g. "SCRAM- 89 SHA-1". See [SCRAM] for the exact syntax of SCRAM mechanism 90 names. 92 The "authInfo" part of the authPassword attribute is the iteration 93 count, followed by ":" and base-64 [BASE64] encoded salt. 95 The "authValue" part of the authPassword attribute is the base-64 96 [BASE64] encoded StoredKey [SCRAM], followed by ":" and base-64 97 [BASE64] encoded ServerKey [SCRAM]. 99 Syntax of the attribute can be expressed using ABNF [RFC5234]. Non 100 terminal references in the following ABNF are defined in either 101 [AUTHPASS] or [RFC5234]. 103 scram-mech = "SCRAM-SHA-1" 104 ;; Complies with ABNF for 106 scram-authInfo = iter-count ":" salt 107 ;; Complies with ABNF for 109 scram-authValue = stored-key ":" server-key 110 ;; Complies with ABNF for 112 iter-count = %x31-39 *DIGIT 113 ; a positive number without leading zeros 115 salt = 117 stored-key = 119 server-key = 121 [[anchor2: Add an example.]] 122 Note that the authPassword attribute is multivalued. For example, it 123 may contain multiple SCRAM hashes for different hashing algorithms. 125 3. Security Considerations 127 Servers MUST validate format of the authPassword attribute before 128 using it for performing a SCRAM authentication exchange. It is 129 possible that an attacker compromised the LDAP server or got access 130 to the entry containing the attribute in order to exploit a 131 vulnerability in the subsystem performing SCRAM authentication 132 exchange. Big iteration counts and invalid base-64 encoding are two 133 possible (but not the only) exploits in the format specified in the 134 document. 136 4. IANA Considerations 138 No action is required from IANA. 140 5. Acknowledgements 142 The author gratefully acknowledges the feedback provided by Chris 143 Newman and Kurt Zeilenga. 145 6. References 147 6.1. Normative References 149 [AUTHPASS] 150 Zeilenga, K., "LDAP Authentication Password Schema", 151 RFC 3112, May 2001. 153 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 154 Encodings", RFC 4648, October 2006. 156 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 157 Requirement Levels", BCP 14, RFC 2119, March 1997. 159 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 160 Specifications: ABNF", STD 68, RFC 5234, January 2008. 162 [SCRAM] Menon-Sen, A., Newman, C., Melnikov, A., and N. Williams, 163 "Salted Challenge Response (SCRAM) SASL Mechanism", 164 draft-ietf-sasl-scram-07.txt (work in progress), 165 September 2009. 167 6.2. Informative References 169 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 170 Security Layer (SASL)", RFC 4422, June 2006. 172 Author's Address 174 Alexey Melnikov 175 Isode Limited 176 5 Castle Business Village 177 36 Station Road 178 Hampton, Middlesex TW12 2BX 179 UK 181 Email: alexey.melnikov@isode.com 182 URI: http://www.melnikov.ca/