RE: stds-802-16-mobile: [security ah] Summarizing Ciphers, user certs, EAP
Ken,
Defining the security as 'bad' is to grossly oversimply the situation,
and this seems consistent with what you are saying. It is unwise for
people to run around claiming .16 security to be bad, when for the base
spec, it is adequate and for the specifications in development it might
not be 'bad' by the time we are done.
802.16 security works to provide a certain security guarantee. This
guarantee just might not be the one that people expect. Further to that,
the security that people expect is not necessarily what a link cipher
can provide.
I believe that we would be wise to provide the reasonable set of
security guarantees that a link cipher can provide, excluding
non-repudiation. I.E.
For the user:
1) Link Privacy
2) Link Data origin authenticity
3) Link Data integrity
For the commercial provider:
4) Protection from theft of service.
At present, 802.16 offers protection from theft of service, providing it
controls both the base and CPE and maintains physical security over the
CPE. This is perfectly adequate for some users.
MITM attacks prevent a security guarantee of privacy and this might be a
problem for some users. However in the fixed case, it is arguably a
difficult thing to deploy such an attack. In the mobile case it is
arguably a simple thing to deploy such an attack.
Origin authenticity and data integrity is something users should be
concerned with but I don't see it as likely that most users would care
to discern the difference between that and privacy.
I have no problem with your assertion that new and existing security
methods should be free to be applied where necessary and the standard
provides the way to extend the security methods consistent with this.
DJ
> -----Original Message-----
> From: owner-stds-802-16-mobile@majordomo.ieee.org
> [mailto:owner-stds-802-16-mobile@majordomo.ieee.org] On
> Behalf Of Ken Stanwood
> Sent: Thursday, November 20, 2003 9:44 AM
> To: 'Jeff Mandin'; stds-802-16-mobile@ieee.org
> Subject: 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
>
>
>