Here is, more or less, a summary of what we
have in 21a from 1000 feet level.
- 21a
specifies mechanism to for mutual authentication between an MN and a PoS.
- 21a
specifies mechanisms to establish a protected tunnel at MIH “layer”
between an MN and a PoS. That is the tunnel is pair-wisely established.
- 21a
specifies to protect MIH messages.
If we use such pair-wisely established
tunnel to distribute a group key, then it can “cut-off” a node
through key update. In this case, it is not to “renegotiate” but to
re-distribute”. (This is not a suggestion. It is an explanation.)
Lily
From: Daniel Corujo
[mailto:dcorujo@xxxxxxxx]
Sent: Wednesday, June 20, 2012
4:48 AM
To: STDS-802-21@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-21] IEEE
802.21d discussion, Security Requirements
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.
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
|