Subject: [Ace] COSE and multicast: Discussion Summary?

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 29 Sep 2015 10:44:52 +0200

Hi all,

I re-read the email messages on the discussion thread Jim posted (see
http://www.ietf.org/mail-archive/web/ace/current/msg01285.html) in an
attempt to find out why version -05 of the COSE draft does not have the
'alg' parameter optional.

I see agreement that in certain use cases a context identifier is needed
(such as a key id, or whatever you want to call it). But I also notice a
lot of unrelated discussions that make it difficult to find out what was
the outcome of the debate.

While a security context identifier is not new concept I would like to
explain it again.

In many security protocols a more sophisticated protocol exchange is
executed first and then keys are derived and form a security
association. The security association consists of keys (typically
different keys in different directions), agreed algorithms, sequence
number counters, and a label. Different protocols utilize the label
differently but that label is used to reference the security
association. Different protocols also use a different term for the
established context information. (Engineers like to invent new terms.)

When this initial phase is completed data traffic can be
encrypted/integrity/replay protected.

Why is this two-step approach used? You do the heavy lifting once and
then you can go full speed with symmetric crypto.

If you know get the impression that you have heard about that concept
before then you are absolutely right.

Example: IKEv2 and IPsec ESP. (This time I picked a different example so
that nobody gets hung up on the DTLS story.)

The heavy lifting in this case is the IKEv2 exchange that establishes
(in this case) the IPsec SAs. IPsec ESP then only uses the previously
established security context and uses symmetric cryptography.

When you look at the IPsec header then you will see that the message
doesn't carry an algorithm field in there.

How come is that? Well. It has been established already with the earlier
IKEv2 exchange. Both parties know the algorithm and all the other
information already. All that is needed at this point is a way to select
the correct security association when receiving a message in order to
decrypt the payload. There needs to be some information in the packet
itself to do that (in the unencrypted part, of course). Let us call it a
label. There is no need to carry redundant information around with every
IPsec packet.

What label is used in IPsec? A quick look at
https://tools.ietf.org/html/rfc4303 reveals that the authors have called
it Security Parameter Index (SPI). In case of unicast IPsec the SPI
itself is not unique and has to be combined with other information
(namely protocol - ESP or AH, and the destination address). Not a big
deal. There are also specs for the use of multicast IPsec.

Is it so far fetched to re-use the same concepts that others have
introduced in the IETF already before?

Ciao
Hannes

---

From: Somaraju Abhinav <[email-masked]>
Date: Tue, 29 Sep 2015 12:57:57 +0000

Hi Hannes,
Thank you for the summary. I agree with what you are saying - I did not understand fully the outcome of this debate with regards to making the 'alg' parameter optional.

It would help a lot if the authors of the CoSE draft clarify if they think that CoSE will be used in such a two-step process.

I assumed that for multicast communication we will follow such a two-step process: 1) In the first step some method (yet to be fixed) is used to distribute the keys to members of the group, establish a context, determine the algorithm that will be used etc. and 2) Use Object security for the second-step so that "we can go full speed with symmetric crypto". This motivated the request to make the 'alg' parameter optional in the header so that we can use CoSE based object security for multicast messages in step 2.

Regards,
Abhinav

-----Original Message-----
From: Ace [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Dienstag, 29. September 2015 10:45
To: [email-masked]
Subject: [Ace] COSE and multicast: Discussion Summary?

Hi all,

I re-read the email messages on the discussion thread Jim posted (see
http://www.ietf.org/mail-archive/web/ace/current/msg01285.html) in an attempt to find out why version -05 of the COSE draft does not have the 'alg' parameter optional.

I see agreement that in certain use cases a context identifier is needed (such as a key id, or whatever you want to call it). But I also notice a lot of unrelated discussions that make it difficult to find out what was the outcome of the debate.

While a security context identifier is not new concept I would like to explain it again.

In many security protocols a more sophisticated protocol exchange is executed first and then keys are derived and form a security association. The security association consists of keys (typically different keys in different directions), agreed algorithms, sequence number counters, and a label. Different protocols utilize the label differently but that label is used to reference the security association. Different protocols also use a different term for the established context information. (Engineers like to invent new terms.)

When this initial phase is completed data traffic can be encrypted/integrity/replay protected.

Why is this two-step approach used? You do the heavy lifting once and then you can go full speed with symmetric crypto.

If you know get the impression that you have heard about that concept before then you are absolutely right.

Example: IKEv2 and IPsec ESP. (This time I picked a different example so that nobody gets hung up on the DTLS story.)

The heavy lifting in this case is the IKEv2 exchange that establishes (in this case) the IPsec SAs. IPsec ESP then only uses the previously established security context and uses symmetric cryptography.

When you look at the IPsec header then you will see that the message doesn't carry an algorithm field in there.

How come is that? Well. It has been established already with the earlier
IKEv2 exchange. Both parties know the algorithm and all the other information already. All that is needed at this point is a way to select the correct security association when receiving a message in order to decrypt the payload. There needs to be some information in the packet itself to do that (in the unencrypted part, of course). Let us call it a label. There is no need to carry redundant information around with every IPsec packet.

What label is used in IPsec? A quick look at
https://tools.ietf.org/html/rfc4303 reveals that the authors have called it Security Parameter Index (SPI). In case of unicast IPsec the SPI itself is not unique and has to be combined with other information (namely protocol - ESP or AH, and the destination address). Not a big deal. There are also specs for the use of multicast IPsec.

Is it so far fetched to re-use the same concepts that others have introduced in the IETF already before?

Ciao
Hannes

________________________________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 29 Sep 2015 13:52:27 -0700

> Sent: Tuesday, September 29, 2015 1:45 AM
> To: [email-masked]
> attempt to find out why version -05 of the COSE draft does not have the 'alg'
> parameter optional.

I would say that it is not done, at least in part, because it is not currently a high priority for me.  However, there is not really a solid document on the table for ACE about what constitutes a protocol to do key establishment, what is done in the key establishment, how COSE messages are going to be constructed and sent.  This being the case it may be a matter of putting the cart before the horse to make the algorithm optional.

> 
> I see agreement that in certain use cases a context identifier is needed (such as a
> key id, or whatever you want to call it). But I also notice a lot of unrelated
> discussions that make it difficult to find out what was the outcome of the
> debate.
> 
> In many security protocols a more sophisticated protocol exchange is executed
> first and then keys are derived and form a security association. The security
> association consists of keys (typically different keys in different directions),
> agreed algorithms, sequence number counters, and a label. Different protocols
> utilize the label differently but that label is used to reference the security
> association. Different protocols also use a different term for the established
> context information. (Engineers like to invent new terms.)
> 
> The heavy lifting in this case is the IKEv2 exchange that establishes (in this case)
> the IPsec SAs. IPsec ESP then only uses the previously established security
> context and uses symmetric cryptography.
> 
> IKEv2 exchange. Both parties know the algorithm and all the other information
> already. All that is needed at this point is a way to select the correct security
> association when receiving a message in order to decrypt the payload. There
> needs to be some information in the packet itself to do that (in the unencrypted
> part, of course). Let us call it a label. There is no need to carry redundant
> information around with every IPsec packet.
> 
> https://tools.ietf.org/html/rfc4303 reveals that the authors have called it
> Security Parameter Index (SPI). In case of unicast IPsec the SPI itself is not unique
> and has to be combined with other information (namely protocol - ESP or AH,
> and the destination address). Not a big deal. There are also specs for the use of
> multicast IPsec.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Sep 2015 00:19:34 +0200

Jim Schaad wrote:
> However, there is not really a solid document on the table for ACE about what constitutes a protocol to do key establishment, what is done in the key establishment, how COSE messages are going to be constructed and sent.  

Right.  But my assumption would be that all we need to know is that the
context established by one of these protocols would go into the
interpretation of the (then incomplete) COSE data.

(Maybe I'm thinking this too much with a view to my old ROHC WG chair hat.)

> being the case it may be a matter of putting the cart before the horse to make the algorithm optional.

Right.  We should have a model how the "needed" parameters are filled in
into the COSE data structure from that context so they don't have to be
"mandatory" in the transmitted version of that data structure.  That
model could be quite simple though.  The important part is that anything
that is not protected can be modified by an attacker anyway, so why send
it with the message if you have it in the context?  The handling of
(integrity-)protected headers is much more interesting.

(Over in the COSE WG I'll make the same case for msg-type, which we
should get rid of summarily.)

Grüße, Carsten