On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M <mohit.m.sethi=
40ericsson....@dmarc.ietf.org> wrote:
> Hi Alan,
> Cleaning up the email. The current draft says the exporter should be
> called once as:
>
> Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> Type-Code, 128)
>
> and then split the 128 into MSK (64) and EMSK (64). As said, from initial
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and
> once in eap_tls_getKey). Both the calls are with exactly the same context,
> context length, and labels. In getKey, the EMSK parts are cleared with
>
> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
>
> while in get_emsk, they are read with
>
> os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> EAP_EMSK_LEN);
>
> Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
> Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I
> was thrown off by Joe's comment "The mechanism for splitting the MSK into
> Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy
> cases (WEP, MPPE?)" and the fact that other EAP methods only export MSK.
> Other EAP methods leave it to the AAA architecture for splitting up the
> MSK. Why should EAP-TLS be different?
>
[Joe] EAP TLS was defined before the keying framework so it
explicitly called out those keys. Originally, there were RADIUS attributes
for carrying send key and receive key material defined for MPPE. These
were reused to carry key material when WEP was integrated with 802.1x/EAP.
With 802.11i and the EAP revision things were made more formal and the MSK
was defined, but the same RADIUS attributes were used for key transport.
Essentially, 802.11i takes the First half of the MSK and uses it as the PMK
for the 4-way handshake, this is transported to the authenticator in the
ms-mppe-recv-key attribute. The second half of the key is sent in the
ms-mppe-send-key attribute and may be used by some other IEEE
specifications. Newer attributes have been developed for key transport in
RADIUS over the years. I don't know their adoption rate at this
point. THe EMSK was developed as a key that was shared between the AAA
(EAP Server) and supplicant (EAP-Peer) that is not known to the
EAP-Authenticator. We could leave the definition of how to derive the
receive and send keys from the MSK in the EAP-TLS spec and reference it
from this one. Or we could just include it.
> --Mohit
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
