IEEE 802.21d discussion, Security Requirements
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