Re: [COSE] Multicast Use Case

[Hannes Tschofenig <[e-mail]>]

Hi Goeran,

I completely agree with you that having an already established security
context will be common for a number of use cases. I posted the use case
for multicast in the lighting environment since this is something I am
currently working on with Sandeep and Abhinav.

The OAuth access token is another such use case.

Ciao
Hannes


On 09/04/2015 03:15 PM, Göran Selander wrote:
> Hi,
> 
> Independently of the multicast use case, there is a secure communication
> setting that is similar to this example which I think deserves being
> considered in COSE.
> 
> What I expect to be a common setting is that the receiver has already
> established a security context, including algorithm, key, sequence
> number/used nonces etc. with a context identifier that is locally unique.
> In this case the only information that needs to be passed in the message
> is context identifier and nonce/sequence number together with ciphertext +
> tag.
> 
> You may of course argue that you should use the existing COSE_encrypt
> format.  But since a) the assumptions are quite different, b) the
> optimizations may be significant and c) this may be a common mode of
> operation, I think it actually deserves a (sub-)format of its own. If we
> don’t define this in COSE, someone may be tempted to do this elsewhere.
> 
> 
> Regards
> Göran
> 
> 
> 
> On 2015-08-31 09:22, "Hannes Tschofenig" <[e-mail]> wrote:
> 
>> Hi Jim, Brian, all,
>>
>> I am trying to compare the work on multicast security done by Sandeed &
>> co against an application layer solution using CBOR/COSE.
>>
>> The DTLS multicast includes the following relevant components:
>> - Epoch: 2 Byte
>> - Sender ID: 1 Byte
>> - Sequence Number: 5 Byte
>>
>> The combination of epoch, sender id and sequence number are used as a
>> nonce for the cipher and the use of the sender id ensures that no member
>> of the group accidentally selects values that will cause re-use.
>>
>> The 1 byte sender id is chosen small to reflect the expected size of a
>> group in the professional lighting environment, as explained in the DTLS
>> multicast document.
>>
>> Ciphersuite related information includes:
>> - Encrypted Content (variable length)
>> - MAC (variable length)
>>
>> Content Type, Version and Length are DTLS-specific aspects that cannot
>> be removed without re-design of the record layer.
>>
>> Data based on Figure 4 of
>> http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08.txt.
>>
>> Since there is no sequence number defined in COSE I put the epoch and
>> the sequence number together into the nonce field.
>>
>> Here is the commented version of the COSE message I came up with:
>>
>> [
>>     2, // Encrypted COSE message
>>     {
>>       1: 10, // Algorithm - AES-CCM-16-64-128
>>       5: h'89f52fa' // 7-byte nonce
>>     },
>>     h'7b9dcfa42c4e1d3182c402dc18ef8b5637de4fb62cf1dd156ea6e6e0',
>>      // encrypted payload.
>>     [
>>       [
>>         h'',
>>         {
>>           1: -6, // Direct use of CEK
>>           4: h'01' // Key ID - 0x01
>>         },
>>         h''
>>       ]
>>     ]
>>   ]
>>
>> According to cbor.me the resulting COSE encoding has 59 bytes whereby 28
>> bytes are purely used for message encryption.  This means that there is
>> 31 bytes overhead with COSE compared to 12 bytes [= 8 for Epoch +
>> Sequence Number + Sender ID, 3 bytes for Content Type and Version fields].
>>
>> Ciao
>> Hannes
>>
>