Network Working Group Request for Comments: 4513 Категория: Standards Track Под редакцией R. Harrison, Novell, Inc. Июнь 2006 года Отменяет: RFC 2251, RFC 2829, RFC 2830
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
В этом документе описываются методы аутентификации и механизмы обеспечения безопасности для протокола Lightweight Directory Access Protocol (LDAP). Здесь же детализируется установление соединения Transport Layer Security (TLS) с использованием операции StartTLS.
В этом документе даётся подробное описание метода аутентификации простого подсоединения (Simple Bind), в том числе механизмы анонимного подсоединения, неаутентифицированного подсоединения и подсоединения с предоставлением имени пользователя и пароля, а также метода аутентификации подсоединения с использованием Simple Authentication and Security Layer (SASL), в том числе механизм EXTERNAL.
В этом документе обсуждаются различные состояния аутентификации и авторизации, через которые может пройти сеанс работы с LDAP-сервером, а также действия, которые вызывают изменение этих состояний.
Этот документ, совместно с другими документами технической спецификации LDAP (смотрите раздел 1 и путеводитель по технической спецификации), отменяет RFC 2251, RFC 2829 и RFC 2830.
- 3.1.1. Последовательность выполнения операций при запросе StartTLS
- 3.1.2. Сертификат клиента
- 3.1.3. Проверка идентификационной сущности сервера
- 3.1.3.1. Сравнение имён DNS
- 3.1.3.2. Сравнение IP-адресов
- 3.1.3.3. Сравнение других типов subjectName
- 3.1.4. Оценка полученного в результате уровня обеспечения безопасности
- 3.1.5. Обновление информации о возможностях сервера
- 5.1.1. Простое подсоединение: механизм анонимной аутентификации
- 5.1.2. Простое подсоединение: механизм аутентификации без проверки подлинности
- 5.1.3. Простое подсоединение: механизм аутентификации по имени пользователя и паролю
- 5.2.1. SASL-профиль протокола
- 5.2.1.1. Имя сервиса SASL для LDAP
- 5.2.1.2. Инициация аутентификации и обмен сообщениями протокола SASL
- 5.2.1.3. Опциональные поля
- 5.2.1.4. Октет, с которого вступают в силу уровни безопасности
- 5.2.1.5. Определение поддерживаемых механизмов SASL
- 5.2.1.6. Правила использования уровней SASL
- 5.2.1.7. Поддержка множественной аутентификации
- 5.2.1.8. Авторизационные идентификационные сущности SASL
- 5.2.2. Семантики SASL в LDAP
- 5.2.3. Механизм аутентификации SASL EXTERNAL
- 5.2.3.1. Неявное заявление
- 5.2.3.2. Явное заявление
- 6.3.1. Соображения безопасности, касающиеся механизма аутентификации без проверки подлинности
- 6.3.2. Соображения безопасности, касающиеся механизма аутентификации по имени пользователя и паролю
- 6.3.3. Соображения безопасности, связанные с паролями
- 6.3.4. Соображения безопасности по хэшированным паролям
- B.1.1. Раздел 4.2.1 (Последовательность запросов Bind)
- B.1.2. Раздел 4.2.2 (Аутентификация и другие сервисы обеспечения безопасности)
- B.2.1. Раздел 4 (Требуемые механизмы обеспечения безопасности)
- B.2.2. Раздел 5.1 (Процедура анонимной аутентификации)
- B.2.3. Раздел 6 (Аутентификация на основе пароля)
- B.2.4. Раздел 6.1 (Аутентификация Digest)
- B.2.5. Раздел 6.2 (Способ аутентификации 'simple' при шифровании TLS)
- B.2.6. Раздел 6.3 (Другие способы аутентификации с TLS)
- B.2.7. Раздел 7.1 (Аутентификация, основанная на использовании сертификата, с TLS)
- B.2.8. Раздел 8 (Другие механизмы)
- B.2.9. Раздел 9 (Авторизационная идентификационная сущность)
- B.2.10. Раздел 10 (Наборы шифров TLS)
- B.3.1. Раздел 3.6 (Проверка идентификационной сущности сервера)
- B.3.2. Раздел 3.7 (Обновление информации о возможностях сервера)
- B.3.3. Раздел 5 (Влияние TLS на авторизационную идентификационную сущность клиента)
- B.3.4. Раздел 5.2 (Последствия закрытия соединения TLS)
Lightweight Directory Access Protocol (LDAP) [RFC4510] — мощный протокол для доступа к каталогам. Он предлагает средства поиска и извлечения информации из каталога, манипулирования содержимым каталога, а также различные способы предоставления доступа к каталогу с богатым набором функций обеспечения безопасности.
Жизненно важно, чтобы эти функции обеспечения безопасности позволяли выполнять взаимодействие между всеми клиентами и серверами LDAP в сети Интернет; поэтому должно быть определено минимальное подмножество функции обеспечения безопасности, которое было бы общим для всех реализаций, утверждающих своё соответствие спецификации LDAP.
Основные угрозы для службы каталогов LDAP (неисчерпывающий список):
Угрозы (1), (4), (5), (6), (7) и (8) представляют собой активные атаки. Угрозы (2) и (3) — пассивные.
Угрозы (1), (4), (5) и (6) связаны с работой злоумышленников-клиентов. Угрозы (2), (3), (7) и (8) связаны с работой злоумышленников-агентов на пути между клиентом и сервером, либо злоумышленников-агентов, выдающих себя за сервер, например, с помощью IP-спуфинга.
LDAP предлагает следующие механизмы обеспечения безопасности:
Опыт показывает, что если просто позволять внедрять в реализациях протокола механизмы обеспечения безопасности по своему выбору, то такая стратегия не приводит к совместимости приложений. В отсутствии обязательных требований клиенты будут продолжать выдавать сообщения, что они не поддерживают какие-либо функции обеспечения безопасности, поддерживаемые сервером, или, и того хуже, они будут поддерживать только те механизмы, которые обеспечивают недостаточный уровень безопасности в большинстве ситуаций.
Желательно позволить клиентам проводить аутентификацию с использованием различных механизмов, в том числе механизмов, где идентификационные сущности представлены как уникальные имена [X.501][RFC4512], в строковой форме [RFC4514] или так, как они используются в различных системах (например, простые имена пользователей [RFC4013]). Поскольку некоторые механизмы аутентификации передают идентификационные данные в форме открытого текста, и/или не предоставляют сервисов обеспечения безопасности данных, и/или являются предметом пассивных атак, необходимо обеспечить совместимость приложений с точки зрения защиты данных путем определения обязательного для реализации механизма установления сервисов безопасности транспортного уровня.
Предоставляемый в LDAP и описываемый в этом документе набор механизмов обеспечения безопасности предназначен для того, чтобы удовлетворить потребности безопасности широкого спектра сценариев развертывания и при этом обеспечить высокую степень совместимости между различными реализациями и системами LDAP.
Этот документ является неотъемлемой частью технической спецификации LDAP [RFC4510].
Этот документ, совместно с [RFC4510], [RFC4511] и [RFC4512], полностью отменяет RFC 2251. Этот документ отменяет разделы 4.2.1 (частично) и 4.2.2 RFC 2251. Основные изменения, внесённые в RFC 2251 этим документом, обобщены в приложении B.1.
Этот документ полностью отменяет RFC 2829. Основные изменения, внесённые в RFC 2829 этим документом, обобщены в приложении B.2.
Разделы 2 and 4 RFC 2830 отменены [RFC4511]. Оставшаяся часть RFC 2830 отменяется этим документом. Основные изменения, внесённые в RFC 2830 этим документом, обобщены в приложении B.3.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "SHALL" (нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в [RFC2119].
Термин "пользователь" ("user") означает любого человека или приложение, получающее доступ к каталогу с помощью клиента каталога. Клиент каталога (или просто клиент) ещё называется пользовательским агентом каталога (Directory user agent, DUA).
Термин "транспортное соединение" ("transport connection") обозначает базовые транспортные сервисы, используемые для проведения обмена сообщениями протокола, а также соединения, установленные этими сервисами.
Термин "уровень TLS" ("TLS layer") обозначает сервисы TLS, используемые для обеспечения безопасности при передаче информации, а также соединения, установленные этими сервисами.
Термин "уровень SASL" ("SASL layer") обозначает сервисы SASL, используемые для обеспечения безопасности при передаче информации, а также соединения, установленные этими сервисами.
Термин "уровень сообщений LDAP" ("LDAP message layer") обозначает сервисы LDAP Message PDU, используемые для предоставления услуг служб каталогов, а также соединения, установленные этими сервисами.
Термин "сессия LDAP" ("LDAP session") обозначает комбинированные сервисы (транспортное соединение, уровень TLS, уровень SASL, уровень сообщений LDAP) и их соединения.
В общем случае, термины безопасности в этом документе используются так, как они определены в [RFC2828]. Кроме того, некоторые термины и концепции, относящиеся к защите информации, аутентификации и авторизации, приведены в приложении A этого документа. Хотя формальные определения этих терминов и концепций выходят за рамки настоящего документа, понимание их является необходимым условием для понимания большей части материала в этом документе. Читателям, которые не знакомы с концепциями защиты информации, рекомендуется перед тем, как читать этот документ далее, ознакомиться с приложением A.
Реализации сервера LDAP должны (MUST) поддерживать механизм анонимной аутентификации метода простого подсоединения (раздел 5.1.1).
Реализации LDAP, поддерживающие любые другие механизмы аутентификации, кроме механизма анонимной аутентификации метода простого подсоединения, должны (MUST) поддерживать механизм аутентификации по имени пользователя и паролю метода простого подсоединения (раздел 5.1.3) и должны (MUST) быть способными защищать данную аутентификацию по имени пользователя и паролю с помощью TLS, устанавливаемого операцией StartTLS (раздел 3).
Реализациям следует (SHOULD) по умолчанию запрещать использование механизма аутентификации по имени пользователя и паролю, если надлежащий уровень защиты данных не был обеспечен соответствующими сервисами обеспечения безопасности; кроме того, реализации могут (MAY) предоставлять другие подходящие сервисы обеспечения безопасности данных для использования с этим механизмом аутентификации.
Реализации могут (MAY) поддерживать дополнительные механизмы аутентификации. Некоторые из этих механизмов обсуждаются ниже.
Реализациям сервера LDAP следует (SHOULD) поддерживать связывание сессии с авторизационной идентификационной сущностью, заявленной клиентом посредством механизма SASL EXTERNAL (раздел 5.2.3).
Реализациям сервера LDAP, не поддерживающим никаких механизмов аутентификации, кроме механизма анонимной аутентификации метода простого подсоединения, следует (SHOULD) поддерживать использование TLS, устанавливаемого операцией StartTLS (раздел 3). (Другие серверы должны (MUST) поддерживать TLS так, как это описано во втором параграфе этого раздела.)
Реализациям, поддерживающим TLS, необходимо (MUST) поддерживать набор шифров TLS_RSA_WITH_3DES_EDE_CBC_SHA и следует (SHOULD) поддерживать набор шифров TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. Поддержка последнего набора шифров рекомендуется для обеспечения совместимости с реализациями, работающими согласно более ранним спецификациям операции LDAP StartTLS.
Операция Start Transport Layer Security (StartTLS), определённая в разделе 4.14 [RFC4511], обеспечивает возможность установления TLS [RFC4346] в сессии LDAP.
Целью использования протокола TLS с LDAP является обеспечение конфиденциальности и целостности данных, а также, опционально, предоставление данных для аутентификации. Эти возможности явно предусмотрены в TLS, хотя сервисы аутентификации TLS доступны для LDAP только в комбинации с методом аутентификации SASL EXTERNAL (смотрите раздел 5.2.3), и то лишь в том случае, когда реализация SASL EXTERNAL примет решение использовать удостоверяющие данные TLS.
В этом разделе описываются общие процедуры, которым должны следовать клиенты и серверы для установления TLS. В этих процедурах учитываются различные аспекты уровня TLS, в том числе выявление результативного уровня обеспечения безопасности и утверждение авторизационной идентификационной сущности клиента.
Клиент может отправить расширенный запрос StartTLS в любой момент после установления сессии LDAP, за исключением случаев, когда:
Как сказано в разделе 4.14.1 RFC4511, нарушение (выявленное) любого из этих требований приводит к возврату результирующего кода operationsError.
Разработчики клиентов должны обеспечить, чтобы клиент строго придерживался этих требований последовательности выполнения операций для предотвращения проблем взаимодействия с серверами. Опыт работы показывает, что нарушение этих требований вызывает проблемы взаимодействия, поскольку существуют особого рода условия, не позволяющие серверу определить некоторые нарушения этих требований вследствие таких факторов, как недостаточная производительность серверного оборудования и низкая скорость сетевых соединений.
Не существует общего требования, должен или нет клиент выполнить операцию Bind (раздел 5) перед тем, как посылать запрос операции StartTLS; однако, если клиент планирует выполнить обе операции Bind и StartTLS, ему следует (SHOULD) сначала выполнить операцию StartTLS для того, чтобы сообщения запроса и ответа Bind были защищены сервисами обеспечения безопасности данных, установленными операцией StartTLS.
Если сервер LDAP запрашивает, чтобы клиент в ходе переговоров TLS предоставил сертификат пользователя, а у клиента нет в наличии подходящего сертификата пользователя (например, такого, подлинность которого можно было бы подтвердить), сервер может использовать локальную политику безопасности для определения того, будет ли окончание переговоров TLS считаться успешным.
Если клиент предоставил подходящий сертификат и вслед за этим выполняет операцию Bind с использованием механизма аутентификации SASL EXTERNAL (раздел 5.2.3), информация из этого сертификата может быть использована сервером для идентификации и аутентификации клиента.
Для предотвращения атак типа "человек посередине" (man-in-the-middle), клиент должен (MUST) проверять идентификационную сущность сервера (как она представлена в сообщении сертификата сервера). В данном разделе то, что клиент понимает под идентификационной сущностью сервера (обычно идентификационная сущность, используемая при установке транспортного соединения), называется "заявляемой идентификационной сущностью" ("reference identity").
Клиент определяет тип заявляемой идентификационной сущности (например, DNS-имя или IP-адрес) и выполняет её сравнение с каждым значением поля subjectAltName соответствующего типа, пока не получит совпадения. Как только совпадение получено, идентификационная сущность сервера считается проверенной, а проверка идентификационной сущности сервера — выполненной. Различные типы поля subjectAltName сравниваются по-разному. В разделах 3.1.3.1-3.1.3.3 поясняется, каким образом сравнивать значения различных типов subjectAltName.
Клиент может отобразить заявляемую идентификационную сущность в другой тип до выполнения сравнения. Отображения могут быть выполнены для всех доступных типов subjectAltName, в которые может быть отображена заявляемая идентификационная сущность; однако, она должна отображаться только в типы, для которых такое отображение либо безопасно по своей сути (например, выделение DNS-имени из URI для сравнения с полем subjectAltName типа dNSName), либо выполняется безопасным способом (например, использование DNSSEC или сконфигурированных пользователем или администратором поисковых таблиц соответствия хоста адресу или адреса хосту).
Идентификационная сущность сервера может также быть проверена путём сравнения заявляемой идентификационной сущности с значением Common Name (CN) [RFC4519] листового относительного отличительного имени (RDN) поля subjectName сертификата сервера. Это сравнение выполняется с использованием правил сравнения имён DNS, описанных ниже в разделе 3.1.3.1, за исключением того, что не разрешён поиск совпадений по шаблонам. Хотя использование значений Common Name является устоявшейся практикой, этот подход устарел, и удостоверяющим центрам (Certification Authorities) рекомендовано вместо этого предоставлять значения в поле subjectAltName. Имейте ввиду, что реализации TLS могут представлять уникальные имена (DN) в сертификатах в соответствии со стандартом X.500 или другими соглашениями. Например, некоторые реализации X.500 располагают RDN и DN в порядке слева-направо (от наиболее значимого до наименее значимого) вместо принятого в LDAP порядка справа-налево.
Если проверка идентификационной сущности сервера завершается неудачей, клиентам, ориентированным на пользователя, следует (SHOULD) либо уведомить пользователя (в этом случае клиенты могут предоставить пользователю возможность продолжить работу с этой сессией LDAP), либо закрыть транспортное соединение и указать, что подлинность сервера вызывает подозрения. Клиентам, работающим без непосредственного участия пользователя, следует (SHOULD) закрыть транспортное соединение, после чего вернуть или поместить в журнал (или и то и другое вместе) ошибку, указывающую на то, что подлинность сервера вызывает подозрения.
Помимо описанной в этом разделе проверки идентификационной сущности сервера, клиентам следует быть готовыми произвести дальнейшие проверки чтобы убедиться, что сервер имеет право (авторизован) предоставлять те сервисы, которые у него запрашиваются. При принятии решения о таких проверках клиенту может потребоваться использовать информацию локальной политики безопасности.
Если заявляемая идентификационная сущность представляет собой интернационализованное доменное имя (IDN), реализации, соответствующие требованиям этого документа, должны (MUST) преобразовать его в формат ASCII Compatible Encoding (ACE) как определено в разделе 4 RFC 3490 перед тем, как выполнять сравнение со значениями поля subjectAltName типа dNSName. Конкретнее, реализации, соответствующие требованиям этого документа, должны (MUST) выполнять определённую в разделе 4 RFC3490 операцию преобразования следующим образом:
После выполнения преобразования "to-ASCII", должно (MUST) быть выполнено сравнение меток и имён DNS на эквивалентность согласно правилам, определённым в разделе 3 RFC3490.
Знак шаблона '*' (ASCII 42) разрешён в значениях поля subjectAltName типа dNSName, но только в качестве крайней слева (наименее значимой) метки DNS в таком значении. Этот шаблон совпадает с любой крайней слева меткой DNS в имени сервера. То есть, субъект *.example.com совпадает с именами сервера a.example.com и b.example.com, но не совпадает с example.com или a.b.example.com.
Когда заявляемая идентификационная сущность представляет собой IP-адрес, она должна (MUST) быть преобразована в бинарное строковое представление "сетевой порядок байтов" ("network byte order") [RFC791][RFC2460]. Для IPv4, как определено в RFC791, строка байт должна содержать ровно 4 октета. Для IPv6, как определено в RFC2460, строка байт должна содержать ровно 16 октетов. Затем данная строка октетов сравнивается со значениями поля subjectAltName типа iPAddress. Совпадение имеет место, если строка октетов заявляемой идентификационной сущности и строка октетов значения идентичны.
Реализации клиента могут (MAY) поддерживать проверку совпадений со значениями поля subjectAltName других типов так, как это описывается в других документах.
После того как уровень TLS установлен в сессии LDAP, каждая из сторон должна самостоятельно решить — стоит или нет продолжать его использовать, основываясь на локальной политике и достигнутом уровне обеспечения безопасности. Если какая-либо из сторон решает, что уровень обеспечения безопасности недостаточен для того, чтобы она могла продолжить использование установленного соединения, ей следует (SHOULD) снять уровень TLS сразу после завершения переговоров (повторных переговоров) TLS (смотрите раздел 4.14.3 RFC4511 и раздел 3.2 ниже). Реализации могут произвести повторную оценку уровня обеспечения безопасности в любой момент и, если выяснится, что он недостаточен, им следует снять уровень TLS.
После того как уровень TLS установлен в сессии LDAP, клиенту следует (SHOULD) отбросить или обновить всю информацию о сервере, полученную до инициации переговоров TLS, а также ту, которая была получена без использования механизмов обеспечения безопасности. Это защищает от атак типа "человек посередине", при которых может быть подменена любая полученная до установления уровня TLS информация о возможностях сервера.
После установления уровня TLS сервер может опубликовать возможности, отличные от тех, что были опубликованы до этого. В частности, могут измениться значения атрибута 'supportedSASLMechanisms' (например, желательно, чтобы механизмы EXTERNAL и PLAIN [PLAIN] были перечислены только после установления уровня TLS).
Установление, изменение, и/или закрытие TLS может привести к тому, что состояние авторизации изменится на новое. Это обсуждается далее в разделе 4.
При выборе наборов шифров TLS, пригодных для использования в заданных условиях, должен приниматься во внимание ряд факторов, в том числе:
У каждой сессии LDAP есть ассоциированное с ней состояние авторизации. Это состояние зависит от многих факторов, в том числе какое состояние аутентификации было установлено (и было ли установлено какое-либо), каким образом оно было установлено, и какие сервисы обеспечения безопасности активны. Некоторые факторы могут быть определены и/или обусловлены событиями протокола (например, операциями Bind, StartTLS или закрытием TLS), а некоторые могут определяться внешними событиями (например, временем дня или нагрузкой на сервер).
Хотя зачастую удобно рассматривать состояние авторизации в упрощённых понятиях, таких как "анонимное состояние" (мы сами часто так поступаем в данной технической спецификации), следует иметь ввиду, что системы авторизации в реализациях LDAP обычно вовлекают в рассмотрение множество факторов, комплексно взаимодействующих друг с другом.
Авторизация в LDAP — это задача, решаемая локально. Одним из ключевых факторов при принятии решения по авторизации является авторизационная идентификационная сущность. Операция подсоединения Bind (определённая в разделе 4.2 RFC4511 и обсуждаемая далее в разделе 5 этого документа) позволяет обмениваться информацией между клиентом и сервером в целях установления авторизационной идентификационной сущности для сессии LDAP. Операция Bind может также использоваться для перехода сессии LDAP в анонимное состояние авторизации (смотрите раздел 5.1.1).
При первоначальном установлении сессии LDAP эта сессия имеет анонимную авторизационную идентификационную сущность. Среди прочего это означает, что от клиента не требуется посылать запрос BindRequest в первом PDU уровня сообщений LDAP. Клиент может посылать запросы любых операций до выполнения операции Bind, а сервер должен (MUST) интерпретировать их так, как если бы они были выполнены после анонимной операции Bind (раздел 5.1.1).
После получения запроса Bind сервер немедленно переводит текущую сессию в анонимное состояние авторизации. Если запрос Bind выполнен успешно, сессия переходит в запрашиваемое состояние аутентификации и в связанное с ним состояние авторизации. В противном случае сессия остается в анонимном состоянии.
Имейте ввиду, что и другие события, как внутренние так и внешние по отношению к LDAP, могут приводить к тому, что состояния аутентификации и авторизации изменятся на анонимные. Например, установление, изменение или закрытие сервисов обеспечения безопасности данных может привести к переходу в анонимное состояние, либо может истечь срок действия удостоверяющих данных пользователя (например, сертификата). В первом случае мы получаем внутреннее по отношению LDAP событие, во втором — внешнее.
Операция Bind (раздел 4.2 RFC4511) позволяет обмениваться аутентификационной информацией между клиентом и сервером для установления нового состояния авторизации.
В запросе Bind обычно указывается требуемая аутентификационная идентификационная сущность. Некоторые механизмы Bind также позволяют клиенту указать авторизационную идентификационную сущность. Если авторизационная идентификационная сущность не указана, сервер получает её из аутентификационной идентификационной сущности специфичным для реализации образом.
Если авторизационная идентификационная сущность указана, сервер должен (MUST) проверить, что аутентификационной идентификационной сущности клиента разрешено принимать на себя заявленную авторизационную идентификационную сущность (например, выступать для неё в качестве прокси). Если у клиента нет таких полномочий, сервер должен (MUST) отклонить операцию Bind с результирующим кодом invalidCredentials в ответе Bind.
Метод простой аутентификации операции Bind предоставляет три механизма аутентификации:
LDAP-клиент может использовать механизм анонимной аутентификации метода простого подсоединения для того, чтобы явно установить анонимное состояние авторизации. Для этого он отправляет запрос Bind, поле name которого имеет значение нулевой длины, а в поле authentication указан механизм simple и значение пароля нулевой длины.
LDAP-клиент может использовать механизм аутентификации без проверки подлинности метода простого подсоединения, чтобы установить анонимное состояние авторизации. Для этого он отправляет запрос Bind, поле name которого имеет значение ненулевой длины (уникальное имя в строковой форме LDAP [RFC4514]), а в поле authentication указан механизм simple и значение пароля нулевой длины.
Предоставленное клиентом значение уникального имени предназначено для использования только в целях трассировки (например, журналирования). Это значение не должно быть подвержено проверке подлинности или какой-либо другой проверке (в том числе и на то, что DN указывает на существующий объект каталога). Это значение не должно использоваться (прямо или косвенно) в целях авторизации.
Операции Bind без проверки подлинности могут иметь значительные проблемы безопасности (смотрите раздел 6.3.1). В частности, пользователи, намеревающиеся выполнить аутентификацию по имени пользователя и паролю, могут непреднамеренно предоставить пустой пароль, и это может привести к тому, что плохо реализованные клиенты выполнят запрос доступа без проверки подлинности. Клиенты должны (SHOULD) быть реализованы так, чтобы от пользователя требовалось явно указывать выбор механизма аутентификации без проверки подлинности отличными от ввода пустого пароля средствами. Клиентам следует (SHOULD) запретить ввод пустого пароля в пользовательском интерфейсе аутентификации по имени пользователя и паролю. Кроме того, серверам следует (SHOULD) по умолчанию возвращать неудачное завершение с результирующим кодом unwillingToPerform в ответ на запросы подсоединения без проверки подлинности.
LDAP-клиент может использовать механизм аутентификации по имени пользователя и паролю метода простого подсоединения, чтобы установить аутентифицированное состояние авторизации. Для этого он отправляет запрос Bind, поле name которого имеет значение ненулевой длины (уникальное имя в строковой форме LDAP [RFC4514]), а в поле authentication указан механизм simple и значение пароля в форме OCTET STRING ненулевой длины.
Серверы, отображающие посылаемое в запросе Bind DN в запись каталога с ассоциированным набором из одного или нескольких паролей, используемых с этим механизмом, сравнивают предоставленный пароль с этим набором паролей. Представленный пароль считается верным, если он соответствует любому из этого набора.
Результирующий код invalidDNSyntax говорит о том, что DN, посылаемый как значение поля name, синтаксически неверен. Результирующий код invalidCredentials говорит о том, что данное DN синтаксически корректно, но не действительно для аутентификации, либо пароль неверен для данного DN, либо сервер по каким-то иным соображениям считает удостоверяющие данные недействительными. Результирующий код success говорит о том, что удостоверяющие данные верны и что сервер готов предоставить сервис субъекту, идентифицируемому этими удостоверяющими данными.
Для запросов Bind с механизмом аутентификации по имени пользователя и паролю, в которых указано значение имени нулевой длины и значение пароля ненулевой длины, поведение сервера не определено.
Механизм аутентификации по имени пользователя и паролю метода простого подсоединения не подходит для аутентификации в окружениях без обеспечения защиты конфиденциальности данных.
Метод аутентификации sasl операции Bind предоставляет средства для использования любого механизма SASL, в том числе механизмов аутентификации и других сервисов (например, сервисов защиты информации).
LDAP позволяет проводить аутентификацию посредством любого механизма SASL [RFC4422]. Поскольку в LDAP есть собственные методы анонимной аутентификации и аутентификации по имени пользователя и паролю (в открытом виде), механизмы SASL ANONYMOUS [RFC4505] и PLAIN [PLAIN] обычно с LDAP не используются.
От каждого протокола, использующего сервисы SASL, требуется предоставлять определённую информацию, в совокупности представляющую собой профиль того, как эти сервисы вписываются в работу протокола (раздел 4 RFC4422). В этом разделе объясняется, как эти требования профилирования удовлетворяются в LDAP.
Зарегистрированным IANA именем сервиса SASL для LDAP является "ldap".
Инициация аутентификации SASL происходит посредством сообщения BindRequest (раздел 4.2 RFC4511) со следующими параметрами:
В общем случае, обмен сообщениями протокола аутентификации SASL состоит из серии вызовов сервера и откликов клиента, содержимое которых специфично для механизма SASL и определяется им. Так, для некоторых механизмов аутентификации SASL, от клиента может потребоваться посылать отклик на один или несколько вызовов сервера путём отправки сообщений BindRequest несколько раз. Вызов обозначается отправкой сервером сообщения BindResponse с результирующим кодом saslBindInProgress. Это означает, что для продолжения процесса аутентификации сервер требует от клиента отправки нового сообщения BindRequest с тем же механизмом SASL.
С точки зрения уровня сообщений LDAP эти вызовы и отклики представляют собой неразбираемые бинарные токены произвольной длины. Серверы LDAP используют поле serverSaslCreds (OCTET STRING) в сообщении BindResponse для транспортировки каждого из вызовов. Клиенты LDAP используют поле credentials (OCTET STRING) в последовательности SaslCredentials сообщения BindRequest для транспортировки каждого из откликов. Имейте ввиду, что в отличие от некоторых протоколов Интернет, в которых используется SASL, LDAP не является текстовым и не выполняет Base64-трансформации значений этих вызовов и откликов.
Клиентам, посылающим сообщение BindRequest с выбранным пунктом sasl, следует (SHOULD) отправлять значение нулевой длины в поле name. Серверам, получающим сообщение BindRequest с выбранным пунктом sasl, нужно (SHALL) игнорировать любое значение в поле name.
Клиент может прервать переговоры Bind SASL путём отправки сообщения BindRequest с другим значением в поле mechanism последовательности SaslCredentials, либо отличным от sasl пунктом в конструкции AuthenticationChoice.
Если клиент посылает сообщение BindRequest с выбранным пунктом sasl и пустой строкой в поле mechanism, сервер должен (MUST) вернуть сообщение BindResponse с результирующим кодом authMethodNotSupported. Это позволяет клиенту прервать переговоры, если он желает вновь попробовать пройти аутентификацию с тем же механизмом SASL.
Сервер указывает на завершение обмена вызовами-откликами SASL путём посылки ответа BindResponse, в котором значение результирующего кода отлично от saslBindInProgress.
В этом сообщении BindResponse поле serverSaslCreds может быть использовано для включения опционального вызова с уведомлением об успешном завершении для тех механизмов, в определении которых сказано, что сервер посылает дополнительные данные вместе с указанием успешного завершения.
Как уже было сказано, LDAP предоставляет опциональное поле для передачи первоначального отклика в сообщении, инициирующем обмен SASL, а также опциональное поле для передачи дополнительной информации в сообщении, указывающем на завершение аутентификационного обмена. Специфичное для механизма содержимое в этих полях может быть нулевой длины. SASL требует, чтобы в протоколе были спецификации, раскрывающие, каким образом поле нулевой длины отличить от отсутствия этого поля.
Данные первоначального отклика нулевой длины отличаются от отсутствия данных первоначального отклика в инициирующем сообщении (BindRequest PDU) наличием в этом PDU строки октетов (OCTET STRING) SaslCredentials.credentials нулевой длины. Если клиент не собирается отправлять первоначальный отклик в сообщении BindRequest, инициирующем обмен SASL, он должен (MUST) опустить строку октетов SaslCredentials.credentials (вместо того, чтобы включать строку октетов нулевой длины).
Дополнительные данные нулевой длины отличаются от отсутствия дополнительных ответных данных в итоговом сообщении (BindResponse PDU) наличием в этом PDU строки октетов (OCTET STRING) serverSaslCreds нулевой длины. Если сервер не собирается отправлять дополнительные данные в сообщении BindResponse, указывающем на окончание аутентификационного обмена, он должен (SHALL) опустить строку октетов serverSaslCreds (вместо того, чтобы включать строку октетов нулевой длины).
Уровень SASL вступает в силу вслед за передачей сервером и приёмом клиентом финального в обмене SASL сообщения BindResponse с результирующим кодом success.
После того, как уровень SASL, предоставляющий сервисы обеспечения целостности или конфиденциальности данных, вступил в силу, он остаётся в силе до тех пор, пока не будет установлен новый уровень (то есть, до первого октета, следующего за финальным сообщением BindResponse операции Bind, в результате которой вступил в силу новый уровень). Таким образом, на установленный уровень SASL не влияют завершившиеся неудачей или не-SASL операции Bind.
Клиенты могут определить поддерживаемые сервером механизмы SASL путём считывания атрибута 'supportedSASLMechanisms' из записи корневой DSE (DSA-Specific Entry) (раздел 5.1 RFC4512). В значениях этого атрибута, если таковые имеются, перечисляются поддерживаемые сервером в текущем состоянии сессии LDAP механизмы. LDAP-серверам следует (SHOULD) разрешать всем клиентам — даже с анонимной авторизацией — получать атрибут 'supportedSASLMechanisms' корневой DSE как до, так и после аутентификационного обмена SASL. Цель повторного получения поддерживаемых механизмов после установления уровня SASL — позволить клиентам выявить возможные атаки типа "downgrade attack" (смотрите раздел 6.4 этого документа и раздел 6.1.2 RFC4422).
Поскольку механизмы SASL обеспечивают критические функции безопасности, клиентам и серверам следует иметь возможность настройки таким образом, чтобы указать, какие механизмы являются приемлемыми, и разрешать использовать только эти механизмы. Перед началом использования сессии и клиенты, и серверы должны убедиться, что установленный уровень обеспечения безопасности удовлетворяет их требованиям.
После установки уровня SASL клиенту следует (SHOULD) отбросить или обновить всю информацию о сервере, полученную им до начала переговоров SASL, а также полученную без использования защитных механизмов.
Если безопасность обеспечивается более низкоуровневыми средствами (такими, как TLS), любой уровень SASL должен (SHALL) работать поверх таких уровней обеспечения безопасности, независимо от того, в каком порядке они были установлены. Во всем остальном уровень SASL и другие уровни обеспечения безопасности функционируют независимо друг от друга. Например, если одновременно действуют и уровень TLS, и уровень SASL, то снятие уровня TLS не влияет на продолжение работы уровня SASL.
LDAP поддерживает множественную аутентификацию SASL согласно определению, приведённому в разделе 4 RFC4422.
Некоторые механизмы SASL позволяют клиентам запрашивать для сессии LDAP желаемую авторизационную идентификационную сущность (раздел 3.4 RFC4422). Решение о том, позволять или не позволять текущей аутентификационной идентификационной сущности получать доступ от имени запрашиваемой авторизационной идентификационной сущности возлагается на локальную политику. Авторизационная идентификационная сущность представляет собой строку символов [Unicode], закодированную UTF-8 [RFC3629], соответствующую грамматике, описанной следующей расширенной формой Бэкуса-Наура (ABNF) [RFC4234]:
authzId = dnAuthzId / uAuthzId
; Авторизационная идентификационная сущность,
; основанная на уникальном имени (DN)
dnAuthzId = "dn:" distinguishedName
; Неопределённая авторизационная идентификационная
; сущность, закодированная UTF-8
uAuthzId = "u:" userid
userid = *UTF8 ; синтаксис не определён
Здесь правило distinguishedName определено в разделе 3 RFC4514, а правило UTF8 определено в разделе 1.4 RFC4512.
Пункт dnAuthzId используется для заявления авторизационных идентификационных сущностей в форме уникального имени, которые должны сравниваться по правилу соответствия distinguishedNameMatch (раздел 4.2.15 RFC4517). Не выдвигается требование, чтобы заявляемое значение distinguishedName соответствовало имени реальной записи, хранящейся в каталоге.
Пункт uAuthzId позволяет клиентам заявлять авторизационную идентификационную сущность в форме, отличной от уникального имени. Формат значения userid определяется только как последовательность символов [Unicode], закодированных UTF-8 [RFC3629], а дальнейшие интерпретации оставлены для решения на локальном уровне. Например, userid может идентифицировать пользователя конкретной службы каталогов, быть именем пользователя (логином) или адресом электронной почты. Не следует (SHOULD NOT) считать, что значение uAuthzId глобально уникально. Для сравнения значений uAuthzId каждое из них должно (MUST) быть подготовлено как строка "query" (раздел 7 RFC3454) с помощью алгоритма SASLprep [RFC4013], после чего два значения сравниваются побайтно.
Приведённая выше грамматика является расширяемой. Конструкция authzId может быть расширена для поддержки дополнительных форм идентификационных сущностей. Каждая форма отличается от других своим уникальным префиксом (регистрационные требования смотрите в разделе 3.12 RFC4520).
Разработчики должны позаботиться о сохранении семантик спецификаций SASL при обработке данных, имеющих другие семантики в протоколе LDAP.
Например, механизм аутентификации SASL DIGEST-MD5 [DIGEST-MD5] использует аутентификационную идентификационную сущность и область действия (realm), которые синтаксически представляют собой простые строки, а семантически — простые значения username [RFC4013] и realm. Эти значения не являются LDAP DN, и не требуется, чтобы они были представлены или рассматривались в качестве таковых.
Клиент может использовать механизм SASL EXTERNAL (приложение A RFC4422), чтобы запросить LDAP-сервер провести аутентификацию и установить результирующую авторизационную идентификационную сущность, используя защищённые удостоверяющие данные, обмен которыми произошёл на более низком уровне обеспечения безопасности (например, в ходе аутентификации TLS). Если клиент не предоставлял свои удостоверяющие данные аутентификации при установке более низкого уровня обеспечения безопасности, операция Bind с механизмом SASL EXTERNAL должна (MUST) завершиться неудачей с результирующим кодом inappropriateAuthentication. Хотя следствием этой ситуации является то, что сессия LDAP остаётся в анонимном состоянии (раздел 4), это не влияет на состояние каких-либо уже установленных уровней обеспечения безопасности.
Клиент может либо запросить, чтобы его авторизационная идентификационная сущность была автоматически получена из его удостоверяющих данных аутентификации, обмен которыми произошёл на более низком уровне обеспечения безопасности, либо явно предоставить желаемую авторизационную идентификационную сущность. Первый случай называется неявным заявлением авторизационной идентификационной сущности, второй — явным заявлением.
Неявное заявление авторизационной идентификационной сущности выполняется путём вызова запроса Bind в форме SASL с использованием имени EXTERNAL в поле mechanism и без указания опционального поля credentials (оба поля находятся в последовательности SaslCredentials сообщения BindRequest). Сервер будет получать авторизационную идентификационную сущность клиента из аутентификационной идентификационной сущности, предоставленной уровнем обеспечения безопасности (например, из сертификата открытого ключа, использованного во время установки уровня TLS) в соответствии с правилами локальной политики. Механизмы получения одной идентификационной сущности из другой зависят от реализации.
Явное заявление авторизационной идентификационной сущности выполняется путём вызова запроса Bind в форме SASL с использованием имени EXTERNAL в поле mechanism и с указанием опционального поля credentials (оба поля находятся в последовательности SaslCredentials сообщения BindRequest). Значением поля credentials (OCTET STRING) является заявляемая авторизационная идентификационная сущность, которая должна (MUST) быть построена так, как описано в разделе 5.2.1.8.
Весь этот документ посвящён обсуждению вопросов безопасности. Очевидно, что безопасность является неотъемлемой частью LDAP. В этом разделе также обсуждается ряд связанных с LDAP вопросов безопасности.
Сам по себе LDAP не обеспечивает защиту от доступа или обновления каталога средствами, отличными от выполнения операций протокола LDAP, например, от просмотра файлов базы данных сервера администраторами базы данных.
Конфиденциальная информация может содержаться практически в любом сообщении LDAP и её раскрытие может попадать под действие законов о защите персональных данных или других правовых актов во многих странах. Разработчикам следует принимать надлежащие меры для защиты конфиденциальной информации от её раскрытия несанкционированными лицами.
Сессия, в которой клиент не установил сервисов обеспечения целостности и конфиденциальности данных (например, средствами StartTLS, IPsec или соответствующего механизма SASL), может быть подвержена атакам типа "человек посередине" с целью просмотра и модификации информации в процессе её передачи. Разработчикам клиентов и серверов следует (SHOULD) принимать меры для защиты конфиденциальной информации в сессии LDAP от подобных атак путём использования сервисов защиты, как это обсуждалось в данном документе. Клиентам и серверам следует обеспечить возможность настройки таким образом, чтобы установление защитных мер было необходимым условием организации работы. Результирующий код confidentialityRequired предназначен для указания на то, что для выполнения запрашиваемой операции сервер требует установления (более строгой) защиты конфиденциальности данных.
При чтении конфиденциальной информации или обновлении информации каталога всегда должен применяться контроль доступа.
Различные факторы, влияющие на безопасность, в том числе информация, касающаяся аутентификации и авторизации, а также сервисы обеспечения безопасности данных могут изменяться в ходе одного и того же сеанса LDAP или даже в ходе выполнения одной конкретной операции. Реализациям следует адекватно обрабатывать изменения факторов безопасности.
Безопасность, достигаемая за счёт использования операции StartTLS, целиком и полностью является безопасностью, достигаемой за счёт использования самого TLS. Сама по себе операция StartTLS не предоставляет никаких дополнительных возможностей обеспечения безопасности.
Уровень безопасности, обеспечиваемый за счёт использования TLS, напрямую зависит как от качества используемой реализации TLS, так и от стиля использования этой реализации. Кроме того, злоумышленник, производящий атаку "человек посередине", может удалить расширенную операцию StartTLS из значений атрибута 'supportedExtension' корневой DSE. Обеим сторонам следует (SHOULD) независимо удостовериться и согласиться с уровнем безопасности, полученным в результате установления TLS, и сделать это до начала использования сессии, защищённой TLS. Например, может так произойти, что полученный в результате переговоров TLS уровень безопасности может ничем не превосходить передачу открытым текстом.
Клиенты должны (MUST) либо предупредить пользователя, если достигнутый уровень безопасности не обеспечивает приемлемого уровня защиты конфиденциальности и/или целостности данных, либо иметь возможность настройки таким образом, чтобы отказаться от продолжения работы, если не обеспечен приемлемый уровень безопасности.
Как сказано в разделе 3.1.2, сервер может использовать локальную политику для определения того, успешно ли завершены переговоры TLS. Администратору политики следует использовать информацию из сертификата пользователя, сгенерированного удостоверяющим центром или проверенного с его помощью, при настройке политик идентификации и авторизации.
Разработчикам серверов следует (SHOULD) разрешить администраторам сервера выбирать, требуется ли обеспечивать конфиденциальность и целостность данных и когда это необходимо делать, а также требуется ли аутентификация клиента в ходе переговоров TLS.
Разработчикам следует быть осведомленными и понимать соображения безопасности TLS, обсуждаемые в спецификации TLS [RFC4346].
В этом разделе обсуждается несколько вопросов безопасности по аутентификации LDAP средствами операции Bind.
Опыт работы показывает, что клиенты могут (и часто так и поступают) неправильно использовать механизм аутентификации без проверки подлинности метода простого подсоединения (смотрите раздел 5.1.2). Например, программа-клиент может принять решение предоставить доступ к информации, не имеющей отношения к каталогу, на основании успешного выполнения операции Bind. Реализации LDAP-сервера могут вернуть успешный ответ на запрос Bind без проверки подлинности. Это может ввести клиента в заблуждение, что сервер произвёл успешную аутентификацию идентификационной сущности, представленной заданным уникальным именем, тогда как на самом деле было установлено анонимное состояние авторизации. Клиентам, использующим результаты операции простого подсоединения для принятия решения по авторизации, следует активно выявлять запросы Bind без проверки подлинности (проверяя, что предоставленный пароль не пуст) и реагировать соответствующим образом.
При использовании механизма аутентификации по имени пользователя и паролю метода простого подсоединения происходит раскрытие пароля серверу, что само по себе является риском безопасности. Существуют другие механизмы, такие как SASL DIGEST-MD5, не раскрывающие пароль серверу.
В LDAP разрешены многозначные парольные атрибуты. В системах, где записи должны иметь один и только один пароль, такое поведение должно обеспечиваться административными методами.
Использование паролей в открытом виде и других незащищённых удостоверяющих данных аутентификации настоятельно не рекомендуется в открытых сетях, когда транспортный сервис не может гарантировать конфиденциальности данных. Реализациям LDAP не следует (SHOULD NOT) по умолчанию поддерживать методы аутентификации с использованием паролей в открытом виде и других незащищённых удостоверяющих данных, если данные в сессии не защищены с помощью TLS или других методов защиты конфиденциальности и целостности данных.
Передача паролей в открытом виде, — обычно для аутентификации или модификации, — представляет собой значительный риск безопасности. Этого риска можно избежать путём использования механизмов аутентификации SASL [RFC4422], не передающих пароли в открытом виде, либо установлением сервисов обеспечения конфиденциальности на транспортном уровне или на уровне сессии перед тем, как передавать значения паролей.
Чтобы снизить связанные с передачей паролей риски безопасности, реализация сервера, поддерживающая любые механизмы аутентификации на основе паролей, передающие пароли в открытом виде, должна (MUST) поддерживать механизм обеспечения такой политики, когда во время аутентификации или модификации пароля обязательными для выполнения были бы следующие условия:
Был успешно установлен уровень TLS.
ИЛИ
Был установлен какой-либо другой механизм обеспечения конфиденциальности данных, защищающий значения паролей от перехвата.
ИЛИ
Сервер возвращает результирующий код confidentialityRequired для такой операции (то есть, операции простого подсоединения Bind с передачей парольного значения, операции SASL Bind, передающей парольное значение в открытом виде, операции добавления или модификации, включающих значения атрибута userPassword, и т.д.), даже если значение пароля было корректным.
Реализации сервера также могут предоставлять механизмы обеспечения политик, при которых учётные данные признаются недействительными или защищаются каким-либо иным образом, если сервер определяет, что пароль для учётной записи был передан в открытом виде.
Некоторые механизмы аутентификации (например, DIGEST-MD5) передают по сети хэши значений паролей, которые могут быть уязвимы к оффлайн-атакам по словарю. Разработчикам следует позаботиться о защите таких хэшированных значений паролей во время их передачи по сети с помощью TLS или других механизмов обеспечения конфиденциальности данных.
До того момента, пока в сессии LDAP не установлены сервисы обеспечения целостности данных, злоумышленник может модифицировать передаваемые по сети ответы сервера со значениями атрибута 'supportedSASLMechanisms', и таким образом понизить качество доступных в списке механизмов SASL, включив в него только наименее безопасные механизмы. Для выявления этого типа атак клиент может запросить доступные на сервере механизмы SASL как до, так и после установления в сессии LDAP сервисов обеспечения целостности данных. Если клиент обнаруживает, что список с обеспечением защиты целостности (то есть полученный после установления сервисов защиты целостности) содержит более строгие механизмы, чем полученный ранее, ему следует считать, что полученный ранее список был модифицирован злоумышленником. В этих условиях клиенту рекомендуется закрыть лежащее в основе сессии транспортное соединение и выполнить переподключение для повторной установки сессии.
Дополнительные соображения безопасности, относящиеся к различным обсуждаемым в этом документе механизмам и методам аутентификации, можно найти в [RFC4422], [RFC4013], [RFC3454] и [RFC3629].
IANA обновила регистрацию механизма протокола LDAP, указав тем самым, что в данном документе и в [RFC4511] предоставлена окончательная техническая спецификация для расширенной операции StartTLS (1.3.6.1.4.1.1466.20037).
IANA обновила регистрацию типов LDAPMessage LDAP, указав тем самым, что в данном документе и в [RFC4511] предоставлена окончательная техническая спецификация для типов сообщений bindRequest (0) и bindResponse (1).
IANA обновила регистрацию метода аутентификации Bind LDAP, указав тем самым, что в данном документе и в [RFC4511] предоставлена окончательная техническая спецификация для методов аутентификации simple (0) и sasl (3) операции подсоединения.
IANA обновила регистрацию префиксов authzid LDAP, указав тем самым, что в данном документе предоставлена окончательная техническая спецификация для префиксов authzid dnAuthzId (dn:) и uAuthzId (u:).
Этот документ объединяет в себе информацию, изначально содержавшуюся в RFC 2251, RFC 2829 и RFC 2830. RFC 2251 — продукт рабочей группы Access, Searching and Indexing of Directories (ASID). RFC 2829 и RFC 2830 — продукты рабочей группы LDAP Extensions (LDAPEXT).
Данный документ — продукт рабочей группы IETF LDAP Revision (LDAPBIS).
[RFC791] Postel, J., "Протокол IP", STD 5, RFC 791, сентябрь 1981 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2460] Deering, S. и R. Hinden, "Спецификация протокола IPv6", RFC 2460, декабрь 1998 г.
[RFC3454] Hoffman, P. и M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, декабрь 2002 г.
[RFC3490] Faltstrom, P., Hoffman, P. и A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, март 2003 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, февраль 2005 г.
[RFC4234] Crocker, D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, октябрь 2005 г.
[RFC4346] Dierks, T. и E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, март 2006 г.
[RFC4422] Под редакцией Melnikov, A. и K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, июнь 2006 г.
[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC 4512, июнь 2006 г.
[RFC4514] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, июнь 2006 г.
[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, июнь 2006 г.
[RFC4519] Под редакцией Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, июнь 2006 г.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993 г.
[DIGEST-MD5] Leach, P., Newman, C. и A. Melnikov, "Using Digest Authentication as a SASL Mechanism", работы продолжаются, март 2006 г.
[PLAIN] Zeilenga, K., "The Plain SASL Mechanism", работы продолжаются, март 2005 г.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC2828, май 2000 г.
[RFC4301] Kent, S. и K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, декабрь 2005 г.
[RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505, июнь 2006 г.
Это приложение не является нормативным.
В этом приложении определены основные термины, концепции и связанные с ними понятия, касающиеся аутентификации, авторизации, удостоверяющих данных и подтверждения подлинности. Эти понятия используются при описании того, как различные подходы к обеспечению безопасности используются в аутентификации и авторизации клиента.
Политика контроля доступа — это набор правил, определяющих защиту ресурсов, обычно с точки зрения возможностей людей или иных субъектов получить доступ к этим ресурсам. Объекты и механизмы обеспечения безопасности, описанные в том числе и в этом приложении, предназначены для выражения политик контроля доступа и обеспечения их выполнения.
Запросы, при их обработке сервером, могут быть ассоциированы с широким спектром факторов, связанных с безопасностью. Сервер использует эти факторы, чтобы определить, стоит ли вообще обрабатывать запрос, и, если да, то как его обрабатывать. Эти факторы называются факторами контроля доступа (access control factors, ACFs). Они могут включать в себя IP-адрес источника запроса, стойкость шифрования, тип запрашиваемой операции, время дня и т.п. Некоторые факторы могут зависеть от специфики конкретного запроса; другие могут быть связаны с транспортным соединением, по которому передаётся запрос; наконец, некоторые (например, время дня) могут "зависеть от окружения".
Политики контроля доступа выражаются в терминах факторов контроля доступа; например, "запрос с факторами i,j,k может выполнить операцию Y с ресурсом Z". Набор факторов контроля доступа, которые разрешены сервером для использования в таких выражениях, зависит от реализации.
Удостоверяющие данные аутентификации — это доказательства, которые одна сторона предоставляет другой, подтверждающие подлинность идентификационной сущности стороны, предоставляющей эти данные (например, пользователя) и пытающейся установить новое состояние авторизации с другой стороной (обычно сервером). Аутентификация — это процесс генерации, передачи и проверки подлинности этих удостоверяющих данных и, следовательно, подтверждения подлинности представляемой этими данными идентификационной сущности. Аутентификационная идентификационная сущность — это имя, которое присутствует в удостоверяющих данных.
Существует множество форм удостоверяющих данных аутентификации. Используемая форма зависит от конкретного механизма аутентификации, применяемого в переговорах между сторонами. Примеры форм удостоверяющих данных аутентификации: сертификаты X.509, разрешения (тикеты) Kerberos, простые пары идентификационной сущности и пароля. Имейте ввиду, что механизмы аутентификации могут накладывать ограничения на используемые с ними формы аутентификационных идентификационных сущностей.
Авторизационная идентификационная сущность — это один из типов факторов контроля доступа. Она представляет собой имя пользователя или иного субъекта, запрашивающего те операции, которые будут выполняться. Политики контроля доступа часто выражаются в терминах авторизационных идентификационных сущностей; например, "субъект X может выполнить операцию Y с ресурсом Z".
Авторизационная идентификационная сущность сессии LDAP часто семантически совпадает с представленной клиентом аутентификационной идентификационной сущностью, но они могут различаться. SASL позволяет клиентам указать авторизационную идентификационную сущность отличную от аутентификационной, представленной в удостоверяющих данных клиента. Это позволяет агентам, таким как прокси-серверы, проходить аутентификацию на LDAP-сервере с использованием своих собственных удостоверяющих данных, а затем запрашивать привилегии доступа той идентификационной сущности, для которой они они осуществляют проксирование [RFC4422]. Кроме того, форма аутентификационной идентификационной сущности, предоставляемой некоторыми сервисами (например, TLS), может не соответствовать авторизационным идентификационным сущностям, используемым для выражения политики контроля доступа сервера, и потому требует выполнения какого либо специфичного для сервера отображения одной сущности в другую. Метод, по которому сервер составляет авторизационную идентификационную сущность из предоставленных клиентом удостоверяющих данных аутентификации и проверяет правильность такого составления, зависит от реализации.
Это приложение не является нормативным.
В данном приложении собраны основные изменения, внесённые в RFC 2251, RFC 2829 и RFC 2830. Читателям данного документа следует знать, что, кроме описанных ниже конкретных изменений, в текст исходных документов были внесены многочисленные общие редакционные правки, в том числе:
В этом разделе собраны основные изменения, внесённые этим документом в разделы 4.2.1 и 4.2.2 RFC 2251. Кроме того, важные изменения, внесённые в раздел 4.2.1 RFC 2251, представлены в [RFC4511].
В этом разделе собраны основные изменения, внесённые в RFC 2829.
В этом разделе собраны основные изменения, внесённые в разделы 3 и 5 RFC 2830. В [RFC4511] перечислены изменения, внесённые в другие разделы этого RFC.
Roger Harrison
Novell, Inc., 1800 S. Novell Place, Provo, Utah 84606, USA
Телефон: +1 801 861 2642
EMail: roger_harrison@novell.com
Copyright (C) Internet Society (2006).
На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.
Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).