Authentication

[rogerioCesar]

Hello chrysn

is it possible to use a bearer header in a request?

[chrysn]

The CoAP community has moved away from bearer tokens for security reasons -- nothing in it prevents MITM attacks.

If you do insist that it's the right tool for your application, you can pick one of the experimental option codes (65000-65535, or register a lower one), and transport your bearer token there; the library won't stand in your way. This could even be justifiable from a security point of view in some cases, for example if you are using DTLS on the hops around a reverse proxy and then still want to identify the client to the origin server (I think).

Could you say a little more about the application you plan this for? Maybe we can work something out that's more aligned with the CoRE concepts, and even turn this into input that can shape the upcoming ACE OSCORE profile implementation.

[rogerioCesar]

My job, in fact, is to investigate authentication mechanisms for IoT scenarios. I am currently investigating how JWT can be useful in this regard in terms of security and performance. I did not find a way to load the token along with the request for access, as I am still new to the area. I would like to discuss some possibilities, if it were possible in aiocoap. I thank you for all your help.

[chrysn]

So The Way It's Supposed To Be (according to me, opinions obviously vary) is using CBOR Web Tokens (RFC8392). When they are issued in the way of the ACE-OSCORE profile (work in progress, https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11), they can be used as non-bearer tokens: The part that's transferred via unprotected channel in the setup phase is encrypted by the issuer to the server. When the client obtains the token, it gets its plaintext parts along with it.

Thus, both parties wind up with a shared secret from which to start an OSCORE context. A MITM can neither impersonate the server (as it can't decrypt the token and doesn't arrive at the right OSCORE context for the following exchange), nor can it impersonate the client (as the client never gives out the secret parts it received).

From my understanding, this is the most mature reasonably secure mechanism (given that that document is currently bubbling through the last round of IETF reviews, even though a few minor changes can still be expected). It provides no Perfect Forward Secrecy, but can be implemented in a very slim way.

The contenders are transporting the tokens in TLS (described in https://tools.ietf.org/html/draft-tschofenig-tls-cwt-01) and EDHOC (described in https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-01); both offer Perfect Forward Secrecy but involve asymmetric cryptographic operations. While EDHOC is already adopted by a working group, it's still in flux around how exactly it would interact with web tokens.

[rogerioCesar]

Got it.

I will look for more information on CWT. But for the time being, could you explain me better about: "[...], you can pick one of the experimental option codes (65000-65535, or register a lower one), and transport your bearer token there; [...] "found in your reply. How do option codes work? They go together with the request under "Message".

P.S .: As I said before, I am starting my studies now.

[chrysn]

How do option codes work? They go together with the request under "Message".

They are the "headers" of CoAP, see https://tools.ietf.org/html/rfc7252#section-5.4 and https://www.iana.org/assignments/core-parameters/core-parameters.xhtml for the registered one.

But as long as you don't have a very very very good application design reasons, this is not a route to follow for bearer tokens.

[rogerioCesar]

Thanks for the information, help and attention. I verified a possible operation using token and studied its infeasibility in the face of MITM attacks.