A Better Way to Protect APE Messages

1. A Better Way to Protect APE Messages Authors: Date: 2009-09-16 Dan Harkins, Aruba Networks

2. Abstract This document describes how to extend SIV protection to the full messages used in the APE exchange Dan Harkins, Aruba Networks

3. 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 • 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) 802.11 header (MAC addresses) MAC addresses encrypted and authenticated authenticated GTK MIC Dan Harkins, Aruba Networks

5. 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 AEK = KDF(PMK, context, data) • SIV protects whole frame • MAC addresses from 802.11 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 802.11 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: • 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. Motion • Instruct the editor to incorporate the changes in document 11-09-0966-01-000s-protection-of-ape-messages.doc into the Draft • Yes: • No: • Abstain: Dan Harkins, Aruba Networks