Hello Andrej, Thanks for your interest in ACE!
On your main question: if one among the client (C) and resource server (RS) has to be picked up, I agree with you that it is more realistic for the RS to be a constrained device (what you call "use case 2").
Some broader feedback below:* In order to effectively instantiate the ACE framework, you need to use one of its *profiles*, as defining in details things like the communication and security protocols to use between C and RS.
As of today, those include the DTLS profile [1], the OSCORE profile [2], the MQTT profile [3], the EDHOC and OSCORE profile (work in progress) [4] and the Group OSCORE profile (work in progress) [5].
Is your intention to define a new profile of ACE?* The diagram shows an optional step where C verifies the AS' signature on the access token.
Even assuming that C has the AS' public key to do that, what is the benefit for C? Note that: i) C has just received an access token over a secure, mutually authenticated communication association with the AS; the access token is opaque to C; the actual consumer of the access token is RS, which indeed is going to verify the security armor that envelops the access token (a signature, in your case).
* The diagram shows a single CoAP request sent to RS, supposedly both: i) transporting the access token; and ii) targeting the protected resource at RS that C wants to access as per the access token. It is also said that C signs the CoAP request with its private key. However:
* How is the CoAP request actually signed by C and using what protocol/construct? Is this about having the CoAP request conveying a COSE signing object [6] as payload? Note that C and RS are not supposed to have a secure communication association yet.
* In ACE, the typical first interaction between C and RS works differently and according to three phases:
1. C uploads the access token to the authz-info endpoint of RS, through a dedicated an unprotected CoAP request.
2. C and RS establish a secure communication association. The details depend on the profile used, and it might be possible to combine this step with the previous one, by transporting the access token in one of the messages used to establish the secure association. In any case, the established secure association is bound to the access token.
3. C can send requests to a protected resource at RS, protecting those with the established secure communication association. If the request is actually granted as per what specified by the access token, then the request is processed by RS and the response from RS is going to be protected using the secure communication association.
It seems that the diagram is somehow trying to combine together all the three phases above into a single request-response exchange. This is different from what other profiles of ACE do, and I wonder if it can still meet all the goals expected when "bootstrapping" a C-RS relationship.
* Like it happens in other profiles of ACE, C is supposed to authenticate to RS during the establishment of their secure communication association and/or when protecting the messages sent to RS protected with that association. This does not require C to early authenticate to RS through a step like signing an early CoAP request.
Best, /Marco [1] https://datatracker.ietf.org/doc/rfc9202/ [2] https://datatracker.ietf.org/doc/rfc9203/ [3] https://datatracker.ietf.org/doc/rfc9431/ [4] https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/ [5] https://datatracker.ietf.org/doc/draft-ietf-ace-group-oscore-profile/ [6] https://www.rfc-editor.org/rfc/rfc9052.html#section-4 On 2025-04-14 09:36, Andrej wrote:
You don't often get email from asums...@gmail.com. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>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 toace-le...@ietf.org
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
