Кратко

  • В RFC 9820 успешный метод EAP и экспорт MSK не завершают доказательство защищённой сессии. Authenticator посылает защищённый OSCORE Step 7, peer проверяет его и возвращает также защищённый Step 8 2.04 Changed; обе проверки подтверждают совместимый производный контекст.
  • Общий контекст не разрешает все ресурсы. Начальная авторизация, политика приложения, срок жизни, повторная аутентификация, смена поколения и принудительное удаление остаются отдельными решениями с разными владельцами и признаками завершения.
  • Минимальная доказательная цепочка связывает поколения ресурсов CoAP, результат EAP, несекретную линию вывода ключей, согласование, Recipient IDs, проверки 7/8, действующую политику, подтверждения удаления и независимо наблюдаемый трафик, не записывая MSK.

Потерянное подтверждение не позволяет объявить общий финал

В гипотетическом случае peer действительно обработал DELETE. Но сеть потеряла его 2.02 Deleted, поэтому authenticator узнал только о собственной очистке после EXCHANGE_LIFETIME. Если отчёт фиксирует один итоговый флаг, он либо объявит удаление без удалённого доказательства, либо сочтёт peer активным вопреки фактическому стиранию. Оба ответа больше имеющихся данных.

RFC 9820 определяет службу EAP поверх CoAP для ограниченных устройств. Устройство выступает EAP peer и одновременно CoAP server. Controller является EAP authenticator и отправляет запросы как CoAP client. В pass-through режиме backend AAA server может выполнять метод или предоставлять авторизационные сведения.

Пересечение ролей требует точного языка. «Клиент прошёл проверку» не сообщает, имеется ли в виду CoAP client, EAP peer, физическое устройство или организация-владелец. Receipt должен сохранять протокольную роль, экземпляр, policy principal и приложение, принявшее последнее решение.

Страница RFC Editor и Datatracker относят RFC 9820 к IETF Standards Track, опубликованному в сентябре 2025 года по итогам работы ACE. Этот статус характеризует спецификацию. Он не доказывает реализацию, соответствие, развёртывание, допуск устройства или исход операции.

Одноразовые ресурсы несут порядок обмена

CoAP-EAP не скрывает все шаги за постоянным endpoint. После обработки peer создаёт ресурс для следующего шага и удаляет предыдущий. Location-Path либо Location-Query в ответе показывает следующий допустимый адрес.

Поэтому поколение ресурса входит в transcript. Запрос к уже удалённому ресурсу не становится текущим из-за поздней доставки. Дублированный Step 0 во время активной аутентификации должен молча отбрасываться. Старый trigger после завершения может выглядеть для authenticator как новый запуск, хотя peer не видит ожидаемого ресурса.

RFC 7252 задаёт семантику запросов, ответов и надёжности CoAP. RFC 4137 описывает машины состояний EAP. RFC 9820 соединяет их, но не превращает в одну строку с полем status.

Нужны роли peer/authenticator, текущее и удалённое поколение, идентификаторы запросов и ответов, переход EAP, результат CoAP, время и транспортное наблюдение. Для повтора на другом поколении следует указать: отклонён, отброшен либо воспринят как новая аутентификация.

Step 7 проверяет, может ли локальный успех перейти границу

После успеха метода authenticator получает экспортированный MSK, EAP Success и такие сведения, как Session-Lifetime. RFC 5247 определяет EAP Key Management Framework. RFC 9820 требует метод, экспортирующий MSK и EMSK не короче 64 octets.

Наличие MSK на одной стороне ещё не доказывает совместимое состояние защиты. RFC 9820 выводит OSCORE Master Secret и Master Salt из MSK, transcript согласования cipher suite и заданных context strings. Обменянные Recipient IDs определяют направления отправки и приёма. RFC 5869 задаёт HKDF, а RFC 8613 — OSCORE.

Authenticator помещает EAP Success в защищённый OSCORE POST. Peer получает собственный MSK, выводит контекст из тех же входов и проверяет запрос. Step 7 — не декоративное шифрование после важного события. Это испытание: способен ли локальный вывод authenticator стать принимаемым состоянием peer.

Для аудита сохраняют fingerprint transcript, method/suite IDs, Recipient IDs, поколение вывода, версии исполняемого ПО и результат проверки. Сам MSK в журнал не помещают: копирование секрета ради доказательства разрушает модель контроля.

Step 8 возвращает доказательство инициатору

После успеха EAP и проверки Step 7 peer отвечает защищённым OSCORE 2.04 Changed. Проверив Step 8, authenticator получает свидетельство, что peer смог работать с тем же Master Secret.

Нужно различать пять событий: результат метода; экспорт ключевого материала; локальный вывод; проверка Step 7 на peer; проверка Step 8 на authenticator. Потеря последнего ответа не отменяет предыдущие, но не позволяет говорить о завершённом взаимном подтверждении.

Transcript согласования входит в вывод. Изменённое значение создаёт разные контексты, и защищённые шаги не проходят проверку. Реестры IANA CoRE Parameters и IANA EAP Parameters закрепляют codepoints, но не подтверждают, что выбрал и выполнил конкретный endpoint.

Зрелая телеметрия отдельно считает результаты метода, проверки Step 7 и проверки Step 8. Разница между счётчиками — открытое состояние, а не помеха для красивого отчёта.

Общая защита не передаёт власть над каждым ресурсом

После Step 8 последняя CoAP-EAP resource должна защищаться OSCORE. Тот же контекст разрешено применять к другим ресурсам, только если это допускает application policy.

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

При AAA организация peer может передавать bootstrap-авторизацию через RADIUS или Diameter; в standalone режиме она располагается у authenticator. После bootstrap возможна дополнительная проверка. RFC 9200 описывает OAuth в ACE, однако ссылка на стандарт не доказывает token decision для конкретного ресурса.

Controller с MSK не становится владельцем организационной политики. AAA, вернувший attribute, не доказывает enforcement. Валидный OSCORE request не доказывает включение ресурса в разрешённый набор. Receipt соединяет версию политики, principal, решение, запрос и выполненный эффект.

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

При повторной аутентификации одновременно существуют два настоящих состояния

Если Session-Lifetime не передан, RFC 9820 использует default восемь часов по рекомендации RFC 5247. Это протокольное значение, не универсальная норма и не свидетельство реальной настройки.

Во время re-authentication текущий контекст продолжает действовать, пока строится кандидат. Старый заменяется после полного успеха нового. При неудаче он может жить до expiry или следующей успешной попытки.

Начало обновления не равно активации. В графе должны быть старое поколение, новый кандидат, method result, Step 7/8, policy decision, activation, последнее использование старого, retirement и expiry. Если оба поколения принимают трафик, фиксируется намеренность overlap и допустимость необратимых операций.

Control Plane может показывать «заменено», пока работающий resource server принимает прежний контекст. Приоритет исполняемого кода требует следовать реально выполненным переходам, а не иерархии интерфейсов.

Удаление имеет отправителя, получателя и внешние остатки

Для принудительного прекращения authenticator посылает защищённый OSCORE DELETE последней state resource. Peer отвечает защищённым 2.02 Deleted. Если ответ не приходит до EXCHANGE_LIFETIME, authenticator удаляет локальное состояние.

Тайм-аут освобождает локальные ресурсы, но не доказывает удалённое стирание. При partition Controller может считать устройство исключённым, peer — сохранять context, application cache — разрешать старую policy, а сеть — продолжать доставку.

Цепочка включает инициатора решения, причину, поколение, отправленный DELETE, получение peer, локальный результат peer, protected acknowledgement, проверку authenticator, timeout, локальный cleanup, downstream invalidation, последующие отказы и наблюдаемое прекращение трафика.

Даже если обе стороны действительно удалили состояние, потерянный acknowledgement оставляет различие между фактом на peer и знанием authenticator. В отчёте следует писать «локальное состояние authenticator удалено после timeout; удалённый результат неизвестен», пока другой источник не закроет разрыв.

Доверие начинается раньше метода

Discovery authenticator или intermediary находится вне области RFC 9820. Найденный сервис не обязательно является назначенной властью. RFC 6677 предоставляет EAP channel binding и lower-layer identifiers, способные выявлять расхождения через метод и AAA path, но их конфигурация и результат должны быть сохранены для конкретной сессии.

Peer может доверять authenticator с MSK, потому что его AAA server доверил ему эту роль. Это ограниченная цепочка делегирования внутри key-management architecture, а не постоянная метка «trusted controller».

Поддельные Step 0 могут расходовать состояние. RFC рекомендует rate limiting и минимум state до EAP-Response/Identity. Счётчик подтверждает работу ограничения, но не легитимность источника.

Испытание должно разорвать счастливую последовательность

Минимальный стенд включает peer, authenticator, AAA pass-through, два ресурса с различными policies и независимый packet observer. Помимо штатного пути, он меняет transcript, теряет Step 7, теряет Step 8, воспроизводит старое поколение, дублирует Step 0, проваливает re-authentication, измеряет overlap, запрещает второй ресурс и удаляет состояние с acknowledgement и без него.

Каждый случай сопоставляет EAP state, CoAP generation, OSCORE verification, application decision и observed traffic. Один итоговый success либо failure не отвечает, какой слой что знал.

Ключевой тест для отзыва теряет подтверждение DELETE и сохраняет кэш приложения. Он вынуждает отдельно доказать локальное удаление, удалённое удаление, отзыв policy и фактическое прекращение доступа.

Чего источники не устанавливают

RFC 9820 не называет продукты, операторов или развёртывания. Он не сообщает показатели батареи, latency, loss, admissions, attacks или interoperability. Примеры объясняют протокол, а не описывают эксплуатационную телеметрию.

История Datatracker, документы, ссылающиеся на RFC 9820, и ссылки из RFC 9820 фиксируют документальные отношения. Поиск errata показывает редакционный статус, не security score.

RFC 3748 определяет общий EAP framework. Само наличие стандартов не позволяет вывести identity, authority, state или outcome конкретного устройства.

Источники

  1. IETF Datatracker: RFC 9820
  2. История RFC 9820
  3. Документы, ссылающиеся на RFC 9820
  4. Ссылки из RFC 9820
  5. Heng Lu: минимальная исходная спецификация
  6. Heng Lu: слои реальности
  7. Heng Lu: приоритет исполняемого кода
  8. IANA CoRE Parameters
  9. IANA EAP Parameters
  10. Errata RFC 9820
  11. RFC Editor: RFC 9820
  12. RFC 3748
  13. RFC 4137
  14. RFC 5247
  15. RFC 5869
  16. RFC 6677
  17. RFC 7252
  18. RFC 8613
  19. RFC 9200
  20. RFC 9820