Hi Martin, Thanks for pointing this out. I think Ben also mentioned this in his review. I am not sure if it is necessary to add the type-code to the label when it is already part of the label string as 'EAP_TLS'. Other TLS based EAP methods should ideally register labels of the form EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the EAP-TLS label) as is currently done in https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.
I do agree with your point about the incorrect usage of the context. Perhaps the ideal choice here would be Server-Id and Peer-Id (if client certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. However, I checked the wpa_supplicant implementation and currently these values are not available. As far as I can tell, the Server-Id and Peer-Id are not exported for any EAP method. So we'll need to think what's the right thing to do: update implementation/use some other sensible value/or leave the context empty (which is allowed in RFC 5705). --Mohit On 1/8/21 12:41 AM, Martin Thomson wrote: > Hi Joe, > > Thanks for doing this, I think that this is a distinct improvement (and I > will take your word for the difficulties involved with further splits). > > One point that I made poorly perhaps, and was dismissed, might be worth > restating: > > MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64) > > The inclusion of a type code as context is, I believe, a misuse of the field. > As this is a fixed value, the value is being used for domain separation. > However, that is the function of the exporter label input. The label exists > to establish that this is EAP-TLS and the key is (in this case) MSK. If you > need different derivations for different type codes, I strongly suggest that > this be included in the label. > > The Context input exists to pull in variables from the context that endpoints > might need to agree on. It is not for domain separation. For example, if > you thought it necessary to authenticate the Identity values that client and > server exchange, you might add those to this field. (As an aside, you might > want to consider that as their value could be used to determine what > parameters to feed into the TLS handshake.) > > If, however, you have an adjacent usage of EAP that wants its own MSK, then > that is domain separation. The right thing to do would be to create new > labels for that usage. > > This might be a fine point in light of the fact that these all just get fed > into HKDF, but I think that it is important to respect the purpose for which > these inputs were designed. > > Cheers, > Martin > > On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote: >> >> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok <al...@deployingradius.com> wrote: >>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M <mohit.m.se...@ericsson.com> >>> 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? >>> Yes. >>> >>> Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and >>> EXPORTER_EAP_TLS_EMSK, which seem simple enough. >>> >> [Joe] I created a pull request >> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17) with the >> proposed labels. Is this change going to cause significant problems >> for implementation? >> >>> Alan DeKok. >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
