On Thu, 1 Dec 2022, at 13:44, Eliot Lear wrote:
> Th proposed change is as follows:
>
>
>
>> 4.2.13. Crypto-Binding TLV
>>
>> The Crypto-Binding TLV is used to prove that both the peer and server
>> participated in the tunnel establishment and sequence of authentications. It
>> also provides verification of the TEAP type, version negotiated, and Outer
>> TLVs exchanged before the TLS tunnel establishment.
>>
>> The Crypto-Binding TLV MUST be exchanged and verified before the final
>> Result TLV exchange, regardless of whether there is an inner EAP method
>> authentication or not. It MUST be included with the Intermediate-Result TLV
>> to perform cryptographic binding after each successful EAP method in a
>> sequence of EAP methods, before proceeding with another inner EAP
>> method_each successful Intermediate-Result TLV to perform cryptographic
>> binding after each EAP authenticaiton or basic password method, before
>> proceeding with another authentication exchange. If no MSK or EMSK has been
>> generated and a Crypto-Binding TLS is required then the MSK Compound MAC
>> field contains the MAC using keys generated according to section 5.2_. The
>> Crypto-Binding TLV is valid only if the following checks pass:
>>
> I think we need to back up and review the three cases that we have:
>
> 1. There is an inner method. This means there is no issue (yay!).
> 2. No inner method but authentication.
> 3. No inner method and just TLVs.
> What value is crypto-binding offering in the latter two cases? I'm not sure
> I see any.
>
Fewer conditionals/branching points in implementations?
At the moment the rule is "start with S-IMCK[0]" and then both:
* mix in MSK goodness and track that progression
* mix in EMSK goodness and track that progression
If we ignore that the RFC should have stated MSK/EMSK needs to be handled
separately for IMSK/IMCK purposes, this is mostly straight forward.
If we start throwing in some exceptions, it it going to make implementations
harder to follow and to describe.
Though there may be zero practical use for the Cryptobinding now, it is more
difficult to explain to implementers this then just letting them continue doing
the Cryptobinding dance.
> If there is any value, then is simply zeroing the field seems wrong. Section
> 5.3 talks about the BUFFER being created from outer TLV information. But
> outer TLVs are not protected. Thus anyone can calculate this with zero'd
> fields. This means we may wish to use TLS seed information. But again, I'm
> not sure I see value here.
Unless I have mis-understood, I think zero'ing the MSK is not a problem, it is
mixed with S-IMCK which is derived from the TLS keying material which is
private. I see it as a label/seed into a hashing function.
> If we choose to zero the field as is suggested in Section 5.2, then I suggest
> we just say that in the text rather than referring to the entirety of Section
> 5.2. In this case we could VERIFY the erratum.
>
I would zero the field. It seems to be the easiest thing, as implementations
already have to do this when there is no MSK to call upon, and we do not have
to bog implementers down with exceptions and additional conditionals.
Thanks
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
