July 2008 doc IEEE 802 11 080836 r

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine Date: 2008 -07 -13 Authors: Submission 1 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Abstract This document describes the changes being proposed to the SAE Submission 2 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Uniqueness of SAE State Machine • The commit messages do a key exchange and the confirm messages do key confirmation. • It’s necessary to have the key before you can confirm the key, so there is a distinct order to the messaging. • Note: this is different than the PLM state machine! • Protocol Rules – A MP can commit at any time – A MP can confirm after it has committed and its peer has committed – A MP can accept after its peer has confirmed. Submission 3 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine • Split functionality between a “parent process” and multiple “protocol instances” that progress through the defined state machine. • Handle the case where different authentication algorithms are proposed by the two peers – This can result in rejection if the offered algorithm is not accepted. – This can result in an ambiguity if the offered algorithm is acceptable but different than the one already offered. • Ensure that replay of a confirm message to a protocol instance in Accepted state cannot result in a failure. Submission 4 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine • Peer offers an algorithm that is supported but differs from the one local instance offered. – The peer with the “higher” MAC address sends offer once more and remains in committed state. Resending the offer is necessary to prevent livelock. – The peer with the “lower” MAC address accepts the new group, discards the old commit message, generates a new commit (using the new group) and a confirm message and transitions to confirmed state. Submission 5 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine Peers offer each other acceptable but different algorithms Peer with “lower” MAC offer group 4 Peer with “higher” MAC Commit, group 4 Commit, group 26 “lower” MAC, change offer group 22 “higher” MAC, repeat offer Commit, group 26 Confirm Submission 6 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine • Peer offers an algorithm that is not supported – Send rejection (status code=13) with algorithm that was rejected – Remain in committed state with retransmission timer set. No need to resend offer, the MP has responded to the offered group but has not yet received a response to its offer (a Rejection could be received or different Commit could be received, just wait). – Peer who receives a Rejection offers another group from its configuration or gives up • If the former we’re back to square 1, checking whether the algorithm being offered matches the algorithm that was offered • If the latter the retransmission timer will ensure the local protocol instance gives up, assuming we didn’t receive the peer’s rejection. Submission 7 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine One peers offers an unacceptable algorithm Peer with “lower” MAC Peer with “higher” MAC Commit, group 4 Commit, group 26 is not supported! Reject, group 26 Commit, group 26 is still not supported! Reject, group 26 Commit, group 4 offer group 22 “higher” MAC, repeat offer pick another group, ignore second rejection… Confirm Submission 8 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine • To deal with the possibility of frame loss a protocol instance in Accepted state must be able to receive a (another) commit message and respond with a (another) commit message. • If both peers are in Accepted state an attacker can replay a commit message. – This can result in a storm of commit messages as the action upon receiving a commit in Accepted state is to send a commit to a peer in Accepted state who sends a commit back…. – To quell the storm an error counter is incremented and after enough the peers give up. But this allows for a trivial attack: just replay one commit message and after the storm the peers give up. Submission 9 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine • Solution: A replay counter! • Behavior on sending: – A “send-commit” counter is added to the Authentication frame of each commit message. Its value is authenticated. – While not in Accepted state the counter is incremented each time a commit message is sent. – When transitioning into Accepted state the counter is set to “infinity”. • Behavior on receipt: – The “send-commit” counter is checked upon receipt against a lastreceived counter. “Old” and invalid commit messages are dropped. – “New”, and valid, commit messages are responded to as long as the “send-commit” counter is not infinity. Submission 10 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 Changes to SAE State Machine Confirm messages can be resent/replayed Peer with “lower” MAC Peer with “higher” MAC Commit in committed state in confirmed state Confirm, 1 in confirmed state in accepted state confirm message is valid, counter is not infinity, send confirm again Submission Confirm, 2 timer fires, retransmit confirm message is valid and has infinity as counter, transition into accepted state, do not retransmit. Confirm, infinity 11 Dan Harkins, Aruba Networks

July 2008 doc. : IEEE 802. 11 -08/0836 r 1 References • 11 -08 -0799 -00 -000 s-sae-state-machine-changes. doc Submission 12 Dan Harkins, Aruba Networks