Security group requirements
Colleagues,
From the TR submission document prepared for the MIH protocol security
requirements:
https://mentor.ieee.org/802.21/file/08/21-08-0011-00-0sec-mih-services-s
ecurity.doc
The following were aspects to be considered:
1) Security of MIHF discovery and MIHF capability discovery:
o There are two kinds of transport mechanisms:
the lower (MAC) layer transport (L2) and the MSTP layer
transport.
o MIHF discovery: over media-specific L2 or higher layer
mechanism
o MIHF capability discovery: either over MIH or over
media-specific broadcast messages
2) Mutual authentication of MIH peer nodes
o No authentication is currently defined by MIH during the
process of MIHF discovery and MIH capability discovery.
o In the CS, the MN authorizes the CS MIHF to issue
commands, so the MN may want to authenticate the CS.
The CS PoS may be willing to direct unknown MNs, or may
require authentication.
o In the IS, the IS MIHF may want to control access to the
information based on authorization,
so the IS MIHF may require authentication of the MN. The
MN MIHF may or may not care if the IS MIHF is known.
o In the ES, the subscriber to the events may or may not
care if the generating MIHF is authentic.
It is also possible the generator may want to allow
subscription for events to authorized remote MIHF only.
3)
o After authentication different MN MIHF may be authorized
to access all or only limited services.
This may help with DoS issues.
o Per-MN management of access rights may be needed, with
additional considerations:
MN may not be known in advance (if belonging to a
different administrative domain.)
MN may not disclose its identity to a visited network.
o Role-based management of access rights may be
implemented.
The role may be based on some aspect of the MN's state
(unauthenticated/authenticated) or its subscription (home/visiting).
o In some implementations the MN MIHF should be able to
select the most *preferred* IS MIHF among all available.
4) Security of MIH Protocol
o MIH protocol integrity and replay protection
o MIH protocol confidentiality.
The TR distills these to:
1.1.2
* Mutual authentication of MIH peer nodes (see 2, also 1)
* Access control to MIH services (see 3, also 1)
* MIH protocol integrity and replay protection (see 4)
* MIH protocol data confidentiality (see 4)
The second bullet of the PAR purpose calls out:
* Define mechanisms that provide data integrity, replay
protection, confidentiality and data origin authentication to MIH
(Media-Independent Handover) protocol exchanges and enable authorization
for the MIH services based on a security association that is bound to
authenticated peer MIH entities.
These three read pretty much in sync with each other, so we are in good
shape. Are there any pieces of the requirements missing?
For example, Tgu has an issue with the DoS possibilities arising from
use of the MIIS in unauthenticated state. We should address this.
Anything else?
BR,
Michael