Subject: Re: [6lo] IETF92 informal security discussion summary

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 2 May 2015 00:05:41 +0000

Hi  Behcet, Robert and Carsten:

Thanks for the good discussion. In regards to Application-level security and network access security (securely access the network by proper identification/authentication], I am with Robert that we should separate application-level security.

I think that the IoT nodes (in our case specifically 6lo nodes) are bootstrapped with the other networked nodes that are with higher authority in the networks and then peered with others. The applications are then started [ once they sense some activity at the network-layer] and the applications  then talk to its peers for application-to-application authorization and perhaps signature authentication etc.

There might be commonality between the two when the application might be using a network-level security as part of it security information/identification.  In this case, defining an interface between the two makes sense.

Thus, if we consider IoT security in-general (bootstrapping both nodes along with apps) – certainly APP security is in scope. When it comes to 6lo-node bootstrapping and access to the networks- APP-level security is out of scope ( for 6lo WG).

Having said that, I wonder if any of you have any particular proposal in mind ?

Thanks,
-Samita

From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, April 28, 2015 3:02 AM
To: Samita Chakrabarti; [email-masked]; [email-masked]
Cc: Brian Haberman ([email-masked]); [email-masked]
Subject: Re: [6lo] IETF92 informal security discussion summary

[…] 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.

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

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: "Turner, Randy" <[email-masked]>
Date: Sat, 2 May 2015 00:10:19 +0000

Ditto regarding Samita's comment regarding separation of app and 6lo

Randy

On May 1, 2015 8:05 PM, Samita Chakrabarti <[email-masked]> wrote:

Thus, if we consider IoT security in-general (bootstrapping both nodes along with apps) - certainly APP security is in scope. When it comes to 6lo-node bootstrapping and access to the networks- APP-level security is out of scope ( for 6lo WG).

Thanks,
-Samita

[...] 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,

Gr??e, Carsten

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 2 May 2015 00:12:35 +0000

Hi Behcet:

Please see below with prefix [SC>].

> surrounding network access.

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.

[SC>]  That's a very good example. And  I agree that the security seed/info can be passed from Network layer to Application layer for simplicity and uniqueness identification. IMHO, this type of exchange should be in scope by delivering an interface to the upper layer.

Thanks,
-Samita

> On 24/04/2015 16:50, Behcet Sarikaya wrote:
>>
>>   Hi Samita,
>>
>> Thanks for the summary.
>>   You mentioned:
>>   3.       Router Advertisement authentication?
>>
>> 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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> 6lo mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/6lo
>>>
>> _______________________________________________
>> 6lo mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lo
>
>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Sat, 2 May 2015 00:29:30 +0000

Thank you Brian! 6lo-office will follow-up.

-Samita

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Brian Haberman
Sent: Friday, April 24, 2015 8:56 AM
To: [email-masked]
Subject: Re: [6lo] IETF92 informal security discussion summary

On 4/23/15 8:13 PM, Samita Chakrabarti wrote:
> 
> 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

This is accomplished by someone following the instructions here:

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

Regards,
Brian