RE: stds-802-16-mobile: [security ah] Summarizing Ciphers, user certs, EAP
The requirement in the CCM spec is that and IV,key pair is never reused.
It is explicitly permitted in the CCM spec to derive the IV from
contextual information, such as a frame number, so it does not have to
be sent as plaintext in the frame. We should explore this further.
I'm not sure who the CCM skeptics are. It seems that ccm is the default
case now, since DES is not FIPS approved for new products but CCM is and
its been adopted in 802.11 and elsewhere. If we wanted to incite
controversy, I would suggest CWC or OCB, which I'm not.
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)
> -----Original Message-----
> From: owner-stds-802-16-mobile@majordomo.ieee.org
> [mailto:owner-stds-802-16-mobile@majordomo.ieee.org] On
> Behalf Of Jeff Mandin
> 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
>
>
>