Кратко

  • В RFC 1446 сторона SNMPv2 могла изменить собственный секрет до формирования ответа, поэтому ответ защищался новым ключом, ещё не принятым локальной базой менеджера.
  • Отсутствие ответа означало либо потерянный запрос со старым ключом на обеих сторонах, либо выполненную смену с потерянным обратным пакетом; прочитать секрет напрямую было нельзя.
  • Отдельным доказательством служила узнаваемая публичная метка, а старый и новый ключи требовалось хранить до сверки, в том числе после перезагрузки.

Восстановление начиналось с двух версий состояния

RFC 1446 задавал порядок смены существующего секрета. Ответственная станция создавала новое значение и отправляла защищённый setRequest. Получатель обрабатывал запрос и отвечал. Собственную базу менеджер менял только после получения ответа.

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

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

Потерянный ответ не говорил, что потерялось

Первый вариант: запрос не дошёл, обе стороны сохранили старый ключ. Второй: запрос дошёл, агент применил новый, но ответ пропал. Внешнее наблюдение одинаково — тишина, а состояние противоположно.

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

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

Карточка RFC 1446 относит документ к Historic. MD5 и DES здесь — исторические механизмы 1993 года, не современная рекомендация. Проблема согласования возникала из последовательности записи и ответа.

Публичная метка отвечала за частное изменение

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

Party MIB в RFC 1447 разделял частные и публичные поля, часы стороны и lifetime. Метка не раскрывала ключ и не была его производной. Она связывала невидимое изменение с читаемым идентификатором транзакции.

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

Неопределённость должна была пережить рестарт

Между отправкой и подтверждением менеджер хранил старое и новое значения. Причиной задержки мог быть сетевой сбой, поэтому RFC 1446 требовал готовности удерживать оба длительно и переносить их через перезагрузку.

Контроллер не мог сохранять только желаемый итог. Удалить старый ключ при недоставленном запросе — потерять доступ. Удалить новый при потерянном ответе после успешной записи — получить тот же риск. В журнале восстановления должны были оставаться обе возможные удалённые реальности.

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

Рестарт не равнялся восстановлению. Необходимо было снова согласовать идентичность, время, две кандидатные версии секрета, lifetime и публичную метку.

Проверка целостности не задавала порядок

Общий секрет и digest поддерживали происхождение и целостность. Часы и срок ограничивали чрезмерную задержку и replay. Они не предотвращали удаление или подавление сообщения. RFC отдельно предупреждал: отсутствие аутентифицированного ответа не является окончательным доказательством сбоя агента либо сети. Из-за рассогласования времени или секретов могло потеряться даже уведомление об ошибке.

Общего порядка для меняющих состояние сообщений SNMP не задавал. Следующее изменение следовало отложить до положительного подтверждения или истечения предыдущего. snmpSetSerialNo из MIB SNMPv2 помогал упорядочивать Set отдельно, но не доказывал долговечность записи или её эффект.

Административная модель RFC 1445 добавляла стороны, контексты и политику доступа. Подтверждённое происхождение пакета не давало всеобщего права изменять объекты и не удостоверяло результат.

Публичный свидетель остался в USM

Модель parties не стала окончательной. RFC 1910 экспериментировал с пользователями, идентичностью агента, счётчиком запусков, временем и доступом. RFC 2574, а затем RFC 3414 определили USM для SNMPv3.

Поздняя схема изменила идентичности и вычисление ключей, но сохранила свидетеля. Односторонние объекты KeyChange меняли нечитаемые ключи, spin lock координировал записи, а usmUserPublic принимал случайную метку. При потерянном ответе её чтение показывало, дошёл ли запрос.

Это не делает криптографию RFC 1446 действующей практикой. Оно показывает устойчивость самой задачи: удалённая смена нечитаемого секрета по каналу с потерями требует доказательства, независимого от ответа.

Источники