Re: [core] Question about AEAD nonce uniqueness

[Mohit Sethi <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> on 
> behalf of Jim Schaad <[e-mail] 
> <mailto:[e-mail]>>
> Date: Monday 10 April 2017 at 19:09
> To: Mohit Sethi <[e-mail] 
> <mailto:[e-mail]>>, 'Core' <[e-mail] 
> <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" 
> <[e-mail] <mailto:[e-mail]>>
> 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:[e-mail]] *On Behalf Of *Mohit Sethi
>     *Sent:* Monday, April 10, 2017 4:51 AM
>     *To:* Core <[e-mail] <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]>
>     *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:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
> tel:[phone]                | http://www.energyharvesting.at/
>                                       | ATU68476614
>
>