In TTLS, any inner method challenge (CHAP / MS-CHAP) is tied to the TLS session:
https://www.rfc-editor.org/rfc/rfc5281.html#section-11.2.3 ... Upon receipt of these AVPs from the client, the TTLS server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the TTLS server MUST reject the client. Otherwise, it forwards the AVPs to the AAA/H in an Access-Request. Something similar is done for EAP-FAST, which TEAP is based on: https://datatracker.ietf.org/doc/html/rfc5422#section-3.3 ... Portions of the extra 72 octets are used for the EAP-FAST provisioning exchange session key seed and as the random challenges in the EAP-FAST-MSCHAPv2 exchange. The question is whether we need something similar for TEAP. TEAP has a Crypto-Binding TLV which binds the inner methods via their MSK / EMSK, which is good. But do we need to enforce binding of the challenges to the TLS session, too? Given that this isn't currently being done in implementations, I think that the answer here is "no". But it's likely worth adding a note to the effect that: * EAP methods such as EAP-MD5 and EAP-MSCHAPv2 rely in part on random challenges for their security in non-TEAP uses * these methods can be tunneled inside of TEAP phase 2 * there is no crypto binding of the challenges used here to the outer TEAP session * however, the results of the authentication bound to the TEAP session via the Crypto-Binding TLV. Since EAP-MD5 doesn't generate inner keying material, it might be worth banning EAP-MD5 for use in TEAP. Otherwise it is possible for MITM attacks. EAP-MSCHAPv2 does generate keying material, so it shouldn't have this issue. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
