Кратко

  • Каждый защищённый NTS запрос содержит ровно один Unique Identifier длиной не менее 32 октетов, созданный клиентом криптографически стойким генератором; сервер возвращает то же значение.
  • Клиент обрабатывает ответ лишь тогда, когда значение совпадает с ещё ожидающим запросом, а пакет успешно аутентифицирован связанным с ним ключом от сервера к клиенту.
  • Такая проверка обнаруживает повтор и связывает одну пару сообщений; она не является устойчивой идентичностью, NTS Cookie или доказательством правильности времени.

Квитанция на один незакрытый вопрос

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

RFC 8915 даёт клиенту собственную квитанцию. В каждом защищённом запросе должен быть ровно один расширенный атрибут Unique Identifier. Его тело создаёт криптографически стойкий генератор случайных чисел, а длина составляет не менее 32 октетов. Проверив запрос, сервер включает в ответ ровно одно такое поле и без изменений копирует полученную последовательность.

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

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

В этих границах слово «Unique» уместно. Значение отличает для клиента одну ожидающую операцию от других. Его не выдаёт сервер как номер учётной записи, оно не даёт полномочий и не указывает на человека или устройство. Запрос принят либо истёк — доказательная работа идентификатора закончена.

Почему отметка часов оказалась слабым вызовом

Корреляция существовала в NTP и раньше. RFC 5905 определяет 64-битный Origin Timestamp как время отправки запроса по часам клиента. Сервер возвращает это значение, а клиент сопоставляет его со своим состоянием, выявляя ложные, дублированные и повторно воспроизведённые пакеты.

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

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

RFC 8915 разрешает использовать поле и без NTS, чтобы помогать обнаруживать подделки от противника вне пути передачи. Внутри NTS сильный вывод возникает только из пары проверок. Случайное эхо указывает на ожидающий запрос, а S2C-аутентификация — на криптографический контекст пакета. Ни один элемент не заменяет другой.

TLS, Cookie и эхо решают разные задачи

Сначала NTS-KE работает поверх TLS: проводится первоначальная аутентификация сервера, согласуются параметры и выводятся ключи. Затем TLS-соединение закрывается. Unique Identifier в последующем NTP-запросе не служит сертификатом и не переопределяет личность TLS.

NTS Cookie переносит иную квитанцию. Клиент возвращает непрозрачный Cookie, полученный ранее; сервер восстанавливает алгоритм AEAD и направленные ключи, не храня состояние отдельного клиента. Предыдущая статья Sofia Ren о Dieter Sibold проследила именно эту передачу состояния после закрытия TLS. Cookie восстанавливает ассоциацию, Unique Identifier соотносит конкретный ответ с конкретным открытым запросом.

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

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

Подлинный ответ не делает время верным

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

Поэтому RFC 8633 отдельно требует достаточного числа источников, их разнообразия и наблюдения за расхождениями. При единственном источнике его ошибка прямо переходит клиенту. Unique Identifier утверждает: «этот защищённый ответ относится к этому ожидающему запросу». Для утверждения о правильном времени нужны другие свидетельства.

Источники