Hi,
I am reviewing the errata on GitHub and would like to close on them.
The first one I am addressing is 5775, which can be found on the RFC
Editor page at https://www.rfc-editor.org/errata/eid5775. Joe's
proposed fix can be viewed at
https://github.com/emu-wg/teap-errata/commit/6fdcc5b155b8b844c4b9e2e24cddf8701a309424.
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 methodeach 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. If that is the case, then we should suppress the
crypto-binding TLV with the result TLV. This would surely break
existing TEAP implementations, and would require a version bump. In
this case, with regard to the erratum, we would HOLD FOR UPDATE.
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.
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.
Eliot
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
