Hi Joe, Why would someone go to the expense to implement EAP-TTLS or EAP-FAST but not also do some hash-a-password-with-nonces method like GPSK or MSCHAPv2 that proves to the client that the server knows the password? The only reason I can see to do PAP inside EAP-TTLS or EAP-FAST is when using a token card or other OTP. What other reason would someone do this? It's like driving a horse-drawn carriage instead of a car-- "why are you still using this failed technology?" (Apologies to the Amish on this list).
Dan. On Thu, June 24, 2010 3:45 pm, Joseph Salowey (jsalowey) wrote: > There are many deployments of Tunneled EAP methods (EAP-TTLS, EAP-FAST) > where a password is sent from the client to the Authentication server > within the protected tunnel. Terminating the tunnel somewhere other > than the home server would be bad as it would disclose this long term > secret. > > Joe > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of > Dan >> Harkins >> Sent: Thursday, June 24, 2010 3:07 PM >> To: Alan DeKok >> Cc: [email protected]; Sam Hartman >> Subject: Re: [Emu] Channel Binding Discussion at IETF 77: why bother >> >> >> 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 > _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
