Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-08/0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 1 Changes to SAE State Machine Date: 2008-07-13 Authors:

Similar presentations


Presentation on theme: "Doc.: IEEE 802.11-08/0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 1 Changes to SAE State Machine Date: 2008-07-13 Authors:"— Presentation transcript:

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

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

3 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 3 Uniqueness of SAE State Machine The commit messages do a key exchange and the confirm messages do key confirmation. Its 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.

4 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 4 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.

5 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 5 Changes to SAE State Machine Protocol Instances –Receive events and transition through defined state machine. –Each protocol instance represents an SAE conversation with a peer MP Parent process –Creates, deletes, and manages protocol instances –Receives frames and dispatches them to protocol instances –Has one state only, all events received in this state transition back to this state

6 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 6 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.

7 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 7 Changes to SAE State Machine offer group 4 offer group 22 Peer with lower MACPeer with higher MAC Commit, group 4Commit, group 26 Confirm higher MAC, repeat offerlower MAC, change offer Peers offer each other acceptable but different algorithms Commit, group 26

8 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 8 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 were 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 didnt receive the peers rejection.

9 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 9 Changes to SAE State Machine offer group 4 offer group 22 Peer with lower MACPeer with higher MAC Commit, group 4 Commit, group 26 Confirm higher MAC, repeat offer group 26 is not supported! One peers offers an unacceptable algorithm Reject, group 26 pick another group, ignore second rejection… Commit, group 4 Commit, group 26 Reject, group 26 group 26 is still not supported!

10 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 10 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.

11 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 11 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.

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

13 doc.: IEEE /0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 13 References s-sae-state-machine-changes.doc


Download ppt "Doc.: IEEE 802.11-08/0836r2 Submission July 2008 Dan Harkins, Aruba NetworksSlide 1 Changes to SAE State Machine Date: 2008-07-13 Authors:"

Similar presentations


Ads by Google