doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 1 Re-authentication when Roaming Dan Harkins

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 2 Roaming in 2.5 Section 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.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 3 Roaming in 2.5 Section (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.”

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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 , IAPP. There are others (SEAMOBY). Unfortunately, i/D2.5 does not mention any way to take advantage of this!

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 6 The Third Way The AP announces its support for re- authentication in the RSN Capabilities bitfield in the RSN Information Element AP supports pre-authentication AP and STA support re-authentication Bit 0 Bit 1 Bit 2 Bits =yes 0=no reserved STA supports pairwise keys 1=yes 0=no 1=yes 0=no

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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”.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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 (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.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 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.

doc.: IEEE /689r0 Submission November 2002 Dan Harkins, Trapeze Networks.Slide 11 An Idea, Not A Motion Add support for “re-authentication” to 2.5: Description of “re-authentication” as a 3rd scheme in New section to define “re- authentication” Modify the Informative analysis of Modify the RSNE in section This would make a good motion, hint, hint :-)