|
Here's
my thoughts on what we might do with security:
There
are arguably three (partially overlapping) layers to 802.16 mobile security, the
link cipher (AES-CCM and DES-CBC), the local network entry and key management
(PKM) and the interaction with network side AAA architectures (currently lightly
defined but involving EAP).
Not
withstanding the need for a more efficient secure link cipher (GCM based?) I
believe the link ciphers are done for now. It would be prudent to wait for
802.1ae and others to go through the pain of specifying an authenticated
encryption mode that is fast, efficient and secure (pick any two) before 802.16
attempts another upgrade. In the meantime, I think the actual requirements will
become much more detailed as we gain deployment experience.
We
know PKM to have a number of security flaws, albeit mitigated by the very high
practical barriers to misuse that derive from the nature of P2PM high frequency
fixed equipment. Rather than attempt incremental upgrades to security with
backwards compatible delta changes to the PKM messaging, I suggest that we go
for a separate PKMv2 with messaging aimed at the needs of mobile equipment. In
the medium term there would be a rough alignment of fixed=PKMv1 and
mobile=PKMv2. PKMv2 would have secure authenticated key exchange, mutual
authentication, base certs etc., generally borrowed from
current examples available elsewhere (802.11i, IETF). This would allow
us to let the current PKMv1 go through without too much fuss and meet the needs
of fixed equipment. Mobile equipment might have something that meets the needs
of mobile operators with PKMv2.
PKMv2
could be done in 16e, A network management PAR or a security
PAR. I think 16e is becoming a stretch and dealing with PKMv2 in a new PAR
would remove a road block from the other mobility work in
16e.
The
AAA network interaction is something tied into the nature of the networks 802.16
becomes part of. I see this as being right on track for a network management
PAR.
So in
summary..
Ignore
link ciphers until a clear need for something new turns up.
PKM
remains as it is, with a version 1 tag as per the current
spec.
PKMv2
gets defined either in a network management PAR or a security
PAR.
AAA is
an integral part of a network management PAR.
Feedback is most welcome..
DJ
Here is the list of
items that can be included in the new Network Management
PAR.
·
802.16 MIB for SS and
BS, including fault management (e.g. fault notification, loop-back, …),
account management (e.g. usage data capture, …), performance management
(performance data capture), security management
·
Provisioned and
Dynamic service flow creation models
·
Service deployment
scenarios and models from the service provider perspective
·
Service flow context
switching during BS – BS handoff from management perspective
·
Service flow context
downloading while roaming into a network that belongs to the same of different
service providers
·
SS management models
(e.g. through the host, circuit city model, through the air interface, …)
Joey
Chou
Intel
Corporation
-----Original
Message-----
From:
owner-stds-802-16@listserv.ieee.org
[mailto:owner-stds-802-16@listserv.ieee.org] On Behalf Of Johnston,
Dj
Sent: Friday,
March 26, 2004 7:53
PM
To:
STDS-802-16@listserv.ieee.org
Subject: [STDS-802-16] [NETMAN_SG]
Network Management Study Group
We need to get moving on inputs to
the network management study group. The goal I put forth to the WG is that we
do our work before and during the May meeting, so this will require us to work
some of the issues on the reflector and maybe have a conference call or two,
if we are to produce a PAR and five criteria during the interim. If we don't
have a workable basis for consensus going into the May meeting, then I expect
we will be asking for an extention in July, and that is a long time, given
that it would then be November before the TG request would be approved by the
EC and NesCom would add more time to the process, so maybe we would be looking
at 2005 before we had a group for real. Finishing in May is a good
plan.
I propose that email directed to
this effort has [NETMAN_SG] in the subject line to allow appropriate
filtering.
The primary thing that led me to
suggesting a study group was the plethora of different things people wanted to
do with respect to network management, network architectures, interfaces, MIBs
and so on and the rapid closure of .16d as a forum in which to address them.
My personal wish list is no secret, you will find it in the comment databases
- security, interfaces, MIBs.
So as a first step, I would like
to request that people forth their ideas for what problems they
think network management group or groups (don't let the name predjudice
the function) should be solving, or what features they should be introducing.
This will give us a list of issues that we can enumerate, sort, sift, rejig,
classify and generally argue about until we can approach consensus on scope
and purpose. But first we need the issues out on the table for all to
see.
A potential benefit I suggested
was that items of questionable scope in .16e might find a more secure home in
a new group. This is not my idea and I have not been in the loop on these
discussions (although I do like the idea), so perhaps it would be useful input
for people who are thinking along these lines to start describing specifics of
what bits in .16e are problematic and might benefit from a group with a
clear scope to address them.
I'll make my suggestions in a
separate email..
(chair 802.16 network management
study group)
|