doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 1 Authentication and Key Management of MP with multiple radios Date: Authors:

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 2 Abstract This presentation states the CID #504 from LB126, the secure association setup problem when the multiple radios MP joins into the mesh network, and the suggested solution including the summary text change of the draft. CID#504: PMK-MKD which is derived after the higher-layer authentication should only be related with the authentication credential and some other device information, not tighten-related with the MAC address of a radio. It would induce multiple authentication problems when the mesh node has two or more radios

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 3 Agenda Problem Statement Resolution

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 4 Current Secure association setup mechanism Step2: After MP authenticates with AS through MKD PMK-MKD and MKDK will be derived –Bind with SPA –Multiple initial authentication procedures should be request for multi- radio MP because each radio will has each SPA. Step1: Authentication Method & Role & Key Management type Negotiation Step2:Authentication through MKD & The key hierarchy setup Step3: PTK/GTK distribution 4-Way handshake to build session keys Probe/Beacon Secure communication Peer Link Management Initial Authentication if needed Supplicant Mesh Authenticator

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 5 Current s Key Hierarchy The PMK-MKD and MKDK are bound with SPA. –MeshTopLevelKeyData = KDF-768(XXKey, “Mesh Key Derivation”,MeshID, MKD-NAS-ID, MKDD-ID, SPA) There will be multiple SPAs for a multi-radio Supplicant MP; hence there will be multiple PMK-MKDs and MKDKs Multiple initial authentication procedures should have to be launched. Held by MKD, Supplicant & MA PMK-MA=KDF-256(PMK-MKD,”MA Key Derivation”, PMK-MKDName|| MA-ID|| SPA) MSK/PSK Held by MKD & Supplicant PMK-MKD = L(MeshTopLevelKeyData, 0, 256) Held & Derived by Supplicant & MA PTK=KDF(PMK-MA,”Mesh PTK key derivation”,MPTKSNonce|| MPTKANonce|| MA-ID||SPA||PMK-MAName) Held by Supplicant & MKD MKDK = L(MeshTopLevelKeyData, 384, 256) Held & Derived by Supplicant & MKD, deliver PMK-MA MPTK-KD=KDF-256(MKDK, “Mesh PTK-KD Key”,MA-Nonce||MKD- Nonce||MA-ID||MKD-ID) PMK-MA PMK-MKD PTK MKDK MPTK-KD Key Distribution branch Link Security Branch

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 6 Disadvantages of multiple authentications Can not detect the authentication credential is used for different MPs or different radios in the same MP simultaneously. –The authentication credential may be used by multiple MPs simultaneously. Increase the air cost overhead when launching multiple times initial authentication

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 7 The root of the above problem The EAP authentication should occur between the peer and EAP server –The low layer identity should only identify the supplicant There are multiple MAC addresses in multi-radio MP which can not only identify MP –Each radio each MAC address –Clarify how to only identify the MP The link security association should bind tightly with the MAC address which identify the wireless radio module. –The radio’s MAC address should still be used to derive PTK

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 8 Agenda Problem Statement Resolution

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 9 Solution Requirements The initial authentication should only be launched once when an MP join the mesh network, no matter how many radios it has. –Authentication credential is issued one MP device –One PMK-MKD and one MKDK for an MP, shared by all the radios Different radio in the same MP should use different PTK. –Distribute keys for radios of the device through one time initial authentication procedure There should be one MPTK-KD between an MA and MKD. –The communication between MKD and MP is not tied to a peer link with MAC addresses Less modification, more better.

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 10 Possible solution Clarify two identifiers –MP-ID: the identifier of the MP. It could be one of the MAC addresses of the MP if it has more than one PHY, and it could not be changed once it determined. –MPA: the MAC address of the communicating radio module of the MP. –Three roles when MP doing authentication and key hierarchy, and different ID names to identify the roles which actually is ‘MP-ID’. Amend the current security solution defined in D2.0 –Bind PMK-MKD,MKDK and PMK-MA to SP-ID instead of SPA MeshTopLevelKeyData = KDF-768(XXKey, “Mesh Key Derivation”,MeshID, MKD- NAS-ID, MKDD-ID, SPA SP-ID) –Only one MPTK-KD between an MA and MKD The key is to protect the communication between the two node entities, not the link level –PTKs should bind with peer link MAC addresses Rename the ‘MA-ID’ into ‘MAA’ (Mesh Authenticator Address), because the MAA has the same definition of ‘MA-ID’ in s D2.0 MP-IDMPA SupplicantSP-IDSPA AuthenticatorMA-IDMAA MKDMKD-IDN\A

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 11 Peer Link Management negotiation clarify Get the MP-ID besides the radio MAC address (MPA) The MP-ID is used to do the selector MP determination –Do not use MPA, because there are multiple MPAs which can not only identify the MP. Link instance is still bound with MPAs – MP1 MP2 I’m MP-ID#1, MPA#1, Who are u? I have PMK-MA#1... I’m MP-ID#2, MPA#2, Who are u? I have PMK-MA#1, PMK-MA# PMK-MA negotiation by MP-ID Role negotiation PMK-MA negotiation by MP-ID Role negotiation I’m supplicant, use PMK-MA#1 OK, I’m authenticator, I could use PMK-MA#1...

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 12 Initial authentication clarify 1.Supplicant MP uses PLM to tell the SP-ID to MA in MSAIE and trigger the initial authentication procedure 2.MA transfers the SP-ID to MKD in Mesh EAP encapsulation frame 3.Supplicant MP and MKD use SP-ID to derive the PMK-MKD, MKDK, PMK-MA and to request PMK-MA AS Sup MP MAMKD 2. EAPOL (EAP-Request Identity) 3. EAPOL (EAP-Response Identity) 5. EAP Transport (EAP-Response Identity) 7. EAP Transport (EAP- Success, MSK) 9. EAPOL (EAP-Success) 1. EAPOL-Start 4. Mesh EAP encapsulation (SPA, SP- ID) Derive Pairwise Key (PMK-MKD, MKDK, PMK-MA) 8. Mesh EAP encapsulation(EAP-Response) 6. EAP-specific (mutual) authentication Peer Link Open (Request Authentication, SPA, SP- ID)

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide s Key Hierarchy Clarify MAA: the authenticator MP’s MAC address SP-ID: the identifier of the supplicant MP which should be the same as its MP-ID. MA-ID: the identifier of the authentication MP which should be the same as its MP-ID. MKD-ID: the identifier of the MKD which should be the same as its MP-ID MeshTopLevelKeyData = KDF-768(XXKey, “Mesh Key Derivation”,MeshID, MKD-NAS-ID, MKDD-ID, SPASP-ID) Bind with MPs Held by MKD, Supplicant & MA PMK-MA=KDF-256(PMK-MKD,”MA Key Derivation”, PMK-MKDName|| MA-ID||SPA SP-ID) MSK/PSK Bind with MPs Held by MKD & Supplicant PMK-MKD = L(MeshTopLevelKeyData, 0, 256) Bind with Radios Held & Derived by Supplicant & MA PTK=KDF(PMK-MA,”Mesh PTK key derivation”,MPTKSNonce|| MPTKANonce|| MA-ID MAA||SPA||PMK-MAName) Bind with MPs Held by Supplicant & MKD MKDK = L(MeshTopLevelKeyData, 384, 256) Bind with MPs Held & Derived by Supplicant & MKD, deliver PMK-MA MPTK-KD=KDF-256(MKDK, “Mesh PTK-KD Key”,MA-Nonce||MKD- Nonce||MA-ID||MKD-ID) PMK-MA PMK-MKD PTK MKDK MPTK-KD Key Distribution branch Link Security Branch

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 14 Summary updated text of the Draft New Abbreviations: –MP-ID: Mesh point Identifier –MPA: Mesh Point Address Change the SPA into SP-ID when deriving the MKDK,PMK-MKD and PMK-MA. Change the MA-ID into MAA when deriving the PTK. Change the criterion of selector MP Add the local MP-ID subfield in MSA IE in order to let the pair MPs know the identities of each other. Change the SPA into SP-ID in EAP Authentication field to send the SP-ID to MKD. Extend the definition of MA-ID and MKD-ID to support multiple radios MP. Encapsulation Type Replay Counter SPA SP-IDEAP Message Length EAP Message MA- ID Option al Param eters Peer Nonce Local Nonce Chosen PMK Selected Pairwise Cipher Suite Selecte d AKM Suite Local MP- ID Handshake Control LengthElement ID

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 15 Summary updated text of the Draft(cont’) Change the SPA into SP-ID in Mesh Key Transport Control field when requesting the PMK-MA PMK- MKDName SPA SP-IDReplay Counter

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 16 Conclusion Less modification, more efficiency –Add the ‘MP-ID’ to only identify the MP, especially for the multiple radio MPs, and hence the SP-ID, MA-ID, MKD-ID when the MP is in different roles. Extend the definition of MA-ID and MKD-ID to be an unique identify of the MP devices, which are more reasonable to be named as an identifier also. –Add the local MP-ID(6 bytes) field in MSA IE to let the pair MPs know the identities of each other when building the link. –Rename the ‘MA-ID’ to ‘MAA’ in PTK derivation formula to make the PTK bind with peer links

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 17 Reference Draft_P802.11s_D2.00

doc.: IEEE r6 Submission July 2008 Charles Fan,Amy Zhang, HuaweiSlide 18 Motion Moved, To adopt the normative text in 11-08/526r6 resolving CID 504 and direct the Editor to incorporate it into the Draft. Moved: Second: Result: