Кратко

  • Если сервер принимает возобновление TEAP, RFC 9930 полностью исключает фазу 2; значит, билет должен сохранять связь с завершённой внутренней аутентификацией и с основанием текущей авторизации.
  • Если новые учётные данные нельзя связать с билетом, сервер обязан аннулировать его и заставить следующую сессию пройти полную аутентификацию.

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

Полный TEAP разделён на две фазы. В первой TLS создаёт защищённый аутентифицированный туннель. Во второй внутри него выполняются методы и передаются TLV: можно аутентифицировать машину, пользователя или обоих, выдать или заменить учётные данные, выполнить Crypto-Binding и обменяться защищёнными результатами. RFC 6678 задаёт требования к стандартному туннельному методу EAP, а RFC 3748 — роли и модель результата EAP. Готовность туннеля не доказывает завершение внутренней проверки.

Именно эту работу экономит возобновление. Если сервер согласен, RFC 9930 предписывает полностью обойти фазу 2. При отказе выполняется полное рукопожатие TLS, после чего обе стороны обязаны перейти ко второй фазе. Состояние может храниться на сервере или переноситься клиентским билетом по механизму RFC 5077. В TLS 1.3 сообщение NewSessionTicket из RFC 8446 создаёт связанное с PSK состояние для будущего соединения. Оно подтверждает возможность криптографического продолжения, но не неизменность права доступа.

Билет может появиться ещё до внутренней аутентификации. RFC 9427 отмечает, что TLS 1.3 разрешает отправить NewSessionTicket после Finished клиента, когда внутренний метод ещё не выполнялся. Клиент может получить билет, оборвать сессию и попробовать возобновление, так и не пройдя внутреннюю проверку. Сервер не должен разрешать такое возобновление без успешного завершения внутренней аутентификации. Лучше отложить выдачу; если библиотека TLS не позволяет, билеты неудачных сессий надо отбросить или аннулировать. Когда статус нельзя восстановить из билета, внутренняя аутентификация считается незавершённой и проводится до предоставления доступа.

Crypto-Binding тоже не заменяет авторизацию. После успешного внутреннего метода RFC 9930 требует Intermediate-Result и Crypto-Binding. Compound MAC связывает участников, туннель и последовательность методов, позволяя обнаружить подмену или разрыв связи. Он не выбирает VLAN, ACL, роль, состояние учётной записи или разрешённый сервис. Даже после успешного Result TLV узел может запросить дополнительное действие, если его политика не удовлетворена; решение сервера остаётся локальным.

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

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

Эксплуатационная запись должна восстанавливать всю цепочку: хеш билета или Session ID, издателя, время выдачи и истечения, исходную полную сессию, успех внутренней аутентификации, версии учётных данных и политики, контекст аутентификатора, изменения, повторную оценку и причину принятия, отказа или аннулирования. Отдельно фиксируются текущая авторизация, подтверждение применения со стороны NAS и наблюдаемый трафик или сервис. RFC 5247 описывает контекст ключей и идентичностей EAP, но не доказывает эти последующие факты.

Принцип минимальной начальной спецификации Heng Lu сохраняет границу: общий билет переносит только ограниченное состояние, необходимое для совместимости. Будущее решение остаётся локальным и подотчётным. Работающий код должен показать, какие данные он действительно использовал; билет, аутентифицированные данные, текущая политика, авторизация, применение и результат принадлежат разным слоям реальности. Надёжное возобновление умеет объяснить не только что было пропущено, но и почему это было безопасно.

Sources