Subject: [icnrg] D2D security and privacy

From: Aaron Yi DING <[email-masked]>
Date: Thu, 05 Jan 2017 20:10:39 +0100

Hi,

For T2TRG & ICNRG colleagues, a recent survey on D2D security and privacy:
https://www.cs.helsinki.fi/u/yding/publications/comst2017.html 

pre-camera pdf can be found here if you are interested:
https://www.cs.helsinki.fi/u/yding/publications/d2d-pre-camera.pdf 

Cheers,
Aaron

On 20/11/16 20:23, "Aaron Yi DING" <[email-masked]> wrote:

As presented in the Lisbon meeting, our work on Securebox (for IoT security) will appear at ACM CoNEXT CAN '16
http://conferences2.sigcomm.org/co-next/2016/#!/canprogram 

The pre-print and abstract can be found here for those who are interested:
https://www.cs.helsinki.fi/u/yding/publications/can2016.html

Cheers,
Aaron

--
TU Munich, Connected Mobility
https://www.cm.in.tum.de/index.php?id=25

---

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 11 Jan 2017 09:18:46 +0100

Hi Aaron,

Thanks for sharing. A few comments after a cursory read:

The description of the security and privacy requirements in IIa seems a 
bit sloppy. For example:

- a) Authentication seems to be mixing up authentication and 
authorisation
- c) Non-Repudiation: what you say here may not be wrong, but the 
example with the attacker who wants an innocent party appear as an 
attacker is not the most straightforward one. Non-repudiation is 
guaranteeing that authentication can be asserted to be genuine and not 
be refuted later. So a better example may be a system that prevents an 
attacker who was authenticated before to deny authorship of messages 
later.
- e) Confidentiality: this is about ensuring that only *authorized* 
users can access the confidential information.

Best regards,
Dirk

On 5 Jan 2017, at 20:10, Aaron Yi DING wrote:

> As presented in the Lisbon meeting, our work on Securebox (for IoT 
> security) will appear at ACM CoNEXT CAN '16
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 11 Jan 2017 18:17:27 +0100

On 11 Jan 2017, at 09:18, Dirk Kutscher <[email-masked]> wrote:
> 
> 	• c) Non-Repudiation: what you say here may not be wrong, but the example with the attacker who wants an innocent party appear as an attacker is not the most straightforward one. Non-repudiation is guaranteeing that authentication can be asserted to be genuine and not be refuted later. So a better example may be a system that prevents an attacker who was authenticated before to deny authorship of messages later.

A much better term for what this not so great term is usually really meant to say is “third-party verifiability”.

Note that “accountability” (which is what the joe-job example is about) may or may not require third-party verifiability — in many cases it is very much sufficient that you know who did this to you and there is no need to prove to third parties.

It’s 2017 and we still don’t have agreed names for the basic security objectives and security services.  RFC 4949 notwithstanding...

Grüße, Carsten