802 1x and 802 11 key interactions n.
Skip this Video
Loading SlideShow in 5 Seconds..
802.1X and 802.11 key interactions PowerPoint Presentation
Download Presentation
802.1X and 802.11 key interactions

play fullscreen
1 / 27

802.1X and 802.11 key interactions

0 Views Download Presentation
Download Presentation

802.1X and 802.11 key interactions

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 802.1X and 802.11 key interactions Tim Moore Tim Moore, Microsoft

  2. Topics • 802.1X key generation • 802.1X in small networks • 802.1X and VLANs Tim Moore, Microsoft

  3. Requirements/Decisions • Security session Management • 802.1X owns the security session, decides when to authenticate and re-authenticate • Encryption is offloaded to 802.11 MAC but encryption decision is made during 802.1X authentication by the authentication server – whether it gives the master key to the authenticator • Race Conditions • Synchronization done by always having a free KeyID • Requires 2 KeyIDs for key mapping keys • Roaming and key hand-off • Key messages must be in clear to allow roaming • Reuse 802.1X EAPOL-Key message • Implies that 802.1X must be unencrypted • WEP “rapid rekeying” • Reuse EAPOL-Key from 802.1X • Authenticator “owns” network so stations must obey key messages • EAPOL-Key is acknowledged from receiver because it is a data message • Authenticator is not told if station cannot obey the message • Fast handoff via IAPP supported • Fast handoff enabled by signature in re-association (562) • Liveliness of station/AP via 802.1X authentication or re-associate signature Tim Moore, Microsoft

  4. 802.1X • 802.1X consists of • Authentication • Includes option for always allowed or always denied • Station assumes authenticated if authenticator does not respond • Multiple authentication methods supported via EAP • Key distribution • Requires a master key known by supplicant and authenticator • Normally obtained from authentication but not required by 1X • Supports updating keys but doesn’t give the policy i.e. have often to change keys, how to derive new keys, etc. Tim Moore, Microsoft

  5. 802.1X Key generation • EAPOL-Key is used to send keys between authenticator and supplicant • Sent as 802.11 unicast data packets so message is acknowledged • Requires a master key known by authenticator and supplicant to sign and encrypt the keys being sent in the EAPOL-Key message • Normally master key generated by the authentication • Allows for the master key to be used as a key by sending no key in the EAPOL-Key message Tim Moore, Microsoft

  6. 802.1X re-keying • EAPOL-Key message can be sent anytime after authentication (but may be before EAP-Success) and may be sent multiple times • I.E. authenticator can update keys whenever it wants. • 802.1X re-authenticates to generate a new master key • Recommend re-authentication at intervals e.g. once at hour Tim Moore, Microsoft

  7. EAPOL-Key interval • 802.1X can update the keys without re-authenticating • Update rate is dependent on • CPU load deriving new keys • CPU load to encrypt, sign and decrypt the keys • Waiting for last key update to be updated in hardware • Decrypting and validating key • Current testing shows this to be < 135ms on a current systems Tim Moore, Microsoft

  8. Key synchronization during updates • Doesn’t use time synchronization • Very difficult to synchronize and not lose packets • Note: There is a time stamp in EAPOL-Key messages that can be used to attempt to synchronize the setting of the keys if required • Currently used as replay protection • Use two key indexes • Use one index while updating another index • EAPOL-Key sender always updates its own table before sending message • Receiver should start using new key as soon as it receives the key • Sender can wait until see new index being used by all required receivers before sending with the new key • Allow multiple keys for key mapping table • Currently with key mapping there is a time hole because there is only one key • Note: Already need to support two keys per station for transmit and receive keys • Recommendation: Allow multiple keys for key mapping table Tim Moore, Microsoft

  9. 802.1X/SetKey interaction • 802.1X should use SetKeys to update the encryption key • Call SetKey before sending an EAPOL-Key message • Call SetKey after receiving an EAPOL-Key message • EAPOL-Keys should not use the master key as an encryption key • Stations must be able to derive encryption keys and use EAPOL-Key message to send updates at intervals • EAPOL-Key message should alternate between two key indexes • Two key indexes should be available for each send and receive key • Including Key mapping table • The EAPOL-Key message sender should update keys in the following sequence • Update local receive key • Send the Senders Transmit key • Send the Senders Receive key • Sender should check receive messages for new index being used and start using new key for transmit when all receives indicate they are using new transmit key index. • Update local transmit key Tim Moore, Microsoft

  10. Roaming between APs • No IAPP • 802.1X does re-authentication • Maybe NULL authentication or a fast re-auth (e.g. TLS resume) • Get new master key • EAPOL-Key messages to send new encryption keys to station • IAPP • Client authenticates to new AP via signature in re-associate message • Via IAPP, New AP sends signature to old AP for validation • Old AP validates signature, sends master key to new AP • If session-timeout attribute in IAPP RADIUS context is 0 and termination-action = RADIUS, then • Set 802.1X state to FORCE_AUTH • Else • Set 802.1X portStatus to Authorized • Set 802.1X state to AUTHENTICATED • EAPOL-Key messages used to send new encryption keys to station Tim Moore, Microsoft

  11. 801.X and WEP • 802.1X must be unencrypted • Otherwise on roaming 802.1X is encrypted and the new AP cannot decrypt unless IAPP is supported • Recommendation: Data frames of Ethertype 802.1X (888E) bypass encryption Tim Moore, Microsoft

  12. 802.1X and IBSS • 802.1X works with IBSS • Each station should authenticate who is allowed to communicate to it • Requires 802.1X supplicant and authenticator on each station, see later for simple way to do this • Stations need to learn whether another station needs 802.1X from probe • Need this to decide which encryption key to configure: the master key or a derived key • Need a way to decide who generates the keys • 802.1X doesn’t specify this Tim Moore, Microsoft

  13. IBSS and encryption keys • If different receive/transmit keys are required • Authenticator sends transmit key • If single transmit/receive key is supported • If sending EAPOL-Key dest MAC address < own MAC address • Do not use key as encryption key and use key received in EAPOL-Key messages • Else • Do use in sending EAPOL-Key message and ignore EAPOL-Key messages received Tim Moore, Microsoft

  14. 802.1X in small networks Tim Moore, Microsoft

  15. 802.1X in small networks • May want to use shared network password • How to do this with 802.1X? • May want to have individual user authentication but with simple UI • How to do this with 802.1X? Tim Moore, Microsoft

  16. Shared Password • Use shared password as master key for EAPOL-Key message • Works with Infrastructure and IBSS • Access Point ignores all 802.1X messages from station • No authentication using EAP • Using key distribution and update support in 802.1X • Send EAPOL-Key messages with default and key-mapping encryption keys, the message is signed and encrypted using the shared password • Only supplicants with the shared password can get the encryption keys Tim Moore, Microsoft

  17. Shared Password implementation • Authenticator state machine, authentication server and Radius client not required • Access Point should ignore received 802.1X messages • Supplicant state machine • Need DISCONNECTED, CONNECTING and AUTHENTICATED states (3 out of 7 states) Tim Moore, Microsoft

  18. Supplicant state machine Intialize || !portEnabled DISCONNECTED eapSuccess = FALSE eapFail = FALSE startCount = 0 logoffSend = FALSE Prevousid = 256 suppStatus = Unauthorized eapSuccess && !(initialize || !portEnabled) && !userLogoff && !logSent UCT CONNECTING startWhen = startPeriod startCount = startCount + 1 reqId = FALSE txStart AUTHENTICATED eapSuccess = FALSE eapFail = FALSE suppStatus = Authorized (startWhen == 0) && (startCount >= maxStart) (startWhen == 0) && (startCount < maxStart) Tim Moore, Microsoft

  19. Individual user authenticationAn example • Requires full implementation of 802.1X for supplicant, authenticator and authentication server • Doesn’t require RADIUS • Each station has a self-signed certificate . • Access Point has authenticator and authentication server built in • No radius implementation since both on the same machine • Authentication server and supplicant implements EAP-TLS Tim Moore, Microsoft

  20. Supplicant • Standard EAP-TLS • No difference from talking to an AP that uses RADIUS to the authentication server Tim Moore, Microsoft

  21. Authentication server authenticating user • Check internal table for username • If not allowed, send EAP-failure • Else validate certificate • If valid • If user allowed then • If certificate matches certificate in table then send EAP-success • Else send EAP-Failure • Else display message to admin with username • If admin allows user • Add user and certificate to table with allowed • Else • Add user to table with disallowed • Endif • Else • Send EAP-failure • Endif • Display could be a web page with a list of users requesting for access • Admin can select users to allow/disallow access Tim Moore, Microsoft

  22. 802.1X and VLANs Tim Moore, Microsoft

  23. 802.1X and VLANs • 802.1X suggests the use of VLANs or VPNs to isolate different user groups • Access Point is a level 2 device so VLANs are the obvious way to do this • Need to be able to separate broadcast traffic in 802.11 • Broadcast messages from different ‘networks’ so not duplicating traffic • Use different broadcast keys for each VLAN • Need 2 keys per VLAN to allow the keys to be changed Tim Moore, Microsoft

  24. 802.1X and default key table • Allow the default key table to be increased from 4 keys to 256 keys • Half the keys for transmit and half for receive • Enable the spare bits to be used as part of the keyid • Add attribute to association request containing size of default key table Tim Moore, Microsoft

  25. Motion • To instruct editor to modify the key mapping table to allow 2 keys per station for ESNs and to use the KeyID to select which key is used Tim Moore, Microsoft

  26. Motion • To instruct editor to add text to 8.2.4 so 802.1X data packets are not encrypted Tim Moore, Microsoft

  27. Motion • Request 1aa to add to EAPOL-Key message section • If key management is used and supplicant and authenticator is available at both ends then the lower MAC address owns the key management • Enable the EAPOL-Key carry a Nonce rather than the key material Tim Moore, Microsoft