Hello Andrej, Please see inline.
Best, /Marco On 2025-04-16 13:02, Andrej wrote:
You don't often get email from asums...@gmail.com. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>---------- Forwarded message --------- From: *Andrej* <asums...@gmail.com> Date: Wed 16. Apr 2025 at 11:29 Subject: Re: [Ace] Implementation RFC 9200 To: Marco Tiloca <marco.til...@ri.se> Dear Marco, Thank you very much for the thorough reply.Validating the token on the client side was considered optional from the start, but your explanation makes sense, hence we would omit this.
==>MT Thanks. <==
For the step of verifying and receiving the resource, the main idea was the following: The client sends a get or post request to the RS this request includes the token and a short message signed by the private key associated with the token.
==>MTLike mentioned in the previous mail, there are fundamentally two ways for uploading the access token to RS:
* The access token is (part of) the payload of a POST request to the /authz-info endpoint; or
* The access token is conveyed by a message of the key agreement protocol used by C and RS to establish their secure communication association bound to the access token.
Within this mindset, one can define a new profile of ACE and therefore the details about the uploading of the access token and about the secure communication association between C and RS.
Is your intention to define a new profile of ACE? If so, how does your construct match with the above?
Note that relying on a GET request (to /authz-info or another endpoint) is not quite right, as you do want to transfer a payload to RS, and the intended operation for RS to perform does not match with the safe and idempotent semantics of the GET method.
<==
This follows the asymmetric proof of possession paradigm, that the token essentially acts as a way for the RS to trust the public key and trust that it is associated with client a. Then the RS verifies the token and if its valid it extracts the public key (one of the claims) it uses this to verify the signature of the request.
==>MTI understand the principle. Beyond the high-level idea, defining something concrete and actionable consists in specifying a profile of ACE, such as one of those mentioned in my previous mail.
<==
If this is also valid the RS generates and ephemeral key pair and does a elliptic curve deffie hellman (with the ephemeral private key and the public key of the client )and a HKDF (HMAC-based Extract-and-Expand Key Derivation Function) to derive a symmetric key pair used for the session.
==>MT A few comments:* What "public key of the client"? The one just received by RS is used for verifying the Client's signature, hence it is intended for signature verification.
Even though there are curves that make an asymmetric key pair usable for both signing and key agreement operations, the same key pair should not be used for both things unless otherwise proven to be secure in the particular context at hand.
I think that, to achieve what you describe here, C should also provide RS with a separate ephemeral public key to use for key agreement.
* If I understand correctly, the first request that C makes to the application resource at RS is not confidentiality protected, which is not desirable.
<==
It then sends the resource to the client encrypted with the symmetric key and also sends the ephemeral public key. Then the client uses his private key and the ephemeral public key to derive the same symmetric key to decrypt the message containing the resource. (Temperature measured by the constrained device for example).
==>MT How does C authenticate RS? <== ==>MTNote that there is a work-in-progress profile of ACE [4] that relies on the Diffie-Hellman-based key agreement protocol EDHOC (RFC 9528) used between C and RS.
By using standard protocols, that profile achieves an outcome aligned with what (I believe) you have in mind, i.e., C and RS run an authenticated, ephemeral-ephemeral Diffie-Hellman exchange, produce a shared secret as output, and ultimately derive symmetric keying material to securely communicate using OSCORE (RFC 8613).
I suggest to have a look :-) [4] https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/ <==
(This was my idea for the process, I found many of these concepts in this or other RFCs. For reference maybe I did not explain this well in my last message, before this the client generates an asymmetric key pair and sends a message to the AS to issue a token for his public key. For the AS to trust the client, the AS and the Client use a trusted channel or the client logs into a system using credentials (similar to keycloak)) As I am still an undergraduate student, I am really new to this, so please excuse me if I have mixed something up. May I ask you if this setup is valid? You mentioned that more messages are actually necessary for this process, may I ask why? Is there a problem with this idea maybe that I have not noticed?
==>MTSee the few comments above. More generally, it is possible to have a better look/analysis of a protocol once more details are specified, e.g., exact messages exchanged and their content.
<==
Thank you very much again for your reply and I am looking forward to hearing from you soon.With kind regards Andrej Sum-Shik * * On Wed 16. Apr 2025 at 02:30, Marco Tiloca <marco.til...@ri.se> wrote: 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/ <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc9202%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105296355%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=d0fWSqJiBsy05uXyVyMXppos7pSXKKcToSQ0Gn8kGG4%3D&reserved=0> [2] https://datatracker.ietf.org/doc/rfc9203/ <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc9203%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105317676%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=Fw0xrwnvcBC8SbmKqmaKGvC86VBE4nKFkIywDz5QPPU%3D&reserved=0> [3] https://datatracker.ietf.org/doc/rfc9431/ <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc9431%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105330479%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=8rt1hbN5MCZgwZhlee2MX4BpilQq0BdGm9uKPpAcRVE%3D&reserved=0> [4] https://datatracker.ietf.org/doc/draft-ietf-ace-edhoc-oscore-profile/ <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-edhoc-oscore-profile%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105342740%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tDf9Wr7LTT5sL%2FB2DeeKniYrRT7jxJqJfrRBePa7Kpw%3D&reserved=0> [5] https://datatracker.ietf.org/doc/draft-ietf-ace-group-oscore-profile/ <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-group-oscore-profile%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105354707%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=1BJ7H%2BAijvM7qlEJIXfctW%2BpdwT%2BqlNPt6xTzD%2BCZSY%3D&reserved=0> [6] https://www.rfc-editor.org/rfc/rfc9052.html#section-4 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9052.html%23section-4&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105367179%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=88L%2BTV%2FZHCLVpCo%2BT068cMYSfELouKHvek0Cs7zs8Ag%3D&reserved=0> 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 TilocaPh.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 <https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&data=05%7C02%7Cmarco.tiloca%40ri.se%7C7fb1eefbeaaa4cef503308dd7cd63510%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638803985105380192%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=cPPz2pJywrTN2pGU75RBpEhzC9wq1ZEtkJCA4WnQc0E%3D&reserved=0> _______________________________________________ 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
