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