Subject: [Ace] draft-zhu-ace-groupauth-00

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 24 Feb 2014 12:42:48 +0100

Hi Judy, Hi Minpeng,

thanks for your contribution. I read through the use case and the problem statement writeup. I believe I understand what you are trying to accomplish.

A few remarks:

* It is rather unlikely that the server will periodically query all sensors (like in the smart meter scenario you describe in your document). Instead, it is more likely that the devices will periodically wake up and report their consumption to servers. Why? The server will have difficulties to reach all sensors since they are sleeping most of the time (for lower power consumption) and because of NATs and firewalls. There is also a problem with finding a suitable identifier to contact these devices.

* In your document you refer to the concept as 'group authentication' but I would call it proxy behavior. I thought that you use case is already covered by the CoAP specification based on the introduction of CoAP proxies. I might be wrong but that was my impression.

Ciao

Hannes

---

From: 齐旻鹏 <[email-masked]>
Date: Wed, 26 Feb 2014 01:58:16 +0800

Hi Hannes,

Sorry to reply late . Your comments are valuable to discuss. Pls see response inline.

BRs,

Minpeng

发件人: Ace [mailto:[email-masked]] 代表 Hannes Tschofenig
发送时间: 2014年2月24日 19:43
收件人: [email-masked]
主题: [Ace] draft-zhu-ace-groupauth-00

Hi Judy, Hi Minpeng, 

A few remarks: 

//Minpeng: In some scenario, it requests high stability service that the server needs to confirm whether all sensors are good or not. If it found some sensor couldn’t work properly, the server should take some action fast, such as to warn people to change the bad sensor, or to get rid of such sensor from the network. What is more, some trigger solutions are needed when the server wants to connect to the sensors. But I agree with you, the scenario the device report to server is more likely 

//Minpeng: Good question. Your impression touches the key point which triggers this draft. The fast reply is: introducing CoAP proxies can solve part of the problem, but not all. 

The reason is: in the normal case, proxy will works as following: proxy authenticates all sensors, then proxy will authenticate with server ON BEHALF OF all sensors. That is to say, the server must fully trust proxy, no matter how it authenticates sensors, no matter what the sensors are under proxy’s control. However, in some cases, the server may want to know what exact sensors it could control under proxy’s cover. Furthermore, considering some deployment, the sensor and server could trust fully each other, but the proxy is deployed by 3rd-party, so it couldn’t be fully trust. The server should consider that proxy could report a fake sensor or hide some existing sensors. So it needs to validate sensor’s identity still. But with current solution, it can’t reach such purpose. As a result, group authentication requirement is raised. 

Hope this clarification make you more clear.

Ciao
Hannes