Кратко

  • RFC 2444 заменил самодельный разбор одноразовых паролей в приложениях именованным механизмом SASL с согласованными форматами обмена.
  • Механизм OTP выполнял аутентификационный обмен, но не предоставлял уровень безопасности, конфиденциальность сеанса, аутентификацию сервера или защиту от активных атак.

Фраза «вход выполнен» отвечает лишь на часть вопроса: кто доказал владение нужным фактором. RFC 2444, опубликованный в 1998 году, занялся способом встроить One-Time Password (OTP) в Simple Authentication and Security Layer (SASL). До этого приложения добавляли OTP ситуативно, а входные данные разбирали эвристически. Именованный механизм должен был дать прикладным протоколам общий вызов вместо множества несовместимых локальных парсеров.

Стандартизация интерфейса не означала защиты всей связи. RFC 2222 отделял аутентификацию от необязательного согласования уровня безопасности для последующего обмена. RFC 2444 прямо указывает, что его механизм OTP такого уровня не предоставляет. Он также не обеспечивает конфиденциальность сеанса, аутентификацию сервера и защиту от активных атак. Поэтому положительный ответ на запрос аутентификации подтверждает результат данного обмена, но ничего сам по себе не говорит о шифровании следующих команд или о том, кто именно ответил клиенту.

Профиль опирается на систему OTP из RFC 2289 и расширенные ответы из RFC 2243. Сервер обязан поддерживать hex, word, init-hex и init-word. Первые два формата передают ответ, а формы с init- также сбрасывают счётчик последовательности. Поддержка MD5 обязательна, SHA-1 рекомендована. Клиент должен сообщать о слишком низком номере последовательности и, по рекомендации RFC, предлагать пользователю сброс. Каждое использование обновляет запись в базе аутентификации. Общие форматы делают обмен предсказуемее, но синхронное изменение состояния и совместимость остаются частью внедрения.

В качестве сценария RFC 2444 приводит недоверенный клиент, например общедоступный терминал. Перехваченный OTP должен дать такому устройству только одну возможность действовать от имени пользователя. Это не защищает сеанс, который возникает после ввода пароля. Скомпрометированная база аутентификации, как сказано в документе, уязвима для словарного перебора, хотя её содержимое не обязано быть эквивалентом открытых паролей. Спецификация упоминает и пассивную словарную атаку, а реализациям предписывает защищаться от гонки, описанной в базовой OTP-системе. Одноразовость ограничивает повтор, но не устраняет остальные риски.

В SASL отдельно существуют идентичность аутентификации и идентичность авторизации. Первая связана с предъявленными учётными данными; вторая определяет запрашиваемые права. При работе через представителя эти значения могут различаться. Если идентичность авторизации не задана, сервер может вывести её из учётных данных. Следовательно, верный OTP — ответ на вопрос о факторе, а не решение о том, какие действия разрешены. Название механизма, синтаксис вызова, кодирование токенов конкретным протоколом, защита транспорта, удостоверение сервера и выдача прав принадлежат разным уровням.

RFC 2444 обновил редакцию SASL 1997 года и объявил предполагаемое применение механизма S/Key в SASL устаревшим. Позже RFC 4422 заменил первоначальный документ SASL; RFC 5034 описал профиль POP3, а RFC 5802 определил другой механизм — SCRAM. Эти документы показывают развитие рамки, но не доказывают повсеместного применения RFC 2444 и не делают его криптографические рекомендации 1998 года актуальными сегодня. Стандарт фиксирует нормативный замысел, а не статистику установленных реализаций.

Исторический результат был узким и полезным: приложения получили формально заданный способ вызвать OTP вместо локальной трактовки пароля. Остальные обязанности никуда не исчезли. Разработчик протокола описывает перенос токенов SASL; автор реализации поддерживает целостность счётчика; оператор защищает канал после входа; приложение связывает удостоверенную идентичность с полномочиями. «Одноразовый» описывает повторное использование ответа, а не безопасность сеанса.

Источники