> The solution to this conundrum is to associate authentication > credentials and authorization information with the original > authentication. That information can then be obtained and applied > during resumption. > > There are two ways to make this association. The first method is via > [RFC5077],
'session tickets for TLS versions 1.2 and below, and [RFC 8446] session tickets in TLS 1.3.' I know it's pedantic, but RFC 8446 obsoletes RFC 5077. .... > Any authorization applied during resumption MUST be done using the > cached data, 'or data resolved or obtained using that cached data.' authorization doesn't need to performed in a sandboxed environment with only the cached data. .... > * MAC address of the EAP peer * IP address of the EAP peer * > Informtion about the ethernet switch to which the EAP peer is > connecting > * MAC address of the switch > * IP address of the switch > * switch port used by the EAP peer > * Wifi SSID > * Information about the ethernet layer used by the EAP peer * Media-Type Cross resumption between VPNs and Wired/Wireless infrastructure could be a big issue. It might be worth mentioning that explicitly as I think it'll be a blind spot for implementors. Out of the box, if someone used our EAP server implementation for authenticating VPN users and wired/wireless users, we would allow cross resumption, because the EAP server doesn't allocate session tickets based in different contexts by default. > The EAP server also has access to the cached EAP-Response / Identity > from the original authentication. > > None of these fields are authenticated or secured. As a result, any > or all of these fields can change between the original > authentication, and resumption. This change creates a "Time of > check, time of use" (TOCTOU) security vulnerability. A malicious > user could supply one set of data during authentication, and a > different set of data during resumption. The malicious user could > then obtain different authorization during resumption, potentially > leading to them obtaining access that they should not have. > > When EAP servers make policy decisions based on unauthenticated > information, they MUST then add that information to the cached data maybe 'then it MUST be used in combination with the cached data described above' Took a couple of readings to understand exactly what you meant there. The cached data isn't being updated, but it's being used together with the unauthenticated information, right? The majority of this sounds great though. -Arran
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
