Кратко

  • RFC 3652 отделил фиксированный 20-октетный Message Envelope для доставки и сборки от 24-октетного Header и тела, зависящего от операции. Цифровая подпись в Message Credential не охватывала Envelope, но защищала Header и Body.
  • Credential мог содержать цифровую подпись отправителя либо код аутентификации сообщения на основе заранее установленного ключа сеанса. Эта граница описывает область целостности протокола, а не задокументированную атаку, ошибку реализации или невозможность защиты на нижнем уровне.

Одно сообщение — разные области доверия

В 2003 году спецификация протокола Handle должна была описать больше, чем поиск. Клиенту требовалось найти ответственный Handle-сервер, запросить разрешение имени или административную операцию, а затем понять ответ. Кроме того, сообщения должны были передаваться транспортами, по-разному представляющими данные. Версия 2.1 RFC 3652 разделила эти функции на четыре соседние части: Envelope, Header, Body и Credential. RFC 3652

Envelope всегда присутствовал и имел длину ровно 20 октетов. RFC описывает его как оболочку для доставки сообщения, а не как данные приложения. Среди его полей — версия протокола, флаги сообщения, идентификаторы сеанса и запроса, номер последовательности и длина сообщения. Обязательный Header занимал 24 октета и содержал общие поля, включая коды операции и ответа. Body содержал данные конкретной операции и мог быть пустым. RFC 3652

Граница доверия не совпадала с границей пакета. RFC 3652 прямо указывает: цифровая подпись в Message Credential не защищает содержимое Envelope, но защищает Header и Body. Непустой Credential мог содержать цифровую подпись отправителя либо односторонний MAC на основе уже установленного ключа сеанса. Документ указывает, что Credential может служить для аутентификации сообщения и проверки целостности данных после передачи. MAC опирается на общий секрет, а цифровая подпись использует другую модель ключей. RFC 3652 RFC 2104

Такое разделение соответствовало назначению Envelope. Клиент Handle мог использовать датаграммы UDP или поток байтов TCP. RFC 3652 ограничивал UDP-сообщения 512 октетами, не считая заголовков IP и UDP. Более длинные сообщения требовалось разбивать на фрагменты; каждый фрагмент нес номер последовательности в Envelope, чтобы получатель мог собрать сообщение. TCP давал поток байтов, но не задавал границы Handle-сообщений. Протокол по-прежнему мог делить более крупные сообщения и собирать их на принимающей стороне. RFC 3652 RFC 768 RFC 793

Header и Body, напротив, описывали действия клиента и сервера. Код операции обозначал тип запроса Handle; код ответа сообщал результат: успех, отсутствие значения, перенаправление к службе, отказ в авторизации или необходимость аутентификации. Протокол следовал отдельно определённой модели пространства имён и данных, а RFC 3650 описывал архитектуру всей службы. Поэтому защищённое семантическое содержимое начиналось после оболочки доставки: сборка фрагмента сама по себе не разрешала содержащуюся в нём операцию. RFC 3652 RFC 3650 RFC 3651

Аутентификация не означала разрешение

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

RFC 3552 рассматривает целостность данных, аутентификацию партнёра, конфиденциальность и безопасность системы как разные цели: подпись или MAC не обеспечивают автоматически их все. Раздел безопасности RFC 3652 обсуждает подписи сервера и аутентификацию клиента, однако определение формата уже: Credential охватывает Header и Body, но не Envelope доставки. Само это утверждение не доказывает, что сообщение меняли в действующей системе. Канал нижнего уровня мог обеспечивать дополнительную защиту; RFC — это спецификация, а не отчёт об инциденте. RFC 3552 RFC 3652

Credential Handle не следует смешивать с профилем подписей X.509. RFC 3279 задаёт идентификаторы алгоритмов и форматы для сертификатов и списков отзыва в рамках этого профиля PKI; он не расширяет подписываемый RFC 3652 диапазон байтов и не превращает Envelope в аутентифицированное содержимое. Одних криптографических терминов недостаточно — нужно точно назвать объект, который защищается. RFC 3279 RFC 3652

RFC 3652 имеет статус Informational; примечание IESG говорит, что обсуждения не привели к консенсусу IETF ни по системе Handle, ни по её месту в архитектуре идентификаторов IETF. Документ описывает предложенный протокол, а не доказывает его повсеместное внедрение. Более узкий вывод таков: кадрирование, сборка и аутентификация могут подчиняться разным правилам, поэтому любое утверждение о целостности должно уточнять, какие именно байты охватывает Credential. RFC 3652

Источники