Кратко

  • В режиме взаимной аутентификации клиент подписывал вызов сервера и собственное только что созданное случайное значение. Финальная подпись сервера покрывала оба, но включала третье: клиент уже знал первый вызов до того, как выбрал своё значение.
  • Третье значение связывало ответ сервера с новым случайным вкладом. Однако механизм не становился защищённым каналом: RFC 3163 не обеспечивает целостность или конфиденциальность и предупреждает, что активные атаки остаются возможными.

Значение, похожее на повтор

Сначала обмен выглядит избыточным. Сервер отправляет случайный вызов; клиент подписывает transcript с этим значением; затем сервер тоже подписывает transcript, где оно есть. Зачем финальному токену сервера ещё одно случайное число?

RFC 3163 «ISO/IEC 9798-3 Authentication SASL Mechanism» отвечает через порядок решений. Важно не количество сообщений, а то, какая сторона уже знала вызов другой стороны, выбирая собственное случайное значение. От этого зависит, что подпись может подтвердить об обмене.

Экспериментальный меморандум, опубликованный в августе 2001 года, определяет два семейства механизмов. 9798-U-<algorithm> аутентифицирует клиента перед сервером. 9798-M-<algorithm> добавляет взаимную аутентификацию: клиент подписывает вызов сервера, затем сервер подписывает вызов клиента. Оба режима используют асимметричные подписи и сертификаты X.509; описанная проверка включает обработку цепочки сертификатов.

Порядок подписанных значений

В обоих режимах сервер сначала создаёт R_B. Затем клиент выбирает R_A и отправляет TokenAB с данными сертификата и подписью над R_A и R_B. Клиент может также добавить идентификатор сервера. Сервер проверяет подпись, сверяет полученный R_B с ранее отправленным вызовом и проверяет идентификатор, если он присутствует.

В одностороннем режиме этот токен клиента завершает основной обмен. Взаимный режим добавляет ответ сервера: TokenBA2 содержит сертификат сервера и подпись над R_A, R_B и новым значением R_C. Клиент проверяет сертификат и подпись, сверяет первые два случайных значения с предыдущими шагами и проверяет необязательный идентификатор клиента.

Раздел 7 объясняет появление R_C. Если включить R_A в подписываемые клиентом данные, сервер не сможет получить от клиента подпись над данными, которые сам выбрал до начала механизма. Обратная сторона не симметрична: клиент знал R_B прежде, чем выбрал R_A. Серверу необходимо включить R_B в свою подпись, чтобы клиент мог проверить transcript, но одного этого значения недостаточно для такой же защиты сервера. Поэтому RFC 3163 включает R_C в подписываемый сервером TokenBA2.

Это конкретное обоснование RFC, а не общее доказательство защиты от любого посредника, повтора или активной атаки. Случайные значения должны формироваться криптографически стойким генератором; предсказуемые числа позволяют атаковать механизм. Третье значение отвечает на временную асимметрию, о которой говорит документ, но не исправляет свойства, не охваченные подписью.

Подпись не защищает сеанс

Граница указана прямо. RFC 3163 говорит, что механизм обеспечивает только аутентификацию. Он не защищает целостность последующих сообщений и не скрывает их содержимое. Раздел безопасности ограничивает защиту пассивным прослушиванием и отмечает, что активные атаки, в том числе перехват управления сеансом, остаются возможны. В примечании IESG критика сформулирована ещё жёстче: механизм несёт издержки PKI, но отказывается от целостности каждой передачи; TLS способен предоставить сходную функцию с преимуществами целостности.

Поля сертификата не объединяют эти уровни. authID в TokenAB может обозначать используемую для контроля доступа идентичность, отличную от личности подписанта сертификата. Принятие цепочки, аутентификация механизмом, сопоставление идентичности и решение приложения о разрешении — разные действия. Действительная подпись подтверждает, что некоторый ключ подписал охваченные данные; она не решает за приложение, что разрешать.

Пример IMAP в RFC также не демонстрирует взаимный режим. Это пример односторонней аутентификации 9798-U; RFC отдельно поясняет, что Base64-кодирование и символ + перед ответом принадлежат профилю IMAP, а не SASL-механизму. Иллюстрация не подтверждает развёртывание или совместимость реализаций.

Note 20 Лу Хэна используется здесь только как аналитическая линза: отделять проверяемые протоколом факты от более широких утверждений об идентичности и полномочиях. Соответствие случайных значений и проверенные подписи относятся к transcript; защиту канала и права приложения должны обеспечивать другие контроли. Эта трактовка не приписывается авторам RFC 3163.

Источники

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. Запись RFC Editor для RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. Реестр механизмов SASL IANA
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Лу Хэн, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile