November 2001 doc IEEE 802 11 -01 562

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Authenticated Fast Handoff IEEE 802. 11 Tgi Tim Moore Bernard Aboba Microsoft Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Why Do We Care About Fast Handoff? • 802. 11 is becoming popular on small devices – PDAs, phones, not just laptops • Multimedia applications sensitive to connectivity loss – Audio, Video • TCP sensitive to multiple losses – Loss of an entire window will cause connection to go into slow-start • 802. 11 -1997 fast handoff is fast, simple and insecure – Authentication occurs prior to reassociation so pre-authentication is possible – Management frames are not authenticated, no cryptographic operations in critical path – If all APs use the same WEP key, no inter-AP communication is required • 802. 1 X support complicates 802. 11 fast handoff – STAs have dynamic per-session keys – With 802. 1 X, authentication occurs after reassociation, not before • If re-authentication is required, STAs need to complete authentication conversation before recovering connectivity – Authentication and key management methods requiring public key operations (e. g. EAPTLS) can take several seconds to complete – TLS continuation can decrease round-trips (from 3. 5 to 2. 5) and size of packets • Disconnection time is still significant, particularly if backend authentication server is far away (e. g. “hotspot” scenarios). Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Fast Handoff Scenarios • Enterprise – – 802. 11 wireless access within a corporate campus VLANs may be implemented Authentication may involve passwords, smartcards, token cards, OTP, etc. User authenticates to an authentication server on the same campus • “Hot Spot” – 802. 11 wireless access in airports, hotels, cafes – Authentication is typically password-based • Account at wireless ISP • Wholesale wireless access to corporations may eventually become popular – VLANs typically not implemented – User authenticates to the home authentication server, which may be far away Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Goals for Authenticated Fast Handoff • Fast – Transfer times on order of 20 ms or less, not seconds – No need to re-authenticate after each re-association – Support for complete context transfer (including VLANID) for seamless user experience • Secure – Support for per-session keys, dynamic key generation – Works with all EAP authentication methods – Secure re-association requests and responses, as well as disassociation notifications – Protection against spoofing, denial of service, hijacking • Deployable – Enable deployment of inter-access point protocol (IAPP) without a registration service Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Security improvements Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 802. 11 i: Implications for Fast Handoff • With 802. 1 X, upper layer authentication occurs after ESN association/reassociation – 802. 1 X state machine is driven by association/reassociation events – AP can only be associated with a single STA; since 802. 1 X authentication occurs after reassociation, an ESN STA can only authenticate to a single ESN AP • Full reauthentication to each AP a significant cost – 802. 1 X authentication may involve multiple round-trips, public key operations – Environments with many mobile stations can heavily load the backend authentication server – Desirable to avoid a full reauthentication at every AP • Need to lock all doors left open by classic 802. 11 – 802. 11 i adds dynamic keying (802. 1 X), credible ciphersuite (AES), but… – Need to address other 802. 11 security holes such as unauthenticated management frames • Cryptographic operations now in the critical path for Fast Handoff – ESN reassociated STA cannot access the controlled port of the ESN AP until upper layer authentication completes – Authentication of Reassociation-Request/Response, Disassociation required to prevent hijacking Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Proposed Approach • Authentication of Reassociate, Disassociate frames – Authenticator Information Element added to Reassociation. Request/Response, Disassociation notification frames – Authenticator Information Element enables STA and new AP to provide possession of the unicast authentication session key negotiated with the old access point. • Support within the Inter-Access Point Protocol (IAPP) – New AP passes the Authenticator IE to the with old AP in the Inter-Access Point Protocol (IAPP) Move-Request – Old AP validates the Authenticator – If successfully validated, old AP sends IAPP Move-Response to new AP • New AP includes Authenticator IE in the Re-association-Response – Otherwise, old AP silently discards IAPP Move-Request • • New AP will not send Reassociation-Response STA Reassociation-Request will time out STA, AP will re-authenticate Appropriate 802. 11 f MIB variable is incremented – 802. 1 X “canned success” sent from AP to STA if Authenticator IE included within the Reassociation-Request is valid. Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 802. 11 i Fast Handoff APold STA APnew Associate-Request Associate-Response DS Notified ACK 802. 1 X/Identity Request Transition Period 802. 1 X/Identity Response EAP-Request [Disassociate (Authenticated)] Transition Period Submission ~ RTTSTA-AP ~ n. RTTSTA-AP n =3. 5 (TLS), 2. 5 (TLS continuation) Reassociate-Request (Authenticated) Reassociate-Response (Authenticated) ACK EAP-Success DS Notified Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Authenticator Information Element • Assumes that a key is available either for the current AP (Disassociation, Re-association. Response messages), or with the previous AP (Reassociation-Request message). • Authenticator = HMAC-MD 5(STA MAC address | AP MAC address | Timestamp, ESSID, key) – Timestamp = 8 octet timestamp (see Section 7. 3. 1. 10) to prevent replay – The authentication session key derived from the negotiated master key is used (same key as is used to authenticate the EAPOL-Key message) Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Authenticator Information Element 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | Algorithm | ESSID# | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Element ID: TBD • Length: 19 = HMAC-MD 5 • Algorithm – 1 = HMAC-MD 5 • ESSID# – Number of the ESSID corresponding to this authenticator (for shared use APs) • Authenticator – For Algorithm=1, 128 -bit HMAC-MD 5(STA MAC address | AP MAC address | Timestamp, key) – Authentication key = session key used to authenticate the EAPOL-Key message Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Deployability improvements Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 The Registration Problem • New AP contacts the old AP via IAPP to validate the re-authentication -request, transfer context • IAPP runs over IP – Implication: New AP needs the IP address of the old AP in order to communicate with it • 802. 11 enables the STA to obtain the MAC address of the old & new APs – Client obtains the MAC address of the old AP when it associates/reassociates with it – Client provides the new AP with the MAC address of the old AP in the reassociation request • But how does the new AP locate the old AP IP address? – New AP knows the MAC address of the old AP, not its IP address – Need a way to map the MAC address to an IP address Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Alternate Solutions to the Registration Problem 1. Inverse ARP (RFC 2390) – – 2. AAA protocols • • 3. Problems: Enterprise customers do not wish to deploy yet another service Selecting an AP to run the service requires an election protocol Registration service designs discussed so far (SLPv 2, DNS) have serious flaws Include AP IP address(es) in management messages – – • Authentication server knows where APs are, but… AAA protocols weren’t designed to solve this problem Registration Service (what’s in 802. 11 Tg. F Draft 2) • – – – 4. Assumes APs are all on the same subnet, so not a general solution Note: Having APs on different subnets does not imply change of subnet for the client (possible for the AP to support dynamic VLANs) IP address(es) of new AP provided to STA in association-response, reassociationresponse STA provides IP address(es) of old AP to new AP in reassociation-request Recommendation: Choice 4 – Eliminates need for registration service (and resulting deployment problems) Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Extended Address Information Element • Added to Association-Response, Reassociation. Request and Reassociation-Response messages • Multiple Extended Address Information Elements can be included if the AP has multiple addresses (IPv 4, IPv 6, etc. ) • New AP provides address(es) to STA in Association. Response and Reassociation-Response messages • STA provides new AP with address(es) of old AP in the Reassociation-Request message • AP uses the address(es) to determine the destination for the Move-Request message sent to the old AP. Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Extended Address Information Element 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element ID | Length | Type | Address. . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ • Element ID: TBD • Length: 7 = IPv 4, 19 = IPv 6 • Type: from “Address Family Numbers” in RFC 1700 – 1 = IPv 4 – 2 = IPv 6 • Address – For Type=1, 32 -bit IPv 4 address – For Type=2, 128 -bit IPv 6 address Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 New Status Codes Status code Meaning TBD Reassociation-Request denied due to failed authenticator Reassociation-Response denied due to failed authenticator Disassociation denied due to failed authenticator TBD Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Motion • To amend the TGi draft to include text detailing usage of the Extended Address and Authenticator Information Elements. Submission Tim Moore, Bernard Aboba/Microsoft

November 2001 doc. : IEEE 802. 11 -01/562 r 1 Feedback? Submission Tim Moore, Bernard Aboba/Microsoft