Network Working Group Request for Comments: 3062 Категория: Standards Track K. Zeilenga, OpenLDAP Foundation Февраль 2001 года
В этом документе определяется предложенный стандарт протокола Internet для сообщества Internet, а также принимаются обсуждения и предложения по его улучшению. Пожалуйста, отслеживайте текущую редакцию "Internet Official Protocol Standards" (STD 1) на предмет состояния стандартизации и статуса данного протокола. Ограничений на распространение этого документа не накладывается.
Copyright (C) Internet Society (2001). Все права защищены.
В результате интеграции протокола Lightweight Directory Access Protocol (LDAP) и внешних сервисов аутентификации были введены в обращение аутентификационные идентификационные сущности, не являющиеся DN, а также разрешено хранение паролей вне каталога. В этих случаях механизмы обновления каталога (такие как Modify) не могут быть использованы для изменения пароля пользователя. В этом документе описывается расширенная операция LDAP, позволяющая модифицировать пароли пользователя вне зависимости от формы аутентификационной идентификационной сущности и используемого механизма хранения паролей.
В этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется) и "MAY" (возможно) интерпретируются так, как описано в RFC 2119.
Протокол Lightweight Directory Access Protocol (LDAP) [RFC2251] поддерживает несколько механизмов аутентификации, в том числе аутентификацию по простым парам имя пользователя/пароль. Традиционно пользователи LDAP идентифицировались по DN [RFC2253] записи каталога, и эта запись содержала атрибут userPassword [RFC2256], в котором хранились один или несколько паролей.
Протокол не устанавливает жёсткого требования, чтобы ассоциированные с пользователем пароли хранились в каталоге. Сервер может использовать любой подходящий атрибут для хранения пароля (например, userPassword), либо использовать отдельное от каталога хранилище.
В результате интеграции протокола [RFC2829] с независимыми от приложения сервисами SASL [RFC2222], поддерживающими простые механизмы аутентификации по имени пользователя/паролю (такие как DIGEST-MD5), были введены в употребление отличные от LDAP DN формы аутентификационных идентификационных сущностей и хранение паролей возложено на поставщика услуг SASL.
Операции обновления LDAP разработаны так, чтобы выполнять действия над атрибутами записи в каталоге. Операции обновления LDAP не могут быть использованы для модификации пароля пользователя, когда пользователь не представлен DN, не имеет записи, или когда используемый сервером пароль не хранится в качестве атрибута записи. Требовался альтернативный механизм.
В этом документе описывается расширенная операция LDAP, предназначение которой — позволить клиентам каталога обновлять свои пароли. Пользователь может быть, а может и не быть ассоциирован с записью каталога. Пользователь может быть, а может и не быть представлен в качестве LDAP DN. Пароль пользователя может храниться, а может и не храниться в каталоге.
Данную операцию не следует (SHOULD NOT) использовать без адекватного обеспечения безопасности, поскольку сама по себе она не обеспечивает никакой защиты конфиденциальности и целостности. Эту оперцию не следует (SHALL NOT) использовать анонимно.
Операция модификации пароля Password Modify — это расширенная операция LDAPv3 [раздел 4.12 RFC2251], она идентифицируется идентификатором объекта (OBJECT IDENTIFIER) passwdModifyOID. В этом разделе описывается синтаксис запроса и ответа протокола.
passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1
PasswdModifyRequestValue ::= SEQUENCE {
userIdentity [0] OCTET STRING OPTIONAL
oldPasswd [1] OCTET STRING OPTIONAL
newPasswd [2] OCTET STRING OPTIONAL }
PasswdModifyResponseValue ::= SEQUENCE {
genPasswd [0] OCTET STRING OPTIONAL }
Запрос Password Modify является расширенным запросом ExtendedRequest, поле requestName которого содержит OID passwdModifyOID; кроме того, в нём может опционально предоставляться поле requestValue. Если поле requestValue предоставляется, в нём должно (SHALL) содержаться значение PasswdModifyRequestValue, в котором присутствует одно или несколько полей.
Поле userIdentity, если оно присутствует, должно (SHALL) содержать строку октетов, представляющую собой пользователя, ассоциированного с запросом. Данная строка может быть, а может и не быть LDAPDN [RFC2253]. Если поле userIdentity не присутствует, запрос выполняется над паролем пользователя, который в текущий момент ассоциирован с сессией LDAP.
Поле oldPasswd, если оно присутствует, должно (SHALL) содержать текущий пароль пользователя.
Поле newPasswd, если оно присутствует, должно (SHALL) содержать пароль, который требуется установить этому пользователю.
Ответ Password Modify является расширенным ответом ExtendedResponse, в котором поле responseName отсутствует, а поле response является опциональным. Поле response, если оно присутствует, должно (SHALL) содержать значение PasswdModifyResponseValue, в котором присутствует поле genPasswd.
Поле genPasswd, если оно присутствует, должно (SHALL) содержать сгенерированный для пользователя пароль.
Если в ответе указан результирующий код resultCode, отличный от success (0), то поле response должно (MUST) отсутствовать.
Клиентам не следует (SHOULD NOT) подавать запрос изменения пароля Password Modify, пока они не убедятся в соблюдении надлежащих мер обеспечения безопасности. Серверам следует (SHOULD) возвращать неуспешный результирующий код resultCode, если безопасность данных не обеспечена должным образом.
Серверам следует (SHOULD) указывать, что они поддерживают выполнение данной расширенной операции, путём предоставления PasswdModifyOID в качестве значения типа атрибута supportedExtension в записи root DSE сервера. Сервер может (MAY) избрать вариант поведения, при котором данное расширение афишируется только когда клиент авторизован и/или установил меры защиты данных, необходимые для использования этой операции. Перед тем как пытаться выполнить эту расширенную операцию, клиентам следует (SHOULD) удостовериться, что сервер её реализует, путём проверки утверждения, что атрибут supportedExtension содержит значение PasswdModifyOID.
Сервер должен (SHALL) возвращать код success только при успешном изменении пароля пользователя. В противном случае сервер должен (SHALL) оставлять пароль неизменённым и возвращать неуспешный результирующий код resultCode.
Если сервер не распознаёт предоставленные поля или не поддерживает комбинацию предоставленных полей, он не должен (SHALL NOT) изменять пароль пользователя.
Если присутствует поле oldPasswd и предоставленное значение не может быть проверено или является неверным, сервер не должен (SHALL NOT) изменять пароль пользователя. Если поле oldPasswd не присутствует, сервер может (MAY) использовать другую политику, чтобы определить, следует ли ему изменять пароль.
Серверу не нужно (SHALL NOT) генерировать пароль от имени клиента, если клиент предоставил значение в поле newPasswd. Если клиент не предоставил поле newPasswd, серверу нужно (SHALL) либо сгенерировать пароль от имени клиента, либо вернуть неуспешный результирующий код. В случае успешного изменения пароля сервер должен (MUST) предоставить сгенерированный пароль в качестве значения поля genPasswd.
Сервер может (MAY) возвращать adminLimitExceeded, busy, confidentialityRequired, operationsError, unavailable, unwillingToPerform или другой неуспешный результирующий код resultCode в зависимости от ситуации, чтобы показать, что он не может успешно выполнить данную операцию.
Серверы могут (MAY) реализовывать административные политики, ограничивающие данную операцию.
Эта операция используется для изменения паролей пользователей. Сама по себе данная операция не обеспечивает какой-либо защиты целостности и/или конфиденциальности данных. Настоятельно не рекомендуется использовать данную операцию, если не были соблюдены должные меры защиты, гарантирующие конфиденциальность, в противном случае возможно раскрытие пароля неавторизованными третьими лицами. Это расширение необходимо (MUST) использовать, когда защита конфиденциальности обеспечена, например, с помощью операции Start TLS [RFC 2830]. Недопустимо (MUST NOT) использовать наборы NULL-шифров.
[RFC2219] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, октябрь 1997.
[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997.
[RFC2253] Wahl, M., Kille,S. и T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, декабрь 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, декабрь 1997.
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. и R. Morgan, "Authentication Methods for LDAP", RFC 2829, май 2000.
[RFC2830] Hodges, J., Morgan, R. и M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security", RFC 2830, май 2000.
Этот документ основывается на различных документах IETF, а также на материалах рабочей группы IETF LDAPext.
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.