Suggested Changes to the Abbreviated Handshake

1. Suggested Changes to the Abbreviated Handshake Authors: Date: 2009-03-08 Dan Harkins, Aruba Networks

2. Abstract This document presents some suggested changes to the Abbreviated Handshake which will simplify construction and processing of frames it uses. Dan Harkins, Aruba Networks

3. The Abbreviated Handshake • The Abbreviated Handshake performs multiple tasks • It authenticates peers by having them prove possession of a PMK. • It derives a session key for use with a symmetric cipher, like CCMP. • It allows the two peers to exchange additional text to agree upon a shared state. • There are two components • A core exchange in which the peers exchange random nonces and authenticate by signing their identities and the other party’s nonce. • Additional data necessary for establishment of a peering is exchanged and also signed. • This document suggests changes to the second component, not the first. Dan Harkins, Aruba Networks

4. Additional Text Handling in the Abbreviated Handshake • If the two peers do not arrive at a shared, common view of state then authentication must have failed. • Which says nothing about what that state is, only that authentication guarantees that the state is shared. Some state may be critical to the establishment of a peering and other state might just be nice to have. • Provided that changes do not allow the peers to arrive at a different view of state, the changes are not security critical. • Provided that the changes do not eliminate state required to establish a peering they are not protocol critical. • These changes only modify how the peers exchange their additional text. They are do not eliminate state required to establish a peering nor are they security critical. Dan Harkins, Aruba Networks

5. Indication of a Peering Frame in the AH Frame control duration • Peering Open and Peering Confirm frames are action frames. • Action frames have a field value of: • Peering Open value • Peering Confirm value • Peering Close value • All peering frames contain a Peering Management IE with a subtype of: • Peering Open subtype • Peering Confirm subtype • Peering Close subtype DA SA BSSID Field Value= OPEN Category= PLM sequence Element ID = PMIE Length Subtype= OPEN Local link ID Peer Link ID Reason Duplication! Dan Harkins, Aruba Networks

6. The Abbreviated Handshake(an abbreviated view) Peering Open Frames RSN IE, Mesh ID IE, Mesh Config IE, Peering Mgmt IE, AH IE, MIC, HT IEs, Other IEs RSN IE, Mesh ID IE, Mesh Config IE, Peering Mgmt IE, AH IE, MIC, HT IEs, Other IEs Peering Confirm Frames RSN IE, Mesh ID IE, Mesh Config IE, Peering Mgmt IE, AH IE, MIC, HT IEs, Other IEs RSN IE, Mesh ID IE, Mesh Config IE, Peering Mgmt IE, AH IE, MIC, HT IEs, Other IEs Dan Harkins, Aruba Networks

7. Processing of Peering Frames • There is checking of parameters and verification that some are equal and others are not equal. • Various IEs must be checked, a subset of which is: • Check the PMK chosen • Check the AKM chosen • Check the MIC • Check the Pairwise Cipher chosen Dan Harkins, Aruba Networks

8. PMK Selection • A peering frame for AH contains an RSN IE, which contains a list of PMKs. • 11B.3.2.4 says, “The chosen PMK shall be the first PMK announced in the supported PMK list….” • A peering frame for AH contains an AH IE which contains a chosen PMK field. • This creates some issues • What is the purpose of indicating the chosen PMK in two different places? • Since there can be only one PMK between any given pair of MPs why even bother indicating the choice of the only PMK available? Dan Harkins, Aruba Networks

9. AKM Selection • A peering frame for AH contains an RSN IE, which contains a list of AKMs. • A peering frame for AH contains an AH IE which contains a selected AKM field which must match the first AKM in the list in the RSN IE (according to 11B.3.2.5.1) • This creates some issues: • What is the purpose of indicating the chosen AKM in two different places? • What purpose does choosing an AKM serve? • We have only one AKM defined so there is no ambiguity. • The authentication procedure specified by an AKM generates the PMK, the PMK has already been selected, implicitly or explicitly, so the AKM must already be implicitly selected. • A PMK derived from one AKM must not be used with another AKM so there isn’t a need to indicate which AKM you want to use with a given PMK Dan Harkins, Aruba Networks

10. Checking the MIC • First of all, this should be done first. • One should check the validity of a frame before parsing it. • Of course this puts the cart before the horse vis-à-vis PMK selection, but that shows the problem with PMK selection as it is currently specified. • The MIC is not an IE and its order is in the middle of the frame. This is unnecessarily cumbersome for a receiver. The MIC should be the first blob of bits after the generic action frame header. • The MIC field includes a “key name” but the key used is nameless and is derived from the already named (and selected) PMK. • The MIC covers “the sender’s MAC address, the receiver’s MAC address, [and] all contents of the frame except the MIC field.” This is a tad ambiguous: • The two MAC addresses are already part of “all contents”? • How do you exclude the MIC? Zero out the place it goes before computation or compute the MIC without the field and the insert the MIC into right place in the frame prior to transmission? Dan Harkins, Aruba Networks

11. Checking the MIC (continued) • The MIC is the output of AES-CMAC. • A Peering Open frame also contains an AH IE which contains a GTK “wrapped” with AES-SIV. • AES-SIV is an authenticated-encryption algorithm that allows additional authenticated data. No need to double authenticate. • Data that AES-SIV “wraps” grows by 128 bits, which is the size of the output of AES-CMAC which is the size of the MIC. • Just use AES-SIV to protect the whole frame! • A Peering Open frame contains a peer’s random nonce and its group key, either will ensure semantic security of an AES-SIV protected Open. • A Peering Confirm frame contains the other peer’s random nonce which ensures semantic security of an AES-SIV protected Confirm. • The Peering Close frame is constructed completely different. Dan Harkins, Aruba Networks

12. Checking the Pairwise Cipher • A peering frame for AH contains an RSN IE, which contains a list of supported Pairwise Cipher suites. • A peering frame for AH contains an AH IE which contains a selected Pairwise Cipher suite field. • Agreement on the Pairwise Cipher suite is done by comparing the ordered lists in the RSN IE and, apparently, the selection in the AH IE is not used (according to 11B.3.2.5.2) • Why not make the AH IE have a list? • Peering Open list contains the offer, possibly more than one. • Peering Confirm contains the selection, a list of only one. It is not possible to construct a Confirm without seeing a peer’s Open and receipt of an Open after a Confirm already has special “go back and make sure” processing defined so all the processing logic is already in place. Dan Harkins, Aruba Networks

13. Recommendations • Remove the subtype from the PM IE. • Get rid of the RSN IE. • Not needed for PMK selection: the PMK is explicitly selected with the AH IE, and since both frames contain a MIC, the PMK is already committed to anyway. • Not needed for AKM selection: a PMK is generated by a protocol indicated by an AKM and it’s not possible to use a PMK with multiple AKMs. The AKM is implicitly chosen by the PMK. In addition, the AH IE explicitly mentions it. • Not needed for Pairwise Cipher suite selection: use the AH IE. Need text to check the list matches that in a beaconed RSN IE (if it’s beaconed). • None of the other fields are relevant to the AH. • Modify the MIC field • Remove the “name” component of the field • Move the field to the front of the frame after the generic header • Use AES-SIV to authenticate the entire frame and encrypt everything after the (MIC after the) generic header. The “growth” from AES-SIV is put into the MIC field which is zeroed out prior to application of AES-SIV. We can get rid of the AKCK since the key used for AES-SIV is the AKEK. Dan Harkins, Aruba Networks

14. Straw Poll • I would support a motion to make these changes to the draft if a document describing them had been on the server for four hours Agree: Disagree: Maybe, But Needs More Discussion: Don’t Care: Dan Harkins, Aruba Networks