Hi Marco: Thank you so much for your review. Regarding about message correlation, I would like to add some additional comments and questions about this discussion. Besides a EAP we have also an EAP lower-layer that transports, in turn, EAP with a set of transport requirements (section 3.1 in RFC 3748).
Regarding your interesting comment, I think multiple EAP authentications with the same EAP peer might be possible but the question is how it might affect to EDHOC. EAP and lower layers provides a way to avoid mixing EAP authentication sessions from the same EAP peer. My understanding from RFC 9528 and CoAP transport is that since there are different ways of transporting CoAP it is better to prepend the identifiers as general rule. In the case of EAP, prepending the identifiers would be to avoid that EAP packets from different parallel EAP authentications can be mixed and confuse the EAP peer since it cannot distinguish they different request belong to different EAP authentication and hence EDHOC is also confused, correct?. In my mind, each EAP authentication session transports a EDHOC session, and each EAP session is distinguishable one from another hence each EDHOC session. would do you foresee a problem for EDHOC with this? In any case, let’s see what others opinions (because it is true that it might be difficult to extract this conclusion from EAP RFC text based only with the definition of the Identifier field). Best Regards. El 4 oct 2024, a las 14:18, Marco Tiloca <marco.tiloca=40ri...@dmarc.ietf.org<mailto:marco.tiloca=40ri...@dmarc.ietf.org>> escribió: Hello Dan, Thanks for considering my comments. Please see inline below, where I have kept only the remaining open point about message correlation. Best, /Marco On 2024-10-04 10:18, Dan Garcia Carrillo wrote: You don't often get email from garcia...@uniovi.es<mailto:garcia...@uniovi.es>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Hi Marco, Thank you very much for the review. Please, see comments inline. Best regards. ~snip * "For duplication and message correlation, EAP has the Identifier field, which allows both the peer and authenticator to detect duplicates and match a request with a response." As I understand Section 4.1 of RFC 3748, the Identifier field works well for correlating an EAP-Request with the corresponding EAP-Response. However, I don't understand how the EAP-EDHOC server can use the Identifier field here in a way that: - is consistent with the rules in Section 4.1 of RFC 3748; and - ensures that the EAP-EDHOC peer recognizes the EAP-Requests transporting EDHOC message_2 and message_4 as pertinent to the same EDHOC session started by the EAP-Response transporting EDHOC message_1. In other words, when the EAP-EDHOC peer receives an EAP-Request transporting an EDHOC message, how does the EAP-EDHOC peer retrieve the protocol state for the EDHOC session started with the previously sent EDHOC message_1? See also Section 3.4.1 of RFC 9528 for more details on message correlation in EDHOC. In order to build that correlation among EDHOC messages belonging to the same EDHOC session, RFC 9528 suggests a number of possible ways. One of those consists in prepending EDHOC messages with the EDHOC connection identifiers, as appropriate with the underlying transport and its intrinsic message correlation properties. As far as I can tell, EAP-EDHOC is akin to the EDHOC reverse message flow when EDHOC messages are transported in CoAP messages (see Appendix A.2.2 of RFC 9528). In the same spirit, you may consider to extend the format of the EAP-EDHOC Request Packet, later in Section 4.1. The additional content would be the EDHOC connection identifier C_I of the EAP-EDHOC peer, which allows the EAP-EDHOC peer to retrieve the protocol state of the correct EDHOC session when receiving an EAP-EDHOC Request. Since such a connection identifier is a hint and is *not* part of the actual EDHOC message, an appropriate place to specify it is right after the "Flags" byte. In particular, it can work with the following two new fields, after the “Flags” byte. - CID Length (1 byte): its value is the length Z in bytes of the following field CID. - CID (Z bytes): its value is the binary representation of a CBOR data item, which encodes the connection identifier C_I as per Section 3.3.2 of RFC 9528. If the EAP-Request is specifically EDHOC Start, then the CID field can specify the CBOR Simple Value True (0xf5) as a sentinel value (since, at that point, no C_I has been allocated as EDHOC connection identifier of the EAP-EDHOC peer yet). This is an interesting subject. We will surely work on improving the explanation. There are several points to have into account. 1) EAP is a lock-step protocol which means, 1) only supports a single packet in flight, so other than the initial Request, a new Request cannot be sent prior to receiving a valid Response. 2) If we look now at how the Identifier works in EAP. According to RFC3748 • "The Identifier field is one octet and aids in matching Responses with Requests. " • " [...] the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations." This allows for a single EAP authentication in a session with separate Identifier space between sessions between the EAP peer and the authenticator. Taking into account this, we think the text applicable regarding EDHOC message correlation would be: RFC9528 -- 3.4.1. EDHOC Message Correlation [...] "Note that correlation between EDHOC messages may be obtained without transport support or connection identifiers, for example, if the endpoints only accept a single instance of the protocol at a time and execute conditionally on a correct sequence of messages." So, we understand that by relying on this, the correlation should be done correctly. ==>MT Thanks for the additional information. I think I was missing that the main intent is to run at most one EDHOC session at the time. That is, until the current EDHOC session fails or is completed successfully, the same EAP-EDHOC Peer is not involved in further, parallel EDHOC sessions. If that's always the case, then I can see that the current design is good already, as building on the EAP correlation mechanism. I am not sure if it's relevant, but you may still want to be flexible and admit (future) cases where the same EAD-EDHOC Peer runs multiple EDHOC sessions in parallel. If so, I think that it be can easily achieved by modifying the format of the EAD Request as follows. * In the Flags field, the currently reserved bit 2 can be defined to use. * If the bit value is 0, then you have the current EAD-EDHOC Request as-is. * If the bit value is 1, then there is an additional field between the Flags field and the EDHOC Message Length field. The additional field is the binary representation of a CBOR data item, which encodes the EDHOC connection identifier C_I as per Section 3.3.2 of RFC 9528. (Note that the CBOR item is self-contained and does indicate the length of the represented C_I. In this latest proposal, the absence of C_I is indicated by the flag bit set to 0 instead of by the 1-byte CID Length field with value 0 in the previous proposal (such a CID Length field becomes then unnecessary altogether). But again, if the intent is to not admit parallel sessions of EDHOC in EAP ever, then the current design is essentially fine. Best, /Marco <== Just want to thank you for the thorough review. Best regards, -- 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://www.ri.se/> _______________________________________________ Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org> To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-le...@ietf.org> -- Dan García Carrillo --------------------- Departamento de Informática, Área de Telemática, Universidad de Oviedo 2.7.8 - Escuela Politécnica de Ingeniería, 33204, Campus de Viesques, Gijón Tel.: +34 985182654 (Ext. 2654) | email: garcia...@uniovi.es<mailto:garcia...@uniovi.es> -- 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://www.ri.se/> <OpenPGP_0xEE2664B40E58DA43.asc>_______________________________________________ Emu mailing list -- emu@ietf.org<mailto:emu@ietf.org> To unsubscribe send an email to emu-le...@ietf.org<mailto:emu-le...@ietf.org> Dr. RAFAEL MARÍN LÓPEZ Assistant Professor Dept. Ingeniería de la Información y las Comunicaciones r...@um.es<mailto:r...@um.es> T (+34) 868 88 8501 [logo UMU]<https://www.um.es> [logo euniwell]<https://www.euniwell.eu/> [logo hr]<https://www.um.es/web/hrs4r> [logo CMN]<https://www.campusmarenostrum.es/>
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
