Кратко

  • RFC 5281 делит EAP-TTLSv0 на TLS-рукопожатие и защищённую фазу данных. В типичной ветви без клиентского сертификата первая фаза аутентифицирует TTLS-сервер, а реальная личность и доказательство абонента поступают только во второй.
  • Надёжная квитанция доступа должна связать внешнюю маршрутную идентичность, проверку сертификата, внутренний метод и личность, решение AAA, авторизацию, доставку ключей, применение на точке доступа и наблюдаемый трафик. Ни один ранний успех не доказывает последующие результаты.

Finished означает готовность задать вопрос, а не готовый ответ

Первая фаза EAP-TTLSv0 — это TLS-рукопожатие. TTLS-сервер предъявляет сертификат, а клиент проверяет цепочку доверия, ожидаемое имя и политику. Сертификат клиента необязателен. После ChangeCipherSpec и Finished стороны могут защищать следующие сообщения на уровне TLS records.

В этот момент доказано лишь то, что у клиента есть зашифрованный канал до TTLS-узла, принятого им за правильный сервер. В обычной ветви без клиентского сертификата об абоненте решения ещё нет. Вторая фаза несёт AVP с реальным именем, парольным доказательством, внутренним EAP, сведениями о целостности, конфигурации или подготовке услуги.

Поэтому «TLS установлен» нельзя сокращать до «абонент аутентифицирован». Это также не доказывает принятие домашним AAA, выдачу актуальной авторизации, установку политики точкой доступа или прохождение полезного трафика. Разделение фаз сохраняет точный порядок полномочий.

RFC 5281 имеет статус Informational и описывает исторически развёрнутую практику. Его прежнее разрешение TLS 1.0 и 1.1 больше не является действующим руководством: RFC 8996 запрещает обе версии, а RFC 9427 обновляет вывод ключей и обработку результатов EAP-TTLS для TLS 1.3. Обновление криптографии не объединяет отдельные границы личности и исполнения.

Первое имя может быть только почтовым индексом маршрута

До создания туннеля точка доступа обычно просит EAP-Response/Identity в открытом виде. Ради приватности RFC 5281 позволяет не раскрывать настоящее имя пользователя: клиент может отправить пустое или анонимное значение, сохранив realm, необходимый для доставки запроса нужному провайдеру.

Внешняя идентичность отвечает на вопрос «в какой административный домен направить обмен?», но не на вопрос «кто запрашивает доступ?». Внутренняя идентичность появляется позже, внутри защищённого канала, и оценивается домашним органом AAA.

Один изменяемый столбец identity в журнале стирает это различие. Если внутреннее имя перезапишет внешнее, исчезнет маршрутная история. Если останется только анонимное внешнее значение, решение AAA будет ошибочно приписано заглушке. Следует хранить оба значения, их роли, наблюдателей, время и привязку к транзакции.

Туннель заканчивается на TTLS-терминаторе

TLS защищает внутренние AVP до TTLS-сервера. Там данные расшифровываются, после чего нужный материал аутентификации передаётся AAA/H через RADIUS, Diameter или иной транспорт AAA. Терминатор и домашний AAA могут быть одним компонентом, но могут быть разными системами с посредниками между ними.

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

Терминатор — не прозрачная труба. Он видит скрытый материал, переводит контексты AVP и решает, что пересылать. RFC 5281 отдельно предупреждает: одинаковый код AVP не обещает одинаковой семантики в EAP-TTLS и backend-протоколе. Атрибут нельзя копировать без понимания смысла в обоих контекстах. Совпадение формата не равно сохранению намерения.

Аутентификация может состоять из нескольких решений

AAA/H может послать challenge, принять или отклонить запрос. Challenge возвращается через TTLS-сервер в защищённый канал, и обмен продолжается. После всех шагов, требуемых политикой, терминатор отображает итог на внешний результат EAP.

Внутри могут последовательно работать несколько методов — например пароль, а затем токен. Должны ли пройти все или достаточно одного, определяет политика. Сообщение «внутренний метод успешен» неполно без порядка методов, каждого результата и версии правила, которое свело их к общему решению.

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

Обратная ошибка значительно опаснее: сохранить для возобновления сессию, которая успешно завершила TLS, но провалила аутентификацию пользователя. RFC 5281 называет последствия катастрофическими. Право на возобновление должно происходить из успеха абонента, а не из факта рукопожатия.

Возможность вывести ключ не даёт права его применять

Из секрета TLS и случайных значений можно вывести MSK и EMSK. После успешной аутентификации ключевой материал и параметры авторизации отправляются точке доступа по тракту AAA.

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

Надо спрашивать не только «создан ли ключ?». Квитанция должна показать исходный transcript и личности, решение, разрешившее выдачу, сессию точки доступа, которая приняла ключ, сопровождавшую политику и трафик, подтвердивший ожидаемый эффект.

Успех идёт к клиенту и исполнителю разными дорогами

После принятия абонента AAA/H клиент обычно видит EAP-Success. Точка доступа по транспортному пути AAA получает принятие, ключи и такие ограничения, как фильтры, логическая сеть, время и полоса. Результаты родственны, но имеют разных получателей и наблюдателей.

EAP-Success на клиенте не доказывает, что точка доступа применила задуманную политику. Получение Access-Accept не доказывает установку VLAN или фильтров. Даже действующая защита канала не гарантирует адрес, маршрут, DNS или доступность приложения.

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

Два успешных слоя ещё не связаны криптографически

RFC 5281 фиксирует ограничение базового EAP-TTLSv0: внешняя TLS-аутентификация и внутренняя аутентификация не имеют криптографической binding. Если одно доказательство пригодно и внутри, и вне туннеля, злоумышленник может перенаправить его в другой контекст. Документ советует избегать такого повторного использования и применять расширения, связывающие уровни.

Это не делает каждую сессию EAP-TTLS ложной. Но утверждение «оба шага успешны» слабее утверждения «оба шага доказанно относятся к одному аутентифицированному контексту». Гарантии позднейших туннельных методов нельзя незаметно приписывать базовой версии.

Квитанция доступа строится в порядке передачи полномочий

Для существенного решения о доступе нужно сохранить:

  • идентичности клиента, точки доступа, TTLS-сервера и AAA/H;
  • открытую внешнюю идентичность, маршрутный realm и путь прокси;
  • цепочку сертификата сервера, правило ожидаемого имени и результат проверки;
  • версию TLS, набор шифров, transcript и завершение первой фазы;
  • наличие клиентского сертификата и роль, которую он реально выполнил;
  • новую или возобновлённую сессию с унаследованными личностью и авторизацией;
  • внутреннюю идентичность, последовательность методов, challenge и результаты;
  • идентификатор транзакции TTLS–AAA и защиту транспортного участка;
  • принятие либо отказ, поколение политики и возвращённую авторизацию;
  • EAP-Success или EAP-Failure глазами клиента;
  • доставку MSK и связь с правильной сессией точки доступа;
  • фактически установленные фильтры, сеть, временные и полосовые ограничения;
  • защиту канала и наблюдаемый двусторонний трафик; и
  • результат приложения, необходимый для эксплуатационного утверждения.

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

Sources