1 / 11

Re-authentication when Roaming

Explore the implementation of re-authentication as a third scheme for roaming in wireless networks. Discover the benefits and resolve issues with pre-authentication methods.

djust
Download Presentation

Re-authentication when Roaming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Re-authentication when Roaming Dan Harkins Dan Harkins, Trapeze Networks.

  2. Roaming in 2.5 Section 8.4.1 describes 2 schemes for roaming: • If the AP supports pre-authentication the STA is expected to pre-authenticate prior to roaming. • If the AP does not support pre-authentication the STA is forced to go through a complete 802.1X authentication. Dan Harkins, Trapeze Networks.

  3. Roaming in 2.5 Section 8.4.6 (3): “When a STA (re)associates with an AP without a (recent enough) pre-authentication, the AP has no cryptographic keys configured for the STA. In this case, the AP’s Authenticator will force a full 802.1X authentication.” Dan Harkins, Trapeze Networks.

  4. Roaming in 2.5 Problems with this “either-or” approach: • A STA can only pre-authenticate with APs it notices during its MLME-SCAN. Depending on how often MLME-SCAN is done a moderately mobile user may move faster than she can pre-authenticate. • Unless there is a sufficient amount of coverage overlap everywhere pre-authentication may not be possible. • Pre-authentication necessarily creates more security associations than needed. Could be problematic in a large, mobile environment. Dan Harkins, Trapeze Networks.

  5. A Third Way • It is possible for the AP to have the cryptographic keys (namely the PMK) for the STA when it roams. • One such context transfer protocol would be a proposal from IEEE 802.11, IAPP. There are others (SEAMOBY). • Unfortunately, 802.11i/D2.5 does not mention any way to take advantage of this! Dan Harkins, Trapeze Networks.

  6. The Third Way • The AP announces its support for re-authentication in the RSN Capabilities bitfield in the RSN Information Element Bit 0 Bit 1 Bit 2 Bits 3-15 1=yes 1=yes 1=yes reserved 0=no 0=no 0=no STA supports pairwise keys AP supports pre-authentication AP and STA support re-authentication Dan Harkins, Trapeze Networks.

  7. The Third Way • When a STA re-associates with an AP that supports re-authentication and with which it has not pre-authenticated it sends an empty EAPOL key message (with the request bit set) indicating a desire to begin the 4 way handshake. • AP retrieves the client’s cryptographic state using the cryptographic context transfer protocol. Dan Harkins, Trapeze Networks.

  8. The Third Way • Upon receipt of the PMK the STA shares with the “old AP” the “new AP” begins the 4 way handshake. • Security association, including session keys bound to the MAC addresses of the “new AP” and STA, is created. • If the 4 way handshake fails the STA must disassociate from the “new AP”. Dan Harkins, Trapeze Networks.

  9. Benefits of Re-Authentication • No interoperability impact on existing deployed base. • If the “re-authentication” bit is not set in the RSNE the assumption from 8.4.6 (3) stands. • A client that does not support “re-authentication” will merely do a full 802.1X authentication with an AP which does. • An addition, not an alternative to “pre-authentication”. • Agnostic on the particular cryptographic context transfer protocol. Dan Harkins, Trapeze Networks.

  10. Benefits of Re-Authentication • No violation of the single use requirement on the PMK. • No security issues: • Proof of possession of the PMK authenticates the STA to the AP under the identity retrieved from the cryptographic context transfer protocol. • Proof of possession of the PMK authenticates the AP to the STA as part of a trusted system. • All of the security requirements are on the cryptographic context transfer protocol and the devices that speak it to make up the trusted system. Dan Harkins, Trapeze Networks.

  11. An Idea, Not A Motion Add support for “re-authentication” to 2.5: • Description of “re-authentication” as a 3rd scheme in 8.4.1 • New section 8.4.6.2 to define “re-authentication” • Modify the Informative analysis of 8.5.3.11 • Modify the RSNE in section 7.3.2.17 • This would make a good motion, hint, hint :-) Dan Harkins, Trapeze Networks.

More Related