1. Changes to SAE State Machine
July 2008
doc.: IEEE /0836r1
July 2008
Changes to SAE State Machine
Date:
Authors:
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

2. Abstract This document describes the changes being proposed to the SAE
July 2008
doc.: IEEE /0836r1
July 2008
Abstract
This document describes the changes being proposed to the SAE
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

3. Uniqueness of SAE State Machine
July 2008
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.
Dan Harkins, Aruba Networks

4. Changes to SAE State Machine
July 2008
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.
Dan Harkins, Aruba Networks

5. Changes to SAE State Machine
July 2008
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.
Dan Harkins, Aruba Networks

6. Changes to SAE State Machine
July 2008
Changes to SAE State Machine
Peers offer each other acceptable but different algorithms
Peer with “lower” MAC
Peer with “higher” MAC
offer group 4
offer group 22
Commit, group 4
Commit, group 26
“lower” MAC,
change offer
“higher” MAC, repeat offer
Commit, group 26
Commit, group 26
Confirm
Confirm
Dan Harkins, Aruba Networks

7. Changes to SAE State Machine
July 2008
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.
Dan Harkins, Aruba Networks

8. Changes to SAE State Machine
July 2008
Changes to SAE State Machine
One peers offers an unacceptable algorithm
Peer with “lower” MAC
Peer with “higher” MAC
Commit, group 26
Commit, group 4
offer group 4
offer group 22
“higher” MAC, repeat offer
group 26 is
not supported!
Reject, group 26
Commit, group 26
group 26 is still
not supported!
Reject, group 26
Commit, group 4
pick another group, ignore
second rejection…
Confirm
Confirm
Dan Harkins, Aruba Networks

9. Changes to SAE State Machine
July 2008
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.
Dan Harkins, Aruba Networks

10. Changes to SAE State Machine
July 2008
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 last-received 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.
Dan Harkins, Aruba Networks

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

12. References 11-08-0799-00-000s-sae-state-machine-changes.doc July 2008
Dan Harkins, Aruba Networks