Кратко

  • Рабочая группа IETF LAKE 8 сентября 2026 года открыла Working Group Last Call по draft-ietf-lake-authz-08; обсуждение завершается 22 сентября.
  • В обычном сценарии ELA устройство U передаёт ID_CRED_I аутентификатору V в сообщении EDHOC 3. V отправляет его серверу W, а ваучер W приходит устройству в сообщении 4.
  • Проект прямо отмечает, что U раскрывает идентичность уже аутентифицированному V, ещё не зная, завершится ли авторизация. Временная идентичность только для подключения предлагается как одна из мер.
  • Daniel Kade предлагает ограниченную квитанцию, отдельно фиксирующую аутентификацию, решение W, отказ и удаление временной идентичности. В проекте такого требования нет.

Объявление Last Call просит до 22 сентября заявить поддержку либо объяснить возражения и возможные решения. История Datatracker фиксирует 8 сентября переход из WG Document в In WG Last Call. Это начало проверки готовности, а не готовый консенсус. Текущая карточка по-прежнему называет редакцию 08 активным Internet-Draft, нацеленным на Proposed Standard, а не RFC или одобренным решением IESG.

ELA расшифровывается как Lightweight Authorization using EDHOC. Ограниченное устройство U обменивается сообщениями с аутентификатором домена V. V связывается с сервером подключения W по менее ограниченной сети. Авторизация идёт одновременно с аутентификацией, поэтому на узком участке не требуется второй полный протокол.

В редакции 08 заранее существуют две разные связи. Устройство знает открытый ключ и местоположение W. Между V и W предполагается неявное доверие, например через Web PKI. Между U и V прежней связи может не быть. Первые две опоры используются, чтобы установить третью.

Что V уже знает до ответа W

В сообщении EDHOC 2 V доказывает U владение ключом своего удостоверения. Затем U посылает сообщение 3 с ID_CRED_I, идентификатором собственного удостоверения. Внешние данные авторизации также несут адрес W и свежий DH-ключ либо шифротекст KEM для отдельной защиты будущего ваучера.

V формирует запрос к W. В него входят выбранный криптонабор, H_12, связывающий первые два сообщения, временный материал, ID_CRED_I и признак необходимости вернуть полное удостоверение U. W связывает отпечаток сеанса с идентификатором, находит политику для U и применяет её. Политика может ограничивать допустимые устройства, время или V, но её содержание оставлено за пределами проекта.

Ваучер имеет конкретного автора и адресата смысла. W сообщает U, что W авторизовал V. Целостность связывает ваучер с текущим обменом, идентификатором U и удостоверением V. Необязательная область разрешения понятна U и W, но остаётся непрозрачной для V. V переносит результат в сообщении 4.

В базовом EDHOC RFC 9528 делает четвёртое сообщение необязательным. В обычном ELA оно обязательно: именно там устройство получает доказательство сторонней авторизации. Только после его обработки проект считает U и V авторизованными для взаимодействия.

До этого момента V аутентифицирован перед U, но разрешение W ещё не дошло. Идентификатор U, напротив, уже дошёл до V и W. Доказательство владения ключом подтверждает контролёра удостоверения; оно не заменяет разрешение доверенного сервера на подключение через этого контролёра.

Защита идентичности не исключает доверенного получателя

Речь не о взломе защиты идентичности EDHOC. Перехватчик и неаутентифицированная сторона не получают те же данные; каналы защищены. Граница сформулирована в самом ELA: U раскрывает свою идентичность аутентифицированному V до того, как узнаёт, удастся ли весь процесс авторизации.

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

Одинаковое слово «ваучер» не означает одинаковый объект. RFC 8366 описывает подписанный производителем артефакт, который закрепляет устройство за владельцем и фиксирует сертификат домена. ELA использует сходную функцию в более компактной форме, но не этот формат. RFC 8995 строит BRSKI вокруг устройства, регистратора и сервиса производителя, отдельно разбирая аудит и приватность. RFC 9031 показывает иной сценарий входа в ограниченную сеть. Это контекст, а не источник порядка сообщений ELA.

Отказ означает выполненную проверку политики

W может распознать ID_CRED_I, но запретить подключение из-за идентичности, временного окна или неподходящего V. Тогда интерфейс возвращает HTTP 403 либо CoAP 4.03. W также может зашифровать для U полезную подсказку, например адрес другого V; текущий V передаст её в ошибке EDHOC Access denied.

Такой исход нельзя смешивать с сетевой неисправностью. Отказ политики, отсутствие удостоверения U, неверный ваучер и тайм-аут W происходят на разных этапах. Во всех случаях требуется иной ответ, а идентификатор успевает пройти разный путь. Один счётчик «неудачный handshake» скрывает и причину, и фактическое раскрытие.

Протокол LAKE на IETF 126 отмечает сохранение разных временных ключей для EDHOC и ELA, несколько сигналов готовности и решение председателей начать Last Call. Рабочая группа LAKE теперь оценивает общий документ. За память конкретной системы после отказа отвечает её оператор.

Квитанция, которая умеет забывать

Минимальная квитанция не обязана хранить исходный ID_CRED_I. Достаточны односторонний маркер попытки, отпечаток удостоверения V, версии якоря доверия и адреса W, H_12, версия политики, класс идентичности U и конечный результат: ваучер принят, политика отказала, перенаправление, ошибка удостоверения или тайм-аут.

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

Эта квитанция предложена Daniel Kade как редакционный вывод. Редакция 08 её не требует и прямо оставляет политику авторизации вне области стандарта. Поэтому развёртывание должно отдельно отвечать, кто аутентифицирован, кем авторизован, какое решение принято для U и что произошло с временной идентичностью.

Источники