802.1X and 802.11 key interactions Tim Moore November 2001 Tim Moore, Microsoft

Topics 802.1X key generation 802.1X in small networks 802.1X and VLANs November 2001 Topics 802.1X key generation 802.1X in small networks 802.1X and VLANs Tim Moore, Microsoft

Requirements/Decisions November 2001 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

802.1X 802.1X consists of Authentication Key distribution November 2001 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

November 2001 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

November 2001 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

November 2001 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

Key synchronization during updates November 2001 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

November 2001 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

Roaming between APs No IAPP IAPP 802.1X does re-authentication November 2001 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

801.X and WEP 802.1X must be unencrypted November 2001 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

802.1X and IBSS 802.1X works with IBSS November 2001 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

IBSS and encryption keys November 2001 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

November 2001 802.1X in small networks Tim Moore, Microsoft

802.1X in small networks May want to use shared network password November 2001 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 Tim Moore, Microsoft

November 2001 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

Shared Password implementation November 2001 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

Supplicant state machine November 2001 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

Individual user authentication An example November 2001 Individual user authentication An 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

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

Authentication server authenticating user November 2001 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 Send EAP-failure 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

November 2001 802.1X and VLANs Tim Moore, Microsoft

November 2001 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

November 2001 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

November 2001 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

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

Motion Request 1aa to add to EAPOL-Key message section November 2001 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