On Thu, June 24, 2010 1:55 pm, Alan DeKok wrote: > 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.
I disagree with disagreements that do not provide any justification for disagreement. >> If someone's doing PAP they're using a token card or some type of >> OTP. > > See above. 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. 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. >> 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. 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. >> 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. 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. 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. Notice how the tunnel method requirements document talks about "the inner EAP method"? It's an EAP method, not just some credential exchange, and being an EAP method it can be sent to another device. How do you propose that "the inner EAP method" terminate at the same place as the tunnel? Can you describe current deployments of tunnel methods that terminate everything, EAP-TLS plus some client credential authentication, at the home AAA server? >> 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. No, the message Sam communicated was not clear. He stated a problem and the implication of "fixing" that "problem" is, itself, a problem. I'm not speculating on anything. I'm asking a simple question. Since you agree with Sam on this then why don't you answer it? 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? Dan. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
