Кратко

  • Экспериментальный профиль RADIUS/1.1, опубликованный в 2025 году, менял защиту отдельного соединения TLS или DTLS. Прокси мог независимо договариваться о транспорте с каждой стороны, поэтому защищённый переход не описывал всю цепочку.
  • Proxy-State решал другую задачу: посредник добавлял собственное частное состояние и забирал его при возвращении ответа, сохраняя значения предыдущих посредников и их относительный порядок.
  • Не интерпретировать чужую кодировку, вернуть её без изменений и доверять всем решениям по пути — разные обязательства. Протокол не объединял их в одно обещание.

Обновление, которое заканчивалось у следующего соседа

В апреле 2025 года экспериментальный RFC 9765 описал RADIUS/1.1 для соединений TLS и DTLS. Профиль убирал старые механизмы пакетов на основе MD5 и общих секретов на соответствующем соединении. Это было существенное изменение, но не превращение всех промежуточных серверов в прозрачную трубу между двумя конечными точками.

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

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

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

Цепочка была составлена из отдельных обменов

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

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

Информационный RFC 2607 июня 1999 года рассматривал эту схему применительно к роумингу. Пользователь мог подключаться через одну организацию, а решение о его аутентификации требовало участия другой. Посредники помогали управлять отношениями, учитывать различие возможностей, применять политики и передавать сведения для учёта.

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

Значение, которое не следовало понимать всем

Proxy-State присутствовал уже в RFC 2138 апреля 1997 года. В RFC 2865, опубликованном в июне 2000 года, правила работы прокси и сохранения порядка получили более подробное описание.

Посредник мог добавить к пересылаемому запросу одно собственное значение Proxy-State, но не несколько. Оно помещалось после уже существовавших значений того же типа. Чужие значения нельзя было изменять, а порядок однотипных атрибутов — переставлять.

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

Такое устройство не требовало от всех участников единой внутренней модели транзакции. Один сервер мог организовать свою память иначе, чем сосед. Общим оставалось поведение на границе: что сохранить, в каком порядке вернуть и какое значение вправе убрать именно этот посредник.

Возвращалась и отрицательная развязка

Конечный сервер переносил полученные Proxy-State в ответ без изменения содержимого и порядка. Это относилось не только к Access-Accept, но и к Access-Reject и Access-Challenge. Отказ в доступе не отменял обязанность вернуть информацию, нужную посредникам для завершения обмена.

Когда ответ приходил обратно, прокси удалял последний Proxy-State, если сам добавил значение при отправке. Благодаря правилу добавления последним было его собственное. Предыдущие значения оставались для предыдущих посредников. Сервер, который ничего не добавлял, не получал права удалить чужое состояние просто потому, что видел его в ответе.

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

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

Сохранить можно было и без дальнейшей пересылки

В правилах 2000 года была ещё одна важная свобода. Прокси мог не включать ранее полученные Proxy-State в запрос, который отправлял дальше. В таком случае он обязан был снова присоединить их к ответу перед возвратом своему клиенту.

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

Поэтому Proxy-State нельзя читать как полную историю пути. Возвращённое значение не доказывает, что его видел конечный сервер. Отсутствие значения на следующем участке не доказывает само по себе потерю. Наблюдать следует правильную границу: что посредник получил от своего клиента и что затем вернул именно ему.

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

Три состояния не образовывали одну личность

В реестре атрибутов RADIUS IANA State, Class и Proxy-State обозначены числами 24, 25 и 33. Общие номера помогают распознать тип атрибута, но не делают значения взаимозаменяемыми.

State мог переносить состояние продолжающейся аутентификации: сервер включал его в запрос дополнительных доказательств, а клиент возвращал в следующем Access-Request. Class мог перейти из принятого решения о доступе в сообщения учёта; базовая спецификация рекомендовала сохранять его без изменений при использовании учёта. Proxy-State обслуживал возврат к посреднику и удалялся своим автором.

RFC 5080 декабря 2007 года уточнил, что новая или заново начатая аутентификация не должна наследовать State предыдущего разговора только потому, что пользователь и порт остались прежними. Совпадение внешних признаков не доказывает, что продолжается тот же обмен.

У учёта была отдельная граница подтверждения. По информационному RFC 2866 июня 2000 года Accounting-Response следовал после получения и записи запроса. Если записать его не удавалось, такое подтверждение не предполагалось. Это больше, чем уведомление о прибытии пакета, но не обязательно доказательство, что все удалённые организации уже имеют одинаковую запись.

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

Непрозрачность не скрывала байты

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

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

RADIUS также не запрещал вообще все изменения ответа. Прокси мог менять некоторые атрибуты ради местной политики, однако существующие Proxy-State, State и Class сохранялись. Граница была конкретной. Нельзя ни объявить весь пакет неизменяемым, ни вывести из права применять политику право переписывать любое чужое состояние.

В старом обмене прокси проверял аутентификатор ответа с использованием секрета для удалённого соседа, отбрасывал не прошедшую проверку посылку, восстанавливал Identifier исходного запроса клиента и рассчитывал аутентификатор для обратной связи с этим клиентом. Это были последовательные отношения, а не один неизменный заверенный конверт через все административные области.

Позднейшая защита сохранила старый вопрос

Экспериментальный RFC 6614 мая 2012 года описал RADIUS поверх TLS, но сохранил способность посредников обрабатывать сообщения. Экспериментальный профиль 2025 года продвинул защиту соответствующих соединений дальше, не отменив раздельных транспортных решений по обе стороны прокси.

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

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