Кратко

  • Мастер-значения RFC 3079 служили только входом следующего вывода. Контексты передачи и приёма инициализировали разные переходные ключи с учётом роли и направления.
  • Совпадение с тестовым вектором доказывало арифметику, но не одинаковую первую аутентификацию, взаимно дополняющие направления, одну силу MPPE или доставку данных приложению.

Главный по имени, промежуточный по функции

Спецификация прямо говорит: мастер-ключи сессии никогда не шифруют и не расшифровывают данные. В MS-CHAP-2 двойной хеш пароля вместе с NT-Response создавал мастер-значение. GetAsymmetricStartKey выбирал ветвь по двум признакам — передача или приём, клиент или сервер. GetNewKeyFromSHA формировал переходный ключ для нужной таблицы RC4.

Запись «master key derived» поэтому заканчивалась слишком рано. Она не показывала ветвь, направление и выбор другого конца. Оба устройства могли успешно вычислить локальные значения и совместно отказать из-за перевёрнутой роли.

RFC 3079 вышел в марте 2001 года как Informational RFC и давал третьим сторонам открытую основу совместимости с продуктами Microsoft. Переговоры CCP, формат MPPE и смена ключей в сессии относились к RFC 3078. Публикация не делала документ стандартом Интернета и не доказывала внедрение.

Три источника не теряли происхождение

MS-CHAP-1 выводил 40- и 56-битные ветви из хеша LAN Manager, а 128-битную — из хеша Windows NT и challenge. MS-CHAP-2 использовал линию Windows NT и NT-Response для всех трёх сил. EAP-TLS начинал с экспортированного секрета TLS.

Общий результат MPPE не превращал эти источники в одно доказательство. Нужно было сохранять семейство аутентификации, инициатора вызова, первое выбранное событие, challenge/response или поколение TLS и целевой link. Восемь октетов могли означать 40 или 56 эффективных бит; шестнадцать — относиться к разным сессиям.

RFC 2759 определял значения MS-CHAP-2, RFC 2433 — предшествующую схему, RFC 2716 — EAP-TLS в PPP. Они задавали входы, а не доказывали состояние CCP Opened.

«Первая аутентификация» была состоянием

Начальные ключи обоих направлений выводились из учётных данных peer, начавшего вызов. При наличии challenge использовался challenge первой аутентификации. Это правило сохранялось при двусторонней аутентификации и для каждого link в multilink bundle.

В распределённой системе слово «первая» легко исчезает. Сервис идентификации хранит последний успех, координатор объединяет links без исходного challenge, резервное chassis получает имя и флаг успеха без поколения. Формула остаётся верной и выдаёт неверный результат из неверной истории.

Для multi-chassis multilink RFC возлагал на реализацию обязанность создать правильные ключи на всех машинах. Алгоритм не распространял происхождение. Настоящий идентификатор включал событие аутентификации, роль, link и поколение.

Передача здесь была приёмом там

Метки GetAsymmetricStartKey связывали концы крест-накрест: отправка сервера соответствовала приёму клиента, а обратная пара — наоборот. В разделе EAP-TLS сказано прямо: send key одной стороны является receive key другой.

Поле send_key нельзя было копировать в одноимённое поле peer. Имя локально, отношение двустороннее. Квитанция должна соединять endpoints, роли, локальное и удалённое направления, fingerprint поколения и переходного ключа, не раскрывая секрет.

Сила также была преобразованием. 40 и 56 бит использовали восемь октетов; первый режим заменял константами три начальных октета, второй — один. 128 бит использовал шестнадцать. EAP-TLS требовал дополнить короткое значение нулями слева или обрезать длинное. Одинаковая итоговая длина не доказывала одинаковое происхождение.

Тестовые векторы проверяли вычисление, а не живую сессию, безопасную передачу или итог переговоров. RFC предупреждал, что 40-битный начальный ключ MS-CHAP-1 повторяется при тех же credentials. Это исторический разбор, а не современная рекомендация RC4 или MS-CHAP.

После вывода ещё не было услуги

RFC 3078 требовал фазу PPP Network-Layer Protocol и CCP Opened до MPPE-трафика. RFC 2548 описывал доставку направленных ключей через RADIUS и хранение у proxies. RFC 1661 разделял фазы PPP.

Успех аутентификации, доставка секрета, привязка к link, сопоставление направлений, переговоры CCP, синхронная расшифровка и обработка приложением были разными квитанциями. Подход слоёв реальности Lu Heng не позволяет словам «master», «send», «authenticated» и «128-bit» заменить исполненные переходы.

RFC 3079 сделал минимальное происхождение воспроизводимым. Успешный вывод разрешал следующую проверку, но не доказывал всю услугу.

Источники