Статус документа
В этом документе содержится спецификация протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.
Тезисы
OTP (One-Time-Password) обеспечивает полезный механизм аутентификации для случаев с ограниченным доверием к клиенту или серверу. В настоящее время OTP добавляется к протоколам специально подготовленным способом с эвристическим анализом. Данная спецификация определяет механизм OTP SASL, который обеспечивает простую и формализованную интеграцию со многими прикладными протоколами.
1. Как работать с документом
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY) в данном документе должны интерпретироваться в соответствии с документом "Ключевые слова для обозначения уровня требований в RFC" [RFC2119].
Данный документ предполагает знакомство читателя с OTP, расширенными откликами OTP [RFC2243] и SASL.
2. Использование
Механизм OTP SASL используется взамен механизма SKEY SASL. OTP является хорошим выбором для ситуаций работы с клиентами, которые не вызывают доверия (например, при подключении из Internet-кафе), поскольку одноразовый пароль предоставляет клиенту лишь однократную возможность подключения от имени пользователя. Удобно использовать OTP и в тех случаях, когда используется интерактивная система входа на сервер (login), поскольку скомпрометированная аутентификационная база OTP может быть использована только для атак по словарю (dictionary attack) в отличии от аутентификационных баз других простых механизмов типа CRAM-MD5.
Важно отметить, что при каждом использовании механизма OTP запись базы данных аутентификации для пользователя обновляется.
Данный механизм SASL обеспечивает формальный способ интеграции OTP с поддерживающими SASL протоколами, включая IMAP [RFC2060], ACAP, POP3 [RFC1734] и LDAPv3 [RFC2251].
3. Создание профиля OTP для SASL
OTP и расширенные отклики OTP [RFC2243] поддерживают множество опций. Однако для выполнения аутентификации требуется использование клиентом и сервером совместимых наборов опций. Данная спецификация определяет один механизм SASL — OTP. Для этого механизма применимы перечисленные ниже правила.
- Должен использоваться расширенный синтаксис откликов.
- Серверы должны поддерживать следующие 4 расширенных отклика OTP: "hex", "word", "init-hex" и "init-word". Серверы должны поддерживать отклики "word" и "init-word" для стандартного словаря; следует также поддерживать дополнительные словари. Для серверов недопустимо требовать от клиента поддержки любых дополнительных расширений или опций OTP.
- Клиентам следует поддерживать вывод для пользователя запросов (challenge) OTP и вводить записи OTP в формате multi-word. Клиенты также могут поддерживать прямой ввод парольных фраз и расчет откликов "hex" или "word".
- Клиенты должны индицировать отказы при аутентификации вследствие слишком малого значения полученного порядкового номера. Пользователю следует предлагать возможность сброса последовательности с использованием отклика "init-hex" или "init-word".
Требуется поддержка алгоритма MD5 и рекомендуется поддержка SHA1.
4. Механизм аутентификации OTP
Этот механизм не обеспечивает никакого уровня защиты.
Клиент начинает с передачи серверу сообщения, содержащего указанную ниже информацию.
- Идентификация полномочий (authorization identity). По умолчанию используется пустая строка идентификации. Это используется системными администраторами или прокси-серверами для входа с чужой идентификацией. Поле идентификации может включать до 255 и завершается октетом NUL (0). Предпочтительно использовать символы US-ASCII, хотя допускается и использование символов UTF-8 [RFC2279] для поддержки имен на отличных от английского языках. Использование других наборов символов кроме US-ASCII и UTF-8 запрещено.
- Идентификация подлинности (authentication identity). Идентификация личности, чья парольная фраза будет использоваться. Это поле может содержать до 255 октетов. Предпочтительно использовать символы US-ASCII, хотя допускается и использование символов UTF-8 [RFC2279] для поддержки имен на отличных от английского языках. Использование других наборов символов кроме US-ASCII и UTF-8 запрещено.
Сервер отвечает, передавая сообщение, содержащее запрос (challenge) OTP, как описано в спецификации OTP и расширенных откликов OTP [RFC2243].
Если клиент видит имя неизвестного ему алгоритма хэширования, он не сможет обработать парольную фразу, введенную пользователем. В такой ситуации клиент может запросить использование формата six-word, ввести последовательность прерывания, указанную в профиле SASL для используемого протокола, и попробовать другой механизм SASL или закрыть соединение и прервать аутентификацию. В результате такого поведения сервер ограничивается одни алгоритмом хэширования OTP на пользователя.
В случае успеха клиент генерирует расширенный отклик в формате "hex", "word", "init-hex" или "init-word". Клиенту не требуется завершать отклик пробелом или символами перевода строки и не следует включать ненужные пробельные символы.
Сервер должен быть устойчив к получению данных произвольной длины, но может прервать аутентификацию если размер введенных пользователем данных превышает разумное значение.
5. Примеры
В приведенных здесь примерах "C:" указывает строки, которые клиент передает серверы, а "S:" представляет строки, передаваемые сервером клиенту. "<NUL>" указывает нуль-символ ASCII (NUL).
Первый пример иллюстрирует использование механизма OTP с ACAP-профилем в SASL. В качестве парольной фразы используется This is a test.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "hex:5bf075d9959d036f"
S: a001 OK "AUTHENTICATE completed"
Следующий пример отличается от первого лишь использованием отклика в формате six-words.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "word:BOND FOGY DRAB NE RISE MART"
S: a001 OK "AUTHENTICATE completed"
В следующем примере для той же ситуации используется механизм OTP-SHA1.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-sha1 499 ke1234 ext"
C: "hex:c90fc02cc488df5e"
S: a001 OK "AUTHENTICATE completed"
Приведенный ниже пример отличается от предыдущего лишь использованием расширенного отклика в формате init-hex.
C: a001 AUTHENTICATE "OTP" {4}
C: <NUL>tim
S: + "otp-md5 499 ke1234 ext"
C: "init-hex:5bf075d9959d036f:md5 499 ke1235:3712dcb4aa5316c1"
S: a001 OK "OTP sequence reset, authentication complete"
Далее приведен пример использования механизма OTP с IMAP-профилем [RFC2060] в SASL. Парольная фраза — this is a test.
C: a001 AUTHENTICATE OTP S: + C: AHRpbQ== S: + b3RwLW1kNSAxMjMga2UxMjM0IGV4dA== C: aGV4OjExZDRjMTQ3ZTIyN2MxZjE= S: a001 OK AUTHENTICATE completed
Отметим, что отсутствие изначального отклика клиента и кодирование base64 являются характеристиками IMAP-профиля SASL. Запрос сервера имеет вид "otp-md5 123 ke1234 ext", а отклик клиента — "hex:11d4c147e227c1f1".
6. Вопросы безопасности
Данная спецификация не связана с вопросами безопасности за исключением тех, которые рассмотрены в спецификациях SASL, OTP и расширенных откликов OTP [RFC2243]. Краткое повторение этих вопросов приводится ниже.
Данный механизм не обеспечивает конфиденциальности сессий, аутентификации серверов и защиты от активных атак.
Данный механизм может быть подвергнут пассивным атак с использованием словаря. Для снижения вероятности успеха таких атак следует правильно выбирать парольные фразы.
Аутентификационная база данных сервера, требуемая для использования с OTP не должна содержать открытого текста или его эквивалентов.
Реализация сервера должна быть защищена от race-атак [RFC2289].
7. Поддержка символов других языков
Удаленный доступ является важным сервером и пользователей следует побуждать к применению в именах и парольных фразах только символов US-ASCII. Однако, если в именах или парольных фразах присутствуют символы, отличные от US-ASCII, их следует интерпретировать в соответствии с кодировкой UTF-8 [RFC2279].
Серверам, поддерживающим дополнительные словари, настоятель рекомендуется разрешать использование формата six-word со словами отличных от английского языков.
8. Согласование с IANA
Here is the registration template for the OTP SASL mechanism:
- SASL mechanism name: OTP
- Security Considerations: See section 6 of this memo
- Published specification: this memo
- Person & email address to contact for futher information: see author's address section below
- Intended usage: COMMON
- Author/Change controller: see author's address section below
This memo also amends the SKEY SASL mechanism registration [RFC2222] by changing its intended usage to OBSOLETE.
9. Литература
| [RFC2244] | Newman, C. и J. Myers, «ACAP — Application Configuration Access Protocol», RFC 2244, Ноябрь 1997. |
| [RFC2195] | Klensin, J., Catoe, R. и P. Krumviede, «IMAP/POP AUTHorize Extension for Simple Challenge/Response», RFC 2195, Сентябрь 1997. |
| [RFC2060] | M. Crispin, «Протокол IMAP v.4, rev.1», RFC 2060, Декабрь 1996. |
| [RFC2119] | Scott Bradner, «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, Март 1997. |
| [RFC2251] | Wahl, M., Howes, T. и S. Kille, «Lightweight Directory Access Protocol (v3)», RFC 2251, Декабрь 1997. |
| [RFC1321] | R. Rivest, «Алгоритм цифровых подписей MD5», RFC 1321, Апрель 1992. |
| [RFC2289] | Haller, N., Metz, C., Nesser, P. и M. Straw, «A One-Time Password System», RFC 2289, Февраль 1998. |
| [RFC2243] | Metz, C., «OTP Extended Responses», RFC 2243, Ноябрь 1997. |
| [RFC1734] | Myers, J., «POP3 AUTHentication command», RFC 1734, Декабрь 1994. |
| [RFC2222] | Myers, J., «Simple Authentication and Security Layer (SASL)», RFC 2222, October 1997. |
| [RFC2279] | Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 2279, Январь 1998. |
10. Адрес автора
Chris Newman
Innosoft International, Inc.
1050 Lakes Drive
West Covina, CA 91790 USA
EMail: moc.tfosonni@namwen.sirhc