Introduction
============

This document describes the various stages of the authentication / association
process for WPA/WPA2 Networks.  It is intended to give the reader a 'map' of
what pieces come into play and when.

For a more broad overview of authentication procedures, refer to Section
4.10.3 of 802.11.

WPA is an earlier stop-gap solution to WEP security vulnerabilities.
Essentially it is a subset of draft 802.11i.  WPA2 refers to the released
802.11i specification.  WPA2 is more of a marketing term; term used inside
802.11 is RSN (Robust Security Network).  Typically WPA uses TKIP with RC4
(also known as ARC4) stream cipher.  WPA2 uses CCMP with AES stream cipher
which must always be supported.  TKIP with ARC4 is also a supported mode of
operation.


Overview of Getting Connected
=============================

To get connected to a typical WPA2 network the user must first know the
Pre-Shared-Key or PSK.  This key can be generated based on a passphrase
instead of being entered in hex form by the user.  The passphrase generation
is specified in 802.11, Annex M.4.  Since the PSK should be long-lived, it
should not be exposed over-the-air.  For this purpose the PSK is not used
directly; instead a session key is derived.  The process for derivation of
this key is called the 4-Way Handshake.

For the purposes of the 4-Way Handshake below, PSK becomes the PMK (Pairwise
Master Key).  The PMK is also obtained from an EAP exchange, but that is a
different topic.

4-Way Handshake generates a key referred to as the PTK (Pairwise Transient
Key).  PTK is generated by feeding the PMK, AP Nonce (ANonce), STA Nonce
(SNonce), AP MAC Address and the STA MAC Address through a hashing function.
The SNonce and ANonce are randomly generated numbers and are exchanged by the
STA and the AP during the initial two steps of the Four-Way Handshake.  The
third step of the handshake establishes the GTK (Group Temporal Key). The
fourth step serves as the acknowledgement step.

The Four-Way Handshake is accomplished by exchanging EAPoL-Key protocol frames
after performing OPEN_SYSTEM Association to the target AP.


Key Derivation
==============

The PTK obtained from the 4-Way handshake is divided into 3 separate keys:

- 16 byte KCK (Confirmation Key).  The KCK is used in the computation of the
  MIC field used by EAPoL-Key frames.  The KCK is used as input to HMAC-MD5,
  HMAC-SHA1 or CMAC-AES depending on what hashing function is used.

- 16 byte KEK (Encryption Key).  The KEK is used to encrypt data in message 3
  if it contains the GTK.

- 16 byte TK (Temporal Key).  Used to encrypt / decrypt normal packets flowing
  between the STA and the AP.

If TKIP used, then the following elements are also derived from the same PTK:

- 8 byte Michael MIC Authenticator TX Key
- 8 byte Michael MIC Authenticator RX Key

For more details on the Four-Way Handshake, refer to 802.11 Section 11.6.2


Overall Process
===============

- The user selects a network to connect to.  This network can be known
  implicitly or via a scan.  A Probe request or a Beacon must first be
  received and the RSN IE must be stored in order to connect to the AP.  The
  RSN element contains the security parameters supported by the BSS.  This RSN
  element must also be compared against the RSN element received from the AP
  in message 3 of the 4-Way Handshake.

- OPEN_SYSTEM Authentication and Association requests are sent to the AP.  In
  the case of the Association request, the RSN element with the selected
  encryption parameters must be included.

- Once the OPEN_SYSTEM Association is successful, the AP shall send Message 1
  of the 4-Way Handshake.  This comes in the form of EAPoL-Key messages and
  require special privileges / setup in order to be read from the netdev
  device.

- STA records all necessary parameters from Message 1 (ANonce, Key Replay
  Counter).  STA Generates the PTK, constructs Message 2 and sends it to the
  AP.

- Once Message 3 is received from the AP, the STA sanity checks certain
  parameters (Key Replay Counter, ANonce, MIC).  The RSN received from the AP
  is also checked against the one received in Message 3.  If everything checks
  out, then Message 4 is constructed and sent to the AP.

- Based on TK and GTK, the keys are set into the hardware.  The Re-Key offload
  is enabled as well (if supported?)

  Here's an example of how this looks like:

< Request: New Key (0x0b) len 68 [ack]
    Key Data: len 16
        3c 7d 08 8b 94 10 0f 21 06 6d 7b 18 a1 7e e0 ad
    Key Cipher: CCMP (0x000fac04)
    Key Sequence: len 6
        00 00 00 00 00 00
    MAC Address: 24:A2:E1:EC:17:04
    Key Index: 0 (0x00)
    Interface Index: 3 (0x00000003)

< Request: Set Key (0x0a) len 28 [ack]
    Key Index: 0 (0x00)
    Interface Index: 3 (0x00000003)
    Key Default: true
    Key Default Types: len 4
        Unicast: true

< Request: New Key (0x0b) len 64 [ack]
    Key Data: len 16
        2e 15 6e 7c 4e 3d f1 37 09 13 ed bd 62 8e 25 65
    Key Cipher: CCMP (0x000fac04)
    Key Sequence: len 6
        00 00 00 00 00 00
    Key Default Types: len 4
        Multicast: true
    Key Index: 2 (0x02)
    Interface Index: 3

< Request: Set Rekey Offload (0x4f) len 64 [ack]
    Interface Index: 3 (0x00000003)
    Rekey Data: len 52
        14 00 01 00 24 7a 90 94 e5 43 de 1b 1e 3d d4 a0
        5c d0 e7 76 14 00 02 00 28 4d b5 b1 cf bc e4 25
        f4 f5 00 47 64 83 87 bc 0c 00 03 00 00 00 00
	00 00 00 01