Subject: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt

From: "Kumar, Sandeep" <[email-masked]>
Date: Thu, 3 Jul 2014 13:11:00 +0000

Hi all

A new version of the existing DTLS-multicast draft has been submitted clarifying the response to multicast requests. We stick closely to what is already defined in the CoAP RFC using token value matching rules.

Regards
Sandeep

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, July 03, 2014 2:55 PM
To: Kumar, Sandeep; Garcia Morchon, Oscar; Kumar, Sandeep; Sye Loong Keoh; Dijk, Esko; Garcia Morchon, Oscar; Dijk, Esko; Akbar Rahman; Sye Loong Keoh; Akbar Rahman
Subject: New Version Notification for draft-keoh-dice-multicast-security-08.txt

A new version of I-D, draft-keoh-dice-multicast-security-08.txt
has been successfully submitted by Sandeep S. Kumar and posted to the IETF repository.

Name:           draft-keoh-dice-multicast-security
Revision:       08
Title:          DTLS-based Multicast Security in Constrained Environments
Document date:  2014-07-03
Group:          Individual Submission
Pages:          22
URL:            http://www.ietf.org/internet-drafts/draft-keoh-dice-multicast-security-08.txt
Status:         https://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/
Htmlized:       http://tools.ietf.org/html/draft-keoh-dice-multicast-security-08
Diff:           http://www.ietf.org/rfcdiff?url2=draft-keoh-dice-multicast-security-08

Abstract:
   The CoAP standard is fast emerging as a key protocol in the area of
   resource-constrained devices.  Such IP-based systems are foreseen to
   be used for building and lighting automation systems where devices
   interconnect with each other, forming, for example, low-power and
   lossy networks (LLNs).  Both multicast and its security are key needs
   in these networks.  This draft presents a method for securing IPv6
   multicast communication based on the DTLS which is already supported
   for unicast communication for CoAP devices.  This draft deals with
   the adaptation of the DTLS record layer to protect multicast group
   communication, assuming that all group members already have the group
   security association parameters in their possession.  The adapted
   DTLS record layer provides message confidentiality, integrity and
   replay protection to group messages using the group keying material
   before sending the message via IPv6 multicast to the group.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

________________________________
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: Michael StJohns <[email-masked]>
Date: Mon, 07 Jul 2014 12:09:58 -0400

Hi - I've gone back through this and through 
https://datatracker.ietf.org/doc/draft-kumar-dice-groupcomm-security/ 
and had a few comments.

The changes to draft-keoh-dice-multicast-security in the last few 
revision seem to me to be mostly cosmetic.  In the latest rev, the word 
"control" was expunged or replaced with "automation".   Quite a lot of 
things that were requirements in previous versions are now "out of 
scope".  However "encrypt the messages" and "prevent replay" and "do 
integrity" are still part of this.

The document remains an uncomfortable mix of specification and "maybe 
think about this sometime"  (e.g. security considerations section 
inappropriately includes issues that really need to be resolved as part 
of the protocol rather than left hanging.  The fact they are hard 
problems suggests that a solution is not imminent).

In the interim, 
https://datatracker.ietf.org/doc/draft-kumar-dice-groupcomm-security/ 
has been submitted.  That document shares a lot of the same boilerplate 
text as this document and I thought it was headed in the direction of 
defining public key mechanisms at the COAP layer rather than something 
at the DTLS layer, but it seems to have mostly restated this document 
with a few paragraphs on why public key is too expensive and *maybe* 
moving the symmetric key secure multicast problem to the COAP layer (but 
even that's unclear).

As I've pointed out, symmetric key multicast security - isn't actually 
secure.  It can be *made* secure in implementation, but that requires a 
not-free secure processing element and a cryptographically verifiable 
guarantee that keys for the multicast group are only ever shared with 
other nodes that can prove they have such a secure processing element.  
The providing of that secure element seems to be anathema to the idea of 
DICE.

Based on my discussions with Sandeep and discussions at the mike during 
the last IETF wg session, what I thought was going to happen was that 
this document was going to be withdrawn, and that a COAP document which 
described public key signatures over COAP control messages (which could 
then be sent over multicast) as well as COAP level replay protection 
mechanisms would be submitted.

I know the charter says "do multicast security using DTLS" - but I 
haven't seen any evidence that suggests any result would actually be 
secure enough for the uses proposed.   Doing secure public key 
signatures at the application layer (e.g. COAP) for source 
authentication and integrity (and incidentally non-repudiation) is 
probably a better choice.  Still unclear what the use case is for 
confidentiality and if there is one why it wouldn't be better applied at 
the IP layer or lower at the link-layer.

Mike

On 7/3/2014 9:11 AM, Kumar, Sandeep wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 8 Jul 2014 12:26:27 +0000

Hi Mike

See inline

> From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael
> StJohns
>
> In the interim,
> has been submitted.  That document shares a lot of the same boilerplate text
> as this document and I thought it was headed in the direction of defining
> public key mechanisms at the COAP layer rather than something at the DTLS
> layer, but it seems to have mostly restated this document with a few
> paragraphs on why public key is too expensive and *maybe* moving the
> symmetric key secure multicast problem to the COAP layer (but even that's
> unclear).
>
[SK] I do not understand what you are referring to but draft-kumar-dice-groupcomm-security
clearly includes the public key options. The SIG field in Figure 2 and Figure 3 are the
public key signatures. This is exactly what we had discussed offline in London on how such a solution would look like.
The symmetric key MAC was also mentioned at the mike in London as being useful for DoS protection.
Confidentiality does not even come into picture if you choose a ciphersuite which has no encryption.

>...
> the last IETF wg session, what I thought was going to happen was that this
> document was going to be withdrawn, and that a COAP document which

[SK] I am afraid you have the wrong conclusions from the London meeting.
The DICE WG report http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00200.html
" In the meeting there was good agreement that draft-keoh-dice-multicast-security-05 is a reasonable
solution for what we were chartered to do, and we should not try to add source authentication to the
DTLS record layer. It was agreed to encourage a straw-man draft to be written exploring if an alternative
approach would make sense doing this in CoAP including source authentication. This is not in our charter,
but the draft is meant to help us determine how to proceed."

This straw-man draft is meant for the *WG* to decide if public-key based solution is the way to go forward with the associated
changes required at CoAP layer, handling group/unicast communication differently and with the added
computational load of public key signature per message. It may be a good solution on paper but I myself doubt
its practicality.

Additionally draft-keoh-dice-multicast-security can be moved to Informational since we all agree that it does
solve a practical problem in the Lighting domain.

Regards
Sandeep

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jul 2014 10:50:05 -0400

On 7/8/2014 8:26 AM, Kumar, Sandeep wrote:
> The DICE WG reporthttp://www.ietf.org/mail-archive/web/dtls-iot/current/msg00200.html

I'm going to hit this one separately and first.    In a private message 
to Zach I disagreed that there was "good agreement" and disagreed there 
was consensus that the draft was a "reasonable solution".  Neither of 
the comments in the meeting report appeared to me to be supported by the 
discussion at the meeting.

The actual working group minutes with the transcript are

>     
>            3) Multicast draft [Sandeep Kumar]
>            draft-keoh-dice-multicast-security-05  <http://tools.ietf.org/html?draft=draft-keoh-dice-multicast-security-05>
>            
>            - Sandeep - Goes over motivating use cases and requirements
>            - Sandeep - Goes over proposed solution (use DTLS rcord layer to protect
>            CoAP group comm messages; out of band setup of Group Security Association)
>            - Sandeep - DTLS record layer adaptation, and DTLS recrd layer processing
>            remains nearly unchanged
>            - Stephen Farrell - Just skip to open questions as we already discussed
>            this previously
>            
>            - Zach - We are chartered for this approach as described by Sandeep.
>            Now we have suggestions by Mike and others to go beyond this solution
>            which is a good discussion.  Like requiring source authentication.
>            As a WG do we need to support this?
>            - Eker - You should abandon DTLS record layer to support multicast [if
>            you want to support source authentication].  Source authentication is
>            really required for many IoT use cases.
>            - Zach - Should we try to extend CoAP to do this (instead of DTLS
>            record layer)?
>            - Carsten - Want to avoid complicated re-design.  Don't know what
>            component we could use for source authentication?
>            - MikeStJohn - Public key integrity can be done in several ways
>            - Eker - There may be problems with this depending on what layers you
>            are doing this
>            
>            - Zach - We have a solution that fits the charter but may need to support
>            source authenticaton.  We need to have complementary drafts looking at
>            alternate solutions
>            - Stepehen Farrell - Sounds like a potentially huge increase in scope
>            - Zach - Yes, we need if weto decide  really want to expand the scope
>            - Stephen Farrell - So we should hold this draft until the complementary
>            drafts are written
>            - Zach - Yes

1) You can't do integrity protection without source authentication.
2) You can't do source authentication with symmetric key systems 
(without the caveats I've listed multiple multiple times)
3) You can't use secure multicast for control systems without some form 
of integrity protection and source authentication and that was the only 
use case that has been proposed so far.

The fact that DTLS multicast security is part of the charter does not 
mean that the group is going to actually be able to produce something 
that works.  There are reasons why multicast security even at other 
layers is not widespread.

> This straw-man draft is meant for the*WG*  to decide if public-key based solution is the way to go forward with the associated

In most ways, this should actually be a CoAP WG issue and not a DTLS WG 
issue.  I was surprised when the suggestion was made that the charter 
might be expanded.

> solve a practical problem in the Lighting domain.

My definition of "solve" is probably a bit more rigorous than yours in 
this case.  My analysis is that multicast security (as you're defining 
it) for your lighting domain problem provides little or no protection to 
active attacks.  If a hacker wants to control your lights, he will grab 
one of them, extract the keys and start blinking SOS (or perhaps 
something more rude).  This will take about 5 minutes.

That said, if you're going to remove this from the WG and submit it as 
an informational RFC describing how your company does lighting multicast 
security, I have no further objections (and that's what I thought you 
were going to do post London).

My objection to draft-keoh-dice-multicast-security is as a WG, general 
solution for DTLS multicast and the possibility that it would be 
published as a IETF standard.   The implementation constraints necessary 
for your approach to ensure even minimal protection do not map well to 
an IOT of 10's of 1000's of cheap devices.  Publishing a DTLS multicast 
security standard "for constrained devices" is supposed to be a profile 
of DTLS multicast security which implies that DTLS multicast security 
needs to work for more than just the DICE cases (or can be constrained 
in the protocol so it *only* works for the DICE cases and can't be used 
as a general DTLS multicast solution).

Mike

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jul 2014 17:08:44 +0200

> 1) You can't do integrity protection without source authentication.  

That depends on your attack model.

Given that much of today’s IoT “security" is depending on a single WiFi key for a whole installation, application-based group keying is still significant progress for those cases where the attack model doesn’t rule out group keying.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jul 2014 11:23:55 -0400

On 7/8/2014 8:26 AM, Kumar, Sandeep wrote:
>> >paragraphs on why public key is too expensive and*maybe*  moving the
> Confidentiality does not even come into picture if you choose a ciphersuite which has no encryption

Hi Sandeep -

I probably was a bit too harsh on my comments, but I got there from:

o Section 4.3 which is basically arguing that PK is too expensive and 
complex.

o Section 4.2 which suggests that PK might be better done as part of 
DTLS (shim layer).

o Section 3.2 which is mostly what you need to do symmetric key 
multicast only slightly modified for PK.

o Section 6. which is all about the issues with symmetric key 
confidentiality rather than discussing PK source and integrity.

Overall I think I saw this document somewhere before without any of the 
PK stuff in it, but I can't place it.  And this document really does 
share a lot in common with draft-keoh....

What I was hoping for based on our discussions was a draft that 
described only PK source auth  and integrity at the CoAP level without 
mixing in any of the symmetric key issues.    And that was actually an 
implementation spec or closer to one (e.g. here's the actual format for 
how you encapsulate signatures with CoAP and here's the backwards 
compatibility issues), and here's what gets signed.  And here's how it 
gets verified.  And here's how it gets placed in a groupcomm message.

Finally, a PK signed CoAP message shouldn't have any special handling 
considerations - it gets sent either unicast or multicast like any other 
CoAP message.  The receiving node makes a decision on whether to act on 
the contents of the message based on the identity of the sender and 
whether the message verifies.

With respect to the symmetric key multicast stuff - it continues to be a 
red herring.  If you provide link layer security for your IOT mesh, 
(which can be done as a two-party symmetric key system), you get as much 
or more privacy protection that you get if you try and do symmetric key 
at the multicast level.  The DOS protection you mention is subject to 
the exact same set of attacks mentioned before - ANYONE that has the 
multicast key can send verified traffic, which means that even one weak 
link (e.g. your lightbulb being hacked - and it will) makes that DOS 
protection moot.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jul 2014 11:47:45 -0400

> Given that much of today’s IoT “security" is depending on a single WiFi key for a whole installation, application-based group keying is still significant progress for those cases where the attack m…

Hi Carsten -

To get to a common point, what I mean by integrity at this point is:  "A 
message can't be modified between a sender and receiver without 
detection by the receiver" - do you agree with this definition?  Under 
that definition if I'm doing multicast symmetric key integrity 
protection, then a third party who holds that key can change the message 
without detection.  If the key is only held by one other party, then I 
know the source as well as the integrity of the message.  Likewise with 
public key - if I can verify the message with a public key, I know the 
holder of the private key is the originator.  All of these guarantees 
break down if a) a symmetric key is shared between more than 2 parties, 
or b) a private key is shared between more than a single party.

In the WiFi model, mostly the "mesh" is one deep.  There's the access 
point and then there's everyone else.  The size of the mesh is 
relatively small (~20 - 200 if you're talking about an IETF meeting!), 
and almost every device talks directly to the AP. Mostly the comm model 
for WiFi is that the wireless guys want something on the wired internet 
- they rarely need to talk to the other wireless devices.  Some "IoT" 
approaches have reused WiFi security - and not in a good way considering 
the WiFi security protocol (802.1x) is such that it doesn't scale very 
well with depth of mesh or number of nodes.  It also doesn't do a lot of 
packet level multicast for the normal designed-to case (e.g. internet 
access).

> application-based group keying is still significant progress for those cases where the attack model doesn’t rule out group keying.

The use cases where this works all seem to involve a secure processing 
element and that's not exactly within the DICE charter. The most 
successful group keying system I'm aware of is pay TV (either satellite 
or cable).  Those systems - obviously - use a secure processing element 
(e.g. smart card or built in) to manage group keys and decryption based 
on credentials.

I literally can't think of a use case without an SPE where the attack 
model doesn't rule out group keying for integrity protection and most 
attack models for most use cases rule it out for confidentiality.

Mike

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 8 Jul 2014 18:04:55 +0200

I consider a definition of (integrity) protection more useful that figures in the attacker.
If an attacker can steal a lamp out of my home and tamper with it, I probably have larger issues than whether they can do some morse code on my lights.  (If they can “hack” it, they already can do the morse code thing.)
So, yes, I consider group keying to provide integrity protection — against attackers outside the group.

> The use cases where this works all seem to involve a secure processing element and that's not exactly within the DICE charter.

Tamper-proofing is not required for the above use case.

> The most successful group keying system I'm aware of is pay TV (either satellite or cable).  Those systems - obviously - use a secure processing element (e.g. smart card or built in) to manage group keys and decryption based on credentials.

This has a quite different attack model — here you hand over the entire environment (smart card, decoder) to any interested attacker.  This is not the case we are interested in.

> I literally can't think of a use case without an SPE where the attack model doesn't rule out group keying for integrity protection and most attack models for most use cases rule it out for confidentiality.

See above.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Tue, 08 Jul 2014 15:03:18 -0400

Hi Carsten - inline.

> So, yes, I consider group keying to provide integrity protection — against attackers outside the group.

If I can hack an individual light to turn it on and off, I can hack it 
to hand over the key material.  I can then turn on and off all of the 
lights in the group.

The attacker may start outside the group - its just that the security of 
the group is that of the least secure device making it trivial for the 
attacker to be "inside" the group as far as key material.

Also, unless I'm mistaken,  the usage case for lighting isn't limited to 
personal residences (nor can that limitation be enforced in the 
protocol), but also (and probably more commonly) to commercial 
buildings.  Even 1 mesh controlled light in a public access space makes 
you vulnerable to someone walking off with the light.

> Tamper-proofing is not required for the above use case.

If the key is not kept in storage not available to the general purpose 
processor running the node, then hacking the node allows the hacker to 
extract the key.

The hack can be physical (e.g. unscrew the lightbulb and take it with 
you and then plug it into a flash reader), or OTA (smash that stack!!).

I'm assuming you're using "tamper-proofing" where I used "secure 
processing element" - you don't necessarily need tamper-proofing (or 
even tamper detection), but you do need a way to keep the key from being 
extracted and that has to exist in each and every node, otherwise it's 
trivial to hack the mesh.

> This has a quite different attack model — here you hand over the entire environment (smart card, decoder) to any interested attacker.  This is not the case we are interested in.

In the pay tv environment, you've got millions of devices available to 
be hacked either remotely or physically.  In the lighting control case 
you've got 100s of lightbulbs (in one building, 100's of 1000's in many 
buildings) available to be hacked either remotely or physically.  Not 
sure I understand why the attack models are different.

The *threat* model for lightbulbs may generate less concern than the 
threat model for pay TV because the value of hacking lightbulbs may be 
less - but that is not a general property of all systems that might 
possibly use symmetric key multicast DTLS.  Even then, hacking a 
building's lighting control system is going to generate enough interest 
that it will be done and probably in a spectacular fashion.

Mike