The selection of S_X is done by party X. This means that all they need to do is to generate – either randomly or deterministically – some identifier which is currently unique for them.
The easiest way to do this is to have an array of N security contexts. Choose the first slot in the array which is empty and use that index as your identifier. If the array is full, then either grow the array or scavenge a security context which has not been used in a while and use that slot. This allows for identifiers that are unique to the party and still very small. The only time that one would need large random identifiers is when the keying material is generated by a third party such as the PSK version of EDHOC where the common PSK needs to be identified for both parties. I also do not have the same problems with collisions that Göran and others have. I am willing to try multiple keys in the event of a collision and only the correct one will work. This is not unusual in some cases already in other environments. Jim From: Mohit Sethi [mailto:[email protected]] Sent: Thursday, April 13, 2017 2:46 AM To: Göran Selander <[email protected]>; 'Core' <[email protected]>; [email protected] Cc: Jim Schaad <[email protected]>; Christian Amsüss <[email protected]> Subject: Re: [core] Question about AEAD nonce uniqueness Hi Göran, Jim and Christian Thanks for responding to my question. @Göran: both 1) use EDHOC or 2) generate large random identifiers, are the same thing. How are they any different? I went through EDHOC draft and it says that sender id is S_V which is variable length session identifier (= generate large random identifier). I am afraid simply waving off the problem as out of scope may lead to some (many) inter interoperability issues. If the Sender ID is variable length, different manufacturers may implement it very differently and could cause collision with just 2-3 devices. If they are generated in software at run time, you can still do something about it, but if it is burnt into the device, then there is no way to recover from . At the very least there could be better guidance. I also think it would make sense to have a minimum length specified and some recommendations/guidelines on how it is generated. I would also like to know what are the concrete affects of a collision? --Mohit On 04/11/2017 08:43 AM, Göran Selander wrote: Hello Mohit, Christian and Jim already provided answers, let me just provide pointers to the relevant sections. OSCOAP: — The requirements on the security context parameters are here: https://tools.ietf.org/html/draft-ietf-core-object-security-02#section-3.3 Two methods for establishing unique sender IDs are presented: 1) use EDHOC or 2) generate large random identifiers. The former allows for the use of short sender IDs. Multicast OSCOAP: — In Multicast OSCOAP (Secure group communication for CoAP) the requirements on the security context parameters are here: https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01#section-2 It is the responsibility of the Group Manager to establish and manage the security context, which includes the sender IDs, but how the assignment is done is out of scope. The uniqueness of sender IDs in this draft follows from OSCOAP, but since you asked I think we should add a sentence to this draft stressing that. Göran From: core <[email protected] <mailto:[email protected]> > on behalf of Jim Schaad <[email protected] <mailto:[email protected]> > Date: Monday 10 April 2017 at 19:09 To: Mohit Sethi <[email protected] <mailto:[email protected]> >, 'Core' <[email protected] <mailto:[email protected]> >, "[email protected]" <[email protected] <mailto:[email protected]> > Subject: Re: [core] Question about AEAD nonce uniqueness There is not a problem with dealing with nonce uniqueness in this draft because each entity is going to be assigned to a unique key for transmissions. The transport key is derived from the PSK and the sender ID. Sender IDs will be unique based on the enrollment protocol in the group as each entity will have a unique identifier. Jim From: core [mailto:[email protected]] On Behalf Of Mohit Sethi Sent: Monday, April 10, 2017 4:51 AM To: Core <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: [core] Question about AEAD nonce uniqueness Hi OSCoAP authors I was trying to read the OSCoAP and 6tisch minimal security drafts. I have a question about the AEAD nonce uniqueness. RFC 5116 says that: When there are multiple devices performing encryption using a single key, those devices must coordinate to ensure that the nonces are unique. A simple way to do this is to use a nonce format that contains a field that is distinct for each one of the devices So my obvious question is how is the AEAD nonce uniqueness ensured. The PSK is known to at least two parties (more in case of some uses such as multicast OSCoAP https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap-01)?? The draft currently says that AEAD Nonce uniqueness is ensured with sequence numbers and sender context which is essentially the sender ID. But how do you ensure that the two parties have different sender ID. Especially since sender ID is not fixed length. I guess there will be other problems in case of sender ID collisions? as Sender IDs are currently used, they are mutually agreed-upon like the rest of the security context (key, algorithm etc); in other words, they are explicitly given to a device by the mechanism that also distributes the key. Best regards Christian -- Christian Amsüss | Energy Harvesting Solutions GmbH founder, system architect | headquarter: mailto:[email protected] | Arbeitergasse 15, A-4400 Steyr tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/ | ATU68476614
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
