On Mon, Jun 5, 2023 at 9:23 PM Alan DeKok <al...@deployingradius.com> wrote:
> 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: > > [Joe] I would also say no here. > * 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. > > [Joe] I'm in favor of banning EAP-MD5 for this and other reasons. > EAP-MSCHAPv2 does generate keying material, so it shouldn't have this > issue. > > [Joe] Yes it seems the protection should mostly be the same. > Alan DeKok. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
