RE: stds-802-16-mobile: [security ah] Summarizing Ciphers, user certs, EAP
Here are some reasons for why EAP is needed in 802.16:
- Flexibility for Service Providers to allow use of existing credentials
issued to existing customers to be re-used for new 802.16 based
services.
- Allowing existing Service Providers to preserve their investments in
RADIUS servers (the most common AAA protocol) without having to upgrade
them (Assuming EAP and credential EAP-method support exists)
- Allow different billing models to be allowed based on nature of
credentials issued. (Assumes each credential has an EAP method to go
with it)
- Allows future extensibility through the means of a generic framework
that is not fixated on a single credential type.
IMO, EAP should not be limited to device authentication, in fact its
richness is in allowing multiple user authentication methods and based
on varied credential types.
Here are links for 802.1X documents and the page where the latest
802.1aa draft is avaliable (private area - so needs password)
http://standards.ieee.org/getieee802/download/802.1X-2001.pdf
http://www.ieee802.org/1/pages/802.1X-rev.html
best regards,
jose
> -----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
>
>
>