Кратко

  • draft-ietf-emu-eap-ppt-04 удаляет 128 октетов, которые предыдущая редакция получала из внешнего TLS-экспортера, и прямо говорит: EAP-PPT не создает ни MSK, ни EMSK.
  • Privacy Pass — предъявительский токен внутри туннеля. Терминатор видит этот токен и вычисляет тот же экспортируемый результат, поэтому байты не доказывают тождество предъявителя и TLS-конечной точки.

Криптографический экспортер исправно сделал то, что от него требовалось: вернул 128 октетов. Ошибка заключалась не в вычислении, а в смысле, которым протокол мог наделить результат.

Редакция 03 Extensible Authentication Protocol (EAP) Using Privacy Pass Token выводила эти октеты из внешнего TLS-туннеля с меткой EXPORTER_EAP_PPT_Key_Material. В контекст входили тип EAP и погашенный токен. Реализация могла представить результат как Master Session Key и Extended Master Session Key, якобы полученные от EAP-PPT.

Редакция 04 от 30 сентября удаляет эту конструкцию. Теперь EAP-PPT не выдает MSK или EMSK, и реализация не должна передавать туннельному методу какой-либо ключевой материал EAP-PPT. Удаление не отнимает реальную защиту. Оно не дает убедительно выглядящим байтам свидетельствовать о связи, которой механизм не установил.

Предъявительский токен не вносит исключительного секрета

EAP-PPT работает как внутренний EAP-метод. Участник вне протокола получает Privacy Pass у эмитента, входит в сервер-аутентифицированный TLS-туннель другого EAP-метода и отправляет токен серверу EAP-PPT для погашения.

Публично проверяемый токен валидируется открытым ключом эмитента. Частно проверяемый — материалом, общим для эмитента и сервера EAP-PPT. Ни тот, ни другой вариант не создает нового общего секрета между участником и сервером. Участник подтверждает владение передачей переносимого предъявительского удостоверения; сервер решает, принимать ли его.

TLS-экспортер относится к внешнему сеансу. Любая сторона, завершившая туннель, способна получить тот же результат. Токен идет внутри этого туннеля, поэтому терминатор знает и значение токена, включенное в контекст. Такой контекст различает отдельные выводы, но не добавляет вход, скрытый от терминатора.

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

Внешний TLS не удостоверяет внутреннего участника

В TEAP это различие особенно важно. Crypto-Binding TLV может объединять материал туннеля с материалом внутреннего метода. Если EAP-PPT выдает в качестве внутреннего ключа значение, целиком полученное из того же туннеля и видимого терминатору токена, итог выглядит как объединение двух независимых доказательств, хотя одна сторона знает все входы.

Редакция 04 прямо описывает сбой. Старое значение позволило бы туннельному методу вычислить Crypto-Binding TLV, не обеспечив криптографической связи EAP-PPT с туннелем. На схеме два участника вносят вклад, а в действительной структуре секретов вкладчик один.

Исправленная граница проста. EAP-PPT авторизует участника погашением токена, но не создает ключи канала. Ключевой материал канала приходит от внешнего туннельного EAP-метода. Если система по-прежнему показывает MSK или exporter-подобный ключ для EAP-PPT, это не дополнительная гарантия, а возвращение удаленной двусмысленности.

Внутренний метод без ключа меняет модель ретрансляции

Без внутренней криптографической привязки первой защитой от relay становится строгая проверка сертификата сервера. Если злоумышленник заставит участника принять свой TLS-туннель, он сможет переслать обмен EAP-PPT настоящему сервису, увидеть предъявительский токен и погасить его ради собственного доступа.

Поэтому черновик требует строгой, специфичной для сети валидации сертификата EAP-сервера. Участник должен сопоставить ожидаемое имя, отклонять ошибку, а не просить пользователя сделать исключение, и не полагаться на trust on first use. Поле origin_info в challenge Privacy Pass, если оно заполнено и сверено с идентичностью сертификата, ограничивает замену challenge, но не создает внутренний ключ.

Размещение серверов тоже определяет доверие. Совмещение EAP-сервера и EAP-PPT-сервера устраняет одну разделенную поверхность внутри провайдера. Разнос серверов Phase 1 и Phase 2 не рекомендуется без явно защищенной связи и межсерверного протокола. Это вопрос ответственности, а не просто топологии.

Channel binding способен выявить расхождение между сетью, в которую, по мнению участника, он вошел, и authenticator, известным серверу. Короткоживущие токены ограничивают окно ущерба; обнаружение двойного расходования может показать relay постфактум. Эти меры полезны, но не превращают удаленный вывод экспортера в доказательство непрерывности владельца.

Токен может быть потрачен до вердикта о контексте

В редакции 04 также закреплен порядок событий, который легко потерять в общей метрике успеха. После удачного погашения сервер EAP-PPT может отправить EAP-Request/PPT-Channel-Binding до EAP Success. Запрос можно пропустить, если предыдущий EAP-метод уже предоставил подходящие сведения.

Получив запрос, участник знает, что токен принят и уже потрачен. Последующие события не отменяют это. Некорректный ответ, неверный контекст, ошибка EAP или отказ в доступе не делают токен пригодным для повторного использования. Правила повтора до погашения с этого момента не действуют.

«Токен потрачен» — узкая квитанция. Она подтверждает погашение, но не успешный channel binding, не EAP Success, не установку внешних ключей, не разрешение RADIUS/NAS и не реально работающий доступ.

Считать расходование подключением — значит слить несколько самостоятельных решений. Принимать EAP Success за доказательство того, что один субъект владел токеном и завершал туннель, — значит повторить в телеметрии преувеличение, которое редакция 04 убрала из ключевой схемы.

Редакция 04 меняет не только кодирование

Новая версия заменяет JSON на TLV в стиле TEAP и переносит структуры Privacy Pass напрямую, без строк base64url. Добавлены No-Suitable-Token TLV, правила длины, дубликатов, полного потребления полей и одного уровня вложенности, политика M-bit для неизвестных TLV и тестовые векторы на уровне октетов.

Код ошибки 9 отделяет некорректное сообщение без погашения от правильно сформированного токена, который не прошел проверку. Разница определяет возможность повторного использования. Документ расширяет анализ relay и уточняет рекомендации для публичных, частных и федеративных типов токенов.

Точная спецификация формата не служит доказательством внедрения. Это активный Internet-Draft рабочей группы EMU с предполагаемым статусом Proposed Standard. В Datatracker все еще указано I-D Exists; нет ответственного Area Director, shepherd или telechat. Это не RFC, а замороженные источники не подтверждают реализацию, совместимость, производительность или принятие.

Эксплуатации нужно связывать разные квитанции

Проверяемая система раздельно сохраняет настроенную сеть и ожидаемое имя EAP-сервера; проверенный сертификат, trust anchor и фактическую TLS-конечную точку; challenge и origin_info; тип токена, ключ эмитента и дайджест challenge; результат и время погашения; источник и вердикт channel binding; EAP Success или Failure; внешние ключи канала; решение RADIUS/NAS; наблюдаемый доступ.

Сертификат отвечает, какой сервер принял участник. Погашение — прошла ли проверку учетная ценность. Channel binding — совпал ли сетевой контекст сторон. Результат EAP завершает протокольную фазу. Только решение NAS и трафик показывают, был ли доступ предоставлен и работал ли он. Одно поле «аутентифицирован» не содержит этих причинных связей.

Вывод не в том, что спецификации не важны. Редакция 04 ценна именно отказом приписать убедительному результату лишний авторитет. Действующая система должна сохранить связи, которые удаленные 128 октетов никогда не доказывали.

Источники