Кратко

  • RFC 3631 требует сначала назвать угрозу, объект, слой и гранулярность защиты, а затем выбирать механизм. Название алгоритма не задаёт границу утверждения.
  • Ключ, сертификат, туннель или handshake подтверждают ограниченное состояние. Они не доказывают автоматически личность прикладного субъекта, разрешение операции, полный охват обмена или итог услуги.
  • Для решения нужен связанный протокол: сборка и конфигурация, согласованные параметры, эталонная личность, путь доверия, жизненный цикл ключа, защищённые байты, правило авторизации и наблюдаемый результат.

Граница — часть требования, а не примечание к схеме

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

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

RFC 3631 поставил гранулярность и слой среди факторов выбора механизма. Чем ниже слой, тем шире технический охват и тем меньше прикладного смысла он обычно видит. Это не иерархия качества; это разные предметы доказательства.

Документ 2003 года не следует читать как нынешний профиль алгоритмов

RFC 3631 опубликован в декабре 2003 года в потоке Internet Architecture Board со статусом Informational. Он не является Internet Standard. Карточка RFC Editor и IETF Datatracker закрепляют этот статус. История описывает документ, а не внедрение; поиск errata не сертифицирует реализации.

Оценки конкретных алгоритмов относятся к своей эпохе. Современный TLS 1.3 определён в RFC 8446, действующие рекомендации по TLS/DTLS — в RFC 9325, последующая архитектура IPsec — в RFC 4301. Исторический текст не используется здесь как инструкция по настройке.

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

Модель угроз выбирает свойства

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

RFC 3552 описывает модель угроз как предположения о возможностях противника и явную границу учтённых и исключённых атак. Протокол приложения не должен считать всех противников off-path. Ограниченная исходная среда тоже не гарантирует, что использование не расширится.

RFC 2316, отчёт семинара IAB по архитектуре безопасности, требовал от RFC содержательно описывать угрозы, меры и пределы. Это свидетельство процесса, а не того, что конкретная система выполнила его требования.

Практическая запись перечисляет ресурс, действие, последствия, on-path и off-path возможности, инсайдера, компрометацию endpoint, требуемый срок, а затем нужные свойства: конфиденциальность, целостность, аутентификацию стороны или источника, защиту от replay, доступность и авторизацию. «Сильное шифрование» не заменяет эту модель.

Поддержка, включение и выбор — разные события

RFC 3631 объясняет mandatory-to-implement как основу совместимости. Если продукты реализуют только непересекающиеся опции, общей защищённой связи не получится. Обязательный механизм гарантирует общую возможность.

Требование адресовано разработчику. Оно не означает, что оператор включил опцию, сделал её default или использовал в данном соединении. Старый слабый механизм можно и нужно отключить, даже если он остаётся реализован. RFC 3365, BCP 61, требует сильной защиты и одновременно разделяет реализацию и применение.

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

Так же следует описывать вывод алгоритмов. Наличие старого кода не равно экспозиции; незавершённое отключение не равно исполненной политике.

Активный IPsec не доказывает маршрут спорного пакета

RFC 4301 связывает услуги IPsec с протоколом, режимом, endpoint Security Association, ключами и политикой. Security Policy Database может направить трафик в protect, discard или bypass. Здоровый туннель и растущие общие счётчики не показывают, в какую ветвь попал конкретный пакет.

Следует соединить версию SPD, селекторы, SA, идентификатор потока или пакета, счётчики, peer validation и результат внутреннего приложения. Даже доказанный проход через gateway-to-gateway SA аутентифицирует шлюзы, а не автоматически пользователя или организацию внутри.

Топология тоже меняет смысл. RFC 3631 называет firewall топологической защитой: он предполагает границу между внутренним и внешним и сам по себе не останавливает внутреннего нарушителя. Туннели, Wi-Fi, прямые соединения, запасные маршруты и скомпрометированные endpoint могут обойти границу при неизменной таблице правил.

Карта, административные домены, альтернативные пути и исключения должны иметь версии и время действия. Неизменный текст firewall может потерять прежний смысл после появления нового пути.

Правильный handshake может прийти не к тому адресу

RFC 9325 подчёркивает критическую роль проверки hostname в обычном TLS. Цепочка может быть валидна, а сторона — доказать владение приватным ключом, но соединение всё равно может завершиться не на нужном endpoint.

Эталонное имя появляется до соединения из конфигурации, discovery или выбора пользователя. Сохраняются это имя, имена сертификата, правило сопоставления, trust anchors, время, status inputs, исключения и вердикт. Нельзя позволять предъявленному сертификату задним числом определить, кого приложение собиралось найти.

После этого остаётся авторизация. Проверка сервера не аутентифицирует клиента. Клиентский сертификат может обозначать устройство, а не человека. И верная личность не получает автоматически право изменить объект.

RFC 3631 сравнивает иерархию сертификатов и web of trust. Обе модели требуют выбранной проверяющей стороной исходной точки и надёжных релевантных связей. Подпись показывает действие ключа; политика решает, почему оно авторитетно для этого назначения.

Результат framework зависит от выбранного механизма

По RFC 3631 свойства SASL определяются реально согласованным механизмом. GSS-API также требует независимой оценки нижележащего механизма. Имя framework не гарантирует взаимную аутентификацию, channel binding, защиту всех последующих сообщений или replay resistance.

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

TLS 1.3 независим от протокола приложения. Версия, cipher suite, client authentication, ALPN, resumption и 0-RTT влияют на утверждение. Данные 0-RTT имеют replay-ограничения; приложение не может считать неидемпотентную операцию однократной только потому, что она шифровалась.

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

Начальная аутентификация не покрывает последующие действия

Пример HMAC в RFC 3631 обозначает временную границу. Challenge на общем секрете способен аутентифицировать начало и защитить от воспроизведения старой сессии. Если последующие protocol data units не защищены, сессию можно перехватить после проверки.

Coverage map указывает, какие method, destination, headers, body, nonce, sequence и response входят в MAC или подпись. Каждое ли изменение состояния защищено? Наследует ли reconnect прежние полномочия? Входит ли финальное подтверждение в тот же контекст?

«MAC действителен» связывает байты и ключ. Авторизация требует principal, resource, scope, policy и freshness. Прямое превращение бита проверки в permit создаёт сведения, которых не было в криптографическом вводе.

Свежесть ключа — только одна временная координата

RFC 4107, BCP 107, различает автоматическое и ручное управление ключами. Автоматика может подтвердить liveness, получить свежие ключи и масштабировать rekey. Ручной подход допустим в ограниченных условиях и всё равно требует идентификатора, перехода, замены и реакции на компрометацию.

Сохраняются происхождение, генерация, граница хранения, распространение, peer binding, назначение, возраст, rotation, revocation, уничтожение и compromise status. Одна suite с эфемерным ключом и с годами копируемым shared secret имеет разный риск. Старый ключ TLS ticket тоже меняет прошлую экспозицию без изменения названия протокола.

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

Имя и адрес не являются самодостаточной личностью

RFC 3631 перечисляет ограничения аутентификации по адресу и имени: routing, DHCP, proxies, spoofing и DNS меняют значение наблюдения. DNSSEC защищает происхождение и целостность подписанных DNS-данных, но не делает ошибочное базовое соответствие истинным и не превращает разрешение имени в прикладное разрешение.

Cross-check может быть полезен человеку при расследовании, не становясь машинной аутентификацией. Нужно хранить источник имени, момент, защищённый ответ, mapping и отдельное решение доверия.

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

Разделять формальную и исполняемую реальность

Тексты Lu Heng о слоях реальности и приоритете работающего кода помогают разнести спецификацию, способность, настройку, согласование, проверку, решение и эффект. Minimum Initial Specification позволяет сделать общий минимальный интерфейс доказательств, не отнимая будущую локальную власть. Authority and Belief требует назвать автора, область и предел утверждения.

Для важного действия связываются ресурс и угроза; требуемое свойство; build; конфигурация; предложение и выбор; эталонная личность, credential, anchors и validation; ключи; пакеты, записи или объекты; application principal и authorization rule; permit или deny; сетевой и деловой результат. Alert, fallback, bypass, replay rejection, expiry, name mismatch, truncation и exception сохраняются наравне с успехом.

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

Источники

  1. RFC 3631 — Security Mechanisms for the Internet
  2. RFC 3631 в plain text
  3. Карточка RFC Editor для RFC 3631
  4. RFC 3631 в IETF Datatracker
  5. История RFC 3631
  6. Поиск errata RFC 3631
  7. RFC 2316 — IAB Security Architecture Workshop
  8. RFC 3365 — требования сильной безопасности
  9. RFC 3552 — руководство по Security Considerations
  10. RFC 4107 — управление криптографическими ключами
  11. RFC 4301 — архитектура IPsec
  12. RFC 8446 — TLS 1.3
  13. RFC 9325 — безопасное применение TLS/DTLS
  14. Lu Heng — Running Code Primary
  15. Lu Heng — Minimum Initial Specification
  16. Lu Heng — On Reality Layers
  17. Lu Heng — On Authority and Belief