Dan Harkins wrote: > The only type of credential that would have the issues you're > talking about is a long-term password used in PAP. Now I'm not > a big OPS guy but I do have quite a bit of experience in actual > deployments of 802.1X and EAP and I haven't seen them used anywhere.
TTLS is in wide-spread use in many environments. > If someone has a long-term password they're doing EAP-MSCHAPv2. I disagree with such a blanket statement. > If someone's doing PAP they're using a token card or some type of > OTP. See above. > Are you worried about a AAA proxy hijacking a client's OTP > and impersonating it? To what effect? An fake billing? Can't this > proxy engage in fraud with the client's MSK as well? Are you worried > about a AAA proxy doing an off-line dictionary attack against MSCHAPv2? It's bad security practice to expose information that doesn't need to be exposed. > Just out of curiosity, though, how do you propose to prevent > a proxy from seeing an MS-CHAPv2 exchange or an OTP fly by? The tunnel methods currently in use terminate the TLS tunnel at the home AAA server. No proxy sees the MS-CHAPv3 or OTP exchange. > These > tunnel methods typically terminate in devices that are also AAA > clients, and that's because people want to do this sort of thing-- > terminate the tunnel locally and then forward the client's credential > on to some central clearing house for a yea or nea. Can you describe a system in wide-spread use that does this? My experience has been that this practice is rare. It is generally done only within the home AAA domain, in order to enable inter-operability with AAA servers that don't do EAP. > Do you want to > prohibit an "inner method" from terminating on a different entity > than the "outer (tunnel) method"? I think the messages are clear. Speculation as to additional intent is not necessary. > If the client's credential needs more protection than the MSK > then why are we bothering with the tunnel method work? If you have a > pre-shared key, code, phrase, or word use EAP-pwd; if you have a > certified public key use EAP-TLS. That protects the client's credential > and regardless of where it's terminated the MSK will be seen by > intermediate proxies but so what. I agree with Sam on this point. I'm also unsure about the benefit of using a TLS-based method without using supplicant to home AAA TLS. Existing WiFi networks *already* use TLS for the web pages obtained over HTTPS. They then use WISPr to post the passwords. This is semantically identical to the proposal to terminate EAP-TLS locally, and proxy the inner tunnel data. The reason EAP channel bindings are being proposed is that many of the people who've deployed "local TLS + password" login methods see it as insufficient. They pretty much have the solution proposed by Glen, and they want something more. Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
