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 <[email protected]<mailto:[email protected]>> on behalf of Jim Schaad <[email protected]<mailto:[email protected]>> Date: Thursday 13 April 2017 at 16:39 To: Mohit Sethi <[email protected]<mailto:[email protected]>>, Göran Selander <[email protected]<mailto:[email protected]>>, 'Core' <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: 'Christian Amsüss' <[email protected]<mailto:[email protected]>> 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:[email protected]] Sent: Thursday, April 13, 2017 2:46 AM To: Göran Selander <[email protected]<mailto:[email protected]>>; 'Core' <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: Jim Schaad <[email protected]<mailto:[email protected]>>; Christian Amsüss <[email protected]<mailto:[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]<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 From: Mohit Sethi <[email protected]<mailto:[email protected]>> Date: Thursday 13 April 2017 at 11:45 To: Göran Selander <[email protected]<mailto:[email protected]>>, 'Core' <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: Jim Schaad <[email protected]<mailto:[email protected]>>, Christian Amsüss <[email protected]<mailto:[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]<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
