Subject: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 26 Jul 2011 08:11:35 -0400

FYI.

-------- Original Message --------
Subject: I-D Action: draft-arkko-core-security-arch-00.txt
Date: Tue, 26 Jul 2011 04:16:19 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : CoAP Security Architecture
	Author(s)       : Jari Arkko
                          Ari Keranen
	Filename        : draft-arkko-core-security-arch-00.txt
	Pages           : 22
	Date            : 2011-07-26

   Constrained Application Protocol (CoAP) is a light-weight protocol
   designed to be used in machine-to-machine applications.  This memo
   describes challenges associated with securing CoAP and proposes a new
   security model that the authors believe is suitable for these
   environments.  The model requires minimal amount of configuration,
   but still provides strong security and is a natural fit with the
   typical communication practices smart object networking environments.
   This memo also proposes JSON payload format extensions to support the
   architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-arkko-core-security-arch-00.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Garcia Morchon, Oscar" <[email-masked]>
Date: Tue, 26 Jul 2011 17:07:46 +0200

All,

Below you find comments on the draft. Two main comments:

Comment A) My main comment is that the threat model and actual security/operational needs for which the architecture has been designed are missing. Thus, it is rather difficult to analyze how well the architecture fits some use cases or others.

Comment B) My feeling is that we have to align in security to make clear how thoughts/solutions fit together. In our draft we describe a number of security profiles, in such a way that applications with basic security needs have basic security mechanism; applications with more strict threats introduce more advanced security mechanisms. It would be good to describe the security architecture for CoAP/6LoWPAN networks in these terms.

Regards,

        Oscar.

-----------------------------------------------
(some first comments)

Comment related to: "This section discusses three challenges: implementation difficulties, practical provisioning problems, and layering and communication models."
For implementation, it is said that resource-limitations should not be overemphasized. It is true; but it is still key to keep things as simple as possible. If I remember well, the target devices are 100/10.

Comment related to: " This list of short identifiers can then be fed to a central server as a list of authorized devices."
It would be good if the architecture could address ad-hoc settings; very frequent in this type of networks.

Comment related to: "The authors have employed a simple but not completely secure method where the last few digits of the identity are printed on a tiny device just a few millimeters across."
This is a very specific use case. I would suggest to clearly identify the application scope of this approach.

Comment related to: " the private key which never leaves the device."
No all applications can assume usage of PKC.

Comment related to: "Each devices generates its own identity in a random, secure key generation process."
This is written as part of the architecture; should be first listed as a requirement.

Comment related to: "Under most circumstances there is actually no additional configuration effort from provisioning security."
Circumstances should be detailed - otherwise, there is risk of misusing security methods.

Comment related to: " Devices that do not belong to the kit can not claim to be in the group, because the group identity would change if any new keys were added to Igrp."
Approach might fail when thinking about the thing lifecycle (decommissioning and reinstallation) - this should be covered to update group identities.

Comment related to: " then communicated out-of- band to the peers that need to know what devices to trust."
This approach might not scale for networks with 100s of devices.

Comment related to: "A node with identity I  should sign each message it sends with the private key associated with the identity I."
This is very expensive from CPU point of view; PKC cannot be assumed in all devices; this should be supported by standard protocols

Comment related to: "timestamp-based approach SHOULD be used in addition to the basic signatures"
This requires time-synchronization (that should be also secure ;)). This might not be supported by all applications/networks/devices.

Comment related to: "that have seen multiple messages from the same sender SHOULD silently ignore messages that do not have a sequence number greater than the one they have seen last"
This does not work - you should consider at least a window of numbers accepted. Otherwise many messages might be dropped (multiple paths might lead to messages arriving in different order).

Comment related to: "However, it is our belief that the right layer for this solution is at the application layer."
In some applications, lower layers should be protected as well. Otherwise, you can just flood the network.

Comment related to: " This can be supported, with some additional provisioning effort and optional pairing protocols."
In my view, we need a basic provisioning protocol that can really be used in different applications. Otherwise, the amount of code/approaches in the devices is going to exploit. It will be also very difficult to manage all the provisioning approaches.

Comment related to: " In any case, as with sensor networks the amount of configuration information is minimized:  just one short identity value needs to be fed in."
Advanced security policies might require defining which type of information is accepted from a given device.

Comment related to: " there are some remaining vulnerabilities that may or may not be acceptable for the application in question."
For the security architecture, we should first list "addressed threats" and "threats out-of-the-scope"; and then define solution.

Comment related to: "Only identities need to be communicated to the devices, not certificates,"
I think that there are other use cases that require more advanced policies.

Comment related to: " The concrete implementation of the proposed architecture involves a specification for the identity format and generation, and a specification of the data format necessary to carry the signature, public key, timestamp, and sequence number data objects."
My feeling is that this can increase the overhead quite a lot. Do you have numbers for the actual message sizes? It would be also good if the solution could be implemented by means of existing protocols (e.g., DTLS); otherwise we are creating something completely new ... when there are already lots of things out there.

Comment related to: " 5.2.  Identity Generation"
The presented methods can work - but it really seems to me that they are quite bulky. This should fit small devices at the end, right? 100/10.

Comment related to: " RSA public/private key pair SHOULD be used."
Personally, I do believe that RSA is very heavy. If I remember well, 128-bit equivalent security requires 3072 bit RSA keys... no fully sure if this applies to small devices (if the devices can run PKC at all)

Comment related to: " The extension data should consist of a 16-bit length field that  expresses the number of public keys that follow, "
Usage of the fingerprint of the public-key would make things more efficient.

Comment related to: " Every secure message MUST carry a JSON envelope object. "
This can be very expensive (BW/CPU). Fragmentation might be required. Security issues might appear with fragmentation.

Comment related to: " deployment model, security architecture, and an initial sketch of protocol design to support the architecture."
Here I am missing the actual threat model, operational needs, and security requirements of the target deployment. It seems to me that the architecture has been designed starting from HITs. The design needs should be at the beginning. Then list possibilities for doing things. Then describe solution. Then analyze how the architecture fits the requirements identified at the beginning.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Tuesday 26 July 2011 8:12
To: core WG
Subject: [core] Fwd: I-D Action: draft-arkko-core-security-arch-00.txt

FYI.

-------- Original Message --------
Subject: I-D Action: draft-arkko-core-security-arch-00.txt
Date: Tue, 26 Jul 2011 04:16:19 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

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.