RE: stds-802-16-mobile: [security ah] Summarizing Ciphers, user certs, EAP
It's interesting that so many people think that 802.16 data security is bad
just because 802.11 security is bad. 802.11 used the RC4 stream cipher
which will give you bytes of the key for every byte of the clear text you
happen to know, coupled with a known first few bytes, coupled with 1 key per
network. Just to make certain changes are made for the correct reason let's
make certain that everyone's understanding of the current 802.16 situation
is 56-bit DES CBC mode, each SS has a separate key, each connection may have
its own key, the IV changes a=every millisecond (at least for
WirelessMAN-SC). While this isn't mil-spec security or even current state
of the art, it's orders of magnitude more secure than what was originally in
802.11. These choices were made for a few reasons:
1) exportability/importability (still a requirement)
2) The fact that we can only protect the air link, not what is before or
after, so anything truly secure must use its own end-to-end security. I.E.,
we were providing privacy, not security.
3) The original 802.16 spec covered only fixed BWA operating at frequencies
above 10 GHz, requiring line of sight. Some of the perceived threats are
extremely unlikely in this situation.
4) The AAS standard was not final when we went to sponsor ballot.
5) While meeting the above reasons, we wanted something a lot stronger than
802.11.
While I don't disagree that the proposed security enhancements may be useful
in some scenarios, I content that we need to be careful to enhance rather
than replace the current security. We also need to be careful to build into
the standard only what is necessary. For example, EAP in RFC 2284 was
originally designed for use with PPP. IETF later standardized it. My
understanding is that it is an encapsulation designed to run over any link
layer. The question would be how best to allow it in 802.16.
The Cryptographic Suite TLV is structured to allow the expansion of the
possible security methods. It was actually designed this way intentionally
because we wanted to be able to add AES in the future. AES should be added
as an alternative. The use of the cryptographic suite TLV already allows
SSs to negotiate their security capabilities. AES should not be made
mandatory at this time due to export/import limitations beyond DES-56.
On the topic of IV overhead, here's a suggestion. I assume the IV must be
sent as clear text. If so, rather than transmit the IV with each packet,
can we come up with a way of calculating the IV so that it can change
without adding overhead. For instance the IV in 802.16 is a function of the
frame number and changes every frame. Granted, there can be many PDUs to or
from the same SS each frame. But we could make it a function of the frame
number and position in the frame. We may lose some randomness, but it's
still a different IV for each PDU, with no possibility of repetition for
hours allowing ample time to change keys.
Ken
-----Original Message-----
From: Jeff Mandin [mailto:jmandin@streetwaves-networks.com]
Sent: Thursday, November 20, 2003 8:23 AM
To: stds-802-16-mobile@ieee.org
Subject: stds-802-16-mobile: [security ah] Summarizing Ciphers, user
certs, EAP
OK. To summarize all this brainstorming ....
[my latest comments are in square brackets]:
1) Ciphers
--------
There is sentiment that DES-CBC is inadequate as a traffic cipher
because:
- its effectiveness depends heavily on the tricky task of
implementing suitable random number generators
- unacceptable potential for an IV or key collision
- no protection from a replay of a valid data packet
[don't we have the same problem with MAC control packets?
also: the HMAC should guarantee the data packet's origin
authenticity as well as the data integrity, should it not?]
The preferred alternative to DES-CBC is AES-CCM [are there other
potential alternatives?] Incorporating AES-CCM to 802.16 includes
the following complications:
- data packet format must be altered to carry a per-packet IV in
addition to the HMAC
- in 128-bit key mode, the KEK must also be 128-bits. Hence the
PKM would have to be adapted.
[ The description of the DES-CBC weaknesses needs to be more detailed if
it is supposed to convince skeptics. Are there any precedents from
802.11? ]
2. User Certification / Device Certification
----------------------------------------
From a customer/service provider perspective there would seem to be 2
basic approaches:
a) the actual SS device is associated with the Service Provider and
the particular set of services that are available (DOCSIS model)
b) the device is bought off the shelf, and the Services are
associated with a smart card, SIM card, or other mechanism.
[In this case it would seem that the MAC address would be
associated with the SIM card, as would be the set
of services offered. So there might be no need at all for a
"device cert" - or rather the SIM card itself would
contain the "device cert" (which would be the only cert).
It might be the case however, that a Sim Card Service Provider
would want to operate only with specific kinds of client devices.
In which case there could be a separate Certificate for the
hardware (whose CA the Service Provider would have to recognize),
If a pair of certificates would be used, it would be necessary to
tunnel the second auth exchange inside the first ie. use PEAP or
something similar.]
Our initial protocol model is that PKM is used for device authorization
if needed), and EAP methods are then used (if indicated) for user
authentication [ need LOTS more detail here. Note that there exist
non-unicast SAIDs - for which keying material is fixed and
non-negotiated. I have some ideas that I'll present soon].
3. EAP issues
-----------
We have strong consensus to support EAP in the 802.16 MAC ( though we
are still hashing out the precise reasons why we want it).
We intend to use PDU formats for transporting EAP messages inside MAC
PKM messages as outlined in the ETRI contribution [though if PKM and EAP
are really orthogonal (and EAP is used only for device auth as DJ
suggests), then it might be possible for us to use 802.1x formats, which
would save us a lot of discussions].
There have been several ideas about what kind of protection is needed
for EAP itself. (sequence numbers, HMAC, Binding to prevent
Man-in-the-middle attack, standardized key distribution) [We need to
specify the threats/concerns in much more detail before continuing in
this direction. In particular I think that we can avoid man-in-
the-middle issues and the complexity of the binding solution by ensuring
that client credentials will not be regarded as valid both inside and
outside of a tunnel].
We seem to agree that 802.1x should be our guide in these matters
[ someone please send a link to 802.1aa or XRev to the reflector].
- Jeff
(Adhoc chair)
--------------------------
Jeff Mandin
Streetwaves Networking