Using EDHOC reverse message flow #36
Conversation
|
I think it is a good idea in that it also may help in the advertisement of lake-authz support. My first thought is about the practicality of the Thus, so far we have the following motivations / use cases for enabling a reverse message flow:
|
|
Sounds viable to me if #21 is viable. For the broadcasting aspect, it may also be an option to broadcast a message_1. Sure, the EDHOC machinery may only advance for one selected peer (especially, sending two message_3 may be dangerous, even though I'm not sure why precisely, as long as all G_Y are distinct), but is there any harm done in decrypting (but not verifying) message_2, and then arriving at a binary decision to advance (and commit to the outcome of 5.3.3 step 6) only if ID_CRED_R and EAD_2 contains the right values? |
|
For the broadcasting aspect, it may also be an option to broadcast a
message_1. Sure, the EDHOC machinery may only advance for one selected
It sounds harmless to do the survey in parallel, if all proxies lead to
different networks. If they lead to the same network, then you've just
created congestion.
|
|
Amplification leading to congestion can be an issue with any multicast that causes later traffic (no matter whether it's an empty POST or a message_1). A message_1 in there may even help keep the traffic low, because if W can see that requests from different V contain the same message_1, can respond positively to the V that may enroll it, and tell the others off. |
|
We are discussing two different kinds of role reversal, change of EDHOC roles, or change of CoAP roles. This gives 4 cases:
Broadcast/multicast/etc. of trigger seems useful at least in case 1, as discussed above, and does not seem harmful in case 3. However, broadcast of message_1 may be an issue. It may be tempting for applications to use multiple sessions resulting from different endpoints responding to the same message_1. The security analyses made for EDHOC may not apply if G_X is reused. Moreover, the same connection identifier C_I intended to be used by the Initiator to distinguish between sessions is now used by the Initiator in multiple sessions (which also means special care needed for OSCORE sessions for which different Sender/Recipient Identifiers are required). Can we restrict multicast to the trigger message, or what functionality / optimization would be lost if we do? |
|
In a design meeting, we discussed a fifth scenario:
Here is what I envision in this scenario: Advertisement of lake-authz capabilityV may broadcast support for lake-authz using some network advertisement mechanism provided by the lower layer, e.g., link layer beacons.
The exact formatting of the When U receives an advertisement containing either of these fields, this information should be made available to the application, which may use it to prioritize the selection of a suitable V. |
The "using X multiple times" aspect is why we should stop here. If one of the security teams could re-do their analysis assuming X reuse (with a check that it's only ever used with different Y), we can resume this, and then we can still fix this (because the direction where C_I is relevant has CoAP request-response binding, and then if C_I is relevant at the OSCORE level, the OSCORE identifiers can be changed in a combined CoAP/message 3 – but only if the X reuse holds). Broadcast on the network layer can still be useful without "multicast EDHOC", but would be more of an anycast use – if more than one device responds, that response would be rejected, and the next device waits for the next multicast that has a new G_X.
The way I'm modeling those advertisements in CoAP-over-GATT is that they are a multicast requests in the CoAP sense. That way, they fall directly into the (11) flow and don't need to be regarded as out-of-band communication. That may or may not work for the link layers you have in mind. |
|
The "broadcast on the network layer" is now also an example in https://datatracker.ietf.org/doc/draft-amsuess-core-coap-over-gatt/07/ (section 4.2). Especially in combination with NIPC, this looks promising as a way to keep radio traffic for unenrolled devices low. But the way it is presented there right now, the default U=I setup holds, but I acts as the CoAP server, so it's reverse flow. It does technically send the first message, but that is a one-shot message expressed as an unsolicited response. (One might also do things subtly differently and invent a new flow, where I POSTs msg_1 with No-Response and waits for R to reverse roles mid-flight, which I don't see anything problematic with, but the phrasing as "it's a response to a POST the client didn't send" works well and is easier on the EDHOC-CoAP side of explanations). |
|
An appendix explaining use with the EDHOC reverse flow was added and merged in #41. I believe this PR can now be closed. |
For discussion.
Instead of sending message_1, U sends a trigger over multicast/broadcast which leads to V sending message_1 to U. This allows a discovery process where EAD_1 could contain an EAD item specified in lake-authz, allowing advertisement of the use of the authz protocol, or certain deployment of authz, independent of underlying layer. This allows U to detect gateways supporting the authz protocol ,or certain deployment, and provide such information to W using the "hints" and allow an effficient deployment.
EDHOC messages then follow with EAD_x having the content of EAD_(x-1) of the forward flow.
Note that ID_CRED_R, sent in message_2, can now be empty because V will now run VREQ/VRES with W and in this case CRED_U can be returned without changing the basic identity protection assumption of EDHOC.