Кратко

  • В редакции 04 проекта рабочей группы EMU от 30 сентября указано, что EAP-PPT не выводит ни MSK, ни EMSK и не должен сообщать несущему туннельному методу о собственном ключевом материале. Редакция 03 делила 128 октетов, полученных экспортёром внешнего TLS, на два ключа по 64 октета. Документ по-прежнему имеет состояние I-D Exists: это не RFC и не отчёт о развёртывании.
  • Сервер может принять токен Privacy Pass и разрешить доступ. Но предъявление токена не устанавливает секрет, общий только для предъявителя и сервера EAP-PPT. Завершившая TLS сторона сама способна вычислить экспортируемое значение. Если назвать его независимым ключом внутреннего метода, криптографическая связь будет выглядеть доказанной без дополнительного доказательства.

В журнале доступа легко свести к одной отметке три разных события: проверен сертификат сервера, погашен токен, передан ключ для соединения. Проект EAP-PPT предлагает использовать токен Privacy Pass внутри TLS-туннеля с проверкой сервера. Вопрос о принятии токена относится к внутреннему серверу EAP-PPT. Ключ для аутентификатора предоставляет туннельный метод EAP. Четвёртая редакция точнее разграничила эти обязанности, чем предыдущая.

Раздел 6.6 третьей редакции предлагал конкретную формулу. Экспортёр внешней TLS-сессии выдавал 128 октетов в контексте, включавшем тип EAP и значение токена. Первые 64 назывались Master Session Key, следующие 64 — Extended Master Session Key. В новом разделе 5.7 от этой формулы отказались: EAP-PPT не производит оба ключа и не должен представлять материал как собственный вклад в несущий метод. Это не утверждение, будто у TLS-туннеля исчез ключ. Изменилось то, кому можно приписывать его происхождение.

Проверка токена не равна согласованию секрета с предъявителем. Публично проверяемый вариант подтверждают открытым ключом эмитента. Для приватно проверяемого варианта используются данные, разделяемые эмитентом и сервером EAP-PPT, но не клиентом и сервером. Клиент передаёт предъявительскую учётную данность и доказывает возможность её предъявить; нового общего секрета между двумя концами EAP-PPT эта операция не создаёт. TLS-терминатор, напротив, знает сеанс, из которого выводился старый ключ. Наличие рассчитанных байтов само по себе ничего не говорит о независимой проверке связи токена с этим сеансом.

В таблице свойств безопасности новая версия ставит No напротив вывода ключей и криптографической привязки EAP-PPT, но сохраняет Yes для привязки к каналу. Последняя сопоставляет сетевую информацию со стороны клиента и сервера; она не превращается в секрет внутреннего метода. Обратная крайность тоже ошибочна: отказ от внутреннего ключа не отменяет проверки сертификата и ключевого материала, которые остаются ответственностью внешнего туннеля. Разрешение, идентичность сервера, источник ключа и согласованность параметров сети — четыре разных результата контроля.

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

Редакция 04 также заменяет JSON на TLV и уточняет правила разбора и обработки ошибок. Это самостоятельные изменения, не свидетельства уже случившейся атаки или сбоя конкретного продукта. Узкая новость в другом: авторы убрали претензию на ключ, который мог вычислить сам участник внешнего туннеля. В проекте ещё могут появиться новые правки, поэтому его выводы нельзя выдавать за окончательно утверждённый стандарт.

Источники