Dan Harkins wrote: > I disagree with disagreements that do not provide any justification > for disagreement.
By the same token, your original opinion lacks justification, too. My opinion is based on my experiences. As you do not share those experiences, I understand why they would be new information. I don't understand why you would discount them completely as being unjustified. > No, what's bad security practice is to expose a secret which allows > an attacker to completely void the security practices engaged in by the > client and NAS! Either a proxy is trusted (to see information that is > hidden from those who are not trusted) or it's not. You can't have it > both ways. I think it's a false dichotomy to label trust as binary. A proxy may not be trusted with long-term secrets, because abusing those long-term secrets is easy. It may be trusted with short-term secrets, because those secrets are short-term, and abusing them is difficult. >> The tunnel methods currently in use terminate the TLS tunnel at the >> home AAA server. No proxy sees the MS-CHAPv3 or OTP exchange. > > I disagree with such blanket statements. I know of implementations > of EAP tunnel methods by such vendors as Cisco that do otherwise. The > freeware hostapd software does too. Evidence abounds to contradict > you blanket statement. By "in use", I meant "in practice". This should have been obvious from the example I gave, which you deleted. In case you didn't know, I've written freeware which does exactly that: terminate the TLS tunnel, and proxy the inner data. This capability has driven some of the experiences noted earlier. And I don't think hostapd has that capability, as it's a much more limited RADIUS server. > Every wireless switch product I know of has a feature where the > tunnel is terminated on the switch and the "inner method" can go > elsewhere if so configured. Where is that used? Within an enterprise, or as part of a roaming consortium? Enterprises use it. They are terminating the TLS tunnel in the same administrative domain as the home AAA server. Which means no proxying. I don't know of any roaming consortium which uses that capability. > Look at PEAP. It's standard in the most > prevalent laptop software around and what are it's "inner methods"? > Well there's EAP-MSCHAPv2 and EAP-TLS. In other words, it's another > EAP method. And the client is speaking EAP inside of EAP because that > allows the "inner method" to be terminated somewhere else. I fail to see how using EAP in the inner tunnel is what "allows" the inner method to be terminated elsewhere. TTLS with PAP can be terminated elsewhere, too. > Notice how the tunnel method requirements document talks about "the > inner EAP method"? It's an EAP method, not just some credential exchange, That is not what the requirements document says. It refers to "inner authentication methods", and has no requirement that it be EAP. It *does* have requirements on the inner method if and when it is EAP. > and being an EAP method it can be sent to another device. Yes... as can any other inner authentication method. > How do you > propose that "the inner EAP method" terminate at the same place as the > tunnel? Pretty much the same way that people are doing it now. > Can you describe current deployments of tunnel methods that terminate > everything, EAP-TLS plus some client credential authentication, at the > home AAA server? Yes. Eduroam. Used by tens of thousands of people world-wide. > Alan, do you want to prohibit an "inner method" from terminating on a > different entity than the "outer (tunnel) method"? If the answer is yes > then I have no further questions. If the answer is no then I'd like to > know how you intend on keeping the contents of that "inner method" away > from the prying eyes of these proxy attackers? The proposal to terminate TLS on the visited network *requires* that the users credentials are exposed all the way down the proxy chain. The proposal to terminate TLS on the home network *permits* the home system to do what it wants with the user credentials. If you can't see a difference between the two scenarios, then there is nothing more to discuss. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
