Кратко

  • draft-ietf-tls-pake-02 описывает сессионную интеграцию PAKE, но не задаёт регистрацию, восстановление, ротацию, миграцию схем и уничтожение старых verifier.
  • Гибридный TLS может защитить записанный трафик, тогда как классический PAKE-транскрипт сохраняет будущий риск восстановления долгоживущего пароля; смена пароля не стирает прошлые сообщения.

Служба сменила пароль пользователя и заменила verifier. Панель отметила инцидент закрытым. Но сетевой архив продолжал хранить годы классических PAKE-сообщений, а кэш внешних импортированных PSK не имел понятного срока жизни.

Изменилась запись. История её использования осталась.

Ревизия 02 draft-ietf-tls-pake опубликована 6 июля 2026 года и истекает 7 января 2027 года. Это активный Informational Internet-Draft рабочей группы TLS, а не RFC, окончательный реестр, доказательство внедрения или аудит. Сам документ предупреждает, что значимый анализ безопасности ещё не завершён.

Пароль нельзя подставить вместо полноценного PSK

Механизм PSK binder в TLS 1.3 рассчитан на секрет с высокой энтропией. Если использовать человеческий пароль напрямую, наблюдатель сможет проверять словарные кандидаты. Расширение pake переносит сообщения парольного обмена, а полученный секрет объединяется с обычным эфемерным key share в расписании ключей TLS.

Клиент передаёт пару identity и отсортированный набор предложений схем. Сервер выбирает общую схему и ищет регистрационный материал. Совпадение алгоритма не означает наличие записи; при отсутствии записи сервер может выдать правдоподобную симуляцию.

Поэтому эксплуатационный журнал должен различать предложение, выбор, lookup, Finished и выдачу прикладных данных. Одного поля PAKE success недостаточно даже внутри одной сессии.

Finished подтверждает текущий transcript

Сервер аутентифицирует клиента только после проверки клиентского Finished. До этого он не должен отправлять прикладные данные. Симулированный ответ для неизвестной identity специально может дойти до позднего отказа.

Успешный Finished подтверждает владение нужным ключевым материалом для конкретного transcript. Он не доказывает, кто создал регистрацию, кто разрешил reset, действительна ли учётная запись и имеет ли она право на операцию.

Эти ограничения важны при ротации. Новый verifier может корректно аутентифицировать будущие сессии, но ничего не сообщает о том, где остался старый материал и какие приложения всё ещё принимают прежнюю схему.

Жизненный цикл регистрации находится вне проекта

Документ предполагает, что пароль либо производные данные уже provisioned. Он не описывает первичную проверку личности, восстановление, отзыв, смену соли, перенос между схемами, период параллельного действия и подтверждение удаления.

Организация должна сама вести версию регистрационной записи, authority, одобрившую изменение, дату активации, дату прекращения старой версии и доказательство уничтожения. Иначе две схемы могут действовать одновременно без видимой причины.

Reset также не равен восстановлению доверия. Если злоумышленник получил старую базу verifier или записал PAKE-транскрипты, новый пароль закрывает лишь некоторые будущие пути. Необходимо перечислить, какие активы были скомпрометированы и какие остаются полезными атакующему.

Старый transcript нельзя отозвать

Обычный TLS key share может быть гибридным или постквантовым и защищать записанный прикладной трафик от будущей расшифровки. Классическая PAKE-схема имеет собственные математические предпосылки.

Если будущий квантовый компьютер позволит извлечь пароль из собранных PAKE-сообщений, сохранённый transcript уже нельзя заменить. Ротация сегодня ограничит период будущего злоупотребления, но не отменит факт раскрытия прежнего секрета и его использования в других системах.

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

OQUAKE, OQUAKE+ и гибридный внешний вариант пытаются адресовать отдельные постквантовые свойства, но зависят от активных исследовательских проектов. Нельзя помечать архив безопасным только потому, что новое соединение предлагает такую схему.

Внешний PAKE создаёт ещё один срок жизни

Внутренние схемы помещают сообщения в ClientHello и ServerHello. Более длинный PAKE выполняется перед TLS, а его результат импортируется как PSK по RFC 9258.

Импортированный ключ и identity могут жить дольше одного соединения, если приложение не установило одноразовость и срок. После смены пароля старый импортированный результат может остаться в памяти процесса, пуле соединений или распределённом кэше.

Успешный TLS handshake подтверждает владение импортированным ключом, но не доказывает, что он создан после последней ротации. В correlation receipt нужны версия регистрации, хэш внешнего transcript, import context, момент создания и потребляющее соединение.

RFC 9258 обеспечивает разделение по протоколу, KDF и контексту. Политику истечения и атомарного потребления всё равно задаёт приложение.

Identity нельзя свернуть в одно имя

PAKE server_identity отделена от SNI. Сертификат, если клиент потребовал его через signature_algorithms, добавляет ещё одну identity. Регистрационная учётная запись и прикладной principal могут быть четвёртым уровнем.

При ротации связь между ними может измениться: сервис мигрирует hostname, аккаунт переносится между доменами, verifier регистрируется под новой identity. Если журнал хранит только нормализованное имя, невозможно понять, к какой версии относился transcript.

Нужно сохранять исходные значения и правило отображения, не объявляя одно из них универсальной личностью. Сертификат доказывает контроль ключа под PKI-политикой, а не правомерность reset пароля.

Симуляция требует стабильного поведения после ротации

Сервер может симулировать PAKE-ответ, когда запись отсутствует. После удаления старой записи поведение должно быть неотличимо от обычной ошибки пароля, иначе момент удаления раскрывает статус учётной записи.

Различия в кэше, базе, CPU, alert или rate limit особенно вероятны во время миграции, когда часть узлов видит новую версию, а часть — старую. Наблюдение должно сравнивать кластеры и версии, а не только среднее по сервису.

Ротация завершена лишь тогда, когда все узлы применяют новый статус, старые импортированные ключи истекли, а внешнее поведение не создаёт новый оракул.

Управлять надо не паролем, а всей цепочкой хранения

PAKE снижает риск передачи низкоэнтропийного секрета и даёт сильную сессионную привязку. Но секрет оставляет производные: verifier, salts, transcript, импортированные identity, audit receipts и резервные копии.

Каждый объект имеет владельца, срок хранения и план уничтожения. Если организация ротирует только строку пароля, большая часть доказательной и атакующей поверхности остаётся без управления.

Зрелая программа показывает не «пароль изменён», а какие записи активны, какие transcript уже необратимо опубликованы, какие ключи отозваны, какие системы повторно использовали секрет и когда исчез последний путь старой версии.

Источники