HPE7-A01 · Question #73
Drag and Drop Question What is the order of operations tor Key Management service for a wireless client roaming from AP1 to AP2? Answer:
The correct answer is Client associates and authenticates to AP1; Cache the client's information; Generate Pairwise Master Key for AP1's neighbors; Get AP1 neighbor AP list; Share Pairwise Master Key along with VLAN and User Role to target APs. Key Management Service (KMS) - Wireless Roaming Order of Operations This question tests your understanding of Proactive Key Caching (PKC) - the mechanism that pre-distributes security credentials to neighboring APs so a roaming client can re-associate quickly without re-running f
Question
Drag and Drop Question What is the order of operations tor Key Management service for a wireless client roaming from AP1 to AP2? Answer:
Exhibit
Answer Area
Drag items
Correct arrangement
- Client associates and authenticates to AP1
- Cache the client's information
- Generate Pairwise Master Key for AP1's neighbors
- Get AP1 neighbor AP list
- Share Pairwise Master Key along with VLAN and User Role to target APs
Explanation
Key Management Service (KMS) - Wireless Roaming Order of Operations
This question tests your understanding of Proactive Key Caching (PKC) - the mechanism that pre-distributes security credentials to neighboring APs so a roaming client can re-associate quickly without re-running full 802.1X authentication.
Why This Order?
1. Client associates and authenticates to AP1 This must come first - nothing else is possible until the client completes 802.1X/EAP authentication with AP1. This exchange produces the original Pairwise Master Key (PMK). Without it, there is nothing to cache or distribute.
2. Cache the client's information Immediately after authentication, the wireless controller's KMS stores the client's PMK, VLAN assignment, and user role. This cached state is the source of truth for all subsequent steps. If nothing is cached, roaming optimization cannot happen.
3. Generate Pairwise Master Key for AP1's neighbors With the base PMK cached, the KMS mathematically derives unique per-AP PMKs for potential neighbors. Crucially, this derivation is a computational step that does not require the neighbor list yet - the KMS can generate candidate keys from the base PMK independently.
4. Get AP1 neighbor AP list Now the KMS queries which APs are actually in AP1's RF neighborhood. This determines the target set for key distribution. It comes after key generation because the keys are computed from cryptographic inputs (not from topology), while the neighbor list only tells the system where to send the already-generated keys.
5. Share Pairwise Master Key along with VLAN and User Role to target APs Finally, the derived PMKs - bundled with the client's VLAN and user role - are pushed to each neighbor AP. When the client roams to AP2, it finds its PMK already waiting, enabling fast re-association without a full re-authentication.
Common Mistakes
| Misconception | Correction |
|---|---|
| "Get neighbor list before generating keys" | PMK derivation is mathematical, not topology-dependent. Key generation and neighbor discovery are independent; the list is only needed at distribution time. |
| "Skip caching - just generate and push" | The cache is essential. It is the persistent record that allows the KMS to re-derive or re-push keys if an AP is added to the neighbor set later. |
| "Client authenticates to AP2 as part of this flow" | No - the whole point of PKC is that AP2 already has the key before the client arrives, so no new authentication is needed on roam. |
| "VLAN and User Role are optional extras" | They are mandatory parts of the push (step 5). Without them, AP2 cannot place the client in the correct network segment or enforce the correct policy. |
The core mental model: authenticate → cache → derive keys → find targets → distribute. The KMS is front-loading the cryptographic work so that roaming is seamless for the client.
Topics
Community Discussion
No community discussion yet for this question.