---------- 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. 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. 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. 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. 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). (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? 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/ > > [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 to ace-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 > >
_______________________________________________ Ace mailing list -- ace@ietf.org To unsubscribe send an email to ace-le...@ietf.org
