Кратко

  • RFC 9645 задаёт переиспользуемые YANG-группировки для идентичности клиента и сервера, проверки партнёра, параметров Hello и keepalive. Это минимальная общая конфигурация, а не полный журнал каждой сессии.
  • Настроенный сертификат, сырой открытый ключ или PSK подтверждает разрешённую возможность. Он не показывает, что запросил партнёр, что было предъявлено, прошла ли проверка, возобновлялась ли сессия и какой principal признало приложение.
  • Для доказуемого вывода нужна связанная квитанция: версия модели и применённой конфигурации, реальная ветвь handshake, идентичность партнёра, результат проверки, клиентская аутентификация, прикладная авторизация и итог операции.

Политика описывает пространство, а не событие

После инцидента команда показывает утверждённую конфигурацию и валидные ссылки на keystore и truststore. Сертификат сервера не истёк. TLS-библиотека поддерживает нужные версии и наборы шифров. Есть внешний PSK для аварийного режима. Каждый факт полезен, но ни один не устанавливает, каким способом была защищена решающая сессия.

RFC 9645 и не обещает такого результата. Он определяет ietf-tls-common, ietf-tls-client, ietf-tls-server и поддерживаемый IANA модуль перечисления наборов шифров. Клиентские и серверные группировки ограничены TLS-настройками; адреса, порты и способ создания транспорта остаются потребляющим моделям. Сам документ называет общий профиль «наименьшим общим знаменателем», а не полной моделью TLS.

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

Четыре ветви означают четыре разных доказательства

Сертификат, raw public key, PSK TLS 1.2 и внешний PSK TLS 1.3 — не просто четыре формата одного credential.

Сертификат включает цепочку, reference identity, время, Key Usage, алгоритмы подписи, trust anchor и локальную политику. Сырой ключ не несёт семантики сертификатной цепочки и обычно требует точного совпадения с доверенным ключом. PSK TLS 1.2 действует в рамках старой версии. Внешний PSK TLS 1.3 содержит external identity, hash и необязательные параметры context и target.

RFC 9257 предупреждает, что идентификатор PSK может быть видимым и связывать соединения, а участники общей PSK-группы способны выдавать себя друг за друга. RFC 9258 различает импортированный PSK с контекстом, связывающим внешнее provision, и context-free PSK. Успешный PSK поэтому может доказывать членство в группе, но не конкретное устройство.

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

Серверная и клиентская аутентификация независимы

В клиентской группировке client-identity отделена от server-authentication. Идентичность клиента необязательна: её может устанавливать верхний протокол. Даже при наличии настройки credential предъявляется на уровне TLS только по запросу сервера.

В серверной группировке server-identity отделена от необязательного client-authentication. Без него сервер не должен запрашивать клиентские credentials. При его наличии CA-сертификаты, точные end-entity сертификаты, raw keys и PSK образуют набор допустимых механизмов.

Фраза «mTLS включён» скрывает несколько переходов: способность запросить, фактический запрос, ответ клиента, проверка сервера, mapping в прикладной principal и разрешение операции. Один Boolean не отличает отсутствующий запрос от отсутствующего ответа, ошибки валидации или последующего отказа приложения.

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

Возобновление меняет состав доказательств

Действующая спецификация TLS 1.3, RFC 9846, разделяет версии, алгоритмы подписи, группы, key shares и PSK identities. Сервер выбирает совместимые PSK и cipher suite и проверяет binder, связывающий PSK с текущим transcript.

Binder защищает нынешний handshake, но не доказывает, что сертификат первоначальной сессии был снова предъявлен и проверен. Возобновление может наследовать ранее установленный контекст. Если отчёт берёт сертификат из статической конфигурации и показывает его рядом с «TLS success», он приписывает сессии отсутствующее доказательство.

Внешний PSK также отличается от resumption PSK. Первый поступает из внешнего provision, второй — из предыдущего соединения. При early data прикладные байты могут уйти до обычной точки подтверждения. Финальный успех не раскрывает replay- и authorization-границу важной операции.

Нужно явно записывать full, resumed или early-data режим, происхождение PSK и состояние контекста, не раскрывая ключ.

Версия и cipher suite не устанавливают личность

hello-params-grouping задаёт диапазон версий TLS и упорядоченный список suites. Опциональное operational state поддерживаемых алгоритмов описывает capability. Это свойства криптографического канала, а не заключение о партнёре.

Реестр IANA предупреждает, что алгоритмы со временем слабеют и регистрация не является рекомендацией. Семантика TLS 1.3 suites отличается от TLS 1.2. RFC 9325 даёт deployment guidance, а RFC 9852 требует поддержку TLS 1.3 для новых протоколов в своей области. Имя может оставаться доступным, когда локальная оценка уже изменилась.

Версия и suite должны быть в квитанции, но отдельно от identity mode, предъявленного материала и результата проверки. «TLS 1.3 с одобренным cipher» не говорит, использовался ли сертификат, raw key, external PSK или resumption.

От мандата конфигурации к факту выполнения

RFC 8342 разделяет intended configuration и operational state. RFC 8341 ограничивает изменение чувствительных узлов. RFC 9641 и RFC 9642 предоставляют переиспользуемые ссылки truststore и keystore. Каждый слой необходим, но не подменяет следующий.

Ссылка keystore может разрешаться, а handshake выберет другой credential. Truststore может быть доступен, хотя партнёр не прислал сертификат. Applied configuration может относиться к listener, которого соединение не достигло. TLS может проверить ключ, который приложение не свяжет с аккаунтом. Авторизованный principal всё равно может получить ошибку операции.

Различие Heng Lu между символической властью и работающей реальностью задаёт порядок: модель управляет словарём, change control — намерением, TLS stack — исполненной ветвью, приложение — значением и результатом.

Минимальная квитанция включает:

  • ревизию RFC/YANG, features, deviations и потребляющую модель;
  • применённую ревизию, происхождение datastore, утверждающего и время активации;
  • ветвь идентичности и реально разрешённые keystore/truststore ссылки;
  • защищённые fingerprints или версии загруженных credential и trust data;
  • session correlation ID и надёжные временные метки;
  • negotiated TLS version и cipher suite отдельно от identity mode;
  • full, resumed или early-data путь, происхождение PSK и контекст;
  • предъявленную идентичность, метод и результат проверки, неизвестные поля;
  • запрос, ответ, проверку и application principal клиентской аутентификации;
  • завершение, alerts, retries и fallback history;
  • прикладную авторизацию, операцию, критерий приёмки и результат;
  • владельца окончательного утверждения.

Ни один источник не предписывает единый формат. Это эксплуатационная конструкция из нормативных границ. Она поддерживает узкий вывод: в этой сессии и операции при этой применённой конфигурации была исполнена эта ветвь, проверена эта идентичность, создан этот principal и получен этот результат.

Источники

  1. Минимальная начальная спецификация
  2. Слои реальности и символическая власть
  3. Приоритет работающего кода
  4. История RFC 9645
  5. Информационная страница RFC 9645
  6. RFC 9645 HTML
  7. RFC 9645 в тексте
  8. RFC 9645 XML
  9. Встроенные errata RFC 9645
  10. Параметры TLS IANA
  11. YANG-модуль IANA для TLS cipher suites
  12. RFC 9641: модель truststore
  13. RFC 9642: модель keystore
  14. RFC 9846: действующий TLS 1.3
  15. RFC 9852: TLS 1.3 для новых протоколов
  16. RFC 9325: безопасное развёртывание TLS
  17. RFC 9257: рекомендации по external PSK
  18. RFC 9258: импорт внешних PSK
  19. RFC 8341: контроль доступа к конфигурации
  20. RFC 8342: архитектура management datastores