[core] Question about AEAD nonce uniqueness

[Mohit Sethi]

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?

--Mohit

[Christian Amsüss]

Hello Mohit,

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.

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

[Jim Schaad]

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:core-***@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <***@ietf.org>; ***@ietf.org
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?

--Mohit

[Göran Selander]

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 <core-***@ietf.org<mailto:core-***@ietf.org>> on behalf of Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>
Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi <***@ericsson.com<mailto:***@ericsson.com>>, 'Core' <***@ietf.org<mailto:***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
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:core-***@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <***@ietf.org<mailto:***@ietf.org>>; ***@ietf.org<mailto:***@ietf.org>
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

[Mohit Sethi]

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

Post by Christian Amsüss
Hello Mohit,
Christian and Jim already provided answers, let me just provide
pointers to the relevant sections.
—
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.
—
In Multicast OSCOAP (Secure group communication for CoAP) the
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
Date: Monday 10 April 2017 at 19:09
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
*Sent:* Monday, April 10, 2017 4:51 AM
*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
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
tel:[phone] | http://www.energyharvesting.at/
| ATU68476614

[Jim Schaad]

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:***@ericsson.com]
Sent: Thursday, April 13, 2017 2:46 AM
To: Göran Selander <***@ericsson.com>; 'Core' <***@ietf.org>; ***@ietf.org
Cc: Jim Schaad <***@augustcellars.com>; Christian AmsÃŒss <***@energyharvesting.at>
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 <core-***@ietf.org <mailto:core-***@ietf.org> > on behalf of Jim Schaad <***@augustcellars.com <mailto:***@augustcellars.com> >
Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi <***@ericsson.com <mailto:***@ericsson.com> >, 'Core' <***@ietf.org <mailto:***@ietf.org> >, "***@ietf.org" <***@ietf.org <mailto:***@ietf.org> >
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:core-***@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <***@ietf.org <mailto:***@ietf.org> >; ***@ietf.org <mailto:***@ietf.org>
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:***@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr

tel:[phone] | http://www.energyharvesting.at/

| ATU68476614

[Göran Selander]

Hi Mohit,

(Also including ACE since EDHOC belongs there.)

Thanks for taking the time and reviewing OSCOAP and EDHOC.

Again, Jim was quicker to answer, and in fact this is one of the features of EDHOC that was proposed by him. Let me give a background, maybe that helps.

One of the main design criteria for OSCOAP and EDHOC is to make the protocol messages small, since many performance aspects are related to message sizes.

Whereas EDHOC is only expected to be run once in a while (maybe just once), OSCOAP may potentially be used with in every CoAP message, so in particular for OSCOAP we have tried to turn over every byte. The current overhead of OSCOAP for a typical CoAP message exchange is 13 bytes in the request and 9 bytes in the response and that includes the 8 bytes of MAC in each message. This message size calculation includes a Sender ID of 1 byte. Hence to get low overhead in particular requires a short Sender ID. See https://tools.ietf.org/html/draft-mattsson-core-security-overhead-00#section-2.11

Note that the Sender ID is only significant for a particular master secret and the use of short identifiers (addressing your comment on "minimum length") is described in the OSCOAP section I referenced below.

If the Sender ID coincides with a Sender ID used with another security context that is not a security issue, but a device receiving a message for which it has multiple security contexts with the same Sender ID would have to try more than once before finding the right (addressing your comment on "concrete effects”). Jim doesn’t have a problem with that, we wanted to try to avoid it. But, just in case, we should describe the processing handling this, I note that as an issue.

For two peers autonomously establishing a security context, neither of the nodes have knowledge about the identifiers used by the peer in its various OSCOAP contexts with other parties. Therefore, in EDHOC, as described by Jim, each party can select its own locally unique short session identifier, and when EDHOC is used with OSCOAP this session identifier becomes the Sender ID, see
https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-05#appendix-B.2
(addressing your comment on "how it is generated")

Having short session identifiers also optimises the EDHOC messages, since they short (of course) but also since the nonces N_U, N_V (which are longer) only need to be sent once, in comparison with a protocol combining the function of nonce and session identifier.

If there is a trusted third party such as the Group Manager in a multicast setting (as referenced below) then the assignment of identifiers in the set of devices sharing a common context can be unilaterally decided by the GM and the size of identifiers optimised (addressing your comment on "out of scope" - which in my mail only referred to this case). Note that there is no additional complication in making this assignment since it just has to be locally unique for that group.

Did that make things more clear? Do you think further clarifications are needed in the drafts?


Thanks
Göran




From: 6tisch <6tisch-***@ietf.org<mailto:6tisch-***@ietf.org>> on behalf of Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>
Date: Thursday 13 April 2017 at 16:39
To: Mohit Sethi <***@ericsson.com<mailto:***@ericsson.com>>, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, 'Core' <***@ietf.org<mailto:***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Cc: 'Christian AmsÃŒss' <***@energyharvesting.at<mailto:***@energyharvesting.at>>
Subject: Re: [6tisch] [core] Question about AEAD nonce uniqueness

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:***@ericsson.com]
Sent: Thursday, April 13, 2017 2:46 AM
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>; 'Core' <***@ietf.org<mailto:***@ietf.org>>; ***@ietf.org<mailto:***@ietf.org>
Cc: Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>; Christian AmsÃŒss <***@energyharvesting.at<mailto:***@energyharvesting.at>>
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 <core-***@ietf.org<mailto:core-***@ietf.org>> on behalf of Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>
Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi <***@ericsson.com<mailto:***@ericsson.com>>, 'Core' <***@ietf.org<mailto:***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
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:core-***@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <***@ietf.org<mailto:***@ietf.org>>; ***@ietf.org<mailto:***@ietf.org>
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:***@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr
tel:[phone] | http://www.energyharvesting.at/
| ATU68476614




From: Mohit Sethi <***@ericsson.com<mailto:***@ericsson.com>>
Date: Thursday 13 April 2017 at 11:45
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>, 'Core' <***@ietf.org<mailto:***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Cc: Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>, Christian AmsÃŒss <***@energyharvesting.at<mailto:***@energyharvesting.at>>
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 <core-***@ietf.org<mailto:core-***@ietf.org>> on behalf of Jim Schaad <***@augustcellars.com<mailto:***@augustcellars.com>>
Date: Monday 10 April 2017 at 19:09
To: Mohit Sethi <***@ericsson.com<mailto:***@ericsson.com>>, 'Core' <***@ietf.org<mailto:***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
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:core-***@ietf.org] On Behalf Of Mohit Sethi
Sent: Monday, April 10, 2017 4:51 AM
To: Core <***@ietf.org<mailto:***@ietf.org>>; ***@ietf.org<mailto:***@ietf.org>
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