Dear Marco, Thank you very much for your reply. I took a look at your mentioned rfc and draft and devised a new sequence of events in correspondence. Please excuse me for troubling you further, but I would like to confirm if my new sequence of event is in correspondence to your rfcs and security practices.
1) C requests an asymmetric proof of possession token from AS (C authenticates itself against AS) 2) AS returns token, in which the public key is included as a claim (cnf) 3) C uploads the token to RS via a post request. 4) RS validates the token using AS's public and extracts the public key which he uses later to verify C 5) C initiates an EDHOC handshake by generating an ephemeral key pair and sending the ephemeral public key 6) RS generates itself an ephemeral key pair and sends the public ephemeral key to the Client. 7) Client computes the shared secret and runs a hkdf to derive the session key. And sends a an encrypted request for the resource, he also authenticates this message using his private proof of possession key. 8)RS verifies that the client is legitimate. If he trusts the client he also derives the session key and returns the resource in an encrypted way. (For further communication they use AEAD). If the client also wants to verify the RS's authenticity, he requests a public key from AS. He can tell in 5) that he wants the RS to prove itself. So in 6) the RS can authenticate using tje private key associated with the public key provided by the AS to the client. This summarises my understanding of how to implement the whole authentication process. I saw in your draft that the token was send in step 7 and not in step 3. Is my approach still valid, I thought it makes more sense to send the token as soon as possible. Because if the token is not legitimate RS can immediately cut the communication. Sorry to bother you again, thank you very much for the provided information and also please excuse any inconvenience I have caused so far for you. With kind regards Andrej On Tue 22. Apr 2025 at 02:32, Marco Tiloca <[email protected]> wrote: > Hello Andrej, > > Please see inline. > > Best, > /Marco > > On 2025-04-16 13:02, Andrej wrote: > > > You don't often get email from [email protected]. Learn why this is > important <https://aka.ms/LearnAboutSenderIdentification> > > > > ---------- Forwarded message --------- > From: Andrej <[email protected]> > Date: Wed 16. Apr 2025 at 11:29 > Subject: Re: [Ace] Implementation RFC 9200 > To: Marco Tiloca <[email protected]> > > > 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. > > > ==>MT > > Like 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. > > > ==>MT > > I 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? > > <== > > ==>MT > > Note 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? > > > ==>MT > > See 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 <[email protected]> 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 [email protected]. Learn why this is >> important <https://aka.ms/LearnAboutSenderIdentification> >> >> Andrej <[email protected]> >> 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 -- [email protected] >> To unsubscribe send an email to [email protected] >> >> >> -- >> 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 >> <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 -- [email protected] > To unsubscribe send an email to [email protected] > > > -- > 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 > >
_______________________________________________ Ace mailing list -- [email protected] To unsubscribe send an email to [email protected]
