Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00]

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 18 Oct 2013 14:30:29 +0000

Dear John

Thanks for the detailed and helpful review. Please find below our reply.

Kind regards
Sandeep

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of John Foley
> Sent: Thursday, October 17, 2013 8:33 PM
> To: [email-masked]
> Subject: [Dtls-iot] Comments on
> [draft-keoh-dice-multicast-security-00]
>
> Hello colleagues,
>
> I've reviewed your draft for DTLS-based multicast security for
> low-power and LLNs.  Please give consideration to my comments for your draft.
>
> Section 1.1:  It's been a while since I've done multicast work.  This
> is a nit, but isn't the traditional term used for a device receiving
> multicast packets called a "Receiver"?  Using the term "Listener" may
> confuse traditional IP multicast experts.

[SK]"Listener" is the term used in MLDv2 for IPv6 (RFC3810). But agree that most multicast security
 related RFC refer to them as receivers. We will change the terminology to what you suggest in the
next version to be consistent with security folks.

>
> Section 4.1.1:  How can we trust this ChangeCipherSpec message?  Since
> all the detail of the DTLS handshake, security association setup,
> group setup, etc. are omitted from this draft, how do we know this
> ChangeCipherSpec is valid?  This appears to be an easy opportunity for a denial of service attack.
> Comparing to TLS, TLS handshake messages are hashed and validated (RFC
> 5246 section 7.4.9).  Additionally, some handshake messages are
> digitally signed (RFC 5246 section 7.4.3).  It seems we need much more
> detail in this draft regarding re-synchronizing the epoch and seq#
> using the ChangeCipherSpec message.  Or, consider using the approach
> defined in [draft-mcgrew-aero-00], which eliminates the need to synchronize the seq#.

[SK] You are right, the ChangeCipherSpec or any mechanism to update epoch (when the sequence number
wraps) should be secured. Since DICE is not chartered at this point to design any key management for the
multicast security, it would be better to remove any reference to ChangeCipherSpec and leave such
mechanisms to a future specification of secure  key management. It is likely that the scope of DICE will be
extended to look at these issues in the future.
.AERO looks like a good primitive to use in this scenario, but not clear how this would solve the epoch
update needed in DTLS after the seq number wrap around.

>
> Section 4.1.2:  What's wrong with using the IP address as the sender
> ID?  If the IP address is included in the MAC, this provides the
> equivalent level of security as using the Sender ID.  The added
> benefit would be no need to reduce the size of the sequence number.
> Additionally, protocols such as IGMP and PIM will use the source IP
> address to route many-to-many multicast packets.  Using the IP address
> as the sender ID in this draft may allow for better cohesion with the
> network management entities and provide for more intelligence in
> security products such as firewalls and intrusion prevention.

[SK] Indeed, the IP address would have been a right candidate as SenderID to MAC. However (D)TLS is at
a different layer in the network stack and it does not allow using headers from the lower layer (IP) to be
used in the  associated data. This would require a change to (D)TLS itself. However, the main reason to
partition the sequence number space according to the sender is to avoid sequence number re-use. In the
AES-CCM mode of operation, it is crucial to ensure that a particular sequence number is not re-used. By
adopting the method you proposed, multiple senders may use the same sequence number, and the same
group key to encrypt different messages, thus vulnerable to security attacks. AERO may not have this problem
if the IP address is part of the associated data, but we try to keep this general to any ciphersuite.

>
> Section 4.2.1:  How does a listener join an existing multicast feed
> while not failing the anti-replay check?  This new listener will not
> know which sequence numbers are valid unless there's some form of
> synchronization logic, which doesn't appear to be defined in the draft.
> You may want to look at incorporating [draft-mcgrew-aero-00].  This
> allows for anti-replay protection while not needing to maintain state
> on the receiver side.  AERO solves the problem of synchronizing the
> sequence number for late multicast joiners.  This reduces the code
> footprint and complexity, which may be very beneficial for constrained devices.
>
[SK] Late joiners are something we have not considered yet. The solution is AERO with one dropped packet
would be nice to have in this case. We will try to incorporate this hopefully without too many changes  to the
DTLS record layer processing. And of course, we welcome contribution (e.g., co-authorship) from Cisco to
further improve this draft together.

> General comment:  You may consider adding a section regarding IGMP and
> PIM.  Should the reader assume there are no ramifications to IGMP/PIM?
> Any entity could join the multicast group and receive packets, albeit
> they will not be able to decrypt them.  Or, is this protocol intended
> to only be used on local subnets?  My point is maybe you should
> provide some context with respect to how multicast networks are typically deployed.

[SK] We will provide more details on the IP multicast itself and make clear that we intend to target IPv6 and
6lowPAN networks only. We expect that this draft does not affect or neither influences how MLDv2 or any
multicast routing protocol works. This would be similar to how RFC5374 approaches with IPSec. Our target
is to only ensure that data payload in such a multicast communication can be secured. So if an entity joins
the multicast group and receive packets, albeit they will not be able to decrypt them if they do not have
the right key material.

>
> Best regards,
> John Foley
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: John Foley <[email-masked]>
Date: Mon, 21 Oct 2013 11:23:14 -0400

Hi Sandeep,

Regarding the multicast terminology for "Listener" or "Receiver", you
are correct.  The IPv6 specs have changed the terminology.  You may want
to continue using the term "Listener".  I apologize for the misdirection.

Regarding your comments on reusing the sequence number while using CCM
mode, I'm a confused between sequence number reuse, IV reuse, and how
you plan to coordinate this among multiple multicast senders.  Section
4.1.2 doesn't fully describe how the encryption context should be
initialized (e.g. what value to use for the IV).  My understanding is
AEAD ciphers such as CCM/GCM must not reuse an IV.  With unicast
TLS/DTLS the IV is derived from the master secret.  There are two
encryption contexts created for both reading and writing.  Therefore,
there are two IV values used in the unicast session
(client_write_iv/server_write_iv).  Your comment about reusing the
sequence number has confused me.  With your draft, should the IV now be
derived from the sequence number rather than the master secret?  How do
you prevent IV reuse when there are multiple senders using the same
master secret value?

Regards,
John

On 10/18/2013 10:30 AM, Kumar, Sandeep wrote:
> .

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 22 Oct 2013 09:19:50 +0000

Hi John

First the background reference
-----
According to the RFC6655 (AES-CCM for TLS) Section 3,  CCMNonce is a combination of a salt value and the sequence number.
        struct {
                        opaque salt[4];
                        opaque nonce_explicit[8];
                       } CCMNonce;

The salt is the IV generated from the handshake - client_write_IV (when the client is sending) or the server_write_IV (when the server is sending).
Further it says that "The value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key."
When the nonce_explicit is equal to the sequence number, the CCMNonce will have the structure below.

              struct {
               uint32 client_write_IV; // low order 32-bits
               uint64 seq_num;         // TLS sequence number
              } CCMClientNonce.

              struct {
               uint32 server_write_IV; // low order 32-bits
               uint64 seq_num; // TLS sequence number
              } CCMServerNonce.

In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated with the 48-bit seq_num.
------
According to my understanding, it is important that the CCMNonce is distinct based on the distinctness of the nonce_explicit. Ofcourse the IVs need to change if the 64-bit seq_num wraps, but that is when (D)TLS renegotiation kicks in to generate new IVs and session keys.

In our case we let all servers (senders) use the same server_write_IV and all clients (listeners) use the same client_write_IV. The client_write_IV is not important here since listeners never write. Since the exact procedure on how this should happen is a key management issue, we only mention in Sec 4 that it is either derived (by using the same random sent by the controller) or the controller directly sets these values in all servers and clients.

For the nonce_explicit to be distinct, we use  the recommendation ins RFC5288 (AES-GCM for TLS) Sec 6.2, to make
nonce_explicit = FixedDistinct || Variable.
Since in DTLS, the  nonce_explicit=epoch || sequence_number, we apply the recommendation as follows
nonce_explicit=Variable1 || FixedDistinct || Variable2.
For the FixedDistinct we use the SenderID (2 bytes) which should be distinct for all senders. The Variable1 is the epoch and Variable2 is the "truncated" sequence number (4 bytes). This is shown in Figure 4.3 of our draft. This avoids the nonce_explicit reuse across senders.

If the nonce_explicit wraps, which in in this situation means [epoch|| "truncated" sequence number] wraps, then just as in original DTLS, a renegotiation to freshen up the IVs and/or session keys are required as discussed in Sec 4.1 of DTLS (RFC6347). This is again something to be aware when designing the key management part.

Hope this clears your doubts or if I am wrong please let me know.

Kind regards
Sandeep

> From: John Foley [mailto:[email-masked]]
> Sent: Monday, October 21, 2013 5:23 PM
> To: Kumar, Sandeep; [email-masked]
> Cc: [email-masked]; Garcia Morchon, Oscar; Dijk, Esko; David
> McGrew; Nancy Cam-Winget
> Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00]
>
> Hi Sandeep,
>
> Regarding the multicast terminology for "Listener" or "Receiver", you are
> correct.  The IPv6 specs have changed the terminology.  You may want to
> continue using the term "Listener".  I apologize for the misdirection.
>
> 4.1.2 doesn't fully describe how the encryption context should be initialized
> (e.g. what value to use for the IV).  My understanding is AEAD ciphers such as
> CCM/GCM must not reuse an IV.  With unicast TLS/DTLS the IV is derived
> from the master secret.  There are two encryption contexts created for both
> reading and writing.  Therefore, there are two IV values used in the unicast
> session (client_write_iv/server_write_iv).  Your comment about reusing the
> > [SK]"Listener" is the term used in MLDv2 for IPv6 (RFC3810). But agree
> > that most multicast security  related RFC refer to them as receivers.
> > We will change the terminology to what you suggest in the next version to
> be consistent with security folks.
> >
> >> Section 4.1.1:  How can we trust this ChangeCipherSpec message?
> >> Since all the detail of the DTLS handshake, security association
> >> setup, group setup, etc. are omitted from this draft, how do we know
> >> this ChangeCipherSpec is valid?  This appears to be an easy opportunity
> for a denial of service attack.
> >> digitally signed (RFC 5246 section 7.4.3).  It seems we need much
> >> more detail in this draft regarding re-synchronizing the epoch and
> >> seq# using the ChangeCipherSpec message.  Or, consider using the
> >> approach defined in [draft-mcgrew-aero-00], which eliminates the need
> to synchronize the seq#.
> > wraps) should be secured. Since DICE is not chartered at this point to
> > design any key management for the multicast security, it would be
> > better to remove any reference to ChangeCipherSpec and leave such
> > mechanisms to a future specification of secure  key management. It is likely
> that the scope of DICE will be extended to look at these issues in the future.
> > .AERO looks like a good primitive to use in this scenario, but not
> > clear how this would solve the epoch update needed in DTLS after the seq
> number wrap around.
> >
> >> address to route many-to-many multicast packets.  Using the IP
> >> address as the sender ID in this draft may allow for better cohesion
> >> with the network management entities and provide for more
> >> intelligence in security products such as firewalls and intrusion prevention.
> > [SK] Indeed, the IP address would have been a right candidate as
> > SenderID to MAC. However (D)TLS is at a different layer in the network
> > stack and it does not allow using headers from the lower layer (IP) to
> > be used in the  associated data. This would require a change to (D)TLS
> > itself. However, the main reason to partition the sequence number
> > space according to the sender is to avoid sequence number re-use. In
> > the AES-CCM mode of operation, it is crucial to ensure that a
> > particular sequence number is not re-used. By adopting the method you
> proposed, multiple senders may use the same sequence number, and the
> same group key to encrypt different messages, thus vulnerable to security
> attacks. AERO may not have this problem if the IP address is part of the
> associated data, but we try to keep this general to any ciphersuite.
> >
> >
> > [SK] Late joiners are something we have not considered yet. The
> > solution is AERO with one dropped packet would be nice to have in this
> > case. We will try to incorporate this hopefully without too many
> > changes  to the DTLS record layer processing. And of course, we welcome
> contribution (e.g., co-authorship) from Cisco to further improve this draft
> together.
> >
> >> General comment:  You may consider adding a section regarding IGMP
> >> and PIM.  Should the reader assume there are no ramifications to
> IGMP/PIM?
> > [SK] We will provide more details on the IP multicast itself and make
> > clear that we intend to target IPv6 and 6lowPAN networks only. We
> > expect that this draft does not affect or neither influences how MLDv2
> > or any multicast routing protocol works. This would be similar to how
> > RFC5374 approaches with IPSec. Our target is to only ensure that data
> > payload in such a multicast communication can be secured. So if an entity
> joins the multicast group and receive packets, albeit they will not be able to
> decrypt them if they do not have the right key material.
> >
> >
> >> Best regards,
> >> John Foley
> >>
> > The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended recipient,
> please contact the sender by return e-mail and destroy all copies of the
> original message.
> >
> > .
> >