1 / 14

Authenticated Roaming

Authenticated Roaming. Tim Moore Bernard Aboba Microsoft. Authentication of Management Frames. Two distinct classes within management frames Management frames that cannot assume existence of a unicast key Management frames used for first time association: Association-Request/Response

knox
Download Presentation

Authenticated 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. Authenticated Roaming Tim Moore Bernard Aboba Microsoft Tim Moore, Bernard Aboba/Microsoft

  2. Authentication of Management Frames • Two distinct classes within management frames • Management frames that cannot assume existence of a unicast key • Management frames used for first time association: Association-Request/Response • Management frames used prior to Association: Beacon, Probe Request/Response • Can be authenticated with a multicast key • Goal is “rogue AP avoidance” – subject of this presentation • Management frames that can assume existence of a unicast key • Management frames used for roaming • Reassociation-Request/Response, Disassociation • Can assume association with a previous AP • Can be authenticated with the unicast key from the previous AP • Goal is “authenticated fast handoff” • Covered in depth in a future presentation Tim Moore, Bernard Aboba/Microsoft

  3. The Rogue AP Problem • The Issue • Good news: 802.11 is becoming ubiquitous • Bad news: 802.11 is becoming ubiquitous • Rogue APs becoming common • Typical scenario: employee brings an AP to work, employees associate with it • Why SSID is not sufficient • Many clients configured to associate with ANY SSID • Client will associate with the rogue AP, will eventually fail mutual authentication, BUT • Authentication failure can require several round trips, significant computation • Client user experience significantly disrupted • Is there a way to optimize recognition of rogue APs? Tim Moore, Bernard Aboba/Microsoft

  4. What is a Rogue AP? • An AP that has not been “blessed” by the administrator • An AP that has no security association with an authentication server • An AP that does not hold user credentials for the authenticating user • How can a STA identify a rogue AP? • An AP that cannot mutually authenticate • Intentional vs. Unintentional Rogue APs • Intentional rogue AP could have obtained the multicast key • Unintentional rogue AP would not bother to obtain the multicast key • Assumption: Neither would be able to obtain the unicast key • Security vulnerabilities in the Inter-Access Point Protocol might make this a bad assumption Tim Moore, Bernard Aboba/Microsoft

  5. Goals of Rogue AP Detection • Addressing inadvertent rogue APs • Client should not reassociate with a rogue AP • Client should not waste time in failed mutual authentication with a rogue AP • Ease of administration • Additional configuration should not be required • Compatibility with shared use APs • Definition: APs that advertise more than one SSID Tim Moore, Bernard Aboba/Microsoft

  6. Non-Goals of Rogue AP Detection • Strong security • The desired protection is more analagous to a “cookie” than a true authentication • Substitute for real authentication • Rogue AP detection is only an optimization; does not verify station claim of identity • Real authentication such as via 802.1X still necessary • Deterring damage from intentional rogue APs • Since management messages are exchanged prior to authentication or context transfer, station and AP do not yet have a session key established • Therefore, only a group secret shared by station and AP can be used • Candidate: multicast group key or something derived from it • This means that stations that have authenticated and obtained the group key can forge messages; rogue APs could be set up to use this multicast group key • Result: Intentional rogue AP would not be deterred from forging management messages Tim Moore, Bernard Aboba/Microsoft

  7. Authenticator Information Element • Used to authenticate two classes of management frames • Frames which can be authenticated via a unicast key • Frames which can only be authenticated via a multicast key • Authenticator = HMAC-MD5(STA MAC address | AP MAC address | Timestamp, ESSID, key) • Timestamp = 8 octet timestamp (see Section 7.3.1.10) • Keying • Unicast: The authentication session key derived from the negotiated master key is used (same key as is used to authenticate the EAPOL-Key message) • Used for Reassociation Request/Response, Disassociation • Multicast: The authentication session key derived from the multicast key • Used for Association Request/Response, Beacon, Probe Request/Response Tim Moore, Bernard Aboba/Microsoft

  8. Authenticator Information Element 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | Algorithm | ESSID# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Element ID: TBD • Length: 19 = HMAC-MD5 • Algorithm • 1 = HMAC-MD5 • ESSID# • Number of ESSID corresponding to this authentication • Authenticator • For Algorithm=1, 128-bit HMAC-MD5(STA MAC address | AP MAC address | Timestamp, key) Tim Moore, Bernard Aboba/Microsoft

  9. Obtaining the Multicast Group Key • Initially, the STA will not have the multicast group key for a given SSID. • STA will be unable to authenticate beacons, probe request/response • STA will associate with an AP, and attempt to mutually authenticate • If mutual authentication succeeds, STA obtains multicast key for the SSID • Multicast group key can be used to authenticate subsequent Beacons, Probe Request/Responses • No need for additional administrative configuration Tim Moore, Bernard Aboba/Microsoft

  10. Computational Load • Beacons: 10 per second • HMAC-MD5 • Assume 30 cycles/byte • Assumptions • Timestamp: 8 octets • Address identification blob: 7 octets • SourceMAC: 6 octets • ESSID: 10 octets • Approximate cycles consumed/second: 9000 • Computational load should not be significant Tim Moore, Bernard Aboba/Microsoft

  11. Information Element Processing • Send • Information element must be included in management messages • Beacon, Probe Request/Response: multicast key used in keyed MIC • Re-associate request/response and disassociate request: unicast key used in keyed MIC • Receive • If the STA has a key corresponding to the SSID, then if the keyed MIC is invalid on reception, the frame must be silently discarded • STA validates the MIC in a beacon, probe response before deciding whether to roam to an AP • Timestamp is validated as well Tim Moore, Bernard Aboba/Microsoft

  12. 802.11F issues • Multiple Move-Notify messages can be received from the same client • How do we determine which is the latest one? • Recommendation • Add a sequence number to the re-associate (10.3.7.3: MLME-Reassociate-indication) Tim Moore, Bernard Aboba/Microsoft

  13. Motion • To amend the TGi draft to include functionality for authentication of management messages. Tim Moore, Bernard Aboba/Microsoft

  14. Feedback? Tim Moore, Bernard Aboba/Microsoft

More Related