Кратко
- В RFC 9813 идентификатор PSK заменяет IP-адрес как ключ поиска отношения клиента RADIUS/TLS, но приходит открыто и до аутентификации: совпадение выбирает кандидата, а не доказывает его подлинность.
- Проверяемая эксплуатация раздельно фиксирует допуск по сети, проверку строки, поколение таблицы, диапазон конкретного клиента, доказательство PSK, целостность RADIUS, политику, возобновление, действие NAS и фактическую услугу.
Классическая таблица клиентов RADIUS выбирала строку по адресу источника. В ней находились shared secret и нередко разрешения устройства. Адрес одновременно обозначал отношение и ограничивал место появления запроса.
NAT показывает несколько клиентов под одним внешним адресом, а мобильность — одного клиента под несколькими. Широкий диапазон возвращает доступность, но не точность; копии строк для всех возможных адресов быстро расходятся с реальностью.
RFC 9813, опубликованный в июле 2025 года как BCP 243, добавил правила TLS-PSK для RADIUS поверх TLS и DTLS. PSK Identity становится идентификатором клиента вместо исходного IP. Однако меняется только ключ поиска. Адрес остаётся фильтром, строка остаётся недоверенной до проверки ключа, а успешный TLS не означает ни разрешения RADIUS, ни выполненного доступа.
Селектор появляется раньше доказательства
Серверу нужно выбрать PSK до его проверки, поэтому клиент сначала передаёт Identity. Значение видно открыто и поступает от ещё не аутентифицированного узла. Любой достигший listener отправитель может выдумать правдоподобное имя. Осмысленная строка раскрывает организацию или площадку; непрозрачная пользовательская часть либо формат Network Access Identifier уменьшает утечку, но не делает значение секретом.
Найденная запись доказывает только совпадение с сохранённым состоянием. Она не доказывает владение PSK, допустимый источник, право на тип RADIUS-запроса или физическое устройство. Метрика «известный идентификатор = аутентифицированный клиент» переносит старую ошибку доверия IP в новое поле.
Недоверенная строка не должна напрямую касаться базы
Identity может содержать неверный UTF-8, NUL, метасимволы SQL, LDAP, REST или shell и достигать 65 535 октетов. Прямая конкатенация превращает протокольный выбор в поверхность инъекции. Безопасный порядок ограничивает длину, определяет пространство имён, валидирует форму, применяет версионированную нормализацию, экранирует под реальный интерфейс и закрывает соединение при ошибке.
Нормализация не вправе незаметно объединить две административные личности. Квитанция хранит ограниченный хеш сырого ввода, результат, каноническое значение, версию правила и ID выбранной строки. Код отказа, поколение парсера и наблюдаемый диапазон дают расследованию данные без тиражирования текста атакующего.
Строка таблицы описывает двустороннее отношение
Логическая таблица TLS-PSK может связать разрешённые сети, Identity, PSK, альтернативные TLS-реквизиты и требование сертификата. После TLS продолжает действовать клиентская политика RADIUS. Единица учёта — не универсальная личность устройства, а отношение конкретного клиента к конкретному серверу.
Одно устройство может иметь независимые отношения с основным и резервным серверами. RFC 9813 требует поддержки уникальных Identity и PSK для каждого возможного отношения. Повторное использование остаётся местным решением, но расширяет симметричные полномочия: при одном PSK у двадцати клиентов каждый способен создать одинаковое доказательство, а отзыв одного затрагивает всех. Утечка со стороны клиента может позволить имитировать сервер, поэтому PSK плохо подходит несвязанным организациям.
Общий слой требует возможности изоляции, а график ротации и топология остаются у оператора — граница, соответствующая Minimum Initial Specification.
IP-адрес остаётся независимой координатой
До разбора Identity сервер отклоняет источники вне общих разрешённых диапазонов. После выбора отношения проверяется его собственный диапазон. Первый шаг ограничивает экспозицию listener, второй отвечает, допустимо ли данное отношение из наблюдаемого места.
Внутри этих рамок несколько Identity могут делить NAT-адрес, а одна Identity — менять адреса. Сетевая проверка свидетельствует о наблюдаемом местоположении, PSK — о владении симметричным реквизитом. Вместе они всё ещё не доказывают конкретного человека или аппарат.
TLS PSK и RADIUS shared secret имеют разные роли
TLS PSK аутентифицирует отношение канала. Секрет RADIUS участвует в проверках вложенного протокола. RFC 9813 запрещает одинаковое значение и требует отклонять такую конфигурацию. Один PSK также не должен переходить между TLS 1.3 и прежними версиями. RFC 9258 связывает импортируемый PSK с версией, KDF и контекстом.
Один экранный параметр «секрет площадки» стирает границу. Интерфейс обязан раздельно показывать роли и несекретные поколения, предотвращать равенство без логирования ключей и перечислять зависимости. Зелёный handshake не заменяет проверку RADIUS и решение авторизации.
Ротация создаёт новое поколение отношения
Поскольку Identity находит PSK, они меняются вместе. Замена ключа под прежним именем делает неразличимыми устаревший клиент, ошибку доставки и атаку. Управляемая ротация создаёт новое поколение, фиксирует его первое использование, ограничивает перекрытие, отмечает последний успех старого и отключает его. Доставка — не завершение; завершение — отзыв прежних полномочий.
Last seen помогает искать спящие клиенты, но молчание означает и вывод, и поломку, и сезонность, и кражу. Автоматическому отзыву нужны владелец, порог, исключение и восстановление.
Возобновление принадлежит другому пространству имён
TLS 1.3 также применяет PSK и Identity для возобновления, но их создаёт TLS-подсистема. Это не статические имена клиентов. RFC 9813 не рекомендует возобновление в данном режиме. Если переходный период требует его, непрозрачные билеты и административные Identity хранятся отдельно; неизвестное значение закрывает соединение, а коллизия не пересекает таблицы.
Возобновление не увековечивает разрешение. Сервер восстанавливает идентичность и политику исходного полного handshake, повторно оценивает изменившийся источник и возвращается к полному handshake при ненадёжном кеше. Срок билета и кеша не превышает семи дней.
Объект аудита — цепочка решений
Для принятого соединения должны восстанавливаться общий диапазон, проверка и нормализация, точное поколение клиентской таблицы, диапазон отношения, версия TLS и KDF, доказательство PSK, кеш возобновления, проверки RADIUS, локальная политика, действие NAS и наблюдаемая услуга. Успех шага не гарантирует следующего.
Running-Code Primacy требует доказательства от работающих парсера, lookup и policy engine, а не от снимка конфигурации. On Reality Layers не позволяет символу «известная Identity» говорить от имени криптографии и результата.
RFC 9813 не передаёт трон от IP новому имени. Он разделяет место, выбор, доказательство, разрешение и эффект. Это разделение должно сохраниться в учёте и журналах.
Источники
- IETF Datatracker: RFC 9813
- История RFC 9813
- Ссылки RFC 9813
- Lu Heng: Minimum Initial Specification
- Lu Heng: On Reality Layers
- Lu Heng: Running-Code Primacy
- Errata RFC 9813
- Информация RFC 9813
- RFC 2865: RADIUS
- RFC 4279: наборы TLS PSK
- RFC 6613: RADIUS поверх TCP
- RFC 6614: RADIUS поверх TLS
- RFC 7360: RADIUS поверх DTLS
- RFC 7542: Network Access Identifier
- RFC 7585: динамическое обнаружение RADIUS
- RFC 8446: TLS 1.3
- RFC 9257: внешние PSK
- RFC 9258: импорт внешних PSK
- RFC 9325: безопасное применение TLS/DTLS
- RFC 9813: эксплуатационные соображения
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
