I've filed number of errata entries against RFC 7170. The email responses from rfc-editor seem to be cc'ed to this mailing list, but I don't receive them from the list or see them in the list archive. Anyway, if there are anyone here who would be interested in getting these reports reviewed and the issues addressed, that would be most helpful.
Some of these items are significant technical issues that prevent me from implemented the protocol and would also make me question how any implementation of TEAP would actually be able to comply with the RFC I can figure out the most likely answers to some of the entries, but there is no straightforward way of resolving the issues related to (1) Crypto-Binding TLV format for the cases where the negotiated TLS cipher suite uses SHA256 (or SHA384, for that matter) instead of SHA-1 (and I'd hope all deployments of TEAP would be recent enough to avoid use of SHA-1..): https://www.rfc-editor.org/errata/eid5768 (2) S-IMCK[j] derivation when inner EAP methods in the sequence derive both MSK and EMSK (or even more complicated, if there are multiple inner EAP authentication methods that have difference in whether they derive MSK or EMSK): https://www.rfc-editor.org/errata/eid5770 I'd hope to avoid having to guess or make my own specification of how this is supposed to work before being able to implement this (and then have to re-implement everything if others disagree with that interpretation/guess on the design), so any feedback on these items would be very welcome so that there would be a general agreement on how the protocol is supposed to work to provide better chances for getting interoperable implementations. - Jouni
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
