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

2. 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

3. 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 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 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

5. November 2001
802.1X Key generation
EAPOL-Key is used to send keys between authenticator and supplicant
Sent as 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. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. November 2001
802.1X in small networks
Tim Moore, Microsoft

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. November 2001
802.1X and VLANs
Tim Moore, Microsoft

23. 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
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. 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

25. 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

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

27. 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