Network Working Group Request for Comments: 3672 Категория: Standards Track K. Zeilenga (OpenLDAP Foundation), S. Legg (Adacel Technologies) Декабрь 2003 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (2003). Все права защищены.
В каталогах X.500 подзаписи представляют собой специальные записи, используемые для хранения информации, связанной с поддеревом, либо с уточнением поддерева. В данном документе механизм подзаписей X.500 адаптируется для использования в Lightweight Directory Access Protocol (LDAP).
Выдержка из [X.501]:
Подзапись — это особый вид записи, которая является непосредственно подчиненной по отношению к административной точке. Она содержит атрибуты, имеющие отношение к поддереву (или уточнению поддерева), связанному с её административной точкой. Подзаписи и их административная точка являются составной частью одного и того же контекста именования.
Одна подзапись может обслуживать все или несколько аспектов административных полномочий. Альтернативным образом, конкретный аспект административных полномочий может обрабатываться одной или несколькими из собственных подзаписей.
В Lightweight Directory Access Protocol (LDAP) [RFC3377] подзаписи должны (SHALL) функционировать в соответствии со стандартом Х.501, если в данной спецификации не указано иное.
Если не указан элемент управления subentries (описанный в разделе 3), подзаписи не должны (SHALL NOT) рассматриваться в операциях поиска с диапазонами one-level и subtree. Во всех остальных операциях, в том числе в операциях поиска с диапазоном base, подзаписи должны (SHALL) рассматриваться.
Определения схемы данных приводятся с использованием форматов описаний LDAP [RFC2252]. Приведённые в данном документе определения отформатированы (разбивка строк) для повышения читабельности.
Элементы протокола описаны с использованием ASN.1 [X.680]. Термин "закодирован в BER" означает, что элемент должен быть закодирован с использованием Basic Encoding Rules [X.690] с ограничениями, изложенными в разделе 5.1 RFC2251.
В этом документе ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) интерпретируются так, как описано в BCP 14 [RFC2119].
Синтаксис спецификации поддерева предоставляет механизм общего назначения для спецификации подмножества записей в поддереве информационного дерева каталога (Directory Information Tree, DIT). Поддерево начинается с некоторой базовой записи и включает объекты, подчинённые по отношению к этой записи, вплоть до некоторой идентифицированной нижней границы, либо, возможно, подчинённые объекты вплоть до листовых записей. Спецификация поддерева всегда используется совместно с контекстом или диапазоном, который неявно определяет границы этого поддерева. Например, в диапазон спецификации поддерева для административной области не входят поддеревья любых подчиненных записей административных точек для администрирования подсхемы. Если спецификация поддерева не идентифицирует непрерывное подмножество записей в одном поддереве, то коллекция называется уточнением поддерева.
Данный синтаксис соответствует ASN.1-типу SubtreeSpecification, описанному в разделе 11.3 стандарта X.501. Это определение типа данных ASN.1 воспроизводится здесь для полноты данной спецификации.
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
LocalName ::= RDNSequence
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0 .. MAX)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
Компоненты SubtreeSpecification: base, идентифицирующее базовую запись поддерева или уточнения поддерева, а также specificExclusions, minimum, maximum и specificationFilter, которые затем сокращают набор подчиненных записей этой базовой записи. Поддерево или уточнение поддерева включает все записи в пределах диапазона, которые не были исключены каким-либо из компонентов данной спецификации поддерева. При отсутствии всех компонентов SubtreeSpecification (то есть когда значением синтаксиса спецификации поддерева является пустая последовательность, {}), указанное поддерево неявно включает в себя все записи в пределах диапазона.
При любом конкретном использовании этого механизма могут (MAY) налагаться ограничения на компоненты SubtreeSpecification.
Спецификация синтаксиса LDAP:
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
Специфичная для LDAP кодировка значений данного синтаксиса определяется общими правилами кодирования строк (Generic String Encoding Rules) [RFC3641]. В приложении A приведён эквивалент расширенной формы Бэкуса-Наура (Augmented Backus-Naur Form, ABNF) [RFC2234] для этого синтаксиса.
Компонент base конструкции SubtreeSpecification назначает базовую запись поддерева или уточнения поддерева. В качестве базовой записи может быть указана любая запись, подчинённая корневой записи того диапазона, в котором используется спецификация поддерева. В этом случае компонент base содержит последовательность относительных уникальных имён (Relative Distinguished Name, RDN), собранную относительно имени корневой записи этого диапазона. Либо базовая запись может быть самой корневой записью диапазона (значение по умолчанию). В этом случае компонент base отсутствует или содержит пустую последовательность RDN.
Записи, не являющиеся подчинёнными данной базовой записи, исключаются из определяемого поддерева или уточнения поддерева.
Компонент specificExclusions конструкции ChopSpecification представляет собой список исключений, где указываются записи, которые (вместе с подчинёнными им записями) должны быть исключены из поддерева или уточнения поддерева. Запись указывается последовательностью RDN, собранной относительно базовой записи (так называемое локальное имя (LocalName)). Каждое исключение может быть либо в форме chopBefore, либо в форме chopAfter. При использовании формы chopBefore из поддерева или уточнения поддерева исключаются указанная запись и подчинённые ей записи. При использовании формы chopAfter из поддерева или уточнения поддерева исключаются только записи, подчинённые указанной записи.
Компоненты minimum и maximum конструкции ChopSpecification позволяют задать исключение записей на основе глубины их расположения в DIT.
Записи, в которых количество RDN, находящихся ниже базовой записи, меньше, чем число minimum, исключаются из поддерева или уточнения поддерева. Значение ноль компонента minimum (по умолчанию) соответствует самой базовой записи.
Записи, в которых количество RDN, находящихся ниже базовой записи, больше, чем число maximum, исключаются из поддерева или уточнения поддерева. Отсутствие компонента maximum указывает на то, что для записей в поддереве или в уточнении поддерева не устанавливается верхнего предела на количество RDN, находящихся ниже базовой записи.
Компонент specificationFilter представляет собой булевое выражение с утверждениями о значениях атрибута objectClass базовой записи и подчиненных ей записей. Элемент утверждения item конструкции Refinement оценивается для какой-либо записи как true, если атрибут objectClass этой записи содержит OID, указанный в этом утверждении. Записи, для которых общий фильтр оценивается как false, исключаются из уточнения поддерева. Если компонент specificationFilter отсутствует, то исключение записей из поддерева (или из уточнения поддерева) по значениям их атрибута objectClass не выполняется.
Административная модель, определённая в пункте 10 стандарта X.501, требует, чтобы административные записи содержали атрибут administrativeRole для указания того, что соответствующая административная область связана с одной или несколькими административными ролями.
Спецификация операционного атрибута administrativeRole:
( 2.5.18.5 NAME 'administrativeRole'
EQUALITY objectIdentifierMatch
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
В стандарте X.501 определены возможные значения этого атрибута:
OID ИМЯ
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
В других спецификациях могут быть определены другие значения. Имена, ассоциированные с каждой административной ролью, являются дескрипторами идентификаторов объектов [RFC3383].
Операционный атрибут administrativeRole также используется для регулирования того, каким подзаписям разрешено быть подчинёнными по отношению к административной записи. Подзапись, относящаяся к классу, не разрешённому в атрибуте administrativeRole, не может быть подчинённой по отношению к административной записи.
Спецификация операционного атрибута subtreeSpecification:
( 2.5.18.6 NAME 'subtreeSpecification'
SINGLE-VALUE
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
Этот атрибут присутствует во всех подзаписях. Смотрите пункт 10 X.501. Значения атрибута subtreeSpecification определяют коллекции записей в составе DIT для одного или нескольких аспектов административных полномочий.
Объектный класс subentry является структурным объектным классом.
( 2.5.17.0 NAME 'subentry'
SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
Элемент управления subentries может (MAY) посылаться с запросом searchRequest для контроля видимости записей и подзаписей, находящихся в пределах диапазона поиска. Невидимые записи и подзаписи не возвращаются в ответе на такой запрос.
Элемент управления subentries представляет собой элемент управления LDAP, в котором поле controlType имеет значение 1.3.6.1.4.1.4203.1.10.1, поле criticality — TRUE или FALSE (при отсутствии — FALSE), а поле controlValue содержит закодированное в BER значение типа BOOLEAN, указывающее видимость объектов. Поле controlValue, в котором содержится значение TRUE, указывает на то, что подзаписи видны, а обычные записи — нет. Поле controlValue, в котором содержится значение FALSE, указывает на то, что обычные записи видны, а подзаписи — нет.
Обратите внимание, что закодированное значение видимости TRUE представляет собой три октета { 01 01 FF }, а закодированное значение видимости FALSE представляет собой три октета { 01 01 00 }.
Поле controlValue не должно (SHALL NOT) отсутствовать.
При отсутствии данного элемента управления, подзаписи не видны при выполнении поисковых запросов с диапазонами singleLevel и wholeSubtree, но видны при выполнении поисковых запросов с диапазоном baseObject.
Соответствующего элемента управления ответа не существует.
Этот элемент управления не подходит для операций, отличных от операции поиска.
Часто в подзаписях содержится административная или иная конфиденциальная информация, и их следует защищать от неавторизованного доступа и раскрытия как описано в [RFC2829] и [RFC2830].
Также к ним применяются общие соображения безопасности о LDAP [RFC3377].
IANA произвела регистрацию описанных в данной технической спецификации дескрипторов LDAP. Был предложен следующий регистрационный шаблон:
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC3672
Author/Change Controller: IESG
Comments:
NAME Type OID
------------------------ ---- --------
accessControlInnerArea R 2.5.23.3
accessControlSpecificArea R 2.5.23.2
administrativeRole A 2.5.18.5
autonomousArea R 2.5.23.1
collectiveAttributeInnerArea R 2.5.23.6
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.17.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
В этом документе используется OID 1.3.6.1.4.1.4203.1.10.1 для идентификации элемента протокола LDAP, определённого в этом же документе. Данный OID бы назначен организацией OpenLDAP Foundation [ASSIGN] в пределах выделенного IANA для этой организации диапазона OID частного предприятия [PRIVATE]. Данный OID был выделен для использования в этой спецификации.
Другие фигурирующие в этом документе OID либо были назначены Подкомитетом 6 Совместного технического комитета 1 ISO/IEC для идентификации элементов схемы X.500, либо назначены в RFC 2252 для использования в порядке, описанном в этом документе.
IANA произвела регистрацию описанных в данной технической спецификации механизмов протокола LDAP [RFC3383].
Subject: Request for LDAP Protocol Mechanism Registration
Description: Subentries
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Control
Specification: RFC3672
Author/Change Controller: IESG
Comments: none
Этот документ основан на исследованиях, произведённых рабочими группами IETF LDUP и LDAPext, в том числе на работе "Схема данных подзаписи LDAP", выполненной Ed Reed. Часть материала этого документа также заимствована из ряда документов ITU, в том числе стандарта X.501.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам IETF в отношении прав в стандартах и относящихся к ним документах можно найти в BCP-11. Предоставленные для публикации копии заявлений о правах, а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации в секретариате IETF.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию исполнительному директору IETF.
Это приложение не является нормативным.
Специфичная для LDAP кодировка строк для синтаксиса спецификации поддерева определяется общими правилами кодирования строк (Generic String Encoding Rules) [RFC3641]. В данном приложении форма ABNF [RFC2234] для этого синтаксиса приведена только для удобства и является эквивалентом кодировке, спецификация которой дана в приложении к [RFC3641]. Поскольку ASN.1-тип SubtreeSpecification может быть расширен в будущих редакциях стандарта [X.501], приведённую ABNF следует рассматривать как моментальный снимок на текущий момент времени. Специфичная для LDAP кодировка любого расширения ASN.1-типа SubtreeSpecification может быть определена в терминах [RFC3641].
В случае несоответствия между этой ABNF и кодировкой, определяемой [RFC3641], дефинитивными считаются определения из [RFC3641].
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
BaseDistance = INTEGER-0-MAX
Правила <sp>, <msp>, <sep>, <INTEGER>, <INTEGER-0-MAX>, <OBJECT-IDENTIFIER> и <LocalName> определены в [RFC3642].
[X.501] ITU-T, "The Directory: Models," X.501, 1993 г.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680, 1994 г.
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", X.690, 1994 г.
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 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 г.
[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 г.
[RFC3377] Hodges, J. и R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", RFC 3383, сентябрь 2002 г.
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, октябрь 2003 г.
[RFC2234] Crocker, D. и P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, ноябрь 1997 г.
[RFC3642] Legg, S., "Common Elements of Generic String Encoding Rules (GSER) Encodings", RFC 3642, октябрь 2003 г.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", http://www.openldap.org/foundation/oid-delegate.txt
[PRIVATE] IANA, "Private Enterprise Numbers", http://www.iana.org/assignments/enterprise-numbers
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Steven Legg
Adacel Technologies Ltd.
250 Bay Street, Brighton, Victoria 3186, AUSTRALIA
Телефон: +61 3 8530 7710
Факс: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
Copyright (C) Internet Society (2003). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.