1 / 13

Fast Re-authentication

Fast Re-authentication. Dan Harkins. Roaming in 3.0. 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.

dorothy-cross
Download Presentation

Fast Re-authentication

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. Fast Re-authentication Dan Harkins Dan Harkins, Trapeze Networks.

  2. Roaming in 3.0 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 3.0 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 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. Dan Harkins, Trapeze Networks.

  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, 802.11i/D3.0 does not mention any way to take advantage of this! Dan Harkins, Trapeze Networks.

  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. Dan Harkins, Trapeze Networks.

  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” Bit 0 Bit 1 Bit 2 Bits 3-15 1=yes 1=yes 1=yes reserved 0=no 0=no 0=no supports pairwise keys supports pre-authentication supports re-authentication Dan Harkins, Trapeze Networks.

  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. Dan Harkins, Trapeze Networks.

  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”. Dan Harkins, Trapeze Networks.

  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 8.4.6 (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. Dan Harkins, Trapeze Networks.

  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. Dan Harkins, Trapeze Networks.

  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 … Dan Harkins, Trapeze Networks.

  13. Proposed: Add support for “re-authentication” to 3.0: • 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 and accompanying text Dan Harkins, Trapeze Networks.

More Related