Re: [Lake] Protocol runs

[Göran Selander <[e-mail]>]

Hi Carsten,

I’ll start, others may want to fill in. There are several potential questions here.

The question about protocol security has as far as I understand been addressed by the different analysis efforts (people are welcome to confirm this). There are no issues with concurrent protocol runs. The attacker can cause the protocol to fail or not terminate, but if the protocol completes the security properties hold.

The question about an attacker manipulating a protocol message causing the protocol to fail, you use the term “vulnerable initial phase”, this phase extends throughout the protocol run. If message integrity fails then the protocol is discontinued. This is by design and has some good security properties, for example security guarantees even with short MACs.

The question how robust the exchange is depends mainly on properties of the underlying transport.

> How do packets know that they belong to a specific protocol run?

The underlying transport in the recipient endpoint knows, either by means of other data fields, e.g. the CoAP Token received by a CoAP client, or else with the use of an explicit identifier prepended to the EDHOC message, see section 3.4.1 about message correlation:

https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-19.html#ci-edhoc

If the EDHOC message received is not a correct expected message this results in failure to verify the integrity and that the protocol is discontinued:

“EDHOC messages SHALL be processed according to the current protocol state.”

More details in Section 5.1:
https://www.ietf.org/archive/id/draft-ietf-lake-edhoc-19.html#name-message-processing-outline


> what is the instance out of potentially several protocol runs that is actually aborted?

The instance of the protocol run to which the transport associates the message, as described above.


> What does an attacker need to know to find and abort a vulnerable in-progress instance?

Any EDHOC exchange that has not completed is susceptible to manipulations, but underlying layers may provide some robustness.


> How could two concurrent protocol runs inadvertently (or deliberately) interfere with each other?

For example, by manipulating the prepended connection identifiers, which would lead to an EDHOC message being associated to the wrong protocol state, failed integrity verification and discontinued protocol.

>  Where are the transitions from a vulnerable initial phase to more robust phases where it is harder to disturb the protocol?

After EDHOC is completed, when the keying material can be persistently stored, as described in the message processing (after message_3 for the Responder, and when message_4 or an application message has been verified by the Initiator, see sections 5.4 and 8.1).

Would be interesting to learn if things can be handled in a different way and still preserve the desirable security properties.  Authentication, like baseball, “ain’t over till it’s over”.

Hope that helps,
Göran

From: Lake <[e-mail]> on behalf of Carsten Bormann <[e-mail]>
Date: Tuesday, 7 February 2023 at 18:57
To: [e-mail] <[e-mail]>
Subject: [Lake] Protocol runs
Today’s brief discussion of the state machine diagrams brought up an observation in my mind that is excellent to demonstrate my ignorance:

The state machine only shows one (essentially linear) protocol run.
How do packets know that they belong to a specific protocol run?
(This is a genuine question; the answer may be trivial.)

When a bad packet shows up and EDHOC reacts by aborting, what is the instance out of potentially several protocol runs that is actually aborted?
What does an attacker need to know to find and abort a vulnerable in-progress instance?
How could two concurrent protocol runs inadvertently (or deliberately) interfere with each other?

A related question is how protected a protocol run is at any point in time.
Where are the transitions from a vulnerable initial phase to more robust phases where it is harder to disturb the protocol?
(Göran: “You need to transition into the persistent state”.)

Stephen pointed out that these questions are quite relevant to security analyses of the protocol, so if you can point out how a security analysis addressed this, that would be interesting.

Grüße, Carsten

--
Lake mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lake