|
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
Network Working Group Request for Comments: 4505 Obsoletes: 2245
|
K. Zeilenga, Ed.
OpenLDAP Foundation
June 2006
|
||||||||||||||||||||||||||||||||||||||||||||||
|
Category: Standards Track
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
Механизм Anonymous в SASL
Anonymous Simple Authentication and Security Layer (SASL) Mechanism
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (2006).
Тезисы
В сети Internet обычной практикой является предоставление анонимным пользователям доступа к различным сетевым службам. Обычно это организуется на основе механизма с открытыми паролями, использующего "anonymous" в качестве имени пользователя и в некоторых случаях использующего необязательную трассировочную информацию (типа адреса электронной почты) в качестве пароля. В новых протоколах IETF не допускаются команды регистрации в системе (login) в виде открытого текста, поэтому требуется новый метод предоставления доступа анонимным пользователям в контексте схемы SASL1.
1. Введение
В этом документе определяется механизм анонимного доступа для схемы SASL [SASL]. Имя этого механизма "ANONYMOUS".
В отличие от многих других механизмов SASL, задачей которых является идентификация и аутентификация пользователя на сервере, задачей данного механизма SASL является предоставление пользователю доступа к службам или ресурсам без раскрытия серверу своей идентификации. Т. е., данный механизм обеспечивает метод анонимной регистрации в системе (login).
Данный механизм не обеспечивает уровня защиты.
Этот документ заменяет собой RFC 2245. Изменения по отношению к RFC 2245 отражены в Приложении A.
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
2. Механизм Anonymous
|
|
||||||||||||||||||||||||||||||||||||||||||||||
|
Механизм состоит из простого сообщения, передаваемого клиентом серверу. Клиент может включить в это сообщение трассировочную информацию в форме строки символов Unicode [Unicode] с кодировкой UTF-8 [UTF-8] в соответствии с [StringPrep] и “трассировать” профиль stringprep, определенный в главе 3 данного документа. Трассировочную информацию, которая не имеет семантического значения, следует задавать в одной из двух возможных форм – адрес электронной почты Internet или произвольная (opaque) строка, не содержащая символов @ (U+0040), которая может быть интерпретирована системным администратором домена на стороне клиента. По причинам сохранения приватности адрес электронной почты или иные сведения, идентифицирующие пользователя, могут использоваться только с его разрешения.
Сервер, который позволяет анонимный доступ, будет анонсировать поддержку механизма ANONYMOUS и позволять использовать этот механизм любому желающему, обычно ограничивая права для анонимных пользователей.
Ниже приведен формальный синтаксис клиентского сообщения в формате ABNF [ABNF], как иллюстрация к данной технической спецификации.
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
message
|
[ email / token ]
|
;; готовится в соответствии с главой 3
|
|||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
/
|
||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
TCHAR
email token
|
|
UTF1 / UTF2 / UTF3 / UTF4
;; любые символы Unicode в кодировке UTF-8, за исключением @ (U+0040)
|
|||||||||||||||||||||||||||||||||||||||||||||
|
= addr-spec = 1*255TCHAR
|
;; в соответствии с [IMAIL]
|
||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
1Simple Authentication and Security
|
Layer – простой уровень аутентификации и защиты. Прим. перев.
|
||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||
|
|
Перевод RFC 4505
|
||
|
|
|||
|
Примечание для разработчиков:
Размер маркера <token> ограничен 255 символами в кодировке UTF-8. Поскольку данная кодировка использует от 1 до 4 октетов на символ, размер маркера может достигать 1020 октетов.
3. “Трассировка” профиля "Stringprep"
В этой главе определена “трассировка” профиля [StringPrep]. Этот профиль разработан для использования с механизмом SASL ANONYMOUS. В частности, клиент готовит <message> в соответствии с этим профилем.
Набором символов для этого профиля является Unicode 3.2 [Unicode].
Для профиля не требуется отображения.
Для профиля не требуется нормализации Unicode.
Список неиспользуемых кодов (code point) для этого профиля определен в Приложении A к документу [StringPrep]. Неиспользуемые коды не являются запрещенными.
Запрещено использование символов из следующих таблиц [StringPrep]:
♦ C.2.1 (управляющие символы ASCII)
♦ C.2.2 (управляющие символы, отличные от ASCII)
♦ C.3 (символы для приватного использования)
♦ C.4 (не имеющие символов коды)
♦ C.5 (суррогатные коды)
♦ C.6 (неприемлемо для текста)
♦ C.8 (изменение свойств дисплея запрещено)
♦ C.9 (символы для тегов) Других запрещенных символов нет.
Данный профиль требует двунаправленной проверки символов в соответствии с главой 6 документа [StringPrep].
4. Пример
Здесь рассмотрен простой пример использования механизма ANONYMOUS между клиентом и сервером IMAP. В примере префиксы "C:" и "S:" указывают строки, передаваемые клиентом и сервером, соответственно. Если следующая строка не содержит префикса "C:" или "S:", она является просто переносом предыдущей строки, сделанным для удобства чтения.
Отметим, что в этом примере используется профиль IMAP [IMAP4] для SASL. Кодирование base64 для запросов и откликов, а также префиксы "+ " в откликах являются частью профиля IMAP4 и не относятся непосредственно в SASL. Кроме того, протоколы с профилями SASL, разрешающими клиенту включать в запрос на организацию аутентификационной сессии начальный отклик, позволяют сэкономить один период кругового обхода для аутентификационного обмена (избежать показанного ниже отклика "+ " с пустой строкой).
В данном примере трассировочной информацией является строка "sirhc".
|
|||
|
|
|||
|
* OK IMAP4 server ready A001 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS A001 OK done
A002 AUTHENTICATE ANONYMOUS +
c2lyaGM= A003 OK Welcome, trace information has been logged.
|
|||
|
|
|||
|
5. Вопросы безопасности
Механизм ANONYMOUS предоставляет доступ к службам и/или ресурсам любому желающему. По этой причине его следует отключать по умолчанию, предоставляя администратору возможность включения этого механизма при необходимости.
Если анонимному пользователю предоставляется право записи, возможна организация атаки на службу путем заполнения всего доступного для записи пространства. Для предотвращения таких атак можно запретить запись для анонимных пользователей.
Если анонимные пользователи имеют возможность чтения и записи в одну область, сервер можно будет использовать в качестве коммуникационного механизма анонимного обмена информацией. Серверам, разрешающим анонимным пользователям подачу информации, следует реализовать модель "drop box", в которой анонимный доступ для чтения невозможен в областях, открытых анонимным пользователям для подачи информации.
Если анонимный пользователь может запускать множество ресурсоемких операций (например, команд IMAP SEARCH BODY), это позволяет организовать атаку на службу. Для серверов настоятельно рекомендуется снизить приоритет для анонимных пользователей или ограничить для них выделяемые ресурсы.
Хотя серверы могут вносить ограничения на число анонимных пользователей, такие ограничения открывают возможность атак на службы, поэтому ими следует пользоваться с осторожностью.
Трассировочная информация не проверяется и ее можно фальсифицировать. Это может использоваться для указания чужих данных при доступе к информации сомнительного свойства. Администраторам, исследующим факты недопустимого использования, следует принимать во внимание возможность фальсификации трассировочных данных.
|
|||
|
|
|||
|
|
|||
|
Перевод RFC 4505
|
|
||
|
|
|||
|
Клиентские программы, использующие корректный адрес электронной почты в качестве трассировочной информации без явного на то разрешения пользователя, может подвергать риску персональные данные пользователя. Любой, кто пользуется доступом к архивам специфического содержания с анонимным доступом (например, сексуальные извращения), очевидно нуждается в скрытности. Клиентским программам не следует передавать почтовый адрес пользователя без явного разрешения и следует предлагать пользователю опцию отказа от передачи трассировочной информации, показывая только IP-адрес и время.
Прокси-серверы с анонимным доступом помогут защитить приватную информацию, но следует принимать во внимание возможность организации в таких случаях DoS-атак.
Анонимные соединения чувствительны к перехвату с участием человека (man-in-the-middle attack) при которых передаваемая информация может просматриваться и изменяться. Клиентам и серверам настоятельно рекомендуется использовать внешние средства защиты данных.
Протоколы, которые не могут обеспечить явную регистрацию в системе (login) для анонимных пользователей, более уязвимы к вторжениям, связанным с некоторыми общепринятыми методами реализации. В частности, серверы Unix, которые предлагают пользователям регистрацию в системе (login) могут запускаться с правами пользователя root и переключаться на соответствующее значение user id после явной команды login. Обычно такие серверы отвергают все команды доступа к данным до явной регистрации в системе (login) и могут создавать безопасную среду с ограниченными возможностями (например, с помощью chroot в Unix) для анонимных пользователей. Если анонимный доступ не запрашивается явно, вся система доступа к данным может подвергнуться внешним атакам без возможности явного использования защитных мер. Протоколам, предлагающим ограниченный доступ к данным для анонимных пользователей, не следует предоставлять такой доступ без этапа явной регистрации в системе (login).
Общие вопросы безопасности SASL [SASL] применимы и к данному механизму.
Вопросы безопасности StringPrep [StringPrep] и вопросы безопасности Unicode [Unicode], рассмотренные в [StringPrep], также применимы к этому механизму. Вопросы безопасности UTF-8 [UTF-8] также применимы к данному механизму.
6. Согласование с IANA
Реестр SASL Mechanism [IANA-SASL] содержит запись для механизма ANONYMOUS, которая была обновлена IANA с учетом данного документа, обеспечивающего техническую спецификацию механизма.
To: iana@iana.org
Subject: Updated Registration of SASL mechanism ANONYMOUS
SASL mechanism name: ANONYMOUS
Security considerations: See RFC 4505.
Published specification (optional, recommended): RFC 4505
Person & email address to contact for further information:
Kurt Zeilenga <Kurt@OpenLDAP.org>
Chris Newman <Chris.Newman@sun.com> Intended usage: COMMON
Author/Change controller: IESG <iesg@ietf.org> Note: Updates existing entry for ANONYMOUS
“Трассировка” профиля [StringPrep], определенная в данном RFC, была зарегистрирована:
To: iana@iana.org
Subject: Initial Registration of Stringprep "trace" profile
Stringprep profile: trace Published specification: RFC 4505
Person & email address to contact for further information: Kurt Zeilenga <kurt@openldap.org>
7. Благодарности
Этот документ является пересмотром документа RFC 2245, который подготовил Chris Newman. Фрагменты синтаксиса, определенного в главе 1, были заимствованы из RFC 3629, автором которого является Francois Yergeau.
Данный документ является результатом работы группы IETF SASL.
8. Нормативные документы
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 42342, October 2005.
[IMAIL] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 44223, June 2006.
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ('stringprep')", RFC 3454, December 2002.
[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/).
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629 (also STD 63), November 2003.
9. Дополнительная литература
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4rev1", RFC 3501, March 2003.
|
|||
|
|
|||
|
2Перевод этого документа имеется на сайте http://rfc.com.ru. Прим. перев.
|
|||
|
|
|||
|
|
||||
|
|
Перевод RFC 4505
|
|||
|
|
||||
|
[IANA-SASL] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", <http://www.iana.org/assignments/sasl-mechanisms>.
Приложение A. Изменения по отношению к RFC 2245
Это приложение не является нормативным.
RFC 2245 позволяет клиенту включать необязательную трассировочную информацию в понятной человеку форме. RFC 2245 разрешает для этих строк только кодировку US-ASCII. В связи с интернационализацией сети Internet данный документ ограничивает такие строки набором символов Unicode в кодировке UTF-8. Определен профиль "stringprep" для точного указания символов Unicode, допустимых для включения в такие строки. Размер строки ограничен 255 символами, для кодирования каждого из которых может применяться от 1 до 4 октетов.
Кроме того, внесено множество редакторских правок.
|
||||
|
|
||||
|
Адрес редактора Kurt D. Zeilenga
OpenLDAP Foundation EMail: Kurt@OpenLDAP.org
|
||||
|
|
||||
|
Перевод на русский язык Николай Малых
|
||||
|
|
||||
|
Полное заявление авторских прав
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Интеллектуальная собственность
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).
|
||||
|
|
||||
|
4
|
||||
|
|
||||