[802SEC] 802.1 comments on draft PAR P802.15.9 Recommended Practice for transport of a key management protocol (KMP) applied to IEEE 802.15 standards
Bob -
Please find below 802.1's comments on the P802.15.9 draft PAR for
Recommended Practice for transport of a key management protocol (KMP)
applied to IEEE 802.15 standard.
Regards,
Tony
Summary
It is far from clear to 802.1 that there is a need for the proposed
project, or even what the real scope of the project might be. The Scope of
the proposed PAR (5.5) says "This Recommended Practice defines a transport
mechanism interface for key management protocols ...". Additional comments
that have been made to justify the project indicates some confusion about
what constitutes a "transport mechanism interface", without illuminating
any reason why such a thing needs to be specific to key management
protocols or why it needs to be defined for a number of key management
protocols which currently use well established protocol multiplexing and
identification procedures. Our comment on this aspect of the PAR is spelled
out in more detail below as point 1 below. An additional comment to justify
the project has also made the contention that "for some 15.4 devices 1X is
just too heavy weight". This contention betrays a very partial appreciation
of what 802.1X comprises, and our comment on this aspect of the PAR is
spelled out in more detail below as point 2.
The proposed PAR appears to set out to redefine the ways in which key
management protocol(s) are instantiated/selected/used even if it proves
true that it "does not create a new KMP". The IEEE 802 and IETF standards
communities have made a considerable investment in thinking through,
specifying, and implementing to a framework that provides interoperability
across a very wide range of scenarios. It appears to be the express intent
of the proposed project to define its own new approach to the key
management problems it believes should be tackled.
At best this will involve a lot of rework, retesting, and repetition of
prior mistakes. More likely scenarios initially deemed to be unimportant
but currently addressed by IEEE 802.1X/802.11/IETF EAP standards will turn
out to be significant, but the differences from those existing standards
will require yet further projects and will result in interoperability
problems. As it stands the justification for this proposed PAR is even
weaker, though similar, to that behind the recent proposal to substitute
alternative international standards for the proven 802.1X/802.11 solutions.
This PAR needs rework. A better approach would be to study what would be
required to support 802.15 key management protocols within the 802.1X
framework, taking into account (and borrowing as much as possible from) the
802.11 experience. A PAR whose wording was very explicit that this was what
has to happen would avoid any semblance of IEEE 802 preaching one thing
(stability, experience, robustness and flexibility of the existing IEEE 802
security framework) in an international context while supporting a more
random approach within IEEE 802.
Details
1. Detail on our comment on "transport mechanism interface"
The "transport mechanism" used by (almost all) key management protocols is
the datagram (packet or frame) with suitable protocol identification. We
are therefore surprised by the comment (made in support of the proposed
PAR) that
"Since there is nothing even close to EthType in .15 (any of them),
there is no simple way to transport any key management. "
Surely the clear answer to this point is to provide a way of supporting
Ethertype identified frames (note that if 802.15 can support LLC frames -
surely a requirement - then there is an existing mechanism to support
Ethertype identified frames (the SNAP SAP).
Further, the key management protocols suggested as being worthy of support
include HIP, IKEv2, and 802.1X. The last of these uses Ethertype protocol
identification, the first two are IP-related and hence rest on Ethertype
usage when used on LANs. If a regular method of supporting Ethertyped
frames is (or has already been) made available then there is no need to
rework this (If protocol procedures need to be augmented then that is
outside the Scope (5.5) of the proposed PAR since that would be new KMP,
however finessed). In contrast if a new way to identify protocols is
invented then the recommended practice will either become a register of
assigned numbers or an additional Registration Authority (or RA
responsibility) will have to be created.
2. Detail on our comments regarding the proposed projects relationship to
802.1X
IEEE 802.1X specifies a framework for port-based access control including
identifying the role played by authentication and authorization. It also
allocates an Ethertype to identify a small number of messages (and simple
accompanying state machines) sufficient to initiate (and transport) EAP
authentication methods (specified by the IETF). IEEE 802.1X-2010 further
specifies a key agreement protocol that is used by IEEE 802.1AE once EAP
authentication has concluded.
Final Remarks
In summary, 802.1X provides a framework and a number of capabilities useful
to authentication and controlling access. The essential aspect of this
framework and details is that they provide a rational, extensible framework
within which our (IEEE 802's) very wide range of requirements can be
addressed while paying proper attention to interoperability and coexistence
so that users' investments can be protected and increased. Because of this
range and flexibility it is possible to make a number of off-hand comments
in order to justify doing something different. These generally take the
form of either pointing out that a different proposal is superior because
it does not have the same capability (it can only do less, and so is de
facto simpler!) or is superior because 802.1X is capable of including (such
as WEP) solutions that are not secure even though these are no longer
admissible. Comments of the form "802.1X is too heavy-weight" carry the
assumption that the '802.1X' referred to includes separation of the
Authenticator and Authentication Server and the use of certain EAP methods,
despite the fact that this possibility is only one aspect of the framework.
There is nothing particularly "heavyweight" about the recognition of a very
small number of message types. There is nothing particularly "heavyweight"
about the use of 802.1X with 802.1AE when pre-shared keys are used without
EAP.
There does not appear to have been any study as to how the objectives of
the proposed PAR could be accommodated within the very simplest aspects of
the 802.1X framework, sufficient to provide the co-existence which would
allow 802.15 to pickup 802.1X/802.11i solutions as the need/demand arises
without further rework. This should happen before the work of the project
begins. If a specific need to extend/modify 802.1X is identified then that
should be undertaken with the consideration and involvement of the 802.1
Security TG. The 802.1 WG is willing to authorize a teleconference Interim
meeting to further discuss these options, should the need exist.
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.