Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Mohit Sethi M <[e-mail]>]

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 <[e-mail]> wrote:
>>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls