Кратко

  • Stand-Alone BTNS защищал трафик внутри успешно созданной SA, но не защищал начальное установление от активного посредника и не подтверждал внешнюю личность участника.
  • Channel-Bound BTNS мог обнаружить посредника с помощью верхней аутентификации и channel binding, однако это происходило после успеха IKE и создания состояния.
  • RFC 5386 запрещал превращать провал известной личности в анонимный успех: обычные PAD-записи шли первыми, wildcard — последним, селекторы не пересекались, SPD требовала BTNS_OK.

Первый зелёный сигнал не был последним

BTNS сохранял криптографический обмен IKEv2. Участник передавал открытый ключ и доказывал владение соответствующим закрытым ключом через AUTH signature. После согласования могли появиться ESP- или AH-ассоциации с целостностью, защитой от повторов и, где применимо, конфиденциальностью.

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

RFC 5387 называет слабое свойство continuity of association. В течение одной SA трафик продолжает исходить от того же неаутентифицированного источника. Это полезно для длинной сессии, если начальное установление не было перехвачено. Оно не создаёт идентичность между разными SA.

Stand-Alone BTNS на этом останавливается. Он может осложнить внедрение пакетов вне пути после установления, но активный посредник в момент обмена способен построить отдельную SA с каждой стороной.

Channel binding выносил приговор позже

Channel-Bound BTNS добавляет аутентификацию верхнего протокола. Её доказательство включает характеристику нижнего IPsec-канала. Если посредник соединил две разные SA, стороны видят разные значения, и верхняя проверка должна завершиться неудачей.

Connection latching связывает поток верхнего уровня с последовательностью похожих SA. Это важно при rekey: новая ассоциация сама по себе не доказывает, что прежний участник продолжает канал. Кэширование latch между сессиями может противостоять межсессионной подмене, а channel binding выполняется для каждой верхней сессии.

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

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

Сильная PAD-запись решала первой

Временной риск CBB не означал, что любая неудача могла перейти в слабый режим. RFC 5386 задаёт строгий порядок Peer Authorization Database.

Сначала система ищет обычные записи по заявленной ID. Если участник соответствует известной записи, он обязан пройти её способ аутентификации. При провале IKE SA отклоняется. Продолжать поиск до BTNS wildcard нельзя.

Только полное отсутствие обычного совпадения позволяет локально преобразовать идентичность в PUBLICKEY, где значением служит переданный ключ, и выполнить второй поиск. Все BTNS-записи логически следуют после обычных. Допустим один wildcard, и он должен быть последним.

Здесь разделены «неизвестный» и «известный, не доказавший себя». Первый может получить намеренно анонимную услугу. Второй уже получил отказ от отношения, которое имело право его судить. Если wildcard поглощает отказ, он становится механизмом downgrade.

Анонимный ключ не наследовал чужой трафик

Установление IKE SA не даёт право на любой Child SA. Участник предлагает traffic selectors, а они могут включать адрес известного хоста или сеть за доверенным шлюзом.

RFC 5386 требует, чтобы ограничения идентичностей wildcard BTNS не пересекались с другими PAD-записями. При создании Child SA PAD можно проверить снова. Неаутентифицированный участник не должен получить селектор, зарезервированный за сильным отношением.

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

RFC 7619 позднее описывает сходный риск для NULL Authentication: анонимный участник за NAT может запросить селектор DNS-сервера и перехватить предназначенный ему трафик. Изоляция и ограничение адресов нужны независимо от качества последующего шифрования.

BTNS_OK отделял открытую услугу от остальной системы

RFC 5386 добавил флаг BTNS_OK в SPD. Трафик BTNS-участника совпадает только с явно помеченной записью. Наличие функции в продукте не делает её глобальной политикой.

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

Поэтому одной записи ike_success недостаточно. Нужны исходная ID, первая PAD-проверка, результат AUTH, право на переход в PUBLICKEY, конкретная BTNS-запись, селекторы, SPD и её флаг. SAD-состояние и счётчик пакетов идут ещё позже, а решение приложения не выводится ни из одного из них автоматически.

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

BTNS не определял спуск к открытому IP

RFC 5386 прямо исключает opportunistic fallback в незащищённый IP, если другая сторона не поддерживает IKEv2. Он также не завершает спецификацию leap of faith и connection latching.

RFC 5387 рекомендует BTNS вместо отсутствия безопасности, а не вместо более сильной безопасности. Цепочка «сертификат не прошёл — попробуем анонимный ключ — затем отправим открыто» является другой политикой.

Отрицательные квитанции поэтому важнее общего статуса доступности. Отказ известной ID подтверждает работу запрета downgrade. Отказ пересекающегося селектора сохраняет чужую область. Отказ SPD без BTNS_OK удерживает анонимную услугу в границе.

Более поздние RFC уточнили, но не доказали эксплуатацию

RFC 7670 вернул в IKEv2 общий формат Raw Public Key через SubjectPublicKeyInfo после изменений базовой спецификации. Он требует внешней проверки, когда нужна уверенность в подлинности ключа. RFC 7619 стандартизовал NULL Authentication и ID_NULL, явно отделив связность обмена от личности.

Эти документы показывают развитие архитектуры. Они не доказывают поддержку BTNS в текущем продукте, распространение, инцидент или защищённость конкретной сети. Для этого нужны версия, сборка, загруженная политика, IKE trace, селекторы и наблюдение пакетов.

Подход Lu Heng полезен как дисциплина источников: заявленная ID, ключ, PAD-решение, SPD-разрешение, SA, channel binding, верхний principal и результат операции принадлежат разным слоям реальности. Поздний успешный principal не должен переписывать ранний анонимный обмен, а ранняя SA не должна предсказывать позднее решение приложения.