doc.: ieee 802.11-01/610r0 submission november 2001 tim moore, microsoft 802.1x and 802.11 key...
TRANSCRIPT
doc.: IEEE 802.11-01/610r0
Submission
802.1X and 802.11 key interactions
Tim Moore
doc.: IEEE 802.11-01/610r0
Submission
Topics
• 802.1X key generation• 802.1X in small networks• 802.1X and VLANs
doc.: IEEE 802.11-01/610r0
Submission
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.
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
802.1X in small networks
doc.: IEEE 802.11-01/610r0
Submission
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?
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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)
doc.: IEEE 802.11-01/610r0
Submission
Supplicant state machineDISCONNECTED
eapSuccess = FALSE
eapFail = FALSE
startCount = 0
logoffSend = FALSE
Prevousid = 256
suppStatus = Unauthorized
Intialize || !portEnabled
CONNECTING
startWhen = startPeriod
startCount = startCount + 1
reqId = FALSE
txStart
AUTHENTICATED
eapSuccess = FALSE
eapFail = FALSE
suppStatus = Authorized
UCT
(startWhen == 0) &&(startCount >= maxStart)(startWhen == 0) &&
(startCount < maxStart)
eapSuccess &&!(initialize || !portEnabled)&& !userLogoff && !logSent
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
Supplicant
• Standard EAP-TLS– No difference from talking to an AP that uses RADIUS
to the authentication server
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
802.1X and VLANs
doc.: IEEE 802.11-01/610r0
Submission
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
doc.: IEEE 802.11-01/610r0
Submission
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