Re: [STDS-802-21] IEEE 802.21d discussion, Security Requirements

[Daniel Corujo <dcorujo@xxxxxxxx>]

Hello everyone,

Just to present myself to the ones who don't know me here in the reflector. I am Daniel Corujo, from the Telecommunications Institute of the University of Aveiro, Portugal. I have been collaborating with Antonio on the multicast requirements. Some of you may remember me personally from the Interoperability Event Plugtest in October 2009, in Sophia Antipolis, France, where I presented ODTONE, our open-source multi-operating system 802.21 implementation.

Regarding the security requirements, I also agree with Antonio and Stephen's view, with the focus on PoS authentication, possibly reusing the authentication features proposed in 802.21a. Regarding encryption, it does sound appealing to have the ability to ensure that mis-behaving MN's are cut-off from the MIH signaling exchange by having key-renegotiation mechanisms. However, malicious nodes impersonating a PoS can create a DoS by constantly forcing the renegotiation of the key, despite achieving this through multicast signaling or not. It is probably a bad example, but it illustrates well the problem.

What we could probably try to consider, was the feasibility of extending/enhancing some of the authentication mechanisms existing in 802.21a, by making them able to be executed via multicast signaling in 802.21d.

Daniel Corujo

dcorujo@xxxxxxxx
http://re.vu/dcorujo

On Jun 19, 2012, at 21:30 , Chasko, Stephen wrote:

Hi Antonio,

The use case for confidentiality is based around software updates. I believe the confidentiality of this type of download could be handled by a mechanism outside of the multicast security mechanisms.

Outside of software updates, I don't see a use case for confidentiality.

As such, I would agree that we can just focus on non-repudiation.

This would simplify the discussion and help us focus on an attainable mechanism for a first version of the standard.

Best Regards,


Steve




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.

-----Original Message-----
From: aoliva.it@xxxxxxxxx [mailto:aoliva.it@xxxxxxxxx] On Behalf Of Antonio de la Oliva
Sent: Tuesday, June 19, 2012 2:06 PM
To: STDS-802-21@xxxxxxxxxxxxxxxxx
Cc: tooru.kamibayashi@xxxxxxxxxxxxx; Chasko, Stephen
Subject: IEEE 802.21d discussion, Security Requirements

Dear all,
I am taking advantage of the reflector to continue the discussion
(that has been held for the last 3 ACs) regarding security
requirements for the upcoming IEEE 802.21d.
The main question is what are the security services required for the
IEEE 802.21d use cases. In our current discussion, it seems we agree
on authorization/authentication as the key security mechanism that
must be defined, although there are some participants that think
confidentiality is also required.

Just to trigger discussion and to position myself, as I understand the
aim of IEEE 802.21d, we want to provide handover commands to a group
of MIH Users, in the typical scenario, sensors. If this is the case, I
do not think we need confidentiality here (meaning encryption), the
only thing we need is a way of strongly authenticating the PoS, so no
other node is able to impersonate it. I think encryption is not
required, since the commands are not carrying any information that is
critical and should not be received by other nodes, the worst thing
that can happen is a rogue node executing a handover that was not
addressed to him...

Also, providing confidentiality for multicast communication means we
need to provide mechanisms for key revocation, since a node leaving
the group will mean that the key of the whole group must be changed.

We would really like to hear your thoughts regarding this issue.

BR
Antonio


--
Antonio de la Oliva
Visiting Professor
Telematics Department
Universidad Carlos III de Madrid
E-mail: aoliva@xxxxxxxxxx
Phone: +34 91 624 8803
Fax:   +34 91 624 8749

Attachment: smime.p7s
Description: S/MIME cryptographic signature