Section 2. - I am not sure if you are trying to restrict to the conversation between the initiator and the acceptor based on the fact that you are throwing in RADIUS. There is no RADIUS spoken here.
Section 2.1 - para #2 - The first sentence is just wrong. No matter what type of RADIUS you are using, intermediates always have access to the EAP MSK. The difference between RADIUS/UDP and RADIUS/TLS or RADIUS/DTLS is the question of how much passive intermediaries are going to be able to see based on the use of a long term shared secret. Section 2.2 - Passive observers may also be able to fingerprint the client based on TLS restart information. Section 2.3 - This should include exposing the realm of the user (or the full user name in bad implementations). You say [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method <http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method> ] could solve the problem of AAA proxies learning the MSK, impersonating the RP ] I would be very interested in seeing how you think there could possibly be a solution in this space. I can't see one. There probably needs to be a nod to using an application level tunnel as well. While I think that it might be nice to have this in the GSS-EAP layer, we cannot ignore this as an option. Jim
_______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
