Network Working Group Request for Comments: 3112 Категория: Informational K. Zeilenga, OpenLDAP Foundation Май 2001 года
В этом документе предоставлена информация для сообщества Интернет. В нём не даётся спецификация какого-либо рода стандарта Интернет. Ограничений на распространение этого документа не накладывается.
Copyright (C) The Internet Society (2001). Все права защищены.
В этом документе описывается схема данных для поддержки аутентификации по имени пользователя и паролю в каталоге LDAP (Lightweight Directory Access Protocol), в том числе тип атрибута authPassword. Данный тип атрибута содержит значения, производные от пароля пользователя (обычно используется односторонний хэш достаточной криптографической стойкости). authPassword предназначен для использования вместо типа атрибута userPassword.
Предназначение типа атрибута userPassword [RFC2256] — хранение значений, используемых для поддержки операции "простого" подсоединения ("simple" bind) LDAP [RFC2251]. Однако значениями атрибута userPassword должны быть пароли в открытом виде. Часто желательно вместо реальных паролей пользователей хранить производные значения от этих паролей.
Тип атрибута authPassword предназначен для хранения информации, используемой для реализации простой аутентификации на основе пароля. Данный тип атрибута может использоваться серверами LDAP для реализации метода аутентификации "simple" LDAP-операции Bind.
Для этого типа атрибута поддерживается несколько схем определения хранимых данных. Предусмотрено правило соответствия для использования с расширяемыми фильтрами поиска, позволяющее клиентам утверждать, что пароль в открытом текстовом виде "соответствует" одному из значений атрибута.
В схемах определения хранимых данных часто используется одностороннее хэширование достаточной криптографической стойкости. Несмотря на то, что использование одностороннего хэширования снижает вероятность получения неавторизованного доступа к каталогу при возможном раскрытии значений атрибута (если только в алгоритмах/реализации хэширования не обнаружены уязвимости), хэширование паролей должно рассматриваться лишь как дополнительный уровень защиты. Рекомендуется (RECOMMENDED) защищать хэшированнные значения так же, как если бы это были пароли в открытом виде.
Этот атрибут может использоваться в сочетании с механизмами генерации пароля на стороне сервера (такими как расширенная операция LDAP модификации пароля [RFC3062]).
Доступ к этому атрибуту может регулироваться средствами административного контроля, например, такими, которые реализуют политику смены пароля.
В этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется) и "MAY" (возможно) интерпретируются так, как описано в RFC 2119.
Приводимые ниже определения схемы данных описаны в терминах определения синтаксиса атрибута LDAPv3 [RFC2252]. Конкретный синтаксис определён с использованием ABNF [RFC2234].
( 1.3.6.1.4.1.4203.1.1.2 DESC 'authentication password syntax' )
Значения этого синтаксиса кодируются в соответствии со следующим определением:
authPasswordValue = w scheme s authInfo s authValue w
scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F
; 0-9, A-Z, "-", ".", "/", or "_"
authInfo = schemeSpecificValue
authValue = schemeSpecificValue
schemeSpecificValue = *( %x21-23 / %x25-7E )
; печатные символы ASCII, кроме "$" и " "
s = w SEP w
w = *SP
SEP = %x24 ; "$"
SP = %x20 ; " " (пробел)
В этом определении поле scheme описывает механизм определения хранимых данных, а содержимое полей authInfo и authValue специфично для конкретного механизма (указанного в поле scheme). Поле authInfo часто представляет собой закодированную в base64 "соль". Поле authValue часто представляет собой закодированное в base64 значение, производное от пароля (паролей) пользователя. Значения атрибута с данным синтаксисом чувствительны к регистру символов.
Передача по сети значений с данным синтаксисом крайне нежелательна в случаях, когда используемая при передаче транспортная служба не гарантирует обеспечение конфиденциальности данных, в результате чего может произойти разглашение таких значений неавторизованным третьим сторонам.
В разделе 3 данного документа описывается несколько схем определения хранимых данных, а также требования по именованию таких схем.
( 1.3.6.1.4.1.4203.1.2.2 NAME 'authPasswordExactMatch' DESC 'authentication password exact matching rule' SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
Данное правило соответствия позволяет клиентам утверждать, что заявляемое значение с синтаксисом authPasswordSyntax соответствует значениям с синтаксисом authPasswordSyntax. Оно предназначено для использования в качестве правила EQUALITY атрибутов с синтаксисом authPasswordSyntax.
Утверждение оценивается как "TRUE", если существует значение атрибута, в котором компоненты scheme, authInfo и authValue такие же, как и в заявляемом значении. Утверждение оценивается как "FALSE", если нет значения атрибута, в котором эти компоненты совпадают с компонентами в заявляемом значении. Во всех остальных случаях утверждение оценивается как "Undefined".
( 1.3.6.1.4.1.4203.1.2.3
NAME 'authPasswordMatch'
DESC 'authentication password matching rule'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
Данное правило соответствия позволяет клиентам утверждать, что пароль соответствует значениям с синтаксисом authPasswordSyntax при использовании компонента фильтра extensibleMatch. Каждое значение сопоставляется согласно его схеме определения хранимых данных, указанной в поле scheme. Утверждение оценивается как "TRUE", если одно или несколько значений атрибута соответствует заявляемому значению, как "FALSE", если все значения атрибута не соответствуют заявляемому значению, и как "Undefined" во всех остальных случаях.
Серверам, поддерживающим использование данного правила соответствия, следует (SHOULD) опубликовать соответствующие значения в атрибуте matchingRuleUse согласно требованиям раздела 4.5 RFC2252.
Передача по сети значений утверждений для сопоставления по правилу соответствия authPasswordMatch крайне нежелательна в случаях, когда используемая при передаче транспортная служба не гарантирует обеспечение конфиденциальности данных, в результате чего может произойти разглашение таких значений неавторизованным третьим сторонам.
( 1.3.6.1.4.1.4203.1.3.3
NAME 'supportedAuthPasswordSchemes'
DESC 'supported password storage schemes'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
USAGE dSAOperation )
Значениями данного атрибута являются имена поддерживаемых сервером схем парольной аутентификации. Синтаксис имён схем описан в разделе 2.1. Данный атрибут может присутствовать только в записи корневой DSE. Если сервер не поддерживает ни одной парольной схемы, данный атрибут не должен присутствовать.
( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword' DESC 'password authentication information' EQUALITY 1.3.6.1.4.1.4203.1.2.2 SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
Значения данного атрибута представляют собой пароль (пароли) пользователей и соответствуют синтаксису authPasswordSyntax, описанному в разделе 2.1. Значения данного атрибута могут быть использованы в целях выполнения аутентификации.
Передача по сети значений атрибута authPassword крайне нежелательна в случаях, когда используемая при передаче транспортная служба не гарантирует обеспечение конфиденциальности данных, в результате чего может произойти разглашение таких значений неавторизованным третьим сторонам.
( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject' DESC 'authentication password mix in class' MAY 'authPassword' AUXILIARY )
Записи с этим объектным классом могут содержать атрибуты типа authPassword.
В данном разделе описываются схемы определения хранимых данных "MD5" и "SHA1". В других документах могут быть определены другие схемы. Имена схем, определения которых не даны в RFC, следует (SHOULD) начинать с префикса "X-" для указания того, что это схема для частного использования или специфичная для реализации схема определения хранимых данных. Кроме того, такие схемы могут именоваться с использованием точечно-числового представления OID [RFC2252], ассоциированного со схемой.
Схема определения хранимых данных MD5 [RFC1321] именуется как "MD5".
Значение поля authValue представляет собой закодированный в base64 MD5-дайджест конкатенации пароля пользователя и "соли". Закодированное в base64 значение "соли" приводится в поле authInfo. Данная "соль" должна (MUST) быть длиной не менее 64-х бит. Реализации данной схемы должны (MUST) поддерживать значения "соли" длиной до 128 бит.
Пример:
Для пользователя "joe" с паролем "mary" и "солью" "salt" в полеauthInfoбудет закодированное в base64 значение "salt", а в полеauthValueбудет закодированный в base64 MD5-дайджест от значения "marysalt".
Сопоставление предоставляемого пароля и значения атрибута, сформированного по данной схеме определения хранимых данных, должно (SHALL) оцениваться как TRUE, если и только если MD5-дайджест конкатенации предоставляемого значения с "солью" эквивалентен MD5-дайджесту, содержащемуся в поле AuthValue. Сопоставление SHALL должно (SHALL) оцениваться как неопределённое, если сервер по каким-либо причинам не может завершить проверку эквивалентности. В остальных случаях сопоставление должно (SHALL) оцениваться как FALSE.
Значения, сформированные по данной схеме определения хранимых данных, следует (SHOULD) использовать только для реализации простой аутентификации по имени пользователя и паролю.
Схема определения хранимых данных SHA1 [SHA1] именуется как "SHA1".
Значение поля authValue представляет собой закодированный в base64 SHA1-дайджест конкатенации пароля пользователя и "соли". Закодированное в base64 значение "соли" приводится в поле authInfo. Данная "соль" должна (MUST) быть длиной не менее 64-х бит. Реализации данной схемы должны (MUST) поддерживать значения "соли" длиной до 128 бит.
Пример:
Для пользователя "joe" с паролем "mary" и "солью" "salt" в полеauthInfoбудет закодированное в base64 значение "salt", а в полеauthValueбудет закодированный в base64 SHA1-дайджест от значения "marysalt".
Сопоставление предоставляемого пароля и значения атрибута, сформированного по данной схеме определения хранимых данных, должно (SHALL) оцениваться как TRUE, если и только если SHA1-дайджест конкатенации предоставляемого значения с "солью" эквивалентен SHA1-дайджесту, содержащемуся в поле AuthValue. Сопоставление SHALL должно (SHALL) оцениваться как неопределённое, если сервер по каким-либо причинам не может завершить проверку эквивалентности. В остальных случаях сопоставление должно (SHALL) оцениваться как FALSE.
Значения, сформированные по данной схеме определения хранимых данных, следует (SHOULD) использовать только для реализации простой аутентификации по имени пользователя и паролю.
Для всех реализаций данной спецификации:
Серверы могут (MAY) накладывать ограничения на то, какие схемы определения хранимых данных будут использоваться совместно с конкретным процессом аутентификации, но должны (SHOULD) использовать все значения, соответствующие выбранным схемам. Если заявляемый пароль соответствует любому из хранимых значений, то этот заявляемый пароль следует (SHOULD) считать валидным. Для поддержки процесса аутентификации серверы могут (MAY) в сочетании с
authPasswordиспользовать другие механизмы строгой аутентификации, такие какuserPasswordили внешние хранилища паролей.Серверы, поддерживающие аутентификацию Simple Bind, должны (MUST) поддерживать схему SHA1, также им следует (SHOULD) поддерживать схему MD5.
Если не обеспечена должная защита конфиденциальности, серверам не следует (SHOULD NOT) ни предоставлять открытый доступ к значениям атрибута
authPassword, ни разрешать выполнение операций, при которых раскрываются значенияauthPasswordили выполняются сопоставления по правилуauthPasswordMatch.Если не обеспечена должная защита конфиденциальности, клиентам не следует (SHOULD NOT) инициировать операции, при которых предоставляются или запрашиваются значения
authPasswordили выполняются сопоставления по правилуauthPasswordMatch.Клиентам не следует (SHOULD NOT) считать, что успешного выполнения сопоставления по правилу
authPasswordMatchпри осуществлении операций сравнения (Compare) или поиска (Search), достаточно, чтобы получить доступ к каталогу. Для аутентификации с целью получения доступа к каталогу должна (MUST) быть использована операция подсоединения (Bind).
В этом документе описывается, каким образом аутентификационная информация может храниться в каталоге. Аутентификационная информация должна (MUST) быть адекватным образом защищена, поскольку её нерегламентированное раскрытие позволит злоумышленникам получить немедленный доступ к каталогу, как описано в [RFC2829].
Поскольку в алгоритме хэширования или в конкретной реализации этого алгоритма могут быть обнаружены уязвимости, либо значения, сформированные по этому алгоритму, в случае свободного доступа к ним могут подвергаться различным атакам, значения authPassword следует (SHOULD) защищать так, как если бы это были пароли в открытом виде. При передаче таких значений по сети следует (SHOULD) обеспечить защиту конфиденциальности, например, с помощью IPSEC или TLS.
Клиентам следует (SHOULD) использовать механизмы строгой аутентификации [RFC2829].
Правило соответствия authPasswordMatch позволяет приложениям проверять валидность пароля пользователя и, следовательно, может быть использовано для выполнения атаки. Серверам следует (SHOULD) принимать соответствующие меры для защиты каталога от таких атак.
Некоторые парольные схемы могут потреблять много ресурсов процессора. Серверам следует (SHOULD) принимать соответствующие меры для защиты от атак типа "отказ в обслуживании" (DoS).
Атрибут authPassword не накладывает ограничений по части назначения единственного пароля для аутентификационной идентификационной сущности. Злоумышленник, получивший доступ на запись к этому атрибуту, может сохранить в каталоге дополнительные значения, оставив при этом истинный пароль (пароли) пользователя действующим. Рекомендуется (RECOMMENDED) использование политики уведомления клиентов и серверов о возможности возникновения подобной ситуации.
Уровень принимаемых защитных мер для разных схем определения хранимых данных отличается. Рекомендуется (RECOMMENDED), чтобы серверы поддерживали отбор используемых схем путём задания параметра конфигурации. Это позволит простым способом отключить использование какой-либо схемы при обнаружении в ней серьёзной уязвимости.
Части этого документа заимствованы из ряда документов IETF. Документ основан на материалах рабочей группы IETF LDAPext.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, апрель 1992 г.
[RFC2219] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, ноябрь 1997 г.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, декабрь 1997 г.
[RFC2307] Howard, L., "Подход к использованию LDAP в качестве Сетевой Информационной Службы (Network Information Service)", RFC 2307, март 1998 г.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, "Authentication Methods for LDAP", RFC 2829, июнь 2000 г.
[RFC3062] Zeilenga, K., "Расширенная операция LDAP модификации пароля Password Modify", RFC 3062, февраль 2001 г.
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, апрель 1995 г.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) Internet Society (2001). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.