Как отправить токен в запросах CoAP? - PullRequest
Новая
       42

Как отправить токен в запросах CoAP?

0 голосов
/ 14 октября 2019

Есть ли согласие относительно того, как отправлять токены в рамках запросов CoAP?

HTTP-клиенты делятся своими идентификационными данными / учетными данными через заголовок Authorization (или, в конечном итоге, Cookie *)Заголовок 1006 *) или реже как часть URL (например, веб-токен JSON, закодированный в base64url). В CoAP RFC нет эквивалента опции Авторизация .

Черновые профили для аутентификации и авторизации для ограниченных сред (например, OSCORE или DTLS ) полагается на базовый протокол безопасности для поддержания соединения с состоянием, и токен загружается на /authz-info один раз: 

      C                            RS                   AS
      | [-- Resource Request --->] |                     |
      |                            |                     |
      | [<---- AS Request  ------] |                     |
      |      Creation Hints        |                     |
      |                            |                     |
      | ----- POST /token  ----------------------------> |
      |                            |                     |
      | <---------------------------- Access Token ----- |
      |                           + Access Information   |
      | ---- POST /authz-info ---> |                     |
      |     (access_token, N1)     |                     |
      |                            |                     |
      | <--- 2.01 Created (N2) --- |                     |

Однако это не подходит для незащищенной среды (например,для разработки или в частной сети). Поскольку CoAP обычно находится поверх UDP, невозможно иметь «сеансы», поэтому мы не можем отследить, какой клиент загрузил какой токен. Я хотел бы избежать обсуждения полезности токена в незащищенном контексте.

Должен ли токен быть частью URI (то есть как опция Uri-Query или в Uri-Path)? ThingsBoard - это пример службы, в которой токен является частью Uri-Path, но я не уверен, что это лучший вариант. Кроме того, будет ли возможна отправка двоичного CBOR Web Token в Uri-Query без кодировки base64url?

1 Ответ

2 голосов
/ 14 октября 2019

В CoAP не предпринимаются попытки обеспечить аутентификацию пользователя без установленного уровня безопасности, а также нет условий для сеансов на уровне CoAP (что нарушило бы дизайн REST).

Как я понимаю,это было сознательное решение направить разработчиков к разработке RESTful и избежать передачи маркеров безопасности по незащищенным транспортам.

Для двух вариантов использования «во время разработки» можно ввести собственный CoAPопция в диапазоне экспериментального использования, например «65003 = Simulated-OSCORE-Key-ID» (где 65003 выбрано как критическое и небезопасное для пересылки). Хотя стек OSCORE не работает, в него можно вставить специальный составной идентификатор ключа OSCORE, а затем получить токен POST, используя его на этапах ACE. Очевидно, что эти конструкции не должны ни выходить из тестовой установки, ни в спецификации.

Частные сети считаются ненадежными («режим NoSec»), как и остальная сеть в CoAP. Это предположение, вероятно, может быть лучше понято в контексте принципа наименьшего уровня прав доступа, который делает установки, при которых все устройства (и процессы) в сети имеют одинаковый набор разрешений, крайне маловероятно.

...