Кратко

  • RFC 3012 позволила Foreign Agent в Mobile IPv4 выдавать собственный свежий вызов и до завершения AAA различать отсутствующее, использованное и неизвестное значение.
  • Правильный ответ доказывал только связь с недавним локальным состоянием; аутентификация, разрешение, принятие регистрации, forwarding и доставленный трафик требовали других подтверждений.

Роуминг разносил знание между сетями. Устройство находилось в гостевом домене, а секреты и правила, способные его проверить, — в домашнем. Foreign Agent должен был обработать Registration Request, хотя заранее установленной security association с посетителем могло не быть.

Удалённая проверка не закрывала первый интервал времени. Старый запрос можно было повторить, пока Authentication, Authorization and Accounting искала учётную запись и политику. Гостевой край нуждался в состоянии, созданном им самим.

Опубликованная в ноябре 2000 года RFC 3012 добавила Challenge extension в Agent Advertisement. Случайное значение рекомендовалось делать не короче 32 бит. Mobile Node копировал его в MN-FA Challenge extension своего запроса.

Главным было происхождение. Foreign Agent знал, какие значения только что объявил, и мог проверить свежесть до решения об идентичности. Ответ на собственный вызов был локальной квитанцией, а не удостоверением личности.

Порядок расширений закреплял границу. После MN-FA Challenge требовалась Mobile-Foreign Authentication либо MN-AAA Authentication. Регистрацию с вызовом, но без любого из этих расширений, следовало молча отбросить.

При прямой security association Mobile-Foreign Authentication связывала запрос с общим секретом. В противном случае узел обязан был использовать MN-AAA и желательно Network Access Identifier из RFC 2794. Realm помогал найти нужный административный домен, но строка имени не доказывала, кто её послал.

В пакете жили разные утверждения. Challenge называл недавнее локальное состояние. Authenticator связывал данные с ключом и алгоритмом, выбранным SPI. AAA проверяла credentials. Политика решала, разрешить ли регистрацию. Совпадение одного поля не заменяло следующего решения.

Три кода сохраняли причину. MISSING_CHALLENGE означал отсутствие. STALE_CHALLENGE — что этот Mobile Node уже применял значение. UNKNOWN_CHALLENGE — что значение не было последним успешно возвращённым и не входило в недавние объявления CHALLENGE_WINDOW. Реестр IANA хранит назначения.

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

Для retransmission существовало точное исключение. Если Identification и Challenge совпадали, а соответствующая запись ещё оставалась pending, Foreign Agent мог повторно переслать запрос. За пределами живой транзакции повтор обычно считался stale.

Значит, replay protection была памятью: агент, узел, значение, Identification, состояние ожидания и срок жизни. Запрет всех дубликатов ломал восстановление после потерь; принятие любого недавнего значения стирало защищаемую границу.

Ответ Home Agent также связывался с транзакцией. Если Challenge оставался в пересланном запросе, Foreign Agent сохранял его и отвергал Registration Reply без того же значения. Совпадение показывало принадлежность ответа, но не установленный маршрут и не доставку приложению.

При прямом MN-FA доверии агент мог проверить и удалить локальный материал перед пересылкой, сохранив Identification у себя. Представление менялось; обязанность поддерживать антиреплейную границу оставалась.

Полная verification infrastructure сознательно находилась вне Mobile IPv4. Foreign Agent мог передать ей материал и ждать защищённый результат, однако RFC не назначала внутренний протокол или поставщика. Общей была граница взаимодействия, а не административная система.

Для совместимости CHAP_SPI 2 описывал MD5-вычисление в стиле CHAP, близкое практике RADIUS. Раздел безопасности одновременно предупреждал: метод слабее HMAC-MD5 и по возможности его следует избегать. Мост к установленной базе не становился вечной криптографической нормой.

Оставалась и denial-of-service граница. Повтор мог вызвать ответ, похожий на отказ, пока легитимное принятие ещё находилось в пути. Mobile Node мог отреагировать на первое сообщение. Локальная свежесть не упорядочивала всю распределённую систему.

Для вызовов короче четырёх байт рекомендовалось хранить Identification как дополнительное свидетельство уникальности. Слово «случайный» не добавляло недостающую энтропию. История и идентификатор транзакции дополняли длину только в явных пределах.

В 2007 году RFC 4721 заменила RFC 3012. Она потребовала вести применимые значения по каждому узлу и запретила возвращаться к значениям, объявленным раньше последнего использованного. Были уточнены Advertisement и Reply, добавлена защита от поддельных сообщений и вариант HMAC-MD5.

Это не доказывает конкретную атаку. Но исправления показывают: свежесть — упорядоченная история. Важны издатель, узел, последнее принятие, pending request и authenticator. Вне связей случайные байты не обладают властью.

Тезис отличается от RFC 2002, где создавался временный binding между home address и care-of address. RFC 3012 описывала более ранний шаг у гостевой границы до принятия состояния Home Agent.

Это и не повтор PPP CHAP. В PPP вызов жил в аутентификации канала. Здесь Foreign Agent вводил локальную свежесть в регистрацию Mobile IPv4 и мог обращаться к отдельной AAA. Похожее вычисление не означало одинаковую власть.

Линза Lu Heng о минимальной начальной спецификации показывает достоинство узкой общей части: формат, порядок, окно, ошибки и корреляция. Проверяющая инфраструктура и admission policy оставались локальными. Running-Code Primacy запрещает принимать опубликованный документ за доказательство включённой функции.

Packet capture показывает возврат значения. Криптографический журнал — результат проверки. Policy log — разрешение. Home Agent — принятый binding. Наблюдение трафика — использование. Термин challenge-response не должен говорить за все эти квитанции.

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

Sources