Кратко

  • RFC 1446 проверял сообщение SNMPv2 в двух независимых измерениях: совпадает ли MD5-дайджест, вычисленный с общим секретом, и попадает ли временная метка в административно заданный срок действия. Правильный дайджест сам по себе не означал свежесть.
  • Пока сторона пользовалась тем же закрытым ключом аутентификации, partyAuthClock не разрешалось уменьшать. Откат заново открывал уже пройденный диапазон меток и мог сделать сохраненные старые сообщения снова допустимыми.
  • Состояние восстановления включало идентичность стороны, поколение ключа и монотонное время как единую эпоху. В RFC 3414 ее позднее представили идентификатором авторитетного движка, энергонезависимым счетчиком загрузок и временем текущей загрузки, сохранив раздельные проверки аутентификации и своевременности.

Когда вчерашний пакет снова попал в настоящее

Пусть агент дошел по аутентификационным часам до отметки 61 000, после чего питание пропало. Ранее в сети было записано сообщение с отметкой 60 500. Если допустимый срок жизни равен 300 секундам, то после продвижения локального представления получателя дальше 60 800 эта копия считается устаревшей.

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

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

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

Совпавший дайджест был только первой частью ответа

RFC 1446 вышел в апреле 1993 года как документ Standards Track и теперь имеет статус Historic. Он определял протокол аутентификации и протокол конфиденциальности для SNMPv2. Профиль v2md5AuthProtocol использовал 16 октетов закрытого аутентификационного материала и 128-битный результат MD5.

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

Однако для полной проверки получатель извлекал также локально известные часы исходной стороны и срок жизни. Временное условие отказа имело вид:

authSrcTimestamp + срок жизни < локальные часы аутентификации

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

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

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

Размер окна определял администратор

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

Узкое окно быстрее исключает записанный трафик, но хуже переносит дрейф и законные задержки. Широкое окно снижает число эксплуатационных отказов и одновременно продлевает полезность копии для повторной подачи. Увеличение срока жизни ради исчезновения ошибок — не нейтральная настройка удобства, а изменение политики риска.

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

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

Новый ключ разрывал связь с открывшимся интервалом

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

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

RFC 1447 повторял это правило в определении partyAuthClock: значение нельзя уменьшать, если одновременно не меняется закрытый аутентификационный ключ стороны. partyAuthLifetime выражал допустимый интервал в секундах. Эти объекты описывали не независимые строки инвентаря, а связанную границу эпохи.

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

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

Сначала получить ориентир, затем подтвердить его

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

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

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

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

Монотонность должна была пережить выключение

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

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

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

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

Счетчик загрузок позволил секундомеру обнуляться

Позднее User-based Security Model из RFC 3414 привязал своевременность к авторитетному SNMP-движку. snmpEngineID идентифицировал его, snmpEngineBoots считал перезапуски или повторные инициализации, а snmpEngineTime отсчитывал секунды в текущей загрузке. Идентификатор движка и счетчик загрузок должны были сохраняться энергонезависимо.

Таймер внутри загрузки мог начинаться с нуля, поскольку сначала увеличивался счетчик. Сообщение предыдущего запуска принадлежало другой эпохе, даже если число секунд совпадало с текущим. Авторитетный получатель отвергал иной счетчик либо время за пределами фиксированного 150-секундного окна.

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

RFC 3414 не был непосредственной заменой RFC 1446; между ними лежали промежуточные стадии развития SNMP. Сравнение здесь архитектурное. RFC 1446 защищал непрерывные часы от отката сменой ключа. RFC 3414 разрешил обнулять таймер загрузки благодаря постоянному счетчику эпох. В обоих случаях соответствия секрету было недостаточно: сообщение должно было принадлежать текущей истории получателя.

Источники