doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 1 Fast Re-authentication Dan Harkins

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 2 Roaming in 3.0 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 /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 3 Roaming in 3.0 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 /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 4 Roaming in 3.0 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 /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 5 A Third Way It is possible for the AP to have the cryptographic keys (for example a derivative of the MK) for the STA when it roams. There are proposals to do this but it’s not necessary to constrain solutions. Unfortunately, i/D3.0 does not mention any way to take advantage of this!

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 6 The Third Way The AP obtains a secret from the AS in a manner outside the scope of this PAR. The AS and supplicant derive the secret to use (derivative of [P]MK or the next secret in a series) but the exact derivation is outside the scope of this PAR. This secret is used for authentication and key derivation in the same way that the PMK is used for initial association.

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 7 The Third Way On (re)association the STA requests re- authentication by setting the in RSN Capabilities bitfield in the RSN Information Element. This indicates “I have the secret and want to use it for fast re-authentication” supports pre-authentication supports re-authentication Bit 0 Bit 1 Bit 2 Bits =yes 0=no reserved supports pairwise keys 1=yes 0=no 1=yes 0=no

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 8 The Third Way If the AP does not support re-authentication, does not have the secret, or does not wish to perform re- authentication it responds with an EAP request and a full 802.1X authentication is performed. If the AP supports re-authentication and has the secret it responds with the first message of the 4- way handshake using the secret as the PMK. The client and AP finish the 4-way handshake and create a new key hierarchy.

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 9 The Third Way 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 (or be forced to disassociate) from the “new AP”.

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 10 Benefits of Re-Authentication No interoperability impact on existing deployed base. –An AP which does not support “re- authentication” is required to ignore the “re- authentication” bit so the assumption from (3) stands. –By not setting the “re-authentication” bit in the RSNE a client that does not support “re- authentication” will merely do a full 802.1X authentication with an AP which does.

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 11 Benefits of Re-Authentication Agnostic on the particular cryptographic transfer protocol –Just as we leave the particulars of EAP to the client and AS, we should leave the particulars of how the cryptographic context is transferred to the client and AS. –Able to use any method going forward without having to rev this standard.

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 12 Benefits of Re-Authentication No security issues: –Proof of possession of the secret authenticates the STA to the AP under the identity retrieved from the cryptographic context transfer protocol. –Proof of possession of the secret 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. Limited forward secrecy could be provided! Addresses comments 270, 1537, 2069 …

doc.: IEEE /095r0 Submission January 2003 Dan Harkins, Trapeze Networks.Slide 13 Proposed: Add support for “re-authentication” to 3.0: 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 and accompanying text