Andrej <asums...@gmail.com> 26.03.2025, 19:18 an ace Dear Madam or Sir, Currently I am working with RIOT as part of a mandatory internship in my university. Prof. Dr. Hahm one of RIOT's founders, is my supervisor and gave me a certain task related to the authentication described in RFC 9200. Today he suggested that I write you and email and ask a few questions regarding an implementation of the authentication process. Prof. Dr. Hahm and me thought of 2 different approaches: 1) our constrained device running on RIOT is the client. 2) our constrained device running on RIOT is the resource server. Prof. Dr. Hahm asked me to ask you which of these use cases is more likely to happen or more realistic? We thought that use case 2 is more realistic. After I read some of the RFC's regarding this topic, I came up with a sequence diagram for this authentication. I regarded Asymmetric Proof of Possession and essentially, my approach follows the idea that between client and authentication server a trust is established beforehand. Then the client generates an asymmetric key pair and sends the public key to the authentication server, which then responds with a signed CWT in which the public key is included as a claim. The client then sends this token via a CoAP request to the resource server and signs this request using his private key. The resource server can then verify both the signature of the request and of the CWT. When granting the resource to the client it can be then encrypted using the public key included in the claims. Or if the client is trusted a secure channel can be established too for granting the resource. This approach in more detail is described in the attached image. We think that this is a valid implementation of the described authentication flow, but we wanted to make sure that it is, thus, we send you this email, so that you can verify our approach and potentially point out problems we did not think about. We hope not to bother you too much and thank you very much in advance. With kind regards Andrej Sum-Shik
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
