Network Working Group Request for Comments: 4515 Категория: Standards Track Под редакцией M. Smith (Pearl Crescent, LLC), T. Howes (Opsware, Inc.) Июнь 2006 года Отменяет: 2254
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
Поисковые фильтры протокола Lightweight Directory Access Protocol (LDAP) передаются в поисковых запросах протокола LDAP в бинарном представлении, подходящем для использования в сети. В этом документе определяется пригодное для чтения человеком строковое представление поисковых фильтров LDAP, которое подходит для использования в LDAP URL (RFC 4516) и в других приложениях.
Протокол Lightweight Directory Access Protocol (LDAP) [RFC4510] определяет сетевое представление поискового фильтра, передаваемого серверу LDAP. В некоторых приложениях может оказаться полезным иметь общепринятый способ представления таких поисковых фильтров в форме, пригодной для чтения человеком; в качестве примера такого приложения можно привести LDAP URL [RFC4516]. В этом документе определяется пригодный для чтения человеком формат для представления всего спектра возможных поисковых фильтров LDAP версии 3, в том числе фильтров расширенного поиска соответствия.
Данный документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей ранее определённую техническую спецификацию LDAP, RFC 3377.
Этот документ заменяет RFC 2254. Изменения, внесённые в RFC 2254, обобщены в приложении A.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Поисковый фильтр LDAP определён в разделе 4.5.1 RFC 4511 следующим образом:
Filter ::= CHOICE {
and [0] SET SIZE (1..MAX) OF filter Filter,
or [1] SET SIZE (1..MAX) OF filter Filter,
not [2] Filter,
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] MatchingRuleAssertion }
SubstringFilter ::= SEQUENCE {
type AttributeDescription,
-- initial и final могут присутствовать не более одного раза
substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
initial [0] AssertionValue,
any [1] AssertionValue,
final [2] AssertionValue } }
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
MatchingRuleAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
matchValue [3] AssertionValue,
dnAttributes [4] BOOLEAN DEFAULT FALSE }
AttributeDescription ::= LDAPString
-- ограничена до конструкции <attributedescription>
-- [RFC4512]
AttributeValue ::= OCTET STRING
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
LDAPString ::= OCTET STRING -- символы [Unicode],
-- закодированные в UTF-8
Как определено в [RFC4511], AttributeDescription — это строковое представление описания атрибута, которое обсуждается в [RFC4512]. Форма строки октетов (OCTET STRING) для конструкций AttributeValue и AssertionValue определена в [RFC4517]. Для передачи по сети данный фильтр кодируется с помощью основных правил кодирования (Basic Encoding Rules, BER), определённых в [X.690], с упрощениями, описанными в [RFC4511].
Строковое представление поискового фильтра LDAP — это строка символов Unicode [Unicode], закодированных в UTF-8 [RFC3629], которая определяется приведённой ниже грамматикой, описанной нотацией ABNF [RFC4234]. Конструкции, определения которых не приведены здесь, определяются (если не оговорено иное) в разделе 1.4 ("Общие конструкции ABNF") RFC 4512. В формате фильтра используется префиксная нотация.
filter = LPAREN filtercomp RPAREN
filtercomp = and / or / not / item
and = AMPERSAND filterlist
or = VERTBAR filterlist
not = EXCLAMATION filter
filterlist = 1*filter
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
lessorequal = LANGLE EQUALS
extensible = ( attr [dnattrs]
[matchingrule] COLON EQUALS assertionvalue )
/ ( [dnattrs]
matchingrule COLON EQUALS assertionvalue )
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; Правило attributedescription определено в
; разделе 2.5 RFC 4512.
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; Правило <valueencoding> используется для кодирования <AssertionValue>
; из раздела 4.1.6 RFC 4511.
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET исключает 0x00 (NUL), LPAREN,
; RPAREN, ASTERISK и ESC.
EXCLAMATION = %x21 ; восклицательный знак ("!")
AMPERSAND = %x26 ; амперсанд (или символ AND) ("&")
ASTERISK = %x2A ; астериск ("*")
COLON = %x3A ; двоеточие (":")
VERTBAR = %x7C ; вертикальная черта ("|")
TILDE = %x7E ; тильда ("~")
Имейте ввиду, что хотя в обеих конструкциях <substring> и <present> из данной грамматики может получиться выражение "attr=*", данное выражение используется только для обозначения фильтра наличия (presence filter).
Правило <valueencoding> гарантирует, что строка фильтра в целом является допустимой строкой UTF-8, а также обеспечивает, что октеты, представляющие собой ASCII-символы "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII 0x29), "\" (ASCII 0x5c) и NUL (ASCII 0x00), представлены в виде обратного слеша "\" (ASCII 0x5c), за которым следуют две шестнадцатеричные цифры, представляющие собой значение этого закодированного октета.
Такой простой механизм экранирования устраняет неоднозначности при синтаксическом разборе фильтра и позволяет любому фильтру, который может быть представлен в LDAP, быть представленным в виде нуль-терминированной строки (NUL-terminated string). Другие октеты, которые являются частью набора <normal>, могут быть экранированы с использованием этого механизма, например, непечатные символы ASCII.
Для значений AssertionValues, содержащих данные с символами UTF-8, каждый октет такого символа, который должен быть экранирован, заменяется обратным слешем и двумя шестнадцатеричными цифрами, которые формируют один октет в коде символа. Например, проверочное выражение фильтра, в котором атрибут "cn" содержит значение с символом "*" в произвольном месте, будет представлено как "(cn=*\2a*)".
Как указывается правилом <valueencoding>, при генерации строкового представления поискового фильтра реализации должны (MUST) экранировать все октеты, большие 0x7F, которые не являются частью допустимой последовательности кодирования UTF-8. Реализациям следует (SHOULD) принимать входные строки, которые не являются допустимыми строками UTF-8. Это необходимо, поскольку в RFC 2254 не однозначно определён термин "строковое представление" (и, в частности, не упоминается то, что строковое представление поискового фильтра LDAP является строкой символов Unicode, закодированных в UTF-8).
В этом разделе приводится несколько примеров поисковых фильтров, составленных с использованием данной нотации.
(cn=Babs Jensen)
(!(cn=Tim Howes))
(&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
(o=univ*of*mich*)
(seeAlso=)
В следующих примерах демонстрируется использование расширенного соответствия:
(cn:caseExactMatch:=Fred Flintstone)
(cn:=Betty Rubble)
(sn:dn:2.4.6.8.10:=Barney Rubble)
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:DN:2.4.6.8.10:=Dino)
В первом примере показано использование правила соответствия "caseExactMatch."
Во втором примере демонстрируется использование формы MatchingRuleAssertion без указания matchingRule.
В третьем примере показано использование нотации ":oid" для указания того, что при выполнении сравнения должно быть использовано правило соответствия с идентификатором OID "2.4.6.8.10". Кроме того, указано (с использованием нотации ":dn"), что при поиске совпадения атрибуты уникального имени записи должны рассматриваться как часть самой записи.
В четвёртом примере представлено соответствие equality, за исключением того, что при поиске совпадения компоненты DN записи должны рассматриваться как часть самой записи.
В пятом примере представлен фильтр, который будет применяться к любому атрибуту, поддерживающему указанное правило соответствия (поскольку часть <attr> была опущена).
В последнем примере также представлен фильтр, который будет применяться к любому атрибуту, поддерживающему указанное правило соответствия. Содержащиеся в DN записи атрибуты, которые поддерживают это правило соответствия, также должны быть рассмотрены при поиске соответствия.
В следующих примерах демонстрируется использование механизма экранирования:
(o=Parens R Us \28for all your parenthetical needs\29)
(cn=*\2A*)
(filename=C:\5cMyFile)
(bin=\00\00\00\04)
(sn=Lu\c4\8di\c4\87)
(1.3.6.1.4.1.1466.0=\04\02\48\69)
В первом примере показано использование механизма экранирования для представления символов скобок. Во втором демонстрируется, как представить символ "*" в значении утверждения, так, чтобы он не интерпретировался как индикатор подстроки. В третьем примере показано экранирование символа обратного слеша.
В четвёртом примере приведён фильтр для поиска значения из четырёх октетов 00 00 00 04 (шестнадцатеричные коды). Иллюстрируется использование механизма экранирования для представления произвольных данных, в том числе NUL-символов.
В пятом примере демонстрируется использование механизма экранирования для представления различных не-ASCII символов UTF-8. В частности, в части <assertionvalue> этого примера присутствуют 5 символов: LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069) и LATIN SMALL LETTER C WITH ACUTE (U+0107).
В последнем примере демонстрируется утверждение закодированного в BER значения.
В этом документе описано строковое представление поисковых фильтров LDAP. Хотя само по себе данное представление не имеет выявленного влияния на безопасность, поисковые фильтры LDAP могут оказывать такое влияние. Они интерпретируются серверами LDAP для отбора записей, из которых извлекаются данные. Серверам LDAP следует позаботиться о защите обслуживаемых ими данных от несанкционированного доступа.
Для получения дополнительной информации смотрите разделы о безопасности в [RFC4511] и [RFC4513].
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.
[RFC4512] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Информационные модели каталога", RFC 4512, июнь 2006 г.
[RFC4513] Под редакцией Harrison, R., "Lightweight Directory Access Protocol (LDAP): Методы аутентификации и механизмы обеспечения безопасности", RFC 4513, июнь 2006 г.
[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Синтаксисы и правила соответствия", RFC 4517, июнь 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."
[RFC4516] Под редакцией Smith, M. и T. Howes, "Lightweight Directory Access Protocol (LDAP): Единый указатель ресурса (URL)", RFC 4516, июнь 2006 г.
[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
Этот документ заменяет RFC 2254, автор Tim Howes. RFC 2254 — продукт рабочей группы IETF ASID.
Изменения, включённые в данную пересмотренную спецификацию, основаны на обсуждениях между авторами, обсуждениях в рабочей группе LDAP (v3) Revision (ldapbis), а также в других рабочих группах IETF. Авторы высоко оценивают вклад, внесённый представителями этих рабочих групп.
Указание набора символов [ISO 10646] заменено на [Unicode].
В раздел "Определение строкового представления поискового фильтра" внесены следующие технические изменения:
Добавлено утверждение, что строковое представление является строкой закодированных в UTF-8 символов Unicode.
Пересмотрены все определения ABNF так, чтобы в них использовались общие конструкции из [RFC4512].
В определениях правил "simple", "extensible" и "substring" ("initial", "any" и "final") правило "value" заменено на новое правило "assertionvalue". Это соответствует изменениям, внесённым в [RFC4517].
Для ясности компоненты подконструкций конструкции <extensible> были окружены круглыми скобками "(" и ")".
Пересмотрены определения ABNF "attr", "matchingrule" и "assertionvalue" для более точного указания на конструкции из документов [RFC4512] и [RFC4511].
Для устранения путаницы в разделе "Определение строкового представления поискового фильтра" конструкции "greater" и "less" заменены на "greaterorequal" и "lessorequal".
Для уменьшения зависимости от описательного текста введено правило "valueencoding" и связанные с ним правила "normal" и "escaped". Конструкция "normal" ограничивает строки фильтров до допустимых последовательностей UTF-8.
Добавлено заявление об ожидаемом поведении из-за недостаточно точного определения "строкового представления" в RFC 2254.
В заголовок документа добавлено указание протокола LDAP.
Примечание IESG: удалено замечание об отсутствии удовлетворительных механизмов аутентификации, обязательных для реализации.
Заголовок и раздел "Адреса авторов": Mark Smith добавлен в качестве редактора документа, а также обновлена информация о месте работы и контактная информация.
Добавлены разделы "Содержание" и "Интеллектуальная собственность".
Заявление об авторских правах обновлено согласно последним требованиям IETF.
Раздел "Тезисы" отделён от вступительного материала.
Раздел "Введение": новый раздел; отделён от "Тезисов". Обновлён второй параграф, где сказано, что данный документ заменяет RFC 2254 (вместо RFC 1960). Добавлена ссылка на [RFC4510].
Раздел "Определение поискового фильтра LDAP": сделаны корректировки ABNF поискового фильтра LDAP, так, чтобы она соответствовала используемой в [RFC4511].
Дано более понятное определение конструкции 'value' (теперь 'assertionvalue'), отражающее тот факт, что эта конструкция не является в точности конструкцией AttributeAssertion из раздела 4.1.6 RFC 4511 (для некоторых символов требуется специальная обработка). Добавлено замечание, что каждый октет символа, который требуется экранировать, заменяется обратным слешем и двумя шестнадцатеричными цифрами, представляющими собой один октет.
Раздел "Примеры": добавлены четыре дополнительных примера: (seeAlso=), (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone) и (1.3.6.1.4.1.1466.0=\04\02\48\69). В одном предложении слово "значение" заменено на "значение утверждения". Исправлено описание примера (sn:dn:2.4.6.8.10:=Barney Rubble). В первом примере с расширенным соответствием числовой OID заменён на "caseExactMatch" для демонстрации использования описательной формы. В последнем примере с расширенным соответствием показано применение "DN" (в верхнем регистре), чтобы напомнить читателю, что значения конструкции <dnattrs> рассматриваются как нечувствительные к регистру символов. Изменено описание четвёртого примера с использованием механизма экранирования: исключена возможность представить байты в неверном порядке. В пятый пример с использованием механизма экранирования добавлен текст, поясняющий, что представляют собой не-ASCII символы в терминах Unicode.
Раздел "О безопасности": добавлены ссылки на [RFC4511] и [RFC4513].
Раздел "Нормативные документы": переименован из "Документов" согласно новым требованиям к RFC. Стиль оформления ссылок изменён с [1] на [RFC4511] по всему документу. Добавлены записи для [Unicode], [RFC2119], [RFC4513], [RFC4512] и [RFC4510], а также обновлена ссылка для UTF-8. Ссылка на RFC 822 заменена на RFC 4234.
Раздел "Информативные документы" (новый раздел): ссылка на [X.690] перенесена в этот раздел. Добавлена ссылка на [RFC4516].
Добавлен раздел "Благодарности".
Добавлен раздел "Приложение A: Изменения, внесённые в RFC 2254".
В описательном тексте все конструкции ABNF заключены в угловые скобки "<" и ">".
Все упоминания "LDAPv3" заменены на "LDAP."
Mark Smith, редактор
Pearl Crescent, LLC, 447 Marlpool Dr. Saline, MI 48176, USA
Телефон: +1 734 944-2856
EMail: mcs@pearlcrescent.com
Tim Howes
Opsware, Inc., 599 N. Mathilda Ave. Sunnyvale, CA 94085, USA
Телефон: +1 408 744-7509
EMail: howes@opsware.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).