Subject: [6lo] IETF92 informal security discussion summary

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 24 Apr 2015 00:13:17 +0000

When:  March 26th -Thursday  evening. About 20-25 people attended.

Acknowledgement: Rene Struik and  Gabriel Montenegro took notes, Hannes Tschofenig and Dave Thaler helped with asking the right questions
                                         James Woodyat facilitated with the meeting ; Samita and Gabriel co-ordinated the meeting discussions

This was an informal gathering discussing 6lo/constrained nodes security for network access.
Conclusion:
1)       Request Brian H. (AD) to create a mailing list for 6lo-constained node security and bootstrapping for discussions
2)      A basic threat analysis and framework of security for 6lo devices is needed for secure network-level bootstrapping
3)      Some solutions already exist (6tisch-security design team, IEEE 802.15.9, ZigBeeIP Security etc.) for specific deployment scenarios and 6lowpan-L2; Evaluate those solutions and re-use when applicable
4)      6lo-chairs are going to consult with AD( Brian H.) on the next step

Short Notes:

Scope of the 6lo-security discussion :  Security mechanisms  Network Access of the device . Application level security is NOT in scope.

Possible discussion items:
1.       L3 Solutions desirable for network access [ since we deal with multi-L2 Technologies]
2.       Dynamic Key/id distribution? [Useful for L2-L3-APP layer SA?]
3.       Router Advertisement authentication?
4.       Join/Leave network
5.       Mobility across 6lowpan/6lo subnets or networks?
6.       Analysis of security work done in 6TiSCH and how can we separate the 6TiSCH-independent part for common usage on 6lo?

Summary:
6Tisch-security , 802.15.9 security (chair: Bob Moskowitz), ZigBee IP solutions are there - should they be applicable for 6lo-devices in general? Do we need one or more network access security solutions per deployment ? Perhaps one or two solutions can cover most usecases?  6Tisch-security framework  is a good one to look at and also ZigBeeIP PANA based network access authentication might be another example.
Sandip Kumar and another person pointed out that each deployment scenario might be different - for example, light switch case is different - separation of business domains owners and separation of network components and software ownership.
Could bootstrapping use COAP resource directory and DNS-SD ?  [ Note: device does not have an IP-address at that point]
Consider scenarios when there is lack of physical access to the device.
QR-code, Chromecast/Wifi-access, bi-directional trust via public-key were mentioned as part of discussions.
Pascal asked questions about stopping of 6tisch-security work if 6lo-security design team is formed. General feeling in the room was to proceed with 6tisch security work and feed applicable common part in 6lo as contribution.

Thanks,
-Samita and Gabriel

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Apr 2015 07:06:04 +0200

Samita Chakrabarti wrote:
> Application level security is NOT in scope.

In general, any reasonable overall security workflow for a constrained
node will need to handle the setup of both network and application security.
So, how do we avoid creating usability issues (as well as security
issues by encouraging the "the WiFi password is the key to the kingdom"
approach) by ignoring application security?
Separation of concerns by layers is a good thing, unless the concerns
aren't separate.

Grüße, Carsten

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 24 Apr 2015 10:50:05 -0500

Hi Samita,

Thanks for the summary.
 You mentioned:

I think this is a different issue, it has nothing to do with secure
bootstrapping.
It is more related to updating 6LoWPAN ND, RFC 6775.
As such, my proposal is to keep it separate from network-level bootstrapping.

I also agree with Carsten, application level security should be in
scope as network-level bootstrapping should facilitate application
level security.

Regards,

Behcet

On Thu, Apr 23, 2015 at 7:13 PM, Samita Chakrabarti
<[email-masked]> wrote:
> When:  March 26th –Thursday  evening. About 20-25 people attended.
>
>
>
> Acknowledgement: Rene Struik and  Gabriel Montenegro took notes, Hannes
> Tschofenig and Dave Thaler helped with asking the right questions
>
>                                          James Woodyat facilitated with the
> meeting ; Samita and Gabriel co-ordinated the meeting discussions
>
>
>
> 1)       Request Brian H. (AD) to create a mailing list for 6lo-constained
> node security and bootstrapping for discussions
>
> 2)      A basic threat analysis and framework of security for 6lo devices is
> needed for secure network-level bootstrapping
>
> 3)      Some solutions already exist (6tisch-security design team, IEEE
> 802.15.9, ZigBeeIP Security etc.) for specific deployment scenarios and
> 6lowpan-L2; Evaluate those solutions and re-use when applicable
>
> Scope of the 6lo-security discussion :  Security mechanisms  Network Access
> of the device . Application level security is NOT in scope.
>
>
>
> 6.       Analysis of security work done in 6TiSCH and how can we separate
> the 6TiSCH-independent part for common usage on 6lo?
>
>
>
> Summary:
>
> 6Tisch-security , 802.15.9 security (chair: Bob Moskowitz), ZigBee IP
> solutions are there – should they be applicable for 6lo-devices in general?
> Do we need one or more network access security solutions per deployment ?
> Perhaps one or two solutions can cover most usecases?  6Tisch-security
> framework  is a good one to look at and also ZigBeeIP PANA based network
> access authentication might be another example.
>
> Sandip Kumar and another person pointed out that each deployment scenario
> might be different – for example, light switch case is different –
> separation of business domains owners and separation of network components
> and software ownership.
>
> Could bootstrapping use COAP resource directory and DNS-SD ?  [ Note: device
> does not have an IP-address at that point]
>
> Pascal asked questions about stopping of 6tisch-security work if
> 6lo-security design team is formed. General feeling in the room was to
> proceed with 6tisch security work and feed applicable common part in 6lo as
> contribution.
>
>
>
> Thanks,
>
> -Samita and Gabriel
>
>
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo
>

---

From: Brian Haberman <[email-masked]>
Date: Fri, 24 Apr 2015 11:55:36 -0400

> 1)       Request Brian H. (AD) to create a mailing list for 6lo-constained node security and bootstrapping for discussions

This is accomplished by someone following the instructions here:

http://www.ietf.org/list/nonwg.html

Regards,
Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 Apr 2015 16:57:56 -0400

Samita Chakrabarti <[email-masked]> wrote:
    > Could bootstrapping use COAP resource directory and DNS-SD ? [ Note:
    > device does not have an IP-address at that point]

1) In IPv6, devices always have a link-local address.
2) the device needs to be on the network before it can be "found"

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Apr 2015 10:48:33 +0100

Regarding application layer security: In the overall picture of 
bootstrapping, i.e. taking a device through various stages to allow it 
to perform to its functional ability, application layer security 
certainly is in scope. However, the concepts of authentication and 
authorization for network access and authentication and authorization 
for application layer are quite separate and can easily become 
conflated, especially in the home/premises scenario. It is fine to state 
a policy where network access authorization implies application layer 
authorization but the two concepts should be kept separate. There are 
many cases where one does not imply the other. An obvious example is 
where access granted to a hotel Wi-Fi network clearly does not imply 
application layer security to e.g. my bank. Peer-to-peer traffic in 
premises networks often needs to be kept distinct, for example I 
wouldn't expect my electricity meter to be able to see my gas meter 
readings.

So in the first instance, I think we should probably focus on security 
surrounding network access.

Robert

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Apr 2015 12:01:51 +0200

[…] It is fine to state 
a policy where network access authorization implies application layer 
authorization but the two concepts should be kept separate. There are 
many cases where one does not imply the other. 

Hi Robert,

certainly, the two (authorization to enter the network, application authorization) should not be conflated.

However, the fact that one kind of authorization does not imply the other does not mean that they will always be set up separately.

There is little point in putting up a sensor in the network and then being unable to configure it further because no application security was set up for the configuration resources.

Grüße, Carsten

---

From: Robert Cragie <[email-masked]>
Date: Tue, 28 Apr 2015 11:24:18 +0100

Hi Carsten,

On 28/04/2015 11:01, Carsten Bormann wrote:
> However, the fact that one kind of authorization does not imply the 
> other does not mean that they will always be set up separately.

Indeed, and I was not saying that. I was saying that the two *concepts* 
must be kept separate ("It is fine to state a policy where network 
access authorization implies application layer authorization but the two 
concepts should be kept separate").

Robert

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 29 Apr 2015 16:43:21 -0500

On Tue, Apr 28, 2015 at 4:48 AM, Robert Cragie
<[email-masked]> wrote:
> bootstrapping, i.e. taking a device through various stages to allow it to
> perform to its functional ability, application layer security certainly is
> in scope. However, the concepts of authentication and authorization for
> network access and authentication and authorization for application layer
> are quite separate and can easily become conflated, especially in the
> home/premises scenario. It is fine to state a policy where network access
> authorization implies application layer authorization but the two concepts
> should be kept separate. There are many cases where one does not imply the
> other. An obvious example is where access granted to a hotel Wi-Fi network
> clearly does not imply application layer security to e.g. my bank.
> Peer-to-peer traffic in premises networks often needs to be kept distinct,
> for example I wouldn't expect my electricity meter to be able to see my gas
> meter readings.
>

I agree with these. But what is meant here is that from secure
bootstrapping of the node its applications can also benefit, like EMSK
can be used by the applications to further derive application keys.

Regards,

Behcet
>>> This was an informal gathering discussing 6lo/constrained nodes security
>>> for
>>> network access.
>>>
>>> Conclusion:
>>>
>>> device