Fw: RE: [LinkSec] Proposed Scope for LinkSec PAR
Forwarding this message from Bernard Aboba. The original bounced because of
the word adver_tisements.
Dolors
----- Original Message -----
> From: "Bernard Aboba" <bernard_aboba@hotmail.com>
> To: housley@vigilsec.com, stds-802-linksec@ieee.org
> Cc: aboba@internaut.com
> Subject: RE: [LinkSec] Proposed Scope for LinkSec PAR
> Date: Sat, 26 Apr 2003 01:03:37 -0700
>
> >I do not have any problem with the priorities. However, I do
> >have some concerns with the "do it later, if needed" tone. If we look
> >at 802.1X development, it focused on 802.3 problems.
>
> IEEE 802.1X-2001 did not focus on 802.3 problems, per se -- it is an
> authentication technology that can be adapted with surprisingly little
> modification to any IEEE 802 technology.
>
> But -- and here's the rub -- you have to understand where it fits within
> the overall architecture of the access scheme that it's being used with,
> and what it's capable of doing. And you've got to fill in the gaps -- and
to
> do that you've got to have a general architectural model of what you're
> trying to build to understand what's missing.
>
> IEEE 802.1X gives you authentication and keying material, but that's
> all it does. It is *not* a full-fledged key management protocol, and
> doesn't provide a general scheme for negotiating security associations.
> In IKE lingo, there is no equivalent of Phase 2. That means, for example,
> that IEEE 802.1X is not inherently well suited for use with IEEE 802.10.
>
> This is actually an asset in some situations, such as port-based
> network access in media (such as IEEE 802 wired networks) that have
> no Discovery phase or concept of Association. But where Discovery
> and Association are required, there's a big gap -- a gap that needs
> to be filled by something called "Secure Association".
>
> Personally, I believe that "Secure Association" is quite distinct from
what
> has so far been thought of as "802.1X key exchange". So much so that I'm
not
> even sure that it is really part of 802.1X at all, although it shares the
> same EtherType.
>
> >This solved real-world problems. Since a 802-wide view was not applied
> >from the beginning, significant changes are needed to make it work in
> >802.11, and other wireless technologies.
>
> Actually, from the viewpoint of security, the most important difference
> between 802.3 and 802.11 is *not* wired versus wireless. It is that 802.11
> has the notions of Discovery and Association, whereas 802.3 does not.
>
> Lest anyone jump to the conclusion that Discovery and Association arise
> purely out of the needs of wireless media, consider that PPPOE also has
> very similar notions. RFC 2516, Section 5 says:
>
> "The steps consist of the Host broadcasting an Initiation packet, one or
> more Access Concentrators sending Offer packets, the host sending a
unicast
> Session Request packet and the selected Access Concentrator sending a
> Confirmation packet."
>
> Seems quite similar to 802.11, where the Host will send a Probe Request,
> receive one or more Probe Responses, then send an Association Request and
> receive an Association Response, no?
>
> In networks in which multiple providers can share the same media,
> authentication plays a very different role within the overall
architecture.
> There are fundamental reasons why it is necessary to do discovery *before*
> authentication, and authentication *before* association in such networks.
> And of course, to provide any real security, the association *must* be
> secured.
>
> Discovery needs to be done first in order to discover the available
> networks. Because the networks need to be found before authentication (or
> key derivation) can occur, the initial discovery phase is difficult to
> secure with dynamic session keys (e.g. either use static session keys or
> nothing). Authentication occurs next, and there are good reasons to do
this
> *before* association -- it may be necessary to authenticate to multiple
> potential networks without commiting to connect to one or more of them.
>
> The role of Association in such an architecture is to
> provide secure negotiation of capabilities, as well as derivation
> of live session keys for protection of data and confirmation of
> the desire to connect (and activate keys). In 802.11 terms, this
> encompasses the roles of *both* the 4-way handshake and the existing
> 802.11 Association exchange. In fact, I would argue that these two
protocols
> are doing *exactly* the same thing -- that that they *must* be
> merged in order to provide a clear point at which a connection
> becomes active.
>
> Therefore the problems that Russ refers to are really not about 802.1X
> at all (which is after all, only about authentication). They are about
> the nature of secure association.
>
> The essence of secure association is a commitment to communicate with
> a given provider and secure confirmation of *all* parameters relevant
> to that communication, as well as derivation of fresh session keys.
>
> Secure association is a really tricky concept, and before trying to
> secure IEEE 802 media, it's critical to understand whether it's needed
> or not to solve the problem, and if so, what it takes to get it right.
>
> To get secure association right, it is necessary not only to
> provide fresh transient session keys (which the 4-way handshake
> does), but also to securely confirm *all* the capabilities (not just
> ciphersuites) so as to detect potential spoofing during the (insecure)
> discovery phase. It's also necessary to integrity protect the entire
> secure association exchange to avoid DoS vulnerabilities. And of course,
> if the desire is to create something that takes the "IEEE 802 view" --
> then this all needs to be done in a way that any IEEE 802 technology
> can use.
>
> Unfortunately, IEEE 802.11i comes up short on these dimensions.
> IEEE 802.11i attempts to support authentication *both* before and
> after association. Not only is this unnecesarily complex, but it
> also means that keys may not be available with which association
> can be secured -- which means that the required integrity protection
> is not achievable.
>
> Instead of securely negotiating *all* capabilities
> in the 4-way handshake, IEEE 802.11i only confirms ciphersuites.
> This means, for example, that an attacker can spoof rate
> adver_tisements within Beacons with no fear of detection --
> and if it succeeds, then it can downgrade performance of
> every 802.11 station! Also, because IEEE 802.11i does not secure
association
> frames, it enables a station in one part of the network to disconnect
> another user anywhere within the ESS.
>
> The merger of the 4-way handshake and association exchange has
> the potential to fix all this if done right. Basically, if
> we take the 4-way handshake, change its name to Secure Association
> and add in the fields from the Association exchanges, most of
> the issues go away. But we will see if that is what we end
> up with ;)
>
> However, even were all of this to be fixed, there are still
> more obstacles to starting from 802.11 and coming up with
> an "IEEE 802" view, due to inherent differences between
> 802.11 and the rest of IEEE 802. Rather than utilizing
> general IEEE 802 facilities, IEEE 802.11 has its own
> forwarding behavior, and its own discovery exchanges.
> And of course, 802.11 PDUs lack the equivalent of a
> SPI or SAID field.
>
> So in looking at all of this, I have to agree with Mick
> that there's no single existing solution that will provide
> all the pieces or even a majority of them. We'll have
> to piece together a solution to this problem from a number
> of sources.
>
> Overall, my hope is that IEEE 802.1AB can be the foundation
> of a general discovery architecture that could
> encompass much of what 802.11 does with Beacons, Probe Request/Response,
> etc. And I'd hope that a generic "secure association" facility can
> be developed based on what IEEE 802.11i has been doing, though
> considerable reworking may be necessary. And of
> course, IEEE 802.1X will play a part -- though given everything
> that's been said above, it will probably be the least of our
> problems.
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>