Кратко

  • RFC 3329 заставлял SIP-агент и первый переход обменяться списками, включить общий механизм с наивысшим приоритетом сервера и вернуть полный статический список сервера в Security-Verify под выбранной защитой.
  • Сравнение выявляло удаление, но не гарантировало современную максимальную стойкость или конфиденциальность; предел задавал самый слабый разрешенный механизм с целостностью и защитой от повторов.

Защиту приходилось выбирать без нее самой

Большая сеть обновляет устройства постепенно. Старый аппарат может знать Digest, новый — также TLS или IPsec. Предварительная настройка каждой пары делает миграцию жесткой. Последовательные попытки позволяют поддельной ошибке представить сильный механизм недоступным.

Переговоры кажутся решением: клиент перечисляет возможности, сервер упорядочивает свои, стороны выбирают лучшее пересечение. Но первые списки проходят до включения выбора. Атакующий на пути может удалить TLS, оставить Digest и сохранить связь. Оба участника решат, что шифрование никогда не предлагалось.

RFC 3329 разнес предложение и доказательство по времени. Клиент отправлял Security-Client следующему SIP-узлу. Сервер отвечал статическим упорядоченным Security-Server и данными для запуска. Клиент выбирал известный общий механизм с наивысшим приоритетом, включал его и посылал новый запрос с Security-Verify — копией полученного списка. Сервер сравнивал квитанцию со своей политикой.

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

Первое сообщение не становилось защищенным ретроспективно. Менялась цена: простое удаление превращалось во взлом целостности действующей защиты в реальном времени. Манипуляция оставляла проверяемое противоречие.

Статический список не давал понижению стать согласованным

Сервер не мог вычислять свой список из Security-Client. Иначе атакующий сначала сокращал бы клиентское предложение, сервер создавал бы столь же сокращенный ответ, а затем получал бы совпадающую слабую квитанцию. Серверный список должен был быть независимым и статическим в области политики. Разные интерфейсы могли иметь разные списки, но каждый существовал до запроса.

Это сохраняло сравнение без нового состояния SIP. Сервер не помнил индивидуальный вызов, а сопоставлял Security-Verify с конфигурацией. TLS или IPsec могли хранить собственное состояние; проверке списка отдельная сессия не требовалась.

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

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

421 и 494 отражали разные стадии

При инициативе клиента открытый запрос нес Security-Client и sec-agree в Require и Proxy-Require. Сервер возвращал 494 Security Agreement Required с полным списком даже без общей опции.

Сервер мог требовать процедуру политикой. Клиент без объявления поддержки получал 421 Extension Required. Клиент, объявивший поддержку, но не завершивший соглашение, получал 494. Оба ответа содержали возможности и сведения запуска.

Коды не были обвинением. 421 мог означать старое устройство, 494 — нормальный первый шаг, несовпадение или восстановление после истечения связи. Для анализа нужны списки, код, материалы, выбор, результат защиты и сравнения.

Механизмы запускались по-разному. TLS создавал защищенное соединение по правилам обнаружения SIP. Digest включал серверный список в проверочный расчет. IPsec-IKE запускал IKE; ручной IPsec зависел от внешних ключей. RFC 3310 дополнял Digest технологией AKA, не заменяя квитанцию.

Срок также различался: закрытие TLS, период IKE, повторный вызов Digest или внешняя политика. Без идентификатора ассоциации и условия окончания запись «успешно» не показывала, как долго действовал результат.

Самая слабая совместимость задавала нижнюю границу

Раздел безопасности требовал, чтобы даже слабейший предложенный механизм защищал Security-Verify от изменения и повтора. Если его можно сломать, предлагать его нельзя. Переговоры затрудняли понижение, но не исправляли сломанный алгоритм.

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

RFC 3329 опубликован в январе 2003 года. RFC 8996 обновил его, запретив TLS 1.0 и 1.1. RFC 8446 определяет TLS 1.3, RFC 7616 обновляет Digest. Архитектура квитанции остается, но слово tls не одобряет все прежние версии.

Errata отделяют правило от примера. Два примера помещают Security-Verify в ACK, хотя нормативная таблица исключает это; исправление ожидает обновления документа. Проверенная ошибка исправляет длину SPI ipsec-3gpp. Реестр IANA подтверждает присвоение имен, но не внедрение или безопасность.

Наследие RFC 3329 — отложенная проверка. Если защита появляется после предложения, исходный список можно донести до защищенного момента, вернуть и точно сравнить. Целая квитанция показывает непрерывность; сила разрешенной политики остается отдельным вопросом.

Источники