RE: [802.21] WG and Security SG Teleconference April 30
Hi All,
After reviewing
https://mentor.ieee.org/802.21/file/08/21-08-0107-00-0sec-threat-modelin
g-and-analysis-for-mih-protocol-security.doc against the existing TR,
the new issues not covered in the TR seem to be as listed, with some
responses and suggestions on what we might do to the TR as a result:
The text about the idea of a security profile for MIH generated the
following differences:
1) Potential threat of 'injecting' bad data into the MIIS database (pg 4
input validation)
- It's not clear how the MICS and MIES can have such injection.
- 802.21 leaves administration of the MIH PoS and update of the IS as
implementation dependent, so the security of such processes is also out
of scope.
-- Suggest we make no changes to TR
2) Configuration management of MIHFID and 'MIH service provisioning' is
not secure
- The system used for this type of configuration management was left as
implementation dependent and so out of scope.
-- Suggest we make no change to TR
3) Session management issues
- Re-introduces the topic of MIH sessions which has been discussed
forever and is clearly not something the protocol supports.
- Since there are no MIH sessions, there are no threats against them.
- MIH can have registration and MIES can have event subscription...
however these are not equivalent to a session as was discussed many
times.
- MIH has transaction ID which does not create a session.
-- Suggest we make no changes to TR
4) Auditing and logging missing
- These are related to MIHF node management and not defined in 802.21,
but left implementation dependent.
- There is no support in the protocol for such management functions, and
presumably no need for the protocol to be involved in these functions.
-- Suggest we make no change to TR
The text in the tables about 'Stage 1' listing threats and
countermeasures has the following differences from the TR:
5) Repudiation threat
- The example of this threat is similar to the 1) above, with bad data
supplied by the MIIS to the MN.
- Nothing in the protocol is directly affected by adding a system of
recording logs for auditing on the backend of an MIH PoS.
-- Suggest we make no change to the TR
6) Elevation of privilege threat
- There is no concept of privilege in the MIH protocol, for example no
levels within the MIHF ID.
- Currently access control to the PoS is not defined in the base draft.
- We need a method of authentication to create SA's, and that will serve
as the access control.
- We could introduce other aspects of access control.
-- Suggest we decide if all or nothing type access control is sufficient
for standardization, or if we need something more to be standardized.
-- Suggest we leave the access control at all or nothing.
Finally, the countermeasures listed here would be provided by using the
IPSec or DTLS mechanisms called out in the IETF transport drafts.
So a simple proposal for a total solution would be to specify that the
MIH protocol be secured by establishing SA's between the MIH entities
using either method.
Best Regards,
Michael
>-----Original Message-----
>From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
>Sent: 29 April, 2008 15:51
>To: STDS-802-21@LISTSERV.IEEE.ORG
>Subject: [802.21] WG and Security SG Teleconference April 30
>
>I assigned 20-minutes for WG Sponsor Ballot issues based on
>request from WG Chair.
>
>Date: April 30 (Wed), 10am - 12pm EST
>
>[1] WG discussion (20min)
>
> + 802.21 Sponsor Ballot issues (Vivek)
>
>[2] Security SG discussion (100min)
>
> + Change of Editor
>
> + PAR draft revised
> -
>https://mentor.ieee.org/802.21/file/08/21-08-0006-07-0sec-802-2
>1-security-par.doc
>
> + TR-related dicussion (Shubhranshu, Lily)
> -
>https://mentor.ieee.org/802.21/file/08/21-08-0107-00-0sec-threa
>t-modeling-and-analysis-for-mih-protocol-security.doc
> - 802 21-IEEE-MIH-Security-04292008.ppt (posted to the reflector)
>
>Bridge information:
> 1-888-699-0348 (US toll free)
> +1-732-336-6000 (other)
> PIN# 5305
>
>Regards,
>Yoshihiro Ohba
>