• Aucun résultat trouvé

This document is a product of the Internet Engineering Task Force (IETF)


Academic year: 2022

Partager "This document is a product of the Internet Engineering Task Force (IETF)"


Texte intégral


Internet Engineering Task Force (IETF) A. Melnikov Request for Comments: 5803 Isode Limited Category: Informational July 2010 ISSN: 2070-1721

Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets


This memo describes how the "authPassword" Lightweight Directory Access Protocol (LDAP) attribute can be used for storing secrets used by the Salted Challenge Response Authentication Message (SCRAM)

mechanism in the Simple Authentication and Security Layer (SASL) framework.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Melnikov Informational [Page 1]


RFC 5803 LDAP Schema for Storing SCRAM Secrets July 2010

Table of Contents

1. Overview ...2

2. Conventions Used in This Document ...3

3. Security Considerations ...3

4. Acknowledgements ...4

5. Normative References ...4 1. Overview

This document describes how the authPassword LDAP attribute

[AUTHPASS] can be used for storing secrets used by [SCRAM] Simple Authentication and Security Layer [RFC4422] Mechanisms.

The "scheme" part of the authPassword attribute is the SCRAM mechanism name (always without the "-PLUS" suffix), e.g., "SCRAM- SHA-1". See [SCRAM] for the exact syntax of SCRAM mechanism names.

The "authInfo" part of the authPassword attribute is the iteration count (iter-count in the ABNF below), followed by ":" and base64- encoded [BASE64] salt.

The "authValue" part of the authPassword attribute is the base64- encoded [BASE64] StoredKey [SCRAM], followed by ":" and base64- encoded [BASE64] ServerKey [SCRAM].

Syntax of the attribute can be expressed using ABNF [RFC5234]. Non- terminal references in the following ABNF are defined in either [AUTHPASS], [RFC4422], or [RFC5234].

scram-mech = "SCRAM-SHA-1" / scram-mech-ext ; Complies with ABNF for <scheme>

; defined in [AUTHPASS].

scram-authInfo = iter-count ":" salt

; Complies with ABNF for <authInfo>

; defined in [AUTHPASS].

scram-authValue = stored-key ":" server-key

; Complies with ABNF for <authValue>

; defined in [AUTHPASS].

iter-count = %x31-39 *DIGIT

; SCRAM iteration count.

; A positive number without leading zeros.

salt = <base64-encoded value>

Melnikov Informational [Page 2]


RFC 5803 LDAP Schema for Storing SCRAM Secrets July 2010

stored-key = <base64-encoded value>

; See definition in [SCRAM].

server-key = <base64-encoded value>

; See definition in [SCRAM].

scram-mech-ext = "SCRAM-" 1*9mech-char

; Other SCRAM mechanisms registered ; in the IANA registry for SASL ; mechanism names.

mech-char = <Defined in RFC 4422>

Note that the authPassword attribute is multivalued. For example, it may contain multiple SCRAM hashes for different hashing algorithms.

2. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Security Considerations

This document defines how the authPassword attribute can be used to store SCRAM secrets. Therefore, security considerations relevant to [SCRAM] and hash functions used with it are also relevant to this document.

General security considerations related to the authPassword attribute (as specified in [AUTHPASS]) also apply to the use of authPassword as specified in this document. In particular, the values of

authPassword SHOULD be protected as if they were cleartext passwords.

A read operation on this attribute that is not protected by a privacy layer (such as IPsec or TLS) can expose this attribute to an attacker who a) would be able to use the intercepted value to impersonate the user to all servers providing SCRAM access using the same hash

function, password, iteration count, and salt or b) would be able to perform an offline dictionary or brute-force attack in order to recover the user’s password.

Servers MUST validate the format of the authPassword attribute before using it for performing a SCRAM authentication exchange. It is

possible that an attacker compromised the LDAP server or got access to the entry containing the attribute in order to exploit a

vulnerability in the subsystem performing the SCRAM authentication

Melnikov Informational [Page 3]


RFC 5803 LDAP Schema for Storing SCRAM Secrets July 2010

exchange. Big iteration counts and invalid base64 encoding are two possible (but not the only) exploits in the format specified in the document.

4. Acknowledgements

The author gratefully acknowledges the feedback provided by Chris Newman, Kurt Zeilenga, Chris Lonvick, Peter Saint-Andre, Barry Leiba, and Chris Ridd.

5. Normative References

[AUTHPASS] Zeilenga, K., "LDAP Authentication Password Schema", RFC 3112, May 2001.

[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[SCRAM] Menon-Sen, A., Newman, C., Melnikov, A., and N. Williams, "Salted Challenge Response Authentication Message (SCRAM) SASL Mechanisms", RFC 5802, July 2010.

Author’s Address Alexey Melnikov Isode Limited

5 Castle Business Village 36 Station Road

Hampton, Middlesex TW12 2BX UK

EMail: alexey.melnikov@isode.com URI: http://www.melnikov.ca/

Melnikov Informational [Page 4]


Documents relatifs

When a transit node’s policy permits it to support reroute request processing and local repair, the node MUST examine incoming PathErr messages to see it the node can perform

Each response may be followed by a response code (see Section 1.3) and by a string consisting of human-readable text in the local language (as returned by the LANGUAGE

This document defines the PaC-EP Master Key (PEMK) that is used by a secure association protocol as the pre-shared secret between the PaC and EP to enable cryptographic filters

The DCSite captures the type, identifier, location, and other pertinent information about the credential gathering process, or data collection site, used in the

It provides a collection of data objects that can be queried using the SNMP protocol and represent the current status of the NTP entity.. This includes general information

This document defines a DHCPv6 option and associated suboptions to provide Network Time Protocol version 4 [RFC5905] or greater server location information to DHCPv6

As a more efficient alternative, if an HTTP server wishes to offer the ability to subscribe to the state of several HTTP resources in a single SUBSCRIBE request, it returns a

As a result, even if a malicious user were able to determine the external (mapped) IPv4 address and port assigned to the Teredo client, the malicious user would still need

This document specifies the payload format for packetization of GSM Half Rate (GSM-HR) codec [TS46.002] encoded speech signals into the Real-time Transport Protocol

The Hypertext Transfer Protocol (HTTP) Extensions for the Web Distributed Authoring and Versioning (WebDAV) do not define the behavior for the &#34;POST&#34; method when

In cases where the Registration Document is to be published in a specification other than RFC, the authors must inform IANA, as soon as the Enumservice Specification has

As specified in RFC 3920, the XMPP address format reuses the &#34;stringprep&#34; technology for preparation of non-ASCII characters [STRINGPREP], including the Nameprep

Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without

To address this problem, this document defines a TLV to be added to purges to record the system ID of the IS generating the purge.. Field experience has shown

This document includes specifications for the United States of America (USA) Federal Information Processing Standard (FIPS) Secure Hash Algorithms (SHAs), code to implement

As with the LSRR and SSRR options, if the packet does not pass these checks it should be dropped, and this event should be logged (e.g., a counter could be incremented to

This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort

Authentication-Results field in its header hash (in this case, the MLM), the Verifier is in a position to believe that a valid Author signature was present on the message.

o A local Signal Fail indication on the protection path SHALL cause the LER to go into local Unavailable state and begin transmission of an SF(0,0) message, if the

[RFC4869] proposed four new UI suites based on implementations of the United States National Security Agency’s Suite B algorithms (see [SuiteB]).. As with the VPN suites,

If configured at a minimum level of security of 192 bits, ECDSA-384 MUST be used by both parties for IKEv2 authentication.. Initiators and responders in a system configured at

The Sieve Notify extension specifies that notification methods MUST provide mechanisms for avoiding notification loops. In this case, the SIP protocol itself prevents loops,

The AS_SET path segment type of the AS_PATH attribute (Sections 4.3 and 5.1.2 of [RFC4271]) is created by a router that is performing route aggregation and contains an