Re: [core] Question about AEAD nonce uniqueness

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

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