Clarify uniqueness requirements

Tag: WGLC

Göran Selander wrote (https://mailarchive.ietf.org/arch/msg/6tisch/fWK4i3bs3r4VmFCkSoGzgtlWSuo): Section 3

"pledge identifier"

The assumptions and application of OSCORE made in this draft requires that the pledge > identifier is globally unique. Although the first sentence states that the pledge identifier uniquely identifies the pledge, there is no normative text in this section and it may not be understood that uniqueness is a requirement.

(For this discussion, pledge identifier == ID Context):

In oscore-13, Section 3.3 states:

"To ensure unique Sender Keys, the quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be unique, i.e. the pair (ID Context, Sender ID) SHALL be unique in the set of all security contexts using the same Master Secret and Master Salt."

While we have fixed the Sender ID to 0x00, I believe this OSCORE requirement is still valid in our case. I am missing the need for requiring global uniqueness if the ID Context is unique in the "set of all security contexts using the same Master Secret and Master Salt". What am I missing?

That said, EUI-64 is globally unique and when used as the pledge identifier / ID Context, results in unique (Master Secret, Master Salt, ID Context, Sender ID) no matter if the Master Secret is reused.

My point is that this global uniqueness of EUI-64 comes as a nice-to-have when provisioning the devices, but that a random string that meets the requirement cited above is still good enough (and increases privacy by not sending the vendor-specific EUI-64).

If my understanding on the above is correct, I can clarify the text.

The last sentence says that the identifier may be "e.g. a random string", without any further details. Please include all relevant requirements on the pledge identifier in this section so readers can get the complete picture, make a reference to a security consideration providing the explanation (see below), and apply the requirements to the example with random strings.

Yes, makes sense to clarify this in security considerations referring to the OSCORE uniqueness requirements.

Comments (5)