1. Nancy Cam Winget, Atheros
March 2002
Secure Roaming
Greg Chesson, Atheros
Nancy Cam Winget, Atheros
Jesse Walker, Intel
Doug Whiting, HiFN
Greg Chesson,Atheros, et al.

2. Outline Motivation and Objectives Definitions
March 2002
Outline
Motivation and Objectives
Definitions
Association/Authentication
Secure Roaming Framework
Details
Greg Chesson,Atheros, et al.

3. Motivations 802.11 architecture requires two key handoff procedures:
March 2002
Motivations
architecture requires two key handoff procedures:
Initial contact X AS to AP/STA
Roaming: from 802.1X AS or old AP or STA to new AP
Claims
Different methods for each case introduces too much complexity to get right
To be secure, key exchange between STA and AP must be tied to the back-end key handoff protocol
Greg Chesson,Atheros, et al.

4. Objectives for Secure Roaming
March 2002
Objectives for Secure Roaming
Utilize the same key-passing procedure both for initial contact and for roaming
Utilize proven authentication procedures
Station-initiated key exchanges
Eliminate AP-AP transactions (!)
Except when AP is also an AS
Greg Chesson,Atheros, et al.

5. March 2002
Definitions
Associate: STA/AP handshake whereby station connects to the Distribution Service (DS) at the AP. Implies nothing about security. A station shall associate with only one AP at a time to ensure DS correctness.
Security Context: synchronized state between a pair of endpoints consisting of identical key material and algorithms and agreement on their usage.
Authentication: process whereby an initial security context is created between an AP and STA.
2-party authenticated key exchange: key exchange with key verification between A and B, involving messages only between A and B.
3-party authenticated key exchange: key exchange between A and B relying on a trusted 3rd party authentication server (AS), with key verification between A and B.
Greg Chesson,Atheros, et al.

6. March 2002
Definitions
Roam: a station moves its DS association from one AP to another.
Secure Roam: a station moves its DS association from one AP/context to another AP/context.
Greg Chesson,Atheros, et al.

7. Association/Authentication Independence
March 2002
Association/Authentication Independence
Station associates without a security context
Legacy definition
RSN Security context possible without association
Unexploited property of RSN 1X proposals
STA does not know address of AS
AP forwards 1X messages to AS on behalf of STA
STA does not need DS for RSN-authentication
Observation: multiple security contexts may exist between one station and several APs.
Greg Chesson,Atheros, et al.

8. Secure Roaming Framework
March 2002
Secure Roaming Framework
Security context is independent of association.
Station maintains multiple independent security contexts at its discretion; e.g. “pre-authentication”.
Each context is a “secure stovepipe” - created by RSN authentication between STA and each AP/AS without message exchanges or key exchange between APs.
A station shall perform standard association after RSN authentication.
Greg Chesson,Atheros, et al.

9. Framework STA AS APa RM APb APc Active association Auth Server MSKa
March 2002
Framework
Auth
Server
Roam
Manager AS
MSKa
APa
MSKb RM
APb
Table:
STA MAC
MSKa 0
MSKb 0
MSKc 1
MSKc
STA
APc
MSKa
MSKb
MSKc
Active association
Greg Chesson,Atheros, et al.

10. Details AP retains MSK context per STA
March 2002
Details
AP retains MSK context per STA
Context may be associated or not
AP forwards association state changes to RM
(side effect of keying protocol)
AS/RM maintains table of stations, keys, associations
AS/RM may provide context removal policy
(new AP/AS message exchange)
Greg Chesson,Atheros, et al.

11. Properties No dependence on an IAPP for security
March 2002
Properties
No dependence on an IAPP for security
Each STA/AP/AS is a “secure stovepipe”
One key-passing protocol used in all cases
Propose Otway-Rees (see next slides)
Pre-authentication now feasible at each STA
Roam via association/disassociation/reassoc.
Appeal to IAPP for DS management only
Greg Chesson,Atheros, et al.

12. Step 1: Encapsulate EAPOL in 802.11 Authentication
March 2002
Step 1: Encapsulate EAPOL in Authentication
Message 1 is null
Message 2 can include any EAPOL message but EAP-Success
Message 3 includes EAP-Success
Need new service interface to allow 802.1X to send these?
Greg Chesson,Atheros, et al.

13. Step 2 – Designing the Stovepipe: Supplicant-Initiated Key Handoff
March 2002
Step 2 – Designing the Stovepipe: Supplicant-Initiated Key Handoff
Use Otway-Rees protocol as the model
Otway-Rees defines a mechanism for distributing keys from a KDC to a server and client that fits our application:
Client contacts Server
Server contacts KDC
KDC responds to Server
Server responds to Client
Greg Chesson,Atheros, et al.

14. Otway-Rees Client Server KDC
March 2002
Otway-Rees
Client
Server
KDC
Cid, Sid, Xid , RC, EKC(RC, Cid, Sid, Xid)
Cid, Sid, Xid , EKC(RC, Cid, Sid, Xid), EKS(RS, Cid, Sid, Xid)
EKS(RS, K), EKC(RC , K)
Assumptions:
KDC and client share a key KC that is used exclusively to encrypt the distribution of the session key K
KDC and the server share a key KS that can be used encrypt the distribution of the session key K
Encryption has data origin authentication built in. This is provided either by some mechanism such as OCB, by a separate MIC and corresponding keys, or by some special construction that allows detection of forgeries.
Message 1 is sent by the client to the new server. Message 1 includes the information Cid, Sid, Xid , RC, EKC(RC, Cid, Sid, Xid), where:
Cid = the client’s ID,
Sid = the server’s ID,
Xid = a transaction id selected by the client
RC = a random challenge generated by the client, to prove liveness of the response from the server, returned in the fourth message.
EKS(RC, Cid, Sid, Xid), an encrypted token protecting the client Cid’s request for a session key with server Sid. The encryption key KS was discussed above and proves that the token was computed by the client. It is computed over the Cid and Sid to prove the client (Cid) wants to communicate with the server (Sid). It is computed over RC and Xid to prevent the server from substituting new values for either. Note that RC  RC, as each exists to prove liveness of a different peer.
Message 2 is sent by the server to the KDC. It includes the information Cid, Sid, Xid , EKC(RC, Cid, Sid, Xid), EKS(RS, Cid, Sid, Xid), where:
Cid, Sid, Xid , EKC(RC, Cid, Sid, Xid) is replicated from Message 1 and represents the client’s request for a session key with the server.
RS, a random value selected by the server, to serve as a challenge the KDC will use to prove the liveness of the third message
EKS(RS, Cid, Sid, Xid), a encrypted value the server uses to bind the server’s request to the client’s.
In response to Message 2, the KDC verifies:
The client’s token decrypts correctly and agrees with the plaintext Cid, Sid, Xid
The server’s token decrypts correct and identifies the same plaintext information as the client’s request
If these checks succeed, the KDC generates a new session key K to be used between the client and server, constructs, sends Message 3, and sends it to the server. Message 3 consists of EKS(RS, K), EKC(RC , K) :
EKS(RS, K) uses the key KS to protect the new session key K and to prove liveness of the response to the server
EKC(RC , K) uses the key KC to protect the new session key K and to prove liveness of the response to the client.
When it receives message 3, the server verifies:
The challenge value RS matches that issued for this request, proving liveness of the response and allowing it to assume the key is fresh.
If these checks pass, the server uses the session key K to construct the fourth message EK(RC, CA), EKS(RC , K) and sends this to the client:
EK (RC, CA) includes the client’s Message 1 challenge RC, to prove it knows the live, fresh key. The inclusion of CA provides a challenge to which the client must respond.
The server passes the token EKC(RC , K) as received from the KDC directly to the client. This will deliver the session key to the client.
When the client receives message 4, it verifies:
The encrypted token EKC(RC , K) includes its challenge to the KDC, proving liveness of the response and presumed freshness of the session key K
If so, it uses the session key K to decrypt the token EK(RC, CA) and verifies this contains the challenge to the server RC.
If these checks succeed, then the station returns message 5 EK(CA) to authenticate itself to the server.
EK(RC, CA), EKS(RC , K)
EK(CA)
Greg Chesson,Atheros, et al.

15. Otway-Rees Adaptation
March 2002
Otway-Rees Adaptation
To use this model:
Let
The Supplicant (STA) play the role of the client
The Authenticator (new AP) play the role of the server
The AS plays the role of the KDC
Let the MSK play the role of the session key K
Separate MIC from encryption
Minimize amount of encrypted data
Greg Chesson,Atheros, et al.

16. Supplicant-Initiated Key Passing
March 2002
Supplicant-Initiated Key Passing
Supplicant (STA) AS
Authenticator (New AP)
Aid, Sid, Xid , RS, NS, MICKS(RS , Xid, Aid, Sid)
Aid, Sid, Xid , RS , MICKS(RS , Xid, Aid, Sid), RA, MICKA(RS , Xid, Aid, Sid)
EKE(MSK), MICKA(RA, EKE(MSK)), EKD(MSK), MICKS(RS, EKD(MSK))
Assumptions:
AS and station share a key KS that is used exclusively to authenticate key handoff;
AS and station share a key KD that is used exclusively as a key encryption key during key handoff;
AS identifies the keys KS and KD by the Supplicant ID Sid;
AS and the new AP share a key KA that is used exclusively to authenticate key handoff;
AS and the new AP share a key KE that is used exclusively as a key encryption key during key handoff;
AS identifies the keys KA and KE by the Authenticator ID Aid.
Message 1 is sent by the roaming station to the new AP. Message 1 includes the information Aid, Sid, Xid , RS , NS, MICKS(RS , Xid, Aid, Sid), where:
Aid = the new AP’s ID;
Sid = the roaming station’s ID;
Xid = a transaction id provided by the STA, included to bind the STA’s information in message 2 to the AP;
RS = a random challenge generated by the station, to be consumed later to prove liveness of the response;
NS = a nonce generated by the station to be used for key derivation, to guarantee key freshness of the derived keys;
MICKS(RS , Xid, Aid, Sid), a MIC value proving the station generated this request. Note this MIC provides no liveness. Rather it is used simply as a filter to limit an attacker to replay attacks against the AS. The MIC key KS was discussed above and proves that the MIC was computed by the station. It is computed over the Aid and Sid to prove the station (Sid) wants to communicate with the new AP (Aid). It is computed over the Xid and RS to prevent alteration of this information, i.e., to prevent an attacker from generating its own values to actively attack the key KS. This in turn implies that the MIC is a normal cryptographic MIC, such as HMAC-MD5 or AES-CBC-MAC, and not a weak MIC such as Michael.
Message 2 is sent by the new AP to the old AP. It includes the information Aid, Sid, Xid , RS , MICKS(RS , Xid, Aid, Sid), RA, MICKA(RS , Xid, Aid, Sid), where:
Aid, Sid, Xid , RS , MICKS(RS , Xid, Aid, Sid) is replicated from Message 1 and represents the station’s request to handoff its MSK to the new AP;
RA, a random value selected by the new AP, to serve as a challenge which the AS will use to prove the liveness in the third message;
MICKA(RS , Xid, Aid, Sid) is a MIC value the new AP uses to bind itself to the station’s request. This MIC is over the same information as the station’s request, except the new AP replaces the stations challenge RS with its own RA. It is computed using the key KA between the new AP and the old AP or AS, proving the message originated from the new AP, although it includes no liveness. The MIC includes the values Xid, Aid, Sid to bind the new AP’s request to the roaming station’s request.
In response to Message 2, the old AP or AS verifies:
The station’s MIC value is correct, using the authentication KS associated with Sid to verify this token was generated by the Supplicant;
The new AP identified by Aid is known and the old AP shares a key KA with it used exclusively for data origin authenticity during key handoff;
The new AP’s MIC value is correct.
If one of these checks fails, then the AS ignores the request. If all of these checks succeed, the AS randomly generates a new key MSK, constructs Message 3, and sends it to the new AP. This consists of EKE(MSK), MICKA(RA, EKE(MSK)), EKD(MSK), MICKS(RS, EKD(MSK)):
EKE(MSK) is the MSK encrypted under the key KE, which is used exclusively for key encryption between the AS and the new AP during key passing;
The first MIC MICKA(RA, EKE(MSK)) is computed over the new AP’s challenge value RA from message 2, proving liveness of the response. It is computed over the encrypted MSK value EKE(MSK) to prevent an attacker from altering the MSK. The MIC is computed using the key KA, to prove the message was constructed by the AS;
EKD(MSK) is the MSK encrypted under the key KD, which is used exclusively for key encryption between the AS and the Supplicant during key passing;
The second MIC MICKS(RS, EKD(MSK)) is computed over the Supplicant’s challenge value RS from messages 1 and 2, proving liveness of the response. It is computed over the encrypted MSK value EKD(MSK) to prevent an attacker from altering the encrypted MSK. The MIC is computed using the key KS, to prove the message was constructed by the AS.
When it receives message 3, the new AP verifies:
The challenge value RA matches that issued for this request;
The first MIC MICKA(RA, EKE(MSK)) is valid under the key KA if computed over the data RA, EKE(MSK).
If either of these checks fails, the Authenticator discards the message. If both these checks pass, the new AP:
Decrypts the MSK using KE, the key encryption key shared between the new AP and the AS used expressly for this purpose;
Selects a new random nonce NA to be used for key derivation;
Calculates K = f(MSK, NS, NA), a key used only for key verification of the MSK with the station, where f is a prf;
Calculates TSK = g(MSK, NS, NA), the transient session key for this association, where g is a prf distinct from f.
The new AP selects a new random challenge value CA for inclusion in Message 4. The Message 4 contents are EKD(MSK), MICKS(RS, EKD(MSK)), NA, CA, MICK(Aid, Sid , RS, CA) and has the following meaning:
EKD(MSK), MICKS(RS, EKD(MSK)) is replicated from Message 3 received from the AS;
NA is a nonce selected by the new AP for key derivation;
CA is the random challenge the new AP issues to the station, which will be used in Message 5 to prove liveness;
The MIC MICK(Aid, Sid, RS, CA) authenticates the exchange to the station. This is computed using the authentication key K derived from the old MSK and nonces NS and NA. This MIC value explicitly covers the Sid and Aid to prevent reuse of the key K by a different pair of parties. It covers the new AP’s CA NA values, to protect it from modification. It cover the station’s RS from the first message, to prove liveness of this response message to the station.
When the station receives message 4, it verifies:
The MIC MICKS(RS, EKD(MSK)) that proves this is a live response involving the AS, since it uses the key KS and covers the station’s challenge RS; this allows it to trust the derived key K below.
If these checks succeed, then the station derives new keys:
Calculates K = f(MSK, NS, NA), a key used only for verification of the MSK with the station, where f is a prf;
Calculates TSK = g(MSK, NS, NA), the temporal session key for this association, where g is a prf distinct from f.
Once it computed K, the station verifies the second MIC value from message 4. This authenticates the new AP to the station, i.e., proves that the AS handed off the MSK to the new AP. If this succeeds, then this verification proves the message liveness, since the second MIC is also computed over the station’s challenge RS from message 1. The Station responds with Message 5 MICK(Sid, CA):
The MIC MICK(Sid, CA) is computed over the Sid, to explicitly say this message came from the station. It is computed over CA, to prove liveness of the response to the new AP. The MIC is computed using the key K, to prove this came from the station;
The new AP verifies message 5 by checking the MIC to authenticate the MSK, i.e., prove the station has possession of the key.
K = f(MSK, NS, NA), TSK = g(MSK, NS, NA)
EKD(MSK), MICKS(RS, EKD(MSK)), NA, CA, MICK(Aid, Sid , RS, CA)
K = f(MSK, NS, NA), TSK = g(MSK, NS, NA)
MICK(Sid, CA)
Greg Chesson,Atheros, et al.

17. Step 3: Expand 8021.X to do Key Passing Right
March 2002
Step 3: Expand 8021.X to do Key Passing Right
First use 802.1X authentication
EAP-Success message triggers key passing
Neither Station nor AP 802.1X authorization state machines transition to “Authenticated” yet
Alter Success message to include MIC based to signal use of key passing protocol
Station transitions to “Authenticated” after sending message 5 of key passing protocol
AP transitions to “Authenticated” after receiving message 5 of key passing protocol
Greg Chesson,Atheros, et al.

18. Step 4: Initial Contact v. Reassociation
March 2002
Step 4: Initial Contact v. Reassociation
On initial contact:
First AS and Station first mutually authenticate
Then AS and Station agree on authentication key KS, key encryption key KD
Finally use KS and KD to run key passing protocol
AS and Station cache KS and KD for later use
On reassociation:
Only run the key passing protocol using cached keys KS and KD
Greg Chesson,Atheros, et al.

19. Step 5: Integrate into TGi
March 2002
Step 5: Integrate into TGi
Remove ASE from (Re)association frames
Reinstate Authentication frames
Declare 802.1X is always used with RSN
Declare independence of authentication and association
Greg Chesson,Atheros, et al.

20. March 2002
To Do
Liaison with 802.1aa, IETF to define EAP encapsulation of key passing protocol
Liaison with RADIUS server vendors to have key passing protocol implemented
Greg Chesson,Atheros, et al.

21. March 2002
Feedback?
Greg Chesson,Atheros, et al.