1. A Better Way to Protect APE Messages
September 2009
doc.: IEEE /1008r0
September 2009
A Better Way to Protect APE Messages
Date:
Authors:
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

2. September 2009
doc.: IEEE /1008r0
September 2009
Abstract
This document describes how to extend SIV protection to the full messages used in the APE exchange
Dan Harkins, Aruba Networks
Dan Harkins, Aruba Networks

3. Authenticated Peering Exchange
September 2009
Authenticated Peering Exchange
Goals
Establish a secure peering with another mesh point
Generate a shared, pairwise key to use when communicating with that mesh point
Inform the mesh point of the local broadcast/multicast key and become informed of the mesh point’s broadcast/multicast key
How these goals are achieved
The PLM protocol
An exchange of nonces and a Key Derivation Function using a previously-established PMK (viz, the result of SAE authentication)
Encrypt and authenticate the group key before transmission
Dan Harkins, Aruba Networks

4. Authenticated Peering Exchange
September 2009
Authenticated Peering Exchange
Tools used by APE to achieve these goals
A key derivation function that creates a key-encryption-key (AKEK) and a key-confirmation-key (AKCK)
SIV for key wrapping uses the AKEK
AES-CMAC for message integrity uses the AKCK
Issues
Double authentication, inefficient
To bind the MAC addresses to the key requires duplicating them inside a “key data” blob, thus imposing security requirements in a non-cryptographic way
AES-CMAC is extraneous since SIV accepts “associated data”
The AKCK is not needed if SIV protects everything.
AKCK | AKEK = KDF(PMK, context, data)
header
(MAC addresses)
MAC addresses
encrypted
and
authenticated
authenticated
GTK
MIC
Dan Harkins, Aruba Networks

5. Authenticated Peering Exchange
September 2009
Authenticated Peering Exchange
Cryptographic requirements on APE messages
Data source authentication– it’s really coming from that peer
Data source integrity– it’s what the peer really sent
Key wrapping– only the real recipient can unwrap the key
SIV-- Authenticated Encryption with Associated Data
Deterministically it does key wrapping
Probabilistically it encrypts and authenticates
It accepts additional data that is authenticated but not encrypted
It retains security even when a nonce/counter is re-used, unlike other authenticated encryption schemes
SIV can satisfy all the requirements of APE
Dan Harkins, Aruba Networks

6. New Authenticated Peering Exchange
September 2009
New Authenticated Peering Exchange
AEK = KDF(PMK, context, data)
SIV protects whole frame
MAC addresses from header are a component of AAD
Action frame header is a component of AAD
Entire frame is encrypted with AEK, binding the MAC addresses and Action frame header to the GTK directly.
“wrapped” key is bound to the MAC addresses since they are used to “unwrap” it
header
(MAC addresses)
KEY
AAD
Mesh Peering Management
frame
MIC
APE IE
PLAINTEXT
CIPHERTEXT
AES-SIV IV
Dan Harkins, Aruba Networks

7. Is this Secure? Short answer: yes Long answer: September 2009
Semantic security is not possible in a deterministic scheme, but this isn’t wholly deterministic, we’re not just doing key wrapping
Each frame is structurally unique
Action frame header has the action frame field value
Mesh Peering IE has local and peer identifiers
APE IE has (one or both of) the local nonce and peer nonce
Tuple of <key, action frame field value, identifiers, nonces> will be unique across all invocations of APE provided the nonces are not repeated
Even if tuple is repeated security is not lost. Only the slight leakage of information: the same frame was protected with the same key twice. No key recovery, no plaintext recovery possible.
Remember: SIV is misuse resistant!
Dan Harkins, Aruba Networks

8. September 2009
Motion
Instruct the editor to incorporate the changes in document s-protection-of-ape-messages.doc into the Draft
Yes:
No:
Abstain:
Dan Harkins, Aruba Networks