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] <mailto:[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
